AI 寫的程式能不能信？Dave Farley：規格要會「變紅」才算數

一群平常意見不合的人，突然說了同一句話

Dave Farley 在影片一開頭就說：他很有主見，也大概知道 AI 時代的軟體開發會長什麼樣。更有趣的是，一堆平常不太同意彼此的人，最近都走到了同一個結論。

Bob Martin（Uncle Bob）說他已經不讀 AI 寫的程式碼了，改用一堆測試、品質指標、突變測試把 AI 圍起來。
Adam Tornhill 做了 25 年 TDD，現在放掉細碎的紅綠重構節奏，但留下一條鐵律：任何改動都得先有一個失敗的測試。
OpenAI 的 Sean Grove 在大會上說：把規格變成可執行的，拿規格餵模型，再拿規格驗結果。
Kent Beck 說 TDD 是跟 AI 合作時的超能力。
Emily Bache 說：所有測試加起來，就是規格。
Anthropic 的 Claude Code 指南寫得更直接：不能驗證的東西，就不要上線。

這些人的共同結論只有一句話：當機器寫程式，人的工作就是把「系統該做什麼」講清楚，而且要講成可以自動檢查的形式。 不是一段 prompt，不是一份 Markdown，而是一份會跑、會告訴你對不對的規格。

Farley 說，這件事他講了 20 年，叫做驗收測試驅動開發（ATDD）。現在大家各自繞路走到同一個地方，說明這個想法可能真的對。

寫程式從來不是最難的事

Farley 說，軟體開發一直有三個真正的難題：

講清楚你要什麼。 精確地說出系統該做什麼。
確認你真的拿到了。 驗證做出來的東西，就是你要的。
一小步一小步走。 步伐要小到一走偏就看得出來。

至於「把想法變成程式碼」這件事，從來不在難題清單裡。它只是花時間，不是難。

AI 改變的就只有這一項：把寫程式碼變得非常便宜。但三個真正的難題，AI 一個都沒解決。Farley 認為它反而讓每一項都更糟：

Prompt 比程式碼更模糊，更容易被誤解。
模型會順手改掉你沒要它改的地方，所以你不敢保證上次檢查過的功能還是好的。
一分鐘產一千行，讓人忍不住跨大步。真正重要的改動，就被淹沒在你根本不在意的改動裡。

換句話說，AI 把「容易的部分」變得更容易，把「難的部分」變得更難。

瓶頸不在寫，在驗

Steve Yegge 說他每天用 AI 產出 12,000 行程式碼。Farley 的反應很簡單：沒有人能一天認真看完 12,000 行。所以真正的問題不是「我們能多快產出程式碼」，而是「我們能多快知道這些程式碼做的事是對的」。

Kent Beck 有句話講得更狠。有工具宣稱一個 prompt 就能做完薪資系統的 80%，Beck 說：薪資系統做了 80%，等於做了 0%。沒人敢用一個八成正確的薪資系統發薪水。

為什麼「叫 AI 補測試」沒用

很多人的直覺是：那就叫 AI 把測試也寫一寫。Farley 認為這條路走不通，理由很簡單：

如果 AI 寫完程式碼才寫測試，那測試唯一的參考資料就是那段程式碼。從程式碼長出來的測試，只能證明「程式碼做了它現在在做的事」，沒辦法證明「程式碼做了你想要的事」。

「你想要什麼」這件事，程式碼裡沒有。它只能來自人，而且要寫成一種可以拿來量測結果的形式。

Spec-driven development：方向對了，材料錯了

業界其實已經注意到這個問題。2025 年「規格驅動開發」變成熱門解法：GitHub 推出 Spec Kit，主張「意圖才是真相來源」；Amazon 的 Kiro 把驗收條件結構化；Tessl 更進一步，主張該維護的是規格，程式碼只是可以重新產生的輸出；ThoughtWorks 把整個想法放進技術雷達。

Farley 說，這些人的診斷是對的：你不能用感覺去指揮 AI，太模糊了。你需要在 AI 開始前就有一份清楚的說明，而且這份說明在 AI 做完後還要留著。

但問題出在規格是用什麼寫的。這些工具的規格，都是 Markdown 散文。有結構的散文，但還是散文。

實際用過的人都撞到同一面牆：

