# 审阅设计与边界

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

本文描述实现，不把文章中的团队制度冒充为插件已经启用的功能。

## 状态机

~~~mermaid
flowchart LR
    S[固定代码快照] --> F[独立找问题与两个风险判断]
    F --> V[逐条独立复核与投票]
    V --> A[Deep 独立汇总]
    V --> G[证据、去重与处置把关]
    A --> G
    G --> C[当前快照的 AI 审阅结果]
    C --> H[仓库 CI、安全检查与人工批准]
    H --> R[仓库合并与发布制度]
~~~

每个结果必须携带 runId、targetId、taskId。原生任务返回值必须来自已完成的 activation.result；不从旧文件猜测任务成功。派发调用绑定真实 service receiver、当前调用 agent、结构化 prompt、cwd 和取消信号。

默认 spawn 不继承作者上下文。后端必须明确声明 inheritsParentContext=false。找问题、风险判断、复核、汇总各自使用新的子会话。独立上下文不代表模型统计独立，也不证明结论正确。

源码、差异、issue 和项目说明均视为审阅材料；它们不能授权扩大权限。检查经调用者的受控终端工具执行，使用相同权限、审批、取消与作业管理。只读环境使用静态代码证据。

## 快照与覆盖

HEAD、基准提交、补丁、实际文件内容、规则、指引和文件清单共同确定 targetId。文件清单由 NUL 分隔的 Git 输出获取，补丁单独解析。暂存区从索引取内容；提交比较使用 merge-base；工作区默认纳入未跟踪文件。

中文和转义路径保留原名。读取被截断、补丁无法解析、符号链接越界、状态损坏或结果缺少时，返回未完成/错误，不把它解释为零问题。二进制仍需人工或领域检查。

REVIEW.md 的全文和结构化规则进入审阅上下文；提交审查使用基准版本的规则，防止本次改动先放宽自己的审阅要求。项目说明文件不允许通过符号链接读取仓库外内容。

## 证据与问题生命周期

候选必须关联真实快照位置与本次引入行。复核者逐条尝试反驳，给出因果理由与可查源码见证，判断 confirm、reject、pre-existing 或 unverifiable。旧版本里有相同代码行本身不构成 pre-existing。

Standard/Deep 每条三个复核任务，至少两票同意才确认。证据冲突无法形成多数时留为未验证并阻止通过。Deep 汇总必须保留所有已确认编号，不能自行删掉阻塞问题。

指纹按文件、代码锚点、出现次数、类型和缺陷类别稳定去重；语义完全相同但表述/类别不同的问题，仍可能需要人工判断。所有已经发表的条目，包括启用的 nit 和 pre-existing，都必须说明处置。新目标上的旧问题会再次验证；代码未改时被反驳的旧结论计为 wrong，代码改变后确认消失才记为 fixed。

规则允许过滤风格类、压制 nit 和低于阈值的条目。过滤不是审查成功；完整执行、独立性、未验证数量和未解决问题仍分别检查。

## 收敛与预算

每个系列默认三轮已完成审阅。提交比较按仓库、分支与解析后的基准聚合；相同基准的不同 Git 别名不会重置轮次。工作区/暂存区在新的 HEAD 上开始新的局部系列。

第 3 轮的新增问题限定到相对上一完成轮次的真实差异，使用结构化 Git 比较计算行范围。旧的未解决问题不受新增问题过滤限制。新增文件不会因为以前没见过而漏审。

每次原生派发都计入预算，包括重试。并行度、候选数、输出大小与运行时长分别受限。取消必须等待宿主回收正在运行的子会话/命令。重复执行同一运行编号由租约阻止。

账本以事务重新读取最新状态，随机临时文件后原子替换。旧实例不得覆盖新数据；状态损坏保持阻塞。v1 账本保留备份，不继承“通过”结论。

## 文章各层如何落实

| 事项 | 实际交付 |
|---|---|
| 先核验，再给出审阅结论 | 独立复核、源码见证、受控检查收据 |
| 多视角找问题和投票过滤 | 分阶段原生子智能体；Quick 为轻量复核 |
| 安全层和检查阻塞 | 所有模式保留安全镜头；PR 策略还要求独立 CI/安全检查 |
| 风险决定人工要求 | 两次风险判断、敏感路径下限、可信作者策略 |
| 每条回应与有限复审 | 带理由的处置、自动重新验证、三轮限制、增量范围 |
| 事故与干净样本评测 | 不可变人工标签、精确运行绑定、逐缺陷计分及未运行覆盖 |
| 合并队列、开关与灰度 | 接入说明；必须由仓库和发布系统实际配置 |
| 人的责任和回滚 | PR 模板与接入指南，不能由模型自签批准 |

GitHub 门禁是只读证据核对，不会自行开启分支保护或合并。它要求基准提交中的固定策略、同一 HEAD 上的成功检查、已解决线程和可信审阅者名单中的独立真人批准。标准 GitHub PR review 无法让作者批准自己的 PR，因此此实现只计非作者的人类 review，比文章允许“负责人自己计一人”的团队制度更严格。未实现额外的负责人签认系统。

## 评测可以证明什么

登记项包含真实不可变提交、基准、人工确认的缺陷位置/类型/类别/锚点；expected=[] 明确表示干净样本。评测任务不携带事故答案和修复说明。执行者仍需使用隔离 checkout，避免未来提交、标签和其他结果泄漏。

计分使用该运行完成时冻结的预测，而不是后来可修改的账本。逐条一对一匹配，输出召回、精度、干净样本误报率、cohort 和未运行清单。未运行不记成已通过，任何不相关 finding 不算命中。

当前合成用例只证明流程和计分规则。没有人工标注的生产事故集、独立模型对照和持续观测数据时，不能声称生产召回率、节约人工时间或降低事故率。评测工具提供准备/计分能力，没有暗中创建定时任务或执行全量生产盲测。