语音客服挂了电话，用户的问题真的解决了吗？

客服通话变短，可能是好事，也可能只是一个更长问题的前半段：用户挂断电话，打开账户，发现事情没有变化，于是又提交工单，或者再打一次。此时，仪表盘上的通话时长下降完全属实，产品给用户和客服团队增加的工作也同样真实。

Vapi 在 10 月 26 日介绍流量分割，让这个测量问题有了现实切口。团队可以把一部分通话分给修改后的助手版本，而不必一次切换所有人。接下来要决定的是：用户接触了新版本之后，究竟统计什么？如果想改善的是问题解决情况，观察就不能止于那通使用新提示词的电话。

本文为小型客服产品提出一套实验方案，不是我们已经完成的测试。撰稿没有使用 Vapi 账户、客户通话、真实路由配置或付费模型。文中的业务场景、观察时长、演练用例和工作表都是建议设计，用来让某类失败变得可见，不代表任何语音服务商已经改善了客服结果。

1. 控制上线范围，与证明改版有效，是两件事

Vapi 10 月 26 日的产品访谈介绍了逐步向助手版本分配通话的做法，并把按结果自动推广版本描述为未来方向。这是一份厂商对功能和早期使用情况的介绍，没有独立测量其效果。10 月 12 日的更新记录已经列出流量分割和带版本信息的通话日志，因此不能把 10 月 26 日写成该功能首次可用的日期。

灰度发布先限制接触新版本的人数，观察运行中是否出现明显问题；结果实验则要回答，被分配到不同体验的人，某项预先定义的结果是否发生了变化。同一个路由功能可以用于两者，但十通电话没有出故障，并不能证明问题解决得更好了。提示词可以不引起崩溃，却仍然误解退货政策。

在这套方案中，先用灰度阶段确认通话确实到达预期版本，既有保护措施也正常工作。随后另开一份比较记录，保持分配规则稳定，并根据决策需要积累足够多的独立来电者。不要把不断调整比例的几个灰度阶段混起来，凑出一个看起来方便的结果。

把要做的决定缩小：针对符合条件的订单状态咨询，是否用新的结束语提示词替换当前提示词？声音、模型、工具、业务政策以及转人工入口都保持一致。这样，团队比较的是一个可解释的改动，而不是一揽子无法拆解的变化。

2. 先选一个能在对话之外核实结果的问题

假设一家小型订阅业务用语音助手处理配送进度咨询。A 版本读出当前状态，结束时邀请用户继续提问。B 版本则先确认，这条状态是否真正回答了用户的问题；如果没有，就提供原本已有的人工支持入口。两个版本的权限和订单数据访问能力完全相同。

假设是：B 能提高来电者首次符合条件的问题的可核实解决率，同时不增加错误承诺和客服总工作量。这里描述的是虚构业务，不是客户案例。实验不要求助手退款、改地址，也不允许它编造送达日期。

在任何人入组之前，为每种支持的问题写明解决标准。“我的包裹在哪里？”可能只需要准确的物流信息；如果用户问的是“物流显示已送达，但我没收到”，那就是另一类问题，可能必须建立人工处理工单。读对一条物流状态，并不能同时解决两种需求。

依据业务真实的服务政策、订单记录和允许采取的下一步动作，固定一份判断规则。审查者即使不知道助手版本，也应能说明哪些证据满足了哪条规则。如果团队自己都无法就解决标准达成一致，就先暂停比较。把更多电话分给新版本，也无法补上尚未定义的产品承诺。

3. 先确定来电者，再统计他的电话

Vapi 路由文档说明，分流比例作用于新发起的通话，已经进行中的通话不会中途换版本。系统会根据电话号码或 SIP 用户名，尽量让再次联系的人进入原来的版本，但这种粘性没有绝对保证。网页通话，以及缺少这类可用标识的通话，可能每次独立分配。版本目标的排列顺序也会影响粘性。追踪后续结果时，这些限制必须先讲清楚。

因此，建议的主要观察人群应从路由身份与已获授权的客服身份能够可靠关联的来电者开始。用新提示词生效前就能得到的信息判断资格，例如原有流程中已经完成身份验证的订单选择步骤。每位来电者在入组期只纳入第一个符合条件的问题，同一实验中不再重复入组。不要把一个人为解决同一件事做出的每次尝试，都当成一个新的独立客户。

电话号码不天然等于一个人或一个账户。家庭共用号码、企业总机、隐藏来电号码以及多设备使用，都需要提前写入资格规则。已知身份存在歧义的情况，单独记在可行性报告里。不能先看到结果不好，再以身份难处理为由把这个人删掉。

