Vapi：让 AI 接电话之前，先把难处理的来电试一遍

让应用可以听懂来电，也能执行任务

Vapi 是搭建语音 AI 助手的平台。它把语音转文字、模型理解、文字转语音与工具调用连接起来，开发者可以用它制作电话接待、客服或预约助手。它解决的是“把一个会回答的模型接到真实语音交互里”，而不是只生成一段录音。

例如，一家摄影工作室希望助手接待咨询、询问拍摄时间，并通过预约工具查询空档。第一次试拨顺利，并不能说明修改提示词后仍然可靠：有人会改变主意，有人会说得含糊，预约服务也可能出错。

从一项来电任务定义可检查的结果

以摄影工作室的改约为教学情境：用户需要明确新时间，预约服务失败时不能被告知已经成功。先把这些结果写成成功条件，再用 Simulations配置模拟来电者。场景表达目标和已知信息，Personality（性格）表达沟通方式，一组相关模拟可以组成 suite（测试集合）反复使用。

先准备独立测试助手和受控的工具环境，再确认待测版本，避免尚未验证的修改先接到真实来电。上线路径说明模拟针对最新已发布版本，而不是正在编辑的草稿；否则修了草稿再运行，可能仍在测试上一版行为。

控制输入与工具边界，再运行对话

1. 选择检查层次：语音测试指南区分检查某一步是否选对工具、跑完整文字对话和进行音频对话。先查任务逻辑，再把重要语音问题放进音频模式，避免用文字通过代替听觉检查。
2. 配置来电行为：同一改约目标可以遇到耐心、含糊或中途改主意的来电者，检查助手是否仍能把事情办清楚。
3. 安排工具返回：需要稳定复现无空档或服务错误时，使用对应 mock（预设的模拟工具返回）。它是替代指定工具的返回，不是自动隔离全部环境；未模拟的工具仍会真实执行。
4. 执行并读证据：查看逐轮对话与条件结果，音频任务再听录音，定位哪一步出现误解或错误承诺。

模拟的价值在于主动制造边界情形，而不只是反复确认一句欢迎语是否自然。

改完后复测同一组任务，再验证真实结果

先用独立的测试助手和受控工具环境验证修改，不要直接把未验证版本发布到已接真实号码的助手。官方上线路径说明：连接真实号码后，发布版本会立即处理线上来电。测试助手发布目标版本后，重新运行保留的测试集合，比较新旧证据；确认通过再安排正式助手的发布。成功条件写得过宽或过窄都会误导判断，分数变化需要回到具体对话解释。

快速开始区分助手说出预约信息与日历里实际出现预约。mock 成功只能证明在指定返回下的行为；真实线路、噪声和外部系统结果仍需验证。把自动模拟与真实集成检查接起来，才知道助手既会正确沟通，也能在实际服务里完成任务。

把“要完成的事”和“来电者的表达方式”拆开

工作室要检查的是能否正确改约，不是能否背出固定台词。把目标与沟通风格分开后，同一目标可以遇到不同来电者：一个信息齐全，一个需要反复解释，一个中途改变时间。

这种组合让测试更接近产品问题：改变语气后任务是否仍能完成，而不只是措辞是否相同。相应地，成功条件应允许多条合理对话路径；如果强制要求一字不差地说完脚本，就可能把有效沟通错判为失败。

记忆点在于：稳定的是用户要办成的事，变化的是到达结果的路径。

让失败成为可以主动制造的测试条件

预约服务今天正常，不代表下一次发布时仍然正常。通过工具模拟返回“无空档”或“服务错误”，团队可以有意观察助手怎样解释、是否继续追问、是否错误地宣布成功。

这里有两个需要分别判断的层次：工具返回什么，以及助手如何表达这个结果。前者可控制，后者才是本轮测试对象。把它们拆开后，“没有预约却说预约好了”就能被描述成具体失败，而不是笼统的“AI 不太稳定”。

分数旁边必须留有可复核的对话

通过率适合发现变化，却不能独立说明变化原因。一个条件写得太宽，会让不合格对话通过；写得太窄，又会惩罚另一种合理表达。逐轮对话和录音让人能检查评分是否符合真正的任务要求。

因此，值得借鉴的不是给每次对话涂绿，而是把判定标准、观察证据和后续修正连起来。同一例子在修改前后都保留，才更容易看出修正解决了什么，又是否带来了新问题。