AI 正在让编程变得更难吗？为何 “Test Only, Zero Code Review” 是一次彻底的灾难

Source: Dev.to

介绍

最近，一篇题为 “AI Fatigue is Real” 的文章引起了强烈共鸣，完美地呼应了许多开发者此刻的感受：在 AI 时代编程实际上变得更加疲惫。

我们已经从 创造者（构建者） 转变为 审阅者。AI 生成代码的速度极快且不一致，以至于审阅的负担变得压倒性沉重：

1. 无法进入心流状态。
2. 你不断在不同上下文之间切换。
3. 这种高密度的微观审阅极其消耗精力，并迅速让你陷入 决策疲劳。

社区观察

在向各个社区推广我的开源项目 fastfilelink CLI (ffl) 时，我一直在潜伏并观察主流开发者讨论。我看到的是无尽的焦虑、无限的炒作，以及一大堆“AI 将取代开发者”的论调，同时伴随着大量质量低劣的代码。

其中一些有其道理，但说实话，绝大部分简直是胡说八道。

“仅测试，零代码审查”提案

社区中出现了一个听起来很诱人的新主张（尤其是由当前以 OpenClaw 为主导的派系推动）：

“不审查代码；只审查输出 / 已通过的测试。”

有些人甚至把编译器当作类比，争辩说我们今天也不审查编译器生成的汇编代码。我认为这种论点根本上是有缺陷的。

为什么类比站不住脚

• 编译器使用严格的语法进行确定性的翻译。
• LLM 是概率模型。当你让 LLM 生成测试用例时，这些测试本身可能是伪造的或质量极差的。
• 即使所有测试都显示为绿色，也不代表系统没有问题。最终你仍然必须审查这些测试用例，所以“根本不审查”的前提是不可靠的。

当前大型语言模型的局限性

• Context windows and RAG capabilities 受限；LLM 只能看到项目的片段，无法整体理解系统。
• 生成的代码常常包含极度冗余，违反了 DRY（Don’t Repeat Yourself） 原则。
• 当需求变化时，代码容易出现大量不一致的错误。

架构崩溃在短期内难以解决

• 训练数据和注意力机制的物理限制意味着上下文窗口始终有上限。
• 项目将持续增长，超出上下文大小的任何提升。
• 因此，前述的架构崩溃在可预见的未来实际上是无法解决的。

测试覆盖率并非灵丹妙药

为了防止奇怪的、未修补的以及不一致的边缘案例错误，您的 测试覆盖率必须接近 100 %，并且测试必须以极高的严谨性设计。这让我们回到之前的观点：测试用例本身也是代码，被 LLM 大量复制粘贴。

如果您想省去审查生产代码的精力，就必须投入同等（甚至更多）的精力来审查大量的测试代码。您只是在把一个地狱换成另一个地狱。

为什么“只关心测试通过”是有缺陷的

• 根本缺陷：只关注测试结果而忽视代码是 AI 的炒作。听起来很棒，但实际充满问题。
• “它能工作”论点：即使大型语言模型最终在足够的时间和 token 下通过测试，项目也会充斥重复的逻辑，需要不断增加资源来修复。

关键点

1. 不进行审查是不可能的——你只是把审查的目标从生产代码转移到测试用例上。那仍然是代码，仍然会消耗你的脑力。
2. 维护成本呈指数增长——一旦技术债务堆积，修复哪怕是小错误也会消耗越来越多的 token 和时间。
3. 经济激励——最终受益的是 AI 开发工具供应商。代码越臃肿、调试需求越多，他们赚得越多。

结论

最古老的软件工程格言仍然成立：

“没有银弹。”

仅依赖 AI 生成的测试而忽视代码审查并不是银弹；它只是把一套问题换成了另一套问题。