微软的实验前设计建议强调标识稳定性、不同参与者之间的相互影响，以及按随机分配单位计算所需样本。在本方案中，来电者首次被分配到的可观测版本决定其分析组。之后即使换过版本，也只增加交叉暴露记录，仍留在最初的组里。这样估计的是实际部署的分配策略，包括粘性不完美的影响，不能把结果解释成始终使用某一提示词的纯粹效果。

4. 跨渠道使用同一个固定观察窗口

演练可以从首次符合条件的通话开始，观察 72 小时。这只是作者选择的示例，不是行业标准。周末不发货、工单响应较慢的业务，可能需要更长的窗口。应根据服务周期事先确定时长，再开始收集版本比较的结果。

起始问题是启动窗口的第一个符合条件的客服需求。重复联系是用户为了同一个问题又来联系，无论后来走的是电话、在线聊天、邮件，还是重新打开工单。关于另一笔订单的新问题，不应自动归为重复。先写好匹配规则：账户标识、订单标识、问题类别，以及有歧义时由谁人工判定。

第一通电话挂断时，不重新计时；用户再次来电时，也不重新计时。否则，导致更多重试的版本会获得不同长度的观察期。按预定日期停止招募新来电者，再等最后一位入组者完整走完窗口，才进行最终比较。

微软关于跨产品 A/B 实验的实践说明解释了为什么第二套系统中的结果必须关联到原始分配。放到客服渠道上，就是即使没有后续联系事件，入组者也不能消失。同时还要单独记录：这些渠道是否真的可观测？只有底层采集和关联正常，“没有匹配到后续事件”才有解释价值。

5. 把解决、重复联系和未知结果分开记录

至少保留三个独立字段：固定规则是否确认问题已解决；窗口内是否出现同一问题的非计划重复联系；后续观察是否完整。一个人没有被记录到再次联系，不代表已经有解决证据。他可能放弃了，也可能去了团队没有观察到的渠道。

主要结果统计经核实且在窗口内未反复的问题解决，下文简称“持续解决”。计入成功必须同时满足：达到该问题的解决标准；窗口内没有与之矛盾的重新开单或非计划重复联系；所需后续证据齐全。任何必要条件未知，都在主要统计中记为未成功，仍保留在分母里，并另列未知数量。这是偏保守的运营指标，不是在宣称所有未成功者都不满意。

计划内跟进与用户被迫重试，要分开统计。对于助手无法独立处理的问题，安排一次正确的人工回电可能就是合理处理路径，但它不属于自动解决。人工协助后的解决与自动解决都应保留。不要通过藏起转人工入口，让“拦截了多少人工请求”变得更好看。

Vapi 的结构化输出是在通话结束后，用 AI 分析对话并提取信息。它可以为审查提供问题类别或“声称已经解决”的候选标签，但通过 JSON Schema 校验的 resolved: true 仍然只是模型提取出来的判断。要用相应业务记录和固定规则核实；两组使用同样的提取器和规则。除了不确定、失败的情况，也要抽查被标为成功的情况，防止一个乐观的提取器悄悄替团队定义成功。

6. 在通话仪表盘旁，再建一份问题台账

Traffic 页面按版本比较通话时长、成本、延迟、结束原因，以及配置比例与实际比例。文档也提醒，固定时间范围可能跨过此前的分流阶段，没有版本信息的通话不会进入页面统计。这些数据有助于观察运行情况；按问题追踪的一组来电者，还需要另一种分母。

每位符合条件的来电者只建一条入组记录，把相关通话和客服事件关联进来。首次版本、分配阶段和后续实际接触版本要分开。这里的“分配阶段”，是分流比例、版本排列顺序和实验配置都保持不变的一段时间。提示词更新、目标重新排序或比例改变，都会结束当前阶段。

下面是一份需要自行适配的数据约定，不是 Vapi API 字段，也不是可执行配置。保留英文键名，便于两种语言的团队共用同一份台账：

experiment: delivery-closing-prompt
cohort_key: pseudonymous-authorized-caller-key
index_issue: pseudonymous-order-key-plus-issue-family
eligibility_rule_revision: required-before-start
first_call_id: required
first_assigned_version: required
allocation_epoch: required
window_started_at: required
window_ends_at: required
exposures: [] # 通话 ID、实际版本、时间
support_events: [] # 渠道、问题匹配、计划内或非计划
resolution_rule_revision: required
verified_resolution: unknown # yes / no / unknown
unplanned_same_issue_recontact: unknown
followup_coverage: unknown # complete / incomplete
crossed_version: unknown
durable_verified_resolution: unknown
total_support_cost: unknown
adjudication: pending

