Codex 可以閱讀程式，並推論修改是否合理，但這種判斷會缺少執行證據。
匯入路徑寫錯、型別不符、格式規則違反或測試行為改變，都要透過專案工具執行後才會出現在輸出中。只留下「程式看起來可以運作」，無法說明目前版本是否通過團隊既有檢查。
建置（Build）、測試（Test）、程式碼檢查（Lint）、格式化工具（Formatter）與型別檢查（Type Check）各自檢查不同範圍。
Codex 需要知道專案實際使用的命令、執行位置、適用檔案與成功條件，修改後才能產生可核對的結果。
完成修改後應執行 Lint 與範圍較小的相關測試，並回報命令和結果。今天我們會先從 codex-hands-on 的現有設定找出五類工具，再把確認過的命令寫入 AGENTS.md，最後用一個小修正走完整套驗證流程。
Build 會把原始碼編譯、打包或轉換成可執行產物，可用來找出模組無法載入、編譯失敗及建置設定錯誤。沒有獨立建置步驟的腳本專案，也應在規則中標示「未提供」，避免 Codex 自行猜測專案該如何建置。
Test 會執行已定義的行為案例。修改標籤統計時，相關單元測試能快速檢查重複標籤。完整測試用來觀察其他命令列行為是否受到影響。測試通過代表已寫出的案例成立，未涵蓋的需求還需要差異審查及其他驗證。
Lint 會檢查未使用變數、可疑語法與團隊編碼規則。Formatter 負責統一縮排、換行及標點格式，除了檢查即有程式碼外，亦可直接重寫檔案。Type Check 會依型別宣告找出不相容的資料流。這三項都要使用專案既有設定，不能臨時套用另一組預設規則。
先讓 Codex 讀取根目錄的 AGENTS.md、package.json、鎖定檔與工具設定。Node.js 專案的命令多半位於 package.json 的 scripts，Lint、Formatter 與 Type Check 也可能在各自設定檔中指定適用目錄。
持續整合（Continuous Integration, CI）設定可以用來核對團隊實際執行哪些檢查。
請只讀取專案，找出正式使用的 Build、Test、Lint、Formatter 與 Type Check 命令。
先檢查 AGENTS.md、package.json、鎖定檔、工具設定與 CI 設定，為每一類列出：完整命令、執行目錄、是否會修改檔案、依據路徑。
專案沒有提供的類別請標示「未提供」，不要自行安裝工具、建立 script、執行命令或修改檔案。若 README、package.json 與 CI 記載不同，列出衝突等待確認。
命令名稱不能只靠常見慣例推測。npm test、npm run test 與 npm run test:unit 可能執行不同範圍。npm run format 也可能直接改寫整個儲存庫。
Codex 應引用實際檔案位置，並說明哪一條命令適合局部驗證，哪一條是完整檢查。
完成唯讀盤點後，抽查每條命令是否存在於 package.json 或專案文件。接著要求 Codex 只更新根目錄 AGENTS.md，新增 ## 專案工具與驗證順序。
實際命令要使用盤點結果替換，沒有提供的工具保留「未提供」，不要補上虛構指令。
## 專案工具與驗證順序
**套件安裝：** 填入專案既有命令。安裝或更新相依套件前需人工批准。
**Formatter：** 填入檢查命令及只格式化指定檔案的命令；未提供時寫「未提供」。不得未經確認格式化整個儲存庫。
**Lint：** 填入專案既有命令；未提供時寫「未提供」。
**Type Check：** 填入專案既有命令；未提供時寫「未提供」。
**Build：** 填入專案既有命令；未提供時寫「未提供」。
**Test：** 填入單一測試、相關測試與完整測試命令。無法縮小範圍時，明確記錄只能執行完整測試。
**驗證順序：** 修改期間先執行直接相關測試。完成修改後依序執行 Formatter 檢查、Lint、Type Check、Build 與完整 Test；「未提供」的項目跳過並記錄。
**結果紀錄：** 回報每條實際命令、結束狀態、通過與失敗數量、關鍵錯誤及未執行原因。不得將未執行項目描述為通過。
今天我們只新增這個章節，不改動前面建立的權限與 Sandbox 規則。
完成後執行 git diff -- AGENTS.md，確認命令和盤點結果一致，也確認 Formatter 的「檢查」與「寫入」模式已分開記錄。
Build 可能建立 dist/、build/ 或快取，Formatter 可能改寫檔案，Test 也可能產生覆蓋率報告與暫存資料。
Codex 執行前應先說明預計新增或改變的路徑，並確認這些產物是否已列入 .gitignore。會下載套件、啟動容器或連線服務的命令，要依權限規則等待批准。
Formatter 很容易製造大量無關差異。若專案提供 format:check，應先使用檢查模式。需要修正格式時，只處理本次修改的檔案，再重新查看 git diff。只提供全專案寫入模式時，先回報預計影響範圍，取得確認後再執行。
測試命令也要確認資料來源。單元測試應使用既有 Fixture 或測試資料，不讀取正式資料與正式憑證。若命令需要未啟動的資料庫、瀏覽器或外部服務，Codex 要保留錯誤輸出並說明環境缺口，不能改測試來掩蓋執行條件。
本篇的小問題承接前一篇新增的測試。當同一筆議題的 labels 為 bug、bug、security 時，輸出應將 bug 計算一次，security 也計算一次。
Codex 只調整標籤統計的直接實作，不修改輸出格式、排名規則及其他標籤行為。
使用之前建立的 test-task Profile 啟動 Codex，再貼上以下的提示詞（Prompt）。若上一輪測試尚未保留在工作目錄，先依專案紀錄確認測試已存在，避免 Codex 同時重寫測試與實作。
請先讀取 AGENTS.md、重複標籤測試與標籤統計實作，重現目前的失敗。
修正同一筆議題中的相同目標標籤被重複計數：
labels 為 bug、bug、security 時，bug 計算 1 次，security 計算 1 次。
只修改直接相關的 src/ 實作。保留既有輸出格式、標籤大小寫處理、排名規則及其他測試行為。不修改測試、fixture、README、套件、設定與部署檔案。
修改期間先執行直接相關測試。完成後依 AGENTS.md 記錄的順序執行 Formatter 檢查、Lint、Type Check、Build 與完整 Test。
未提供的工具直接記錄，不要自行安裝或新增 script。
最後顯示 git status、git diff、每條實際命令及結果，並列出失敗與未執行項目。不要建立 commit。
Codex 應先執行失敗測試，保留修正前證據，再進行小範圍修改。
若測試原先就通過，代表重複計數問題已不存在，或測試沒有打到預期路徑。這時應停止並重新檢查測試資料與呼叫路徑。
直接相關測試能縮短修改回饋時間。Codex 修正統計邏輯後，先重跑重複標籤案例，再執行標籤統計所在模組的測試。
失敗訊息要保留測試名稱、預期值、實際值與結束狀態，方便判斷錯誤位於資料整理或計數流程。
局部測試通過後，檢查 git diff --stat 與完整差異。變更應集中在直接實作，沒有混入測試調整、重新命名或大量格式化。
若 Formatter 已經改到其他檔案，先找出命令模式及影響範圍，保留任務相關修改，再依 Git 安全策略處理額外差異。
這一輪檢查能縮短修改回饋時間，不能取代完整驗證。模組測試只涵蓋局部行為，命令列整合、輸出格式及其他排名案例還需要後續 Test、Build 及靜態檢查確認。
修改內容穩定後，依 AGENTS.md 的順序執行 Formatter 檢查、Lint、Type Check、Build 與完整 Test。
固定順序能讓每次任務的紀錄方便比較。我們可以先處理格式與靜態問題，再確認型別及建置，最後以完整測試檢查行為。
遇到「未提供」的工具時，Codex 應跳過並記錄專案缺少該項命令。遇到命令不存在、相依套件缺少或環境未準備完成時，結果要記為「未完成」或「失敗」，並附上原始錯誤摘要。
不應讓 Codex 自行增加套件、修改 script 或把失敗命令換成較寬鬆參數。
若某項檢查失敗，先判斷是否由本次差異造成。修正內容後，要重新執行直接失敗的命令，並重新跑受影響的後續檢查。
先前的成功結果若已受到新修改影響，也要重新驗證，避免拿修改前的綠燈當成最後證據。
最後的完成紀錄要讓另一位開發者能看出 Codex 做了什麼、實際驗證到哪裡。
每一項工具都要附上完整命令與結果，成功時記錄通過數量或結束狀態，失敗時保留第一個關鍵錯誤，未執行時則寫明原因。
修改範圍：填入實際檔案
行為結果：重複目標標籤在單一議題中只計算一次
相關測試：填入命令與通過／失敗結果
Formatter：填入命令與結果；未提供則明確標示
Lint：填入命令與結果；未提供則明確標示
Type Check：填入命令與結果；未提供則明確標示
Build：填入命令與結果；未提供則明確標示
完整 Test：填入命令、通過數量與失敗數量
未驗證項目：填入項目與原因；沒有則寫「無」
工作目錄狀態：摘要 git status 與差異範圍
開發者接著抽查命令是否來自 AGENTS.md、輸出是否對應同一次修改，以及差異是否維持預定範圍。
工具全部通過能提供明確的自動化證據，需求規則與修改方式還要透過差異審查確認。若存在未驗證項目，任務狀態也要如實保留，交由具備所需環境的人補做。
iThome鐵人賽
看影片追技術