今天開始把工作從討論移到程式修改。我選的第一個任務是「新增任務時拒絕空白標題」。它夠小，卻同時需要釐清輸入、錯誤回饋與資料保存；如果連這個任務都無法清楚驗收，後面跨檔案功能只會更難判斷。

先寫明確的完成條件

使用者輸入正常標題後，任務成功出現在清單。輸入空字串或只含空白時，表單顯示可理解的錯誤訊息，資料庫不新增紀錄。標題前後的空白要不要保留，先由 PRD 決定；本次採「儲存前裁掉前後空白」。無論前端是否攔住，伺服器端都必須驗證，避免直接送請求時產生無效資料。

任務範圍限於新增流程的必要檔案與相關測試。不重寫整個表單、不順手更換 UI 套件、不變更資料表欄位。這些限制的目的不是束縛 Codex，而是讓每一次修改都能單獨審查、回復與比較。

交給 Codex 的原始任務描述

「請先閱讀任務新增流程與相關測試。實作標題 trim 後不可為空的驗證：前端給出清楚回饋，伺服器端拒絕無效請求，成功路徑維持原有行為。只修改必要檔案。完成後執行與新增流程最相關的測試，列出修改檔案、測試指令與結果；若環境無法執行，說明原因，不要編造通過結果。」

這份描述把目標、邊界、驗收與證據放在一起。實際執行時，我會保留完整 Prompt，不在文章裡事後把它修得像完美指令；若中途補充限制，也要記錄是第幾輪才補的。否則讀者無法判斷成功來自第一輪理解，還是來自人工一路提示。

測試不只證明它會擋錯

最容易漏掉的，是正常輸入的回歸。若驗證函式把所有標題都判為無效，空白案例會通過，功能卻完全壞了。因此正向案例和反向案例要成對出現。另一個常見缺口是只測 UI 元件：它看起來拒絕純空格，但有人直接對伺服器送出請求時仍能寫入資料。這也是為什麼我把伺服器驗證列為驗收的一部分。

測試失敗時，我會先判斷是預期行為寫錯、測試環境不完整，還是實作有問題，不要求 Codex 為了讓指令變綠而刪掉測試。若它說「無法執行」，應交代卡在哪個步驟，以及我下一步能怎麼重現；這比一個沒有輸出的「測試通過」更有價值。

我會怎麼檢查它交回的工作

先看 diff：有沒有改到不相關檔案？驗證是否同時落在使用者回饋與伺服器入口？錯誤訊息是否能幫人修正輸入？再看測試：空字串、純空格、正常標題、前後空白與直接呼叫伺服器端的情況是否覆蓋。最後手動操作一次，因為測試通過不保證畫面上的錯誤位置與時機合理。

若 Codex 只在前端加上 disabled 按鈕，卻沒保護伺服器，我會判定未達驗收；若伺服器有擋，但畫面沒有可讀提示，也仍未完成。這是一個具體的「兩層都要對」案例，能避免只因 Demo 看起來正常就過關。

今天的結果與限制

本文先建立完整的首個 Feature 任務與審查標準。因為目前尚無可操作的 Repository，沒有真實 diff、測試次數或成功率；上述情境是驗收案例，不是已通過的實測。實作完成後，才會在此記錄 Codex 是否一次做對、修改了幾輪，以及我修正了什麼。

今天學到什麼？

交付小功能的關鍵不是任務夠簡單，而是「做完」有共同定義。下一篇我會用同類型的任務比較不同 Prompt，看看明確描述是否真的改變結果。