写在文档里的评测，等于没有评测
很多团队的评测"定义"写在文档里 ✗：判定标准、样本清单、指标口径 ✔ ——
但没有可执行的脚本 ✔。结果每年都要有人重新实现一遍 ✗，
而且两个人的实现细节不同，指标无法比较 ✗。
评测要落成脚本 ✔：一条命令能跑、输出结构固定、结果可存档 ✔。
一、评测脚本该有的四个部分
① 样本加载（含版本号 ✔）
② 调用被测系统（限速、可重试、可缓存 ✔）
③ 判定（规则 + 人工标注表 ✔）
④ 报告（指标 + 失败类型 + 明细文件 ✔）
第 ③ 部分是关键 ✗：判定逻辑必须可读、可测、可版本化 ✔ ——
不能散在临时笔记本里 ✔（下一个人无法复用 ✔）。
二、三个硬性要求
- 可复跑 ✔：同一批样本 + 同一系统版本 → 指标应稳定 ✔；
- 可对比 ✔：报告里带"上一次运行"的对照（或与基线文件比较 ✔）；
- 可存档 ✔：每次运行输出一个带时间戳的结果文件 ✔（便于画趋势 ✔）。
三、把"人工判定"也纳入流程
规则判不了的部分（生成质量、语气 ✔）需要人看 ✔。做法：
- 脚本导出待人工判定的清单（含输入、输出、样本 id ✔）；
- 人工填回一张表（格式固定 ✔），脚本再合并它的结果 ✔；
- 人工表也要版本化 ✔（否则历史结果无法复现 ✔）。
要点：人工环节不能被绕过（脚本应检查人工表是否存在且覆盖 ✔），也不能静默为空 ✔。
四、评测脚本本身的测试
- 判定函数的单元测试（正例/反例 ✔ —— 尤其是"该拒答却作答"这类边界 ✔）；
- 回归用例：故意构造一个"必然失败"的样本 ✔，确认脚本会报错 ✔（我给门禁做反证是同一个思路 ✔）；
- 变更判定逻辑时，旧结果要能重算 ✔（或明确标注口径已变 ✔）。
五、与流水线的关系
- 本地跑：
make eval一条命令 ✔； - CI 跑：冒烟集（几十条、1 分钟内 ✔）阻断合并 ✔；
- 夜间跑：完整集 + 成本/延迟统计 ✔（见评测接进 CI 那篇 ✔）。
一条判据
换一个人来做同一件事 ✔，能否只读脚本就明白"怎么判定、为什么这么判定" ✔，并复跑出一样的数字 ✔？
不能，说明评测还停在文档与个人习惯上 ✗。