昨天讓 Codex 完成了 Issue Tracker 的第一個產品功能，也執行了測試、建置與人工操作。

今天不增加功能，而是回頭 Review add issue creation 這個 commit，從 diff 確認 Codex 實際改了什麼。

完成摘要和 diff 有什麼不同？

Codex 的完成摘要是它對工作的整理，通常會告訴我：

• 完成了哪些功能
• 修改了哪些檔案
• 執行了哪些驗證
• 還有哪些問題

摘要很適合快速掌握結果，但它仍然是對修改的描述。

Diff 則是兩個 Git 狀態之間真正發生的差異。新增了哪一行、刪除了哪一段、測試如何改變，都會直接顯示出來。

如果摘要說「加入表單驗證」，我仍然要從 diff 確認驗證條件、錯誤訊息與測試是否符合需求。

功能已經 commit，還能 Review 嗎？

可以。

昨天已經把功能建立成 commit，所以目前工作區可能沒有未提交變更。這時要比較的是該功能 commit 和它前一個 commit，而不是只看 working tree。

可以先用下面的指令確認目前最新 commit：

git show --stat --oneline HEAD

如果 HEAD 就是昨天的 add issue creation，審查範圍可以使用：

HEAD^..HEAD

如果後來又增加了其他 commit，就應該改用實際的起點與終點 commit hash，避免把無關修改一起放進來。

先看變更規模

進入每一行以前，我會先確認：

• 這次改了幾個檔案
• 哪些是功能程式、樣式與測試
• 有沒有修改套件或專案設定
• 新增與刪除的行數是否符合功能規模
• 是否出現不應提交的產物

「新增任務」是一個小功能。如果 diff 突然包含大量設定變更、套件更新或整份檔案重新格式化，就值得先停下來查明原因。

開一個新的 Codex 任務做 Review

我會另開一個 Codex 任務，讓 Review 不受昨天實作過程與完成摘要影響。

今天使用的 Prompt 是：

目標：
請審查 Issue Tracker 最新的「add issue creation」功能 commit。
先確認 HEAD 是否為該 commit；如果不是，請找出正確 commit，並說明實際審查範圍。

請比較功能 commit 與它的第一個 parent，只審查這次新增任務功能引入的差異。

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

請檢查：
- 每項修改是否能對應需求
- 是否出現範圍外行為或無關重構
- 驗證與錯誤狀態是否正確
- 是否有可能造成錯誤的邊界情境
- 測試是否真的覆蓋需求，而不只是讓元件成功 render
- 是否修改或提交了不必要的檔案

輸出規則：
- 只回報具體、可採取行動的問題
- 依「高、中、低」嚴重度排列
- 每項問題附上檔案與行號
- 說明觸發方式、實際影響與最小修正方向
- 不確定的內容要標示為推論
- 如果沒有發現問題，請直接說明

限制：
- 這次只做 Review，不要修改任何檔案
- 不要把範圍外的新功能當成缺陷

最後一條限制很重要。這次沒有實作編輯、刪除或資料保存，Reviewer 不能因為完整的 Issue Tracker 應該具備這些功能，就把它們全部列成 Bug。

這段 prompt 的回覆

人工 Review 的順序

收到 Codex 的結果後，我也會自己分四輪檢查。

第一輪：範圍

先看修改檔案清單，確認每個變更都屬於新增任務、必要樣式或測試。

第二輪：行為

逐項對照驗收條件，追蹤輸入內容如何被整理、驗證、加入狀態，再呈現在清單上。

特別注意錯誤狀態何時出現、何時清除，以及連續送出時會發生什麼事。

第三輪：測試

確認測試真的模擬使用者輸入與送出，而不是只檢查某段文字存在。

測試名稱、操作步驟與 assertion 應該能對應到需求，包括有效標題、前後空白、空白輸入、錯誤訊息與成功後清空。

第四輪：可維護性

最後才看命名、重複邏輯與複雜度。這一輪的重點不是追求最漂亮的架構，而是確認目前的小功能沒有被過度設計，也沒有把未來需求硬塞進來。

不要把所有建議都當成 Bug

Review 中常會混合三種內容：

• 正確性問題： 某種輸入會得到錯誤結果
• 需求缺漏： 已確定的驗收條件沒有完成
• 偏好建議： 另一種命名或寫法可能更漂亮

前兩種通常需要處理，第三種則要看是否違反 AGENTS.md、是否真的降低可讀性，以及修改成本。

如果只是個人偏好，又不影響行為與維護，就不必為了接受 AI 建議而製造額外 diff。

如果真的找到問題

今天的任務只做 Review，不直接修改。

確認 finding 成立後，可以先記錄重現方式與預期結果，下一個任務再要求 Codex 做最小修正並重新執行測試。

把「找問題」和「改程式」分開，可以避免 Reviewer 還沒有證明問題，就直接按照自己的猜測改變實作。

今日小結

今天用 commit diff 重新檢查了 Codex 昨天完成的新增任務功能。