Claude Code First PR Review Rubric：先抓真实风险，再看风格问题

如果直接让 Claude Code 评审 PR，生产回归和命名建议可能被放在同一层级。看起来很多产出，但评审者很难判断什么必须阻塞合并。

这篇文章建立第一版 PR 评审 rubric。先定义 P0 到 P3、证据、评论格式和重试规则，再让 Claude Code 阅读 diff。

相关阅读: claude-code-code-review-checklist, claude-code-prompt-library-maintenance, claude-code-pull-request-quality. 官方文档基线: Anthropic Claude Code docs.

为什么要在第一条命令前决定

在风格反馈之前发现回归、权限风险、数据丢失和测试缺口

关键是不要把第一条请求写得太大。先写清阅读范围、禁止触碰的区域、第一步动作和验证命令，Claude Code 就不容易把任务扩展到无关修改。

已经用 Claude Code 做 review，但需要更精准问题的开发者

实际工作流程

1. 在 diff 前贴目标和改动文件
2. 评审前定义 P0 到 P3
3. 禁止没有证据的推测评论
4. 要求测试、build 或复现证明
5. 把 P3 风格建议放到最后

场景	交给 Claude Code 的工作	人工确认的证据
认证 PR	先把 token 保存和权限边界当作 P0	build, diff, URL
UI 修复	把不可点击和移动端破版当作 P1	build, diff, URL
重构	把行为不变证明和测试缺口分到 P2	build, diff, URL

有了这些证据，Claude Code 的结果就能用可观察的工作来判断，而不是只看一段自信的总结。

可复制的提示词和代码

请用 P0/P1/P2/P3 严重度评审这个 PR diff。P0 指安全、数据丢失、支付、认证或生产事故。每条发现都包含行号、失败场景、需要的证据和修复建议。纯风格反馈放在最后。

const reviewRubric = {
  P0: "security, data loss, payment, auth, production outage",
  P1: "user-visible regression or broken release path",
  P2: "test gap, unclear edge case, maintainability risk",
  P3: "style, naming, or optional cleanup"
};

function classifyReviewFinding(finding) {
  const text = finding.toLowerCase();
  if (/auth|token|payment|delete|secret|production/.test(text)) return "P0";
  if (/regression|broken|crash|deploy/.test(text)) return "P1";
  if (/missing test|edge case|unclear/.test(text)) return "P2";
  return "P3";
}

console.log(classifyReviewFinding("missing test for failed payment retry"));

真实例子和失败模式

场景	交给 Claude Code 的工作	人工确认的证据
认证 PR	先把 token 保存和权限边界当作 P0	build, diff, URL
UI 修复	把不可点击和移动端破版当作 P1	build, diff, URL
重构	把行为不变证明和测试缺口分到 P2	build, diff, URL

• 如果先看命名和格式，Claude Code 会用低风险评论填满 review。
• 没有严重度时，支付 bug 和标点问题会混在同一列表。
• 不要求证据时，看似合理但未验证的评论会增加。

关键是不要把第一条请求写得太大。先写清阅读范围、禁止触碰的区域、第一步动作和验证命令，Claude Code 就不容易把任务扩展到无关修改。

把证据包留下来

在风格反馈之前发现回归、权限风险、数据丢失和测试缺口 如果只停留在一次聊天里，价值会很快消失。更好的做法是保存成证据包：原始请求、Claude Code 阅读的文件、没有触碰的区域、执行的命令、公开URL或截图，以及仍然不确定的判断。下一次 session 就能复用同一套判断，而不是重新解释背景。

对已经用 Claude Code 做 review，但需要更精准问题的开发者来说，第一天不需要完整的团队制度。先在一个 PR、一条笔记或一次部署上使用这个流程。失败时，把失败原因写回 checklist，再用更小的版本重试。只有在 build、diff、URL、CTA、rollback 证据都可见之后，才扩大 Claude Code 的访问范围。证据不足时扩大权限，看似更快，实际会把验证成本留给后面的人工 review。

收入路径也遵循同样原则。读者还卡在基础命令时，免费PDF是下一步。读者每周重复同类 prompt 时，Gumroad 教材更合适。读者要做团队或生产判断时，咨询更合适。文章不是把所有人都推去购买，而是只把需要 PR 评审提示词和可复用 rubric 的读者送到付费教材，其余读者回到免费PDF和相关文章。

还要留下一个判断分支。Claude Code 的建议是直接采用、缩小范围，还是先补一个验证步骤，都用一句话写下来。PR 评审可以写「没有 P0，P1 是移动端破版，P2 是测试缺口」。Obsidian 到 issue 可以写「没有使用整篇笔记，只采用 CTA 改善」。deploy dry run 可以写「preview URL 正确，但 rollback owner 未设置，所以暂不生产部署」。

有了这句话，下一次选择 CTA 也更清楚。基础命令不熟的人去免费PDF，反复做同类工作的人去 Gumroad，卡在责任边界或生产权限的人去咨询。PR 评审提示词和可复用 rubric 对应的是已经可以自学、但需要带走一个稳定模板的读者。

把读者导向免费PDF、Gumroad 和咨询

如果基本命令还不稳定，先用 免费速查表 固定日常习惯。想深入 PR 评审提示词和可复用 rubric，请看 Gumroad 教材。如果需要团队导入、评审规则或收入路径设计，请进入 咨询；产品比较从 products 开始。

CTA 不应该只放在文章底部。开头适合免费PDF，实作例子之后适合 Gumroad 教材，涉及团队导入或生产风险时，咨询就是自然的下一步。

发布后要看的数字

发布后观察从这篇 review 文章到 Prompt Templates、未来 Code Review System 和咨询页的点击。

不要只看 PV。要分开看正文开头阅读、内部链接、免费PDF注册、Gumroad 点击和咨询页访问。HTTP 200、h1、canonical、heroImage、CTA 和本地化正文都必须指向同一个 slug。