前面已經讓 Codex 閱讀 GitHub 上的儲存庫，並整理專案用途、主要模組、測試位置與可執行命令。這份「專案理解摘要」可以幫助開發者認識程式碼，也能作為判斷任務範圍的起點。
同一個專案裡，有些工作可以直接交給 Codex，有些需要先取得人工批准，另一些則應由具備相應責任與權限的人員處理。
適合交給 Codex 的任務，通常具有清楚的修改範圍、可檢查的產出與可重複的驗證方式。
解釋一段程式、修正說明文件、補上既有函式的單元測試、處理格式問題，以及調整局部命名，都可以透過檔案差異或測試結果確認成果。結果不符合預期時，開發者也能捨棄變更，回到任務開始前的狀態。
判斷時可以先檢查四項條件：Codex 會接觸哪些檔案與系統、成果要如何驗證、失敗後能否安全回復，以及工作是否會影響正式環境。
修改範圍、驗證方式與回復方法越明確，任務就越容易控制。權限、沙盒（Sandbox）與網路存取則構成不同的安全邊界，用來限制代理人可以接觸的檔案、命令與外部資源。
就算任務名稱看起來很小，仍要確認實際影響範圍。「修改一行設定」可能改變正式環境的付款流程，風險會高於新增一個隔離的測試檔案。「更新相依套件」也可能連帶改變大量間接套件與執行行為。任務分類應依照實際影響、驗證方式與回復條件判斷，不能只看修改行數。
程式理解很適合作為 Codex 的起點。它可以沿著函式呼叫、模組引用與測試檔案整理功能路徑，協助開發者縮小閱讀範圍。
文件更新、局部程式修正、測試草稿與小範圍重構也有明確產出，開發者可以直接查看檔案差異，再透過既有工具確認格式、型別與測試結果。
適合的任務仍需要寫清楚完成條件。「幫忙改善這個專案」沒有指定工作範圍，Codex 就必須自行判斷改善方向。「修正 README.md 中已失效的啟動命令，依照 package.json 核對內容，不修改其他檔案」則提供了目標、依據與限制。這樣的描述能讓 Codex 知道需要查看哪些資料，也方便開發者快速核對結果。
Codex Cloud 會在隔離環境中取出指定的儲存庫與分支，任務完成後提供工作摘要與檔案差異。開發者可以檢查結果、要求後續調整，再決定是否建立拉取請求（Pull Request）。這類流程適合能在分支中完成、可透過差異審查，且不需要存取正式資料的工作。
測試通過只能證明已執行的已知案例得到預期結果，未寫入測試的業務規則仍需要另外確認。Codex 產生的文件、程式與測試都屬於候選成果。開發者需要確認需求是否被正確理解、測試是否涵蓋重要情境，以及修改內容是否符合專案規則。
任務一旦涉及正式資料、帳號權限、外部服務費用、部署流程或敏感憑證，代理人的一次操作就可能產生難以回復的結果。
這類工作可以先請 Codex 分析影響、整理執行計畫或產生草稿。實際執行前，需要由負責人核對目標、範圍與回復方式。每次批准都應對應明確動作，避免一次開放過大的權限。
資料庫結構變更、相依套件升級與登入權限調整，常屬於「需人工批准」的任務。Codex 可以先在隔離環境中準備修改與測試，合併或套用前再檢查資料相容性、安全影響與部署順序。
沙盒（Sandbox）用來限制 Codex 能接觸的資源，批准機制則控制哪些動作必須先停下來等待人員同意。批准範圍應限制在完成當前任務所需的最小權限，避免直接使用 Bypass 模式開放所有指令。
刪除正式客戶資料、直接發布到正式環境、變更付款帳戶，以及建立或擴大管理員權限，應由具備正式職責的人員執行。這些操作涉及組織授權、法規要求與責任歸屬，判斷依據也超出程式碼差異與測試結果。
Codex 可以協助整理檢查清單、模擬操作步驟與產生操作草稿，正式執行仍應納入既有的審批與稽核流程。
網路存取也要納入任務分類。Codex Cloud 的代理人工作階段預設是封鎖網路存取。在開放網路後，提示注入、程式碼或祕密外洩，以及下載惡意套件等風險都需要納入評估。需要查詢外部網站或下載相依套件時，應限制可連線的網域與存取方式，並且在完成後檢查相關的工作紀錄。
本篇沿用前面的 Codex Cloud 任務與儲存庫內容。這次仍維持唯讀，不可修改檔案、安裝套件或執行專案指令。讓 Codex 根據先前已查看的文件、設定與程式碼，提出 10 個與專案相關的候選開發任務。
請在原有任務對話中輸入以下提示詞：
請根據儲存庫現有內容，列出 10 個具體的候選開發任務，並整理成「Codex 任務分類表」。分類只能使用「可交給 Codex」、「需人工批准」與「不可交給 Codex」。每個任務都要說明修改範圍、驗證方式、失敗後的回復方法、是否接觸正式環境或高權限操作，以及最後的分類理由。請勿修改檔案、安裝套件或執行專案指令。每項判斷須附上相關檔案路徑；儲存庫沒有提供的資訊請標示為「待確認」，不要自行補充。
完成後，表格應包含任務、依據檔案、修改範圍、驗證方式、回復方法、環境與權限風險、分類及理由。10 個任務需要涵蓋程式理解、文件更新、局部修正、補測試、重構、相依套件、資料庫、權限、正式資料與部署等情境。若專案缺少其中一類內容，Codex 應標示「待確認」，不需要自行虛構檔案、服務或操作流程。
分類完成後，開發者需要逐項核對 Codex 提供的檔案依據。「可交給 Codex」的任務應有明確邊界、驗證方式與回復方法；「需人工批准」的任務還要指出批准發生的時間點，以及由哪個角色負責確認；「不可交給 Codex」的任務則要說明涉及哪些正式責任、權限或難以回復的影響。若分類理由只寫成「風險很高」這類概括描述，仍不足以支援後續判斷。
Codex 能否執行某個動作，只能說明工具具備相應能力。任務是否適合交付，仍要根據修改範圍、驗證證據、回復成本、正式環境影響與權限責任判斷。
以下分類是依照目前儲存庫中可觀察到的程式碼、測試與設定所做的候選任務風險分類：
儲存庫沒有提供組織層級的 Codex 使用政策、正式環境定義、部署權限模型或資料敏感度規範。因此，下表中相關資訊均明確標為「待確認」，而不是假設既有環境或權限。
| # | 候選開發任務 | 修改範圍 | 驗證方式 | 失敗後的回復方法 | 正式環境／高權限 | 分類 | 分類理由 |
|---|---|---|---|---|---|---|---|
| 1 | 補齊所有輸入欄位的驗證測試 | 在 tests/triage.test.ts 增加空白 title、不支援的 severity、負數或非有限數值，以及非布林 hasWorkaround 的案例；原則上不必修改正式程式碼。現有驗證分支位於 src/domain/issue.ts。 |
執行 npm test，確認新增案例通過且既有 5 個測試不回歸。測試 script 已設定為 vitest run。 |
放棄或還原新增的測試提交；此任務沒有資料遷移或外部狀態。 | 否；只修改本機測試。 | 可交給 Codex | 驗證規則已由程式碼明確定義，但目前測試只覆蓋非陣列及空 ID，缺少其他既有分支的測試。 |
| 2 | 補齊優先標籤邊界值測試 | 在 tests/triage.test.ts 增加分數位於 35、65、90 邊界及其相鄰值的測試；如需直接測試標籤函式，可改以能產生相應分數的 issue 測試公開的 rankIssues。標籤門檻位於 triage service。 |
執行 npm test，確認 monitor、schedule、expedite、interrupt 四種結果及邊界行為。 |
還原新增測試；若測試揭露現有行為與期望不一致，先停止，不自行改變門檻。 | 否。 | 可交給 Codex | 任務只把現有明確門檻固化成回歸測試，不改變產品規則；現有測試只個別檢查了部分標籤。 |
| 3 | 補齊分數公式上限及 workaround 扣分測試 | 在 tests/triage.test.ts 新增受影響人數分數最高 30、等待天數分數最高 20、workaround 扣 15 分及四捨五入行為的案例。 |
執行 npm test；用公開的 rankIssues 檢查輸出的 priorityScore，並執行 npm run check 驗證型別。 |
還原測試提交；若測試與現有公式不符，先將結果交由人工判斷，不逕自修改公式。 | 否。 | 可交給 Codex | 評分公式已完整存在於程式碼中，任務可在不重新定義需求的前提下增加測試保護。 |
| 4 | 消除同一 issue 重複計算優先分數 | 修改 src/services/triage.ts 的 rankIssues，讓每個 issue 只呼叫一次 calculatePriorityScore，再將同一結果用於 priorityScore 和 priorityLabel。目前每筆 issue 會呼叫兩次。 |
執行 npm test、npm run check，並以現有範例執行 npm run dev -- ./examples/issues.json，確認排序、標籤和輸出不變。這些命令皆有既有設定或文件依據。 |
還原該重構提交；沒有資料格式變更或���久化狀態需要回復。 | 否。 | 可交給 Codex | 這是範圍小且預期保持行為不變的內部重構，現有排序、摘要與格式化測試可提供基本回歸保護。 |
| 5 | 新增 CLI 層的自動化測試 | 新增 CLI 測試檔，例如 tests/cli.test.ts，涵蓋有效 JSON、未提供路徑、無效 JSON、無效 issue 及空陣列；必要時小幅重構 src/cli.ts，把主流程抽成可測試函式，同時保留命令列進入點。 |
執行 npm test 與 npm run check；測試應確認標準輸出、標準錯誤及非零結束碼。現有 CLI 已明確定義缺少參數及錯誤處理行為。 |
還原新測試及 CLI 重構；保留原本 main().catch(...) 流程。 |
否；測試使用本機暫存檔即可。是否允許衍生程序則屬執行環境細節，待確認。 | 可交給 Codex | CLI 行為和輸入格式已由程式碼與 README 定義，且任務可使用隔離的本機測試資料，不需要外部服務。 |
| 6 | 將測試編譯產物與應用程式建置產物分離 | 調整 tsconfig.json，或新增專用的 build tsconfig，使正式建置只輸出 src，測試仍由型別檢查涵蓋。目前 rootDir 是專案根目錄，且 include 同時包含 src 與 tests。 |
執行 npm run build、npm run check 和 npm test；檢查 dist 的實際檔案清單是否符合人工批准的預期。dist/ 已被 Git 忽略。 |
還原 tsconfig 與 script 變更，刪除本機 dist/ 後重新執行原建置。是否有已發布產物需要回復為待確認。 |
本機建置不需高權限；是否會影響正式發布流程為待確認，因儲存庫沒有部署設定。 | 需人工批准 | 這會改變建置產物布局；儲存庫沒有說明 dist 的消費者、發布方式或正式環境啟動方式，因此應先由人工確認期望產物。 |
| 7 | 調整嚴重程度權重或優先標籤門檻 | 修改 severityWeights、分數公式或 labelPriority 門檻，並同步更新測試和文件。 |
先由人工提供具體的新規則及代表性案例，再執行 npm test、npm run check，並用 examples/issues.json 比較調整前後排序。 |
還原公式、門檻、測試和文件提交；若新排序已被外部流程採用，外部回復方式為待確認。 | 原始碼修改本身不需高權限；是否影響正式 triage 決策或正式環境為待確認。 | 需人工批准 | 權重和門檻會直接改變「應該先處理哪些 issue」的產品／營運決策，不能只由 Codex 根據技術判斷重新定義。專案用途明確依賴這些排序結果。 |
| 8 | 升級 TypeScript、Vitest、tsx 或 Node.js 型別套件 | 修改 package.json 中的 devDependencies 及 package-lock.json；可能也需調整 TypeScript 或測試設定。現有版本範圍列於 package.json。 |
在人工允許使用套件 registry 後執行乾淨安裝，再執行 npm test、npm run check、npm run build 和範例 CLI。Node.js 最低版本目前是 20。 |
還原 package.json 與 package-lock.json，刪除本機 node_modules/，按舊 lockfile 重建；外部套件快取的處理方式為待確認。 |
需存取外部套件來源；是否使用公司 registry、憑證或受控網路為待確認。 | 需人工批准 | 相依升級涉及供應鏈、相容性及 lockfile 大量變更；儲存庫沒有依賴更新政策或核准流程，應由人工先決定版本與來源。 |
| 9 | 新增持續整合工作流程 | 新增 CI 設定，使提交或 PR 自動執行安裝、npm run check、npm test，並可選擇執行 npm run build。現有 npm scripts 足以構成基本檢查步驟。 |
在 CI 平台上建立測試 PR，確認 Node.js 20 以上的 runner 能完成所有工作；分支保護及必要檢查名稱需由人工確認。 | 還原或停用新增的 CI workflow；若已設成必要檢查，需由具有儲存庫管理權限的人員移除對應分支規則。 | 會接觸外部 CI 平台及可能的儲存庫設定權限；平台、權限、secrets 和分支保護規則均為待確認。 | 需人工批准 | Codex 可以撰寫 workflow，但儲存庫目前沒有可確認的 CI 設定，且啟用外部自動化及修改分支保護可能需要管理權限。 |
| 10 | 將 CLI 接到正式 issue 系統並直接執行正式 triage | 可能需要修改 src/cli.ts 以呼叫外部 API、加入認證與分頁處理，並對正式 issue 資料執行排序；但目前程式只讀取本機 JSON 檔案。 |
API sandbox、契約測試、正式資料驗證、稽核紀錄及成功判準全部為待確認；儲存庫目前僅提供本機 JSON 範例。 | API 寫入是否可逆、正式執行紀錄、先前狀態備份與回復程序全部為待確認。在這些資訊完成前不可執行。 | 會涉及正式系統、正式資料及認證憑證；系統位置、資料敏感度和授權方式均為待確認。 | 不可交給 Codex | 儲存庫沒有外部 issue 系統介面、憑證管理、sandbox、部署或回復文件。不能讓 Codex 自主取得正式存取權或直接對未知的正式資料執行操作。README 只承諾讀取 JSON 陣列。 |
這些任務都能限制在 src、tests 與本機測試資料內；現有 scripts 提供測試與型別檢查入口。
這些任務分別涉及建置契約、產品排序政策、軟體供應鏈或外部平台權限；相關治理規則在儲存庫中均沒有完整說明，因此必須先取得人工決策。
可以另行把「撰寫不含憑證、只針對 mock server 的整合程式」拆成待批准的開發任務，但取得正式憑證、直接連線正式系統及操作正式資料不應交由 Codex 自主完成。現有程式沒有任何外部 API 或正式環境設定，只有本機檔案讀取流程。
npm install、npm ci、npm run dev、npm run build、npm test 或 npm run check。以下只讀命令用於確認檔案清單、工作樹狀態及相關檔案內容；它們不是專案建置、啟動或測試指令。
find . -maxdepth 4 -type f -not -path './.git/*' -not -path './node_modules/*' | sort
git status --short --branch
nl -ba README.md
nl -ba package.json
nl -ba tsconfig.json
nl -ba .gitignore
nl -ba src/cli.ts
nl -ba src/domain/issue.ts
nl -ba src/services/triage.ts
nl -ba tests/triage.test.ts
nl -ba examples/issues.json
iThome鐵人賽
看影片追技術