code-review

审查拉取请求

参数：$ARGUMENTS — PR 编号或 URL，和／或一种模式。BUGS、SECURITY 或 PERFORMANCE 会将审查范围限定为相应方面；否则审查所有方面。

输入

如果直接粘贴了差异内容 → 只审查这些文本，不获取其他内容。否则，使用 PR 编号或 URL；若未提供，则使用当前分支的 PR → gh pr view + gh pr diff。如果没有找到 PR → 请对方提供一个。

批准标准

只要变更确实提升了整体代码质量，即使并不完美，也应批准。不要因为变更没有采用你会使用的写法就阻止它。如果变更改善了代码库并遵循其惯例，就应批准。

如果变更太大，无法有效审查（约 1000 行以上），可以要求作者拆分。建议一种拆分策略：堆叠（先提交较小的变更，再基于它提交下一项）、按文件组拆分、横向拆分（先改共享代码，再改使用方），或纵向拆分（每个 PR 完成一个端到端切片）。

审查标准

审查每个有变更的文件，而不只是最新提交。先审查测试：它们是否测试了行为、涵盖了边界情况，以及能否发现回归？如果已在本地检出该分支，通过实验回答最后一个问题：反转这次变更新增的一个条件，运行测试套件，再还原文件。如果测试仍全部通过 → 缺少测试；请指出缺失的测试。如果与其他 Agent 并行审查 → 跳过实验：test-auditor 会在临时副本中运行变异测试，而直接修改文件会产生竞争。

• 正确性：逻辑错误、差一错误、竞态条件、未处理的状态、缺失的错误处理路径
• 可读性：超过 50 行的函数、超过 2 层的嵌套、死代码、未使用的导入
• 安全性：暴露的密钥、未经验证的外部数据
• 类型安全与不可变性：any 或缺乏理由的类型断言；原地修改共享数据
• 模式：是否符合代码库惯例，是否避免重复造轮子
• 性能：不必要的重新渲染、明明 O(n) 可行却采用 O(n²)
• 代码异味：对照基线 smells.md 检查差异中的问题——始终需要结合判断；仓库中记录的风格优先于基线
• 依赖升级（差异中包含清单／锁文件）：每次变更只升级一个依赖——批量升级一旦出现问题，就无法确定是哪个包导致的；依据变更日志核实，而非版本号；审查锁文件差异（升级一个直接依赖会带来数十项传递依赖的变更）；标记手动编辑的锁文件

输出

按严重程度分组，每条发现都标注 file:line，并为每个 Critical 项提供建议的修复方案：

• Critical — 合并前必须修复（错误、漏洞）
• 建议 — 值得考虑的改进
• Nit — 细微且可选；真正的吹毛求疵应标记为 Nit，而不是省略或夸大
• FYI — 仅供参考
• 优点 — 值得指出的良好模式
• 已验证 — 运行了哪些内容（测试、构建、实验），以及仅阅读了哪些内容

一个结构性问题和十个细枝末节：结构性问题才是这次审查的重点——应优先提出。最后根据批准标准给出结论。