「讓另一個 AI agent 來 review 剛剛那個 AI agent 寫的程式碼，這樣真的有用嗎？他們不都是同一套模型嗎？」
Day 07 提過一個具體案例：獨立的 review agent 沒有參與原本的實作過程，重新審查一次抓到了一個實作過程沒發現的架構風險。這個案例證明「獨立視角有用」，但沒有回答今天要問的問題：要怎麼設計這個審查流程，才能讓「獨立視角」真的發揮作用，而不是流於形式、變成另一個容易誤判的橡皮圖章？
如果只是把程式碼丟給另一個 agent，說一句「幫我看看有沒有問題」，得到的結果通常是一份看起來完整、其實深淺不一的清單——有些是真正的風險，有些只是風格偏好，還有一些是 review agent 憑著程式碼表面「看起來合理」就直接放行，跟原本那個 agent 犯的錯誤一模一樣，只是換了個人犯。
「沒有共享上下文」只保證這個 agent 不會被前面的假設帶著走，不保證它會用足夠嚴謹的標準去審查。 如果沒有給審查流程一個明確的標準，review agent 一樣會依賴它自己對「這段程式碼看起來合不合理」的直覺判斷——而直覺判斷正是這個系列從 Day 01 開始反覆提醒要小心的東西。
有效的審查流程，會先把「找問題」這件事拆成幾個具體、可以逐條檢查的維度，而不是丟出一個籠統的指令讓 AI 自由發揮。舉例來說：這段改動有沒有引入迴歸（跟 Day 06 的乾淨基準比對是同一件事，只是換成人工/AI 審查的角度）、這段改動有沒有踩到這個專案已知的陷阱（例如 Day 13、Day 14 講過的 DI 容器陷阱）、測試斷言是不是真的驗證了正確的事，還是只是為了讓測試變綠而放寬條件（Day 03 講過的案例）。
用一組對照來看差異：
❌ 籠統的審查指令：
「幫我看看這段程式碼有沒有問題。」
→ review agent 只能憑自己的直覺判斷「合不合理」，
標準不明確，容易漏掉這個專案特有的已知陷阱
✅ 明確的審查標準：
「檢查這段改動：(1) 是否可能引入迴歸——
有沒有跟 Day 06 講過的基準比對確認過；
(2) 有沒有踩到已知的 DI 容器陷阱；
(3) 測試斷言是不是驗證了正確的值，
而不是用寬鬆比對迴避判斷。」
→ review agent 知道具體要對照什麼標準，
結果可以被檢查、可以被追蹤是不是真的每一項都確認過
即使有了明確標準，AI review AI 還有一個更根本的邊界：兩個 agent 都是用類似的方式在理解程式碼，它們可能會共享同一種系統性偏誤——比如都傾向信任表面邏輯合理的程式碼、都容易在「看起來測試涵蓋了」的情況下不進一步深究測試到底斷言了什麼。這不是「換一個角度審查」能自動解決的問題，因為兩個角度可能出自同一種思維習慣。
比較穩健的做法是把審查拆成兩個階段：第一階段讓 review agent 產出「可能有問題的地方」清單，第二階段針對清單裡每一項，要求提出具體的失敗情境——什麼樣的輸入、什麼樣的狀態下，這個問題會真的造成錯誤。只有能講清楚具體失敗情境的發現，才算是被驗證過的問題；講不出具體情境、只停留在『感覺怪怪的』的項目，要嘛降低信任度，要嘛回頭要求提供更多證據，不能直接當成定論。
這個「發現 → 驗證」的兩階段設計，本質上跟這個系列從 Day 07 開始強調的「驗證跟判斷要分開」是同一個邏輯——第一階段的清單只是初步觀察，不是結論；第二階段的驗證才把它變成一個可以被信任的具體宣稱。
要誠實面對這個機制的邊界：它能有效抓出「實作過程中被自己的假設帶偏」的問題，但解決不了「這整個團隊、這整套 AI 工具都有的共同盲點」。如果某種錯誤判斷是這個模型普遍的行為模式（就像 Day 23 要講的，某些坑值得回饋給工具本身），單靠換一個 review agent 重新審查一次，兩邊很可能會用同一套盲點得出同一個錯誤結論。這種情況下，真正有效的把關，還是要靠人在關鍵節點提出「這個標準夠不夠嚴謹」這個問題本身。
回想你上一次讓 AI 幫你 review 程式碼的經驗：那次的審查指令，是具體到可以逐條檢查的標準，還是一句籠統的「幫我看看」？如果是後者，那份審查清單的可信度，其實跟隨機抽查沒有太大差別。
明天要往上升一層：如果某個誤判不是這個專案特有的，而是 AI 工具本身反覆出現的行為模式，這種洞察值得怎麼處理——把踩坑經驗回饋給 AI 工具本身，一份好的回饋長什麼樣。
iThome鐵人賽
看影片追技術