Day 06 的 Spec 處理「這次要改什麼」，
Day 07 的 Plan 則讓我先確認「準備怎麼改」。

一份 Plan 往往混著好幾種工作：畫面狀態要改、資料怎麼處理、不同情境要怎麼檢查、文件是否要更新。有些工作可以一起做，有些必須等前一項完成。這時候，我會再往下產生一份 Task。

• Task 把已確認的 Plan 拆成實作、驗證與交付工作，讓 AI 知道下一步要做什麼。
• 用 /speckit.tasks 產生 tasks.md；通常不用再自己逐項補清單。
• LLM 勾選完成後，我仍會看程式與頁面狀態。checkbox 是進度回報，不能當成已驗證完成的證明。

Plan 都確認了，為什麼還要再拆 Task？

Day 07 我先看 AI 對 API、資料來源與改動範圍的理解。確認後，AI 當然可以開始改 code；但我很快發現，直接實作常常只會先完成最看得見的部分。

畫面做完了，切換模式後的預設值有沒有一起調整？送出後的確認頁有沒有保留同樣的規則？不同操作情境有沒有列出來？這些問題不一定會消失，只是很容易被埋在一大段 Plan 裡。

我不想自己再把 Plan 手動改寫成另一份待辦事項，所以第三代剛開始採用 Spec Kit 時，Plan 確認後會接著使用 /speckit.tasks 產生 tasks.md。它把接下來的工作攤開，實作不再只剩一句「把功能做完」。

Plan 是技術做法；Task 是把做法交到下一步的工作單位。

我先讓 LLM 產生 Task

我的順序很簡單：先用白話描述需求，讓 LLM 整理 Spec；看過需求範圍後產生 Plan；Plan 確認後，再用 /speckit.tasks 產生 tasks.md。

我通常不需要逐項要求「這裡再補一個 Task、那裡再補一個 Task」。Task 產出後，我就讓 LLM 往下開發，然後確認每一個項目有沒有真的做完。這比我每次在對話裡重新提醒「畫面改完要記得驗證」、「改完文件也要更新」更順。

GitHub 的 Spec Kit 也把從 Plan 產生可執行 Tasks，放在進入 implementation 前的步驟。不過我不會把工具流程當成品質保證。工具能幫我列出清單，卻不能替我決定這份清單是否涵蓋了真正需要處理的事。

我當時使用的指令是 /speckit.tasks；Spec Kit 的命令與整合方式可能隨版本調整。這篇不談指令，而是分享我為什麼需要一份 Task。

一個表單模式調整，裡面其實有四種工作

我用一個匿名化的案例說明。

當時有一個建立申請的表單，需要新增一種比較精簡的使用模式。聽起來像是前端加一個切換功能，但實際上不能只多一個按鈕。切換後，表單的預設值、可見欄位、候選清單，連送出後確認頁的內容，都要跟著一致。

這次不需要新增 API。這件事也被寫進 Task，先把邊界講清楚：不用為了這個頁面調整，再多做一層後端接口。接下來才是畫面的狀態切換、條件顯示和確認頁；完成後，要用不同模式分別操作一次，檢查送出結果和確認頁有沒有跑偏。最後還有資安審查與文件更新。

我後來比較習慣以一段可以交接、可以檢查的責任範圍來拆，不會每一行程式都列成 Task。頁面實作是一段工作；驗證要等實作完成；文件則應該以最後改動為準。拆到每一行 code 都有一個 Task，只會讓清單長到沒人想看。

checkbox 勾了，還不能當成完成

LLM 會依照 Task 往下實作，也會勾選它認為已完成的項目。但我不會只看到 checkbox 就結束。開發完成後，我會確認每個 Task 是否真的有對應的程式修改，再看頁面狀態是否符合原本需求；如果少了什麼，就要求 LLM 再檢查並補齊。

回頭看這個表單案例留下的 Task 文件，頁面實作與文件更新有被標記完成；Scenario 與資安審查沒有被勾選。這不代表它們一定沒有執行，也不能藉此判定當時的品質。我能說的只有：這份文件保留了哪些工作有完成紀錄，哪些沒有。

這個差異讓我把「完成」拆成兩層：Task 的進度回報，以及我看過程式、頁面和驗證結果後的確認。

我不需要把人工確認做回以前那種逐步下 prompt 的方式。AI 仍然幫我讀程式、實作和回填進度；我保留的是最後確認每一項是否符合需求的責任。

今天可以做的：替一個 Plan 寫最小 Task

選一個已經有 Plan、而且至少會碰到兩個工作面向的變更，例如改畫面同時要確認資料送出是否正確。

# Tasks｜功能名稱

## 實作
- [ ] T1：要修改的行為與主要檔案
  - 完成條件：

## 驗證
- [ ] T2：操作情境與預期結果
  - 證據：截圖、測試結果或可比較輸出

## 交付
- [ ] T3：要更新的文件／索引
  - 完成條件：

## 相依與停止點
- T2 需要等 T1 完成。
- 哪一項完成後需由人確認：

如果你已經使用 Claude Code，可以先讓它提出 Task 草稿，不要立刻改程式：

請讀取這份 Plan 與相關程式，將工作拆成可交接的 Tasks。
每個 Task 請列出：主要修改範圍、相依關係、完成條件與驗證方式。
資訊不足時列出待確認問題；暫時不要修改程式碼。

寫完後，問自己一個問題：每個 checkbox 旁邊，我能不能回答「我要看哪個程式、畫面或驗證結果，才算真的完成？」答不出來時，這個 Task 還只是待辦句子，還不夠交接。

小結：Task 是交接清單，不是完成宣告

Spec 讓需求有範圍，Plan 讓技術做法可以先被確認，Task 則讓後續工作不必靠記憶或臨時對話接力。我用 /speckit.tasks 產生 Task，讓 LLM 往下實作；每項勾選後，我仍會確認程式與頁面，必要時再請它補齊。

Task 文件同時留下已完成與未標記完成的工作。這點比「清單看起來完整」更重要，因為它讓我看見還少了什麼。可靠性不會因為多了一份 tasks.md 自動出現，還是要靠後面的驗證慢慢建立。

下一篇會接著談：Task 已經拆好了，AI 做 UI 時又要根據什麼資料交換規則工作？Day 09 會從 API、型別與 mock 開始，避免前端自己猜資料。

參考資料

• GitHub. Spec Kit.
• Anthropic. Building effective agents.