试点开始前，怎样确定验收口径和上线阈值？

AI 项目最激烈的争论，常常发生在试点快结束时：供应商说准确率不错，业务说关键错误不能接受，技术说已经达到预期，管理者却不知道该不该上线。

这场争论通常来得太晚。

验收口径必须在试点前确定，把任务质量、错误代价、人工容量、业务结果和风险底线放进同一张决策表。 上线没有统一分数线，它取决于企业愿意承担什么后果。

先定义任务与分母

“准确率 90%”如果不说明评测对象，几乎没有决策价值。需要写清任务范围、样本来源、正常样本与难例比例、错误分类，以及标准由谁确认。

类别极不平衡时，总体准确率尤其容易误导。风险事件只占很小比例，模型把所有对象判断为正常，也可能得到一个漂亮分数。

用一张上线阈值表作决定

维度 试点前要写什么 上线时看什么

任务效果 评测集、分母、当前基线 分类型结果和波动

严重错误 哪些错误不可接受 严重错误数量与原因

人工负担 团队可承受的复核量 复核时长、积压和接管成功率

业务结果 希望改变的完整流程指标 端到端时长、返工、成本或客户结果

运行能力 监控、暂停、恢复责任人 异常能否发现、接管和恢复

上线范围 用户、数据、动作权限 扩大、保持或退回条件

表里既要写目标值，也要写“一票否决项”。平均结果达标，但出现无法接受的越权、资金或安全错误，项目仍然不能按原范围上线。

误杀和漏检要分开算

漏检代表该发现的问题没有发现，误杀代表正常对象被错误拦截。两者的成本通常不同，还会随着客户、金额和场景改变。

把错误按严重度分级：哪些可以后续修正，哪些会造成客户权益、资金或安全后果。阈值围绕严重错误设置，不能只追求平均分。

人工兜底也有容量上限

AI 把不确定样本交给人工，是常见的安全设计。若每天需要复核的数量超过团队容量，系统即使模型分数合格，也无法长期运行。

所以要一起测复核量、平均处理时间、积压、接管成功率和疲劳风险。试点期靠专家随时救火，不能直接推算到规模化阶段。

上线是一组权限决定

没有历史基线，可以先和当前人工流程、简单规则比较，或先记录一段真实运行。证据不足时先进入影子模式，只给建议；随后再限定用户、数据和任务类型，最后才逐步开放自动动作。

第 36 问会继续回答评测标准由谁提供、争议由谁裁决。本篇先把上线需要的证据和阈值固定下来。

上线阈值写的是企业愿意接受什么错误、用多少人工兜底，以及谁承担剩余风险。

本问行动：试点启动前把这张六维表填完，任何一项只有“到时再看”，都可能变成结束时的争议。