一个 reviewer 能抓住部分 bug。三个不同视角的 reviewer 几乎能抓住全部。
起因
2026 年 4 月 2 日。我们让一个 agent 做内部审查，对 30 个 PR 逐一检查 22 项 checklist。结果有两个 PR 被标记为”22/22 全绿”。
Coraline 检查了其中一个”全绿”PR，发现了明显的共性问题：config.py 字段缺 Field 注释、中文硬编码。我们复查另一个”全绿”PR——同样的问题。
两个”全绿”PR 都是误判。
单人审查不可信。不是因为 agent 不够好——是因为一个视角覆盖不了所有维度。PM 看不到视觉问题，设计师看不到功能问题，QA 看不到产品逻辑问题。
体系设计
三个独立 reviewer，三套独立 checklist，三个不同的专业视角：
| 审查者 | 视角 | 项数 |
|---|---|---|
| 奶茶（产品经理） | 需求合规、交互逻辑、边界情况、文案 | 28 项 |
| 可乐（视觉设计师） | 布局、色彩、字体、响应式、动效 | 26 项 |
| 牛奶（测试工程师） | 覆盖率、回归、性能、可访问性、错误处理 | 33 项 |
总计：87 项，三个视角。
流程
代码变更 │ ├──→ 产品审查（奶茶，28 项） ├──→ 视觉审查（可乐，26 项） └──→ 测试审查（牛奶，33 项） │ ▼ 交叉验证阶段 （每个 reviewer 检查其他人的发现） │ ▼ 问题合并去重（芋泥/架构师） │ ▼ 统一修复清单（含优先级）关键规则
三方都过才算过
三个 reviewer 必须独立通过。没有例外。不存在”这个改动很小，一个人看就行”。
因为”小改动”最容易引入问题——人的注意力和 agent 的上下文窗口都会因为”小”而放松警惕。
统一问题 Schema
所有审查发现遵循统一格式：
issue_id: VR-001page_or_module: Home Screenseverity: P1tags: [layout, responsive]suggested_fix: Adjust grid breakpoint at 375pxblocker: trueowner_role: tangyuansource_reviewers: [xiaomi, kele, yuni]统一格式的好处：
- 架构师可以自动去重（同一个根因，三个 reviewer 可能从不同角度报告）
- 工程师拿到的是一份清单而不是三份
- 可以按
severity自动排优先级 owner_role支持自动派工
问题合并节点
三方审查完成后，架构师（芋泥）执行合并：
- 去重：三个 reviewer 报告的”首页加载慢”可能是同一个根因
- 补全归因标签：
product/visual/arch/data/state/interaction - 统一优先级：PM 说 P2，QA 说 P1——以更严格的为准
- 双轨输出：
merged-review-issues.md（给人看）merged-review-issues.json（给 engine / 自动派工用）
全覆盖，不抽查
- 每个页面必须从顶部滚动到底部
- 每个可点击元素都要点
- 每个可触发的状态都要触发
- 代码层 + 渲染层 + 操作层
对照设计文档，而不只是 checklist
Checklist 抓的是通用问题（“按钮对齐了吗？”）。但 reviewer 还必须对照：
- 产品设计文档
- 视觉设计文档
- 架构设计文档
Checklist 抓”这个按钮对齐了吗”。设计文档对照抓”这个按钮应该存在吗”。
PR 前检查单
在提 PR 前，必须生成 pr-ready-checklist.md，至少包含：
- 三方 review 是否全部通过
- 年糕证据包路径是否存在
- 芋泥内审是否完成
- merged-review-issues 是否已清空
- 是否还有 blocker / high 风险未收口
这是一个硬门禁——不通过则工作流不会继续执行 push-and-pr。
实际效果
质量评分变化（一次 4 天工作流，4 轮审查）
| 维度 | 第 1 轮 | 第 4 轮 |
|---|---|---|
| API E2E 通过率 | 0%（5 个 blocker） | 100%（14/14） |
| 视觉设计评分 | 3.0/5 | 4.2/5 |
| 产品合规评分 | 3.0/5 | 4.0/5 |
审查体系演化
| 无审查（W1） | 单人审查（W2） | 三方审查（W3） | |
|---|---|---|---|
| 审查层数 | 0 | 1 | 3 |
| Checklist 项 | 0 | 22（不可信） | 87（逐条执行） |
| 误判率 | N/A | 高 | 低 |
| 证据支撑 | 无 | 无 | GUI 截图 + 测试报告 |
| 审查体系 | 无审查 | 单人审查（误判频发） | 三方审查（87 项 checklist） |
W2 单人审查频繁误判，质量问题漏到下游导致返工。
W3 引入三方审查后，问题在审查阶段就被拦住，返工率显著下降。
不只是 87 项 Checklist
Checklist 是必要条件，不是充分条件。
真正起作用的是三个不同专业背景的 reviewer 同时看同一份代码。PM 会发现”这个功能逻辑和 PRD 不一致”，设计师会发现”这个按钮在 375px 下溢出了”，QA 会发现”这个异常路径没有错误提示”。
没有哪一个视角能覆盖全部。这就是为什么必须是三方，而不是一个更厉害的 reviewer。