Day 06 的 Spec 先處理「這次要改什麼」。
但當需求開始碰到既有 API、資料來源與多個檔案時，還有一件事不能跳過：先看 AI 準備怎麼做。

• Plan 會先把 AI 對 API、資料與改動範圍的假設攤開；我主要確認 API 是否正確。
• 資訊還不夠時，先釐清再進 Plan，不讓 AI 把猜測寫進程式。
• 多 Agent 能不能繼續，不取決於開了幾個 Agent，而是它們是否拿到已確認的共同輸入。

Spec 都寫好了，為什麼我還不讓 AI 直接改？

Day 06 我把需求先寫成 Spec，讓「這次要改什麼」有一個可以確認的範圍。照理說，下一步好像就該直接開始改 code。

我一開始也是這樣想。後來在 DAP 開發時才發現，Spec 寫清楚目標，並不等於 AI 已經知道該怎麼接進既有系統。這個頁面該 call 哪一支 API？資料結構是不是我以為的樣子？有些流程能沿用，有些不能動，這些都還需要被說清楚。

畫面做得出來，不代表它接得上既有系統。API 接錯，按鈕再完整，送出的資料還是可能不對，甚至走不到原來的流程。

所以我開始把 Plan 放在實作前。它不是要多開一場架構會議，而是先讓 AI 把「我準備怎麼改」寫出來。我看完後，再決定這個方向能不能往下走。

Spec 決定目標；Plan 讓我先看 AI 準備怎麼走到那裡。

這裡我重點會去確認 API 對不對

我不會把 plan.md 當成需要自己重寫一次的技術設計書。LLM 先讀相關程式與 Spec，整理它認為可以沿用的 API、預計修改的位置，以及還沒確認的問題；我先看最務實的一件事：API 是否正確。

在既有系統裡，這比畫面做得像不像更早決定功能會不會走偏。像是一個匿名化後的表單模式調整，Plan 會先列出：哪些既有 API 可以沿用、前端要在什麼時機呼叫、需要哪些資料，以及 mock 是否有相應欄位。程式還沒改之前，我就能知道 AI 有沒有把資料來源想對。

另一份 Plan 曾經明確標出：某個資料欄位的讀取路徑還不確定，實作前要再看真實資料結構。這種「還不知道」對我反而很有用。它沒有讓 Plan 失敗，而是避免 Agent 把看似合理的猜測直接寫進程式。

我通常會用下面四個面向看 Plan：

這裡不會公開 DAP 的真實 endpoint、欄位、頁面路徑或內部資料。重點不在 API 的名稱，而在於改 code 前，這些資訊有沒有被拿出來確認。

當時開發狀態，前後端拆開來處理，而前端按鈕接仰賴討論完的 API 規格。
因此這個步驟才會如此重視 API 的串接是否正確。

資訊不夠時，先釐清，不要讓 AI 補答案

有些需求本來就很清楚，直接產生 Plan 沒有問題。但如果我或 LLM 發現某個欄位的位置、既有行為是否保留，或 API 的輸入輸出還說不準，我會先用 /speckit.clarify 把模糊處問出來，再進 Plan。

這不是為了多跑一個指令。真正危險的不是 Plan 裡出現未知，而是未知沒有被標記，AI 卻把它當成已確定的事實繼續開發。

後來讀 Anthropic 談 context engineering 的文章時，我覺得這很接近它提到的做法：Agent 不必一開始拿到整個 repository 的所有內容，而是在要做決定時取得真正缺少的高訊號資訊。對我而言，待確認的 API 或資料路徑，就是任務當下最需要補的 context。

需求或資料還不清楚
  ↓
先列出待確認問題
  ↓
clarify／查既有 API 或程式
  ↓
確認後產生或更新 Plan
  ↓
才進 Tasks 與實作

Plan 裡能寫「我還不知道」，比讓 AI 假裝已經知道更有用。

Day 04 提到的多 Agent 實作，是從各自的 Plan 開始

