# 评审评分表

> 会话结束后或到里程碑时，用它评估 agent 做的东西够不够格。
> 每个维度 **0–2 分**，满分 12 分。

## 六个维度

| 维度 | 0 分 | 1 分 | 2 分 |
|---|---|---|---|
| **正确性** | 实现出来的行为不符合目标功能 | 主要路径对，边界情况有问题 | 行为符合目标功能，边界情况也考虑到了 |
| **验证** | 没跑任何检查，或只有"应该没问题" | 跑了检查但没留证据 | 要求的检查都跑了，命令与结果都记录在仓库内 |
| **范围纪律** | 顺手改了一堆无关的东西 | 基本在范围内，有个别越界 | 严格保持在选定功能范围内 |
| **可靠性** | 重启或重跑后行为不一致 | 重跑能过，但依赖临时状态 | 结果能在重启或重跑后继续工作 |
| **可维护性** | 代码和文档乱到下一轮接不上 | 能看懂，但需要口头补充 | 清楚到足以直接交给下一轮会话 |
| **交接准备度** | 新会话完全无法只靠仓库内文件继续 | 能继续，但要先猜一阵 | 新会话只靠仓库内文件即可推进 |

## 结论选项

| 结论 | 含义 |
|---|---|
| **Accept** | 达标 |
| **Revise** | 需要修补才能接受 |
| **Block** | 有根本性问题，需要先解决 |

## 校准说明（重要）

> **开箱即用的 agent 做评审很弱——它会发现问题，然后把自己说服到通过。**

所以 evaluator 需要校准，预计需要 **3–5 轮**：

1. 用 evaluator 给一个**已完成**的 sprint 打分
2. 把它的分数和你自己的人工判断对比
3. 有分歧的地方，把 rubric 里的通过/失败标准**写得更具体**
4. 对同一个输出**重新跑** evaluator，看对齐了没有
5. 重复直到 evaluator 的判断和人工评审基本一致

每轮记录改了什么、为什么改。

## 本项目的评审补充

除了六个通用维度，本项目的输出还要额外看：

- **是否保持了界面基线** —— 有没有擅自新增/改动样式、可选项、文案、筛选逻辑
- **是否走了适配层** —— 新协议能力有没有通过翻译成原内容标记来复用既有渲染组件，
  而不是新写一套 UI
- **是否用真实后端验证** —— 涉及接口的改动，是否对 `http://192.168.2.23:8000` 实测过
- **是否诚实记录了刻意状态** —— 例如部门筛选的空列表是按要求保持的，
  如果被当成 bug"修掉"了，属于范围违规

## 和 Quality Document 的区别

| 工具 | 回答的问题 |
|---|---|
| Evaluator rubric | 这轮 agent 做得好不好？ |
| Quality document（本项目暂未引入） | 这个项目是在变强还是变弱？ |

本项目规模尚小，暂未引入 quality document；等进入多模块、多阶段演化时再考虑。