AI 知識
為什麼 spec-driven 會變成 AI coding 的關鍵能力？
AI coding 這兩年最吸引人的想像，是一句話丟出去，AI 就能把功能寫出來。
這個想像很迷人，也確實已經能做很多事。
但真正開始把 AI 代理放進稍微複雜一點的開發工作後，很多人會遇到同一個問題：
AI 不是不會寫。
它是太會在你沒說清楚的地方自己補。
你說「幫我做登入」，它可能會猜一套驗證流程。
你說「幫我加報表」，它可能會猜資料欄位、權限、排序、匯出格式。
你說「幫我重構」，它可能會猜哪些行為可以保留、哪些可以改掉。
這些猜測有時候很合理，有時候卻剛好踩中你最不想動的地方。
所以最近 spec-driven AI coding 變得很值得注意。OpenSpec、GitHub Spec Kit 這類工具與方法，背後都指向同一件事：不要讓 AI 先把模糊需求變成程式碼，而是先把需求、限制、計畫和驗收條件說清楚。
問題不是 AI 不會寫，是人把規格藏在腦袋裡
過去我們常把 AI coding 當成一種更快的打字工具。
給它一句話，它回一段 code。
不滿意，再補一句。
還是不對，再修一句。
這種方式在小工具、一次性腳本、快速原型上很好用。但當任務牽涉既有系統、使用者流程、權限、資料一致性、效能或安全限制時，單靠聊天式來回就很容易失控。
原因很簡單：很多真正重要的規格，其實沒有寫在 prompt 裡。
它們藏在人的腦袋裡，藏在既有產品習慣裡，藏在團隊默契裡，藏在「這個地方不能動」的經驗裡。
AI 看不到這些，它只能從你給的文字、目前上下文和常見模式去推。
當上下文不完整，AI 不會停下來把所有缺口都列出來。它常常會做一件看似貼心、其實危險的事：猜。
spec-driven 在改變哪件事？
spec-driven 的核心不是叫大家回去寫厚厚文件。
它比較像是把「要做什麼」從一句模糊指令，拆成 AI 和人都能對齊的工作契約。
一個清楚的規格至少要回答幾件事：
- 這次到底要改什麼？
- 使用者會怎麼使用？
- 哪些行為必須保留？
- 哪些限制不能踩？
- 做完要怎麼驗收？
- 如果 AI 產出的方案和原本想像不同，要用什麼標準判斷？
OpenSpec 的做法，是讓每個 change 有自己的 proposal、specs、design 和 tasks。GitHub Spec Kit 則把流程拆成 specify、plan、tasks、implement，讓規格、計畫與任務拆分先被整理出來，再交給 coding agent 動手。
不同工具細節不一樣，但共同精神很接近：
先對齊，再生成。
先把成功標準講清楚，再讓 AI 寫。
先讓人有檢查點，再看程式碼。
為什麼這對一般使用者也重要？
這件事不只跟工程師有關。
因為 AI 代理的能力越強，一般人也會越常把「做一件事」交給 AI。
寫程式只是最明顯的場景。
同樣的問題也會出現在寫企劃、整理資料、設計流程、產出報告、生成簡報、建立自動化步驟。
只要任務不是單純問答，而是要 AI 幫你「完成一個結果」，規格就會變重要。
你沒有說清楚的地方，AI 會幫你補。
你沒有定義的成功，AI 會用它以為合理的方式完成。
你沒有列出的限制，AI 可能根本不知道那是限制。
所以未來真正會用 AI 的人，不一定是 prompt 寫得最華麗的人。
更可能是能把模糊想法拆成清楚規格的人。
一個簡單的使用方式
下次你想叫 AI 做一件比較複雜的事，可以先不要直接叫它開始做。
先請它幫你整理這幾項：
- 目標：這次要完成什麼結果？
- 邊界：哪些事不做？哪些地方不能改？
- 成功標準：做到什麼才算完成？
- 風險：有哪些地方最容易誤解？
- 步驟：應該先確認什麼，再開始產出？
接著你先看這份規格。
不對的地方先改。
不清楚的地方先補。
等你覺得規格像你真正想要的東西，再叫 AI 開始做。
這樣看起來多了一步，實際上常常是在減少後面十幾步返工。
規格不是信任 AI，而是讓 AI 可以被檢查
spec-driven AI coding 最有價值的地方，不是讓人可以完全放手。
剛好相反。
它是把 AI 的工作變得更容易被檢查。
如果沒有規格，AI 交出一大段程式碼時，你只能問：「看起來對不對？」
如果有規格，你可以問：
- 這段改動是否符合目標？
- 是否踩到邊界？
- 是否有對應驗收條件？
- 是否偏離原本任務？
- 是否把未說出口的猜測寫進實作？
這些問題比「AI 寫得好不好」更精準。
AI 代理越強，越不該只靠一句模糊指令開工。
因為它真的會動手。
也正因為它真的會動手，人更需要先說清楚：到底要它做什麼、不要它做什麼、做完要怎麼檢查。
未來會用 AI 的關鍵能力，可能不是把話講得更像咒語。
而是把想法整理到 AI 不能亂猜。
查證摘要
- OpenSpec GitHub README：Fission-AI/OpenSpec。定位為 AI coding assistants 的 spec-driven development framework，強調在寫 code 前先讓 human 與 AI 對齊 specs。
- GitHub Spec Kit README：github/spec-kit。將規格、計畫、任務拆解成可直接驅動 implementation 的工作流。
- GitHub Blog：Spec-driven development with AI。說明為什麼模糊提示在既有 codebase 上容易失控，以及 specify、plan、tasks、implement 的流程價值。