AI 代碼審查怎麼做：自查、工具審查、人工覆核三層流程與各家審查工具對照

本文根據 Cursor 官方教學《Reviewing and testing code》、GitHub 官方的 Copilot code review 文檔，以及本站已整理的 Codex、Claude Code 審查教學彙總而成，資料核對於 2026-10-11。本文講通用流程；具體某個工具怎麼點，見文中連結的單篇教學。

適用於誰

• 用 AI 寫了不少代碼，擔心「看着對、其實有坑」的人；
• 搜「ai 代碼審查」「ai 代碼審查工具」的人；
• 團隊負責人，想把 AI 審查接進 PR 流程的人。

結論先說

1. AI 寫的代碼更需要審查。Cursor 官方的說法：AI 生成的代碼可能看起來正確、能編譯、能通過你寫的測試，卻仍然漏掉邊界情況、有安全問題，或重複了代碼庫裏已有的邏輯。合併的標準不應該因為「是智能體寫的」而降低。
2. 審查分三層：提交前自查 → PR 上工具自動審 → 人工覆核。前兩層是為了讓第三層更省力，不是替代它。
3. 用全新的上下文來審。讓剛寫完代碼的那個對話審自己，容易偏袒；開新會話、換一個工具或用專門的審查功能更有效。
4. 給審查者可驗證的信號：測試、類型檢查、lint。檢查越多，越敢放手。
5. 所有官方文檔都有同一句免責：AI 審查不保證發現所有問題，也會誤報，必須有人驗證。

第一層：提交前自查

邊做邊看。智能體工作時 diff 是實時出現的，方向不對就立刻停下重來，不必等它做完。

讓智能體把整個分支的改動審一遍。在 Cursor 裏可以用 @Branch 把當前分支的完整 diff 交給它；其他工具直接說「審查當前分支相對 main 的全部改動」也行。可複製的提示詞：

text
審查我在這個分支上的全部改動。重點找：
1. 邏輯錯誤和沒處理的邊界情況；
2. 缺失的錯誤處理；
3. 和項目裏現有寫法不一致、或重複造了已有工具函數的地方；
4. 安全問題（輸入校驗、權限檢查、密鑰泄露）。
按嚴重程度排序，每條給出文件和行號，先不要改代碼。

再追問一句，往往能提前堵住評審意見：

text
評審的人看到這些改動會問什麼問題？PR 描述裏應該補充哪些背景？

用內置的審查功能。Cursor 在智能體完成任務後可以點 Review → Find Issues，逐行分析改動；對全部本地改動，可在 Source Control 裏運行 Agent Review 與主分支對比。Codex 的 CLI 裏有 /review，Claude Code 有 /code-review（別名 /review）和 /security-review。

新會話審查。Claude Code 官方最佳實踐裏的「寫 / 審分離」：會話 A 實現，會話 B 在全新上下文裏審查，再把意見交回 A。全新上下文不會偏向自己剛寫的代碼。

第二層：把提交整理成能審的樣子

智能體一次能改很多文件，容易產出一個幾百行的大提交，誰都審不動。Cursor 官方建議的做法：

1. 開發時不用管提交是否整潔，先把功能做通；
2. 都跑通後，讓智能體重排提交歷史：回到 main，通讀全部改動，規劃一個合乎邏輯的順序，拆成若干個小而語義清晰的提交；
3. 最後讓它驗證最終 diff 和原來完全一致，確保沒有丟改動。

text
功能已經完成。請把這個分支的改動重新整理成 3–6 個小提交，每個提交只做一件事，
提交資訊寫清「做了什麼、為什麼」。整理完對比最終 diff，確認和整理前完全一致。

第三層：PR 上的自動審查工具

Cursor 對這類工具和 linter 的區別說得很清楚：linter 抓格式問題，審查智能體找的是邏輯錯誤。兩者不互相替代，linter 和類型檢查應該先在 CI 裏跑掉，別讓 AI 審查把額度花在格式上。

定製審查重點。幾家都支持用規則文件告訴審查者「我們在意什麼」。寫法大同小異：

markdown
審查時優先關注：
- 涉及金額的計算是否用整數（分）
- 新接口是否做了權限校驗和入參校驗
- 數據庫查詢是否可能產生 N+1
不要評論純格式問題，格式由 linter 負責。

Copilot 放在 .github/instructions/*.instructions.md，Cursor 放在 Bugbot 規則裏，通用的約定可以放 AGENTS.md。見《copilot-instructions.md 怎麼寫》。

第四步：人工覆核時看什麼

AI 審過一遍之後，人的精力應該花在它不擅長的地方：

• 需求對不對：代碼實現的是不是真正要的東西——AI 只能對照代碼，不知道你沒寫出來的業務意圖；
• 架構取捨：這個改動放在這裏合不合適、會不會讓以後更難改；
• AI 的評論本身：GitHub 官方要求仔細驗證 Copilot 的反饋；誤報要標掉，別讓下一個人再看一遍；
• 高風險區域：鑑權、支付、數據遷移、刪除操作，無論 AI 說沒說問題都要人看。

Copilot 的評論回覆有個細節：你回覆它，其他人看得到，但它看不到。想讓它重審，要重新請求審查。

讓審查更有效的三個前提

1. 可驗證的目標。Cursor 官方列的三樣：測試抓行為迴歸、類型檢查抓結構錯誤、lint 抓風格和模式問題。這些檢查越齊全，越能放心把工作交給智能體。
2. 讓智能體補測試。過去補測試成本高，現在可以讓它寫，再由你核對。見《用 AI 寫單元測試》。
3. 反饋環要快。測試套件跑 10 分鐘、同時開 10 個智能體，就是近兩小時的等待。加快測試、精簡依賴、優化 CI，對每一次會話都有回報。

常見誤區

「AI 審過了就可以合併」。預設情況下 Copilot 的審查不計入必需審批，這是有意的設計。讓 AI 審查直接放行，等於去掉了最後一道人工關。

「讓同一個對話自己審自己」。它帶着寫代碼時的全部假設，容易認為自己是對的。

「審查意見全盤接受」。AI 的建議也可能是錯的，或者和項目約定衝突。每條建議都要判斷，一鍵應用之前先看 diff。

「大 PR 一次丟給它」。上下文越大，漏的越多。拆小再審。

「把私有代碼貼到隨便哪個聊天窗口裏審」。先確認工具的數據政策和公司規定，見《AI 編程安全注意事項》。

參考資料

• Reviewing and testing code（Cursor 官方教學）：https://cursor.com/learn/reviewing-testing
• Bugbot（Cursor 官方）：https://cursor.com/docs/bugbot
• About GitHub Copilot code review（GitHub 官方）：https://docs.github.com/en/copilot/concepts/agents/code-review
• Using GitHub Copilot code review on GitHub（GitHub 官方）：https://docs.github.com/en/copilot/how-tos/copilot-on-github/use-copilot-agents/copilot-code-review
• Best practices（Claude Code 官方）：https://code.claude.com/docs/en/best-practices