评审

为什么需要这个工作流

一次评审的价值取决于两件事：评审对象是否被钉死，以及每条结论是否带证据。Review 先把比较点冻结——某个 diff、分支合并基，或当前未提交的改动——再从八个独立维度逐轴检查。每条发现都给出位置、证据和最小可信的修正方向。发现缺陷不等于获得修复权限。

流程逐阶段拆解

下面每一条规则都取自源仓库里的工作流定义——这就是智能体真正被要求做的事。

1. 01

   定义比较点

   先把评审对象钉死——移动的目标没法评审。

   • 你给了固定参照就用你给的。
   • 分支比较时，解析合并基，并检查提交记录和三点 diff。
   • 评审当前未提交的工作时，把已暂存、未暂存和相关未跟踪文件与 HEAD 比较。
   • 参照无效或范围为空时明确失败，绝不改去评审另一份改动。
2. 02

   还原意图

   先弄清这次改动"应该做什么"，再判断它"做了什么"。

   • 按优先级读：你这次的评审请求 → 项目指令 → 原始需求、问题、设计或验收标准 → 相关测试和文档。
   • 完全没有规格时，明确说明：这次评审能评估正确性风险和可维护性，但无法完整判断需求符合度。
3. 03

   八轴独立审查

   每一轴单独检查，绝不混成一句笼统印象。

   • 需求：缺失、部分实现、实现错误，或者根本没人要求的行为。
   • 正确性：边界情况、失败处理、并发、状态，以及对调用点的影响。
   • 安全：权限、信任边界、数据完整性、破坏性影响、兼容性和可访问性。
   • 设计：归属、语义复用、错误的去重、抽象成本和不必要的依赖。
   • 可读性：显式的流程与副作用、有意义的命名、局部可推理、可调试性，以及没有正当理由的新奇写法。
   • 测试：测试是否针对稳定的公共行为，以及它到底能不能发现这个缺陷。
   • 文档：过时或矛盾的事实，以及为迁就实现而被改写的需求。
   • 范围：无关改动、临时诊断代码、生成产物和未授权操作。
   • 不挑工具已经强制的偏好，也不提没有维护影响的纯主观替代写法。
4. 04

   报告发现

   按影响排序，每条都有证据，一个文件也不改。

   • 按影响排序输出发现。
   • 每条包含：严重程度、文件与精确位置、来自 diff 的证据和相关需求或不变式、对用户或维护的影响、最小可信的修正方向。
   • 重要发现不藏在总结段落里。
   • 确实没有实质发现时就直说，并写明验证缺口在哪里。
   • 全程不编辑文件、不提交、不推送。

不可绕过的规则

一次真实调用

从你发出的 token 到你拿回的证据，这次对话实际长什么样。

1. 智能体

   先确定范围：已暂存、未暂存和相关未跟踪文件，与 HEAD 比较。

2. 智能体

   读 docs/access-policy.md 和项目指令，还原这次改动"应该做什么"。

3. 智能体

   逐轴走完八个维度，把"权限校验发生在写操作之后"标为影响最大的发现。

4. 智能体

   按严重程度输出发现，每条附文件、行号、diff 证据、影响和最小修正方向——一个文件也没改。

什么时候用它

• 合并前想要一次独立检查。
• 评审对象是某个 diff、分支、PR 或未提交的改动。
• 你要的是问题报告，而不是被人默默改掉。
• 需要一份按严重程度排序、可以直接交给修复者的清单。

什么时候改用别的

常见问题