review 真正在做的事

2013 年，微軟研究院的 Christian Bird 和當時在那裡實習的 Alberto Bacchelli 做了一項研究：觀察、訪談、問卷調查微軟各團隊的工程師和主管，再把五百多則真實的 review 留言一則一則分類，想知道 code review 到底在做什麼。

問大家為什麼要做 review，最常見的回答是抓 bug。但分類完留言之後，跟 bug 有關的只占一成多，遠比大家以為的少。留言裡最多的是改進程式碼的建議，其次是為了看懂而提的問題。訪談和問卷裡，工程師還提到 review 帶來的其他好處：知識在團隊裡流動，大家知道別人改了什麼、為什麼這樣改，有時也會冒出另一種做法；主管們則提到，review 也是教資淺工程師認識 codebase 的方式。

研究還指出，review 最大的挑戰是看懂這次改動。工程師花了很多力氣在理解程式碼和改動的脈絡，而當時的工具在這方面幫不上什麼忙。

順著這個發現往下想，可以把 code review 看成有兩份工作。一份是抓問題，另一份是讓團隊裡有人真的看懂這段程式。

一個 PR 的三道關

假設一個功能做完了，準備開 PR。Claude Code 有幾個指令可以在這時候派上用場，各自看不同的東西。

先跑 /code-review。它檢查這次的改動有沒有正確性的 bug，也可以指定某個 PR 或分支，並調整檢查的深度。找到的問題可以加上 --fix 直接修，或加上 --comment 貼到 GitHub 的 PR、GitLab 的 merge request 上。改動比較大、比較關鍵的，可以用 ultra 在雲端讓多個 agent 一起做一次深度 review。

如果改動碰到了登入、權限或使用者輸入，再跑 /security-review。它比對目前分支和遠端預設分支之間的差異，專找注入、驗證與授權問題、資料外洩這類安全風險。

最後是 /simplify。它不找 bug，看的是有沒有重複造了專案裡已經有的輪子、能不能寫得更簡單、效率好不好、有沒有放在對的抽象層級，找到之後會直接改掉。

有一件事值得特別提醒：很多教學裡寫的 /review，在 v2.1.223 之前是另一個指令，只針對 GitHub PR 做一次唯讀的 review。現在的 /review 是 /code-review 的別名，參數和行為都跟著改了。照舊文章的說明去用，結果會跟預期不同。

第一份工作交給 AI

抓問題這份工作，AI 很適合分擔。它不會因為 diff 太長就開始跳著看，也不會因為是資深同事寫的就不好意思挑，每一次改動都能完整跑一遍。安全檢查也不必等到上線前才排人力。

它當然不會抓到所有問題，檢查深度設得低時，回報的也只是少數把握比較高的發現。但有了這一層，人在 review 裡的時間可以少花一點在逐行找錯，多留一點給 AI 做不到的那件事。

第二份工作要落在人身上

麻煩在第二份工作。

/code-review 跑完，問題清單有了，bug 也修了，但這些都沒有讓團隊裡任何一個人更了解這段程式。review 過去附帶的那些東西，知道誰改了什麼、為什麼這樣改，在這個流程裡並不會自動發生。

如果程式碼本身也是 AI 寫的，情況更明顯。寫的是 agent，review 的也是 agent，合併進主線之後，團隊裡可能沒有一個人完整讀過它。Day 15 講過，程式碼留下來之後，每一天都要有人理解和維護；一段沒有人讀過的程式，等到要改它的那天，所有理解的成本會一次湧上來。

AI 在這裡幫得上忙，但角色不同。它可以解釋一段程式在做什麼、整理這次改動的摘要、回答「為什麼這裡要這樣寫」。只是解釋得再清楚，理解也得發生在讀的人腦子裡，這一步沒辦法代勞。

人的 review 換了重點

所以有了 AI review，人的工作換了重點。

bug 先交給 /code-review 和 /security-review 去找，處理掉它們抓到的問題。人接著做 Bacchelli 和 Bird 說的那件最難的事：看懂這次改動。

一個好的起點，是要求 PR 的說明寫清楚幾件事：這次要解決什麼問題、為什麼選這個做法而不是另一個明顯的替代方案、哪裡最可能出事、怎麼驗證過。這段說明可以請 agent 先起草，再由開 PR 的人確認每一句都說得通。

合併之前，可以用兩個問題檢查理解是否到位。如果有人問「為什麼不用另一種做法」，答得出來嗎？如果這段程式上線後壞了，知道該先看哪裡嗎？兩個都答不出來，就還沒看懂。這時候請 agent 解釋；解釋完還是說不清楚，往往代表這段程式本身需要改寫。

從會議室到指令

1970 到 80 年代，code review 是正式的檢閱會議，一群人在會議室裡逐行看程式碼。後來它變成了輕量的線上 review，在 PR 下面留言就好。現在，它又多了一個不會累的 AI reviewer。

每一次工具改變，抓 bug 的方式都變得更快。Bacchelli 和 Bird 在 2013 年就發現，review 最大的挑戰是讓人看懂改動，這一點到今天也沒有改變。

延伸閱讀

• Expectations, Outcomes, and Challenges of Modern Code Review — Microsoft Research — Bacchelli 與 Bird 2013 年的研究
• Commands — Claude Code docs — /code-review、/review、/security-review、/simplify 的官方說明
• Review a diff locally — Claude Code docs — 本機 review 的深度等級與用法
• Ultrareview — Claude Code docs — 雲端多 agent 深度 review