一个用于编写代码的AI编码助手，需要降低你的维护成本
你需要能降低维护成本的AI
2026年5月10日
我直截了当地说吧：你的AI编码助手，也就是你用来写代码的那个，需要降低你的维护成本。而且不是降低一点点。你现在写代码的速度快了一倍？那最好你的维护成本也减半了。效率提高了三倍？那维护成本也要降到原来的三分之一。否则，你就完了。你是在用暂时的速度提升换取永久的束缚。
哦，你想知道为什么？当然可以。咱们来兜个风。在一条黑暗的沙漠公路上……
生产力由维护成本决定
你写的每一行代码都需要维护：修bug、清理、依赖升级等等。我说的不是新功能或优化，只是维护。你花一个月写代码，接下来一年里就要花一定时间维护这些代码，之后每年都要花一些时间，只要代码存在，就永远如此。
假设你问一群开发者，比如50个人，这些维护成本是多少。使用一种叫做群体智慧的技术，你就能得到相当准确的回答。¹
¹ 欢迎你自己做一次群体智慧调查！不过具体数字对我这里的整体论点来说并不重要。
你的这群开发者可能会告诉你，每花一个月写代码，你就要花……
- 第一年维护10天；并且
- 之后每年维护5天。
如果你特别执着，可以花几个小时做个电子表格，模拟这些估计值如何随时间影响生产力。像这样的电子表格。
新项目的第一个月是辉煌的。你把所有时间都花在构建炫酷的新功能上。
第二个月就没那么辉煌了。你的一小部分时间——不多，但一点点——花在了修复错误和清理第一个月设计失误上。第三个月，又多一点。第四个月、第五个月、第六个月……如此下去。
最终，它一点都不辉煌了。根据我们收集到的维护成本估算数据，两年半后，你将花超过一半的时间在维护上。十年后，你几乎做不了其他任何事情。
将维护成本估算减半，你就能在达到50%门槛前再多争取三年。而翻倍的话，你在不到一年内就会低于50%。
教训很明确。如果你想要一个高效的团队，就必须关注他们的维护成本。
所有模型都是错的
这些数字对你来说真实吗？对我来说是的。在我作为顾问的职业生涯中，我专门服务晚期初创公司，它们都存在上图所示的精确问题。大约5-9年后，它们会注意到团队再也无法高效完成任务，然后就会找我。
他们的团队其实并没有图表显示的那么糟糕。也许他们的维护成本更低。或者……我觉得这个可能性更大——他们的维护成本正是那么糟糕，只是他们掩耳盗铃了而已。也许他们：
- 决定不修复每个 bug，或不升级每个依赖
- 当团队变慢时增加人手……然后继续增加，因为永远不够
- 推倒重来，开始重写
具体的维护数字可能有争议，但总的来说，这个模型是对的。如果你经验丰富，你知道这张图是真的。你见过生产力如何随时间流逝而消失。你有切肤之痛。
这和 AI 有什么关系？
一切都有关系。
假设你的团队刚刚开始使用 Rock Lobster（最先进的神级 AI 编码框架），你的代码产出翻倍了！！哇哦！不过，代码变得更难理解了，你的团队淹没在 pull request 中，而且你或许在点下“批准”按钮之前，根本就没有真正读过代码。说真的，完全没有。我的意思是，你在无聊的会议中扫了两眼，偶尔而已，这总该够了吧？LGTM，赶紧搞定它吧！
所以现在你一个月干出两个月的活，假设每个“月”的产出维护成本翻倍。那么下个月的维护成本翻四倍。