AI 功能怎么验收：把验收标准写进需求

验收标准必须在开工前写好且可测。本文给出四级结构（功能/质量/性能/边界）、阈值怎么定、三次检查时点、不通过怎么办与三个反模式。

"效果好"不是验收标准

AI 功能的验收最容易糊弄 ✗："看着还行""比之前好" ✔ —— 这不叫验收 ✔。

**验收标准必须在开工前写好** ✔，并且**可测、可复现、有阈值** ✔。

四级结构 ✔：

```

① 功能：能完成什么（具体到输入输出 ✔）

② 质量：指标与阈值（正确率 ≥ X%、该拒答却作答率 ≤ Y% ✔）

③ 性能：延迟与成本（P95 ≤ A 秒、单位成本 ≤ B 元 ✔）

④ 边界：明确不做什么（超出范围要拒绝 ✔）

```

**要点**：②必须是**可复算**的 ✔（有评测集、有脚本 ✔ —— 见评测脚本化那篇 ✔）。

**与基线比**（现有方案/人工的指标 ✔）→ 目标是"不低于基线"或"提升 X%" ✔；

**看业务容忍度**（错误率红线来自后果 ✔ —— 见需求七问 ✔）；

**留出波动空间**（生成类任务方差大 ✔ → 阈值要含波动 ✔，否则天天验收不过 ✔）。

| 时点 | 查什么 |

|---|---|

| 开发中 | 冒烟集（几十条 ✔）不退化 |

| 提测前 | 完整评测集 + 成本/延迟 ✔ |

| 上线后一周 | 真实流量指标（负反馈率、拒答率、成本 ✔） |

**第三次常被忽略** ✗：离线达标 ≠ 线上达标 ✔（真实输入分布不同 ✔）。

**明确"差在哪里"** ✔（是质量、性能还是边界 ✔ —— 用分段指标定位 ✔）；

**给两条出路**：达标上线 ✔，或**缩小范围**上线 ✔（只放低风险场景 ✔）；

**不接受"先上线再说"** ✗（除非有明确回滚与灰度方案 ✔ —— 那也是一种验收方式 ✔）。

**验收标准写在验收当天** ✗（等于为结果找理由 ✔）；

**只有主观判断** ✗（"产品觉得可以" ✔）；

**只看质量不看成本** ✗（上线后账单翻倍 ✔）。

> 把验收标准交给**第三方**（不参与开发的人 ✔），他能否**独立复跑**并得出"通过/不通过" ✔？

> 不能，说明这份标准还不够可验收 ✗。