|

用 Claude Code 做 Code Review 的 25 个实用提示词：从安全审查到架构评审

作者APIYI - Stable and affordable AI API

作者注：收集 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 最高频的场景，附提示词编写公式和好坏对比。

claude-code-code-review-prompts-collection-guide 图示

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
- 排序是否使用了合适的算法

标注当前复杂度 → 可优化到的复杂度 → 具体优化方案。

claude-code-code-review-prompts-collection-guide 图示

场景四：架构评审（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。

claude-code-code-review-prompts-collection-guide 图示

常见问题

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 提示词的核心要点：

  1. 25 条提示词覆盖 7 大场景: 安全审查（4）、Bug 检测（4）、性能分析（3）、架构评审（4）、PR Review（4）、可读性（3）、重构建议（3）——直接复制使用
  2. 好提示词的五要素公式: 角色 + 范围 + 重点 + 格式 + 严重级别。像测试用例一样精确，不像 Slack 消息一样模糊
  3. 三层 Review 体系: 内置命令（/security-review）→ 自定义提示词（本文 25 条）→ /loop 自动化持续 Review

推荐通过 API易 apiyi.com 以八折价格接入 Claude Opus 4.6 API，构建自动化 Code Review 系统。

📚 参考资料

  1. Claude Code Code Review 官方文档: 内置 Review 功能完整说明

    • 链接: code.claude.com/docs/en/code-review
    • 说明: 包含 PR Review、多 Agent 系统和定制方法

  2. Claude Code Security Review: Anthropic 官方安全审查方案

    • 链接: github.com/anthropics/claude-code-security-review
    • 说明: 包含 /security-review 命令的完整实现

  3. 7 个 Claude PR Review 提示词: 社区验证的 Review 提示词

    • 链接: rephrase-it.com/blog/7-claude-pr-review-prompts-for-2026
    • 说明: 包含 PR 审查的结构化提示词模板

  4. API易文档中心: Claude Opus 4.6 API 八折接入

    • 链接: docs.apiyi.com
    • 说明: 构建自动化 Review 系统的最优 API 方案

作者: APIYI 技术团队
技术交流: 欢迎在评论区讨论，更多资料可访问 API易 docs.apiyi.com 文档中心

Try AI Large Model https://api.apiyi.com for free
Stable and reliable AI LM API aggregation service, Get 300 Millions Tokens for Free~

类似文章