測試把修改結果轉成可重複證據

Codex 完成程式修改後，可以立刻執行相關測試、讀取錯誤訊息並調整實作。

這段循環比單純閱讀程式多了一層執行證據。相同命令由另一位開發者或持續整合（Continuous Integration, CI）再次執行，也能確認結果是否一致。

測試會把輸入、操作與預期輸出寫成可執行案例。標籤統計功能若要求同一筆議題的重複標籤只計算一次，測試就能固定輸入資料與預期數量。

Codex 後續調整正規化或計數流程時，這個案例會繼續檢查原有規則。

測試能提供多少證據，取決於案例內容、執行環境與斷言。通過十個案例，代表這十個案例沒有發現違規行為。

需求是否寫對、案例是否涵蓋重要邊界、測試替身是否符合真實服務，仍需由開發者根據產品規則與系統背景判斷。

Codex 可以執行測試與整理失敗線索

Codex 適合處理可重複的驗證工作。它可以先執行單一案例重現問題，再跑模組測試、完整測試、Lint、Type Check 與 Build。

每次執行都應保留完整命令、結束狀態、通過與失敗數量，以及第一個有判斷價值的錯誤。

測試失敗時，Codex 可以沿著堆疊、預期值、實際值與相關程式找出候選原因。例如 " bug " 沒有被計入 bug，線索可能指向字串正規化，也可能是測試資料沒有走到統計函式。代理人可以提出假設，再用更小的測試或唯讀追蹤確認。

Codex 程式碼審查（Code Review）也能在測試完成後檢查未提交差異。/review 會閱讀選定範圍並回報問題，不會直接修改工作目錄。

測試輸出與審查結果可以互相補充，開發者仍要回到需求、差異與實際命令確認結論。

同一個代理人容易把錯誤一路帶進測試

Codex 同時解讀需求、設計實作、撰寫測試與判定完成時，前面產生的錯誤假設可能出現在後面每一層。

若把「標籤前後空白要忽略」理解成「含有空白的標籤全部忽略」，就可能寫出符合錯誤理解的實作與測試，最後得到一路的綠燈。

另一種風險出現在修復失敗測試時。當既有實作回傳 0、驗收條件要求 1，修改期待值可以讓測試立刻通過。任務若只要求「把測試修到通過」，Codex 可能把測試、實作或兩者都視為可調整範圍，綠燈便失去原先的保護意義。

任務開始前要先固定判斷依據，包括需求範例、公開契約、已確認的測試及不可修改範圍。

Codex 可以建立候選測試，開發者應先審查輸入與期待值，再允許代理人修改產品程式。測試受到同一份錯誤假設影響時，外部依據才能指出偏差。

先由人確認本次驗收案例

今天我們沿用 codex-hands-on 的四種標籤統計。新增規則很明確：比對標籤名稱前，先移除字串前後空白；" bug " 要計入 bug，" SECURITY " 要計入 security。既有的不分大小寫、重複標籤去重、零值輸出與排名行為都要保留。

開始修改前，開發者先確認三個案例。第一個案例使用 " bug "，預期 bug 為 1。第二個案例使用 " SECURITY "，預期 security 為 1。第三個案例使用只含空白的字串，四種目標標籤都維持 0。這些期待值是本次外部判斷依據，Codex 不得為了通過測試而更改。

先要求 Codex 只新增或調整直接相關測試，這一輪禁止修改 src/。開發者閱讀差異，確認案例資料、期待值與測試名稱都符合上述規則，再允許進入實作。

測試在修改產品程式前已全部通過時，要先確認功能是否已存在，以及測試是否真的走到正式統計路徑。

先建立會失敗的驗收測試

使用先前的 test-task Profile 啟動 Codex，讀取 AGENTS.md 與標籤統計相關測試。

以下提示詞（Prompt）將測試與實作拆成兩個停止點，第一輪只建立可由人審查的失敗證據。

請先讀取 AGENTS.md、標籤統計實作與直接相關測試。

本次新增規則：比對標籤前先移除字串前後空白。
「 bug 」應計入 bug，「 SECURITY 」應計入 security，只含空白的標籤不計入四種目標標籤。

第一輪只修改直接相關的 test/ 檔案，加入上述三個案例。
保留既有大小寫、重複標籤去重、零值與排名測試。
不得修改 src/、fixture、README、套件與設定，也不得降低或刪除既有斷言。

完成後執行直接相關測試，顯示測試差異、實際命令與失敗結果，再停止等待我確認。這一輪不要讓新測試通過，也不要修改期待值。

