把评测做成可复跑的脚本，而不是一份文档

写在文档里的评测等于没有评测。本文给出评测脚本的四个部分（样本/调用/判定/报告）、三条硬性要求（可复跑/可对比/可存档）、把人工判定纳入流程的做法，以及评测脚本自身的测试。

写在文档里的评测，等于没有评测

很多团队的评测"定义"写在文档里 ✗：判定标准、样本清单、指标口径 ✔ ——

但**没有可执行的脚本** ✔。结果每年都要有人重新实现一遍 ✗，

而且两个人的实现细节不同，指标无法比较 ✗。

**评测要落成脚本** ✔：一条命令能跑、输出结构固定、结果可存档 ✔。

```

① 样本加载（含版本号 ✔）

② 调用被测系统（限速、可重试、可缓存 ✔）

③ 判定（规则 + 人工标注表 ✔）

④ 报告（指标 + 失败类型 + 明细文件 ✔）

```

**第 ③ 部分是关键** ✗：判定逻辑必须**可读、可测、可版本化** ✔ ——

不能散在临时笔记本里 ✔（下一个人无法复用 ✔）。

1. **可复跑** ✔：同一批样本 + 同一系统版本 → 指标应稳定 ✔；

2. **可对比** ✔：报告里带"上一次运行"的对照（或与基线文件比较 ✔）；

3. **可存档** ✔：每次运行输出一个带时间戳的结果文件 ✔（便于画趋势 ✔）。

规则判不了的部分（生成质量、语气 ✔）需要人看 ✔。做法：

脚本**导出待人工判定的清单**（含输入、输出、样本 id ✔）；

人工填回一张表（格式固定 ✔），脚本再合并它的结果 ✔；

**人工表也要版本化** ✔（否则历史结果无法复现 ✔）。

**要点**：人工环节**不能被绕过**（脚本应检查人工表是否存在且覆盖 ✔），也不能**静默为空** ✔。

判定函数的**单元测试**（正例/反例 ✔ —— 尤其是"该拒答却作答"这类边界 ✔）；

**回归用例**：故意构造一个"必然失败"的样本 ✔，确认脚本会报错 ✔（我给门禁做反证是同一个思路 ✔）；

变更判定逻辑时，**旧结果要能重算** ✔（或明确标注口径已变 ✔）。

本地跑：`make eval` 一条命令 ✔；

CI 跑：冒烟集（几十条、1 分钟内 ✔）阻断合并 ✔；

夜间跑：完整集 + 成本/延迟统计 ✔（见评测接进 CI 那篇 ✔）。

> 换一个人来做同一件事 ✔，能否**只读脚本**就明白"怎么判定、为什么这么判定" ✔，并复跑出一样的数字 ✔？

> 不能，说明评测还停在文档与个人习惯上 ✗。