敏捷贏瀑布，靠的其實只有一條理由。而 AI 剛好把那條理由抽掉了——但接手的不是瀑布。
先講清楚我不主張什麼。我不是要在這裡宣布瀑布平反，也不是要說「spec-driven development」是我發明的詞——業界討論它很久了。我要主張的只有一件事：敏捷與瀑布的取捨，從頭到尾建立在一個成本假設上；那個假設正在我手上失效，而失效的方式跟大多數人以為的相反。
還有一件事要先標好：這篇是論證文，不是實測報告。上一篇我給你的是一組讀數，這篇沒有。它的力氣全部花在拆一條推理鏈上——如果那條鏈斷在哪裡，你不需要任何數據就可以推翻我。文末我會把證據等級一條一條標清楚。
一、敏捷贏瀑布，其實只靠一條理由
我們把敏捷勝出的理由講得很多——擁抱變更、持續交付、快速回饋、以人為本。但真正在承重的，其實只有一條：需求會變，而改的成本很高。
順著這條理由往下推，整套邏輯是這樣長出來的：
前期大設計（Big Design Up Front）＝在你對問題理解最淺的那一刻，一次把方向賭死。一旦賭錯，代價不是「改個文件」，是大量已經寫好的 code 白寫。推倒重來很貴，貴到你賭不起。
所以「改的成本高」是瀑布的原罪。而敏捷的整套機制——短迭代、持續交付、擁抱變更——本質上是一種避險工程：既然你賭不起大的，那就把賭注切小，讓每一次「賭錯」的下注額都在你賠得起的範圍內。
這裡值得停一下：
敏捷贏，不是因為它天生更對，而是因為在「改很貴」這個前提下，把賭注切小是理性的。
換句話說，這條贏的邏輯，地基是一個成本假設，不是一條真理。而成本假設這種東西，是會被技術換掉的。
二、AI 從兩個相反的方向抽掉那塊地基
AI 沒有選邊站。它做的事更狠——它把上面那塊地基抽掉了，而且是從兩個相反的方向同時抽。
一個方向讓瀑布的原罪失效，另一個方向把整個瓶頸搬家。這兩件事必須一起看，只看其中一個都會得出錯誤的結論。
斷點①：寫 code 的成本崩塌，於是「白寫」不再那麼痛
寫 code 的成本崩塌，直接後果只有一個：「做錯了重做」變便宜了。
瀑布最怕的那件事——賭錯方向、大量 code 白寫——威力因此大幅下降。既然重寫幾乎免費，那句對瀑布最核心的指控「一次寫太多會浪費」，就鬆動了。
這是個反直覺的結果，而我認為它值得被講白：AI 反而讓瀑布的一部分反對意見失效了。 敏捷當年那些「別做大設計、免得白寫」的告誡，前提正在蒸發。
但請注意分寸，我在這裡不打算多送你一寸：失效的是「白寫成本高」這一支反對意見，不是瀑布整體翻案。 瀑布還有另一個真問題——回饋太晚——那個問題 AI 一點都沒有解決，而且待會你會看到，它反而變得更致命。
斷點②：瓶頸整個搬家，從「做得出來」到「要什麼、驗得出嗎」
這是更關鍵、也更容易被忽略的一處。AI 不只是讓某個環節變便宜，它把整個瓶頸搬了家。
- 舊瓶頸：「這東西寫得出來嗎？」——實作能力是稀缺資源。
- 新瓶頸：「你知道你要什麼嗎？」＋「你驗得出它對不對嗎？」——意圖的清晰度與驗證能力，成了新的稀缺資源。
為什麼會這樣？因為 AI 產出快。你餵它一個模糊的意圖，它不會停下來問你到底要什麼——它會照著它猜的方向，快速產出一座自信但錯的山。
產能不再是限制。於是天花板換人當：你有沒有能力指定正確的方向、有沒有能力判斷它交回來的東西對不對，直接變成整件事的上限。
而這裡有一個惡性的乘數：產出越快、越廉價，模糊意圖的代價就被放得越大——因為錯誤也被同樣廉價、同樣快速地大量生產。
瓶頸從「手」，移到了「腦」與「眼」：定義（你要什麼）與驗證（它做對了沒）。
三、新形狀：明確意圖 × 緊回饋迴路
把兩個斷點合起來看，AI 協作真正獎勵的形狀就浮出來了。它同時要兩種美德——而這兩種美德，剛好分別來自瀑布與敏捷：
| 美德 | 出身 | 在 AI 協作裡對應什麼 |
|---|---|---|
| 明確的意圖 | 瀑布 | 先把「要什麼」想清楚、寫下來，AI 才有方向可以跟 |
| 緊的回饋迴路 | 敏捷 | 短週期驗證產出對不對，別讓錯誤的山越堆越高 |
而兩種純粹版，各自會死在自己缺的那一半：
純瀑布 → 死在「回饋太晚」。 就算意圖寫得再清楚，等到最後才驗，一座自信但錯的山已經堆完了。而且 AI 堆山的速度比人快得多——這意味著「回饋太晚」這個瀑布的老毛病，在 AI 協作裡不是變輕，是變重。
純敏捷（cowboy 版）→ 死在「意圖從沒被寫下來」。 只顧快速迭代、擁抱變更，卻從沒把「到底要什麼」固定成一份可對照的東西。AI 拿著模糊指令，會一路自信地跑偏，而每一輪迭代都在把偏差當成既成事實往下疊。
所以正解不是二選一，而是取兩者的美德、去兩者的死穴：用瀑布式的明確意圖給方向，用敏捷式的緊回饋迴路防跑偏。
這裡要接上我上一篇的結論，因為它們其實是同一件事的兩個切面。上一篇我講的是：投資輸入（把 context 給對）跟驗證輸出，是對稱互補、不是兩條可以各自採納的建議——因為輸入端的失敗長相是「不在場」，而不在場不會報錯，你只能從輸出端測到它。
換到方法論這一層，同一組關係換了名字：
明確的意圖，就是投資輸入。緊的回饋迴路，就是驗證輸出。它們不是兩個可以各挑一個的選項，是同一個迴路的兩端。
少了任何一端，你拿到的都不是「半套的好」，而是一個你以為在運轉、其實沒有讀數的系統。
四、對 Agile Manifesto 的重讀：一句在今天變危險的建議
順著上面這條線走下去，會撞到一句大家都會背的話。
Agile Manifesto 那句名言——"working software over comprehensive documentation"（可運作的軟體，重於詳盡的文件）——對 AI 協作來說，我認為已經變成一句危險建議。
當年這句話是對的。它針對的痛點很具體，有兩個：
- 文件寫了沒人看；
- 維護文件太貴——人力手動維護，需求一改就過時。
在那個成本結構下，「別花力氣在文件上，把力氣放在能跑的軟體上」是理性的資源配置。
但 AI 把這兩個前提都拆了：
第一，AI 恰恰需要那份文件才有方向。 這裡指的不是操作手冊式的 documentation，而是 documentation-of-intent（意圖的文件）——你要什麼、為什麼要、什麼算對。這正是第二節那個新瓶頸要的東西。對人類團隊來說，文件是溝通的輔助；對 AI 協作來說，這份文件不是可省的成本，它是方向盤本身。
第二，「維護文件太貴」這個當年的反對理由，被 AI 自己消掉了。 過去文件會過時，是因為維護靠人、很貴；現在 AI 自己就能廉價地維護這份意圖文件。那條「別寫文件、反正會過時」的理由，地基跟第一節那條一樣，蒸發了。
於是同一句 Manifesto，換到新的成本結構下，就從智慧變成了陷阱：它叫你別做的那件事（把意圖詳盡寫下並維護），正好是 AI 協作最需要、而且現在最便宜的一件事。
這裡我要替 Manifesto 說一句公道話，不然我就是在稻草人。原文寫的是 over，不是 instead of——它自己在下面明講了：右邊那些項目仍然有價值。真正被誤讀成「不用寫文件」的，是後來的實踐者，不是那份宣言。而順帶一提，瀑布模型也有同樣的命運——Royce 1970 年那篇被當成瀑布起源的論文，本身就在警告單次通過、不迭代的做法會出事。兩邊的原典都比它們的信徒溫和。
所以我不是在叫你回去寫百頁 SRS。我要的是意圖文件，不是規格官僚。這兩者的差別不在厚度，在於它回答的是「要什麼、為什麼、什麼算對」，還是「按鈕放左邊還右邊」。
就地交代我自己怎麼做的，並標好證據等級：我自己的 AI 協作系統走的是規格驅動——先有條文化的規格當權威，再有可執行的操作去落地，每個階段設一道 Gate，過了才放行。這條紀律在我的系統裡跑了幾個月，它確實把「AI 自信地跑偏」擋掉了不少。但這是自證：我自己的系統、我自己的判斷，沒有對照組，也沒有公開發表。你可以不信——這篇的論證不靠它成立，它只是一個實例。
五、代價
我不打算給你一份沒有帳單的建議。上面每一條主張都要付錢，以下是六筆。
| 主張 | 它會怎麼壞 |
|---|---|
| 重寫變便宜了 | 便宜的是打字，不是理解。 重寫的真成本已經移到了 review、遷移、以及「你根本沒發現它重寫錯了」。把「產出便宜」直接當成「改變便宜」，是這整條推論裡最容易犯的錯 |
| 先把意圖寫清楚 | 對探索性任務，過早精確化會扼殺發散——在你還不知道要找什麼的時候先鎖死範圍。這時候模糊是功能，不是缺陷 |
| 意圖文件由 AI 廉價維護 | 廉價維護出來的文件，也可能廉價地錯。而且一份沒有人真的拿去對照的意圖文件，就是新的裝飾——寫下了 ≠ 被讀了 ≠ 起了作用 |
| 緊的回饋迴路 | 迴路要有人點火，而人會累。防線真正的死法不是被推翻，是被略過；一個從來只吐「通過」的驗證，跟沒有驗證不可分 |
| documentation-of-intent | 最容易長成規格官僚。 你會先加一份意圖模板，再加一道意圖審查，再加一個意圖版本規範——然後你就重新發明了 1998 年 |
| 這篇文章本身 | 如果你讀完決定導入一套「意圖文件治理制度」，你就親手示範了它要防的病。修過度工程的藥，不得變成新的過度工程。 本文所有建議的力度上限是「一句自問，追不到就停」 |
最後一列不是自謙，是必要條件。一篇說「別把方法論當信仰」的文章，如果它自己催生了一套新儀式，那它就推翻了自己。
六、所以什麼時候偏瀑布側、什麼時候偏敏捷側
到這裡該給的不是答案，是切換的判準。這兩側都不是永遠該開滿的。
| 情境 | 該偏哪一側 | 為什麼 |
|---|---|---|
| 目標本身就是發散、你還在找問題 | 意圖側關小 | 過早精確化會殺掉探索。此時把方向寫死，你只是把猜測升格成規格 |
| 一次性、風險低、可逆的小事 | 兩邊都免 | 花力氣準備的收穫小於成本。硬上全套只會變成儀式，還把人搞累 |
| 多階段、跨 session、要交給 AI 自己跑一段 | 意圖側開滿 | 這是 AI 唯一能拿到的方向盤。這裡省下的每一分鐘，都會在下游變成一座自信但錯的山 |
| 產出會進到別人手上，或會被拿去做決定 | 回饋側必開 | 這裡的錯誤不由你承擔，你沒有資格用「我看起來沒問題」結案 |
| 不可逆、碰錢、對外發布 | 回饋側必開，而且最後一關要是人 | 換一個 AI 來審，消不掉它們天生一樣的盲點。這種事情上多一層不叫過度工程 |
| 你發現自己連續三輪驗證都判「通過」 | 停下來檢查迴路本身 | 一個從來沒說過一次「這個方向錯了」的回饋迴路，跟沒有迴路一樣。此刻該懷疑的是機制，不是產出 |
| 你發現自己在為「文件格式」開會 | 兩側都關，先停 | 意圖文件的價值在於被對照，不在於被規範。開始管格式，就是官僚化的第一個症狀 |
結論：問題換了一題
舊問題是這樣問的：
我該選敏捷還是瀑布？
這題現在問錯了。錯在它預設了兩者的取捨是永恆的——但那個取捨從來只是一個成本結構的投影，而成本結構已經被換掉了。
該問的是這兩題，順序不能倒：
我要什麼，寫下來了嗎？
如果我要錯了，我會在哪裡、隔多久發現？
第一題是瀑布留給我們的美德，第二題是敏捷留給我們的。AI 沒有讓我們在兩者之間選邊——它讓我們必須同時要兩邊，因為它同時放大了兩邊的死穴。
立即可做的 3 件事
每一件都要在今天做完，而且必須產出一個讀數。沒有讀數的不算。
-
翻出你手上正在跑的那個任務，找出「意圖」寫在哪裡。 不是找需求單，是找「什麼算對」。找不到，讀數就是零——那你這幾天餵給 AI 的，全部是你腦子裡的東西，而它讀不到你的腦子。
-
量一次你的回饋間隔。 從「AI 產出」到「有人真的判斷它對不對」，中間隔了多久、隔了幾輪？讀數＝那個間隔。 如果答案是「等它全部做完再看」，那你正在跑純瀑布，只是跑得比較快。
-
找一份你最近讓 AI 維護過的文件，跟現況對一次。 廉價維護是這篇的核心前提之一，讀數＝對不上的地方有幾處。對不上，代表你的方向盤是鬆的，而你一直以為它是緊的。
長期培養的習慣
-
把「什麼算對」寫在動工之前。 不用長，一句也行——但它必須在你開始產出之前就存在，不然它只會變成事後追認。
-
每寫下一條意圖，順手登記一句「它若被違反，我會在哪裡發現？」 答不出來的那一條，此刻就是裝飾。這句話比任何治理制度都短。
-
每半年回頭問一次：我現在守的這條方法論紀律，它的成本假設還成立嗎？ 敏捷贏瀑布的那條理由撐了二十年才失效。你手上一定還有別的紀律，正靠著一個已經消失的前提在運轉。
查證與證據等級
本文的主張分三類，這裡分開交代。
外部事實（可公開查核）
- Agile Manifesto 原文——注意它寫的是 "over" 而非 "instead of"，且明文保留右側項目的價值
- Agile Manifesto 十二原則
- Waterfall model（維基百科）——記載 Royce 1970 年論文本身即在警告單次通過、不迭代的做法
論證（不靠數據，靠推理鏈）
第一節到第四節的主體是一條推論鏈：敏捷的優勢建立在「改的成本高」→ AI 從兩處抽掉這個前提 → 因此獎勵的形狀改變。這條鏈可以被純邏輯推翻，不需要任何實測。 最脆弱的一環是「重寫變便宜」——如果你認為重寫的成本從來就不在打字上，那第一個斷點的力道會大幅減弱（我在代價表第一列自己標了這一點）。
自證主張（n=1，不可復現）
第四節提到的「規格驅動 + 階段 Gate」是我自有系統的實踐，有版本紀錄可回溯，但未公開發表、無獨立驗證、無對照組。它的作用是提供一個實例，不是提供證據。
明示不主張
本文不主張瀑布回歸，不主張「規格驅動開發」是我提出的概念，也不主張本文提出的形狀適用於沒有 AI 參與的團隊協作。
如果這篇讓你想去翻一次「我到底把意圖寫在哪裡」，歡迎訂閱我的 Newsletter。每週一篇，我會把自己系統裡量到的東西——包含那些量出來很難看的——寫給你看。
特色圖片：Photo by cottonbro studio on Pexels
