把评测做成组织能力：谁来写、谁来跑、谁来读

评测不能是一次性项目。本文给出三个角色的分工（业务写样本与标准、工程接流水线、业务+管理每周读）、让评测活起来的四个机制与一个小团队最小落地方案。

评测不是"一次性项目"

很多团队的评测是这样的：上线前突击建一批样本 ✗，上线后放进仓库落灰 ✗。

过三个月再想做优化时，发现样本过时、跑不起来、也没人记得判定标准 ✗。

**把评测做成组织能力** ✔，需要回答三个问题：**谁来写、谁来跑、谁来读** ✔。

**写样本**：最了解业务的人（产品/运营/客服）✔ —— 他们知道"什么答案算有用" ✔；

**写标准**：写样本的人 + 工程各一人共同定 ✔（边界情况必须双方认可 ✔）；

**工程负责**：把标准落成**可执行**的判定（规则或标注表 ✔），并接进流水线 ✔。

**反模式**：让工程自己想象用户问题 ✗（样本会偏离真实分布 ✔）。

**自动化**：接进 CI（见评测接进 CI 那篇 ✔），每次改动自动跑 ✔；

**维护责任要明确**：指定一个人（或轮值 ✔）负责"样本保鲜" ✔ ——

每季度补充新样本、淘汰过时样本 ✔（没有 owner 的资产会腐烂 ✔）；

**成本归口**：评测也会花钱（调模型 ✔），要进预算（见预算那篇 ✔）。

**每周看一次失败类型分布** ✔（不是只看总分 ✔）；

**每次改动看净胜数与区间** ✔（见小样本那篇 ✔）；

**读的人要有决策权** ✔（否则报告只是"信息" ✔，不会变成行动 ✔）。

**反模式**：报告只发给工程 ✗（业务看不到，问题就永远在"模型不行"上打转 ✔）。

1. **失败即补样本** ✔（每次线上事故/负反馈都产出 1 条样本 —— 见反馈回填那篇 ✔）；

2. **改动即回归** ✔（流水线阻断退化的合并 ✔）；

3. **季度校准** ✔（重看判定标准是否还成立 ✔）；

4. **公开可见** ✔（把关键指标做成看板，而不是锁在某人电脑里 ✔）。

```

写：产品 1 人 + 工程 1 人，用半天定 100 条样本与判定标准

跑：工程接进 CI（冒烟 30 条、1 分钟内阻断合并）

读：每周 30 分钟例会，看失败类型分布 + 本周改动对照

owner：工程一人轮值，负责样本保鲜与季度校准

```

> 如果一个新同事加入，能否在**一天内**看懂"怎么判断这个系统好不好" ✔？

> 不能，说明评测还停在个人能力上，没有变成组织能力 ✗。