别把"没人敢动"的代码留给未来的自己：谈谈 AI 生成代码的可维护性

一、一笔被忽略的账单：写得快 ≠ 改得动

AI 让"写代码"这件事变得前所未有的便宜。一句话进去，一片代码出来，速度令人上瘾。

但代码的一生里，"写"只占很小的一段。真正占大头的是后面那段：半年后加一个需求、一年后换个人接手、三年后想升级却发现——动一处塌一片。我们前面聊过的"不敢动的老代码"，很多其实就是当年图快留下的债。

所以这里想聊一件不在"提效"账面、却决定长期成本的事：AI 生成的代码，未来改得动吗？

写得快是本事，但如果行业性地用 AI 制造出一批"能跑、却没人敢碰"的代码，那我们只是把成本从"写"平移到了"维护"——而那笔账，更贵。

二、AI 生成代码常见的那几种"维护坑"

不是危言耸听，观察下来，AI 写的东西很容易带这几个毛病：

• 过度实现：为了"保险"，塞进大量用不到的分支、抽象层、兜底 try/catch。读的人不敢删——谁知道它是不是在防某个真实场景？
• 复制粘贴式的重复：它复制代码毫无心理负担，于是相似逻辑出现第五遍、第六遍。改一处，得找全所有副本。
• 命名与风格飘忽：同一个概念，这里叫 fetchUser，那里叫 loadUserInfo，下一个文件又成了 getUser。
• 注释讲了废话，缺了关键：要么把代码翻译一遍（// 分配内存 这种），要么完全不写——而真正该留的"为什么这么写、这里踩过什么坑"，一个字都没有。
• 抽象层级漂移：一个文件里，业务编排、数据转换、字符串拼接混在一起，读的时候得在三个思维层次间来回跳。
• 关键决策"只活在对话里"：为什么选这个方案、为什么绕过那个库——答案散在一次 AI 对话里，代码里毫无痕迹。

单看每一条都不致命，凑在一起就是"三年后没人敢碰"。

三、把"可维护"写进协作流程

关键动作只有一个：别再让"能跑通"当唯一验收标准。

具体可以这样做：

1. 验收标准加一条：“另一个没参与的人，能不能看懂并安全改动？”——把它和"功能正确"并列。
2. 先让它解释，再让它简化。拿到一段复杂实现，先问"为什么这么写"，再要求"用更直白的方式重写一遍"。很多时候，简单版本才是正确的。
3. 一致性优先于聪明。让它严格遵循项目既有的命名、目录、风格约定，别每个文件一套写法。风格一致本身就是可维护性。
4. 注释只留"为什么"。复述代码的注释统统删掉，决策理由、边界条件、踩过的坑，必须写下来。
5. 对"顺手加依赖、顺手加抽象"保持警惕。每一次新增，都要有个说得出的理由——为了省事而引入的东西，未来都会加倍讨回来。
6. 主动收敛重复。定期让它找相似逻辑并合并，而不是让第六份副本继续生长。
7. 用测试固定行为。有了回归护栏，后人才敢动。测试在这里的意义不是"证明写对了"，而是"给动手的人壮胆"。
8. 把关键决策落成可查阅的记录（设计说明、注释、提交信息都行）。代码之外的那部分知识，别让它只留在某次对话里。

四、一个最朴素的检验标准

不用复杂工具，问一个问题就够：

把自己想象成"三个月后完全忘了上下文的自己"，或者一个刚接手的人——能不能在没人讲解的情况下，看懂这段代码为什么这样、改动风险在哪？

能，就可维护；不能，就是债。这个"陌生人测试"，比任何 lint 规则都更贴近可维护性的本质。

五、但也别走过头

可维护不等于"抽象越多越好"。恰恰相反，过度抽象、过早抽象，本身也是不可维护的——绕三层才找到真正干活的代码，比一段平铺直叙更难懂。

还有两个分寸要守住：

• 投入应与生命周期匹配。一次性的脚本、用完就扔的原型，不值得为可维护性过度工程。
• 别用"优雅"拖住交付。可维护性是为了让后续更快，不是为了让此刻更慢。

六、结语

AI 让"写"的成本下降了，但"读"和"改"的成本不会自动跟着降，甚至可能上升——因为它把产出量放大了。

所以交付的标准，不该停在"它能跑"。真正该问的是：三个月后，这段代码还改得动吗？

把"可维护"从一开始就写进和 AI 的验收标准里，远比事后返工划算。毕竟，代码是写给未来那个要改它的人的——那个人，很可能就是你自己。