没有测试的 AI 生成代码，就是机器速度下堆积的技术债

Dev.to AI 2026-10-21T09:45:32.219394

周三了，说个我个人的直白看法：如果你的团队上了 AI 编程工具，却没改验证代码的方式，那你并没有变快，只是借钱借得更快了。

过去写代码是最慢的环节。写一个函数要一小时，做一个功能要一周，敲键盘的这段时间其实也留给了你思考的空间。AI 助手和智能体把这一步压缩到了几分钟。但紧接着的那一步——确认代码是对的——一点都没变便宜。所以瓶颈挪了位置。现在的问题不再是"谁来写"，而是"我们怎么知道它能跑对"。

验证不了的代码不是资产，而是一笔还没出账单的负债。没有验证层，生成速度快上 10 倍，你就是在以机器的速度累积技术债。

数据已经指向这个方向。我不会自己编数字，下面是我认为每个用 AI 写代码的团队都该读的三份公开资料。

1. Google 的 DORA 2024 报告。
DORA 发现，AI 采用率提高 25%，对应的变化是文档质量提升 7.5%、代码质量提升 3.4%、代码审查速度提升 3.1%。这是好消息。但同样的 25% 提升，也对应着交付吞吐量下降约 1.5%、交付稳定性下降 7.2%。

他们的解释才是关键：优化开发流程并不会自动改善交付，"除非真正落实成功交付的基本功，比如小批量变更和可靠的测试机制。"报告还提出一个假设：AI 会让变更清单变大，而变更越大，交付越慢，也越容易不稳定。

2. Stack Overflow 的 2025 开发者调查。
开发者对 AI 工具最大的不满，66% 的人选择了"AI 给的方案差不多对，但就是不完全对"。排第二的（45%）是"调试 AI 生成的代码更费时间"。而且，明确不信任 AI 输出准确性的开发者（46%）比信任的（33%）更多。

"差不多对"是最危险的一种代码。明显坏掉的代码会大声报错。差不多对的代码，一眼扫过去没问题，跑个 demo 也没问题，最后却在上线后、在没人写进文档的边界情况上出问题。

3. METR 的 2025 随机对照试验。

2025 年初，一项针对经验丰富的开源开发者的研究发现：在他们自己维护的成熟代码库上，允许使用 AI 工具后，任务耗时反而增加了 19%；但开发者本人却坚信 AI 让自己提速了 20%。METR 如今也表示，那批结果已经过时，用现在的工具开发者很可能确实更快，所以别把 19% 当成铁律到处引用。真正持久的教训，是感知与测量之间的鸿沟：「感觉更快」不是一种验证手段。

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

工具厂商的说法也是一样的。Anthropic 官方的 Claude Code 最佳实践讲得很直白：要给智能体「一个它能运行的检查：测试、构建、截图对比」。他们写道，如果没有这样的检查，「『看起来做完了』就是唯一可用的信号，而你就成了那个验证回路。」这句话就是全部论点。没有可执行的检查，你就是测试套件，而人是没法水平扩展的。

一个好的测试干三件事，这三件事在有了 AI 之后比从前更重要：

我会怎么做

先写测试，再写提示词。 做新功能，先写两三个示例用例，其中包含一个边界情况。修 bug，先把它复现成一个失败的测试，确认它是因为正确的原因而失败，提交之后再让 AI 去修。

让「完成」等于「检查通过」。 一条命令（make test、npm test、pytest），失败时以非零状态退出。让智能体去跑它、把输出贴出来，而不是让它说「我已经验证过了」。

保护检查。 「改代码，别改测试。」任何削弱、跳过或删除测试的 AI 改动，默认都当作危险信号。

保持改动小。 DORA 关于批次大小的警告在这里直接适用。一个 2000 行的生成式 PR，比十个各带测试的 200 行 PR 更难验证。

把省下来的时间花在验证上。

如果 AI 能把实现时间砍掉一半，那就把省下来的这部分红利投到测试、类型和契约上。复利效应正是从这里产生的。

有人会反驳：“写测试会拖慢 AI 给我们的速度。”如果只是一次性原型，那确实可以不写。但只要代码需要维护、要上线部署，或者会被别人（包括未来的你）继续开发，这笔账迟早要还。区别只在于：是今天用一个测试来付，还是以后用一次线上事故来付。

AI 让代码变便宜了，但没让正确的代码变便宜。

未来几年能赢的团队，不会是生成代码最多的团队，而是能最快验证代码的团队。

你们团队里，验证最先从哪一环崩掉？是缺测试、测试不稳定，还是测试没人信？

参考来源：

查看原文