我越來越推薦用 Codex Subagents 做 AI Code Review

大家好，我係子昕。

一、我以前嘅流程，可能都係你嘅流程

最近用 Codex CLI 寫代碼越嚟越多之後，我嘅開發流程基本上變咗：

Codex 生成代碼 → 自己睇一次 → 覺得冇問題 → 提交 → 等測試同事發現問題 → 改

呢個流程我一直覺得冇乜問題。

直到今次需求比較大，自查完之後，我突然停低問咗自己一句：

我頭先真係喺度「審代碼」”嗎？

定係只係喺度確認——

呢啲代碼睇落冇問題。

呢兩件事，感覺差唔多，但其實唔一樣。

二、人腦會畀 AI 輸出「帶住走」

用 AI 寫代碼用得耐咗，會有一個好隱蔽嘅變化：

你嘅審查視角，開始跟住 AI 嘅輸出走咗。

AI 寫咗一個實現思路之後，你讀代碼嘅時候，個腦已經會不自覺咁沿住佢嘅路徑去驗證——

呢度邏輯啱唔啱？

呢個分支有冇漏？

而唔係退返嚟重新諗：

呢個地方係咪仲有第二啲設計方式？

邊界到底啱唔啱？

細需求嘅時候，呢個問題其實唔明顯。

但需求一大，AI 寫嘅代碼量上咗嚟，呢種「跟住走」嘅慣性就會被放大。

自查，越來越似係喺度確認 AI 有冇寫死。

而唔係重新思考：呢個需求到底應該點樣實現。

今次我意識到呢一點，係因為需求確實比之前大咗唔少。

自查完，我自己都唔係好有信心。

三、我畀 Codex 配咗兩個「唯讀審查員」

我喺 Codex CLI 裏面開咗兩個 Subagents，分工明確，並行運行：

使用/agent命令，可以睇到所有 Subagents 列表，並切換到任意一個 Agent 去睇執行詳情。

Helmholtz — 淨係睇架構

負責審查架構原則、模塊職責、依賴方向、可演進性。淨係輸出 findings，唔改代碼。

James — 淨係睇邏輯同邊界

負責審查邊界條件、邏輯語義、異常處理、潛在 bug。同樣唯讀，唔鬱代碼。

我後來意識到，呢個其實就係傳統工程裏面最基本嘅職責分離：

主代理負責「開發」，Subagents 負責「Review」。

點解堅持「唯讀」？

如果俾多個代理同時修改代碼，好容易基於唔同版本互相 review，最後合併出嚟嘅結果可能比原來更亂。

兩個審查代理並行跑，主代理等兩份結果返嚟之後統一合併判斷，再決定邊啲點今輪一定要改、邊啲記錄到後續演進。

某程度上，呢個已經有啲似 AI 時代嘅 lightweight CR 流程喇。

四、真實結果：唔係錦上添花，係查咗真問題出嚟

喺跑 Subagents 之前，我其實已經覺得呢個版本「差唔多可以提測喇」。

而且嗰種「差唔多冇問題」嘅感覺，其實都幾強。

第一輪

Helmholtz 之前嘅 Ptolemy Agent 發現咗 P1 級架構問題，涉及職責邊界同模塊設計。

唔係「以後可以優化」嘅建議，係當前結構裏面真實存在嘅風險。

Codex 當時就改咗。

改完之後，跑第二輪

Helmholtz 今次淨係返回咗 P2——主要係後續演進建議，冇必須處理嘅架構問題。說明第一輪嘅修改係有效嘅。

James 喺第二輪返回咗 P1——當前需求鏈路裏面嘅邊界風險，屬於今次上線必須處理嘅問題。

呢啲，我自查嘅時候，全部漏咗。

當時我第一反應其實係：呢啲問題我頭先點解會睇唔到？

返轉頭睇，其實唔係代碼收得深。

而係我嘅注意力已經被 Codex 嘅實現路徑帶住走咗。

五、呢個流程真正解決嘅問題

我唔認為呢個係「用 AI 替代 Code Review」。

團隊 CR、測試覆蓋，應有嘅都仲要有。

但呢個流程解決咗一個好具體嘅問題：

喺我自查嘅時候，俾我一個唔會畀 AI 輸出「帶住走」嘅外部視角。

Subagents 冇參與代碼生成嘅過程，唔知 Codex 嘅實現思路，佢淨係睇代碼本身。

而呢個「局外人視角」，啱啱係自查最難做到嘅。

某程度上，Subagents 唔係喺度替開發者做判斷。

而係喺 AI Coding 越來越重嘅時候，強行將開發者重新拉返去「Review 視角」。

六、最後

以前我覺得測試同事係喺度幫我「驗收功能」。

而家越來越覺得：佢哋好多時候，其實係喺度替開發者補 AI 漏咗嘅邊界。

唔係 AI 唔夠好，係當 AI 開始承擔大量實現之後，

人喺審查環節投入嘅真實注意力，已經喺悄悄減少咗。

後面我準備將呢套 review workflow 固定落嚟，大需求默認先跑一輪 Subagents 再提測。

AI Coding 發展到後面，

