AI 應該幫我們寫出更好的程式碼，而不是更多 — Simon Willison 的論點與 77 則 Lobsters 激辯

「AI 讓程式碼變更糟了。」

你一定聽過這種說法。Stack Overflow 被 AI 生成的垃圾答案淹沒，GitHub 上到處是半成品的 AI 專案，code review 時看到明顯是 LLM 吐出來的樣板碼。這些抱怨都是真的。

但 Simon Willison 最近一篇文章提出了一個尖銳的反問：如果你的團隊用 AI 產出了低品質程式碼，那是 AI 的問題，還是你們的選擇？

這篇文章在 Lobste.rs 拿到 66 分、引發 77 則留言的激烈討論。正反雙方都說出了一些重要的東西。

Willison 的核心論點：改善程式碼的成本已經崩盤

Willison 的立場其實很簡單：過去你看到一個小 code smell，心裡想「改了吧，但要花兩小時」，然後你就不改了。技術債就是這樣一點一滴累積的。

現在，agent 可以在幾分鐘內完成這種重構。這代表什麼？

程式碼改善的成本已經低到我們可以對小 code smell 零容忍。

注意他不是在說「讓 AI 幫你寫更多功能」。他是在說「讓 AI 幫你把現有的程式碼打磨得更好」。這個方向性差異很關鍵。

三個具體使用場景

Willison 不只丟概念，他給出了三個他認為 AI agent 最能提升品質的情境：

1. 技術債清償

API 重新設計、變數命名清理、合併重複功能、拆分過度肥大的檔案。

這些工作有一個共同特徵：邏輯簡單，但極度耗時。人類工程師不是不知道該做，而是「值不值得花這個時間」的計算讓他們選擇忽略。Agent 把這個計算的天秤完全翻轉了。

2. 探索式原型

團隊在會議上爭論「activity feed 要用 Redis 還是 PostgreSQL？」傳統做法是花一週做技術評估報告。

Agent 的做法：直接建兩個原型、跑負載測試、產出比較數據。用實驗取代猜測，消除那些昂貴的直覺判斷。

3. 擴展解決方案空間

這一點最微妙。LLM 從海量訓練資料中學到了大量「無聊但有效」的常見方案。當你的團隊陷入思維定式時，AI 常常能提醒你：「欸，其實有一個更直接的做法你可能沒想到。」

Willison 稱之為「boring technology」推薦——不是什麼花俏的新架構，而是那些經過千萬個專案驗證的老派解法。

複合工程：讓品質產生複利效應

文章中提到一個來自 Every 的方法論叫做 Compound Engineering（複合工程），值得特別拆解。

概念很直覺：每次專案結束後做回顧，把「什麼 prompt 有效」、「什麼架構讓 agent 容易出錯」、「哪些模式可以重複利用」記錄下來，供未來的 agent 使用。

這會產生複利效應——第一次用 agent 可能只省了 20% 的時間，但當你累積了足夠的模式庫，第十次可能省 80%。更重要的是，品質也在複利。每一次回顧都讓 agent 的產出更貼近你團隊的標準。

如果這聽起來很熟悉，那是因為這正是 CLAUDE.md 的設計哲學——把團隊的知識、慣例、偏好寫進一個 agent 看得懂的文件裡，讓每次互動都站在上一次的肩膀上。

Lobsters 社群的 77 則激辯

理論說得再好聽，實戰派的工程師社群可不會輕易買單。以下是 Lobste.rs 上正反兩方最有力的論點。

同意方說了什麼

「繁瑣但可檢查的任務，AI 真的很強。」

多位留言者提到，TypeScript 遷移、大量 API 介面更新、跨檔案 rename 這類工作，交給 agent 效果極好。關鍵在於「可檢查」——你能快速驗證結果對不對，所以就算 agent 犯錯，修正成本也很低。

「LLM 擅長當水管工。」

有一則精彩的留言說：在現代軟體架構裡，大量工作是在不同 layer 之間做「plumbing」——前端接 API、API 接 service、service 接 database。這種工作 pattern 固定、容錯空間大，正好是 LLM 的甜蜜點。

「還技術債終於便宜了。」

過去要說服老闆花一個 sprint 去還技術債，簡直像在拔牙。現在如果同樣的工作只需要半天？決策門檻大幅降低。

反對方說了什麼

「學習問題被完全忽略了。」

這是最有力的反對意見。如果初學者從來不需要自己動手寫 boilerplate、不需要自己追蹤 bug、不需要自己做重構，他們要怎麼建立對程式碼的直覺？寫程式碼的過程本身就是學習的過程。

「激勵結構永遠推向數量。」

有人用工業革命做類比：紡織機理論上可以讓工人生產更精緻的布料，但實際結果是工廠選擇生產更大量的廉價布料。AI coding 工具的商業激勵結構也是一樣的——衡量 AI 產出的 KPI 通常是「寫了多少行程式碼」「完成了多少 ticket」，而不是「程式碼品質提升了多少」。

「Amazon 已經退縮了。」

留言中提到，Amazon 已經對 LLM 生成的程式碼踩了煞車。如果一家以自動化著稱的公司都覺得不對勁，那或許真有結構性問題。

「LLM 垃圾文件的膨脹雲。」

有人擔心一個更長期的風險：當 AI 讓產生文件和程式碼的成本趨近於零，我們會不會被淹沒在一片「看起來合理但沒人真正理解」的程式碼海裡？code review 的成本可能會因此暴增而非降低。

最有趣的中間立場

「文字改變了口述傳統，但沒有消除技能。」

