让 Claude Code 审查聚焦真实缺陷

Claude Code 在大仓库里做代码审查，难点往往是让它少提无关意见，把真正影响合并的问题留下来。作者给出的办法是：写清项目约定，只审查本次变更，把安全检查单独跑一轮，再由人决定是否合并。

这套流程值得借鉴，因为它把 AI 审查变成了可核查、可修正的工程步骤。不过，原文提供的是作者的使用经验，没有量化对照，不能据此断言它一定省时、省钱。

为什么先写清楚哪些问题不用管

作者开头用「40 条评论里有 38 条在谈命名」描述 AI 审查的噪声。这是引出问题的场景，不是正式实验数据。

他们感受到的最大改善，来自把资深工程师会告诉新同事的事情写进仓库里的 CLAUDE.md：审查什么、忽略什么，以及哪些项目约定不能靠猜。

下面这份配置同时约束审查重点和项目事实：

## CLAUDE.md

## Review priorities
1. Correctness: logic errors, unhandled errors, race conditions.
2. Security: input validation, secrets, permission checks.
3. Breaking changes to public APIs or database schemas.

## Ignore in reviews
- Formatting and import order (handled by the linter).
- Naming preferences unless a name is actively misleading.

## Project facts
- All money values are integers in cents.
- Database access goes through the repository layer, never raw SQL in handlers.

重点看 Ignore in reviews：格式、import 顺序交给 linter，命名只有在确实误导读者时才值得评论。作者认为，这份忽略清单消除了大部分噪声，但没有给出具体降幅。

项目事实也很重要。比如「金额使用整数分」可以帮助模型判断金额计算，「数据库访问经过 repository 层」则提供了检查分层约定的依据。缺少这些背景，模型容易拿通用习惯评价项目内部合理的实现。

为什么审查入口应该是 diff

让 AI 审查整个大型项目，容易得到泛泛的建议。作者改为把当前分支相对 main 的变更传给非交互式运行的 Claude Code，同时限定输出内容：

git diff main...HEAD | claude -p "Review this diff using the priorities in CLAUDE.md. \
List only issues that could cause a bug, a security problem, or a breaking change. \
For each, give the file, the line, and a one-sentence reason."

重点看最后一行：每个问题都要提供文件、行号和一句理由。这样人才能直接定位代码，判断模型说得对不对。作者称这种输出便于人工在两分钟内检查，但没有提供计时记录。

这条命令保留了原文写法；作者也明确提醒，接进脚本前应核对所用 Claude Code 版本的当前文档，确认参数。原文没有指定版本号。

运行时机和变更大小也要控制。作者只在 PR 创建或标记为 ready 时运行，避免每次 push 都触发。对于巨大 diff，建议按目录拆分审查；平时则尽量提交小 PR。至于多大算巨大、成本会增加多少，原文没有说清。

安全单独检查，误报回写成文档

虽然示例中的通用审查已经包含安全问题，作者仍主张增加一轮范围更窄的安全检查，专门寻找代码中的 secrets、缺失的权限检查，以及未经验证就进入数据库查询的输入。

理由是，一个提示词同时承担正确性、风格和安全检查，容易每项都做得不够深入。安全结果放进同一个 PR，单独标记，方便审查者集中核查。这是作者的经验判断，原文没有提供两种提示方式的对照结果。

AI 提供第一轮问题清单，人负责最终合并决定。

作者举出的 AI 用途包括发现遗漏的 null 检查、被 catch 吞掉的错误；人则把更多注意力放在设计和意图上。他们还有两条规则：没有具体行号的评论不处理；确认属于误报的意见，要把相关约定补进 CLAUDE.md。

这种反馈能逐步沉淀项目知识。不过，文档应该记录误报背后的有效规则，避免为了消除一次错误判断，写下会屏蔽真实问题的宽泛禁令。

我的判断

我认可这套流程对职责的划分：linter 处理机械规则，AI 检查可能影响行为的变更，人判断设计是否符合需求。比起追求评论数量，这更接近代码审查真正要解决的问题。

但它依赖两个前提：项目约定能被准确写下来，人工也愿意核实并维护这些约定。仅有 diff 和一份文档，未必足够判断跨模块调用、权限继承或数据库约束，必要时仍需补读相关代码。

单独跑安全检查也不能直接替代已有的静态分析、依赖扫描或人工安全审查。原文没有展示漏洞检出率、漏报率和实际费用，也没有证明拆分提示一定优于单轮审查，因此应把它当作待验证的团队实践。

作者建议统计 AI 评论中有多少促成代码修改、有多少被驳回，这是实用的起点。不过，修改数量还需结合问题严重程度和核查耗时，才能判断是否真正有帮助。

能拿来做什么

• 在前端或 Node 仓库的 CLAUDE.md 中写入真实约定，优先补充金额单位、错误处理方式和数据访问边界，并把已有 linter 覆盖的事项列入忽略范围。
• 在 PR 创建或转为 ready 时运行 diff 审查，要求每条意见包含文件、行号和一句理由，让人工能逐条验证。
• 对涉及输入、权限和数据库访问的变更单独跑安全检查，并将结果单独标记，方便人工集中核查。
• 记录评论被采纳或驳回的原因；持续出现同类误报时，收紧审查规则，同时观察人工核查时间是否下降。