2.9 KiB
2.9 KiB
评审评分表
在一轮（或几轮）会话实现完成后、正式验收前，用这张表做一次结构化评审，回答"这轮 agent 做得好不好"。 它评的是单次输出质量；代码库长期健康度见
quality-document.md。
评分维度
六个维度，每个 0-2 分（0 不满足 · 1 部分满足 · 2 满足）。
| 维度 | 问题 | 分数 (0-2) | 备注 |
|---|---|---|---|
| 正确性 | 实现出来的行为是否符合目标功能 / 验收标准？ | ||
| 验证 | 要求的检查是否真的跑过，并在对应任务文件（docs/tasks/T-<编号>.md）的 ## 执行记录 留下证据？ |
||
| 范围纪律 | 这一轮是否基本保持在选定的单个任务范围内？ | ||
| 可靠性 | 结果是否能在重启或重跑后继续工作？ | ||
| 可维护性 | 代码和文档是否清楚到足以交给下一轮会话？ | ||
| 交接准备度 | 新会话是否能只靠仓库内文件继续推进？ |
结论
从下面三选一：
- Accept — 达标，可验收。
- Revise — 需要修补才能接受（列出必须补的修复）。
- Block — 有根本性问题，需要先解决（列出阻塞项）。
独立评审门禁
如果任务声明了 review_mode: test 或 dual，评分前还要核对：
- 评审角色没有修改仓库、提交 Git 或直接更新 Gitea。
- 每个必需评审都记录了
reviewed_sha和ACCEPT/REVISE/BLOCK。 - 启用 PR 时，最终
reviewed_sha等于待验收的 PR head；未启用 PR 时，它覆盖最后一个实现变更提交，之后只有当前任务文件的评审证据提交。修复后不能继续沿用旧 SHA 的结论。 - 测试评审检查了验收标准、边界 / 失败路径、回归范围和实际命令证据。
dual模式的安全/架构评审检查了权限、秘密、数据风险、模块边界、公共接口、依赖和回滚。- 未解决的
BLOCK、critical 或 high 发现存在时，结论不得为 Accept。
review_mode: none 不要求为了形式启动评审 Agent，但仍必须满足自动验证和本表六个评分维度。
后续动作
- 缺失的证据：
- 必须补的修复：
- 下次复审触发条件：
关于校准（重要）
开箱即用的 agent 做评审很弱——它会发现问题，然后把自己说服到通过。所以这张表的通过/失败标准需要反复校准到和人工判断一致：
- 用本表给一个已完成的任务打分。
- 把它的分数和你自己的人工判断对比。
- 有分歧的地方，把对应维度的"什么算 2 分 / 什么算 0 分"写得更具体，落到本项目的真实验收标准上。
- 对同一个输出重新打分，看是否对齐。
- 重复直到评审判断和人工评审基本一致。
预计需要 3-5 轮校准。每轮把改了什么、为什么改记入 ../progress.md 的项目级大事记（跨任务的校准决策适合记在那里）。