语音智能体开场告知的十二项验收测试

语音 Agent 答得再准，也可能在接通电话时就出问题：来电者没听清自己正在和 AI 交谈，或者把 AI 身份告知当成了录音提示。作者的结论是，把告知做成整条通话链路的上线验收条件，不能只在系统提示词里加一句话。

这篇值得程序员读的地方，是它把透明度要求拆成了音频、路由、时间戳和发布记录。不过，文中的 12 个场景没有经过真实通话验证，配套脚本也只能检查证据登记是否完整，不能替人判断告知是否有效。

前 10 秒是检查窗口，不是法律倒计时

按原文转述的欧盟委员会 FAQ，Article 50(1) 涉及直接与自然人进行双向交互的 AI 系统，要求从首次交互开始，以清晰、可区分的方式告知身份；「显而易见」的例外应从严解释。原文称 Article 50 自 2026 年 8 月 2 日适用，第 2 款部分内容标记义务的过渡安排，不能扩展成全部透明度义务的延期。这里是对原文法律依据的转述，具体部署仍须核对适用规则。

标题里的「前 10 秒」是作者选的实用检查窗口，并非法律规定的时限。真正要判断的是：在 AI 开始实质交流之前，来电者是否已经收到可理解的身份告知。不能先问业务问题，过几轮再补一句自己是 AI。

谁负责也不能凭采购关系推断。原文区分 provider 与 deployer，并提醒团队记录谁控制首段音频、谁能修改文案、谁维护路由。供应商控制模型，采购方控制电话交换系统（PBX）时，双方都有可能以为完整链路已经由对方验过。

告知文案则要回答不同的问题：正在交谈的是 AI，属于身份信息；通话是否录音、是否转写，属于数据处理信息。转写可以发生在不保存音频的情况下，录音提示也不会自动告诉用户对面是 AI。

AI 身份、录音和转写，需要分别表达清楚。

作者建议用来电者能理解的语言，说明这是代表某个组织的 AI 助手，再给出提问或转人工的下一步。这是交互建议，并非统一法定措辞。

验收对象应该是来电者听见的声音

管理后台有文案，只能证明配置存在。真实电话还会经过运营商连接、交互式语音应答（IVR）、排队、语言分支、转接和兜底。任何一层都可能让开场白被截断、被其他播报覆盖，或者晚于第一句 AI 业务回复。

作者要求关联保存四类证据：批准的文案与语言、电话路由与软件版本、来电端音频或可确认顺序的监听记录，以及审核人依据验收标准给出的结果。关键时间戳包括接通、各段播报起止、首次用户发言、首次 AI 实质回复、转接开始和完成。

本地预览可以早期排错，最终验收仍要拨打客户实际使用的号码，走相同的入口和路由。若测试录音不适合采集，原文允许使用有记录的人工监听或足够确认顺序与完整性的平台轨迹。

开场播完还不够。用户之后问「你是真人吗」，模型也必须如实回答。原文引用 RealityTest：研究测试了 17 个文本模型和 6 个语音模型，发现身份披露行为存在差异，一条要求不披露身份的系统指令就能显著降低披露率。它测的是模型回答，并未验证电话链路，因此只能支持一个有限结论：不能依赖模型临场生成开场告知。

更稳妥的组合是固定、带版本的开场音频，加上持续如实回答身份问题的模型指令。两部分都要验收。语言切换、发音、语速、移动网络下的音量，也属于测试范围；网页上的隐私说明无法替代电话里的可听告知。

12 个场景检查覆盖，脚本检查登记

作者明确说明，这组场景于 2026 年 11 月 9 日人工设计，没有测量真实来电、参与者、供应商表现或通过率。12 指场景数，不是用户样本数。提供的原文也没有列出 D1 到 D12 的具体内容，不能据此补出一套所谓原版矩阵。

测试前应写好预期语义，再逐条执行。结果只有 PASS、FAIL、INCONCLUSIVE；音频缺失、时间戳含糊，都不能算通过。修复缺陷后，还要重测可能受影响的相邻转接或路由。

下面保留原文检查器的关键配置与检查循环，它解决的是证据漏填问题：

REQUIRED = {f"D{i}" for i in range(1, 13)}
FIELDS = ["case_id", "route_id", "locale", "build_id", "notice_version",
          "call_trace", "reviewer", "tested_at", "result", "failure_note"]
VALID_RESULTS = {"PASS", "FAIL", "INCONCLUSIVE"}

要注意 REQUIRED 只定义了 D1 至 D12，FIELDS 才承载路由、语言、版本和审核信息。

    errors = []
    seen = set()
    for line, row in enumerate(rows, start=2):
        case_id = (row.get("case_id") or "").strip()
        seen.add(case_id)
        for field in FIELDS:
            if not (row.get(field) or "").strip():
                errors.append(f"line {line}: empty {field}")
        result = (row.get("result") or "").strip().upper()
        if result not in VALID_RESULTS:
            errors.append(f"line {line}: result must be PASS, FAIL, or INCONCLUSIVE")
        if result == "FAIL" and not row.get("failure_note", "").strip():
            errors.append(f"line {line}: FAIL requires failure_note")
        if case_id not in REQUIRED:
            errors.append(f"line {line}: unknown case_id {case_id!r}")

要注意 for field in FIELDS：它要求包括 failure_note 在内的所有字段都非空，实际比后面的「FAIL 必须填写失败说明」更严格。

完整脚本保存为 check_disclosure_cases.py，运行命令是 python check_disclosure_cases.py disclosure-evidence.csv。它把「登记完整」与「可进入后续发布审核」分开，存在 FAIL 或 INCONCLUSIVE 时返回失败。但它不听音频、不判断法律适用，也不证明用户理解。

我的判断

我认同把检查点放到来电端。只测模型、只看供应商演示，容易漏掉电话基础设施引入的问题。固定开场音频也比完全依赖生成式开场更容易控制和追溯，但仍要验证用户实际收到的声音。

这套方法目前是一份验收设计，没有实测结果，更没有证明某种文案能提高信任。原文引用 EY 2026 年调查：18,152 名受访者来自 23 个市场，34% 希望 AI 无须自己参与便解决客服问题，66% 认为人工监督仍然必要，73% 担心无法辨别人类与 AI 内容。调查采用市场等权处理，部分市场样本也不代表全部人口。这些数字能解释为什么需要清晰选择，不能预测某条业务线的挂断率。

脚本距离团队发布工具还有两处缺口。它只检查 D1 至 D12 是否出现，没有验证每条路由、每种语言是否覆盖完整；它还会统计全部历史行，旧版本的 FAIL 也可能阻塞新版本。接入发布流程前，需要明确目标版本和覆盖组合。

另外，提供的原文在最后一段截断，无法确认作者后续如何设计业务指标比较。能确认的原则是先锁定必须提供的告知，再观察继续通话、转人工或放弃等结果，不能为了转化率删掉告知。

能拿来做什么

• 为语音 Agent 绘制实际入口清单，标出公开号码、IVR、语言分支、转接和兜底，再逐条验证告知播放顺序。
• 在 Node 编排服务中记录告知版本、路由、语言和关键事件时间，把记录关联到人工审核结果，避免只留下模型请求日志。
• 为前端配置后台区分 AI 身份、录音与转写文案，并明确哪些配置变化会触发重测。
• 借用 CSV 登记思路时，补上按目标版本和路由语言组合验收的规则，同时保留人工听审；全部场景通过，也只能报告指定配置下的覆盖结果。