用 Claude Code 做 Code Review 的 25 個實用提示詞：從安全審查到架構評審

作者注：收集 25 個經過實戰驗證的 Claude Code Code Review 提示詞，覆蓋安全審查、性能分析、架構評審、Bug 檢測、PR Review 等 7 大場景，附提示詞編寫公式

Claude Code 自帶 /security-review 命令和 Code Review 多 Agent 系統，但默認的 Review 輸出往往太囉嗦、事無鉅細都要點評。好的 Review 提示詞應該像測試用例一樣精確——定義範圍、設定優先級、要求給出具體行號和修復建議。本文收集了 25 個覆蓋 7 大場景的 Code Review 提示詞，從安全審查到架構評審，每個都可以直接複製使用。

核心價值: 25 個提示詞覆蓋 Code Review 最高頻的場景，附提示詞編寫公式和好壞對比。

Review 提示詞編寫公式

好的 Review 提示詞像測試用例一樣精確。差的 Review 提示詞像模糊的 Slack 消息。

五要素公式

[角色] 以資深 {語言/領域} 工程師的角度
[範圍] 審查 {文件/目錄/PR} 的 {變更內容}
[重點] 重點關注 {安全/性能/邏輯/架構}
[格式] 輸出格式：{編號列表/表格/行內註釋}
[級別] 標註嚴重級別：{Critical/High/Medium/Low}

要素	差的示例	好的示例
角色	（沒設定）	"以資深後端工程師角度"
範圍	"看看這段代碼"	"審查 src/auth/ 最近的 git diff"
重點	"給點反饋"	"重點關注 SQL 注入和認證繞過"
格式	（隨便輸出）	"編號列表，每項包含文件:行號、問題描述、修復建議"
級別	（沒要求）	"標註 Critical/High/Medium/Low"

場景一：安全審查（4 條提示詞）

安全審查是 Code Review 中優先級最高的場景。Claude Code 自帶 /security-review 命令，但自定義提示詞可以做得更深。

提示詞 #1：OWASP Top 10 全面掃描

以安全審計工程師角度，審查 src/ 目錄下最近修改的所有文件。
按 OWASP Top 10 逐項檢查：
1. 注入（SQL/NoSQL/命令注入）
2. 認證缺陷
3. 敏感數據暴露
4. XXE
5. 訪問控制缺陷
6. 安全配置錯誤
7. XSS
8. 反序列化
9. 使用有漏洞的組件
10. 日誌和監控不足

輸出格式：編號列表，每項包含 [文件:行號] [嚴重級別] [問題描述] [修復建議]。
只報告實際存在的問題，不要報告理論風險。

提示詞 #2：API 端點安全審查

審查所有 API 路由文件（routes/、controllers/），重點檢查：
- 是否有缺少認證中間件的端點
- 參數是否做了輸入驗證和消毒
- 是否存在批量賦值（mass assignment）風險
- 速率限制是否配置
- 錯誤響應是否泄露了內部信息

輸出表格：端點路徑 | 問題 | 嚴重級別 | 修復方案

提示詞 #3：敏感信息泄露檢測

掃描整個項目，檢查以下敏感信息是否被硬編碼或意外暴露：
- API Key、Secret、Token
- 數據庫連接字符串
- 私鑰和證書
- 內部 IP 和域名
- 註釋中的密碼或憑證

檢查範圍包括：源代碼、配置文件、.env.example、docker-compose.yml、README
標註每個發現的文件路徑和行號。

提示詞 #4：認證和授權邏輯審查

以安全專家角度，審查認證和授權相關代碼：
1. JWT token 驗證邏輯是否完整（過期、簽名、篡改）
2. 密碼存儲是否使用了安全哈希（bcrypt/argon2）
3. Session 管理是否有固定會話攻擊風險
4. CORS 配置是否過於寬鬆
5. OAuth 回調是否驗證了 state 參數

只報告 Critical 和 High 級別的問題，附修復代碼示例。

場景二：Bug 檢測（4 條提示詞）

提示詞 #5：空指針和邊界條件

審查最近修改的文件，尋找以下潛在 Bug：
- 未檢查 null/undefined 就訪問屬性的地方
- 數組越界訪問
- 除零錯誤
- 空字符串未處理
- parseInt/parseFloat 未處理 NaN

