AI 项目验收：别在上线那天才谈怎么算成

需求评审会上最常出现、又最不可执行的一句话是："验收标准：系统上线并通过验收。"这句话没法变成验收条件------它没有指标名，没有基线，没有取样口径，也没有写谁签。我（唐欢，弯弯）做企业 AI 诊断这些年，按"先诊断，再落地"的顺序看这类项目，习惯把验收拆到AI 应用成熟度五维 里最容易被跳过的那一维------ROI 可验证性；这一维不难算，难在它必须在上线之前就算清楚。

下面按工程视角拆：三个概念的边界、验收单的字段规范、主指标怎么从四维里落一维、基线采集的做法、目标区间的处置规则、取样怎么写到可复现、观察项埋在哪、付款与变更怎么绑、失败条款要交什么。

一、三个概念先分开：测试、上线确认、验收

图01：三张单子各答一个问题：测试问功能对不对、上线确认问能不能跑、验收问这一段算不算完成；前两件是技术动作，第三件是商业动作

概念	回答的问题	典型动作	判据性质
测试	功能对不对	点下去有反应，结果等于预期值	技术
上线确认	能不能跑	并发、权限、日志、回滚	技术
验收	这一段算不算完成、钱结不结、下一段还做不做	主指标达标、取样可复现、签字人确认	商业

前两件是技术动作，第三件是商业动作。混用这三张单子，最常见的后果是"测试全绿、上线成功、验收签不下来"------因为验收要的那几个数，谁都没在开工前定义过。

三张单子的责任人也不同：测试归开发，上线确认归运维，验收归那个能对主指标负责的业务岗。让运维去判断"这块业务有没有变好"，他只能签"已交付"。

一个项目可以同时满足"功能全对""没人用""说不清省了什么"，三者并不矛盾：它们分别落在三张不同的单子上。

二、验收单的字段规范

图02：五栏条款与每栏填错的样子：指标名、基线值、目标值、取样方式、签字人；少一栏，验收就退回成演示顺不顺

把它做成一张有类型、有必填、有反例的表，评审时才能逐格过。

字段	必填	类型/格式	合格示例	反例
主指标名	是	业务方日常用语，唯一	报价单返工率	响应时长
基线值	是	数值＋取样窗口＋样本量＋剔除规则	12.4%，取 2026-09 全月 486 单	以现状为准
目标区间	是	区间＋未达处置	降至 8% 以下为通过，8%---12.4% 按比例结算	提升 30%
取样方式	是	谁取/从哪取/频次/剔除规则	业务主管每周五从工单系统导出全部完工单	由项目组统计
签字人	是	岗位名（对指标负责的人）	售后部经理	IT 项目经理
观察项	否	只观察不结算	周活、调用次数、绕过率	把观察项写进结算

表里五行都填满，才算具备可验收条件。缺一栏，验收就退回成"演示顺不顺"。

三、主指标：从四维落到一个可数指标

图03：效率、成本、质量、风险各给两个可数指标；四维里只挑一维，一维只落一个主指标，其余三维只作观察项

四维口径覆盖老板会追问的四个方向，每维给两个可直接采集的：

维度	可数指标 A	可数指标 B	采集注意
效率	单张单据处理分钟数（中位数）	一人一天处理单量	用中位数，不用均值
成本	每千次处理的直接成本	单位业务量外包支出	工具费与分摊人力分开记
质量	抽检 100 单的差错条数	返工单占比、一次通过率	抽检样本要随机抽
风险	按月计越权访问次数	敏感字段外发事件数	目标为 0 也要写清怎么计

规则只有一条：挑一维，落一个主指标，其余三维只作观察项。观察项进周报，不进结算。

选哪一维，看两个条件是否同时成立：这件业务现在最疼的是哪一个；这个数字现在有没有人在看。都满足才是它。

举个假设的典型（不是具体客户）：一家做工业品贸易的企业，最初把"报价单处理时间"当主指标。这个选择错在因果链上------报价单本来就要等客户确认，内部处理时间缩短，客户不回，总周期不变。他们真正疼的是返工：报价单发出后被客户退回改价的占比。指标换成返工率之后，改善才第一次可见。

这条经验可以写成一句工程判据：这个数字变好，业务负责人会不会在周会上主动提。会提，说明它在业务侧有归属；不会提，它只是技术侧的自评。

四、基线：三个坑对应三条工程约束

图04：基线的三个坑与处置：没采要留一张带日期的导出文件、被污染要同期只改一件事、不可复现要把取样写到换人也能算出同一个数

坑	症状	工程约束
没采	开工时觉得"现状都清楚"，三个月后靠回忆	基线采集写进项目启动第一周任务；交付物是带日期的导出文件，没有它项目不算启动
被污染	同期上了 ERP 模块、调了绩效口径，效果说不清归谁	同期只改一件事并写进条款；做不到就延长观察期，或只记方向不记幅度
不可复现	换个人算出两个数	数据源、筛选条件、剔除规则、计算式四样写齐

三条约束有一个共同点：它们都不是技术问题，是流程问题。流程问题在开工前解决才有成本优势，上线后再补，补的是纠纷。

五、目标区间与处置规则

点值只回答达标没达标，不回答差一点怎么办；区间才能带处置。写成三段，评审时不会争：

