报告只发给工程，问题就永远在「模型不行」上打转。
评测不是"一次性项目"
很多团队的评测是这样的：上线前突击建一批样本 ✗，上线后放进仓库落灰 ✗。
过三个月再想做优化时，发现样本过时、跑不起来、也没人记得判定标准 ✗。
把评测做成组织能力 ✔，需要回答三个问题：谁来写、谁来跑、谁来读 ✔。
一、谁来写（样本与标准）
· 写样本：最了解业务的人（产品/运营/客服）✔ —— 他们知道"什么答案算有用" ✔；
· 写标准：写样本的人 + 工程各一人共同定 ✔（边界情况必须双方认可 ✔）；
· 工程负责：把标准落成可执行的判定（规则或标注表 ✔），并接进流水线 ✔。
反模式：让工程自己想象用户问题 ✗（样本会偏离真实分布 ✔）。
二、谁来跑（执行与维护）
· 自动化：接进 CI（见评测接进 CI 那篇 ✔），每次改动自动跑 ✔；
· 维护责任要明确：指定一个人（或轮值 ✔）负责"样本保鲜" ✔ ——
每季度补充新样本、淘汰过时样本 ✔（没有 owner 的资产会腐烂 ✔）；
· 成本归口：评测也会花钱（调模型 ✔），要进预算（见预算那篇 ✔）。
三、谁来读（决策与行动）
· 每周看一次失败类型分布 ✔（不是只看总分 ✔）；
· 每次改动看净胜数与区间 ✔（见小样本那篇 ✔）；
· 读的人要有决策权 ✔（否则报告只是"信息" ✔，不会变成行动 ✔）。
反模式：报告只发给工程 ✗（业务看不到，问题就永远在"模型不行"上打转 ✔）。
四、让评测"活"起来的四个机制
1. 失败即补样本 ✔（每次线上事故/负反馈都产出 1 条样本 —— 见反馈回填那篇 ✔）；
2. 改动即回归 ✔（流水线阻断退化的合并 ✔）；
3. 季度校准 ✔（重看判定标准是否还成立 ✔）；
4. 公开可见 ✔（把关键指标做成看板，而不是锁在某人电脑里 ✔）。
五、最小落地（小团队版）
```
写：产品 1 人 + 工程 1 人，用半天定 100 条样本与判定标准
跑：工程接进 CI（冒烟 30 条、1 分钟内阻断合并）
读：每周 30 分钟例会，看失败类型分布 + 本周改动对照
owner：工程一人轮值，负责样本保鲜与季度校准
```
一条判据
> 如果一个新同事加入，能否在一天内看懂"怎么判断这个系统好不好" ✔？
> 不能，说明评测还停在个人能力上，没有变成组织能力 ✗。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：长会话的成本控制：摘要频率与预算联动
下一篇：检索与生成的分工契约：谁负责什么 →
第 76 / 171 篇