Vapi 通话日志文档列出了通话 ID、版本、结束原因、相关产物及工具调用查看方式，实际可用内容取决于配置。入组前先确认自己的账户中确实存在所需记录。这张台账并不意味着某个现成导出功能已经能把所有客服渠道自动关联起来。

关联时使用假名化标识，只保存判断结果所需的最少字段，限制访问，并遵守团队已有的保留政策。对电话号码做哈希之后，它仍然可能用于关联身份。这个实验没有理由让团队额外保存录音，或在缺少授权用途时合并客户身份。

7. 接触客户之前，先演练数据能否关联

使用员工控制的身份和虚构订单做合成演练。先准备十二种情况：正确回答、错误回答、正常转人工、中途放弃通话、邮件重复联系、电话重复联系、计划内回电、无关的新问题、身份未知、版本缺失、日志迟到，以及再次联系时换了版本。这是检查覆盖范围的十二个用例，不是足以证明性能的十二份样本。

每次生成事件前，先写下期望的台账状态。缺少版本的通话应该进入入口核对记录，并阻止结果归因，不能因为版本仪表盘没显示就凭空消失。日志迟到的用例要验证是否按事件实际发生时间处理：只要联系发生在窗口内，即使日志后来才到，也仍与结果有关。最终冻结数据前允许等待多久，应提前确定。

随后，可以考虑用两个实际配置相同的已发布版本，再通过员工可控流量做 A/A 演练。目的在于发现版本归因错误、关联丢失、信息提取不一致或两边日志记录不对称。它不能证明服务商随机分配算法正确、真实人群平衡，也不能证明生产环境的后续观察完整。保留演练前后的记录，让实现者之外的人能够重新算出各个标记。

如果当前系统无法关联准备观察的渠道，或者不能确认首次符合条件的接触被分配到了哪个版本，就停在可行性阶段。仍然可以做范围更窄的逐通电话运行比较，但不要称它为持续解决问题的实验。这个停止条件，是为了防止小团队围绕一个根本看不见的结果，积累出漂亮的仪表盘。

8. 核对分配时，别把通话数当成来电者人数

样本比例失配，简称 SRM，指观察到的分配比例与预期比例的偏离，已经超出所采用随机分配模型能够解释的范围。微软的SRM 排查建议将它视为需要调查的数据质量信号，而不是遇到好看结果时可以绕过去的细节。

保留两份核对记录。运行核对从所有进入系统的通话出发，逐一对应有版本通话、无版本通话、资格判断以及入口失败。实验核对则在每个固定分配阶段内，检查去重后新入组的来电者，而不是把所有通话混在一起。回头客的多通电话彼此相关；如果新版本导致更多重试，通话占比发生变化本身就可能是结果，不能直接当成分配故障的证据。

在声称改动导致了结果差异之前，先核实这类符合条件的来电者是如何首次分配版本的，其预期比例是否适用于准备采用的 SRM 检验。公开的粘性路由说明不是完整的随机化证明。如果无法确认机制，就把工作称为受监控的观察性试点，避免因果措辞。不能只因为仪表盘上有配置比例，就对重复来电直接计算二项分布的 p 值。

用接触新提示词之前已确定的渠道和问题类别，检查异常失衡或数据缺失。分配未知的情况要单列，不能为了让人数平衡，把它们塞进方便的一组。分配记录丢失原因不明、关联失败受版本影响，或者入组人群失衡无法解释，都应阻止“改版有收益”的结论。修好采集后，另开一批有清晰记录的观察人群，不要删掉难看的行。

9. 比较结果时，守住最初的分母

设 N 为某组所有已入组、已分配版本，并且观察窗口已经走完的来电者人数。持续解决率，就是满足全部主要成功条件的人数除以 N。失败通话、换过版本、转过人工和缺少后续证据的人，仍在 N 里面。分别列出这些数量，避免保守指标掩盖了可观测性本身有问题。

举一个纯粹说明算法的虚构例子：A 组有 100 位入组者，70 个持续解决，5 个结果未知；B 组也有 100 位，74 个持续解决，但有 15 个未知。主要比例是 70% 和 74%。如果删掉未知结果，两组分母都会改变，B 的表现尤其会显得大幅改善。这些不是测试结果；这样的少量样本中，四个百分点的差距本身也不足以证明改版有效。