我在 Day 04：為什麼我不只想拉皮 提過，第三代除了要重做頁面，還要在四個月內完成一套編審與分派流程。我回頭看這段開發時，很適合說明多 Agent 怎麼接進流程的一天。

當天同時有一批混合需求，有些偏前端調整，有些牽涉資料規則，也有文件工作。如果一開始就把它們全部交給不同 Agent 改 code，等於每個 Agent 都得自己判斷該用哪個 API、資料怎麼取、改動邊界在哪裡。

我當時沒有直接派實作 Agent。先讓不同 Agent 各自讀取自己負責的需求與相關程式，產出對應的 Spec／Plan。Plan 產出後，主 Claude 會把需要確認的技術問題帶回來；我在這個點確認 API 與做法，再讓後續的工作繼續。

確認後，不同 Agent 才依自己的 Spec／Plan 處理沒有重疊的範圍，最後由主 Claude 彙整結果。把當天的工作順序匿名化後，大致是這樣：

我真正得到的感覺是，Plan 還沒確認前，多派幾個 Agent 只會把不確定性複製好幾份。每個 Agent 都拿到已確認的共同輸入後，才有討論分工的基礎。

多 Agent 的前提不是先派工，而是先確認每個人拿到的是不是正確的資訊。

Plan 後停一次，把確認留在該停的地方

我現在的流程保留兩個由我確認的關卡。

第一個在 Plan 完成後：我確認 API 與做法，才讓開發繼續。第二個在開發完成後：我看結果是否符合需求，確認後才更新文件。

這不代表每一步都要我重新下指令。AI 還是會讀程式、起草 Plan、列出未知問題，並依確認後的範圍實作。我保留的是它不應該替我決定的事：既有接口是否正確、技術做法能不能接受，以及最後結果是不是我要的。

Anthropic 在〈Building effective agents〉裡區分了預先定義路徑的 workflow，與由模型自行決定過程的 agent；workflow 可以在中間設檢查關卡。放回我的案例，DAP 目前使用的不是放手讓 Agent 一路跑到底，而是讓 AI 在清楚邊界內工作、並保留人工停點的協議。

停下來不是為了再做一次 AI 的工作，而是把人的時間留給 AI 不應自行決定的事。

今天可以做什麼：替一個會動到 API 的變更寫最小 Plan

今天不要挑一行文字調整。選一個真的會碰到既有 API、資料流，或至少兩個檔案的變更，先讓 AI 把做法寫出來。

# Plan｜功能名稱

## 既有接口與現況
- 目前頁面／服務使用哪些 API：
- 本次沿用、修改或新增哪一支：

## 做法與影響範圍
- 要改哪些檔案：
- 這次不改哪些既有行為：

## 還不知道的地方
- 要向誰確認：
- 確認前不要假設什麼：

## 實作後怎麼驗證
- 最小操作：
- 預期結果：

如果你已經在用 Claude Code，可以先這樣要求它：

請讀取這份 Spec、相關頁面與 API 定義，提出 Plan。
請列出：既有 API、預計修改的檔案、不變規則、尚待確認的問題與驗證方式。
資訊不足時請提出問題，暫時不要修改程式碼。

做完後，問自己一個問題就好：我願不願意讓 AI 依這份 Plan 開始改碼？如果答案是否定的，先補問題或修 Plan，不要急著往下走。

好的 Plan 不必很長，但要讓我敢把下一步交出去。

小結：Plan 先把「怎麼改」攤開，Task 才有可交接的內容

Day 06 的 Spec 讓我先確認目標與邊界。Day 07 的 Plan，則讓 AI 把它準備沿用的 API、會動到的位置，以及還不知道的事先攤出來。

我 review Plan 時，最主要確認 API 是否接對。Day 04 提到的多 Agent 實作也讓我知道：後面能不能分工、要不要平行，前提都是先有一份大家可以共同依據的 Plan。

下一篇要進入 Task。Plan 確認後，要怎麼拆成可交接、可安排相依，也知道什麼叫完成的工作？

參考資料

• Anthropic. Effective context engineering for AI agents.
• Anthropic. Building effective agents.