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)」。