报告绝对差值，并按照真正独立的分配单位计算不确定性区间。如果多个身份共用路由，或多个来电者属于同一账户，可能需要按组分配并做聚类分析，不能默认 200 行就是 200 个相互独立的人。开始前先确定最小值得追求的改善、基线假设、统计功效和分析方法。如果路由机制不满足这些假设，应请有统计经验的人协助设计。

很小规模的灰度阶段，可以发现显眼故障，却可能根本没有能力测出温和的收益。低流量团队可以在得到有价值的可行性结论后停止，也可以事先登记好方案，再运行更长的比较。不要因为某一天好看就宣布赢家。安全监控可以随时停止新版本暴露；收益判断则遵循预定分析方案，而不是反复检验，直到碰到一次显著结果。

10. 把转移到电话之外的工作也算进来

一个有用的伴随指标，是固定窗口内每位入组者消耗的客服总工作量。最初通话、重复联系、人工回电、工单处理和纠错都要计算。还可以展示每个持续解决问题的成本：分子用该组全部客服成本，分母用持续解决数。如果一个成功案例都没有，或者成本记录不完整，就如实说明，不能编一个效率数字。

人工工作采用什么计价方式，要事先声明。已安排的整体人力成本与新增处理时间不是同一概念，两组必须使用一致口径。如果无法把员工分钟数可靠地折成金额，就把电话费、模型费和员工用时分开呈现。语音账单下降，与人工工作变多，完全可能同时发生。

微软关于指标解读陷阱的原始研究讨论了局部指标改善、指标所覆盖人群变化为何可能误导产品决策。在这里，无论工作转移到哪里，都用最初入组的人群来锚定比较。通话时长、轮次延迟和转人工率可以帮助解释结果，却不能替代选定的问题解决指标。

11. 提前写清楚，什么结果才允许推广

开始前完成下面的工作表。每个阈值都需要替换成适合自己业务、并且有理由支持的具体值。还有阈值留空，就说明实验没有准备好。

最后选择四种结果之一：修复采集；保留 A；按预先写好的计划延长比较；或者只针对验证过的人群推广 B。如果分配机制仍未核实，团队可以依据有限证据做运行层面的推广决定，但报告不能声称取得了随机实验支持的因果收益。

停止招募或回滚之后，已经入组的人仍要继续收集后续证据。回滚改变未来接触，不改变历史分母。紧急修改要记录内容和时间；一旦改动改变了实验干预，就结束当前分配阶段。不能为了保持实验形式上的完整，让需要帮助的来电者继续受影响。

12. 明确这套实验回答不了什么

这套设计适用于可重复、风险较低、有独立结果判断规则，并且能观察后续渠道的客服问题。身份共用关系无法厘清、结果几个月后才出现，或者业务根本不知道未解决的工作流向何处时，就不适合照搬。它也不能替代医疗、金融、紧急求助等高后果通话所需的领域审查。

72 小时的示例窗口，无法证明长期满意度、留存，或以后再也不会复发。即使指定渠道的日志完整，也看不到所有默默放弃的人。实际部署策略的比较包含换版本的真实行为，不能自动把差异全归因于提示词措辞。本文没有来源独立验证 Vapi 功能的实际效果，也没有声称完成了实验。

第一步可以很小：选一类问题，看看能否在不让助手给自己打分的前提下，把昨天的一通电话关联到真实结果。关联不起来，就先补这段能力，再扩大新版本接触范围。关联可靠之后，流量分割才能帮助团队判断：改版究竟解决了一个问题，还是只结束了一段对话。

参考来源

1. Vapi：Traffic splitting is live，2026 年 10 月 26 日——产品访谈，属于厂商介绍，不是效果验证。
2. Vapi：2026 年 10 月 12 日当周更新记录——功能更早已经可用的记录。
3. Vapi：流量分割文档——路由、身份、目标排列与版本固定规则。
4. Vapi：在 Traffic 页面比较版本——指标、时间范围与无版本通话的统计边界。
5. Vapi：结构化输出——用 AI 从对话中提取信息。
6. Vapi：通话日志——可查看的通话记录及检查入口。
7. 微软研究院：可信实验的实验前设计——假设、身份与随机分配单位。
8. 微软研究院：跨产品 A/B 实验——把下游结果关联到原始分配。
9. 微软研究院：诊断 A/B 实验中的样本比例失配——分配与数据质量问题排查。
10. Dmitriev 等：A Dirty Dozen，KDD 2017——指标解读为何可能误导决策的原始研究。