Vibe Coding 會讓你迷失：一個30年老工程師的 Spec-driven 轉型實錄
整理版優先睇
從Vibe Coding迷失到Spec-driven重掌主導：用規格說明書取代隨機生成，重建項目心智模型
Simon Martinelli係一位喺瑞士做咗30年嘅軟件工程師，2024年佢幫朋友整一個志願者管理系統，一開始用Vibe Coding——不斷同AI對話、等佢生成代碼。幾個月後系統大致行到，但Simon發現自己完全唔知自己做咗啲乜，陷入咗『失去項目心智模型』嘅困境：AI冇項目記憶，開發者冇辦法維護上下文。
2024年聖誕前後，Simon接觸到Spec-driven Development，核心係『先寫規格說明書，再生成代碼』。佢揀咗系統用例作為規格載體，因為用例天然包含主流程、替代流程、錯誤流程等完整上下文。實戰中佢用Claude Code配合三類工具：Skills（封裝上下文）、MCP服務器（存取外部資訊）、Guidelines（項目規範）。測試分兩層：系統用例測試同工作流測試，並用@UseCase註解對抗規格漂移。
Simon指出Spec-driven Development唔係放棄控制，而係用規格建立可檢查嘅期望，開發者始終要為AI生成嘅一切負責。呢套方法帶嚟結構性變化：需求工程師嘅產出直接驅動代碼生成，開發者變成規格執行者同質量守門人。對於企業級業務應用，Spec-driven提供咗一個可重複嘅框架，取代Vibe Coding嘅隨機性。
- 結論：Vibe Coding會令你失去對項目嘅掌控，因為AI冇項目記憶；Spec-driven Development以規格說明書為核心，重建心智模型。
- 方法：先寫系統用例（包含主流程、替代流程、錯誤流程等），再生成代碼；用例係唯一真相來源，修改規格而非直接改代碼。
- 差異：Spec-driven唔係20年前嘅模型驅動開發，AI非確定性，同一份規格可生成不同代碼，只要通過測試就算合格；開發者角色從寫代碼轉為定義規格同驗證。
- 啟發：工具三件套（Skills、MCP、Guidelines）可以封裝項目上下文，確保AI輸出一致；測試兩層體系（用例測試+工作流測試）配@UseCase註解防止規格漂移。
- 可行動點：如果你嘅項目引入AI後掌控感下降，可以試下Spec-driven：先用用例反向工程現有系統，再逐步過渡到以規格為主導；注意架構上選擇自包含系統或模塊化單體，減少上下文負擔。
Spring I/O 2026 Simon Martinelli 演講
Spec-driven Development 轉型實錄
迷失嘅開始：Vibe Coding點樣令我完全唔知自己做緊乜
Simon Martinelli，一位喺瑞士做咗30年嘅軟件工程師，2024年幫運動俱樂部朋友整志願者管理系統。佢用咗當時最流行嘅 Vibe Coding 模式——不斷同AI對話、等佢生成代碼，然後話『行，繼續』。
幾個月後系統大致行到，但Simon發現自己陷入咗一種奇怪嘅困境：佢完全唔知自己做咗啲乜。加新功能？唔知功能係咪已經存在。修bug？揾唔到代碼位置。重構？唔知會影響啲乜。代碼越多，掌控感越少。
Simon形容呢種感覺：『我企喺一堆我唔太理解嘅代碼前，無法自信咁講清楚佢哋做緊乜。』呢個正正係Vibe Coding嘅限制。
轉向Spec-driven：先寫規格，再生成代碼
2024年聖誕前後，Simon喺ainativedev.io見到一個概念：Spec-driven Development（規格驅動開發）。三個支柱：Spec-centric（規格係核心）、Context-aware（AI必須知你真正想構建乜）、Agent experience（工具要好用）。
核心思想得一句：『先寫規格說明書，再生成代碼。規格係唯一真相來源，唔係代碼。』Simon指出呢個唔係20年前嘅模型驅動開發——AI係非確定性，同一份規格每次可能生成結構唔同嘅代碼，但只要通過測試、實現規格，就係合格輸出。
真正嘅區別在於：我哋唔修改代碼來修復問題，我哋修改規格說明書。如果代碼唔符合預期，先問：規格係咪寫清楚咗？
- 1 主流程（Main Flow）：正常情況下系統點樣運作
- 2 替代流程（Alternative Flows）：正常以外嘅變體
- 3 錯誤流程（Error Flows）：出錯時嘅處理
- 4 前置條件（Preconditions）：用例開始前必須滿足嘅條件
- 5 後置條件（Postconditions）：用例完成後保證嘅狀態
- 6 業務規則（Business Rules）：業務上嘅限制同邏輯
實戰工具：Skills、MCP、Guidelines
Simon主要用 Claude Code，並搭建咗三類輔助工具來實踐Spec-driven Development。
- Skills：封裝項目特定嘅上下文，避免每次要重複解釋背景
- MCP服務器：Model Context Protocol，讓AI實時存取外部資訊，例如Javadoc、Vaadin組件用法、Figma設計稿
- Guidelines：項目架構規範、測試規範，以純文字形式放喺項目入面，AI生成代碼前會讀取確保符合團隊約定
測試方面有兩層體系：系統用例測試（白盒）由開發者負責，AI同時生成規格同實現；工作流測試（黑盒）用Playwright寫端到端測試，係用戶眼中嘅真相。Simon仲加咗 @UseCase 註解，標記每個測試方法對應嘅用例ID同業務規則，配合IntelliJ插件可以從業務規則直接導航到測試，再導航到實現。呢個係對抗規格漂移嘅實踐。
架構建議同結構性變化
為咗控制AI嘅上下文窗口，Simon推薦使用 自包含系統（Self-Contained System）——UI、業務邏輯、數據庫喺同一個垂直切片入面，最小化跨系統依賴。 全棧框架更友好，因為只需要為一個生態寫skill同guideline；如果前後端分離，工作量會翻倍。微服務要小心，模塊化單體通常係更好嘅起點。
最重要嘅一句話：『你對AI生成嘅一切內容負責。沒有任何情況下係AI負責嘅。』 Spec-driven Development唔係解放雙手，而係用規格建立可檢查嘅期望，用測試驗證輸出。
Simon喺政府項目入面一週只工作一日（作為唯一開發者），對方配備兩個全職需求工程師。呢個比例喺傳統開發荒謬，但Spec-driven模式下合理：需求工程師嘅產出（用例）直接驅動代碼生成。『寫代碼』嘅稀缺性降低，『定義清楚要做乜』嘅能力升值。軟件行業分工正發生結構性變化。
Simon Martinelli 喺 Spring I/O 2026 嘅演講台上講咗一句令我印象深刻嘅話：
❝「我已經超過一年冇親手寫過 code 㗎喇。」
❞
呢句唔係一個程序員嘅自我放棄宣言，而係一個轉型宣言。
佢係一位喺瑞士做咗30年軟件工程師嘅人，做過保險公司、政府、批發零售嘅系統。2024年，一個運動會所嘅朋友揾到佢：
「Simon，你係軟件工程師，我聽講 AI 好犀利，你一定可以幫我哋整一個義工管理系統。」
佢開始咗——用最流行嘅方式：「vibe coding」。
大家知唔知 vibe coding 係咩？就係你不斷同 AI 傾偈、佢不斷生成 code、你不斷話「得，繼續」嗰種模式。
幾個月後，系統大體上行得鬱。但 Simon 發現自己陷入咗一個奇怪嘅困境：「佢完全唔知自己做咗啲乜」。
想加新功能？唔知嗰個功能係咪已經存在。想修一個 bug？唔知 code 喺邊度。想重構一嚿邏輯？唔知佢影響咗啲乜。
Code 越嚟越多，但掌控感越嚟越少。
呢種感覺，有幾多人經歷過？
Vibe Coding 嘅本質困境
Vibe coding 嘅問題唔係生成嘅 code 質素差，而係「你冇咗個項目嘅心智模型」。
傳統開發入面，就算你寫得好慢，每一行 code 都經過你個腦，你知道成個系統嘅結構、每個模組嘅職責、每個決策背後嘅理由。
但 vibe coding 係跳過個腦嘅——你描述目標，AI 生成實現，你驗證結果，然後繼續下一個目標。當項目細嘅時候，呢個冇問題。但當項目變大，你會發現自己企喺一堆你「唔太明」嘅 code 面前，冇信心清楚講得出佢做緊啲乜。
呢個正正係模型嘅侷限：「AI 冇項目記憶，每次對話都係新開始」。你嘅項目上下文必須由你嚟維護，但 vibe coding 嘅模式冇留低空間畀呢個維護動作。
轉捩點：Spec-driven Development
2024年聖誕節前後，Simon 喺 ainativedev.io 上見到一個叫 「Spec-driven Development（規格驅動開發）」 嘅概念。
三個支柱：
「Spec-centric」：規格說明書係核心，唔係 code 「Context-aware」：AI agent 一定要知道你真正想構建啲乜 「Agent experience」：工具應該好用，而唔係要開發者不斷手動幹預
核心思想只有一句話：「先寫規格說明書，再生成 code。規格係唯一嘅真相來源，而唔係 code。」
聽落有啲耳熟？有人可能會諗起20幾年前嘅「模型驅動開發（Model-Driven Development）」。Simon 喺演講入面都有主動提到呢個對比：
嗰時有工具叫 Open Architecture Ware，你畫 UML 模型，工具生成 code，從模型可以重複生成一模一樣嘅 code。
Spec-driven 唔係呢樣嘢。
「AI 係非確定性嘅。」 畀同一份規格，佢每次可能生成結構有少少唔同嘅 code。呢個唔係 bug，同畀兩個唔同開發者同一個需求——佢哋會寫出唔同嘅實現——係同一道理。只要 code 通過咗測試、實現咗規格，就係合格嘅輸出。
真正嘅分別在於：「我哋唔修改 code 嚟修復問題，我哋修改規格說明書」。如果 code 唔符合預期，先問：規格係咪寫清楚咗？
呢個原則睇落簡單，但佢重新定義咗開發者嘅角色。
用例（Use Case）作為規格載體
Simon 揀咗一個好舊嘅工具嚟做規格：「系統用例（System Use Case）」。
呢個係 Ivar Jacobson 佢哋喺1992年做 UML 時提出嘅概念——今年計起嚟已經34年。Simon 嗰時先20歲，仲未入行。
點解揀咁「舊」嘅嘢？
因為用例天然係一種「高密度上下文」嘅載體。
一個完整嘅用例包含：
主流程（Main Flow） 替代流程（Alternative Flows） 錯誤流程（Error Flows） 前置條件（Preconditions） 後置條件（Postconditions） 業務規則（Business Rules）
呢啲資訊組合埋一齊，就係 AI agent 需要嘅完整上下文。你唔使反覆解釋背景，亦唔使擔心 AI 理解有偏差——規格入面寫清楚曬。
更加重要嘅係：「業務方能睇得明用例」。
你可以將用例文檔畀產品、畀業務、畀最終用戶睇，佢哋明白入面寫咗啲乜，可以驗證係咪符合佢哋嘅期望。呢樣係 code 做唔到嘅。
兩種工作流：綠地 vs 棕地
「綠地項目（Greenfield）」：由零開始。需求工程師同業務用戶合作，先做實體模型（Entity Model），再寫用例。用例經過 AI review 之後，生成測試同 code。
「棕地項目（Brownfield）」：呢個先係大多數企業嘅現實。
Simon 同時做緊兩個現代化改造項目——一個政府系統，一個瑞士最大批發公司嘅 ERP。棕地工作流係：「將現有 code、文檔、Jira、Confluence 餵畀 AI，等 AI 反向工程出用例」。然後人工審核呢啲用例——唔單止驗證佢哋係咪準確描述咗現有系統，仲要判斷現有系統做得啱唔啱。
一個有趣嘅發現：當佢哋完成規格化之後，發現可以隨便加新功能。因為「從規格生成 code」呢個動作係中性嘅，唔區分係新功能定舊功能。
呢個為現代化項目帶嚟咗意外驚喜：「最終用戶等咗多年嘅新功能，可以順便實現埋」。呢個令本來好難推動嘅現代化項目得到用戶方面嘅支持。
工具層：Skills、MCP、Guidelines
實踐 Spec-driven Development 需要配套工具。Simon 主要用 Claude Code，並搭建咗三類輔助：
「Skills（技能/插件）」
類似宏命令。例如佢只需要輸入 /implement 002，就會觸發一個預先寫好嘅 skill，呢個 skill 包含完整嘅實現指令：用咩框架、跟咩架構、測試點寫。
唔同項目有唔同嘅 skill 集合：用 Vaadin 嘅項目有 Vaadin 相關嘅 skill，用 React + .NET 嘅項目有對應嘅 skill。「技能係上下文嘅封裝」，令每個項目成員用相同嘅提示詞，避免結果唔一致。
「MCP 伺服器」
Model Context Protocol，等 AI 可以即時存取外部資訊源。例如：
Javadoc MCP（James Ward 做嘅），AI 直接查文檔 Vaadin MCP，AI 瞭解組件用法 Figma MCP，AI 直接讀設計稿，唔需要截圖或者匯出
「Guidelines（規範文件）」
項目架構規範、測試規範，以純文字形式放喺項目入面。AI 喺生成 code 前會讀呢啲規範，確保輸出符合團隊約定。例如「按功能分包」、「用 browserless 測試 Vaadin 組件」等。
測試：兩層體系
Spec-driven 開發有一套對應嘅測試策略：
「系統用例測試（白盒）」：每個用例對應一個測試類，測試名稱同用例名稱一樣。呢個係開發者負責嘅，AI 喺生成 code 時同時生成，因為佢睇到規格同實現。
「工作流測試 / 驗收測試（黑盒）」：用 Playwright 寫端到端測試，呢個先係「用戶眼中嘅真相」。呢部分通常由測試工程師負責，用工作流規格嚟驅動。
Simon 仲做咗一件小事：喺測試入面加咗一個 @UseCase 註解，用嚟標記每個測試方法對應邊個用例 ID 同業務規則。配合 IntelliJ 插件，可以從業務規則直接導航到測試、再導航到實現。
呢個係一種對抗**規格漂移（Spec Drift）**嘅做法：code 可能會慢慢偏離規格，測試可能會慢慢偏離 code，註解提供咗一個可以檢查嘅對應關係。
架構建議
如果你想用 AI 做開發，架構選擇會影響效率：
「控制上下文視窗」：AI 唔係處理唔到大系統，而係上下文越大，效率越低、出錯率越高。Simon 推薦「自包含系統（Self-Contained System）」：UI、業務邏輯、數據庫喺同一個垂直切片入面，減到最少跨系統依賴。
「全棧框架更友好」：如果只用一種技術棧（例如 Vaadin / Thymeleaf 做伺服器端，或者 React 全棧），你只需要為一個生態寫 skill 同 guideline。如果前後端分離（好似瑞士政府偏好嘅 Angular + Spring Boot），即係兩套 skill、兩套 MCP、兩套規範，工作量翻倍。
「微服務要小心」：如果一個用例跨越幾個微服務，AI 需要睇得曬所有相關嘅 code。一係用 mono repo，一係有完善嘅 OpenAPI 文檔。模組化單體（Modular Monolith）通常係更好嘅起點。
最重要嘅一句話
Simon 喺演講就嚟完嗰時講咗一句話，我認為係成場最重要嘅：
❝「你對 AI 生成嘅一切內容負責。冇任何情況下係 AI 負責嘅。」
❞
Spec-driven Development 唔係令你放開雙手、交出控制權嘅方法。而係用規格建立可以檢查嘅期望，用測試驗證輸出，用你嘅架構知識同領域知識確保方向正確。
佢舉咗一個例子：佢熟 Vaadin 好多年，所以一眼睇 AI 生成嘅 code 就知啱唔啱。但佢做 React 項目時，見到 AI 生成嘅 code 一頭霧水——「行得鬱，但我唔知發生咗咩事」。呢個先係危險嘅地方。
「AI 唔能夠取代你對技術棧嘅理解，亦唔能夠取代你對業務領域嘅理解。」 佢只係將呢兩種理解嘅實現成本大幅降低咗。
正在發生嘅結構性變化
Simon 提到咗一個數字，令我印象深刻：
喺政府項目入面，佢一星期只做一日（作為唯一嘅開發者），而對方配備咗「兩個全職需求工程師」。
呢個比例，放喺傳統軟件開發語境入面係荒謬嘅。
但喺 Spec-driven 模式下係合理嘅：需求工程師嘅產出（用例）直接驅動 code 生成，佢哋嘅工作效率直接決定項目推進速度。開發者變成咗規格嘅執行者同質素守門人，而唔係主要嘅生產力輸出者。
軟件行業嘅分工正在發生結構性變化。「寫 code」呢個能力嘅稀缺性喺度降低，「定義清楚要做啲乜」嘅能力喺度升值。
Simon 將呢套流程改咗個名：「AI Unified Process（AI 統一過程）」，有啲致敬 Rational Unified Process 嘅意思——但佢話自己嘅版本更精簡。
總結
Spec-driven Development 唔係銀彈，Simon 自己都話，對於複雜嘅業務邏輯，測試驅動開發依然更合適。
但對於企業級業務應用——大量嘅 CRUD、業務流程、主數據管理——呢套方法提供咗一個結構化框架，令 AI 輔助開發由「靠運氣」變成「可重複」。
核心要點：
「Vibe coding 會令你失去掌控」；規格說明書係掌控嘅根基 「用例係一種被低估嘅規格格式」；佢密度高、可理解、可驗證 「Skills + MCP + Guidelines 係工具三件套」；令 AI 嘅輸出符合你嘅項目上下文 「你始終負責」；AI 生成嘅 code，你一定要能夠理解、能夠驗證
最後，留一個問題畀你：
你而家做緊嘅項目，有幾多比例嘅 code，你可以有信心話「我知佢做緊乜，點解要咁做」？
如果呢個比例因為引入 AI 而下降，可能係時候考慮 Spec-driven Development 喇。
❝原文連結：https://www.youtube.com/watch?v=35dH6q18UtI
❞
Simon Martinelli 在 Spring I/O 2026 的演講台上說了一句讓我記住的話：
❝"我已經超過一年沒有親手寫代碼了。"
❞
這不是一個程序員的自我放棄聲明，而是一個轉型宣言。
他是一位在瑞士工作了30年的軟件工程師，做過保險公司、政府、批發零售的系統。2024年，一個運動俱樂部的朋友找到他：
"Simon，你是軟件工程師，我聽說 AI 很厲害，你肯定能幫我們做一個志願者管理系統。"
他開始了——用最流行的方式：「vibe coding」。
大家知道 vibe coding 是什麼嗎？就是那種你不斷地跟 AI 對話、它不斷生成代碼、你不斷說"行，繼續"的模式。
幾個月後，系統大致能跑了。但 Simon 發現自己陷入了一種奇怪的困境：「他完全不知道自己做了什麼」。
想加新功能？不知道那個功能是否已經存在。想修一個 bug？不知道代碼在哪裏。想重構一塊邏輯？不知道它影響了什麼。
代碼越來越多，但掌控感越來越少。
這個感受，有多少人經歷過？
Vibe Coding 的本質困境
Vibe coding 的問題不是生成的代碼質量差，而是「你失去了項目的心智模型」。
傳統開發中，即使你寫得很慢，每一行代碼都經過你的大腦，你知道整個系統的結構、每個模塊的職責、每個決策背後的理由。
但 vibe coding 是跳過大腦的——你描述目標，AI 生成實現，你驗證結果，然後繼續下一個目標。當項目小的時候，這沒問題。但當項目變大，你會發現自己站在一堆你"不太理解"的代碼前，無法自信地說清楚它在做什麼。
這正是模型的侷限：「AI 沒有項目記憶，每次對話都是新的開始」。你的項目上下文必須由你來維護，但 vibe coding 的模式沒有給這個維護動作留下空間。
轉折：Spec-driven Development
2024年聖誕節前後，Simon 在 ainativedev.io 上看到了一個叫 「Spec-driven Development（規格驅動開發）」 的概念。
三個支柱：
「Spec-centric」：規格說明書是核心，不是代碼 「Context-aware」：AI agent 必須知道你真正想構建什麼 「Agent experience」：工具應該好用，而不是讓開發者不斷手動干預
核心思想只有一句話：「先寫規格說明書，再生成代碼。規格是唯一的真相來源，而不是代碼。」
聽起來有點耳熟？有人可能會想到20多年前的「模型驅動開發（Model-Driven Development）」。Simon 在演講裏也主動提到了這個對比：
那時候有工具叫 Open Architecture Ware，你畫 UML 模型，工具生成代碼，從模型可以重複生成完全相同的代碼。
Spec-driven 不是這個。
「AI 是非確定性的。」 給同一份規格，它每次可能生成結構略有不同的代碼。這不是 bug，這和給兩個不同的開發者同一個需求——他們會寫出不同的實現——是一樣的道理。只要代碼通過了測試、實現了規格，就是合格的輸出。
真正的區別在於：「我們不修改代碼來修復問題，我們修改規格說明書」。如果代碼不符合預期，先問：規格是否寫清楚了？
這個原則看似簡單，但它重新定義了開發者的角色。
用例（Use Case）作為規格載體
Simon 選擇了一個很老的工具來做規格：「系統用例（System Use Case）」。
這是 Ivar Jacobson 他們在1992年做 UML 時提出的概念——今年算起來已經34年了。Simon 當時才20歲，還沒入行。
為什麼選這麼"老"的東西？
因為用例天然是一種「高密度上下文」的載體。
一個完整的用例包含：
主流程（Main Flow） 替代流程（Alternative Flows） 錯誤流程（Error Flows） 前置條件（Preconditions） 後置條件（Postconditions） 業務規則（Business Rules）
這些信息組合在一起，就是 AI agent 需要的完整上下文。你不需要反覆解釋背景，也不需要擔心 AI 理解偏差——規格里寫清楚了。
更重要的是：「業務方能看懂用例」。
你可以把用例文檔給產品、給業務、給最終用戶看，他們能理解裏面寫的是什麼，能驗證它是否符合他們的期望。這是代碼做不到的。
兩種工作流：綠地 vs 棕地
「綠地項目（Greenfield）」：從零開始。需求工程師和業務用戶合作，先做實體模型（Entity Model），再寫用例。用例經過 AI review 後，生成測試和代碼。
「棕地項目（Brownfield）」：這才是大多數企業的現實。
Simon 同時在做兩個現代化改造項目——一個政府系統，一個瑞士最大批發公司的 ERP。棕地工作流是：「把現有代碼、文檔、Jira、Confluence 餵給 AI，讓 AI 反向工程出用例」。然後人工審核這些用例——不只是驗證它們是否準確描述了現有系統，還要判斷現有系統做得對不對。
一個有意思的發現：當他們完成規格化之後，發現可以隨意添加新功能了。因為"從規格生成代碼"這個動作是中性的，不區分新功能還是舊功能。
這給現代化項目帶來了意外之喜：「最終用戶等了多年的新功能，可以順便實現了」。這讓本來很難推進的現代化項目獲得了用戶側的支持。
工具層：Skills、MCP、Guidelines
實踐 Spec-driven Development 需要配套工具。Simon 主要用 Claude Code，並搭建了三類輔助：
「Skills（技能/插件）」
類似宏命令。比如他只需要輸入 /implement 002，就會觸發一個預先寫好的 skill，這個 skill 包含了完整的實現指令：用什麼框架、遵循什麼架構、測試怎麼寫。
不同項目有不同的 skill 集合：用 Vaadin 的項目有 Vaadin 相關的 skill，用 React + .NET 的項目有對應的 skill。「技能是上下文的封裝」，讓每個項目成員使用同樣的提示詞，避免結果不一致。
「MCP 服務器」
Model Context Protocol，讓 AI 能實時訪問外部信息源。比如：
Javadoc MCP（James Ward 做的），AI 直接查文檔 Vaadin MCP，AI 瞭解組件用法 Figma MCP，AI 直接讀設計稿，不需要截圖或導出
「Guidelines（規範文件）」
項目架構規範、測試規範，以純文本形式放在項目裏。AI 在生成代碼前會讀取這些規範，確保輸出符合團隊約定。比如"按功能分包"、"用 browserless 測試 Vaadin 組件"等。
測試：兩層體系
Spec-driven 開發有一套對應的測試策略：
「系統用例測試（白盒）」：每個用例對應一個測試類，測試名稱與用例名稱相同。這是開發者負責的，AI 在生成代碼時同時生成，因為它既看到了規格，也看到了實現。
「工作流測試 / 驗收測試（黑盒）」：用 Playwright 寫端到端測試，這才是"用戶眼中的真相"。這部分通常由測試工程師負責，用工作流規格來驅動。
Simon 還做了一件小事：在測試里加了一個 @UseCase 註解，用來標記每個測試方法對應哪個用例 ID 和業務規則。搭配 IntelliJ 插件，可以從業務規則直接導航到測試、再導航到實現。
這是一種對抗**規格漂移（Spec Drift）**的實踐：代碼可能慢慢偏離規格，測試可能慢慢偏離代碼，註解提供了一個可檢查的映射關係。
架構建議
如果你想用 AI 做開發，架構選型會影響效率：
「控制上下文窗口」：AI 不是不能處理大型系統，而是上下文越大，效率越低、出錯率越高。Simon 推薦「自包含系統（Self-Contained System）」：UI、業務邏輯、數據庫在同一個垂直切片裏，最小化跨系統依賴。
「全棧框架更友好」：如果只用一種技術棧（比如 Vaadin / Thymeleaf 做服務端，或者 React 全棧），你只需要為一個生態寫 skill 和 guideline。如果前後端分離（比如瑞士政府偏好的 Angular + Spring Boot），意味着兩套 skill、兩套 MCP、兩套規範，工作量翻倍。
「微服務要小心」：如果一個用例跨越多個微服務，AI 需要能看到所有相關代碼。要麼用 mono repo，要麼有完善的 OpenAPI 文檔。模塊化單體（Modular Monolith）通常是更好的起點。
最重要的一句話
Simon 演講快結束時說了一句話，我認為是整場最重要的：
❝「"你對 AI 生成的一切內容負責。沒有任何情況下是 AI 負責的。"」
❞
Spec-driven Development 不是讓你解放雙手、交出控制權的方法。而是用規格建立可檢查的期望，用測試驗證輸出，用你的架構知識和領域知識確保方向正確。
他舉了一個例子：他熟悉 Vaadin 多年，所以掃一眼 AI 生成的代碼就知道對不對。但他在做 React 項目時，看到 AI 生成的代碼一頭霧水——"能跑，但我不知道發生了什麼"。這才是危險的地方。
「AI 不能替代你對技術棧的理解，也不能替代你對業務領域的理解。」 它只是把這兩種理解的實現成本大幅降低了。
正在發生的結構性變化
Simon 提到了一個數字，讓我印象深刻：
在政府項目裏，他一週只工作一天（作為唯一的開發者），而對方配備了「兩個全職需求工程師」。
這個比例，放在傳統軟件開發語境裏是荒謬的。
但在 Spec-driven 模式下是合理的：需求工程師的產出（用例）直接驅動代碼生成，他們的工作效率直接決定了項目推進速度。開發者成了規格的執行者和質量守門人，而不是主要的生產力輸出者。
軟件行業的分工正在發生結構性變化。「"寫代碼"這個能力的稀缺性在降低，"定義清楚要做什麼"的能力在升值。」
Simon 給這套流程取了個名字：「AI Unified Process（AI 統一過程）」，有點致敬 Rational Unified Process 的意思——但他說自己的版本更精簡。
總結
Spec-driven Development 不是銀彈，Simon 自己也說，對於複雜的業務邏輯，測試驅動開發依然更合適。
但對於企業級業務應用——大量的 CRUD、業務流程、主數據管理——這套方法提供了一個結構化的框架，讓 AI 輔助開發從"看運氣"變成"可重複"。
核心要點：
「Vibe coding 會讓你失去掌控」；規格說明書是掌控的根基 「用例是一種被低估的規格格式」；它密度高、可理解、可驗證 「Skills + MCP + Guidelines 是工具三件套」；讓 AI 的輸出符合你的項目上下文 「你始終負責」；AI 生成的代碼，你必須能理解、能驗證
最後，留一個問題給你：
你現在做的項目，有多少比例的代碼，你能自信地說出"我知道它在做什麼，為什麼這樣做"？
如果這個比例因為引入 AI 在下降，也許是時候考慮 Spec-driven Development 了。
❝原文連結：https://www.youtube.com/watch?v=35dH6q18UtI
❞