Add harness coding documentation

2026-07-06 10:25:29 +08:00
commit f68d443c0d
23 changed files with 1336 additions and 0 deletions
@@ -0,0 +1,43 @@
+# 评审评分表
+
+> 在一轮（或几轮）会话实现完成后、正式验收前，用这张表做一次结构化评审，回答"这轮 agent 做得好不好"。
+> 它评的是**单次输出质量**；代码库长期健康度见 [`quality-document.md`](quality-document.md)。
+
+## 评分维度
+
+六个维度，每个 0-2 分（0 不满足 · 1 部分满足 · 2 满足）。
+
+| 维度 | 问题 | 分数 (0-2) | 备注 |
+| --- | --- | --- | --- |
+| 正确性 | 实现出来的行为是否符合目标功能 / 验收标准？ |  |  |
+| 验证 | 要求的检查是否真的跑过，并在 `../progress.md` 留下证据？ |  |  |
+| 范围纪律 | 这一轮是否基本保持在选定的单个任务范围内？ |  |  |
+| 可靠性 | 结果是否能在重启或重跑后继续工作？ |  |  |
+| 可维护性 | 代码和文档是否清楚到足以交给下一轮会话？ |  |  |
+| 交接准备度 | 新会话是否能只靠仓库内文件继续推进？ |  |  |
+
+## 结论
+
+从下面三选一：
+
+- **Accept** — 达标，可验收。
+- **Revise** — 需要修补才能接受（列出必须补的修复）。
+- **Block** — 有根本性问题，需要先解决（列出阻塞项）。
+
+## 后续动作
+
+- 缺失的证据：
+- 必须补的修复：
+- 下次复审触发条件：
+
+## 关于校准（重要）
+
+开箱即用的 agent 做评审很弱——它会发现问题，然后把自己说服到通过。所以这张表的通过/失败标准需要反复校准到和人工判断一致：
+
+1. 用本表给一个已完成的任务打分。
+2. 把它的分数和你自己的人工判断对比。
+3. 有分歧的地方，把对应维度的"什么算 2 分 / 什么算 0 分"写得更具体，落到本项目的真实验收标准上。
+4. 对同一个输出重新打分，看是否对齐。
+5. 重复直到评审判断和人工评审基本一致。
+
+预计需要 3-5 轮校准。每轮在 `../progress.md` 记录改了什么、为什么改。