Codex 做完一個 task，最後常會留下一句很像結案的話：

Done. Fixed the retry bug and added tests.

這句話可以當摘要，但還不夠拿來決定要不要 Merge。

假設這次修的是 payment retry。接手驗收的人需要看到哪幾個檔案被改了、目前改動落在哪個 Branch 或 Commit、測試實際跑了什麼、Review 看的是不是最新版，以及 PR 有哪些合併條件。只要中途又 Push 一個 Commit，前面留下來的測試結果和 approval 也可能需要重新確認。

Codex 已經能把這些材料放進同一套工作流：Diff、Review comments、terminal logs、test outputs，以及 Pull Request 的 changed files 和 comments。[1][3][4] 驗收時要做的，是把每份證據對回它實際檢查的那批修改。

先確認你在驗收哪一版

同一個工作目錄裡，可以同時存在 unstaged、staged 和已經 commit 的內容。兩個人如果看的不是同一份變更，後面談測試或 approval 很快就會雞同鴨講。

Codex App 可以直接看 Git summary、Diff、changed files 和 Pull Request comments。[3][4] Terminal 端用下面三個指令就能先把狀態摸清楚：

git status --short --branch
git diff
git diff --staged

git status --short --branch 會顯示目前 Branch，以及 staged、unstaged、untracked 的概況。git diff 看 Working Tree 相對 Index 的未暫存修改；git diff --staged 看 Index 相對 HEAD 的已暫存修改。

如果 Agent 已經 Commit，驗收對象可以直接換成那個 Commit，或 Head Branch 相對 Base Branch 的整份變更。這時 PR 比「我剛剛在本機看過」更容易重查，因為 Base、Head 和 changed files 都已經固定下來。

以 payment retry 為例，如果 Diff 裡只有：

src/payment/retry.ts
tests/payment/retry.test.ts

接著看每一段修改：重試條件改在哪、錯誤處理有沒有一起動、新增的 test case 是否真的對到 task，有沒有混進無關檔案。Codex App 從早期就能直接 Review Agent changes、在 Diff 上留 comment；後續又補了 inline / detached review、Git summary，以及 PR 的 changed files 和 Review comments。[3][4]

Diff 能讓你看到修改內容，但它沒有執行程式，也沒有碰到執行時依賴。

The closure evidence stack from change set to merge decision

Figure 1｜Diff、Git 狀態、測試與 checks、Review、PR gate 各自檢查不同面向。後面的狀態不會把前面的證據範圍自動放大。

測試要連同範圍一起看

Codex 可以跑測試、linter 和 type checker，task 結束後也能留下 terminal logs 和 test outputs。[1] 看到 PASS 時，先看它是由哪個指令、哪個 job 跑出來的。

例如這次只執行：

pytest tests/payment/test_retry.py -q

那這份結果可以支持：

這次執行的 payment retry focused tests 通過。

它沒有測完所有 payment path。外部依賴、不同環境設定、timing，以及沒被這支測試碰到的 failure path，也都還在這份結果之外。

GitHub status checks 也要看內容。CI build、test、code scan、deployment check 都可能回報狀態；Branch protection 則可以要求特定 checks 達到 GitHub 接受的成功狀態後才能 Merge。[6][7]

其中一個容易誤讀的細節是，GitHub 對 required checks 接受的成功 conclusion 包含 success、skipped 和 neutral。[6] 所以 merge gate 已滿足，不代表每一條你以為會跑的測試都真的執行過。需要依賴某個 check 時，還是要打開它背後的 workflow 或 job。

Review 看風險，repo 規則決定能不能合併

Codex code review 會對照 PR 描述的意圖和實際 Diff，連同周邊 code 與相依關係一起看，必要時也能執行程式或測試；GitHub 上可用 @codex review 觸發 Review。[2]

Codex review 可以補找 focused test 沒問到的問題，例如實作是否偏離 task、其他路徑有沒有 regression、錯誤處理是否漏掉、相依關係有沒有改變，或 security risk 是否需要繼續追。OpenAI 也把 Codex code review 定位成 additional reviewer，不用來取代 human review。[2]

如果 Review 沒有 finding，紀錄就寫成「這次 Review 沒找到問題」。

Pull Request 另外負責合併邊界。GitHub Review 可以是 Comment、Approve 或 Request changes；repo 的 ruleset / branch protection 可以要求 approvals、Code Owner review、status checks，或要求 Branch 跟 Base 保持最新。[5][7]

Reviewer 表達的是審查意見，repo 規則決定哪些狀態真的會擋住 Merge。Request changes 並不是在所有 repo 裡都自動等於禁止 Merge，要看 ruleset 或 branch protection 怎麼設定。[5]

