PR 审查
这些规则适用于任何审查者，无论是人类还是代理（Copilot 代码审查、Claude 等）。相关的技能 github 涵盖了作者方面的内容：修复评论、回复以及请求下一轮审查。如果仓库自身的审查规则（AGENTS.md、CONTRIBUTING.md、风格指南）与本技能冲突，则以仓库规则为准。
审查的目标是让一个正确的 PR 被合并。它的目标不是找话说。“未发现问题”是一个好的结果。
提出问题的标准
只有在你能指出一个真实的故障场景时，才提出问题：一个真实的调用方、输入或配置，以及它产生的错误结果。如果你无法用一两句话描述这个场景，就不要提出。
| 严重性 | 使用场景 |
|---|---|
| 阻塞 | 常见路径上的错误结果、安全漏洞、数据丢失、构建或测试失败、对公共 API 的破坏性变更，或明显违反仓库中已记录的规则 |
| 应修复 | 在不太常见的路径上存在真实错误、新行为缺少测试，或文档、指令会导致读者在正常情况下做错事 |
| 小幅问题 | 命名、措辞或小的清晰度修复。可选。每轮审查最多三个，且仅在第一轮中提出 |
不要提出：
- 需要不切实际的输入、配置错误的环境或攻击者已经拥有攻击本应授予的访问权限的假设性问题。
- 针对无调用方能达成的场景的防御性代码（如“考虑添加空值检查”）。
- 仓库中的格式化工具、linter 或类型检查器已强制执行的内容。
- 两种合理方法之间的个人偏好。
- 没有热点路径或测量数据支持的性能问题。
- 要求扩大 PR 范围的请求：功能、重构或清理等 PR 未打算处理的内容。
- PR 未更改的代码中的问题，除非 PR 使问题变得更糟。如果存在严重问题，可以提一次，标记为 预先存在，不阻塞。
对于文档、技能和其他指导，只问一个问题：遵循此文本的读者在正常情况下是否会做错事？罕见配置的漏洞最多算是小幅问题。不要要求写出每一种边缘情况。
多轮审查中的收敛
PR 应随着每轮审查变得更安静，而不是更嘈杂。
- 第 1 轮（首次审查）：完整差异，所有严重级别，小幅问题按上述上限处理。
- 第 2 轮及之后（自上次审查以来的新提交）：
- 仅审查自上次审查以来的变更，并检查你先前提出的问题是否已修复。
- 不要对你已审查且未发生变更的代码提出新的问题。如果你在那里遗漏了某些内容，仅当其是阻塞问题时才提出。
- 无小幅问题。
- 不要重新提出作者已给出理由回复的问题，除非你有新证据表明该理由错误。仅仅意见分歧不是新证据。
- 如果没有符合标准的问题，用一行说明并停止。不要填充审查内容。
撰写问题
- 每条评论一个问题，锚定到它所涉及的行。
- 以严重级别开头：
阻塞:、应修复:或小幅问题:。 - 然后用一两句话描述故障场景，然后提出最小可行的修复方案。
- 每次审查最多五个问题，最严重的优先。如果问题更多，在摘要中简要列出其余问题。将重复的问题合并为一条列出所有位置的评论。
- 保持具体和中性。不要添加赞美性的填充词，也不要使用委婉的“你可能需要考虑”。
摘要
以简短的摘要结束：
- 结论：批准、批准（附小幅问题） 或 请求变更（仅当至少有一个阻塞性问题时）。
- 按严重级别计数。
- 在第 2 轮及之后：哪些先前的问题现已修复，哪些仍然未解决。
在循环中作为代理进行审查
当另一个代理正在修复你提出的问题并请求你进行下一轮审查时：
- 将作者的回复视为审查的一部分。“已在 abc1234 中修复”意味着检查该提交。“保留原样，因为……”意味着除非理由错误，否则该问题已关闭。
- 三轮之后，仅提出阻塞性问题，并说明剩余事项由作者决定。