昨天替 Issue Tracker 建立了 AGENTS.md，讓 Codex 每次進入 repository 時，都能先取得相同的專案規則。

今天終於要準備第一個產品功能：「新增任務」。

不過這一篇仍然不寫程式。我會先請 Codex 閱讀需求與現有專案，提出一份可以檢查的實作計畫。

為什麼要先規劃？

直接要求 Codex「幫我做新增任務」當然也可能成功，但我通常要等它改完，才會知道它如何理解需求。

如果它誤會了資料欄位、修改了不必要的設定，或自行加入 PRD 沒有要求的功能，這些問題都要在程式完成後才能被發現。

先規劃的目的，是在修改發生以前確認：

• 它理解的需求是否正確
• 準備修改哪些檔案
• 使用者操作會經過什麼資料流
• 測試會如何對應驗收條件
• 有哪些假設、風險或問題尚未決定

修改一份計畫的成本，通常比修改一大段已經寫好的程式低。

先固定今天的功能範圍

這次的「新增任務」只包含：

• 使用者可以輸入任務標題
• 送出後，任務會出現在清單中
• 標題前後的空白不應成為內容
• 空白標題不能建立任務
• 驗證失敗時要顯示可理解的訊息
• 成功新增後要清空輸入欄位
• 加入對應的自動化測試

這次不處理：

• 編輯與刪除任務
• 搜尋、篩選與排序
• 拖曳改變順序
• 後端、資料庫與登入
• 和新增任務無關的重構

至於資料是否要在重新整理後保留，如果目前需求或程式還不能明確回答，就應該先列為待確認問題，而不是讓 Codex 自行決定。

今天使用的 Prompt

我會在 Issue Tracker repository 中開啟一個新的 Codex 任務，輸入：

目標：
請根據目前的 Issue Tracker repository，規劃「新增任務」功能。
這次只做分析與規劃，不要修改任何檔案。

驗收條件：
1. 使用者可以輸入任務標題
2. 送出後，新任務會顯示在任務清單中
3. 標題前後的空白要移除
4. 空白標題不得建立任務
5. 驗證失敗時要顯示可理解的訊息
6. 成功新增後要清空輸入欄位
7. 必須加入對應的自動化測試

不做事項：
- 不實作編輯、刪除、搜尋、篩選、排序或拖曳
- 不加入後端、資料庫、登入或雲端服務
- 不進行和本功能無關的重構
- 不新增正式環境套件，除非先說明必要性並取得同意

請先閱讀 AGENTS.md、README、package.json、現有原始碼與測試，再提供：
1. 現有行為與可沿用的結構
2. 預計新增或修改的檔案，以及每個檔案的責任
3. 從輸入、驗證、建立資料到畫面更新的資料流
4. 依照實作順序排列的步驟
5. 每項驗收條件對應的測試
6. 風險、假設與仍待我確認的問題

每項判斷都附上實際檔案路徑作為依據。
找不到證據時請直接說明，不要猜測目前不存在的架構。

這次刻意沒有要求 Codex 把計畫寫入檔案，因為任務的限制是「不要修改任何檔案」。計畫可以先留在對話中，等確認後再進入實作。

這段 prompt 的回覆

怎麼 Review Codex 的計畫？

Codex 產生計畫後，要依序檢查四件事。

1. 檔案真的存在嗎？

計畫引用的現有檔案應該能在 repository 中找到。如果它提到不存在的 service、API 或資料庫，就代表計畫沒有建立在目前專案上。

預計新增的檔案則要有明確理由。專案還很小時，不一定需要為一個表單建立很多抽象層。

2. 每一步都對應需求嗎？

計畫中的修改應該能回到某個驗收條件。如果出現動畫、路由、狀態管理套件或視覺重設計，就要確認是否真的屬於今天的範圍。

3. 測試有驗證行為嗎？

只測試元件成功 render，不能證明新增任務功能正確。

測試至少應涵蓋：

• 輸入有效標題後能新增任務
• 標題前後空白會被移除
• 空白標題不會建立任務
• 驗證失敗會顯示訊息
• 成功後輸入欄位會清空

4. 假設有沒有被藏起來？

任務 ID 如何產生、初始狀態是什麼，以及是否立即保存到瀏覽器，都可能影響實作。

如果現有需求沒有答案，計畫應該主動列出問題，而不是把其中一種做法當成已經確定。

用追問修正計畫

如果第一版計畫有問題，不需要整段 Prompt 重來，可以直接指出具體落差：

請更新剛才的計畫，但仍然不要修改檔案：

1. 移除和新增任務無關的樣式重構
2. 補上空白標題與去除前後空白的測試
3. 說明任務 ID 的產生方式是否需要我決定
4. 將每個實作步驟對應到驗收條件

請輸出更新後的完整計畫，不要只列出差異。

請它重新輸出完整計畫，是為了讓明天實作時只有一份有效版本，不必在多段對話中拼湊最後決定。

今日小結

今天沒有讓 Codex 直接實作「新增任務」，而是先用現有 repository、AGENTS.md 與驗收條件產生一份可以人工審查的計畫。