對每個發現，給出觸發條件（什麼輸入會導致崩潰）和修復代碼。

提示詞 #6：異步和併發問題

審查項目中所有異步代碼（async/await、Promise、回調），檢查：
- 是否有 Promise 沒有 catch 錯誤處理
- 是否有競態條件（race condition）
- 是否有 await 在循環中導致串行執行（應該用 Promise.all）
- 是否有 callback hell 可以重構
- 事務是否正確處理了回滾

標註 [文件:行號] [問題] [影響] [修復方案]

提示詞 #7：邏輯錯誤獵手

仔細閱讀以下函數的業務邏輯，尋找：
- if/else 分支是否覆蓋了所有情況
- 循環的終止條件是否正確
- 比較運算符是否正確（== vs ===，> vs >=）
- 變量作用域是否正確
- 返回值是否在所有路徑都有定義

不要關注代碼風格，只關注邏輯正確性。

提示詞 #8：錯誤處理審查

審查項目的錯誤處理機制：
1. try/catch 塊是否捕獲了具體異常而非泛型 Error
2. catch 塊是否只是吞掉了錯誤（空 catch）
3. 錯誤是否被正確傳播到上層
4. 用戶可見的錯誤消息是否友好（不暴露內部信息）
5. 關鍵操作（支付、數據變更）是否有失敗回滾機制

按嚴重級別排序輸出。

場景三：性能分析（3 條提示詞）

提示詞 #9：數據庫查詢性能

審查所有數據庫查詢代碼（models/、repositories/、ORM 調用），檢查：
- N+1 查詢問題（循環中執行查詢）
- 缺少索引的查詢字段
- SELECT * 是否應該替換爲具體字段
- 大數據量查詢是否有分頁
- 是否有可以用緩存優化的重複查詢

對每個問題估算性能影響（低/中/高），給出優化後的代碼。

提示詞 #10：內存和資源泄漏

審查項目中可能的內存和資源泄漏：
- 事件監聽器是否在組件卸載時移除
- 定時器（setInterval/setTimeout）是否有清理
- 數據庫連接是否正確關閉
- 文件句柄是否在 finally 中釋放
- 大數組/對象是否在使用後解引用

重點關注 React 組件的 useEffect 清理和 Node.js 的流處理。

提示詞 #11：算法複雜度審查

審查最近修改的函數，分析時間和空間複雜度：
- 是否有 O（n²） 或更高複雜度的實現可以優化
- 是否有可以用哈希表替代線性搜索的地方
- 是否有不必要的深拷貝
- 字符串拼接是否應該用 StringBuilder/join
- 排序是否使用了合適的算法

標註當前複雜度 → 可優化到的複雜度 → 具體優化方案。

場景四：架構評審（4 條提示詞）

提示詞 #12：依賴和耦合度分析

分析 src/ 的模塊依賴關係：
1. 畫出模塊間的依賴圖（哪個模塊 import 了哪些模塊）
2. 找出循環依賴
3. 找出耦合度最高的模塊（被其他模塊依賴最多）
4. 建議哪些依賴應該通過接口/抽象解耦

輸出：依賴關係表 + 循環依賴列表 + 解耦建議

提示詞 #13：分層架構合規檢查

檢查代碼是否遵循分層架構原則：
- Controller 層是否包含業務邏輯（應該只做路由和參數校驗）
- Service 層是否直接操作數據庫（應該通過 Repository）
- Model/Entity 層是否包含 HTTP 相關邏輯
- 是否有跨層調用（Controller 直接調 Repository）

列出每個違反分層原則的文件和具體代碼位置。

提示詞 #14：API 設計評審

以 RESTful API 設計最佳實踐角度，審查所有 API 端點：
- URL 命名是否遵循 REST 約定（複數名詞、層級關係）
- HTTP 方法使用是否正確（GET 只讀、POST 創建、PUT 更新、DELETE 刪除）
- 響應格式是否一致（錯誤碼、分頁格式、時間格式）
- API 版本控制是否到位
- 是否有可以合併的冗餘端點

輸出：改進建議表（當前 → 建議 → 原因）

提示詞 #15：技術債評估

