"效果好"不是验收标准
AI 功能的验收最容易糊弄 ✗："看着还行""比之前好" ✔ —— 这不叫验收 ✔。
验收标准必须在开工前写好 ✔，并且可测、可复现、有阈值 ✔。
一、好的验收标准长什么样
四级结构 ✔：
① 功能：能完成什么（具体到输入输出 ✔）
② 质量：指标与阈值（正确率 ≥ X%、该拒答却作答率 ≤ Y% ✔）
③ 性能：延迟与成本（P95 ≤ A 秒、单位成本 ≤ B 元 ✔）
④ 边界：明确不做什么（超出范围要拒绝 ✔）
要点：②必须是可复算的 ✔（有评测集、有脚本 ✔ —— 见评测脚本化那篇 ✔）。
二、阈值怎么定（不要拍脑袋）
- 与基线比（现有方案/人工的指标 ✔）→ 目标是"不低于基线"或"提升 X%" ✔；
- 看业务容忍度（错误率红线来自后果 ✔ —— 见需求七问 ✔）；
- 留出波动空间（生成类任务方差大 ✔ → 阈值要含波动 ✔，否则天天验收不过 ✔）。
三、验收的三次检查
| 时点 | 查什么 |
|---|---|
| 开发中 | 冒烟集（几十条 ✔）不退化 |
| 提测前 | 完整评测集 + 成本/延迟 ✔ |
| 上线后一周 | 真实流量指标（负反馈率、拒答率、成本 ✔） |
第三次常被忽略 ✗：离线达标 ≠ 线上达标 ✔（真实输入分布不同 ✔）。
四、验收不通过怎么办
- 明确"差在哪里" ✔（是质量、性能还是边界 ✔ —— 用分段指标定位 ✔）；
- 给两条出路：达标上线 ✔，或缩小范围上线 ✔（只放低风险场景 ✔）；
- 不接受"先上线再说" ✗（除非有明确回滚与灰度方案 ✔ —— 那也是一种验收方式 ✔）。
五、三个反模式
- 验收标准写在验收当天 ✗（等于为结果找理由 ✔）；
- 只有主观判断 ✗（"产品觉得可以" ✔）；
- 只看质量不看成本 ✗（上线后账单翻倍 ✔）。
一条判据
把验收标准交给第三方（不参与开发的人 ✔），他能否独立复跑并得出"通过/不通过" ✔？
不能，说明这份标准还不够可验收 ✗。