案例 01 · 提 PR 前先讓它審一遍

什麼場景

功能寫完了，測試也過了，但你心裡知道有幾處是趕出來的。 提上去之前想先過一遍，又不想麻煩同事——這時候讓 Codex 先審一次。

它審得比人快，也比人耐心；但它不知道你們團隊的歷史包袱， 所以它的結論要過你這一道。

在什麼權限下跑

只讀就夠。 審查不改工作樹——這是 /review 的設計： Codex 啟動一個專用審查器，讀所選的差異，報告按優先順序排列的結果，不動你的工作樹。

保險起見可以顯式限死：

codex --sandbox read-only

怎麼跑

先確認狀態：

git status
git diff --stat        # 心里有数：这次动了多少

進 Codex 之後輸入：

/review

會讓你選範圍：

• 對照基準分支審查——看這個分支相對 main 的全部改動，適合提 PR 前
• 審查未提交的更改——看你現在手上還沒提交的東西，適合提交前

/review 只在 Git 倉庫裡出現

專案不是 Git 倉庫的話這個指令不會顯示。桌面應用的審查窗格也一樣， 會直接提示你建立一個。

想審得更有針對性

/review 是通用預設。如果你知道風險在哪，直接說會更準：

审查当前分支相对 main 的改动，重点看三件事：
1. src/payment/ 下新加的重试逻辑会不会造成重复扣款
2. 有没有把错误吞掉只打日志的地方
3. 新加的两个依赖，许可证和体积

不要提格式和命名问题，那些 lint 会管。
每条结论给出文件和行号，并说清楚在什么输入下会出问题。

最後兩句很關鍵：排除掉 CI 已經管的東西，讓它把注意力放在機器查不出來的地方； 要求給出觸發條件，能立刻篩掉一半的「理論上可能有問題」。

結果怎麼讀

審查發現會以內聯評論的形式顯示在審查窗格里，並按優先順序排列。

審查窗格反映的是你 Git 倉庫的狀態，不只是 Codex 改的東西—— 裡面包括它的改動、你自己的改動，以及倉庫裡任何其他未提交的改動。 預設顯示未暫存的更改；已暫存看 Git 索引，提交看選中的提交， 分支看與基準分支的差異，上一輪看助手最近一輪改了什麼。

在窗格里：點檔名一般會在你選的編輯器裡開啟； 點檔名所在的背景區域展開/摺疊差異；Cmd + 點選某一行直接跳到那一行。

讓它順手改掉

覺得某條結論成立，可以直接讓它改。但注意： 如果你讓 Codex 應用它提出的修復，你原有的沙盒和核准設定仍然適用。 也就是說前面用 --sandbox read-only 的話，它改不了——得先放開權限。

我的做法是分兩步：先只讀審完，把結論過一遍， 挑出真要改的，再切到 workspace-write 讓它改這幾條。 一次審一次改分開，比讓它邊審邊改可控得多。

幾個用得上的設定

審查用不同的模型。 config.toml 裡的 review_model 可以讓審查用一個跟當前工作階段不一樣的模型：

review_model = "gpt-5.6"

把審查開成獨立聊天。 預設審查在當前聊天裡跑，會佔掉主執行緒的上下文。 桌面應用：設定 → 常規 → 程式碼審查 → 獨立。 IDE 擴充功能：把 chatgpt.reviewDelivery 設成 detached。

長工作階段裡這個開關值得開啟——審查產生的輸出量很大， 留在主執行緒裡就是 快速上手 06 說的那種上下文汙染。

處理 PR 上的評論

如果 Codex 有你倉庫的 GitHub 存取權限，而且當前專案在 PR 分支上， 桌面應用可以在應用內處理 PR 反饋：側邊欄顯示 PR 上下文和審查者的意見， 審查窗格把評論和差異並排顯示。

前提是裝了 GitHub CLI 並登入：

gh auth login

gh 沒裝或沒通過身份驗證的話，PR 詳情就不會出現在側邊欄和審查窗格里。

完整流程：在 PR 分支上開啟審查窗格 → 看 PR 上下文、評論、改動的檔案 → 讓 Codex 針對某條具體評論修 → 在窗格里檢查生成的差異 → 暫存、提交、推送。

容易翻車的地方

把審查結果當結論。 它不知道那段看起來很怪的程式碼是三年前為了繞某個線上問題寫的。 每條結論自己判斷一次。

讓它邊審邊改。 改了之後 diff 就變了，你分不清哪些是原本的問題、哪些是它新引入的。 審完再改。

範圍給太大。 「審一下這個倉庫」會得到一堆泛泛而談。 限定到分支差異或某幾個目錄，結論質量差別很大。

相關官方文件

• 程式碼審查
• 在 GitHub 中使用 Codex
• 開發者設定（官方頁面，本站未映象）
• 安全審查