Claude Code 评审流程检查清单：发布前抓住 PR 风险

前三行决定评审深度

如果你觉得 Claude Code review 很浅，原因通常不是模型不会审代码，而是请求里没有说明范围、风险、已执行的验证和下一步判断。只写“帮我 review 这个 PR”，很容易得到礼貌但没抓住重点的总结。

这里的“评审流程”不是让 AI 随便发表意见，而是把差异、风险、证据和交接格式固定下来。对新手来说，diff 是“这次改了什么”，review gate 是“合并或发布前必须经过的关口”，verification receipt 是“执行了什么检查、结果如何、还有什么风险”的记录。

Claude Code 的基础能力可以看官方 Claude Code overview 和 common workflows。Pull request 评审规则以 GitHub pull request reviews 为准；Node 项目的命令行为可以对照 npm scripts。站内可以继续读 Claude Code 代码评审清单 和 verification receipt workflow。

Claude Code 看到 diff 之前，人先整理输入

评审质量主要取决于四类信息：Scope、Risk、Evidence、Handoff。没有这些，Claude Code 会倾向于写“代码整体不错”这种安全但没价值的内容。

信息	作用	弱写法	强写法
Scope	限定变更范围	改了一些内容	只改文章 CTA 链接、文案和移动端间距
Risk	说明影响	应该没问题	产品、咨询、内部链接会影响收入路径
Evidence	说明验证	本地看过	npm run build 成功，360px 宽度检查了 CTA
Handoff	定义输出	帮忙看看	按 P1/P2/P3 返回 findings、残余风险和下一步检查

flowchart LR
  A["Diff"] --> B["Scope and risk"]
  B --> C["Claude Code review"]
  C --> D["Human decision"]
  D --> E["Fix, verify, or ship"]
  E --> F["Review receipt"]

边界要明确：Claude Code 是第二双眼睛，不是最终批准人。它可以减少遗漏、提出测试和指出假设，但是否修复、重新验证或发布，仍由 PR 负责人判断。

评审前检查清单

先收集工作区状态和验证命令。下面是 Node 项目的例子，其他技术栈可以替换成 go test ./...、pytest 或团队 CI 命令。

git status --short
git diff --stat
git diff --name-only
npm run build
npm run test -- --runInBand

然后把下面的清单放进 PR 描述、.github/review-checklist.md 或团队 Wiki。

# Claude Code Review Checklist

## Scope
- [ ] This PR has one clear purpose.
- [ ] Changed files match the stated purpose.
- [ ] No unrelated formatting, dependency, or generated files are mixed in.

## Risk
- [ ] Risk level is marked as low, medium, or high.
- [ ] User-facing routes, forms, auth, billing, analytics, and CTA paths are named.
- [ ] Rollback or recovery steps are written for high-risk changes.

## Evidence
- [ ] Build, test, lint, or typecheck commands are listed with results.
- [ ] Manual checks include browser width, account state, and actual URL when relevant.
- [ ] Screenshots, logs, or console output are attached for UI and integration changes.

## Review output
- [ ] Findings come first, ordered by severity.
- [ ] Each finding has file reference, reproduction condition, and expected fix.
- [ ] Residual risk is written even when no blocker is found.

这份清单的目的，是让 Claude Code 找发布风险，而不是评价代码“好不好看”。

可直接使用的评审提示词

提示词可以很短，但输出格式要严格。特别是 findings first、severity order 和 do not rewrite code yet。

Review this diff with a bug-finding mindset.

Scope:
- Only review the files changed in this PR.
- Do not rewrite code yet.

Prioritize:
1. behavioral regressions
2. security, privacy, or permission mistakes
3. missing tests or weak verification
4. broken mobile layout, internal links, product CTA, or training CTA

Return:
- Findings first, ordered by P1/P2/P3 severity
- File and line references when possible
- Why each issue matters to users or revenue
- Checks I should run next
- Residual risk if no blocker is found

先让 Claude Code 只审查，不要直接改代码。否则评审和修复混在一起，团队很难判断哪些问题真正值得阻塞发布。

四个实用场景

