写得快不等于做得好#

James Shore（敏捷开发圈的老前辈了）在五月份写了一篇长文，标题很直接：你的 AI 编码 Agent 必须降低维护成本，否则你就是在给自己挖坑。

他的逻辑其实不复杂：每写一行代码，后面都有维护成本——bug 修复、依赖升级、设计缺陷的善后。假设写一个月代码，第一年要花 10 天维护，之后每年 5 天。听着不多，但积累起来很恐怖。按照这个模型，两年半以后团队一半以上的时间都在维护旧代码，十年以后基本动弹不得。

现在 AI 让你写代码速度快了一倍，但如果你写出来的代码维护成本没降，那你只是在更快地给自己挖坑。速度提升是暂时的，维护负担是永久的。

这个观点听起来像常识，但你仔细想想，有多少人真的认真评估过 AI 生成代码的维护成本？

说说我自己的经历#

用 Agent 批量生成 CRUD 接口，十分钟搞定了以前要半天的活，当时看着确实挺爽。但后面改需求的时候发现不对了——那些代码能跑，结构却很别扭。变量命名是”合理”的但不是”直观”的，错误处理是”有”的但不是”到位”的。改一个地方要连着改三四个文件，比我自己从头写还费劲。

后来学乖了，给 Agent 的指令越来越细。不再说”写一个用户注册接口”，而是”用这个项目的现有模式写，错误处理参考 auth 模块的写法，命名风格跟 service 层保持一致”。效果确实好了不少，但你品品这个转变——我已经不是在”让 AI 帮我写代码”了，我是在”教 AI 怎么按我的方式写代码”。这中间的区别挺微妙的。

多 Agent 并行，看起来很美#

最近还有个让我有点不安的趋势：多 Agent 并行。有人在 HN 上分享自己同时跑三个编码 Agent，连续跑了三天。Vibe Kanban 直接做了一个看板来管理多个 Agent 的工作流。InsForge 号称是”编码 Agent 的 Heroku”，让部署和运行 Agent 变得像部署 Web 应用一样简单。

理论上很诱人：三个 Agent 同时改三个功能分支，效率翻三倍。

但我跟几个试过的人聊了聊，反馈比较一致：管理三个 Agent 的认知负担，比管理三个初级开发者还大。Agent 不会主动跟你确认模糊的需求，它会自己”理解”然后直接开干。三个 Agent 各自”理解”出来的结果可能互相矛盾。你最后花在 review 和 merge 上的时间，可能比自己写还多。

这让我想到自动驾驶。L2 辅助驾驶很好用，但要求驾驶员随时准备接管。问题是人一旦习惯了”它在开”，注意力就不可避免地会下降。AI 编码也一样——你越依赖它，review 就越容易走过场，bug 就越容易溜进去。

实际怎么用才靠谱#

我不是要唱衰 AI 编码工具。它们确实是近几年对开发者生产力提升最大的东西。但”提升生产力”这件事，需要一些前提。

你得有足够的判断力来 review AI 的输出。不是说要逐行看每一行代码，而是你得知道什么结构是好的，什么是坏的。如果你自己都写不出清晰的代码，AI 帮你写出来的你也看不懂对不对。

维护成本应该成为评估指标。现在大家衡量 AI 编码工具主要看”写得快不快”、“一次通过率高不高”。但很少有人追踪”AI 写的代码半年后的 bug 率”、“AI 写的模块重构频率”。这些数据不难收集，但大家好像不太愿意去量。

别急着上多 Agent。单个 Agent 用好再说。管一个人和管三个人完全是两回事，先把一个人的工作流跑通，review 流程建好，再考虑扩展。

社区在往哪走#

有意思的是，社区已经在往”让 Agent 写出更好维护的代码”这个方向努力了。ProofShot 给 Agent 装上”眼睛”，让它能验证自己写的 UI 是不是真的对。Mozilla 的 Cq 项目想做”Agent 的 Stack Overflow”，让 Agent 之间共享错误处理的经验。还有人做了 Agent 专用的记忆系统，让 Agent 能记住”上次这种写法踩了什么坑”。

这些尝试都在解决同一个问题：怎么让 AI 写的代码不只是”能跑”，而是”好维护”。

写代码从来不是最难的部分。理解需求、做出取舍、保持代码库长期健康——这些才是。AI 现在很擅长第一件事，后面的路还长。

我现在的做法是把 AI 当一个特别勤快但不太有主见的搭档。它干活快，但方向得你来定。你要是自己都没想清楚要什么，它只会更快地帮你做出一个你不满意的东西。