本页速答
Claude代码审查提示词（2026-11-03）：声明语言与运行环境 → 选定审查维度（最多 3 个）→ 贴差异或文件 → 要求按严重级别列出问题，附大致行号/函数名 → 区分「缺陷 / 风格 / 纯猜测」。不要让它「随便看看有没有 bug」这种无边界请求。
| 意图 | 要它找什么 | 别混进来 |
|---|---|---|
| 正确性 | 边界、空值、并发 | 变量命名审美 |
| 安全 | 注入、鉴权、密钥 | 大规模重构建议 |
| 性能 | 热路径、N+1 | 未测量的微优化 |
| 测试 | 缺用例、脆弱断言 | 重写业务 |
审查范围怎么定
- 写明：语言、框架版本、是否生产代码。
- 提供：相关接口契约或调用方说明（可短）。
- 排除：生成全部重写，除非你明确要。
- 密钥：用占位符；真密钥轮换。
可复制审查提示词
你是资深代码审查员。语言={{lang}}；环境={{env}}。
只做这三项：{{正确性/安全/测试缺}}。
输出：
- [SEVERITY: high|mid|low] 标题
位置：函数/大致行
为何是问题（≤40字）
最小修复建议（不整文件重写）
置信度：高/中/低（低=需人工验证）
禁止：编造不存在的 API；把风格当高危。
代码：
```
{{paste}}
```
输出评分表（给你自己用）
| 项 | 通过标准 |
|---|---|
| 高危项 | 有测试或人工路径验证 |
| 模型低置信度 | 不盲目改 |
| 大重构建议 | 另开任务，不塞进热修 PR |
终端代理类工作流请去 Claude Code；不要与本文混搜。
三类真实场景怎么处理
场景 A：评审同事的 PR 片段
只贴 diff 与相关函数，声明「不评价人只评代码」。
场景 B：自己写完急着上线
先跑测试；再用提示词做安全窄审；高危项不过夜。
场景 C：遗留代码看不懂
先让它「解释控制流」再「找缺陷」，分两轮，避免一边解释一边乱改。
审查提示词的工程化用法
把代码审查提示词当成「可版本管理的检查单」，不要每次即兴写。团队可维护三种预设：正确性、安全、测试缺口。开 PR 时按变更类型点名调用，避免一次要求「安全+性能+风格+架构」导致模型泛泛而谈。输出必须带置信度，低置信度项默认人工验证。
贴代码时优先最小复现：相关函数 + 调用方 + 接口注释。整仓库粘贴会稀释注意力，也增加泄密面。对于 diff，说明「+ 是新增，- 是删除」，并声明旧行为是什么。若审查前端，注明浏览器与框架；若审查后端，注明并发模型与数据存储。
安全窄审可固定清单：注入、鉴权绕过、敏感日志、SSRF、路径穿越、密钥硬编码。让模型逐项给「通过 / 存疑 / 未覆盖」。未覆盖不等于安全，只代表本次片段看不见。性能审查则要求指出「需要测量才能成立」的建议，防止把微优化写成高危。
- 一轮一个主意图；二轮再问「还有哪些低置信度风险」。
- 禁止默认「重写整个文件」；要最小补丁思路。
- 测试缺口：列出缺少的边界用例标题即可，不必立刻生成万行测试。
- 与 Claude Code 分工：聊天审查想法与清单；终端代理改大仓库另谈。
把审查结论贴回 PR 描述时，删掉模型的虚词，保留可验证条目。若模型建议升级依赖或改架构，另开设计讨论，不塞进热修复。API 集成代码还可对照 API 入门 的职责边界，避免把密钥塞进前端示例。
多语言与生成代码的额外约束
审查由模型生成的代码时，额外要求「指出可能幻觉的 API」。你提供官方文档链接或本地类型定义，能显著降低编造方法名。对基础设施脚本（IaC、CI），强调幂等与回滚，不要只看「能不能跑通一次」。
审查结果如何变成可合并变更
模型给出一串问题后，你要做分诊：热修、可跟随、忽略、需设计评审。提示词可要求它预分诊，但最终标签由你定。热修项必须能写清复现；写不清的先补测试或日志，再改代码。
对「建议重写」保持怀疑。让模型回答：「最小可行补丁是什么？重写的收益是否覆盖回归成本？」若答不出量化或可验证收益，降级为备忘。风格问题交给 linter/formatter，不要占用审查模型的高危名额。
安全项处理流程：确认是否可达 → 写复现 → 修 → 加回归测试 → 轮换可能泄露的密钥。不要只改表面字符串。若审查对象包含基础设施，额外确认最小权限与审计日志是否仍在。
- 分诊标签：热修/跟随/忽略/评审。
- 最小补丁优先。
- 安全项必有回归。
- 风格交给工具链。
记住本文不是安装教程；终端代理与仓库级工作流去 Claude Code。聊天里的审查提示词可以和 Code 流程并存：先审查定范围，再在工具里改。
审查提示的版本管理建议
把提示词放进仓库 docs/review-prompts.md，用语义化版本。变更时写清：新增了哪条安全检查、删除了哪条易误报规则。新人 onboarding 先跑同一段故意含缺陷的示例代码，校准「什么算高危」。这样审查标准不随个人心情漂移。
对生成式代码（模型写的）增加专项：幻觉 API、过时写法、许可证危险依赖。对人工代码则更关注业务边界。两者不要混用同一套权重。完成后在 PR 模板勾选「已跑窄意图审查」即可，不必粘贴模型全文。
误报与漏报怎么对待
审查模型会误报：把风格当缺陷，或在看不懂框架时吓你。要求它写置信度并给「为何可能误报」。漏报更危险：关键路径没贴全。所以审查范围声明必须诚实。宁可缩小范围跑两次，也不要假装看完整个单体仓库。
将反复出现的误报规则从提示中删除或降级，把反复漏报的模式写成强制检查项。这就是提示词迭代，与产品功能迭代一样需要记录。
审查与测试的衔接
审查列出的缺陷，若缺少复现，先补最小测试再改代码。可让模型「为高危项各写一个失败用例标题与断言意图」，你再实现。不要接受无测试的大规模重写建议。把「先测后改」写进团队规范，审查提示词才能转化为质量，而不是评论区。
对遗留代码，允许「理解轮」与「缺陷轮」分离：先解释数据流，确认你的理解，再允许挑错。混合进行时，模型容易在解释中顺便提出不成熟重构，干扰焦点。
常见问题
这是 Claude Code 教程吗？
不是。Code 产品另见 Claude Code 专页；本文只谈聊天审查提示词。
一次审查多少代码合适？
优先单文件或单 PR 片段；过大则按目录拆。
模型说「没问题」就合并？
不行。关键路径仍需测试与人工把关。
能审查私有仓库密钥吗？
先脱敏；密钥应用密钥管理，勿贴进对话。
中英文注释怎么要求？
在提示里规定报告语言与是否保留标识符原文。
和 API 编程有关吗？
API 集成见 API 入门；审查提示词可共用结构。