規格驅動開發在 AI 時代的新方向：讓代理自動維護計劃
來源: @augmentcode | 原文連結
日期: Mon Feb 23 17:57:33 +0000 2026
標籤:
AI編程代理規格驅動開發開發實踐
來源: @augmentcode (Augment Code)標籤:
AI 開發spec-driven developmentcoding agents文件維護
規格驅動開發的問題
你唯一能 100% 信任的文件就是程式碼本身。
設計文件、變更日誌、README、架構圖、入職指南。每一個幾乎都會立刻過時。
讓書面文件與不斷變化的系統保持同步是一項持續性成本，而工程師習慣的是爆發式工作。寫完文件、交付功能、繼續前進。更新文件這部分是看不見的工作，它與其他所有事情競爭，而且幾乎每次都會輸。我們嘗試過流程、嘗試過工具、嘗試過把它變成團隊價值觀。這些都不管用，因為我們一直在要求人類去做一件人類可靠地不會做的事情。
這就是規格驅動開發（spec-driven development）通常會失敗的地方。這個想法本身沒問題：當你與 coding agents 合作時，先寫下你想要什麼，再讓它們開始工作。這顯然比把提示詞貼到聊天視窗然後祈禱好運要好得多。
但規格（spec）是一份文件。而我們剛剛已經確認文件會發生什麼事。
差別在於風險。過時的設計文件會誤導下一個碰巧讀到它的工程師。過時的規格會誤導不知道更多資訊的 agents。它們會自信地執行一個不再符合現實的計劃，而且不會標記任何問題。
Intent 的解決方案
所以當我們開始打造 Intent 時，我們一直在思考的問題是：如果規格不是你需要維護的東西呢？如果它能自我維護呢？
以下是我們的做法。
規格既不是人類的產物，也不是 agent 的產物。雙方都從中讀取並寫入。
你描述你想建立什麼。協調 agent 起草一份規格，將其分解為任務。你查看、編輯、在任何東西執行前批准。一旦 agents 開始工作，它們會寫回更新：它們發現了什麼、改變了什麼、遇到了哪些計劃中沒有的限制。你可以隨時暫停、重寫部分規格，agents 會從新狀態繼續。
像與優秀初級工程師協作
想想當你把任務交給一個優秀的初級工程師時會發生什麼。你給他們工作項目，他們去執行，當他們發現 API 不像工作項目假設的那樣支援分頁時，他們會自己更新工作項目。他們不會等你注意到有問題。他們不會只是建立錯誤的東西。他們會回來說：「這個假設是錯的，這是我改做的，這是原因。」你審查他們的更新，然後批准或反駁。
這就是我們想要的開發者與規格之間的關係。工作項目保持誠實，因為雙方都在維護它。
優秀初級工程師的類比比你想的還要深入。一個好的初級工程師不會描述每一行程式碼。他們會浮現那些改變方向的決策：「我找到了現有的 auth context，所以我接入那個而不是創建新的。」這就是訊號。這也是你想從 agents 那裡得到的。把這個粒度做對，結果是系統中一個真正有趣的設計問題。太多會讓規格變成你學會忽略的噪音。太少你又回到猜測發生了什麼的狀態。
實際運作方式
以下是一個任務實際的樣子。你寫：「在設定頁面加入深色模式切換，並尊重系統偏好設定。」協調者讀取你的程式碼庫，起草一份包含三個子任務的規格：加入切換元件、將它連接到偏好設定儲存、更新 CSS 變數。
你瀏覽它，注意到它遺漏了跨會話持久化選擇的部分，然後加入一行。
你批准。
Agents 接手工作。
十五分鐘後，其中一個更新了規格：「在程式碼庫中找到現有的主題 context provider。接入該處而不是創建新的儲存。」
你審查程式碼變更（清楚地按 agent 和任務分組）。
規格現在反映的是實際建立的內容，而不是最初計劃的內容。而且沒有人需要記得去更新它。
結論
軟體中每一個文件優先的倡議都因為同樣的原因失敗：它要求開發者做持續的維護工作，但沒有人看到也沒有人獎勵。
除非 agents 承擔它們該做的維護工作，否則 SDD（規格驅動開發）會因為同樣的原因失敗。
如果 agents 能寫程式碼，它們就能更新計劃。讓它們做吧。