AI 时代写程序反而更累？「只看 Test 不 Review Code」根本是场灾难

最近有一篇文章《AI Fatigue is Real》 引发了强烈共鸣，完美说出了现在许多开发者的心声：AI 时代编程反而更累了。

因为我们从创造者（Builder）变成了审查者（Reviewer）。AI 产出源代码的速度太快又不稳定，导致 Review 的负担变得极重：一来无法进入心流，二来不断 Context switch，三来这种高密度的微观审查，是种极大的消耗，很快就会让人陷入「决策疲劳」。

最近我在各大社群推广我的开源项目 fastfilelink CLI (ffl) 时，潜水观察了主流开发者的讨论。我看到的是满满的焦虑、无止尽的 Hype，以及伴随着大量粗制滥造的源代码，所衍生出各种「AI 将取代开发者」的方法论。

其中有些确实有道理，但有很大一部分，说白了就是鬼扯。

为了对抗这种疲劳，现在社群（特别是现在以 OpenClaw 为主的流派）诞生了一种听起来很爽的主张：

"Don’t review code; review output / tests passed."（不要 Review 源代码，只要 Test 会过就好。）

有人甚至拿 Compiler 来类比，说我们现在也不会去 Review Compiler 产生出来的 Assembly。我个人觉得这个说法根本狗屁不通。理由很简单：

1. LLM 不是 Compiler，它没有「确定性」

Compiler 是基于严格语法的确定性转换，但 LLM 是概率模型。你叫 LLM 产生 Test Case，它有时候连 Test 本身都是假的或质量不到位。就算绿灯全亮，也不代表系统没问题。你终究得去 Review 这些 Test Case，所以「完全不 Review」根本不靠谱。

2. 缺乏全域视野，导致 Single Source of Truth 崩坏

受限于 Context Window 及 RAG 的能力极限，LLM 只能看到项目的碎片，无法理解系统全貌。这导致它产生的源代码会有极度多的重复内容，完全不 DRY（Don't Repeat Yourself）。一旦需求变更，极容易产生大量不一致的 Bug。

3. Context Window 的极限是短期无解的硬伤

不要幻想「以后模型变强就好了」。受限于训练资料与注意力机制的物理极限，Context Window 永远会有天花板（更何况 Context window 不管多大，项目只会更大），所以第 2 点的架构崩坏问题，在可见的未来几乎是无解的。

4. 陷入「鸡生蛋、蛋生鸡」的无穷循环

为了防堵第 2 点那些奇奇怪怪的边角 Bug，你的 Test Coverage 必须逼近 100%，而且必须设计得极度严谨。这就回到了第 1 点：Test Case 本身也是 Code，也是 LLM 大量 Copy/Paste 写出来的。

如果你想省下 Review Production Code 的力气，你就必须花同等（甚至更多）的心力去 Review 庞大的 Test Code。你只是把一个地狱换成了另一个地狱。

残酷的现实：这是一场「算力资本主义」的游戏

所以，只看 Test Case 会过而不去管 Code 的方法论，有着根本上的基本问题。它更像是一种 AI Hype，听起来很爽，但实务上问题一大堆，只是把一个问题换成了另一个问题。

当然，你可能会说：「但似乎 it works 啊！只要只管 test / output，给 LLM 足够的时间和 Token 让它去修，它还是能把 test 跑过。」

哦，是啊！因为项目越来越大，被 LLM 搞得重复逻辑越来越多，你确实可以砸钱让它慢慢改。但重点是：

• 不 Review 是不行的： 只是你 Review 的对象从 Production Code 变成了 Test Case，那依然是 Code，依然消耗你的脑力。
• 维护成本呈指数级累加： 技术债叠加之后，改一个小 Bug 需要消耗的 Token 和时间越来越多。

人都懒，谁不想把所有工作都丢给 AI？（尤其是对本来就不那么享受写程序的绝大多数开发者来说，这只是一份工作）。所以这种「AI 可以帮你做完所有事」的叙事只会让人感到兴奋，同时也贩卖了焦虑。

但最终的受益者是谁？是那些 AI 开发工具商。 源代码越冗长、你需要 Debug 的次数越多，他们赚得越多。他们不想让你知道的残酷真相是：软件工程界那句老话依然适用——「没有银弹 (No Silver Bullet)」。