Part 2｜第一次把開發寫成協議：DAP 的 8-Step（Day 06–13）

接下來這八天，我會回頭拆解 DAP 在上線過程中逐步形成的 8-Step。從 Spec、Plan、Task 到後續實作，看看它們怎麼串成一條人與 AI 都能接手的開發協議。

我也不是每次都跑完八個步驟。小修改和 Bug Fix 可以分流；當需求開始牽涉既有行為、API 或較大範圍的調整時，才走進這套流程。每個步驟都有當時要解決的問題，也有相對應的人與 AI 分工。

Day 05 我先把畫面畫出來，讓 Coding Agent 不必猜按鈕、版面和互動。
可是畫面有了，還有一個問題：這次到底要改到哪裡？哪些既有行為不能動？

• 白話需求可以是起點，但它還不是實作範圍。
• 我會讓 LLM 先起草 Spec；資訊不夠時，再回來討論。
• 我看過 Spec 後，才決定要不要讓它往 Plan 走。

畫面都畫好了，我為什麼還不直接叫 AI 改？

Day 05 我先把 UI 的任務、版面和狀態畫出來。導覽怎麼分、右側要不要固定保留申請摘要、點了哪裡之後畫面要切到什麼狀態，這些事有了設計稿，至少不必再靠「按鈕往右一點」來回討論；我甚至可以直接在 Pencil 頁面上調整。

但把設計稿交給 Coding Agent 時，這也面只是前端頁面的殼。Agent 知道畫面要長什麼樣子，卻不知道既有頁面原本是怎麼運作，也就是業務邏輯的部分；更不會自己知道這次是不是只改一個入口、哪些規則不能動，或改完後看到什麼才算完成。

第三代我開始使用 Spec Kit，主要是因為我想要將每次功能改動都留下文件，這個改動是做的什麼，技術細節有哪些。

設計稿讓人看懂畫面；Spec 讓團隊確認這次到底要改到哪裡。

我第一次寫 Spec 的方式

第三代第一個移轉的是登入頁。當時我的輸入沒有很複雜，大概只有一句：「參考 Login Page，改寫 login 頁面。」

我沒有先坐下來手寫一份完整規格，也沒有先列完所有技術細節。我先把需求交給 /specify，再依序跑 /plan、/tasks。

這個順序讓我第一次感覺到，AI 開發不一定要從「直接改程式」開始。它可以先把自己的理解寫成一份文件，讓我在還沒碰到 code 前先看一遍。

我的確認方式其實很直接：我看 Spec 裡描述的內容是不是我想要的。如果不符合，我就直接跟 LLM 說要改哪裡；如果我一開始講得不夠清楚，LLM 會要求我補充。

我不把這當成流程卡住。它只是告訴我，這句需求還沒有足夠資訊可以往下做決定。

白話需求
  ↓
/specify 產出 Spec 草稿
  ↓
資訊不夠？→ 我補充
  ↓
我確認需求描述
  ↓
/plan → /tasks

我後來回頭整理 repository 時，也沒有把登入頁當成「流程已經完整驗證成功」的案例。它是我開始改變工作方式的起點；這篇真正要拆解的，是另一個留下較完整需求與 Spec 紀錄的案例。

我會把 Spec 切成小範圍，每次變動都留在自己能掌握的邊界裡。

三句白話需求，怎麼變成一份可以 review 的 Spec？

我選了一個很小的側邊欄調整當主案例。原始需求很日常，而且幾句話就講完：某個入口前要補圖示、功能群組的順序要調整、其中一個群組名稱要改得更清楚。

這些需求還混在同一份工作紀錄裡，不是一張排版漂亮的需求單。這其實很接近我平常收到需求的樣子。

如果直接把它交給 AI 實作，它還是要自己猜不少事情：現在的群組順序是什麼？這個圖示為什麼沒有出現？只改排序，會不會讓目前選中的樣式、既有互鎖或導覽跳轉壞掉？什麼畫面出現才算完成？

Spec 主要是把原本沒講完整的事情記錄清楚：先記錄現況，列出這次要調整的內容，最後把驗收條件列成可以到瀏覽器檢查的項目。