這個類比很有味道：人類發明文字之後，確實不再需要「背誦整部史詩」的技能了。但新的技能（閱讀、寫作、文學分析）取而代之。AI coding 可能也是——我們會失去一些底層技能，但獲得更高階的系統思維能力。問題不在於「有沒有改變」，而在於「轉型期間我們能否好好管理這個過程」。

「大部分技術債不是已知的錯誤，而是未決定的設計選擇。」

這一點直接挑戰了 Willison 的「agent 清技術債」論述。如果技術債的本質是「我們還沒決定這段程式碼應該長什麼樣」，那 agent 能做的就很有限——因為決策本身需要業務脈絡和判斷力，這些不是 AI 的強項。

「品質 = 可理解、可導航、可擴展、可刪除。」

一位留言者給出了一個務實的品質定義。注意最後一項——「可刪除」。好的程式碼不只是容易加東西，也要容易拿掉東西。AI 生成的程式碼往往在「可刪除」這項特別糟糕，因為模組之間的耦合度難以控制。

學術研究：Anthropic 自家論文的硬數據

Lobsters 的討論是觀點交鋒，但 Anthropic 的研究員 Judy Hanwen Shen 和 Alex Tamkin 拿出了硬數據。他們的論文 “How AI Impacts Skill Formation”（2026 年 2 月）用 52 位開發者做了隨機對照實驗，讓他們學習一個新的 Python 非同步程式庫。

結論：AI 組的理解測驗分數低了 17%（p=0.010），但完成任務的時間沒有顯著加快（p=0.391）。AI 沒讓他們更快，也沒讓他們學到更多。

但真正的發現更有深度。研究者找出了六種開發者與 AI 互動的模式，其中三種保留了學習效果：

模式	Quiz 分數	時間	做了什麼
AI 全託管	39%	19.5min	只叫 AI 生成程式碼，直接貼上
漸進式依賴	35%	22min	第一題問問題，第二題整個丟給 AI
反覆 AI 除錯	24%	31min	不斷讓 AI 修 bug（5-15 次查詢）
概念詢問	65%	22min	只問概念問題，自己解決錯誤
混合式程式碼+解釋	68%	24min	要求生成程式碼時「附帶解釋」
先生成再理解	86%	24min	讓 AI 寫完後，追問「為什麼這樣寫」

低參與模式 24-39% vs 高參與模式 65-86%。差距是驚人的。

最差的模式是「反覆 AI 除錯」——不停讓 AI 幫你修錯誤，但從不嘗試理解根本原因。這些開發者最慢，也學到最少。最好的模式是「先生成再理解」——讓 AI 寫完程式碼，然後問它為什麼這樣寫。這些人的分數幾乎跟沒用 AI 的控制組一樣好。

兩個額外發現值得管理者注意：

Debug 能力差距最大。 AI 組遇到的錯誤比較少（中位數 1 vs 控制組 3），這代表他們得到的除錯練習也少了。
AI 組的參與者自己說「覺得變懶了」、「有很多理解上的缺口」。 他們知道自己學到比較少，但停不下來。

這篇來自 Anthropic 內部的研究，實質上確認了 Lobsters 社群的辯論：AI 輔助可以建立技能也可以侵蝕技能，取決於互動模式。技術是中性的，工作流不是。

我們的觀點：這不是 AI 的問題，是工作流的問題

讀完整場辯論後，我們認為正反雙方其實在吵不同的東西：

同意方在談的是「刻意設計過的 AI 工作流」
反對方在談的是「不加思索地讓 AI 生成程式碼」

兩邊說的都對。差別在於你怎麼用。

在 Claude Code 的生態系裡，我們看到一些模式正在讓「更好而非更多」成為現實：

品質門檻機制

Claude Code 可以設定 /self-review 和 code-reviewer agent，在程式碼產出後自動執行品質檢查。這不是可選的——它是工作流的必經關卡。Agent 寫的程式碼必須通過和人類一樣的 review 標準。

先測試，再實作

TDD（測試驅動開發）配合 AI 的效果極佳：先讓 agent 根據需求寫測試案例，然後再讓它實作。測試是「品質錨」，它強制 agent 的產出必須符合明確的行為規範。手動寫測試太痛苦所以很多人跳過？讓 agent 寫。然後你專注在 review 測試是否涵蓋了正確的案例。

複合工程的落地：CLAUDE.md

前面提到的複合工程概念，在 Claude Code 生態裡有一個天然的載體：CLAUDE.md。把你團隊的 coding convention、架構決策、常見錯誤模式全部寫進去，每次 agent 啟動都會讀取這份文件。每一次 session 的學習都回饋到這份文件裡。這不是理論，而是每天都在發生的事。

實戰數據

我們親身經歷過的案例：一個預估需要三天的跨模組重構（涉及 40+ 個檔案的 API 介面統一），用 agent + 明確的規格文件，在一個下午完成了，而且通過了所有既有測試。省下的不是三天的時間——而是三天裡可能產生的注意力疲勞、手動 typo、遺漏邊界案例。

品質不是偶然的結果，是刻意設計的產物。

結論：問對問題

「AI 會讓程式碼變好還是變差？」是一個錯誤的問題。

正確的問題是：「你的團隊有沒有刻意設計一個讓 AI 產出高品質程式碼的工作流？」

如果沒有，那 AI 確實會讓程式碼變差——因為阻力最小的路徑永遠是「更多、更快」。

如果有，那 Willison 說的就是對的：我們終於有能力對小 code smell 零容忍了。

Lobsters 上那位用文字類比的留言者說得好：技術革命不會取消技能，但會重塑什麼技能重要。在 AI coding 的時代，**「設計工作流」和「定義品質標準」**正在變成比「手寫程式碼」更關鍵的工程能力。

這不是降級，這是升級。但前提是你要主動掌握方向盤。