生活分享

規格驅動開發（Spec-driven Development）是什麼

規格驅動開發先把需求、限制與驗收條件寫成可維護的規格，再讓設計、實作和測試依它推進。本文以社區場地預約提醒為例，說明需求、技術設計與任務清單的差別，如何處理模糊條件、需求變更和測試追溯，並比較它與只寫一大段提示詞的工作方式。讀完能整理一份可討論、可實作、可驗證的小型規格，避免檔案寫完卻和程式脫節。

更新日期: 閱讀時間約 7 分鐘

展開的規格圖紙連到積木與勾選章，表示書面需求被轉成實作並接受驗證。
圖片：Mokaair (© Mokaair)

規格驅動開發是把需求與預期行為放在開發工作的中心，再讓設計、實作與驗證對應這份規格。規格不是越厚越好，而是要讓參與者知道做什麼、為什麼做、哪些情況要怎麼處理，以及何時算完成。在 輔助開發裡，它尤其有助於把容易含糊的自然語言請求變成可核對的工作依據。

這個名稱不是單一工具專屬，也不表示自然語言檔案可以自動保證程式正確。以下參考 GitHub Spec Kit 與 Kiro 的官方工作流程，用「預約前傳送提醒」的原創案例示範需求如何連到測試。資料查證截至 2026 年 9 月 14 日。

需求、設計和任務不是同一份清單

GitHub Spec Kit 把規格、計畫與任務作為可追蹤的產物；Kiro 文件則用需求、設計和任務檔案整理工作。兩者反映相近的規格導向做法，但細節、工具操作和流程不完全相同。這裡採用這些共同觀念，不要求讀者必須安裝特定軟體才能開始。

需求描述使用者期待，例如借用人希望在預約前收到提醒，以免忘記到場。設計說明如何達成，例如由排程工作查詢待提醒預約，再交給通知服務。任務則是可實作的小項目，例如新增提醒狀態、建立時間判斷、加入取消測試。混在一起時，很容易把「寫了排程」誤認成「提醒需求已完成」。

規格還需要範圍界線。這次只提供已確認預約的提醒，不包含候補通知與活動推薦，就應寫明。界線能阻止代理因為覺得相關而自行擴張功能，也能讓人把尚未處理的需求放進後續工作。範圍不是逃避品質，而是使交付可以被完整驗收。

把一句願望改成明確行為

原創需求是：「預約前一天提醒我。」它至少缺少時區、傳送時刻、通知管道與取消處理。前一天是曆日概念，還是距離開始滿一天？若預約在當天才建立，又該怎麼辦？這些問題會改變使用者收到通知的時間，應在實作前澄清，而不是由代理任選合理解釋。

假設這份示例規格決定以場地當地日期計算，前一個曆日的固定時刻傳送；已取消預約不送；新建立時已錯過提醒時刻的預約，頁面顯示不會再補發。這只是教學選擇，並非所有提醒系統的通則。重要的是將選擇寫清楚，讓後續程式與使用者說明一致。

接著寫驗收案例：一筆仍有效且已到提醒時間的預約應產生通知；取消的預約不產生通知；重跑同一批工作不重複傳送。每個案例都要有前提、觸發與可觀察結果。像「提醒功能正常」這種句子，既沒有提供輸入，也沒有說明到哪裡看證據。

讓設計解決非功能條件

規格也可能包含可靠性與資料處理條件，例如通知失敗應可重試、同一預約不應重複提醒、聯絡方式僅供通知使用。這些條件不一定在畫面上看得見，卻會直接影響實作。設計階段要說明狀態何時寫入、如何確認傳送結果，以及傳送途中斷線時如何判斷是否重試。

若系統在訊息送出後、紀錄成功前中斷，單純重跑可能造成重複通知。這時設計需要明確的通知識別與狀態查核方式，實際方案依通知服務能力而定。不能只在提示詞加一句「請確保不重複」，就假定分散在不同服務的動作會自動保持一致。

讀者不必自己設計所有技術細節，但可以要求設計說明指出每個重要條件由何處保障。取消檢查在選取待傳送資料時做，還是在真正傳送前再做？兩者可能處理不同時間差問題。把這種取捨留下來，之後維修才知道程式為何如此安排。

任務完成要能回到規格驗收