Gojko Adzic（《Specification by Example》作者）試了 Spec Kit，發現 Markdown 規格缺一大堆細節。真正的規格最後還是落在單元測試和整合測試裡。
ThoughtWorks 的 Birgitta Böckeler 用了三套工具，回報說：就算有一堆檔案、模板、檢查清單，AI 還是常常沒有照著做。
Scott Logic 的 Colin Eberhardt 講得最直接：程式碼之所以是法律，是因為它是形式語言，可以推理、可以測、可以證明對錯。Markdown 規格沒有這種性質。

Farley 把整個問題濃縮成一句：散文規格，就是字數比較多的 prompt。 AI 讀了它，做出不符合規格的東西，但沒有任何東西會失敗、會變紅。所以 AI 不知道有錯，你也不知道有錯。你又回到讀程式碼、交叉手指、希望沒事的老路。

出路：規格和驗證要是同一份東西

O’Reilly 的作者 Marcus 點出了方向：BDD 做得好的時候，「寫規格」和「驗證規格」會收斂成同一個東西。

Farley 說這正是重點。規格和驗證應該是同一份文件。當它們是同一份時，規格就不可能跟程式碼漂移，因為一漂移，build 就壞了。

什麼叫「可執行規格」

可執行規格是一個例子，描述系統做某件有用的事，用業務的語言寫，但它會真的跑在系統上，而且在那個行為還不存在之前會一直失敗。

Farley 舉的例子：

Given 顧客的購物車裡有一本書 When 他套用折扣碼 SUMMER Then 購物車總額減少 10%

重點不在它寫了什麼，而在它沒寫什麼：沒有 HTTP、沒有按鈕、沒有資料表、沒有 class 名稱。它只說系統該做什麼，完全不說怎麼做到。

這不是寫作風格，而是整個方法的核心。Farley 的說法是：描述解法的規格不是規格，是設計。 而設計會在有人（或 AI）找到更好的做法時失效。

只描述行為的規格，不管你用哪種方式實作，它都成立。這種規格「更深層地為真」。如果你改了什麼讓測試失敗，測試就是在對你大喊：你的程式碼沒有做到你說它該做的事。

只要任何一種實作通過了所有的可執行規格，它就是合格的。當然，前提是你把想要的東西規定得夠清楚。規定得不夠清楚怎麼辦？Farley 說，那跟以前寫程式碼漏掉東西一樣：發現錯誤、再補規格，就像以前補程式碼。

四層架構：讓規格撐得過任何改寫

要讓「套用折扣碼」這種例子真的跑起來，Farley 和他的 AI 助手會把測試分成四層。他 2007 年在 LMAX 就是這樣做的，至今有上萬條這種規格在每次 commit 時執行。

規格在最上層，所有技術細節都在最下層。你可以換掉整個實作、換 web framework、用另一種語言重寫，最上層的規格一個字都不用改，而且還是會告訴你真話。

這對 AI 的意義很大。這種「what 和 how 分開」的做法，剛好就是 AI 需要的契約：它對「怎麼做」有完全的自由，對「系統該做什麼」零自由。規格既是它要達成的目標，也是評量它的尺，而且兩者是同一份東西。

三條實作規則

Farley 說，照這三條做，你跟 AI 合作寫程式的結果會好很多。

1. 規格先寫，AI 才開始

一次只寫一個情境。先看它失敗（變紅），再讓 AI 把它弄到通過（變綠）。

「先紅」不是儀式。跟 AI 合作時，紅燈是一個證明：證明你的規格有能力抓到錯誤答案。沒看過它紅過，你就不知道它綠的時候是不是真的。

2. 把規格放在 AI 碰不到的地方

Kent Beck 最近在煩惱一件事：AI 為了讓測試通過，會直接把測試刪掉。Emily Bache 也回報同樣的壞習慣，AI 遇到失敗的測試，不是修程式，是刪測試。

在這個方法裡，驗收測試就是契約，就是程式本身。所以要嘛放在 AI 改不到的地方，要嘛把每一次對測試的修改都當成契約變更，必須由人核准。

Bob Martin 的 AI 團隊裡有一個專門的「規格撰寫者」角色。Farley 的意見是：那個角色最好是人，至少要有人簽核它的產出。

3. 小步走

一個情境、紅、綠、review、commit。然後下一個。

這不是因為 AI 需要小步，而是因為人需要。小步是在「犯錯還便宜」的時候發現自己錯了的唯一方法。如果 AI 對著一份模糊的需求產出 3,000 行，那是跨了很大的一步。這種規模的 code review，根本看不出那是好的一步，還是摔了一跤。

