评测脚本是没人要求、却必须交付的那件东西

没有一份 SOW 会写评测脚本。它不出现在任何截图里，演示起来很难看，也没法单独报价。但它是唯一一件能让客户和交付方在质量上产生分歧、而不至于把讨论变成口味之争的东西——没有它的项目，验收就是一次演示加一次点头。

先造尺子

题要从系统真的会被问到的问题里取，来源是客户自己的历史，不是团队的想象。按需求点分组，每个需求点写三类：正常情况、反向情况、边界情况。再单独加一组明显偏难的：型号没说全的、一条消息里夹两件事的、资料里根本没有答案的。

每道题五个字段：输入、预期产出或预期处理、判断它对错的依据、难还是易、负责人。少了最后一个字段，题目会悄悄腐烂——三个月后没人发现某道题早就不该算了。

真正要紧的划分，是有确定答案的题和没有确定答案的题。一位做小团队交付的分享者自述，知识库场景里大约 85% 的题目会设计成有确定答案，其余作为判断分歧记录下来。这个比例是设计目标，不是定律；关键在于是有意选的，不是攒到什么算什么。

有确定答案，也包括「该拒答」

有确定答案不等于资料里必须有个答案。「应当追问一句」和「应当转人工」都是确定结果，而在多数项目里，恰恰是这两种结果决定了这个东西安不安全。

这里也是评测集和口径表接上的地方。口径表里没有剔除规则的指标，是一个会被人拿来吵的数字；测试集里没有预期处理的题，是一道「谁最后跑谁判过」的题。你写进需求里的停止条件，在评测里就是一行普通的用例。

剩下那一成是记录，不是噪声

两个讲道理的评审对一道题看法不同时，诚实的做法是把这个分歧本身记下来：谁读的、哪天读的、对着哪一版评分标准、最后怎么定的。不能做的是把它平均进一个百分比。一次权限越界，不会因为另外四十道题答得好而消失；一个报错的金额，也不具备舍入误差的性质。

两条规则防止这件事变成公文。同一个分歧出现第二次，要么变成一条评分标准，要么变成一个缺陷，不允许第三次仍然悬着。会造成伤害的用例——访问权限、钱、合规——从不参与平均，它只有通过与不通过。

客户能自己扩展的脚本长什么样

评测脚本是交付物，所以在项目结束之后必须能被客户用起来。形态是一个文件、五个部分，其中任何一部分都不需要读懂模型的代码。

题目放在一张普通表格里，客户能自己加一行。跑分脚本对每道题给出通过、不通过、需要判断三种结论，绝不只给一个准确率。金额、状态、编号这类字段用代码核对——它们不是判断，不该由判断来打分。与上一次运行做对比，点名哪些题变了，让回归有一个具体的名字。最后，给一部分题打上「留出」标记。

客户能自己加一道题、在没有你在场的情况下拿到结论，他手里就是一套验收机制。客户拿到一张表格和一句承诺，那是一件纪念品。

把分数接进告警，而不是放进面板

面板上的分数，大家看一周。同一个分数接进告警链路，行为就变了：留出集上的回归变成一个有负责人、有升级路径、有时间戳的事件，和事故响应用的是同一套机制。

阈值要硬：留出集里有一道题从通过变成不通过，就拦住这次变更。不是「评审一下」，是拦住。任何更软的说法，都会在最不想慢下来的那一刻被谈掉。

会看到的失败，与判据

常见的失败是：测试集由乙方出，题目选自系统已经答得对的那批。上线前全过，百分比写进了材料；第二周第一个真问题就挂，而手上没有基线可以对比。客户记得演示是过的，却没人说得清当时覆盖了哪些题。还有一种更隐蔽也更伤人的版本：拿一个单独的准确率百分比给业务方看，看起来严谨，却拆不开，于是真正坏掉的那一类问题始终看不见。

判据很短。评测脚本做完了的标志是：一个没看过代码的业务评审，能自己加题、自己跑、拿到结论，全程不需要你在场；同时，这一轮每一道没过，都被写进方法库，带上触发场景、失败模式、识别信号、避免动作和边界条件，让下一次交付从一个比这次稍好的题集开始。这一步属于回灌；没有它，脚本只是一张收据，不是资产。