AI 编程提速之后，真正的瓶颈是认知能力

代码行数真的不能衡量 AI 编程效率吗？

软件工程领域长期以来有一个共识：代码行数不是一个好的生产力指标。

但在编码智能体出现之后，这个观点值得增加一些限定条件。

Simon Willison 提出了一个很实际的观察：过去，一名软件工程师每天能够交付几百行真正达到生产标准的代码已经非常困难。按照他的经验，一天完成约 200 行已经算非常出色，很多时候可能只有 50～60 行。

如果编码智能体能够帮助工程师完成 1000 行已经调试、测试，并且具备可维护性的代码，那么这种数量级的变化本身仍然具有意义。

关键前提是：代码质量不能下降。

也就是说，这些代码依然需要可维护、经过测试，并达到生产环境要求。要真正利用智能体做到这一点，仍然需要大量技能、知识和经验，而这些恰恰也是资深工程师的重要价值所在。

编码速度提高之后，一个新的限制会变得更加明显：认知容量。

Willison 的说法很形象：即使一个工程师借助智能体能够以过去几十倍甚至上百倍的速度生成代码，他也没有能力同时理解和掌控过去 100 倍规模的代码。

这也是为什么 AI 并不自然意味着软件团队只需要一个工程师。

除了团队只有一人本身存在明显的人员风险之外，更重要的是，大型软件系统需要多人共同承担理解、审查和维护系统的认知负担。

换句话说，AI 可以大幅降低“把代码写出来”的成本，却没有同步降低“把整个系统装进脑子里”的成本。

这又引出了《人月神话》中一个经典的软件设计概念：概念完整性（Conceptual Integrity）。

一个设计良好的软件系统应该具有一致而清晰的结构：各个部分彼此协调，没有令人意外的行为，系统覆盖的领域边界明确，整体设计能够说得通。

编码智能体让维持这种完整性变得更加困难。

以前，工程师想到一个新功能时，可能会先考虑：

这个功能需要一周时间，真的值得做吗？

时间成本本身形成了一道天然的约束。

但现在的情况可能变成：提出一个功能想法，写下提示词，几分钟后功能就出现了。原本需要一周的工作如果缩短到一小时，那么“顺手加上这个功能”就变得非常容易。

问题在于，每一个局部功能单独看都可能合理，但不断追加之后，整个系统未必仍然合理。

讨论中用温彻斯特神秘屋做了一个类比：房屋在漫长时间里不断增加新的房间，最终形成复杂甚至怪异的整体结构。这个比喻被用来描述编码智能体可能带来的软件设计风险——增加一个新“房间”的成本越来越低，于是系统不断向不同方向扩张，最终可能失去原有的概念完整性。

需要注意的是，关于温彻斯特神秘屋主人因通灵者建议而持续扩建的著名故事存在可信资料的质疑，因此这里更适合作为软件工程的比喻，而不是历史事实的依据。

编码智能体带来的一个有趣变化是：过去由成本强制执行的工程纪律，现在越来越需要工程师主动执行。

以前，一个功能需要一周时间，仅仅这个成本就足以让团队重新思考它是否值得存在。现在，当实现成本下降到几个小时甚至几分钟之后，这层天然过滤器正在减弱。

因此，AI 编程时代值得关注的指标可能不只是“生成了多少代码”，而是另外几个问题：这些代码是否仍然可维护和可测试？团队是否真正理解新增代码？新功能是否符合系统原有的设计边界？整个软件是否仍然保持概念上的一致性？

编码智能体可以让写代码变得非常便宜，但理解代码、维护系统边界以及决定什么不应该被加入系统，仍然是稀缺能力。