審查測試差異時，先確認三個輸入沒有被測試輔助函式提前清理。建立測試資料時若已先執行 trim()，測試只會證明輔助函式有效，沒有驗證產品程式。也要確認斷言讀取四種標籤的實際統計輸出，避免只測到中間變數。

確認測試後才修改產品程式

開發者接受測試差異與失敗原因後，再要求 Codex 修改 src/。這一輪要鎖定測試檔案，讓失敗案例保持原樣。

代理人只能在標籤正規化的直接路徑中完成小幅修改，不能順便調整輸出格式或重構排名流程。

我已確認剛才三個測試案例與期待值。現在只修改直接相關的 src/ 實作，讓標籤比對前移除前後空白，並保留大小寫不敏感與單一議題內去重行為。

不得修改、刪除、略過或放寬任何測試，也不得針對固定測試資料寫特殊判斷。
先執行三個新案例，再執行標籤統計模組的相關測試。

局部測試通過後，依 AGENTS.md 執行 Formatter 檢查、Lint、Type Check、Build 與完整 Test。未提供或無法執行的項目要如實記錄。

最後顯示 git status、完整差異、每條命令與結果，等待人工判斷。
不要建立 commit，也不要宣告變更已可合併。

Codex 若發現既有測試互相衝突，應停下來列出衝突的需求與路徑。它不能自行挑選較容易通過的一方，也不能用跳過測試、刪除案例或放寬斷言處理。這類衝突需要產品規則或維護者決定。

相關測試與全域檢查回答不同問題

三個新案例通過，表示空白正規化符合本次驗收條件。標籤統計模組測試通過，可以增加大小寫、去重、零值與排名行為維持不變的信心。完整 Test 則檢查命令列入口及其他模組是否受到影響。

Lint、Type Check 與 Build 驗證的面向不同。Lint 找出規則與可疑語法，Type Check 檢查資料型別，Build 確認專案可以完成編譯或打包。

這些檢查全部成功，也不代表需求案例已完整；它們提供不同種類的證據，應在完成紀錄中分開呈現。

持續整合會在另一個環境重新執行團隊設定的檢查，可以發現本機版本、平台或快取造成的差異。持續整合的結果是綠燈，仍需確認執行的是目前提交、必要工作沒有被條件跳過，且失敗步驟沒有設定為可忽略。開發者應檢查工作名稱、日誌與提交雜湊，再採用該次結果。

測試通過後仍要閱讀差異

測試只能觀察案例設定的輸入與輸出。Codex 可能加入過度寬鬆的 trim()，改變原本應保留空白的其他欄位。也可能在整份資料輸入階段修改標籤，影響後續輸出與除錯資訊。

測試未涵蓋這些行為時，完整綠燈不會主動指出設計範圍擴大。

執行 /review 時，可以指定檢查正規化位置、重複標籤去重順序、非字串標籤與未預期資料變更。審查結果要附上路徑與具體行為，開發者再回到差異確認。沒有證據的推測可以保留為待確認項目，不需要直接修改程式。

最後閱讀 git diff，確認測試期待值和人工確認版本相同，產品修改位於正確責任層，也沒有混入套件、設定與文件變更。任何測試刪除、跳過標記、覆蓋率排除或斷言弱化，都要先說明原因並重新取得確認。

由開發者填寫驗證判斷表

Codex 完成命令紀錄後，開發者依實際輸出填寫以下判斷表。

表中的「是否接受」由人決定，Codex 可以協助整理證據與指出缺口，不代填最終結論。無法確認的項目應寫「待確認」，保留需要補做的工作。

判斷表全部有證據，也不代表必須接受變更。若關鍵風險仍未覆蓋、持續整合尚未完成，或差異中存在無法解釋的修改，可以將結論標為「暫不接受」，並寫下補測試、縮小差異或請熟悉模組的人審查等下一步。

綠燈是證據的一部分

Codex 可以快速建立測試、反覆執行命令並整理大量輸出，這些能力能降低驗證工作的操作成本。

開發者負責確認測試依據、接受標準與剩餘風險，並決定目前證據是否足以讓變更進入下一個流程。

同一個代理人負責修改與測試時，任務要保留幾個清楚停止點。人先確認驗收案例，Codex 再修改實作。

局部測試通過後執行全域檢查，最後閱讀差異並填寫判斷表。這些停止點能讓錯誤假設較早被看見，也避免測試綠燈直接變成接受決定。

完成紀錄應保留失敗過程、實際命令、通過範圍與未驗證項目。後續若出現回歸，團隊可以回頭確認當時驗證了什麼、哪個風險尚未覆蓋，以及接受變更時使用了哪些依據。