實作任務可依資料狀態、時間判斷、通知介面與測試拆分，但每項都應指向它服務的需求。當代理說「排程完成」時，審查者應能追到相關程式與案例。任務勾選只代表工作流程中的；是否滿足需求，仍由可觀察結果與驗收條件決定。

可以用測試接收端接收示例通知，核對內容和傳送次數，再把排程重跑一次。預期是不多送同一筆。接著取消另一筆預約，確認它不再進入待傳送集合。如果測試只檢查函式回傳成功，卻沒有確認接收端得到什麼，就可能漏掉真正的使用者結果。

檔案和程式的連結不必複雜到建立巨大平臺。一個小專案可以在規格段落標記穩定名稱，於任務與測試說明引用它。重點是有人能從需求找到證據，也能從程式變更找到理由。這種雙向追溯讓規格持續有用途，而不只是專案開始時的形式。

需求、設計、任務與測試橫向連線，下方變更紀錄回到整條鏈，表示規格改變需要同步檢查後續產物。
檔案的價值在於持續連結決策與證據，而不是只在開發前寫一次。 · 圖片：Mokaair (© Mokaair)

需求改變時，更新的是整條關係

若社區後來要求取消後也傳送取消通知，這是一個新的行為，不能只改原先「已取消不送」的文字而不檢查其他影響。要確認原條件指的是預約提醒，新需求指的是取消通知，兩者可以並存，再更新設計、任務和測試，避免用語混淆造成全面停送或重複通知。

規格驅動開發適合需求涉及多人合作、複雜例外或長期維護的工作。對一次性探索，規格可以短到只有目標、範圍和幾個驗收案例。重點是保持與任務相稱的細節，不是把所有未知都先寫成看似確定的檔案。未決問題應保留並安排確認。

它與提示詞工程的差別，在於規格是團隊維護的工作依據，不只是某次模型呼叫的指令；與代理式工程的關係，則是提供可委派與可驗收的需求。真正有效的規格會隨決策更新，並讓人看得出哪些需求已實作、哪些只有設計，以及哪些還沒有驗證。

規格工作各產物的角色（2026 年 9 月查證）
產物提醒系統的內容常見誤會
需求規格何時提醒、取消如何處理只描述畫面或一句願望
技術設計狀態與重試如何保障堆出元件名稱就算完成
驗收案例重跑不重複，取消不送提醒只看任務已被勾選

同主題延伸閱讀

  • 生活分享

    世界模型（World Model）是什麼：讓 AI 預測「接下來會怎樣」

    世界模型指 AI 內部用來預測「這樣做之後會怎樣」的模型，但這個詞至少有三種用法：強化學習代理在想像中練習用的環境模型、LeCun 主張預測抽象表示的架構路線，以及能隨操作即時生成畫面的互動環境。內容用示例說明怎麼在想像中規劃，並列出大型語言模型有沒有世界模型的正反研究，附讀新聞時的檢查問題。

  • 生活分享

    視覺語言模型（VLM）是什麼：讓 AI 讀圖片、再用文字回答

    視覺語言模型（VLM）能同時接收圖片與文字，再用文字回答。內容拆解視覺編碼器、連接層與語言模型三段結構，說明 CLIP、Flamingo、LLaVA 三篇論文各補上哪一塊，並和多模態 AI、文字生圖分清楚；也整理它常犯的錯：數錯數量、搞混位置、說出圖裡沒有的東西，附上讀收據時逐行核對的步驟。

  • 生活分享

    溫度（Temperature）是什麼：AI 回答變化程度的取樣參數

    溫度（temperature）是文字生成時調整取樣的參數，讓模型從下一個 token 的機率分布裡抽得更集中或更分散。用假想的台南早餐示例算出低溫與高溫的差別，說明 top-p 的來源和它與 top-k 的差別，並依官方文件與論文指出：調低溫度不代表更準，設成 0 也不保證每次相同，部分模型還不開放調整。

  • 生活分享

    合成資料（Synthetic Data）是什麼：兩種用途、品質控管與模型崩潰

    合成資料是由演算法或模型產生、模仿真實資料特徵的資料，常見用途有兩種：訓練模型，以及在隱私需求下替代真資料。內容依 Self-Instruct、模型崩潰研究（替換與累積資料的差別）與 NIST、ICO 的隱私文件，說明做法、抽查流程，以及它不能保證的事。

引用本文的文章

最新旅遊情報攻略

資料來源

生活分享