Spec-driven development 吵錯重點了，關鍵是那份規格寫完之後要活多久

spec-driven development 的真正分水嶺，是規格寫完之後要活多久。Martin Fowler 網站一篇文中未署名的實測比較三個 AI coding agent 規格工具，整理出三層規格壽命。 ⭐ 文章深度讀：三個警訊，都有實測撐著 → https://heymaibao.com/spec-driven-development-spec-lifespan/ ⚡ 章節重點 吵的其實不是該不該寫規格 00:00 引爆點：他公開拒絕被歸進 SDD 00:27 同一個詞，三種規格壽命 01:12 把光譜再往下延一格 02:10 三個工具，各自在替存活期投票 03:03 三個警訊，都有實測撐著 04:20 MDD 這面照妖鏡 06:27 動手前先問一次：這份規格要活多久 07:23 📝 懶人包 ∙ 那篇評測把 SDD 拆成三層：只服務當下任務的 spec-first、任務結束後繼續維護的 spec-anchored、規格變成唯一主檔的 spec-as-source。作者試的三個工具裡，只有一個明確追求 spec-anchored，而且還在探索最上面那層。 ∙ 最痛的實測結果是尺寸不匹配。作者拿 Kiro 修一個小 bug，需求文件把它變成 4 個 user story (使用者故事，需求的標準寫法)、總共 16 條驗收條件。 ∙ Matt Pocock 公開拒絕被歸進 SDD。他說他的工具產生的規格是設計成要立刻刪掉的，不是留著，也不是被當成原始碼。 ∙ 我的觀察是，這條軸上唯一在變的變數就是存活期。Matt Pocock 的立場不是另一個陣營，是同一條軸再往下一格，成立條件是你願意把「產生規格的過程」而不是「規格本身」當成真正的產出。 📚 參考資料 Martin Fowler 網站：三個自稱 spec-driven development 的工具實測 → https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html Matt Pocock 談 spec-driven development 的貼文 → https://x.com/mattpocockuk/status/2083563195671667176 github/spec-kit → https://github.com/github/spec-kit/blob/main/README.md Matt Pocock 的 /grill-me skill 頁面 → https://www.aihero.dev/skills-grill-me 8 Reasons Why Model-Driven Approaches (will) Fail → https://www.infoq.com/articles/8-reasons-why-MDE-fails/