當 AI 寫 code 比人快十倍，瓶頸就從「寫程式」移到「把需求講清楚」。 2026 年業界收斂出的主流交付模式是：先寫一份可驗收的 spec，再讓 AI 依規格實作。核心哲學是一次反轉——不是 spec 服務 code，而是 code 服務 spec（spec-kit 方法論、Microsoft）。
原因很單純：AI 非常擅長依「明確契約」實作，非常不擅長推斷「隱含契約」。輸出品質幾乎正比於你給的 spec 品質——這點 Microsoft、Addy Osmani、Augment Code 三方獨立表述一致。
核心方法：標準生命週期
Constitution（原則）→ Specify（意圖）→ Clarify（消歧義）→ Plan（技術設計）→ Tasks（拆解）→ Implement → Validate（對照驗收）。
- GitHub Spec Kit（CLI
specify）把這串變成可執行指令：/speckit.constitution、/speckit.specify、/speckit.clarify（標[NEEDS CLARIFICATION]）、/speckit.plan、/speckit.tasks（[P]標可平行任務）、/speckit.implement（repo）。 - AWS Kiro：Requirements（EARS
WHEN...THEN...）→ Design → Tasks（相依分析）（kiro.dev）。 - JetBrains Junie：輕量四步、受控執行「只做任務 1-2」——「你保留方向盤，agent 提供動能」（JetBrains）。
- OpenSpec（改既有系統用）：propose→apply→archive，用 delta（ADDED/MODIFIED/REMOVED）只描述「這次改了什麼」。
Best practices：怎麼寫「AI 可驗收」的 spec
- Osmani 六區塊：Objective／Tech Stack（含版本）／Commands／Project Structure／Boundaries（✅Always ⚠️Ask first 🚫Never）（Osmani）。
- 驗收條件用 Given/When/Then，且必須：具體可測（禁「快」「合理」，改「2.5 秒內」）、二元判定（不能完成 50%）、通過自我檢驗——「兩個人看這條，會不會一個判過、一個判不過？會的話就是不夠精確」（BrainGrid）。
- 最能防失敗的三個區塊：驗收條件、input/output 契約（機器可讀 schema）、「Not Included」範圍邊界（Augment）。
- 技術決策刻意延到 Plan 階段，Specify 只講 what／why。
- spec 內部矛盾時 agent 會靜默選一個執行、不告訴你——所以要主動檢查 spec 有無自相衝突。
實踐步驟
- 建 constitution（tech stack、測試優先、Boundaries 三分類），專案共用。
- 每個新功能開 spec，用 Objective + User story 起手。
- 驗收條件全改 Given/When/Then，逐條做「兩人判定一致嗎」檢驗。
- 跑 clarify 消歧義，再轉 Plan（data model／API 契約／依賴）。
- 拆 Tasks（每個可獨立驗證），分批執行 + 每批人審，別一次全跑。
- 對照最初 spec 逐條打勾驗收；需求變了先改 spec 再改 code。
主張 vs 可佐證
- 可佐證：四階段收斂是主流敘事（多家獨立用詞一致）；小任務套全套 SDD 會過度開銷（Martin Fowler、Scott Logic 實測慢~10× 有量化）；Given/When/Then 是最適格式。
- 反面共識：SDD 是「執行工具」不是「發現工具」——需求不明時先寫死 spec 只會把錯誤更快放大（Nearform）；spec 會與實作漂移且 agent 不示警（Augment/Isoform）；大型既有 codebase「幾乎不可用」（Marmelab）。
- 主張／存疑：「3-10× 首次成功率」（廠商）、star 數（會變）、「10× 變慢」（n=2 單一實測）。學界幾乎無對照實驗。
一句話判準：中大型、需求明確、需長期維護 → 值得；小修改、探索性原型、需求還在變 → 開銷常大於收益。
這是工程實作群的起點。定義需求的上游功夫見 Problem Framing ＋ Spec-Driven；spec 寫完要交給 AI 執行，方法見 委任溝通術；驗收要能量化見 Evals；實作完的把關見 AI Code Review 與 測試生成。