對項目進行技術債全面評估：
1. 過時的依賴包和框架版本
2. 棄用的 API 調用
3. 硬編碼的配置值（應該用環境變量）
4. 複製粘貼的重複代碼塊
5. 缺少單元測試的關鍵模塊
6. 過於複雜的函數（圈複雜度 > 15）

按修復緊迫性排序：阻塞（必須立即修復） > 高 > 中 > 低

場景五：PR Review（4 條提示詞）

提示詞 #16：PR Diff 快速審查

審查當前分支與 main 的 diff，以資深工程師角度評估：
1. 這個 PR 的目的是什麼（從 diff 推斷）
2. 變更是否完整（是否有遺漏的文件或邏輯）
3. 是否引入了新的 Bug 或迴歸
4. 測試覆蓋是否充分
5. 是否有不必要的變更（調試代碼、格式化噪音）

只報告 High 和 Critical 級別的問題。不要 nit-pick 代碼風格。

提示詞 #17：向後兼容性檢查

審查當前 PR 的所有變更，檢查是否有向後不兼容的改動：
- 公共 API 接口是否改變了簽名或返回值
- 數據庫 schema 是否有 breaking change
- 配置文件格式是否變化
- 是否刪除了其他模塊正在使用的函數
- 是否改變了環境變量的名稱或格式

對每個不兼容項，評估影響範圍和遷移方案。

提示詞 #18：測試充分性審查

對比當前 PR 的代碼變更和測試變更：
1. 新增的函數是否都有對應的單元測試
2. 修改的邏輯是否更新了已有測試
3. 邊界條件和異常路徑是否有測試覆蓋
4. 集成測試是否覆蓋了新的 API 端點
5. 測試數據是否合理（不是隨意的 123、abc）

列出缺失的測試用例建議：函數名 | 缺少的測試場景 | 優先級

提示詞 #19：Commit 質量審查

審查當前 PR 的 commit 歷史：
1. commit message 是否清晰描述了變更內容
2. 每個 commit 是否是原子性的（一個 commit 一個目的）
3. 是否有可以 squash 的瑣碎 commit
4. 是否有"fix typo"、"wip"等應該清理的臨時 commit
5. commit 順序是否符合邏輯（先基礎設施後業務邏輯）

建議需要整理的 commit 和最終的 commit 結構。

場景六：可讀性（3 條提示詞）

提示詞 #20：命名審查

審查最近修改的文件中所有變量、函數、類的命名：
- 是否有含義模糊的名稱（data、info、temp、res、obj）
- 是否有縮寫過度（usr → user、btn → button）
- 是否有布爾值命名不以 is/has/should 開頭
- 函數名是否以動詞開頭準確描述行爲
- 類名是否以名詞準確描述職責

對每個不良命名，給出更好的替代名稱。

提示詞 #21：註釋質量審查

審查代碼中的註釋質量：
- 是否有"what"註釋應該改爲"why"註釋
- 是否有過時的註釋（與代碼不一致）
- 是否有應該被提取爲函數名的註釋
- 複雜業務邏輯是否缺少解釋性註釋
- 公共 API 是否有 JSDoc/docstring

不要建議添加顯而易見的註釋（如 "// increment counter"）。

提示詞 #22：函數拆分建議

審查所有超過 30 行的函數，評估是否應該拆分：
- 函數是否有多個職責（做了多件不相關的事）
- 嵌套層級是否超過 3 層
- 參數數量是否超過 4 個
- 是否有可以提取的重複邏輯

給出具體的拆分方案：原函數 → 拆分後的函數列表 → 每個函數的職責。

場景七：重構建議（3 條提示詞）

提示詞 #23：DRY 違反檢測

掃描項目中的重複代碼：
- 找出 3 行以上的重複代碼塊
- 找出邏輯相似但寫法不同的代碼
- 找出可以提取爲工具函數的公共模式

對每組重複代碼，給出提取爲公共函數的具體實現代碼。

提示詞 #24：設計模式優化

以設計模式專家角度審查代碼：
- 大量 if/else 或 switch 是否應該用策略模式
- 複雜對象創建是否應該用工廠/建造者模式
- 重複的模板代碼是否應該用模板方法模式
- 多層嵌套回調是否應該用責任鏈模式
- 全局狀態管理是否應該用觀察者模式

