写在前面
代码Review有两种：一种是走过场——快速扫一遍，没有明显语法问题就点Approve；另一种是真正有效的Review——找出潜在Bug、安全漏洞、性能瓶颈、设计问题，防止技术债务积累。
做好Review需要时间和精力，但大多数团队的Review质量都停留在”走过场”。原因很简单：真正深入的Review太费时间，在交付压力下，这件事很难做到位。
Claude 4.6能补这个缺口：它可以作为你的第一道审查，把明显的问题过滤出来，让人工Review聚焦在更需要业务和上下文判断的地方。
基本用法：定制化的Review提示词
代码Review的提示词质量决定输出质量。不要只发”帮我Review一下这段代码”，要把Review的维度和优先级说清楚。
请以严格的代码审查者身份Review以下代码，
这是一个电商平台的支付处理模块，数据安全和金融准确性至关重要。
审查维度和优先级：
P0（必须修复，否则不能合并）：
- 安全漏洞（SQL注入、XSS、敏感信息泄露、未授权访问）
- 金融计算精度问题（浮点数精度、四舍五入规则）
- 可能导致资金错误的逻辑Bug
P1（强烈建议修复）：
- 未处理的错误情况（特别是数据库操作、外部API调用）
- 并发安全问题（竞态条件、超卖、重复扣款）
- 性能问题（N+1查询、没有索引的大表查询）
P2（建议但非强制）：
- 代码可读性
- 测试覆盖缺失
- 更好的实现方式
输出格式：
每个问题：[优先级] [文件:行号] 问题描述 | 风险说明 | 修改建议
最后给出：整体评价、是否建议合并（合并/有条件通过/需要大改）
[粘贴代码]
场景一：安全审查
安全Review是最需要系统性检查的场景，人工容易遗漏。
请对以下Node.js代码进行安全专项Review，
这是对外暴露的API接口，处理用户提交的数据：
重点检查（按严重程度）：
1. 输入验证和过滤
- 是否对所有用户输入做了验证（不只是格式验证，还有长度、类型、范围）
- 文件上传：MIME类型检查、文件大小限制、存储路径安全
2. SQL/NoSQL注入
- 参数化查询还是字符串拼接
- ORM是否正确使用（ORM也可能有注入漏洞）
3. 认证和授权
- 每个接口是否有认证检查
- 有没有水平越权（A用户能看B用户的数据）
- 有没有垂直越权（普通用户能调用管理员接口）
4. 敏感信息处理
- 日志里有没有打印密码、token、信用卡号
- 错误响应里有没有暴露过多内部信息
- 密码存储是否用了合适的哈希算法（bcrypt/argon2）
5. 其他
- CSRF防护
- 速率限制
- HTTPS强制
[粘贴代码]
场景二：性能Review
请Review以下代码的性能问题，
这是一个处理订单列表的接口，在数据量大时响应很慢：
关注点：
1. 数据库查询
- 有没有N+1查询
- SELECT *是否必要（是否加载了不需要的字段）
- 查询条件是否有对应索引
- 大数据量下的分页策略是否合适
2. 内存使用
- 有没有把大量数据加载到内存再处理
- 数组/对象操作是否有不必要的复制
3. I/O操作
- 串行的I/O操作是否可以改为并行
- 有没有可以缓存但没有缓存的数据
4. 算法复杂度
- 有没有在循环里做了O(n)的查找（应该用Map）
- 有没有明显的O(n²)操作
请针对每个问题，估计对性能的影响级别（高/中/低），并给出具体的优化代码。
[粘贴代码]
场景三：并发安全Review
Review以下代码的并发安全问题，
这是处理库存扣减的逻辑，在高并发场景下可能出现超卖：
检查要点：
1. 共享资源的读-改-写操作：有没有使用原子操作或锁保护
2. 数据库事务：多步操作是否在同一个事务里
3. 缓存一致性：缓存和数据库的更新顺序是否正确
4. 幂等性：同一个请求重复发送会不会造成重复操作
[粘贴代码]
场景四：Review整个PR diff
真实工作场景里，Review的是PR diff，不是单个文件。
以下是一个PR的完整diff，修改了用户注册模块：
[粘贴git diff输出]
请做全面的Review，注意：
1. 前后变化的上下文（旧代码改了什么，是否引入了新问题）
2. 修改是否完整（有没有应该一起改但没改的地方）
3. 测试用例是否更新（新增功能有没有对应测试）
4. 有没有意外的副作用（改了A的代码，但可能影响B）
场景五：架构级Review
不只是代码本身，还要Review架构决策：
我们正在设计一个新模块，以下是设计方案和相关代码，
请从架构层面做Review：
设计目标：[描述]
当前设计：[描述类/模块划分、数据流]
代码实现：[粘贴核心代码]
架构Review问题：
1. 这个设计是否满足业务需求（有没有遗漏的场景）
2. 模块划分是否合理（职责是否清晰，有没有不该在一起的逻辑）
3. 未来扩展性如何（预计的变化方向，现有设计能否应对）
4. 与现有系统的集成是否有潜在的冲突
5. 有没有更简单的实现方案（YAGNI原则）
给Review结果写回复
有了Claude的Review，还需要把结果整理成合理的PR评论：
以下是Claude给出的代码Review结果，
帮我把它转化成适合在GitHub/GitLab PR里发表的评论：
要求：
- 使用建设性的语气，而不是批判性的
- P0问题要明确标记为"必须修改"
- P2问题用"建议"或"可以考虑"这样的措辞
- 每条评论要有具体的改进建议，不只是指出问题
- 对代码里做得好的地方，也给出正面评价
Claude的Review结果：
[粘贴Review结果]
建立团队Review规范
用Claude帮你建立团队的Review规范文档：
我们团队的代码Review目前不够规范，
请帮我起草一份《代码Review规范》文档，适合10-20人的开发团队：
包含以下内容：
1. Review的目标和原则（什么是好的Review）
2. 提交Review的准备工作（PR提交者应该做什么）
3. Review的必查清单（Reviewer应该检查什么）
4. 问题分级标准（什么级别的问题必须修复才能合并）
5. Review的沟通规范（如何给出建设性的评论）
6. 常见的Review反模式（要避免的错误）
7. Review时间标准（多久应该完成Review）
语气：实用、直接，不要写成空洞的理念文章。
如何用上Claude 4.6做代码Review
最简单的方式是在claude.ai网页版直接粘贴代码。如果想把Review集成到Git工作流里，可以用Claude API在GitHub Actions里自动触发。
国内用户注册需要海外邮箱和接码平台手机号。如果想把Claude集成进CI/CD流程（自动触发PR Review），需要API接入，国内开发者可以通过 Code80 接入，支持国内支付，换个endpoint配置即可使用。详情：code.ai80.vip
常见问题
Q：Claude做代码Review会比有经验的工程师更准确吗？
A：不一定更准确，但更全面。Claude不会因为疲劳漏掉安全检查，不会因为跟作者关系好就手软，也不会忘记检查某类问题。它的价值是”系统性”，而不是”比人更聪明”。对于需要业务上下文判断的问题，人工Review仍然不可替代。
Q：把代码发给Claude，有数据泄漏风险吗？
A：通过API调用（包括Code80渠道），Anthropic官方承诺不将API调用内容用于模型训练。对于包含商业机密的核心代码，可以先做变量名替换脱敏，再交给Claude Review——Review质量不会因此明显降低。
Q：Claude找出的安全漏洞可靠吗？会不会有误报？
A：Claude的安全审查能覆盖常见的OWASP Top 10漏洞，准确性相当高。对于False Positive（误报），Claude通常会给出理由，你可以据此判断是不是真实问题。不建议跳过验证，直接按Claude说的改——先理解问题再改。
Q：如果Review发现了很多P0问题，需要重写怎么办？
A：把Review结果和原始需求一起给Claude，让它给出重构建议而不是补丁式修复。很多时候大量P0问题背后是设计层面的缺陷，修补表面不如重新设计。
评论前必须登录！
立即登录 注册