Merge requirements 全部滿足時，能確認的是目前設定的條件已經通過。專案如果沒有要求 integration test、security scan 或 owner approval，Merge gate 不會替你補做那些檢查。[7][8]

Codex 還有一個名字很接近的 Auto-review。Agent 想跨出 sandbox 執行邊界時，Auto-review 會把規劃動作與近期 context 交給 auto-approval subagent 判斷是否放行；這和 Pull Request code review 是兩條不同的工作流。[9]

新 Commit 進來後，重新對一次證據

假設 Commit A 的狀態是：

focused tests     PASS
review            APPROVED
required checks   PASS

Reviewer 留下一個 comment，Agent 修完再 Push Commit B。

這時被驗收的程式已經變了。A 的 test output 不能直接拿來替 B 作證。GitHub 的 required status checks 也要求結果對應最新 Commit SHA，舊 Commit 的 result 不能拿來滿足新的 Head。[6]

Approval 也可能受到影響。GitHub 可以設定「新 Commit 改變 Diff 時 dismiss stale approvals」，也可以要求 latest reviewable push 必須由另一位 reviewer approve。[7] 這些都是 repo policy，不是每個專案預設都會開。

Evidence should stay bound to the exact change set being reviewed

Figure 2｜Commit B 進來後，被驗收的版本已經改變。哪些 tests 要重跑、哪些 Review 要重做，要看修改範圍和 repo policy；Commit A 的證據不會自動覆蓋 Commit B。

驗收流程跟著整合風險走

有些 scratch work 根本不會進 shared branch，開完整 PR 流程只是在增加等待。另一邊，一行 authentication rule 或 migration 的修改，影響面可能比幾百行丟掉就算了的 experiment 更大。

情境合理的驗收方式原因
Throwaway experiment、不會進 shared branchLocal Diff + 需要的 targeted check沒有 shared integration boundary
小型、低風險、單一 owner 的 repo 修改Diff + Git 狀態 + focused tests / lint完整 PR 流程可能只增加等待
會進 shared main branchBranch / PR + Review + repo checks需要固定這批變更和合併邊界
多 Agent 平行施工每個工作單位維持清楚的變更範圍，再交給 integration owner 收斂平行執行沒有消掉最後的整合工作
共用設定、authentication、migration、payment 等敏感區域PR + appropriate owner review + 對應 checks影響面較大，需要更多可重查的驗證
Release / production pathRepo policy gates + 最新版本的證據 + 明確 merge owner最後決策不能只停在 Agent 的完成訊息

選哪一層流程，主要看這批修改會碰到誰、進到哪個 shared boundary，以及出錯後的影響面。

Merge 前再看一遍

Agent 回 Done 之後，可以直接檢查下面幾件事：

  • 驗收對象清楚嗎？ 要能說出是哪個 Branch、Commit 或 working tree，Diff 也要對得上這次 task。
  • 實際跑過什麼？ 測試、lint、type check、manual validation 各自覆蓋到哪裡。
  • Review 還是最新的嗎？ Findings 是否已處理，後續 Push 有沒有改掉 reviewer 當時看到的內容。
  • Repo 規則實際檢查哪些條件？ 哪些 gate 已滿足，哪些風險根本沒有被目前的規則檢查。
  • 誰做最後的 Merge 決定？ Agent 可以整理證據，負責整合的人仍要判斷這些資料對這次修改夠不夠。

其中一項答不出來，就先補那一層的證據，再決定要不要 Merge。

References

  1. OpenAI, Introducing Codex. Codex can run test harnesses, linters, and type checkers, and exposes terminal logs and test outputs for review.
  2. OpenAI, Introducing upgrades to Codex. Codex code review, @codex review, review behaviour, and the recommendation to use Codex as an additional reviewer.
  3. OpenAI, Introducing the Codex app. Reviewing agent changes in-thread, commenting on diffs, and built-in Git-oriented workflows.
  4. OpenAI, ChatGPT & Codex changelog. Review modes, Git summary, and Pull Request workflow inside the app.
  5. GitHub Docs, About pull request reviews. Comment, Approve, Request changes, and required review behaviour.
  6. GitHub Docs, Status checks and Troubleshooting required status checks. Check conclusions and latest-commit-SHA requirements.
  7. GitHub Docs, About protected branches. Required reviews, Code Owners, required checks, stale approval handling, and latest-push approval.
  8. GitHub Docs, Merging a pull request. Repository requirements that gate merging into the upstream branch.
  9. OpenAI, Running Codex safely at OpenAI. Auto-review as an approval mechanism for requests that cross the sandbox boundary.