常見質疑，Farley 怎麼回

質疑	Farley 的回應
這不就是穿著程式碼外衣的 waterfall？	如果你把整個系統的規格先用 Markdown 寫完，這批評成立。但 ATDD 一個情境只有幾行：寫、紅、綠、下一個。這是比大多數團隊今天還細的迭代。
小工作包跟規格驅動的精神相反（Böckeler）	小工作包就是 ATDD 的全部重點。
不讀程式碼會累積認知負債	Bob Martin 完全不讀，多數 TDD 實踐者還是會讀，Farley 自認在中間。可執行規格不是禁止你讀程式碼，而是讓讀程式碼變成「風險夠高時才做的選擇」，不再是「每一行都要讀的義務」。這就是能不能跟上 AI 產碼速度的分水嶺。
驗收測試又慢、又脆、斷言又少（Fowler）	寫得爛的驗收測試確實如此，而且比沒有還糟。解法是別把測試綁死在 UI 上，用四層架構隔開。再搭配突變測試：如果突變體活下來，代表規格有洞。
AI 寫的測試就不算 TDD（Ian Cooper）	同意。所以驗收測試要人來寫，或至少由人擁有、人批准。AI 可以起草一個、起草十個，但在一個真正懂問題的人說「這個算」之前，什麼都不算規格。

Farley 的結論是一句話：規格驅動開發，就是把「可執行」這部分拿掉的 ATDD。 業界現在正一篇篇部落格地重新發現：規格一定要能跑。

我的看法

這支影片最有價值的地方，不是論點本身，而是「大家都走到這裡了」這個觀察。Farley 沒有說「我早就講過了」，他說的是「連不同意我的人都這麼說，所以這可能是真的」。這個說法比自賣自誇有說服力得多。

三句最值得記住的話

「從程式碼長出來的測試，只能證明程式碼做了它在做的事。」 這句話直接拆掉「叫 AI 補測試就好」這個最常見的偷懶解。而且理由不是道德的，是邏輯的：輸入只有程式碼，就不可能帶進程式碼以外的意圖。

「描述解法的規格不是規格，是設計。」 這把「Given/When/Then 不要寫 UI 細節」從一個好習慣，升級成「不這樣做整套方法就失效」的結構性要求。這也解釋了為什麼很多團隊的 Cucumber 專案最後會爛掉：他們寫的其實是用 Gherkin 包裝的 UI 腳本。

「紅燈是你的規格能抓到錯誤答案的證明。」 以前先紅再綠是 TDD 的紀律，現在它有了新的意義：你在測試你的測試。

講得太輕的地方

把規格鎖起來，實作上比他說的難。 AI 要跑測試就得讀測試；要寫 DSL 和 driver 就得碰測試基礎設施。實務上大概只能做到「最上層的情境唯讀，其餘層可改但要 review」。這條線怎麼畫，影片沒展開。

規格的漏洞在 AI 時代會更危險。 Farley 說規格不完整就跟以前寫程式漏東西一樣，發現了再補。但人跟 AI 填空的方式不同：人會問，AI 會猜，而且猜得很有自信。所以「找出規格的洞」的機制（探索性測試、突變測試）可能比影片給的篇幅更重要。

四層架構的建置成本是真的。 LMAX 是頂尖團隊花多年打磨出來的。一般團隊從零搭 DSL 和 protocol driver 划不划算，影片用「我做了一個 skill 可以幫你」帶過。這同時也是他的產品。

「80% 等於 0%」不是放諸四海皆準。 薪資系統成立，探索型產品不一定。對一個還在找 product-market fit 的團隊，80% 可能正是他們需要的。

整體判斷

主張本身不新，但這可能正是它的價值。它把 2025 到 2026 年一堆看起來很新潮的規格驅動工具，重新放回一個有 20 年實證的實踐，並精確指出它們缺的那一塊：可執行性。

如果你本來就在做 Specification by Example 或 BDD，這支影片是一個外部背書：你的方法剛好是 AI 時代最需要的契約形式。如果你正在 vibe coding，或剛開始用 Spec Kit 這類工具，它給了一個清楚的診斷：你的規格會漂移，是因為它不會變紅。

來源

Dave Farley, The Industry Is Catching Up: The Only Way to Generate AI Code That Works, Modern Software Engineering 頻道。

本文根據影片字幕整理，人物說法均為 Farley 在影片中的轉述。