接手 AI 烂代码要花多久，我的真实进度

2026-09-22 AI编程,代码重构,真实记录

接手烂代码一般要花多久，我自己这几轮的答案是：读懂占一半，动手占另一半，而且读懂那一半没法压缩。 这个结论不好听，但它是我把时间花在哪看了一遍之后得出的。

下面是我的真实进度记录。数字只写我确实记过的，其余用具体动作代替。这一点我吃过亏：之前直接开读，读了几天也没建立整体印象。

接手烂代码一般要花多久：我的时间线摊开

第一天：只做一件事，把它跑起来。 没跑起来之前我没读一行代码，因为读出来的理解没法验证。

第二天到第三天：找出口、列清单。 对外能力表、数据流向、不敢动的地方，三样凑成一页纸。

第四天开始：才动第一处代码。 动的是重复最多、被调用最频繁的那一段。改完立刻跑一遍。

之后每一处改动：都是「改一处、跑一遍」的节奏。 我没有一次改多个地方，因为改多了就分不清因果。

收尾阶段：把读懂的东西固化下来。 出口清单、数据结构说明、异常分支清单，三样加起来一页。

接手别人的 AI 项目时，最贵的成本不是改代码，是建立判断基准。

你要知道哪个地方动了会牵连哪里、哪几个行为是业务要求不能碰。这些信息不会写在代码里，只能靠跑、靠问、靠画出来。

跳过这一步直接改的人，往往在改到第三处的时候开始反复回滚——那种反复比老老实实读几天更费时间，也正是「接手烂代码一般要花多久」这个问题的答案被拖长的原因。

顺便说一句，这部分工作是可以借力的。用 AI 帮你解释结构、整理清单都行，只要喂给它的是真实信息（接口定义、数据表、实际报错），而不是一句「帮我理解这个项目」。

第一，先跑起来再读。 这是我这轮最大的改进。以前拿到项目就开读，读到一半发现理解有偏差，前面的时间基本白花。

第二，一次只改一处。 这条看着保守，但它是唯一能让你在出问题时迅速定位的做法。

第三，把「不敢动」写下来。 这份清单让我避免了几次冲动改动。凡是列在清单上的地方，我都先问清楚再碰。

错在了第三天想直接重写。 当时觉得乱得没法改，一度准备推倒重来。冷静下来后发现连哪些行为要保住都说不清——这种情况下重写必然漏东西。

还错在给一个模块补了详细注释。 补到一半我就意识到这是无底洞，AI 代码的量级不适合逐行注释。后来改成每个函数只写一句话：什么时候被调用、失败会怎样。

能复制的是顺序，不能复制的是判断。

顺序部分——先跑、再列清单、最后动手、一次改一处——这套任何人照做都有用，而且不需要什么经验。

判断部分——比如「这个模块该修还是该重写」，就得靠积累。我给不了标准答案，我自己的判断依据写在修 AI 的代码还是重写，我用两个模块试过里，可以对照着看。

如果你手上正好有项目要接，起手顺序那篇更直接：接手别人用 AI 写的项目，怎么开始理。

Q：接手烂代码一般要花多久，有没有大概范围？

A：我给不了统一数字，因为差异主要来自代码量和你能不能联系上原作者。能压缩的只有动手那一半，理解那一半基本压不掉。判断标准是：你说不清数据流向之前，别动手。

Q：怎么判断自己已经读懂了，可以开始改了？

A：三个检查点。你能说出数据从哪来到哪去、能说出改动会影响哪些模块、能说出这个模块失败时会怎样。三条都答得上就可以动手了。

Q：如果时间很紧，能不能跳过准备直接改？

A：能，但要接受返工。跳过准备最直接的后果是改完不知道影响了哪里，出问题后定位时间会成倍增加。真赶时间的话，宁可只做一个小改动，也别做大范围调整。