Code Review 准则，可更新到.agent/rules/rule.md

可更新到.agent/rules/rule.md

https://claude.dev/blog/solving-code-review-at-anthropic/

Code Review 准则（review时遵守）：

• 目标：用最少的人工时间换来不增加回滚和事故。只报真正会出问题的点，不追求“读完每一行”。

• 先对齐意图：对照当前需求 / PR 意图和整个仓库审 diff，回答三个问题：是否真正解决了问题、是否符合现有系统与约定、是否会破坏别处。bug 修复必须确认改的是根因而不是绕过症状。

• 意见必须有证据：每条给出 文件:行号 和触发条件 / 复现路径，不凭命名或猜测下结论。拿不准的先自己验证（读调用链、跑类型检查 / 测试），仍无法确认的标“待确认”，不要当成 bug 报。

• 先自证再交付：自己改完代码，在说“完成”之前先跑能跑的检查（类型检查、lint、测试、build，UI 改动截图对照），以真实输出为准。

• 降噪：可从多个角度找问题，但报出前逐条复核，确认是真问题才保留。纯风格、命名偏好、格式、“可以更优雅”之类的意见直接丢掉；Nit 最多 3 条。

• 分级标注并按严重程度排序：

  • Important：会导致 bug、安全、数据或计费问题，必须处理；
  • Nit：小问题，可选；
  • Pre-existing：不是本次改动引入的老问题，单独列出，不算本次作者的锅，不要求本次修。

• 输出格式：开头先给数量（如“2 个 Important，1 个 Nit”）；没有问题就直接说“没有需要修的”，不要硬凑意见。

• 按风险决定深度：文案、文档、样式、加在开关后面的新增改动快速过；支付 / 计费 / 积分扣减、鉴权登录、权限、数据库迁移、webhook、CI / 部署配置、密钥与环境变量必须深审，并在结论里明确提示“这块建议人工再看一眼”。

• 安全单独过一遍：越权 / 缺少鉴权（尤其 server action、API route）、SSRF、注入、密钥泄露到前端、未校验的外部回调。

• 报一类而不是报一处：发现某类问题时指出模式并列出全部出现位置，让作者一次改全，避免下一轮又冒出同类。

• review 必须收敛：

  • 同一改动最多 3 轮，第 3 轮后仍有 Important 就停下来，建议退一步换方案，而不是继续打补丁；
  • 第 2 轮起只审新增的 diff；
  • 已经提过的意见不重复提；
  • 复审时不去翻第一轮就已存在的老代码（这类最多归入 Pre-existing）。

• 可回滚：较高风险的改动检查是否容易回滚（开关、可逆迁移、单独提交），并在结论里一句话说明怎么回滚。

• 同一类意见反复出现时，建议沉淀进本 rule.md 或 lint 规则，从源头解决。