没有基线的效果评估，都是自说自话

一个用了三个月的 AI 客服，老板问它到底省了多少时间。能拿出来的只有供应商后台的一张图：会话量、平均响应时长、满意度，三条线都在往好的方向走。

这张图回答不了那个问题。因为上线之前，没有人量过。

于是接下来发生的事很固定：负责这件事的人开始找感觉——"以前一单大概要半小时吧"，"快多了"。这句"以前大概"就是全部的基线，它不来自任何一次计时，来自记忆。拿记忆当分母算出来的提升，是自说自话。

一、三个最常见的错法，你多半犯了其中两个

错法一：把上线后的数当成效果。

会话量、响应时长、满意度这三个数都是真的，问题在于它们没有对照。没有对照期，也没有对照组，那么它们只能说明"这套东西在运转"，不能说明"它比原来好"。

这一条听起来是常识，但它在实际里长成另一副样子：汇报材料上会写"平均响应时长 2.4 分钟"，而没有人问上线前是多少。因为上线前那个数根本不存在，于是它就从汇报里消失了，只剩下一个孤零零的 2.4。

错法二：拿供应商后台的指标当自己的指标。

供应商给你的指标是它能测的，不是你要的。它能测"从客户发出消息到系统给出第一句回复"，测不了"这件事一共占了你的人多少分钟"——因为后半段发生在它的系统外面：转给人、人去查、人回来答、客户又追问一句。

这两件事经常反向变化。第一句回复更快了，而整件事占用的人工分钟数没变，甚至因为多了一道"看看它答得对不对"而变长。只看前者，你会得到一份漂亮且错误的结论。

错法三：一上来量五个指标。

五个指标的采集成本不是两个的 2.5 倍。多出来的那三个通常包括满意度和准确率，这两样都要额外去问人、去抽检，采集动作从"记一个数"变成"发起一次沟通"。两周之后你会拿到一张缺格子的表，然后整张表作废。

再放一组外部的数，用来说明"没量过"这件事有多普遍。据埃森哲中国数字化转型指数 2025 年版（2025 年 7 月），46% 的企业在规模化使用生成式 AI，而只有 9% 拿到显著价值。据 InfoQ 研究中心与中欧国际工商学院《中国大模型落地应用研究报告 2025》（N=1166，2025 年发布，核心数据标注来源为 2024 年 7 月调研），进入大范围推广的只有 14%，序言里那三句话是「试点易、复制难；用得上、用不好；投入快、见效慢」。

请注意这些数字共同的前提："拿到显著价值""见效慢"这类判断，本身就建立在有人量过的基础上。 而在你自己公司里，那个前提通常不成立——你既不知道自己算不算那 9%，也不知道自己离它有多远。

二、先定"一次"是什么，再谈量什么

处方从这里开始。三步，顺序不能换，答不上任何一步就停在那一步。

第 1 步。定计数单位：什么算"一次"。

不是"客服工作量"，而是"一次咨询从进来到关闭"。不是"报价效率"，而是"一次询价从收到到发出报价"。不是"对账"，而是"一个供应商一个月的一次对账从开始到确认无误"。

这一步最容易被跳过，跳过之后所有的数都不能相加。给三个反面例子：把"一次咨询"和"一轮追问"混着算，条数会虚高；把"一次报价"里的改价重发算成新的一次，耗时会虚低；把"对账"按单据条数算而不按供应商算，两个月之间没法比。

判据只有一句：这个"一次"必须有一个明确的开始动作和一个明确的结束动作，两个动作都能被同一个人观察到。 说不清结束动作在哪，就说明还没拆干净，回去拆。

第 2 步。定两个指标：一个耗时，一个返工。上限是两个，我建议一个都别多。

耗时指标：这一次从开始到结束，占用了人多少分钟。注意是占用人的分钟数，不是自然时间——中间等别人回复的那 40 分钟，如果这个人去干别的了，就不算在里面。这一条要在开始之前跟记录的人说清楚，否则两个人会记出两套口径。

返工指标：这一次有没有被退回来重做。只记有和没有，打个勾，不记程度。

为什么第三个指标不能加：第三个通常是满意度或准确率。这两样的采集成本是前两样的十倍，而且三天之内采不出有意义的量。它们该在上线三个月之后单独立项去做，不该混在基线里。

第 3 步。定一张表：四列，一张纸。

日期 / 这一次的编号 / 占用分钟数 / 返工（打勾）。就这四列，不许加第五列。

三条约束，一条都不能松：

• →记的人必须是干活的那个人本人，不是主管，不是被指派搞 AI 的你。主管记的是印象，本人记的是分钟。
• →记的时间点是做完那一刻，不是下班前统一补。补的那份基线一律作废——人对自己刚花掉的时间的估计，误差方向是稳定偏低的。
• →表头上必须写清这次采集的用途，一句话：本次记录用于测量流程耗时，不与任何人的绩效挂钩。这一句要真的做到。

关于最后一条，我的建议是把用途如实说出来，而不是含糊成"统计各岗位工时"。在一家几十人的公司里，隐瞒用途几乎必然穿帮，而穿帮之后你损失的不是这一次的数据，是下一次采集的配合度——而下一次采集，就是上线之后的那一次，那一次比这一次重要。

三、三天怎么定，以及三条让这份基线作废的情况