真正拉開差距嘅，

可能已經唔係邊個生成代碼更快，

而係邊個先建立咗穩定嘅 AI Review 流程。

俾個關注啦，我會繼續用我呢半桶水水平為大家帶嚟更多AI編程工具嘅第一手體驗～

「讚好、轉發、睇緊」
同大家一齊睇

大家好，我是子昕。

一、我以前的流程，可能也是你的流程

最近用 Codex CLI 寫代碼越來越多之後，我的開發流程基本變成了：

Codex 生成代碼 → 自己過一遍 → 感覺沒問題 → 提交 → 等測試同學發現問題 → 修

這個流程我一直覺得沒什麼問題。

直到這次需求比較大，自查完之後，我突然停下來問了自己一句：

我剛才真的是在“審代碼”嗎？

還是隻是在確認——

這些代碼看起來沒問題。

這兩件事，感覺差不多，但其實不一樣。

二、人腦會被 AI 輸出“帶着走”

用 AI 寫代碼用久了，會有一個很隱蔽的變化：

你的審查視角，開始跟着 AI 的輸出走了。

AI 寫了一個實現思路之後，你讀代碼的時候，腦子已經會不自覺沿着它的路徑去驗證——

這裏邏輯對嗎？

這個分支有沒有漏？

而不是退回來重新想：

這個地方是不是還有別的設計方式？

邊界到底對不對？

小需求的時候，這個問題其實不明顯。

但需求一大，AI 寫的代碼量上來了，這種“跟着走”的慣性就會被放大。

自查，越來越像是在確認 AI 有沒有寫崩。

而不是重新思考：這個需求到底應該怎麼實現。

這次我意識到這一點，是因為需求確實比以往大了不少。

自查完，我自己都不太有底氣。

三、我給 Codex 配了兩個“只讀審查員”

我在 Codex CLI 裏開了兩個 Subagents，分工明確，並行運行：

使用/agent命令，能看到所有Subagents列表，並切換到任意一個Agent去看執行詳情。

Helmholtz — 只看架構

負責審查架構原則、模塊職責、依賴方向、可演進性。只輸出 findings，不改代碼。

James — 只看邏輯和邊界

負責審查邊界條件、邏輯語義、異常處理、潛在 bug。同樣只讀，不動代碼。

我後來意識到，這其實就是傳統工程裏最基本的職責分離：

主代理負責“開發”，Subagents 負責“Review”。

為什麼堅持“只讀”？

如果讓多個代理同時修改代碼，很容易基於不同版本互相 review， 最後合併出來的結果可能比原來更亂。

兩個審查代理並行跑，主代理等兩份結果回來後統一合併判斷， 再決定哪些點本輪必須改、哪些記錄到後續演進。

某種程度上，這已經有點像 AI 時代的 lightweight CR 流程了。

四、真實結果：不是錦上添花，是查出了真問題

在跑 Subagents 之前，我其實已經覺得這版“差不多可以提測了”。

而且那種“差不多沒問題”的感覺，其實還挺強的。

第一輪

Helmholtz 之前的 Ptolemy Agent 發現了 P1 級架構問題，涉及職責邊界和模塊設計。

不是“以後可以優化”的建議，是當前結構裏真實存在的風險。

Codex當時就改了。

改完之後，跑第二輪

Helmholtz 這次只返回了 P2——主要是後續演進建議，沒有必須處理的架構問題。 說明第一輪的修改是有效的。

James 在第二輪返回了 P1——當前需求鏈路裏的邊界風險，屬於這次上線必須處理的問題。

這些，我自查的時候，全部漏掉了。

當時我第一反應其實是：這些問題我剛才怎麼會沒看到？

回頭看，其實不是代碼藏得深。

而是我的注意力已經被 Codex 的實現路徑帶着走了。

五、這個流程真正解決的問題

我不認為這是“用 AI 替代 Code Review”。

團隊 CR、測試覆蓋，該有的還是要有。

但這個流程解決了一個很具體的問題：

在我自查的時候，給我一個不會被 AI 輸出“帶着走”的外部視角。

Subagents 沒有參與代碼生成的過程，不知道 Codex 的實現思路，它只看代碼本身。

而這個“局外人視角”，恰好是自查最難做到的。

某種程度上，Subagents 不是在替開發者做判斷。

而是在 AI Coding 越來越重的時候，強行把開發者重新拉回“Review 視角”。

六、最後

以前我覺得測試同學是在幫我“驗收功能”。

現在越來越覺得：他們很多時候，其實是在替開發者補 AI 漏掉的邊界。

不是 AI 不夠好，是當 AI 開始承擔大量實現之後，

人在審查環節投入的真實注意力，已經在悄悄減少了。

後面我準備把這套 review workflow 固定下來， 大需求默認先跑一輪 Subagents 再提測。

AI Coding 發展到後面，

真正拉開差距的，

可能已經不是誰生成代碼更快，

而是誰先建立起了穩定的 AI Review 流程。

點個關注唄，我會繼續用我這半吊子水平為大家帶來更多AI編程工具的第一手體驗～

「點贊、轉發、在看」
和大家一起看