第一个场景是 CTA 和收入路径。文章底部、产品卡、价格文案或咨询链接变更时，要检查目标 URL、商品是否匹配、按钮顺序、移动端布局和 analytics 事件。常见失败是按钮写着“模板”，却仍然跳到旧 Gumroad 商品。文中应该自然指向 /zh/products/ 和 /zh/training/。

第二个场景是认证、权限和隐私数据。隐藏 UI 按钮不等于服务端授权。Claude Code 应该检查谁可以执行、谁必须被拒绝、日志是否暴露 email 或支付 ID、测试是否覆盖拒绝路径。只看可读性而漏掉越权，是高风险 PR 的典型问题。

第三个场景是多语言发布。一个语言读起来很自然，另一个语言可能 updatedDate 旧、code fence 没关、产品链接缺失或出现乱码。提示词里要写清楚允许触碰的 locale 文件、必须保留的 metadata，以及必须扫描 mojibake。

第四个场景是 build 或 test 失败排查。不要把整段巨大日志丢给 Claude Code。给失败命令、最后相关日志、失败前的 diff 和已尝试的修复即可。落坑点是为了修一个小 build error，顺手更新依赖或重构无关文件。

常见失败和规避方式

“请 review 全部”是最常见的坏请求。范围太大时，Claude Code 会输出安全的泛泛建议。更好的写法是列出文件、风险和明确不在范围内的内容。

第二个失败是没有证据。npm run build、typecheck、浏览器路径、移动端布局是否验证过，如果不写清楚，评审只能猜。没执行也要写原因，例如“未执行：依赖未安装”。

收入路径还有单独的坑：只看桌面端、不点真实链接、不确认 /products/ 和 /training/ 顺序。CTA 的换行、横向滚动、目标页错误，都会直接影响转化。

安全方面，不要把 API key、token、客户 email、支付 ID 或私有内容贴进提示词。日志要先缩小到最小复现信息。

用脚本检查 verification receipt

下面的 Node 脚本会检查 review receipt 是否包含必要章节，并且至少有一个勾选过的命令。它不是完整质量保证，但能避免“没有证据就发布”的流程问题。

{
  "requiredSections": ["Scope", "Risk", "Checks run", "Findings", "Residual risk"]
}

#!/usr/bin/env node
const fs = require("node:fs");

const receiptPath = process.argv[2] || "review-receipt.md";
const policyPath = process.argv[3] || "review-policy.json";
const receipt = fs.readFileSync(receiptPath, "utf8");
const policy = fs.existsSync(policyPath)
  ? JSON.parse(fs.readFileSync(policyPath, "utf8"))
  : { requiredSections: ["Scope", "Risk", "Checks run", "Findings", "Residual risk"] };

const escapeRegExp = (value) => value.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
const missingSections = policy.requiredSections.filter((name) => {
  const heading = new RegExp(`^## ${escapeRegExp(name)}\\b`, "m");
  return !heading.test(receipt);
});

const hasCheckedCommand = /^- \[(x|X)\] `(npm|pnpm|yarn|node|pytest|go test|cargo test)/m.test(receipt);

if (missingSections.length || !hasCheckedCommand) {
  for (const section of missingSections) console.error(`Missing section: ${section}`);
  if (!hasCheckedCommand) console.error("Missing checked command evidence such as - [x] `npm run build`");
  process.exit(1);
}

console.log("Review receipt passed.");

# Review receipt

## Scope
Article CTA links and mobile layout only.

## Risk
Medium: product and training links affect revenue.

## Checks run
- [x] `npm run build` passed
- [x] mobile CTA path checked at 360px

## Findings
- P2: Product CTA text and destination mismatch on one locale.

## Residual risk
Analytics event names were not checked in production.

团队可以把同样思路放进 PR 模板、Claude Code prompt 或轻量 CI 检查。

下一步

个人开发者可以先用免费 Claude Code cheatsheet固定日常命令和安全提示词。如果 review、debug、triage prompt 总是重写，建议使用 Prompt Templates 和 /zh/products/ 里的模板。

团队真正困难的不是一个聪明 prompt，而是 CLAUDE.md、权限边界、review gate、verification receipt 和最终批准责任。要把这些落到真实 repository，可以从 /zh/training/ 开始设计导入流程。