只在模式改進能顯著降低複雜度時才建議，不要過度設計。

提示詞 #25：遺留代碼現代化

審查項目中的遺留代碼，找出可以用現代語法重寫的部分：
- var → const/let
- 回調函數 → async/await
- for 循環 → map/filter/reduce
- 字符串拼接 → 模板字符串
- require → import
- Class → 函數組件 + Hooks（React）

給出重構前後的代碼對比，評估重構風險（低/中/高）。

🎯 使用建議: 建議把最常用的 Review 提示詞保存到 CLAUDE.md 或 .claude/skills/ 中，團隊統一標準。通過 /loop 可以讓安全審查和 PR Review 自動化運行。
如果你通過 API 構建自動化 Review 系統，推薦通過 API易 apiyi.com 以八折價格接入 Claude Opus 4.6。

常見問題

Q1: 默認的 /code-review 太囉嗦怎麼辦？

在項目根目錄創建 REVIEW.md 或在 CLAUDE.md 中添加 Review 規則，明確告訴 Claude 只關注什麼、不要關注什麼。比如："只報告 Critical 和 High 級別的問題。不要 nit-pick 代碼風格和命名。不要建議添加註釋。"Claude Code 會在每次 Review 時自動讀取這個文件。

Q2: 怎麼把提示詞保存爲可複用的 Skill？

在 .claude/skills/security-review/SKILL.md 中保存你的安全審查提示詞，設置 user-invocable: true，它就會註冊爲 /security-review 斜槓命令。以後輸入 /security-review 就能直接執行，不用每次複製粘貼。多個提示詞可以保存爲多個 Skill。

Q3: PR Review 能自動發到 GitHub 評論嗎？

可以。兩種方式：1）在 PR 評論中輸入 @claude review，Claude 會自動分析 diff 並以行內評論形式發表發現；2）用 /code-review --comment 命令，Claude 會把 Review 結果作爲 PR 評論發佈。Anthropic 在 2026 年 3 月發佈了專門的 Code Review 多 Agent 系統，能調度一組專業 Agent 從安全、邏輯、測試等多個角度審查 PR。

Q4: Review 提示詞消耗多少 Token？

取決於審查範圍。單文件審查約 2000-5000 Token，全項目安全掃描可能 10000-30000 Token。建議用具體的文件/目錄範圍限制審查範圍，避免"掃描所有文件"浪費 Token。通過 API易 apiyi.com 以八折價格接入 Claude Opus 4.6，可以顯著降低 Review 成本。

總結

Claude Code Code Review 提示詞的核心要點：

25 條提示詞覆蓋 7 大場景: 安全審查（4）、Bug 檢測（4）、性能分析（3）、架構評審（4）、PR Review（4）、可讀性（3）、重構建議（3）——直接複製使用
好提示詞的五要素公式: 角色 + 範圍 + 重點 + 格式 + 嚴重級別。像測試用例一樣精確，不像 Slack 消息一樣模糊
三層 Review 體系: 內置命令（/security-review）→ 自定義提示詞（本文 25 條）→ /loop 自動化持續 Review

推薦通過 API易 apiyi.com 以八折價格接入 Claude Opus 4.6 API，構建自動化 Code Review 系統。

📚 參考資料

Claude Code Code Review 官方文檔: 內置 Review 功能完整說明
- 鏈接: code.claude.com/docs/en/code-review
- 說明: 包含 PR Review、多 Agent 系統和定製方法
Claude Code Security Review: Anthropic 官方安全審查方案
- 鏈接: github.com/anthropics/claude-code-security-review
- 說明: 包含 /security-review 命令的完整實現
7 個 Claude PR Review 提示詞: 社區驗證的 Review 提示詞
- 鏈接: rephrase-it.com/blog/7-claude-pr-review-prompts-for-2026
- 說明: 包含 PR 審查的結構化提示詞模板
API易文檔中心: Claude Opus 4.6 API 八折接入
- 鏈接: docs.apiyi.com
- 說明: 構建自動化 Review 系統的最優 API 方案

作者: APIYI 技術團隊
技術交流: 歡迎在評論區討論，更多資料可訪問 API易 docs.apiyi.com 文檔中心