为什么是三天。 三天是"能盖住一个业务小节律的最小值"和"人还愿意认真记的最大值"之间的一个折中。这个天数是本文给出的建议值，不是任何研究的结论，你的业务如果是周节律（比如周一集中来单），那就采一个完整的周而不是三天。

但三天有个前提：这三天必须是普通的三天。 撞上下面任何一条，往后推，不要在这几天采：

• →月初或月末的对账高峰；
• →大促、展会前后一周；
• →有人休假由别人顶班的那几天；
• →系统刚换过版本的第一周。

算法：取中位数，不取平均数。

把三天里所有条的分钟数从小到大排一遍，取中间那一条。如果一共 27 条，就取第 14 条。

理由是耗时的分布是长尾的：一次卡了三个小时的异常单，会把平均数拉走十几分钟，而它一个月只发生一次。中位数不受它影响。这一步是本文给的口径，不是行业标准——如果你的汇报对象一定要平均数，那就两个都给，并且把最长的那三条单独列出来说明。

三条作废条件：

第一，三天里有一天的条数不足另外两天的一半。 说明那天不正常，作废重采，不要用另外两天凑。

第二，记录人中途换过。 分开算，别合并。两个人对"占用分钟数"的理解差异，通常大于你要测的那个提升。

第三，采集期内有人明确要求"你们记得快一点"。 这一句一出口，这份基线就废了——你测到的不再是常态，是被观察之后的状态。所以第 2 步末尾那句"不与绩效挂钩"必须由主管本人说，不是由你转述。

四、上线之后怎么用这张表，以及什么时候不该采基线

上线之后，同一张表、同一个人、同一套排除规则，再采三天。 然后拿两个中位数相减。

给一个演算示范，下面这两个数是为了说明口径而设的假设值，不是任何一次实测：假设上线前中位数 42 分钟、上线后 26 分钟，差 16 分钟；这个月这件事跑了 180 条，16 × 180 = 2880 分钟，约 48 小时。

这个 48 小时有一句必须跟着的口径说明，它是最常见的一次夸大：这 48 小时不等于省下 48 小时的工资。 它是分散在 180 次里的碎片，每次 16 分钟。除非你把这些碎片攒起来去做另一件具体的事——多接一档单、把某项一直没人做的整理做掉、把加班压回去——否则它不落到任何一张成本表上。汇报里写"节省 48 小时"没问题，写"节省 X 万元人工成本"就越界了，除非你能说出那 48 小时被换成了什么。

返工那一列的用法更简单，也更容易被跳过：如果耗时降了而返工升了，那不是省了，是把工作从前面挪到了后面。 这种情况在上线第一个月很常见，它不代表失败，代表校对环节的强度还没降下来——但你必须看得见它，才不会在第二个月盲目扩大范围。

接下来是这套方法的代价，三条。

第一，采集这三天，干活的人每次要多花十几秒记一笔，还要在心里区分"占用分钟"和"自然时间"。这是真实的打扰，别假装没有。

第二，这份基线不准。它一定偏低（人对刚花掉的时间估计偏低）、一定漏记（忙的时候会忘）。它的价值不在准，在于上线后用同一套有偏的方法再采一次，两次的偏差方向一致，差值才有意义。 所以上线后那次绝不能换人、换记法、换排除规则——换了，前面全白采。

第三，两个指标意味着你主动放弃了很多信息。准确率、满意度、客户流失，这些在基线里都不会有。接受这一点，否则你会在第 4 天开始加列，加到第 10 天这张表就没人记了。

什么时候不该采基线，三种情况。

第一种：这件事一个月只跑三五次。 三天采不到样本。这类流程不要装成基线，就老老实实做一次完整的实测：上线前完整记一次（每一步几分钟、卡在哪），上线后完整记一次，两次并排放。样本 1 对 1，但它诚实，比一份用三天硬凑出来的假基线有用。

第二种：你还没定下这件事的"一次"是什么。 回第 1 步，别往下走。定不出开始和结束动作，说明这段流程本身还没被写下来，那么该做的是把流程写下来，不是采数。

第三种：你已经上线了。 那就承认基线没了。唯一不该做的事是用"上线前印象中的样子"倒推一个数写进汇报——那是自说自话的第二种形态，而且比第一种更危险，因为它带着一个具体的数字。

这种情况下能补的只有一件事：去找上线前留下的、带时间戳的原始记录——工单系统的创建与关闭时间、聊天记录的首条与末条时间、邮件的收发时间。只取有时间戳的那部分，条数少也没关系，然后在汇报里写明"样本 N 条，来自某系统的时间戳，非全量"。条数少而口径清楚，比条数多而来路不明强得多。

最后说一句为什么这件事在 AI 这类项目上格外要紧。换一套新的业务系统，前后对比可以事后补——旧系统有日志，新系统也有日志，两边都能导出来。而 AI 顶掉的那一段恰恰不在任何系统里：它顶掉的是一个人打开对话框、想一下、写一段话的那几分钟。这几分钟在上线前没有任何日志，上线后落进了供应商的后台，两边口径还不一样。所以这是少数几类"基线必须靠人手工采、且过期不补"的项目——它不像别的系统那样，事后还能从数据库里翻出来。

这套评估往下延伸到迭代闭环怎么排，完整的做法在《DeepSeek企业实战》第 5 课。