白話需求	Spec 補上的內容
補一個入口圖示	現況圖示為何未顯示、要出現在哪裡、怎樣檢查。
調整群組順序	原本順序、目標順序，以及哪些既有導覽行為不能被破壞。
修改群組名稱	新名稱、影響範圍與驗收時要看到什麼。
Repository 裡可以對照到原始白話需求、對應的 Spec，以及同日的實作紀錄。我在文章裡把它匿名化，因為重點不是 DAP 的實際功能，而是需求怎麼被翻成工程邊界。

Spec 不是替需求加格式，而是把 AI 原本必須猜的狀況寫出來。

LLM 問我問題，不是流程卡住

以前用 Vibe Coding 時，我常常是在程式做出來後，才發現自己少說了一件事：還有一個欄位、另一個 API，或這個畫面其實不能這樣排。

現在不是保證我不會忘記，而是把「還沒想清楚」提前到 Spec 階段處理。

所以當 LLM 問我：「這個既有行為要不要保留？」「這個規則是不是本次範圍？」，它是在提醒我，現在的需求還不足以替我決定細節。

分工可以很簡單：LLM 讀既有文件、整理目前行為、起草 Spec，並列出不知道的地方；我確認需求是否正確、範圍是否合理、哪些業務規則不能動。確認後，才進到 Plan。

Spec 裡如果沒有寫對現況和邊界，後面的 Plan、Tasks 再完整，也只是在錯的前提上往下走。

AI 問問題，代表需求還沒有足夠資訊可以往下做決定。
把功能範圍說清處，才不會讓最後產出結果超出想像。

Spec Kit 在這裡發揮的效果：固定順序

我喜歡 Spec Kit 的部分在於它將需求流程結構化，是「先談什麼」的順序：先把想做的事寫成 Spec，再談技術方案，最後才拆成 Tasks。它的核心觀念是先定義 what，再討論 how，而不是從一次性的 prompt 直接跳到實作。Spec Kit README

對我而言，工具的價值不是自動產生三份 Markdown，而是把「先確認需求，才談技術方案」變成一個固定動作。

今天可以做的：替一個變更寫最小 Spec

今天不需要安裝 Spec Kit，也不需要把整個專案補成文件。選一個你下週真的會改的功能，先寫一份最小 Spec 就好。

# Spec｜功能名稱

## 現況
- 使用者現在怎麼操作：

## 本次要改什麼
- 新增／修改什麼：

## 這次不要改什麼
- 不要碰到的既有行為、API、權限或資料規則：

## 完成時要看到什麼
- [ ] 使用者完成哪個操作後，應看到什麼結果：

如果你已經在用 Claude Code，可以先請它起草，但不要讓它直接開始改 code：

請先讀取這個頁面的現況與相關設計稿，依上方模板起草 Spec。
不知道的地方請列為問題，不要自行假設；暫時不要修改程式碼。

做完後，你手上不只是一段 prompt，而是一份下一個人、下一個 session，甚至下一個 Agent 都看得懂的變更說明。

延伸工具：如果你正在處理既有系統，也在煩惱「每次變更後怎麼同步回專案知識」，可以研究 Prospec。它主打既有 codebase 的知識整理與 change spec；DAP 第三代並未使用它，因此我把它當作下一輪實驗的候選工具。

小結：Spec 解決「要改什麼」，Plan 才能討論「怎麼改」

白話需求沒有問題，它本來就是我和使用者最自然的溝通方式。但進入改碼前，我需要先把它轉成能確認的現況、範圍、不變規則和完成條件。

我從登入頁開始嘗試這件事，也從側邊欄調整留下比較可追溯的案例。它沒有讓我從此不必思考，而是讓我在 AI 開始改 code 前，先知道我們是不是在做同一件事。

下一篇要接著問：既然 Spec 已經說清楚「要改什麼」，技術上到底要怎麼改？Plan 又為什麼值得在 AI 實作前多停一次？

參考資料

• GitHub. Spec Kit.
• ci-yang. Prospec.