评审评分表

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

六个维度

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

结论选项

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

校准说明（重要）

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

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

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

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

本项目的评审补充

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

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

和 Quality Document 的区别

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

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