AI 程式碼審查
OpenClaw 當你的 Senior Engineer —— 7×24 在線,每一行程式碼都認真看
Code Review 的現實
等 Review 等到花都謝了
提了 PR,Senior 在忙別的專案。過了兩天終於 Review 了,就留了句「LGTM」。要麼等太久,要麼根本沒認真看 —— 你說這 Review 有什麼用?
更頭疼的是團隊裡每個人標準不一樣。張三覺得這麼寫沒問題,李四說必須改。到底聽誰的?統一標準?開三次會也定不下來。
OpenClaw:7×24 在線的 Senior Engineer
把程式碼丟給 OpenClaw,它會按業界最佳實踐逐行審查:安全漏洞、效能瓶頸、可維護性、邊界情況,全部覆蓋。
不用排隊,不用看人臉色,不會因為「太忙」就隨便 LGTM。而且每次審查的標準完全一致 —— 再也不用在群裡吵「這到底算不算問題」了。
3 條 Review Prompt,複製就能用
從安全審查到設計原則,按需選用。
Review PR:安全 + 效能專項審查
黃金指令
請 Review 以下程式碼變更(PR diff),重點關注:
1. 安全漏洞:SQL 注入、XSS、CSRF、敏感資訊洩露、不安全的反序列化
2. 效能問題:N+1 查詢、不必要的記憶體分配、未加索引的查詢、阻塞操作
3. 邊界情況:空值處理、並發競爭、超大資料量場景
對每個問題給出:
- 嚴重等級(Critical / Warning / Suggestion)
- 具體位置(檔案名 + 行號)
- 修復建議和示例程式碼
最後給出整體評價和是否建議合併。
這條適合提交 PR 前自己先過一遍,能抓到大部分常見安全問題。建議用 Claude Opus 4.6,它對跨檔案的安全風險理解更準。
SOLID 原則合規檢查
進階技巧
請檢查以下程式碼是否符合 SOLID 原則:
- S(單一職責):這個類/函式是不是幹了太多事?
- O(開閉原則):新增功能需要改現有程式碼嗎?
- L(里氏替換):子類能安全替換父類嗎?
- I(介面隔離):介面是不是太胖了?
- D(依賴倒置):高層模組直接依賴了底層實現嗎?
對每個違反的原則:
1. 說明具體違反了什麼,在哪裡
2. 為什麼這是個問題
3. 給出重構方案和程式碼示例
這條適合 Review 核心業務邏輯或者基礎架構程式碼。日常的 CRUD 小介面沒必要上這個。
資料庫查詢 N+1 問題排查
黃金指令
請分析以下程式碼中的資料庫查詢:
1. 找出所有 N+1 查詢問題:
- 標出循環中觸發的查詢
- 計算最壞情況下的查詢次數
2. 給出優化方案:
- 哪些可以用 JOIN 合併
- 哪些可以用 eager loading / preload
- 哪些需要加快取
3. 寫出優化後的程式碼
4. 估算優化前後的效能差異
ORM 框架是 [你的框架,如 SQLAlchemy / Prisma / ActiveRecord]。
N+1 是最常見的效能殺手之一,清單頁一慢先查這個。記得把 ORM 框架名替換成你實際用的。
程式碼審查:OpenClaw vs GitHub Copilot
都能 Review 程式碼,但方式完全不同。
OpenClaw
- 能看到整個專案的上下文,跨檔案理解業務邏輯
- Prompt 完全自訂,按你的團隊規範來審查
- 可以切換模型:簡單 Review 用 GPT-4o,複雜架構用 Opus 4.6
- Review 結果可以導出、存檔、作為團隊知識庫
VS
GitHub Copilot Code Review
- 集成在 GitHub PR 介面,觸發方便
- 審查範圍主要是 diff 內容,跨檔案理解有限
- 模型固定,無法自訂審查規則
- 對中文註解和變數名的理解偶爾翻車
真實場景
創業團隊:兩個後端扛全部程式碼
團隊就俩後端,互相 Review 經常漏掉問題,上線後出 Bug 才發現。
OpenClaw 方案
提 PR 前先用 OpenClaw 做一輪安全 + 效能審查,把明顯問題過濾掉,人工 Review 只需要關注業務邏輯。上線事故率降了一半,Review 時間從平均 2 天縮到半天。
純人工方案
兩個人互相 Review,忙的時候只能 LGTM。程式碼標準全靠口頭約定,新人來了又得重新培訓一遍。
幾點實用建議
別把整個專案一次性丟給 AI Review。按模組分批來,每次聚焦一個關注點(比如安全、效能、可讀性),效果更好。
AI Review 不是替代人工 Review,是在人工之前先過一遍。讓機器抓格式和常見問題,讓人關注設計和業務邏輯。