規格導向開發：換上新包裝的瀑布式開發

資料來源#

• Uncle Bob on Software Fundamentals in the Age of AI

摘要#

Robert C. Martin（Uncle Bob on Software Fundamentals in the Age of AI，2026-08-19，practitioner-opinion）將業界目前對規劃的熱衷放在一條歷史脈絡中：

「誘惑在於先把規格寫好，叫人來寫規格，寫了又寫、再寫又寫，然後交給代理程式。**這是很古老的誘惑。1970 年代我們也經歷過這種誘惑。它讓我們走向瀑布流程，以及所有相關做法。**敏捷革命就是對此的回應。」

他對現代版本的判斷是親身經驗的報告，而非預測——他在受訪當週就一直在做這項實驗：

「我試過了。事實上，就在這週我一直在嘗試，結果總是一場災難。結果也總是一樣：你做了所有這些計畫，接著代理程式開始執行時，你這個人類才發現他們沒辦法照計畫做，因為你沒想到所有事情，而且他們沒有你那麼明智。於是他們就半吊子地跑去做些莫名其妙的事，你只好叫停、退回去、重寫計畫，然後讓他們重新開始。所以我放棄了。」

失敗模式是經典的那一種，只有一個新變化#

瀑布式開發之所以失敗，是因為計畫無法經受實際建造時揭露的狀況。Martin 描述的情形有著相同結構，只是換了個位置：落差不再發生於計畫與現實之間，而是發生在計畫與執行者之間。代理程式會稱職地照計畫做下去，越過人類早已停下來詢問的時刻。「他們沒有你那麼明智」是關鍵所在——人類實作者的判斷力默默彌補了計畫中的缺陷，而代理程式無法提供這種彌補。

他指出的新變化是，代理程式特別擅長產生那種會失敗的成品：

「代理程式很愛寫計畫。天啊，他們超愛。他們會把計畫寫得更豐富，讓計畫漂亮又精美，列出各式各樣的細節。」

漂亮的計畫比平庸的計畫更能讓人堅定投入，因此不斷把計畫做到極致的循環（Matt Pocock：「他們會讓七個不同的代理程式審查規格」）不只是浪費時間，還會適得其反。

經濟層面的論點：變更成本#

他支持敏捷做法的理由，是他過去在敏捷演講中常講的故事，只是更新了版本。假如房子的每一項變更——包括打地基——都只要一美元，沒有人會花好幾千請建築師畫出完美計畫；他們會移動廚房、看看效果，再移動樓梯、看看效果。

「變更成本已經降到我認為所能達到的最低點附近了——不過，這個預測我大概會看錯，但還是先說吧。變更成本降得這麼低，為什麼還要事先規劃？為什麼不就這樣反覆調整、反覆調整、反覆調整，直到看起來對了為止？」

他特別指出自己預期這項預測會失準，這點值得保留：整個論點都取決於變更成本能否維持在接近零的水準，而這正是可被證偽的部分。論點也默默假設有一道把關程序——只有在會造成破壞的變更能被抓出來時，低成本變更才安全；對他來說，這正是確定性檢查關卡的用途（重拾不切實際的品質工具）。

規格是短暫的，成品就是規格#

有人直接問他會不會把規格留在程式碼庫裡：

「不會，我不會。規格是短暫的，會消失。它們變動很大……我不再建立一份定義我想要什麼、甚至定義現有內容的規格，而是看著最後的成果說，嗯，那就是規格。」

他的理由是，過去原始碼就是最終規格，因為是人類撰寫的——「嗯，這種情況已經不存在了。原始碼還在，但寫程式的人已經不是我們人類了。」他認為，業界渴望保留規格，是在試圖恢復一種由人類撰寫、但如今工作流程已不再產生的真實依據。他自己的替代方案是工具：CRAP 評分器、變異測試工具、依賴規則檢查器，才是系統必須遵守的持久聲明；短暫的規格則是腳手架。

這和Matt Pocock既有的主張站在同一邊：「文件腐化會致命——實作完成後就刪掉 PRD。」兩人的出發點不同：Pocock 擔心過時文件會誤導未來的代理程式，Martin 則認為持久保存的規格從來就不是正確類型的成品。

與本文集觀點相左之處#

• **規劃與執行的分工**分析了 400K 個 Claude Code 工作階段中，人類約做出 70% 的規劃決策。這描述的是人們實際怎麼做，並不能證明大量前期規劃有效；Martin 的主張與這種分工並不矛盾，但反對進一步把工作推向計畫端。
• 設計概念質詢和 Matt Pocock的工作流程都在實作之前進行大量有架構的工作——但產出是共同理解和描述目標的文件，而不是代理程式逐步遵循的可執行計畫。Martin 針對的是後者；這項區分正是 Pocock 在訪談中追問的：「提示工程算不算規格導向開發？某種程度上算吧。」兩人都沒有定下界線；Pocock 提議以是否持續保存作為判準，Martin 則直接回答說他不保存。
• **垂直切片示蹤彈**是現有頁面中最接近 Martin 補救方法的做法——先做一個薄切片，再回頭檢視；這個想法源自《Pragmatic Programmer》，而非敏捷。
• **以程式碼作為真相來源和提交成品鏈**在他最明確的主張上採取相反做法。前者將規格提交到程式碼庫，讓人能檢查規格是否偏移；Anthropic 的 Applied AI playbook（vendor-claim，2026-08-21）更進一步，把已提交的 intent.md → spec.md → plan.md 鏈本身當成交接機制，並以 plan.md 作為 PR 審查依據。Martin 的「不，我不會」同時拒絕這兩種做法；代理程式會一路照著做、超出人類會停下來的時機才喊停的那份漂亮計畫，正是這條鏈要提交的成品。雙方都沒有測量任何結果——playbook 提供的是規範，Martin 報告的是經驗。能調和的部分在於範圍：他針對的是逐步執行的計畫，而 intent.md 更接近設計概念質詢的產出。無法調和的部分是 plan.md。
• **原型勝過 PRD從產品角度得出他所說的「那就是規格」——Dan Carey 的原型就是規格；AI 原生速度下的 PRD 替代光譜**則在同一條軸線上排列本文集從最重到最輕的建置前規格立場。Martin 位於光譜右端之外：完全不保存規格，將系統必須遵守的持久聲明交給檢查器，而不是任何成品。

