AI 写代码提速后，验证能力成了瓶颈

这周三，我想说个可能有争议的观点：如果你的团队采用了 AI 编程工具，却没有改变验证代码的方式，那你们并没有变快，只是在更快地借债。

过去，写代码是最耗时的环节。写一个函数要一小时，做一个功能要一周，敲代码的时间也给了你思考的空间。AI 助手和 Agent 把这个步骤压缩到了几分钟。但接下来的步骤，也就是确认代码是否正确，成本并没有降低。所以，瓶颈转移了。问题不再是“谁来写？”，而是“我们怎么知道它能正常工作？”

无法验证的代码不是资产，而是一笔尚未向你收账的负债。如果没有验证机制，却把代码生成速度提高到 10 倍，你就是在以机器的速度积累技术债。

数据已经指向了这个问题

我不打算编造数字。下面这三份公开资料，我认为每个用 AI 写代码的团队都应该读一读。

1. Google 的 DORA 2024 报告。 DORA 发现，AI 采用程度每提高 25%，对应的文档质量提高了 7.5%，代码质量提高了 3.4%，代码审查速度提高了 3.1%。这是好消息。但同样的采用程度提升，也对应着交付吞吐量估计下降 1.5%，交付稳定性下降 7.2%。他们的解释才是值得关注的部分：如果没有“切实遵循成功交付软件的基本原则，例如小批量变更和健全的测试机制”，开发流程的改善并不会自动带来交付的改善。报告还提出了一种假设：AI 会让变更集变大，而更大的变更处理起来更慢，也更容易导致不稳定。

2. Stack Overflow 的 2025 年开发者调查。 开发者对 AI 工具最大的不满是“AI 给出的方案差一点就对了，但就是不完全对”，有 66% 的开发者提到了这一点。排在第二位的是“调试 AI 生成的代码更耗时”，占比为 45%。而且，明确不信任 AI 输出准确性的开发者占 46%，超过了信任它的 33%。

“差一点就对了”的代码最危险。明显有问题的代码，出错时动静很大。差一点就对的代码，粗看没问题，演示也能过，却会在生产环境中，栽在某个没人写下来的边界情况上。

3. METR 在 2025 年开展的随机试验。 2025 年初，经验丰富的开源开发者在自己维护的成熟仓库中工作时，获准使用 AI 工具后，完成任务反而多花了 19% 的时间，但他们依然认为 AI 让自己提速了 20%。METR 自己如今也表示，这些结果已经过时，开发者使用当前工具很可能已经更快了，所以别把这 19% 当成什么自然定律。真正值得记住的教训，是感受与测量之间的差距：“感觉更快了”不是一种验证方法。

测试和规格说明才是真正的杠杆

工具厂商也在说同一件事。Anthropic 官方的 Claude Code 最佳实践说得很直接：给 Agent“一个它能运行的检查：测试、构建，或者一张可供比对的截图”。他们写道，如果没有这样的检查，“‘看起来做完了’就是唯一可用的信号，而你就成了那个验证循环”。

这句话概括了整篇文章的观点。如果没有可执行的检查，你就是测试套件，而你的精力无法随工作量一起扩展。

一个好的测试能发挥三种作用，而在 AI 出现之后，这三种作用比以前更重要了：

• 它是一份模型能读懂的规格说明。 “编写 validate_email；user@example.com 返回 true，user@.com 返回 false”，这个 prompt 比一大段文字描述好得多。示例用例能消除歧义。

• 它是一个停止条件。 有失败测试的 Agent，可以自行反复迭代，直到测试通过。没有测试的 Agent，则会在输出看起来合理时停下来。

• 它是一个防止倒退的棘轮。 一旦某个行为被测试固定下来，下一次生成的变更就无法悄无声息地破坏它。

先写测试，再写 prompt。 开发功能时，先写两三个示例用例，其中至少包含一个边界情况。修复 bug 时，先用一个失败的测试复现它，确认测试确实因为预期的原因失败，然后提交这个测试，再让 AI 动手修复。

让“完成”意味着“检查通过”。 用一条命令（make test、npm test、pytest）执行检查，失败时返回非零退出码。要求 Agent 运行命令并展示输出，而不是只说一句“我已经验证过了”。

保护好检查本身。 “修代码，别改测试。” 默认情况下，只要 AI 生成的 diff 削弱、跳过或删除了测试，就应该把它视为危险信号。

保持小规模变更。 DORA 对变更批量大小的提醒，在这里完全适用。一个由 AI 生成、包含 2,000 行代码的 PR，比十个各有 200 行代码、各自配有测试的 PR 更难验证。

把省下来的时间花在验证上。 如果 AI 把实现时间缩短了一半，就把其中一部分收益投入测试、类型和契约。这才是产生复利的地方。

“写测试会拖慢 AI 带来的速度。”如果只是一个用完就扔的原型，当然可以不写。但只要这段代码需要维护、部署，或者会有人在它的基础上继续开发，包括未来的你，这笔账迟早都要付。唯一的问题是：今天用一个测试来付，还是以后用一次事故来付。

AI 让代码变便宜了，却没有让正确的代码变便宜。未来几年，胜出的团队不会是生成代码最多的团队，而是验证代码最快的团队。

在你的团队里，验证最先卡在哪个环节：缺少测试、测试时好时坏，还是根本没人信任测试？

Google Cloud：《2024 DORA 报告发布》

DORA：《2024 Accelerate DevOps 现状报告》（PDF）

Stack Overflow 2025 年开发者调查：AI 部分

METR：《衡量 2025 年初的 AI 对资深开源开发者生产力的影响》

Anthropic：《Claude Code 最佳实践》

如需采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。