AI 功能验收：质量、成本、延迟与信任四张表

「感觉还行」不是验收结论，四张能复算的表才是。

一、上线六周后，没人能回答「它到底行不行」

许澄一个人做客服工单工具，六个月前加了 AI 摘要：把一长串对话压成三行，帮客服在接起电话前扫一眼。上线六周，使用率 34%，看起来是个不错的数字，但周会开成了吵架。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

工程师说模型很强，公开评测里排在前列；运营说用户抱怨「摘要答非所问」；财务说推理成本是预算的 2.3 倍；她自己则收到两封退款邮件，理由都是「不敢信这个摘要」。四个人说的「行」根本不是同一件事。

她把六周日志按功能、套餐、周切片拉出来，第一次把四个维度放在同一张桌上：质量加权通过率 78%，严重错误 6 起，p95 首 token 2.8 秒，每成功任务成本 0.19 美元，人工兜底率 31%，引用覆盖率只有 54%。

数字一摆，争论立刻变成取舍：不是模型不行，而是她从来没有定义过什么叫行。摘要本身可用，但它没有引用来源，客服无法判断哪一句能信，于是全部转人工；转人工又推高了兜底率，看起来像质量问题，实际是信任设计缺失。

验收不是上线前的一次签字，而是一条贯穿上线的判断链。 上线前用它决定放不放，上线后用它决定继续、修复、降级还是下线。没有这条链，所有讨论都会退回到「我觉得」。

这一篇给出一套一个人能维护的验收结构：四张表、一个 gate、一次 30 天复盘。它不替代评测方法，而是把评测结果和成本、延迟、信任放进同一个决策。

二、四张表：质量、成本、延迟、信任

四张表各自回答一个问题，彼此不能补偿。质量高不能抵消成本失控，延迟低不能抵消引用造假。

质量表要用固定评测集，不用临时抽样。 第 05 篇的 50 条用例就是这里的分母；每次改提示、换模型、调参数，都跑同一套题。临时抽样的通过率会随样本难度漂移，无法比较。

成本表要算「每成功任务」，不是「每次调用」。 失败重试、用户放弃、人工返工都要计入分子或分母。一个单价很低但成功率只有六成的方案，每成功任务成本可能高于贵一倍但稳定的方案。

延迟要拆首 token 与总时长。 用户对「多久看到第一个字」的容忍度远低于「多久全部写完」。首 token 慢，用户会觉得卡死；总时长慢，只要有进度反馈，容忍度会高很多。两个指标要分别设阈值。

信任表必须区分漏拒与误拒。 引用覆盖率只衡量事实句是否附有效引用，支持关系仍需复核。拒答召回率是正确拒答除以应拒答数，精确率是正确拒答除以实际拒答数，分别反映漏拒与误拒，不能统称“准确率”。另记人工兜底率、客诉和退款，避免只看一个高分掩盖风险。

红线是一票否决，不参与加权。 严重错误、引用造假、退款异常这类问题，不应该被「总分 0.85」掩盖。先把红线列出来，再谈分数；顺序反了，验收就会变成给已经决定要上的功能找理由。

阈值要写日期和负责人。 「p95 ≤3 秒」是哪个版本、哪个模型、哪个地区测出来的，要写清楚。否则三个月后没人知道这个数还算不算数，也没人敢改。

三、上线 gate 与 30 天 cohort 复盘

Gate 的作用不是拦住所有风险，而是让「带病上线」变成一个需要明确签字的选择，而不是默认发生。

灰度阶段看方差，不只看均值。 5% 用户里如果有一个重度账号把成本拉高，均值可能仍然正常，但尾部已经失控。同时看 p95 成本与单用户最大成本，才能提前发现第 09 篇那类「一晚烧掉整月预算」的情形。

30 天复盘要按 cohort，不要和上线前的老用户混。 把「上线后首次使用」的用户单独分组，比较付费转化、次月留存、成本分布与事故数。混在一起看，早期尝鲜用户会把数据拉好看，掩盖真实留存。

成本方差比成本均值更值得盯。 均值告诉你这个月花了多少，方差告诉你下个月会不会突然翻倍。一个人维护的产品没有预算缓冲，方差大就意味着随时可能被一个用户打乱整个月的现金流。

复盘结论只能是三选一：scale、fix、kill。 scale 是扩大入口或推广到更多套餐；fix 是保留功能但修一个明确问题，并写下复检日期；kill 是关闭入口、保留数据、通知用户。不要用「再观察观察」当结论，那只是把决定推迟到更没信息的时候。

失败案例要回流到评测集。 上线后每一个真实 bug、每一次客诉，都应该变成第 05 篇 50 条用例里的一条。评测集不增长，验收就永远在测上线前想象出来的问题。

决策记录要写给三个月后的自己。 记下当时的四个分数、红线状态、选择了什么、下次复核日期。三个月后你会忘记为什么留着这个功能，这份记录是唯一能阻止「凭感觉再上一次」的东西。

四、看板与决策记录

看板不是给老板看的仪表盘，而是一张「看到这个数就做这个动作」的对照表。没有动作的指标，不该占用看板。

切片决定你能不能看见问题。 只看全站总分，会掩盖某个套餐、某个功能、某一周的恶化。功能切片看取舍，套餐切片看公平性，周切片看趋势；三个维度至少保留两个。