他尚未解決的問題#

敏捷做法留下了一個他無法移除的人工步驟：「讓他們做一兩個使用者故事，然後我們看看最後的架構，也許我得親自介入，整理幾件事。」他正在嘗試自動化這種架構重整，「但到目前為止進展不大」（代理程式的深層模組）。所以，誠實描述他的立場，不是說規劃沒有必要，而是規劃從工作開始之前移到了各個工作增量之間，而增量之間的規劃仍由人類負責。

延伸閱讀#

• 氛圍式寫程式與代理式工程——相鄰的定義爭論；本文提出持續保存與否，作為在實作可見度上劃出的界線

• Robert C. Martin（Uncle Bob）——本文所述立場的主人，包括他指出可能會看錯的預測

• Matt Pocock——同樣反對持久保存規格，並提出以是否持續保存作為定義判準的人

• 規劃與執行的分工——本文主張不該再進一步推向計畫端的實測基準

• 設計概念質詢——不受這項反對意見影響的前期工作，因為其產出是共識，而非可執行計畫

• 垂直切片示蹤彈——最接近先做增量、再回頭檢視這項補救方法的現有論述

• 重拾不切實際的品質工具——讓低成本變更安全、而不只是便宜的檢查關卡

• 代理程式的深層模組——他目前還無法自動化的架構審查步驟

• Agentic Technical Debt——如果沒有檢查關卡就反覆調整，會累積的問題

• 原型勝過 PRD——從產品角度得出相同結論：成品就是規格，持久保存的文件只是腳手架

• 以程式碼作為真相來源——他拒絕的做法：把規格提交到程式碼庫以便檢查偏移；他的持久聲明則存在檢查器裡

• 提交成品鏈——本文集裡最強烈的相反立場：將 intent → spec → plan 鏈提交，作為交接機制；Martin 所稱的失敗模式正是鏈條的核心

• AI 原生速度下的 PRD 替代光譜——本文集衡量規格比重的軸線；本文位於其右端之外

• 持續保存是否是提示工程與規格導向開發的界線？——以本文集檢驗持續保存這條界線，並修正本文對 Martin 的描述：他確實在程式碼庫裡保留一份規格檔案（附有檢查器的依賴規則檔案），因此他的做法以可強制執行與否劃界，而非以是否儲存劃界

尚待解答的問題#

• 隨著系統成長，變更成本真的能維持在接近零嗎？還是會在系統達到某種規模後再度膨脹——如果如此，事先設計的理由就會恢復，也能判定 Martin 自己標出的預測是否正確？
• 在固定內容與讀取行為後，單看儲存形式是否會改變結果——同一份規格分別以已提交檔案和貼入對話的方式提供，兩種情況都要求代理程式在每次決策前重新閱讀，再以返工、缺陷率或偏移程度評分？本文集沒有任何研究做過這項測試；Khatri 的有／無消融測試架構（agent-context-files 頁面上的正確性零效應結果）是最接近的現有工具。若結果為零，持續保存就連替代指標的資格也會失去；若效果可測量，則會首次出現能與持續保存是否是提示工程與規格導向開發的界線？所主張的權威判準一較高下的實測結果。

已解答的問題#

• 持續保存是否如 Pocock 提議、Martin 的做法所預設，是區分提示工程與規格導向開發的正確界線？已回答：持續保存是否是提示工程與規格導向開發的界線？——不是。持續保存是權威性的可觀察替代指標（後續工作是否以該成品為依據？），而且它會在兩個方向上錯誤分類本文集：CLAUDE.md、WORKFLOW.md、REVIEW.md、工單關係圖，以及 Martin 自己的依賴規則檔案，都是持續保存且會再次參照的內容，卻都不是規格；相反地，質詢逐字稿、Carey 討論原因的對話，以及 Martin 刪除的計畫雖然短暫，卻完整承擔了規格的功能。此處引用的兩種立場也都遭到誤讀：Pocock 的說法是兩件事並列——「你有沒有持續保存規格……你會不會回頭參照那些規格？」——而只有後一句站得住腳（他會關閉而非刪除 PRD，撤銷其權威性但保留檔案）；Martin 會保存由檢查器強制執行的限制，只丟棄沒有任何機制強制執行的計畫。全文的來源類型都是 practitioner-opinion，而且本文集沒有任何研究測量持續保存本身的效果。

資料來源#

• Uncle Bob on Software Fundamentals in the Age of AI — Robert C. Martin 與 Matt Pocock，2026-08-19，practitioner-opinion