落点	处置
达到区间下限或更好	视为通过，按节点结算
落在下限与基线之间	按改善幅度比例结算
回到基线或更差	进入免费修补期，期限写死

六、取样方式：写到换人也能算出同一个数

判据是可复现：写清数据源、筛选条件、剔除规则、计算式。四样齐了，两个人算出来的数应当一致；不一致，说明还缺一样。

一段可以直接照抄的写法：

bash 复制代码

数据源：工单系统 T_TICKET，完工时间落在本周一 00:00 至周日 23:59
筛选：status = 'CLOSED'
剔除：客户主动撤销（cancel_type = 'CUSTOMER'）、测试单（is_test = 1）
计算：超期单数 / 全部完工单数
留存：每周五 18:00 导出 CSV，文件名含周次
附注：本周是否开过催办会（是/否）

最后一行经常被省略，但它是判断"这是系统跑出来的还是人催出来的"的唯一依据。这一节只管最后结算那一次；过程里的节点放行是另一件事，不能互相顶替。

取样脚本要在开工后第二周就跑通一遍，不要等验收前才写。脚本跑不通意味着这个指标取不到；取不到的指标只能手算，而手算的数在验收会上谁都不认。

七、观察项：三个埋点口径

图05：使用侧三个观察项：周活看真实调用的岗位数、调用次数看集中度、绕过率看系统在关键路径上是不是可选

观察项	口径	阈值判读
周活	一周内有过真实调用的岗位数，不是账号数	与账号数差三倍以上要查原因
调用次数	按岗位拆	集中度过高说明只有两三个人在撑
绕过率	该走系统却手工处理的比例	高，说明系统在关键路径上是"可选"

功能齐、培训做了、单子也签了，半年后日志安静得像没人来过------这类项目最容易被误判成功。原因不是系统难用，是它没有嵌进任何人的日常动作。判断有没有嵌进去，不看走不走流程------流程节点上照样可以有催办。看撤掉催的人之后业务卡不卡：下游拿不到输入、账对不上、单子交付不了，是嵌进去了；只是有人会来问一句，那是靠人撑。

但三项只能证"有人在用"，证不了"换个条件还在用"。上面那个检验做一次，成本不低；验收单要的是天天能取数的。两者都得有：日常盯指标，结项做条件复核。复核一般不推翻结算，只回答这套东西靠什么成立。至于能否照搬到第二个部门，不在这张单子上。

八、付款结构与变更规则

图06：三种付款结构各自的适用与风险：按使用率绑、按指标改善绑、按周期验收绑

结构	挂钩对象	适用	主要风险	缓解
按使用率	周活/调用量	工具型、上岗即用	刷量（把测试单算进去）	把"有效调用"定义写死在取样栏
按指标改善	主指标改善幅度	流程型、可归因	外部因素混入	配"同期只改一件事"
按周期验收	满一个业务周期	强周期性业务	周期长、供应方现金流压力	拆成节点付款

两个极端不做：全额预付，验收失去意义；全额后付，供应方没动力管交付质量之外的事。

还有一笔成本常被漏算：验收本身的成本------取样人工、数据清洗、复核工时。它不写进合同但真实发生，要写进预算并写明由谁承担。这段没写，最后往往是业务岗自己垫时间，垫不动就开始绕过系统，绕过率就是这么上去的。

按 90 天试点模型推的项目，第 76 到 90 天本来就该是复盘段。把它用成验收前的对账期，比上线当天临时对账省事：数据已经跑满一个周期，双方也见过异常。

评审时用四问过一遍：这个指标业务方现在有没有在看、基线有没有带日期的导出文件、取样换个人算不算得出同一个数、指标掉了谁被问责。四问有一问答不上，这张单子还不该签。

九、失败条款：四项退出物

图07：四项退出物与归属：场景卡与提示词资产、数据与标注、配置与脚本、复盘记录

只写"怎么算成"会漏掉另一半。没有失败条款的项目，结局通常是拖------不签字、不结算、不结束。四项退出物，每项都要写清归属：

退出物	交付形态	必须写明
场景卡与提示词资产	文本＋配置	能不能带走，带走的是文本还是配置
数据与标注	原始数据＋标注集	原始归客户，清洗后的标注集归谁
配置与脚本	可复跑的最小集合	能不能在客户环境复跑，交到什么程度
复盘记录	一页纸	哪个假设不成立：数据不够、场景选错、流程本不该这么走

第四项最容易被省略，也最值钱。判失败但写清假设错在哪，对下一段的用处不比成功项目小；含含糊糊判成功的项目，谁也说不清为什么成，也就复制不了。

复盘记录一页纸就够：原假设、实测、偏差、下一步。写清"原假设是什么"最要紧------多数失败项目复盘到一半，已经想不起当初假设了什么。

把前面压成一张十项字段单：主指标名、基线值、目标区间、取样方式、签字人、观察项、付款结构、变更规则、失败条款、复核（第几周、谁出人、复核什么、结果怎么用）。填不满别硬填，说明还不具备可验收的条件。

我做企业 AI 诊断，一贯的路子是先诊断，再落地。验收口径定不下来的项目，问题往往不在交付方，在企业不知道自己站在哪一级台阶上。