Claude 能很快为一段差异写出许多意见，但“可能有问题”和“已经找到能触发问题的输入”价值不同。高效的审查应从变更目标开始，要求每个重要结论有代码位置、触发条件、影响和验证方法。本文用一个归档记录的编辑规则演示，关注如何形成可行动的审查意见。
一 选择正确的差异范围
审查已暂存但尚未提交的修改，可在仓库中运行 git diff --cached --no-ext-diff --no-textconv。审查工作区尚未暂存的修改则省略 --cached。如果比较分支，要先确认主分支名称和本地引用是否足够新，再选择比较基准，不要直接假定所有项目都叫 main。
Git diff 文档说明了这些差异范围。git diff --check 可帮助发现某些空白错误，却不能证明权限逻辑正确。把差异交给外部服务前，检查其中是否包含密钥、客户信息或私有数据；只提供任务需要且允许共享的片段。
还应附上规则、调用者和相关测试。只贴改动的那一行，模型可能不知道 archived 到底表示什么，或者权限是否已经在另一层验证。
二 一个会改变行为的改动
练习规则是：管理员或所有者可以编辑，但任何人都不能编辑已归档记录。某次整理括号后，代码变成：
- return (role === 'admin' || ownerId === userId) && !archived; + return role === 'admin' || ownerId === userId && !archived;
这里不需要凭风格判断。保存以下完整例子为 review-example.mjs，运行 node review-example.mjs：
import assert from 'node:assert/strict';
const changed = (role, owner, user, archived) =>
role === 'admin' || owner === user && !archived;
const corrected = (role, owner, user, archived) =>
(role === 'admin' || owner === user) && !archived;
assert.equal(changed('admin', 'u1', 'u2', true), true);
assert.equal(corrected('admin', 'u1', 'u2', true), false);
for (const [role, owner, user, archived, expected] of [
['admin', 'u1', 'u2', false, true],
['member', 'u1', 'u1', false, true],
['member', 'u1', 'u2', false, false],
['member', 'u1', 'u1', true, false],
['admin', 'u1', 'u2', true, false]
]) {
assert.equal(corrected(role, owner, user, archived), expected);
}
console.log('review counterexample and corrected cases passed');
这个反例证明：管理员访问已归档记录时，新表达式返回了 true，与练习规则冲突。审查意见可以写成“管理员分支绕过归档限制，触发输入为……”，而不是笼统说“括号不规范”。这只是演示用判断函数，真实授权还应在可信的服务端完成。
三 可复制的审查提示
请审查下面的 Git 差异。目标：重构编辑权限判断，保持行为不变。 业务规则：管理员或所有者可编辑，但任何人都不能编辑已归档记录。 我会提供差异、完整函数、调用位置和现有测试：[粘贴脱敏内容]。 每个问题请给：位置、触发输入、实际影响、支持结论的证据、最小修复和回归测试。 把确定问题、需要更多上下文的疑问、风格建议分开；证据不足时不要编造调用关系。 只审查，不扩大成架构重写；没有实际运行的测试请明确标注。
收到意见后，逐条检查它引用的代码是否真的存在。对“可能为空”“可能越权”等结论，要求给出入口条件与数据流；如果缺少调用者，就补上下文，而不是让它用想象补全。
四 让审查形成闭环
先在测试中加入最小反例，确认错误版本会暴露差异，再恢复正确逻辑并运行相关测试。本文独立例子已在 Node.js 24.19.0 执行，验证了反例与五组修正后输入；没有审查或修改任何真实仓库。
最终保留的是有证据的审查意见和回归用例。不要因为 Claude 回复“没有问题”就跳过人工审查，也不要把发现的每个风格偏好都升级为合并阻塞。能清楚解释触发条件与后果的结果，才值得进入团队的审查记录。
五 控制审查范围与信息量
较大的提交可以按行为边界分批审查，例如先看权限函数及其调用，再看界面文案。分批时必须保留跨文件依赖说明，避免模型把尚未提供的定义误判为缺失。审查记录最好注明比较基准与提交标识；代码继续变化后，旧行号和旧结论可能不再成立。复核时重新获取当前差异，再确认反例仍然适用，不要拿上一个版本的意见直接阻止新版本合并。
方法参考：Anthropic 提示工程概览。