規格先行。在程式碼之前，你先讀它。

流程：規格、審閱、計畫、審閱、任務、建置

不是一個大提示加一堆程式碼，而是讓工作經過一份份文件，每一份在下一份寫出之前都先由你檢查。

1. 規格：做什麼、為什麼

   功能必須做什麼、為誰而做、又不能做什麼。先不要有檔案名稱，也不要有技術選擇。

2. 計畫：怎麼做

   做法：哪些部分要改、順序如何、風險是什麼。計畫要對規格負責。

3. 任務：小步驟

   一份代理可以逐項處理並勾選的清單，每項任務小到可以檢查。

4. 建置

   到這時代理才寫程式碼，依據的是你已經讀過的文件。

一份簡短的規格範本

規格不必很長。六個標題就足以抓出大部分的誤解：

# Feature name

## Goal
## Non-goals
## Users
## Requirements
## Edge cases
## Open questions

Non-goals 和 Open questions 是人們最常跳過、代理卻最需要的。被告知不要做什麼、還有什麼沒決定的代理，會去問，而不是亂猜。

在 Claude Code、Codex 與 Cursor 中進行

三者都能寫這些文件，也各有規劃階段使用的計畫模式：Claude Code 計畫模式、Codex 計畫模式與 Cursor 計畫模式。

若要讓審閱步驟自動發生，請在 CLAUDE.md 或 AGENTS.md 加一條規則：寫完規格或計畫後，用 DotMD 的 request_review 送給你，然後等待。代理就會在每份文件後停下，等你的註解或核准，等待期間不消耗 token。DotMD 可以幫你加上這條規則：請見 CLAUDE.md 與 AGENTS.md。

可擴展的審閱

聊天不是審閱文件的好地方。你改在 DotMD 閱讀渲染後的規格，選取錯誤的段落，按 ⌥⌘M。註解綁定在它的行上，所以代理確切知道你的意思。你可以先把所有註解寫完，再一次送出。

代理修正之後，每項更動都顯示在檔案中：舊文字為紅色、新文字為綠色，就在它所回應的註解旁。逐項 Accept 或 Reopen。DotMD 也會列出沒人要求的更動。請見審閱變更。

想要第二意見，可以先讓另一個代理審閱。由 Claude Code 寫、Codex 加註解的規格，到你手上時明顯的缺漏已經標出，由你決定哪些意見交給撰寫者：代理審閱代理。

規格驅動開發的工具

• 儲存庫中的純 Markdown。一個 docs/specs 資料夾加上上面的範本，就是完整的設定。
• 計畫模式。各代理在建置之前自己的規劃方式。
• GitHub Spec Kit。一個開源工具組，為你的代理提供每一步的指令，並替你寫出 spec.md、plan.md 與 tasks.md：GitHub Spec Kit。

無論你選哪一種，這些文件都是 Markdown 檔案，DotMD 都能讀。

關於規格驅動開發的問題

更多問題