Ars Technica 上周的这篇报道触及了一个已经在工程团队里发酵了很久的问题：AI 编码 Agent 生成的代码行数在增长，但实际可交付的软件数量并没有同步提升。这个落差不是一个模糊的感受，而是一个可以被观察和测量的现象。
瓶颈在哪里
报道的核心论点是：速度的瓶颈从来不在”写代码”这一步。集成、测试和代码审查才是吞吐量的真正限制。
AI Agent 的加入让代码生成速度大幅提升，但它并没有自动地让这三件事变得更快。相反，当生成量增加，审查压力反而同步上升。一名工程师在单位时间内能消化的代码量是有限的，无论这些代码来自人还是模型。
这让我想到一个具体的类比：假设你有一条装配线，零件供给速度提升了三倍，但质检和组装工位的数量没变。产出不会变成三倍，反而可能因为待检队列积压而降低。
为什么这个问题被低估
早期评估 AI 编码工具的团队，很多人用的是”节省了多少行代码”或者”任务完成速度快了多少”来量化收益，这是自然的选择，因为这两个指标容易测量。
但这两个指标都绕过了集成和验证。代码生成快，不代表这段代码能顺利合并进现有系统；合并进去，不代表它在真实负载下行为符合预期。审查环节需要的是判断力，而不只是阅读速度，这是现阶段 Agent 最难覆盖的部分。
更重要的是，生成的代码越多，潜在的集成风险表面积也越大。这对依赖小型工程团队的项目尤其明显，因为审查资源是固定的。
如果要重新校准 ROI 预期
我的判断是，在评估 AI 编码 Agent 的实际价值时，应该将”软件吞吐量”而非”代码产量”作为主要指标。具体来说，可以跟踪以下变化：
- 从任务创建到合并进主干的时间有没有缩短
- 代码审查积压有没有加重
- 集成后的缺陷密度有没有变化
这些指标比代码行数更难收集，但它们更接近真正想要回答的问题。
另一个值得观察的方向是：Anthropic 这次更新中提到 Claude 可以自主规划任务拓扑，即动态工作流。如果 Agent 不只是生成代码，还能承担测试用例编写和局部集成验证，那么”生成但不可交付”的问题或许会在架构层面得到一部分缓解。但这还是一个条件句，具体效果要等有实际使用数据再说。
当前这个阶段，对工程团队更务实的建议是：在部署 AI 编码 Agent 之前，先确认审查和集成流程有没有足够的容量来消化更高的代码产出。否则瓶颈只是从”写得太慢”变成了”堆积太多”。
参考资料
完整版日报请看 爱窝啦 AI 日报