每个指标必须绑定一个动作。 「通过率低于 80%」后面要跟「修提示或缩范围」，而不是「关注」。没有动作的阈值只是一句愿望，周会念完就过去了。

看板更新频率要与决策频率匹配。 质量与信任按周看，成本按周对账、按月结算，延迟按天看告警。全部实时既没必要，也会让人对红色麻木。

阈值每季度重算一次。 模型降价、缓存命中率提升、用户结构变化，都会让旧阈值失真。重算时保留旧值，写清变化原因，避免阈值被悄悄放宽成「刚好能过」。

不要用平均值掩盖尾部。 平均延迟 1.2 秒听起来很好，但 p95 是 8 秒时，每二十个用户就有一个在等八秒。AI 功能的体验由尾部决定，因为失败的那一次往往就是用户决定不再用的那一次。

决策记录和看板要放在同一个地方。 看板给现状，记录给历史。分开存放，三个月后你会看到一堆数字却不知道当时为什么这么定。最省事的做法是一个文件：上半周指标，下半决策与日期。

关掉一个功能也要留记录。 kill 不是失败，反复重启同一个不合格的功能才是。写下关闭原因、哪些用户受影响、数据保留多久、什么条件下可以重开；这份记录能防止半年后有人凭记忆再把同样的坑踩一遍。

五、行动清单与复算验收

先补齐数据，再谈分数。四张表里任何一张没有稳定数据源，验收就会退化成主观判断；宁可先把埋点、账单和工单标签接好，也不要先算一个漂亮的总分。

用一次真实复盘校准阈值。 拿最近 30 天的数据，按四张表算一遍，看看哪些指标其实一直在红线附近。阈值不是从本文抄的，而是根据你的客单价、支持成本和风险承受度调出来的。

• 把 50 条评测集固定下来，确认每次发版都跑同一套。
• 从账单与日志算出每用户月成本、每成功任务成本与成本 p95。
• 在追踪里拆出首 token 与总时长，分别记录 p50 与 p95。
• 给引用覆盖率、拒答召回率、拒答精确率与人工兜底率各接数据源，并保留人工标注口径。
• 为四张表各写一行红线，明确「触发即不通过」。
• 把上线 gate 的四个阶段与对应动作写进发布清单。
• 建立一个按功能、套餐、周切片的看板，每个指标绑定负责人。
• 约定 30 天 cohort 复盘日期，并预留写 scale / fix / kill 的时间。

验收标准：任取一个上线满 30 天的 AI 功能，你能用四张表在十分钟内给出 scale、fix 或 kill 的结论，并说出依据的是哪几个数和哪条红线。

综合验收分 = 质量×0.4 + 成本×0.2 + 延迟×0.2 + 信任×0.2
示例：质量 0.86、成本 0.74、延迟 0.90、信任 0.82
= 0.344 + 0.148 + 0.180 + 0.164 = 0.836 → 通过（≥0.8 且无红线）
单位成功任务成本 = 总推理成本 ÷ 成功任务数 = 412 ÷ 2170 ≈ 0.19 美元
结论：综合分达标；若严重错误 ≥1，仍判不通过，先修复再谈分数

使用边界与实操验收

本文假设功能已经上线或即将上线，并且你能拿到调用日志、账单与工单数据。它不教你如何设计评测题，也不讨论模型选型；那些在第 05 篇与第 03 篇。四张表是决策界面，不是评测方法本身。

• 生成式 AI 可观测性：LLM 调用追踪、Token 成本监控、质量与安全评估 ：它讲追踪、Token 成本与质量评估的技术实现，本文讲把这些数据收束成四张验收表与一个上线 gate。
• 模型评测与灰度发布 ：它讲评测与灰度的流程，本文把评测结果与成本、延迟、信任放在同一张决策桌上。
• 开发者体验验收：首次成功时间、留存口径与复算表 ：它讲 API 产品的 DX 验收口径，本文是同一套「阈值 + 复算 + 决策」方法在 AI 功能上的版本。

实操验收建议做一次「盲评」：把四张表的数字遮住，只看结论，请一个不了解这个功能的人判断该 scale 还是 kill；再揭开数字，看他的判断是否改变。如果数字不能改变判断，说明指标没有选对，或者阈值离现实太远。

这套表不适用于三种情况。 一是功能还在原型期、没有稳定用户；二是 AI 只是营销页面上的一个演示，不进入付费工作流；三是受监管场景，验收还需要外部审计与合规签字，四张表只能作为内部前置检查。

关键参考与核验范围

核对日期：2026-10-25。下列来源仅支持明确标注的机制或原则。

• NIST AI Risk Management Framework : 用于核对风险识别、测量与管理需形成持续过程的原则。
• Claude：Define success criteria and build evaluations : 用于核对验收标准与任务用例相对应的做法。

使用边界。 四张表、权重、阈值与综合分是内部教学模型，不是任何机构的认证标准。严重错误和权限泄露不能被加权分抵消。

如何自行复核。 给质量、完整成本、逐次延迟和信任指标各留数据来源与窗口；拒答召回率与精确率分别报告，再确认红线与回滚出口。

系列导航

• 上一篇：把推理成本写进价格：额度、超额与升级触发
• 回到目录：一个人给产品加 AI：判据、成本、护栏与验收
• 相关阅读：小样本评测：50 条用例、评分表与上线门槛 、推理账单：每用户每月、每次调用与毛利下限