不被它唬:怎麼又快又準地審 Codex 的 diff

你已經敢讓 Codex 在你的 repo 跑任務、用手機核准、設好了權限。最後一個上手技能，是它把 diff 交回來時——怎麼審，才不會收進一個有 bug 的版本，也不會把它的工作整個重做一遍。

先認清楚：測試綠 ≠ 正確

AI 寫的 code 出錯時，不會長得可疑。它會交一段排版整齊、命名漂亮、測試還綠的 code——問題藏在測試沒涵蓋的地方，或它順手寫的一個其實不存在的 API、一個它「以為」的函式簽名。模型自信地產出錯誤的東西，這叫幻覺;寫 code 上，它特別會「編一個看起來很合理的 API」。

它說「測試綠了」只代表「它寫的測試過了」，不代表「它寫的測試是對的、涵蓋夠的」。綠燈是起點，不是結論。

這一點在用手機核准時更要小心：小螢幕上你更容易只看到「測試綠了」就放行。真正要收進 main 的東西，值得你回到電腦前好好讀。

把它當一個 PR 來 review

最簡單的心態：它交的 diff，就是一個資淺同事開的 PR。 你不會盲 merge 別人的 PR，也別盲 merge 它的。抽查風險最高的地方，別逐行重寫：

• 邏輯與邊界:核心邏輯對嗎？空值、錯誤、邊界有處理嗎？——bug 最愛藏這。
• 它用的 API／函式真的存在嗎:特別是你不熟的 library，它可能很篤定地呼叫一個不存在的方法。
• 它寫的測試測對了嗎:是不是只測 happy path?斷言有意義嗎(別只是 expect(true).toBe(true))?
• 它沒改到的地方:漏掉該一起改的呼叫端？順手改壞別的？

排版、命名這種，交給 lint／formatter，你不用花眼力。力氣花在「機器擋不掉、錯了代價大」的地方。

讓它幫你縮小審查範圍

在交代時就要求它把審查變簡單：

• 「改完後，跟我說你動了哪些檔、每個檔為什麼改。」
• 「列出你不確定、或我可能想再確認的地方。」
• 「你用到的外部 API，標出來，我要核對文件。」

它常會老實列出幾個沒把握的點。這不是讓它自我背書，是用它的速度幫你標出可疑區，你再針對那幾處親自看。

力道對準後果

• 拋棄式腳本、本地實驗:跑得動、結果對就好，快速掃過。
• 要進 main、會上 production:每一行都讀、邊界都想、測試品質都查——而且這類動作本來就該停在你核准那一關。

審查和核准是同一件事的兩面：approval 擋的是「它做之前」，review 擋的是「你收之前」。 兩道都過，這段 code 才真的能算你的。

你仍是負責的人

說到底：不管是誰、哪個 agent 寫的，進了你 repo、掛你名字 merge 的 code,負責的是你。 Codex 讓你寫得更快，不讓你不用負責。把心態擺正，你會自然養成讀 diff 的習慣——這正是用 AI 寫 code 不出事的關鍵。

上手階段：你已經會用了

走到這裡，你學會了這條路線最核心的三件事：把任務講成規格、設好 approval 與權限、像審 PR 一樣審 diff。加上入門的動手與手機核准，你已經能放心讓 Codex 處理真實工作了。

接下來進階階段，把效益放大：用可恢復的長流程跑單一 session 扛不動的大任務，再把 Codex 接進你的系統與 CI，讓它從「幫你做單一任務」變成你工作流的一部分。

林子睿（編輯：廖玄同），《不被它唬:怎麼又快又準地審 Codex 的 diff》，矽基前沿 [Si]gnals，2026-06-19。https://signals.tw/articles/codex-verify/