语音交互设计规范

面向设计师与工程师：让系统听得准、让用户随时打断得了、让话说得短到能记住、让忘了的能再问一遍、让声音的身份不含糊、让在场的人知道麦克风在做什么，并且始终留着一条不说话也能办成事的路。

语音把交互压进了一条线性的、不可扫视、不可回看的通道。屏幕上用户可以先扫一眼再决定要不要读，语音里用户必须听完才知道该不该听；屏幕上信息留在那里等人回来看，语音里说过就没了。同时，麦克风前面往往不止一个人，喇叭外面也往往不止一个人。

因此语音交互的设计对象不是"话术"。设计对象是：系统对用户话语的接收与理解结果、话轮控制权的持有与让出、系统语音输出本身、听者的短时记忆、合成声音所承载的身份、麦克风所处的物理空间，以及语音这条通道的进入与退出。

本规范由七条原则和47 条规则组成：原则说明设计方向，规则规定适用情境、行为要求与验证方式。每条规则归属且仅归属一条原则，规则编号即原则编号（V3-2 就是第三条原则下的第二条规则）。

本规范约束的是产品在语音场景下对用户作出的体验承诺及其兑现机制的性质，不预设唯一的技术架构，不绑定任何一家的识别、合成或实时通话方案，也不区分级联管线与端到端语音模型——两种架构下的体验承诺相同，兑现方式不同。它不是话术手册，不是对话流程图模板，也不是语音引擎的调参指南。

采用本规范不能替代无障碍、隐私、安全与领域合规的专项评估。语音场景显著放大三类风险，这些专项评估比图形界面产品更必要而不是更次要：听觉是唯一通道时，认知与感知差异直接决定任务能否成立；麦克风采集的是物理空间，第三方从未同意；合成语音的身份披露在多个法域已是法定义务而非设计选择。

全文四章：第 1 章原则，第 2 章规则的读法与速查，第 3 章规则详解，第 4 章术语；验证清单、论据说明与完整任务示例见附录 A、B、C，完整来源见 reference.md。

---

1. 七条原则¶

七条原则按规范对象切分设计责任：每条原则管辖一类对象上的义务，每条规则按其义务的直接规范对象归属唯一原则。对象不同，原则就不会互相替代——这是切分的依据，也是检验切分的方式。

同一个场景可以触及多条原则——用户在客厅打断了正在播报余额的音箱，同时涉及打断的即刻生效与后果（V2-1、V2-2）、外放输出的呈现级别（V6-4）和被打断内容的补达（V4-1）——这不是分类错误：三条规则约束的是三个不同规范对象上的义务，一个是话轮控制权，一个是物理空间，一个是听者的信息可及性。互斥与穷尽是这套切分接受检验的主张，不是宣布即成立的事实：规则增删或归属存疑时，按附录 A 的分类检验验证。检验不过，修改的是原则的切分。

本切分中最需要持续检验的三处边界，在此明示：

• V1 与 V6——旁人的话该不该被当成指令是指令来源的问题（V1-6），旁人的声音能不能被留存和使用是隐私与同意的问题（V6-3）。同一段音频，两条规则约束的是两件事。
• V3 与 V4——说得短管的是输出本身（长度、结构、密度），记不住有救管的是听者事后的补救能力（重复、回退、延时）。前者做到位可以减少后者的使用频率，但不能替代它。
• V2 与 V7——打断是在语音通道内收回话轮，退路是离开语音通道。用户喊"停"和用户改用打字，是两件事。

这三处若在实践中反复出现归属争议，应当调整原则的切分而不是增设中间层。

原则用于理解规则与裁决归属，本身不作为单独的判定条目。当原则与具体条款的解读出现冲突时，以适用条款为准，并记录需要澄清的歧义。

规则归属唯一，不等于机制不能复用。同一计时设施可支撑端点判定（V2-3）与应答等待（V4-3），但两者的起算事件、重置与到期动作必须分开；一次"可见级别解析"既服务于外放输出（V6-4）也服务于转屏内容的裁决（V7-1）。同一机制一物多用是常态，写在哪条取决于义务的直接规范对象。

2. 规则的读法¶

2.1 每条规则的结构¶

一句话概括各部分的效力：规则正文规定要求；适用与边界条件共同限定要求的适用范围；设计应用、验证示例、反例与依据参考不另行增加义务。

规则写行为性质、不写实现方式：用户开口后系统在可感知的时间内停声是产品行为，用 VAD 加能量阈值还是端到端模型判定是工程方案——两者必须对得上，但不是同一份交付物。

本规范不规定跨产品通用的性能阈值。首音时延、静音阈值、单话轮长度、并列项上限这类参数，规则只要求"有明确定义、有依据、可验证"。这不是回避：这些数值随语言、任务类型、用户群体与部署环境差异极大，引用资料不足以支持跨场景的统一性能阈值。工程参数记录在 reference.md 第四节，作为实现映射参照而非合规依据。

2.2 约束词¶

规则正文使用三级约束词：

• 必须：不满足即不符合本规范。缺了它，某条对用户的承诺会在可预见的情境下失效——这是标「必须」的唯一依据。
• 禁止：与「必须」同等强度的反向表述，指明不得出现的行为；正文中的「不得」与「禁止」等价。
• 应当：默认遵循；确有理由偏离时，记录理由与替代做法，并接受同样的验证。偏离不需要审批，但需要留痕。「不应当」是「应当」的反向表述。

合规判定以正文中的独立义务子句为单位：无约束词的陈述句承接所在规则标题的强度；显式标注约束词的子句按其自身强度判定——【应当】规则内的「禁止／不得」子句仍是硬约束（V2-4、V3-2、V4-4、V5-5、V7-4 含此类子句），规则标题与速查表的强度标注不替代子句约束力。正文中的「不能」仅用于能力或事实陈述，不表达义务。

强度表示约束力，不表示重要性。

2.3 反例的两侧¶

反例分两侧："做不到"是漏掉这条要求，"做过头"是为了满足它而堆确认、复述、提示音和兜底话术。两侧都算没做对——语音产品被做坏的方式高度集中在后者：每句话都复述一遍让用户确认、每个回答前先念一段能力声明与免责、为了不误打断把响应等到用户以为断线、为了"自然"往每句话里塞"嗯""好的呢""我明白您的心情"。语音里的冗余比屏幕上的冗余贵得多，因为它占用的是时间而不是空间。

2.4 规则速查：47 条¶

下表是全部规则的一句话记忆版，点击规则名可跳到第 3 章的完整正文。速查不替代各条的适用条件与完整要求；个别【应当】规则内含禁止级子句（V2-4、V3-2、V4-4、V5-5、V7-4），判定以正文为准（见 2.2）。

V1 听得准

V2 轮次有主

V3 说得短

V4 记不住有救

V5 声音有主

V6 在场可知

V7 有退路

2.5 设计交付与运行事实¶

评审每条适用规则时都回答三问：产品选择什么行为，工程用什么事实证明它发生，用户怎样知道并纠正它。下面的表是设计与验证方法，不新增规则或要求独立交付物。

这些维度可以并行：系统播放时仍可接收打断，任务处理时麦克风也可能关闭。不能用一个互斥的“听／想／说”动画代替所有状态；用波形表达正在收音时，波形必须来自实际输入，不能用循环动画伪造采集。音频能量只证明输入活动，不证明来源、意思或授权。

控制与数据事件需关联同一任务、会话、话轮或输出片段，并记录发生时间与事实来源。迟到事件不能把新状态覆盖回旧状态：退出后的识别结果不得启动动作，停止后的旧音频不得重新入队，过期确认不得匹配到新问题。是否使用事件序号、取消标记或其他机制由工程决定，验证的是这些行为结果。

2.6 从任务到方案¶

先选择两三项真实任务，写清完成条件、关键值与不可逆后果，再比较按住说话、点击提交和自动端点的收益。用目标用户的实际停顿、环境噪声与可访问控制成本选择方案；不因“更像人”默认开启连续采集。

为每项任务画出开始、纠正、确认、执行、恢复与退出路径。对每个关键节点记录默认行为、用户控制、失败出口和需要的事实；有参数取舍时再使用 Design Token。正常路径与异常路径共用同一任务状态。附录 C 给出一条完整示例。

3. 规则详解¶

本章按七条原则展开全部 47 条规则。每条的结构与各部分的约束力见 2.1；其中的设计应用、验证示例与反例只是帮助落地的说明，不指定唯一组件，也不要求新增独立交付文档。

3.1 V1 听得准¶

语音产品最常见的第一层错误，是把语音识别的输出当成用户说的话。它不是——它是一个可能出错的假设，其质量需按口音、噪声、专有名词和非典型语音分别验证。本原则管辖这个假设如何成立、如何被核对、误了怎么办，以及"听到的声音"与"用户的指令"之间的分界。

V1-1识别结果是假设不是事实必须¶

一句话：识别可能出错；没有可靠置信，也不能靠猜测执行不可逆动作。

适用任何以语音作为输入的产品。

规则产品必须把语音识别结果作为带不确定性的假设处理，而不是确定的用户输入。系统必须能够区分"高置信理解"与"低置信理解"，并以该区分作为后续处理的输入。低置信理解禁止直接触发不可逆动作（对外发送、支付、删除、公开发布、权限变更等，按产品实际后果界定，不能以识别准确率替代后果判断）；此类情况下必须转为确认、澄清或改由其他模态完成。识别置信不可得时，按低置信处理。

用于区分置信档位的信号必须经过目标语言、用户群体与环境下的实测校准；禁止把模型自述“我听清了”、语句流畅度或总体成功率当作单次输入已正确理解的证据。流式转写的中间结果必须作为可修订内容处理，修订影响关键对象或后果时，先前基于旧内容的确认必须失效并重新核对。

边界条件本条不要求向用户展示置信度数值，也不要求每一次低置信都打断用户——V1-2 规定确认强度如何随后果变化，V1-3 规定连续失败时如何换策略。本条要求内部明确记录不确定性依据；无可靠依据时保留“未知”，不能伪造一个置信分数。

设计应用把"置信度"设计成一条贯穿链路的输入，而不是识别模块内部的调试信息。端到端语音模型不单独输出转写置信时，保留“置信未知”并按后果进入核对。重述率、澄清率和打断率用于评估系统质量，不能直接当作当前话语识别正确的概率。

验证示例

• 用户侧：在有背景噪声的环境中说一句会触发不可逆动作的指令，观察系统是直接执行还是转为确认。
• 实现侧：验证低置信路径确实存在且被触发，而不是阈值形同虚设；验证置信不可得时走的是保守分支。

反例做不到——嘈杂环境里听成"转给张伟"就直接转账；做过头——每一句都要求用户复述确认，包括"把灯关了"这种一秒可撤销的操作。

V1-2确认强度与后果相称必须¶

一句话：按后果可不可逆决定确认到什么程度，不是每句都复述一遍。

适用语音输入会触发状态改变或外部动作的产品。

规则产品必须为语音输入定义确认策略，且确认强度由后果的可逆性与影响范围决定，而不是由识别置信单独决定。策略至少区分三档：不确认（后果可立即撤销且影响仅限本次会话）、隐式确认（在下一句回应中带出已理解的关键要素，并在既有授权范围内继续）、显式确认（停下来等待用户明确应答）。不可逆动作必须至少采用显式确认，且确认的对象是行动与后果本身，不是"你刚才说的是不是这句话"。确认所依据的内容必须与实际将要执行的内容一致。

隐式确认不是授权方式，沉默不产生新的许可。显式应答必须关联本次已告知的具体行动与内容快照；播报尚未覆盖必要对象及后果时的一声“嗯”，不得直接作为该行动的同意。用户在同一句话中自我修正（“不是周四，是周五”）时，必须处理完整修正再核对，不得抓到前半句就提交。确认必须绑定具体对象、关键值、后果与有效条件；其中任一项改变后旧确认失效。含糊应答、背景声或已过期确认不得授权新的动作。

边界条件本条不要求为每一档确认设计独立话术模板；也不禁止在用户明确表达偏好后在低后果动作上关闭隐式确认。

设计应用隐式确认是语音里最省时间的一档，应当优先用它承担中间环节——"好，寄到公司地址，周三送到"既是确认也是进度。显式确认留给钱、对外、删除和权限。

验证示例

• 用户侧：让用户在显式确认点复述自己正在批准什么，检验其表述与系统即将执行的一致。
• 实现侧：遍历所有会产生外部影响的动作，检查其确认档位与后果分级的对应关系是否有缺口。

反例做不到——"删除全部录音"识别后直接执行；做过头——查询天气也要"您是说要查询今天的天气，对吗？"

V1-3听不懂要换策略不是重复问必须¶

一句话：连着听不懂就换问法、换模态、转人工，不把同一句提示念第三遍。

适用存在识别失败、无匹配意图或反复澄清的语音流程。

规则产品必须定义识别失败或无法理解时的升级序列，并规定每一级及当前问题的总最大尝试次数；达到次数上限必须进入下一级，禁止以相同措辞重复同一提示超过声明的次数，也禁止在没有新信息的情况下无限循环澄清。升级序列必须至少包含一次换措辞或缩小问题范围，并以换模态或转交人处理为终点（终点的可得性见 V7-2、V7-5）。每一次升级必须保留用户此前已提供的信息，不得因升级而清空进度。必须区分未收到输入、听到但无法识别、识别出文字但无法理解、以及权限或连接故障；不得在麦克风不可用时要求用户“再说一遍”。等待开口按 V4-3 处理，不消耗识别失败次数。计数以当前未解决问题为范围，成功解决、用户明确换任务或退出才重置；换措辞、模型或输入通道本身不重置总失败预算；达到总上限直接进入可用终点。用户主动请求换模态或转人工时立即处理，不必走完升级序列。

边界条件本条不要求所有产品都提供人工坐席——不代表机构办理事务的产品（如设备控制）可以把"换模态"或"明确告知无法完成并给出可行替代"作为终点，但必须显式声明这一终点，不得以静默失败代替。

设计应用例如在第二次失败时换问法，之后换模态或转人工；具体次数由场景验证决定。比较缩小范围与重复播报的完成率和用户负担，再确定升级策略。

验证示例

• 用户侧：连续给出无法识别的输入，记录到达可用出路所需的轮次，以及此前提供的信息是否还在。
• 实现侧：检查升级计数器的重置条件；验证达到上限后确实换级而不是回到第一级。

反例做不到——"抱歉，我没有听清，请再说一遍"循环七次直至用户挂断；做过头——第一次没听清就立刻转人工，把可自助的事全部推给坐席。

依据与参考W3C COGA 语音模块明确指出"简单的错误恢复应转向人工，而不是制造令人沮丧的循环"（见 reference.md 第二节）。

V1-4非典型语音不被排除必须¶

一句话：口音、构音障碍、儿童与老年语音听不出来，是系统的问题不是用户的。

适用面向一般公众的语音产品；企业内部产品在用户群体已知的前提下按实际构成解析。

规则产品必须为识别质量系统性偏低的用户群体提供不依赖识别质量的完成路径（按键输入、文字输入或可访问的人工渠道之一以上），且该路径的可达性不得低于语音路径。禁止因识别置信持续偏低而缩减该用户可用的功能范围，也禁止把识别失败表述为用户的表达问题。产品必须声明其识别能力覆盖的语言与口音范围——单语言产品同样需要声明，"只支持一种语言"本身就是需要写明的覆盖范围；范围外的用户必须在进入语音流程前或首次失败时即可得到替代路径，而不是在多轮失败之后。

边界条件本条不要求产品宣称已经对所有语言与口音达到同等识别率；它要求的是识别率的差异不转化为可用功能的差异。

设计应用把替代路径做成入口而不是兜底：在流程开始处就能选择"改用按键"，而不是失败三次后才出现。语音生物特征相关的能力（V6-6）尤其不能成为唯一门槛。

验证示例

• 用户侧：招募带明显口音、构音障碍或非母语的参与者完成同一任务，比较完成率与到达替代路径的成本。
• 实现侧：验证替代路径不需要先经历失败即可进入；验证功能范围不随置信度变化。

反例做不到——系统听不懂就反复要求"请说标准普通话"，无其他出路；做过头——一检测到口音就直接跳过语音强制改为按键，剥夺用户本可以完成的语音交互。

依据与参考W3C NAUR 要求为非典型语音、聋人与言语障碍用户提供非语音替代（见 reference.md 第二节）。覆盖范围和效果仍须通过目标用户完成任务的证据判断。

V1-5关键内容逐字保真必须¶

一句话：人名、编号、金额不得被顺滑成更常见的文字。

适用语音输入包含专有名词、标识符、数值或需要精确记录内容的产品。

规则产品必须定义逐字保真域——人名、地名、机构名、订单号与各类编号、金额、日期时间、地址等，其实际含义在从识别到执行的全链路中不得被语言模型或后处理静默改写、纠正或“顺滑”。原始表达、规范化值与已确认值必须可区分；格式规范化只能采用已声明、语义不变的规则，存在歧义时先核对。落在保真域内且置信不足的内容，必须转入核对或拼读流程，禁止以更常见的同音词静默替换。产品必须提供逐字核对手段（逐字重复、拼读、分组播报之一以上），其可得性见 V3-5。

边界条件订单号、日期等业务值与密码、支付口令等认证秘密不同。认证秘密不得被要求进入普通对话、转写或模型上下文；须通过可访问的专用认证入口处理，语音流程只接收认证结果。

本条不禁止在保真域外对口语进行整理（去除填充词、断句、书面化）；也不禁止在明确告知的前提下提供纠正建议——建议与替换的区别在于用户是否知情并可拒绝。

设计应用保真域应当在意图与槽位设计阶段就标注出来，而不是在输出前才判断。生成式后处理链路尤其需要显式围栏：模型倾向于把不常见的名字改成常见的。

验证示例

• 用户侧：让用户说出不常见的人名与一串编号，核对系统最终记录的内容与用户所说是否逐字一致。
• 实现侧：对保真域字段做端到端比对，验证不存在静默替换；检查生成式环节是否有围栏。

反例做不到——用户说的收款人"李昱"被改成"李玉"，转账照常进行；做过头——把整段自由描述都当作保真域逐字复述给用户确认。

V1-6听见的不等于用户说的必须¶

一句话：电视声、旁人对话和系统自己的回声，都不是指令来源。

适用在开放声学环境中运行的语音产品，包括音箱、车载、可穿戴与免提通话场景。

规则产品必须区分采集到的音频与来自当前用户的指令。系统自身的语音输出、环境中的媒体播放声、以及未被确认为当前对话方的他人语音，禁止作为指令来源触发动作；来源无法判定时按非指令处理。音频内容中出现的指令性文本（广播、录音、他人朗读的内容）不因为被听见而获得指令权威；听到的内容不能扩大操作权限，也不得替用户授权。

边界条件本条不要求产品具备说话人识别能力；不具备时，可用显式触发与连续对话窗口界定候选输入范围，但窗口内的声音不因此都成为本人指令；来源仍有歧义时，必须通过定向输入或可访问的非语音方式核对，边界必须明确（见 V2-7）。本条也不禁止用户显式授权多人共同参与同一次对话。用户主动通过辅助沟通设备（AAC）发出的合成语音可以作为其表达；须按输入归属核对，不能仅因声音是合成的就排除。背景媒体与用户有意使用的辅助输入必须区分。

设计应用把"回声消除"从纯音频问题上升为设计问题——系统被自己的播报唤醒并执行动作，是可复现的产品事故而不是偶发噪声。对来源不明的高后果指令，宁可要求一次显式确认。

验证示例

• 用户侧：在电视播放含唤醒词与指令的内容时，观察设备是否被触发并执行。
• 实现侧：构造包含指令性语句的音频（广播、他人朗读、系统自身播报回灌），验证其被作为数据处理而非指令；验证来源不明时走保守分支。

反例做不到——电视广告里念出唤醒词加下单指令，音箱照单全收；做过头——为杜绝误触发要求每次指令前都先做一次声纹验证，把日常控制变成安检。

V1-7语言切换不改写用户的意思必须¶

一句话：语言切换不改写用户的意思。

适用适用于多语言、方言或中外文混说用户的产品。

规则产品必须分别声明识别、端点判定与合成输出所覆盖的语言及地区，不得把识别支持某种语言推定为整条语音链路都支持。用户明确选择的语言必须可修改；自动识别与其冲突时，必须保留用户选择并提供纠正入口。中途切换语言不得清空已收集信息或改变关键值，无法可靠处理时按 V1-3 提供出路。

边界条件本条不要求支持所有语言，也不要求自动检测语言；是否支持句内混说必须明确并实测。

设计应用中文任务可覆盖“把 meeting 改到周五”、多音姓名、汉字与字母编号等输入；“李昱，日字旁的昱”需核对最终汉字，不能只读同音字。数字本地化按 V3-5 处理。

验证示例

• 用户侧：同一任务中切换中文、英文及声明支持的混说，核对信息、日期和对象是否保持一致。
• 实现侧：按语言分别检查 ASR、端点与 TTS 能力和回退路径，不以单一总体准确率替代。

反例做不到——只因为用户说了一个英文产品名，就把整个流程切成英文并重问地址；做过头——每轮都询问用户要用什么语言。

依据与参考语言覆盖的需求见 reference.md 第二节；具体中文样例为本规范的设计推导，须由目标任务实测验证。

3.2 V2 轮次有主¶

语音通常围绕一个主要话轮展开，也可能出现附和、重叠发言或全双工交互。谁在说话、什么时候可以插话、什么时候算说完、说完之后等多久——这些在面对面交流里由无数细微信号协商完成的事，在产品里必须被显式设计。做不好的两个方向同样常见：系统霸着话头说完为止，或者用户还在思考就被抢答。本原则管辖话轮控制权本身。

V2-1打断随时可用且即刻生效必须¶

一句话：用户发起打断时及时停声，不强迫用户等这句话说完。

适用任何会主动播放语音输出的产品。

规则在已启用语音输入的交互中，用户必须能够在系统语音输出的任意时刻通过说话将其打断，产品必须声明从检测到用户开口到系统实际停止发声的时间上限，并使其在真实环境下可达。除法定或安全必需、且必须完整播出的片段外，禁止存在用户无法打断的语音输出；存在此类片段时，其范围、原因与时长必须事先声明，且片段结束后立即恢复可打断。在语音之外，产品还必须提供至少一种不依赖说话的停止方式（按键、触屏或手势），供无法及时出声或身处不便出声环境的用户使用。

语音输入已由用户关闭、麦克风权限被撤销，或使用按键开启输入的模式时，必须保留立即可用的非语音停止入口，并说明如何重新进入语音输入；禁止为满足语音打断而擅自重新打开麦克风。停声验证必须覆盖播放端的已缓冲音频，不能只验证服务端停止生成；同时记录用户实际开口至检测到开口的耗时，避免用延迟检测掩盖实际停声过慢。

边界条件要求完成告知不等于要求强制听完。不可语音打断的例外必须有明确的领域依据，只覆盖必要片段；停止播放的非语音入口、退出与撤销采集权限仍可用，未完成告知按实际状态补达，不能以例外阻止退出。

本条不要求把一切非语音声响（提示音、通话中的对方语音）都设为可打断；它约束的是产品自身的语音输出。本条也不规定打断的判定灵敏度——那是 V2-4 的范围。

设计应用把打断做成基础控制：播放端清理缓冲，任务端单独处理取消，并分别给出回执。只停止模型生成，不足以兑现停声承诺。

验证示例

• 用户侧：在系统播报长段内容时打断，测量实际停声时间与用户的主观感受。
• 实现侧：在弱网、高负载与长文本合成条件下重复测量停声时延，验证仍在承诺上限内。

反例做不到——用户喊了三次"停"，系统把整段两分钟的条款念完；做过头——把打断阈值调到极低，用户一咳嗽播报就中断，反复重来。

V2-2打断的后果明确必须¶

一句话：没播出去的不算已告知，已经做了的不因为闭嘴而消失。

适用语音输出承载告知义务，或语音播报与实际动作并行的产品。

规则被打断而未播出的内容禁止计为已送达用户；产品必须能够区分"已播出"与"已生成但未播出"，并据此决定该内容是否需要补达（补达路径见 V4-1、V7-4）。打断只终止语音输出，不自动撤销已经执行的动作——已产生外部影响的动作必须在打断后的首次回应中被如实说明，撤销前必须核对实际结果与可撤销范围；无法撤销时说明已发生的后果和可行的补救。产品必须区分“停止说话”与“停止任务”这两种意图。用户在行动推进中说“停”等范围不明的控制语时，必须先停声并暂停尚未提交的受影响动作，再澄清停止范围；禁止一边追问一边继续提交。明确只停止朗读时按原有效授权处理任务，明确取消时进入任务停止路径。

后续对话上下文必须同步实际播放进度，禁止把已生成、已发送或进入播放队列的内容当作用户已听到的共同信息。未播放部分可为重复与补达暂存，但必须与“已播放”区分。播放回执最多证明设备播放了某段内容，不证明用户听懂或同意；播放位置不可得时必须保留送达未知，不能推定完整送达。控制、播放与识别事件必须关联具体话轮或输出片段；停止或退出后迟到的转写、生成结果和旧播放队列不得重启已停止的输出或推进任务。

边界条件本条不要求为每一次打断都生成一段"刚才没说完的是什么"的摘要；补达义务只覆盖必要告知与用户主动索取的内容。

设计应用把"停"和"别做了"设计成两件事并在回执中明确区分——"好，我不念了，但转账已经发出去了"是一句合格的回应；"好的"不是。

验证示例

• 用户侧：在系统播报"正在为您提交"的同时打断，检验用户能否从后续回应中判断提交是否已经发生。
• 实现侧：验证未播出内容不被记为已告知；验证打断事件与动作执行状态各自独立记录。

反例做不到——打断后系统安静了，用户以为取消了，订单其实已经提交；做过头——每次打断都完整复述"以下内容尚未播报"清单。

V2-3说完的判定有依据有上限必须¶

一句话：声明凭什么判定用户说完了，并且等待有尽头。

适用需要判断用户话轮结束以决定何时响应的产品。

规则产品必须声明话轮结束的判定方式（静音时长、语义完整度、专用端点模型或其组合）及其可解析的参数来源，并必须设定端点判定的最长等待上限。该时限从检测到语音活动暂停时起算，用户继续说话后重置；达到上限时，系统必须给出可继续输入的询问或状态反馈，禁止无限期悬置判定，也禁止在用户仍持续表达时因该计时器到期而抢话。达到等待上限本身不构成"用户已说完"的证据，禁止据此直接执行不可逆动作；此类情况必须转为确认或询问。判定为结束但用户实际未说完时，用户必须能够续说而不必从头重述，已说出的部分不得被丢弃。

等待用户开始回答的时限按 V4-3 处理，会话空闲收尾按 V7-6 处理，两者不得与端点时限共用含混的“超时”定义。按键开始／结束或按住说话等显式提交模式可以不用自动端点判定，但必须声明开始、提交与取消的区别，并提供不依赖持续按压的可访问方式。

边界条件本条不规定具体阈值（见 2.1 的数值说明），也不预设不同场景的阈值之间存在固定大小关系——听写是否应当比问答等更久，由目标任务与目标用户的停顿分布实测决定。本条不要求所有场景使用同一判定方式，但每一种都必须有声明。采用会输出分数的端点机制时，必须同时声明该分数的含义（高分表示"已说完"还是"尚未说完"）、比较方向与所属模型与分数定义；机制不暴露分数的，记为不适用并按其原生参数声明，不得补造一个概率值。

设计应用单纯缩短静音阈值可能增加抢话，拉长则可能增加等待；语义端点或显式提交是可比较的方案。地址、描述、听写等场景应单独测试停顿容忍度，并让用户知道可以续说。

验证示例

• 用户侧：让用户说一句中间带思考停顿的长指令，观察是否被截断；截断后观察续说能否接上。
• 实现侧：验证等待上限确实生效且触发保守分支；验证续说时前半句被保留。
• 实现侧：对输出分数的端点机制，验证比较方向与分数含义一致——把"高分＝已说完"的模型配成"高分＝未说完"应当被检出；引擎或模型升级改变分数含义时，旧阈值与旧验证证据一并失效。

反例做不到——用户报地址报到一半停顿两秒，系统抢答"好的，已为您下单"；做过头——为了不打断把等待拉到六秒，每一轮都像断线。

依据与参考行业现行参数与端点模型的实现形态见 reference.md 第四节，作为实现映射参照而非合规依据。

V2-4抢话与冷场都算失败应当¶

一句话：换个气就被打断，和说完了等五秒没反应，是同一个问题的两侧。

适用以连续对话为主要形态的语音产品。

规则产品应当把"系统在用户未说完时插话"与"用户说完后长时间无响应"作为同一组质量指标的两端进行度量与调优，并分别设定可接受范围。产品应当结合上下文区分附和、思考停顿、纠正与打断；“嗯”“好”等表述不得仅凭词表在所有情境中一律忽略，同一表述可能是对当前问题的回答。附和词表如被使用，应当按语言和情境配置，不得屏蔽明确的停止、否定与纠正。度量应当基于真实使用数据而非仅基于实验室录音。

产品应当声明误打断后的恢复方式。自动续播前必须确认不存在待处理的停止、纠正或新输入；转写为空不等于没有有效表达，言语障碍、短词或掉包造成的漏识不得直接归为噪声。恢复应当从实际停播位置或最近完整语义边界继续，不重启整个任务、不重复执行。

边界条件本条不要求达到某个具体的抢话率或响应时延数值；它要求的是这两个方向被同时度量，而不是只优化其中一个。

设计应用调低等待门槛可能减少延迟却增加抢话；调高可能产生相反影响。把两项放在一起观察，同时检查误打断后的恢复，不能只根据其中一个指标决定效果。

验证示例

• 用户侧：在真实环境中记录一批完整对话，标注抢话与冷场事件，分别统计发生率。
• 实现侧：验证附和词集合确实生效；验证参数调整后两项指标的变化被同时观察。

反例做不到——上线后只跟踪平均响应时延，抢话事故靠用户投诉发现；做过头——为压低抢话率把所有场景的等待统一拉长，牺牲了短指令的流畅度。

V2-5现在轮到谁说是可知的必须¶

一句话：让用户随时知道系统在听、在想、还是在说。

适用任何语音交互产品。

规则产品必须让用户能够随时判断系统当前处于在听、在处理、在说、已结束等状态及其合法组合，指示方式至少一种不依赖视觉（提示音、语音、灯效之外的触觉，或语音本身的节奏）。状态指示必须反映真实的系统状态，禁止在未实际采集时呈现"在听"，也禁止在无实际处理时呈现"在处理"。在纯语音、驾驶、视障使用等无法依赖视觉的场景中，非视觉指示是唯一手段而非补充。

全双工中“在说”可以同时保持采集，后台任务也可以在听用户输入时继续处理；状态呈现必须区分输入接收、任务处理与输出播放，不得强行用互斥四态掩盖并行事实。麦克风静音、权限不可用或连接异常导致无法收音时，必须呈现该限制而非继续显示“在听”。开始采集必须等待设备成功回执；拒绝授权、硬件占用、设备拔出与系统来电中断不得被显示为用户沉默。恢复连接不自动重新取得已撤销的采集许可，未完成输入须保留已可靠接收部分并说明缺口，不能默认为完整指令。

边界条件本条不要求四种状态各有一个独立的提示音；用可区分的方式表达即可。也不要求持续发声——静默本身在有明确约定时可以是一种状态表达。

设计应用起音与收音提示音可以界定交互区间，但仍需验证其可辨识性；不能依赖视觉的场景须提供其他可用反馈。

验证示例

• 用户侧：蒙眼或在驾驶模拟中完成一次对话，让用户在多个时刻报告"现在轮到谁"，统计正确率。
• 实现侧：验证状态指示由真实运行事实驱动，而非按预估时长播放。

反例做不到——音箱静默三秒，用户不知道是在想还是没听见，于是重说一遍造成双重输入；做过头——每次状态切换都播一段语音说明"我正在思考"。

V2-6长时处理不静默必须¶

一句话：实质回答预计不能及时开始时，在首反馈预算内说明真实等待，并允许取消。

适用存在需要检索、调用工具或多步执行从而超出常规响应时延的语音产品。

规则产品必须声明首音时延的承诺值；实质回应不能及时开始时，必须在该上限内提供真实的处理信号（非语言提示音、简短填充语或进度播报）。超过上限仍无反馈时记录为超限并给出降级或退出手段，不能以稍后补播提示音取消这次超限记录。处理中的表述禁止被表述为动作已完成或已执行，也禁止使用与实际运行状态不符的进度描述。处理超出声明时长时，用户必须能够取消，取消必须有回执并说明已经产生的影响。

时延必须区分首个反馈与实质回答开始，分别声明起止事件、测量位置与超限处置。提示音、填充语不得计为实质回答。测试事件至少区分用户实际结束表达、端点成立、首个反馈开始播放与实质回答开始播放；端点判定的等待属于用户感受到的等待，不得从统计中扣除。某一事件无法取得时标为缺测，不填零，也不改用生成完成时刻代替。验证必须覆盖端点等待、处理、传输和播放缓冲，记录典型与尾部时延、超限比例及测试条件；不能只用服务端首包时间或平均值代表用户等待。取消入口必须在处理期间持续可用，不必等到超限后才出现。

边界条件本条不要求为所有等待都播报进度；要求预计不能及时开始实质回答的等待在首反馈预算内被说明；若回答已开始，不另播冗余提示。达到预算仍无反馈须记录超限，事后补播不使本次测量通过。也不禁止使用填充语——禁止的是内容不实的填充语。

设计应用填充语的内容要么与任务相关且真实（"正在查三家的价格"），要么保持中性；用"好的，马上为您办好了"填充等待是把等待变成虚假回执。

验证示例

• 用户侧：人为拉长后端响应，观察用户在多长时间后开始重复指令或认为断线。
• 实现侧：验证处理中信号由真实运行事实触发；验证取消路径可用且回执如实。

反例做不到——问一句复杂问题，音箱沉默八秒，用户以为没听见又说了一遍，触发两次执行；做过头——每次查询都先播一段"让我想想哦，这个问题很有意思"。

V2-7多人在场时的话轮归属应当¶

一句话：说清正在跟谁对话，别把旁人的半句话接进任务。

适用可能在多人环境中使用的语音产品（家庭音箱、车载、会议、公共场所设备）。

规则多人可能同时在场时，产品应当明确当前对话的归属方，并使该归属对在场的人可知。归属方之外的语音不应当被并入当前任务的输入；确实需要接纳多人输入时，应当由当前归属方或产品显式声明进入多人模式，而不是默认合并。对话归属发生转移（另一位用户接手）时，应当有可感知的标识，且原对话的个性化信息仅在新对话方有权使用时携带，第三方数据处理仍须满足 V6-3，不因为在同一次对话中就自动共享。

边界条件本条不要求产品具备说话人分离或声纹能力；不具备时须说明归属的不确定性；连续对话窗口只限定接收时段，不能证明声音来自同一个人，指令来源仍按 V1-6 裁决。本条也不适用于明确设计为多人共同使用的场景（如会议记录），但那类场景需要另行声明其输入范围。

设计应用车内是最典型的失败场景——副驾的一句闲聊被并进主驾正在进行的导航修改。把"当前对话方"做成可解析的状态，而不是隐含假设。

验证示例

• 用户侧：在一位用户对话过程中让另一人插入一句无关语句，观察其是否进入任务。
• 实现侧：验证归属判定的边界与有效期；验证归属转移时个性化信息不被自动继承。

反例做不到——家庭音箱把孩子随口的一句话加进了家长正在确认的购物清单；做过头——每一轮对话前都要求用户先自报身份。

3.3 V3 说得短¶

屏幕上的信息是并置的，用户可以扫视、跳读、回看；语音里的信息是串行的，用户只能按系统给的顺序、按系统给的速度，听一遍。同样一段内容，放在屏幕上叫"完整"，念出来叫"冗长"。本原则管辖系统语音输出本身的长度、结构与密度——它约束的是说出去的东西，听者事后的补救能力由 V4 管辖。

V3-1单话轮有长度上限必须¶

一句话：定义一次最多说多久，超了要分段，段间能打断。

适用任何会输出语音的产品。

规则产品必须为单次话轮的语音输出定义长度上限（以时长或等效度量表示），并按场景分别声明——查询应答、流程引导、长内容朗读的上限可以不同。超过上限的内容必须分段输出，段与段之间必须存在可被打断与可被中止的间隙，且用户必须能够知道还有后续（"还有三条"或等效表达）。禁止以单个不可分割的长话轮输出可分段的内容。

边界条件本条不适用于用户显式请求的连续朗读（有声内容播放、长文朗读），但那类场景仍受 V2-1 的可打断要求约束，且必须提供暂停与定位手段。

设计应用上限不是文本字数上限，是听觉时长上限——合成语速、停顿与用户所处场景共同决定它。驾驶、运动和居家场景应分别验证注意力负担，不直接复用同一个长度上限。

验证示例

• 用户侧：让用户听完一段达到上限的输出后复述要点，观察记忆保持与不耐感出现的位置。
• 实现侧：遍历各场景的输出路径，验证不存在绕过上限的分支；验证分段间隙确实可打断。

反例做不到——问一句退货政策，系统开始朗读整段条款；做过头——把一句完整的两句话答复硬拆成两个话轮，中间插一句"还要继续听吗"。

V3-2结论先行应当¶

一句话：先回答，再解释；免责声明不放在用户想听的东西前面。

适用语音应答类交互。

规则系统的语音回应应当把用户所问的结论、结果或下一步动作放在最前，理由、来源与补充说明置后。禁止把免责声明、能力说明、品牌用语或寒暄置于用户所问的结论之前——这些内容如确有必要，应当置后或在首次交互时一次性给出（AI 身份披露按 V5-1 处理，属于必须前置的例外）。回应中应当能明确区分"直接回答"与"附加信息"，使用户在听到答案后即可打断而不损失关键内容。应当使用用户熟悉的词，解释必要术语，并支持“说简单点”；简化只能改变表达，不能去掉否定、限制、费用或关键条件。

边界条件本条不适用于结论本身依赖前置条件才成立的情形（如"如果您指的是上周的订单，那么……"）；此时前置条件属于结论的一部分。安全告警与法定必须前置的告知不受本条约束。

设计应用这条规则的经济价值在于配合 V2-1——结论在前，用户听到答案就能打断，从而有机会减少实际交互耗时。结论在后则用户必须听完全部。

验证示例

• 用户侧：统计用户在回应开始后多少秒可以打断而不损失关键信息。
• 实现侧：抽样检查生成式回应的开头，验证前置的不是套话与免责。

反例做不到——"感谢您使用我们的服务。请注意以下信息仅供参考，具体以实际为准。关于您咨询的余额问题……"；做过头——为了简短把必要的限定条件全部删掉，给出一个孤立而误导的结论。

V3-3并列项有上限且可导航必须¶

一句话：一次别念八个选项，给"下一批""再说一遍""第几个"。

适用会以语音输出列表、选项或多个候选结果的产品。

规则产品必须为一次语音输出中的并列项数量设定上限，并使超出部分可分批获取。列表输出必须提供导航手段：至少支持获取下一批、重复当前批，以及按位置或名称选择其中一项。禁止要求用户记住超过上限数量的选项后再作选择，也禁止在未给出总数或范围提示的情况下开始逐项播报。每一项的表述必须能被单独识别与引用，不得只有序号。

边界条件本条不要求所有列表都先播报总数——总数不可知时给出范围或"还有更多"的表达即可。本条也不禁止在有屏场景中同时展示完整列表（见 V3-4 的伴随呈现）。

设计应用语音里的可承载项数低于图形界面的经验值。把"缩小范围"设计成列表过长时的默认动作，而不是继续念下去——"有十七个结果，要不要先按距离筛一下"通常比念前五个更有用。

验证示例

• 用户侧：播报达到上限数量的选项后请用户选择，统计需要重复播报的比例与选错率。
• 实现侧：验证导航指令在列表任意位置均可用；验证每项可被独立引用。

反例做不到——"为您找到以下航班：第一，……第二，……"一口气念完九条，用户什么也没记住；做过头——每念一项就问一次"是这个吗"。

依据与参考W3C COGA 语音模块要求限制菜单选项数量、把列表分块，并按"先说用途再说编号"的顺序表述以降低记忆负担（见 reference.md 第二节）。

V3-4不朗读屏幕文案必须¶

一句话：语音输出是为听重写的，不是把界面文字念出来。

适用同时存在图形界面与语音输出，或复用同一内容源的产品。

规则语音输出必须是面向听觉重写的内容，而不是图形界面文案、结构化标记或开发者输出的直接朗读。禁止默认逐字朗读 Markdown 标记、URL、文件路径、代码、表格结构与括号注释等不适合听觉承载的内容；这类内容必须转写为可听的表述，或通过伴随的可视化通道呈现（见下）。当产品具备可用屏幕时，必须定义哪些内容必须同时可见而不得只靠听：长列表、金额与账号、链接与地址、法律与费用告知至少属于此类。无屏时这类内容的处置见 V7-4。

用户明确请求逐字读取链接、路径、代码或标点，或通过屏幕阅读器核对精确内容时，必须允许按请求读取并提供定位、分组和重复；不得因默认简化而删除用户需要核对的原文。有屏不等于屏幕可访问，伴随呈现不能强迫无法看屏或操作屏幕的用户中途换通道。

边界条件本条不要求语音与屏幕的内容完全一致——两者承载不同的信息密度是正常的；它要求的是不适合听觉的内容不被硬塞进听觉通道。

设计应用把语音输出当作独立的内容层来设计，而不是渲染层的一个变体。生成式回应尤其需要显式约束：模型默认输出的是给屏幕看的格式。

验证示例

• 用户侧：让用户仅通过听觉完成一次含链接或长编号的任务，观察成功率。
• 实现侧：对默认输出做格式扫描，并分别验证用户请求精确朗读时原文可得；最后检查实际音频。

反例做不到——助手念出"井号井号 结果 星号星号 重点 星号星号"；做过头——为了适配听觉把所有数字与专名都省略，让用户听完不知道具体是什么。

V3-5关键值播报可核对必须¶

一句话：金额、编号、时间要分组念，用户能要求逐字重复。

适用语音输出包含金额、账号、编号、日期时间、地址或其他需要精确核对的值的产品。

规则关键值的语音播报必须采用便于核对的形式（分组、停顿、单位显式），且用户必须能够要求对该值进行逐字或分段重复，其可得性不因对话已经进入下一环节而失效。涉及不可逆动作时，被确认的关键值必须以上述形式播报至少一次，禁止仅以概括表述代替（"给张伟转两千"中的收款账号不得只以姓名代替，除非该姓名已可唯一解析且用户可核对到具体对象）。播报的值必须与实际将要执行的值一致。

日期、时间、币种、单位、前导零和小数位必须按当前任务的语言及地区格式保留语义。相对日期参与关键行动时必须解析为明确日期，跨地区时间还须明确时区；同音姓名不得仅靠再次读出同一发音完成消歧。产品必须提供可唯一核对对象的补充信息或非语音核对方式。

边界条件本条不要求所有数值都逐位播报——低后果的数值（气温、步数）按自然表述即可。

设计应用分组方式按内容类型与当地习惯确定：电话号码按号码结构、金额明确币种与小数位、编号按核对任务分段，不把四位一组作为通用要求。把"逐字重复"设计成一个随时可用的指令，而不是某个环节的特有选项。

验证示例

• 用户侧：播报一串编号后让用户复述，统计准确率；在下一环节请求逐字重复，验证仍可用。
• 实现侧：验证播报值与执行值同源；验证重复请求返回的是同一个值而不是重新生成的表述。

反例做不到——"将向尾号一二三四的账户转账两千三百五十元"一口气念完，用户没听清也没法再听一遍；做过头——每一个数字都逐位播报两遍，包括查询类的无后果数值。

V3-6不确定与来源在语音里同样表达必须¶

一句话：屏幕上会标的"依据/推断/未知"，语音里不许吞掉。

适用语音输出包含检索结果、推断结论或存在已知不确定性的内容的产品。

规则在图形界面中会以标记、脚注或视觉层级表达的来源、时效与不确定性，在语音通道中必须以听觉可承载的方式同样表达，禁止因为语音需要简短而省略。至少必须做到：区分"来自可核对来源的内容"与"系统的推断"，并在信息可能已过时时说明其时点。用户必须能够就任一结论追问其依据，且追问的答复不得以概括的可靠性表述（"来自权威渠道"）代替具体来源。

边界条件本条不要求为每一句话附加来源说明——那会摧毁语音的可用性；它要求的是这一区分在需要时可得，且在结论可能被用于决策时主动给出。

设计应用语音里表达不确定性靠措辞而不是符号："查到的是……"与"我估计……"是两种不同的开头。把这两类开头做成受约束的表述集合，而不是交给生成式自由发挥。

验证示例

• 用户侧：给出一个系统只能推断的问题，检验用户听完后能否正确判断这是推断而非查证结果。
• 实现侧：验证推断类回应确实走了不同的表述路径；验证追问返回具体来源。

反例做不到——把模型推测的营业时间用与查证结果完全相同的语气播报；做过头——每句话后面都跟一段"此信息可能不准确，建议您自行核实"。

V3-7听得清的参数由用户可控必须¶

一句话：听得清的参数由用户可控。

适用任何以合成语音承载任务信息的产品。

规则产品必须提供可访问的语速与音量调整方式，并在支持音高调节时提供相应入口；可由系统或辅助技术承担，但在当前使用路径中必须真实可达。“慢一点”“大声一点”等请求必须只改变输出方式，不重启任务或重新执行动作。用户选定的可懂度设置必须延续到同一任务的后续播报，变化受设备能力或安全限制影响时必须说明。产品必须验证关键专名、数字与多音词的实际发音，而不得只检查合成前的文本。

边界条件本条不规定统一语速、音高或声压，也不允许为满足音量请求突破设备安全限制。声线与情感身份仍由 V5 管辖。

设计应用把语速、音量入口放在播放控制附近；电话可使用设备音量键，语速调整需有可用的会话指令或替代路径。

验证示例

• 用户侧：播报中请求放慢并重听编号，再进入下一轮，检查是否仍能听清且设置被沿用。
• 实现侧：验证最终音频的时长、发音与可懂度；引擎不支持某项韵律控制时，不展示无效控件。

反例做不到——按钮显示已放慢，实际音频毫无变化；做过头——每次播报前都要求用户重新选择语速。

依据与参考W3C NAUR，REQ 14、23列出调整语音与正确发音需求；它是用户需求草案。SSML 仅提供一种实现语义，见 reference.md 第四节。

3.4 V4 记不住有救¶

语音交互对听者的工作记忆提出了图形界面不会提出的要求：选项要记住、刚才说的数字要记住、已经回答过什么要记住。这类负担对所有人都存在，对认知障碍、疲劳状态、非母语与分心场景的用户则直接决定任务能否完成。V3 通过减少输出来降低这类负担，本原则管辖负担仍然发生时听者手上有什么补救手段。

V4-1重复始终可用必须¶

一句话："再说一遍"任何时候都有效，而且重复的是刚才那段。

适用任何会输出语音的产品。

规则用户必须能够在任意时刻请求重复系统最近一次的语音输出，在会话有效、内容仍处于已声明可重听范围且输入方式可用时，该能力不得依赖特定环节或唯一措辞；麦克风已关闭时通过非语音入口请求，不得暗中采集。重复的内容必须是上一次实际播出的内容，而不是就同一意图重新生成的另一段表述；被打断而未播出的部分必须可通过继续或重听完整段落获取，不得混称为此前已经播过的内容。产品应当支持对更早内容的重复或摘要（"刚才说的第二个选项是什么"），但至少必须保证对最近一次输出的重复。重复必须可以多次请求，不得在若干次后失效或改为其他行为。

重复与继续必须重新核对当前输出通道的私密性（V6-4）。缓存已过保留期、被用户删除或无法精确重现时，必须如实说明；禁止重新编造一句“刚才说过的话”，也禁止为支持重听而无限保留原始音频。

边界条件本条不要求逐字保存所有历史音频；保留可重现最近输出所需的内容即可。

设计应用这是语音里最基础的一条补救通道，成本极低而缺失代价极高。生成式链路要特别注意：重新调用模型得到的是一段"意思差不多"的新话，对正在核对编号的用户毫无用处。

验证示例

• 用户侧：在播报关键值后请求重复，核对两次内容是否逐字一致；在被打断后请求重复，验证未播出部分可得。
• 实现侧：验证重复读取的是已播出内容的缓存而非重新生成。

反例做不到——用户说"再说一遍"，系统换了一种说法重新解释了一遍，编号还是没听清；做过头——每段输出结束都主动问一次"需要我再说一遍吗"。

依据与参考W3C NAUR 要求系统遵从用户对重复语音输出的请求（见 reference.md 第二节）。

V4-2回退一步不必从头必须¶

一句话：说错一个字不该让用户从第一个问题重来。

适用包含多步语音流程（表单填写、预约、办理、配置）的产品。

规则用户必须能够在多步语音流程中回退到上一步或已完成的指定步骤并修改其输入，禁止只提供"重新开始"作为纠错手段。回退必须保留其他步骤已提供的信息，不得因回退而清空全部进度。修改某一步的输入导致后续步骤失效时，必须告知哪些内容需要重新确认，而不是静默作废。用户必须能够知道当前处于流程的哪一步以及还剩什么。

边界条件本条不要求支持任意跳转到任意步骤；至少支持回退一步并能定位到明确列举的已完成步骤即可。

设计应用把"改一下"设计成随时可用的指令而不是某一步的选项。语音流程中用户想改的往往不是上一步，而是三步前说错的那个日期。

验证示例

• 用户侧：在流程末尾请求修改中途的一项，观察是否需要重新回答全部问题。
• 实现侧：验证回退后其他步骤的数据仍在；验证级联失效的步骤被显式告知。

反例做不到——预约到最后一步说错了日期，系统回到第一步重问姓名；做过头——每一步之后都确认一次"这一步没问题吧，要不要修改"。

依据与参考W3C COGA 语音模块把"出错后能轻松返回而不必从头开始"列为明确需求（见 reference.md 第二节）。

V4-3时限可延长，超时不等于同意必须¶

一句话：不催用户；催了也要能延，而且没回答绝不按同意处理。

适用会等待用户语音应答的产品。

规则产品不应当限制用户作出语音应答的时间；确因业务或技术原因必须设置时限时，必须事先告知该时限、必须提供延长手段（用户请求延长、或系统在检测到用户仍在尝试时自动延长），且该手段本身不得依赖快速反应。超时禁止被作为用户同意、确认或选择默认项的依据；超时后的行为必须限于重述问题、降级到其他模态或保存进度后结束，且已提供的信息必须保留。

边界条件安全相关实时控制可按适用领域要求采用不能延长的时限与后备动作，必须记录具体依据并明确后果；例外只涉及计时和安全行为，不允许把无响应记录为用户同意。会话空闲收尾须停止对应采集，不以“应答不限时”为由无限常听。

设计应用使用辅助沟通设备、构音障碍、老年与非母语用户组织一句应答所需的时间远超默认设定。把"还需要一点时间"做成可识别的表达，而不是靠用户抢在超时前说完。

验证示例

• 用户侧：邀请需要更长应答时间的用户完成同一任务，统计因超时而失败的比例。
• 实现侧：遍历所有超时分支，验证不存在把超时映射为同意或默认值的路径。

反例做不到——"请在五秒内说出您的选择"，超时后系统按默认项继续办理；做过头——取消所有时限，用户离开后会话无限挂起并持续占用采集。

依据与参考W3C NAUR 要求不限制用户的应答时间，确有限制时须提前告知并可调整；COGA 语音模块指出处理速度与言语组织需要显著额外时间（见 reference.md 第二节）。

V4-4一次只问一件事应当¶

一句话：复合问题拆开问，别指望一句话回答三个问题。

适用以语音向用户提问或索取信息的产品。

规则系统在一个话轮中应当只提出一个需要用户回答的问题。禁止在同一话轮中提出两个以上需分别作答的问题而仅接受一次应答——用户只回答其中一个时，未被回答的部分不得被按默认值填充，必须重新单独提出。需要一次性收集多项信息时，应当允许用户自然地一次说完，但产品应当按项核对而不是整体接受或整体拒绝。

边界条件本条不禁止用户主动一次提供多项信息；它约束的是系统提问的方式。也不适用于确认类话轮（复述多项内容请用户确认整体正确性）。

设计应用当复合问题频繁造成遗漏时，可以将姓名、电话、时间分别收集，并比较完成率与总轮次；用户主动一次说全时仍应接纳，避免为分步而重复问。

验证示例

• 用户侧：提出一个含三项的复合问题，统计用户完整回答的比例与遗漏项的处理方式。
• 实现侧：验证未回答项不被静默填充默认值。

反例做不到——"请告诉我您的姓名、联系电话和希望的时间"，用户只说了名字，系统按今天下午下单；做过头——把本可以一次说完的地址拆成省、市、区、街道四个话轮。

依据与参考W3C COGA 语音模块要求把信息分块、每个列表项一个概念（见 reference.md 第二节）。

V4-5已说过的不再问一遍必须¶

一句话：用户交代过的信息，换个环节不必重说。

适用跨环节、跨话轮或跨会话延续的语音流程。

规则用户在本次任务中已经提供且仍然有效的信息，禁止在同一任务内再次索取，除非需要核对其正确性且该核对的必要性可以说明。跨会话复用此前提供的信息时，必须让用户知道系统正在沿用什么，并且能够更正；必须保留信息来源、适用任务与有效条件；过期或冲突的信息先核对，长期个性化信息须可查看、更正和删除。历史偏好禁止覆盖用户在本次对话中的明确表述。

边界条件本条不禁止出于安全目的的重新验证（身份、支付授权），但重新验证必须说明原因。

设计应用语音里重复索取的代价远高于表单——用户必须重新组织并说出全部内容。转人工与转模态时的信息传递尤其容易断裂，那是这条规则最常失效的地方（与 V7-2、V7-3 一并检验）。

验证示例

• 用户侧：在流程中途转人工或转屏，观察此前提供的信息是否需要重说。
• 实现侧：验证任务级信息在环节切换时被携带；验证历史偏好不覆盖本次明确表述。

反例做不到——用户对语音助手报了三遍订单号，转到人工后又被要求报一遍；做过头——把两年前一次性的临时地址当作长期默认并直接沿用。

V4-6帮助与"我能说什么"随时可得必须¶

一句话：用户不知道能说什么的时候，有地方问。

适用任何语音交互产品。

规则用户必须能够在任意时刻获知当前可以说什么或可以做什么，该能力不依赖特定环节。产品在提问时应当采用开放式或给出示例的方式建立共同基础，而不是要求用户猜测可接受的措辞；禁止在用户表述不被接受时仅返回失败而不给出可用表述的线索。帮助内容必须与当前所处的环节相关，不得只提供一份与情境无关的通用能力清单。开始使用时须能获知可办理事项、能力限制和退出方式；帮助按当前任务给出，不用长篇能力清单占满每个话轮。

边界条件本条不要求每个话轮都主动播报可用指令；要求的是用户索取时可得，以及失败时给出线索。

设计应用给示例比给规则有效——"比如说'改到下周三下午'"胜过"您可以修改预约时间"。示例应当来自该环节的真实可用表述。

验证示例

• 用户侧：在流程中途请求帮助，检验返回内容是否针对当前环节；给出不被接受的表述，检验是否获得可用线索。
• 实现侧：验证帮助入口在所有环节可用；验证帮助内容随环节解析。

反例做不到——"抱歉，我不能帮您处理这个"，没有任何关于能处理什么的线索；做过头——每次进入新环节都完整播报一遍可用指令清单。

3.5 V5 声音有主¶

合成语音已经越过了"听得出是机器"的阶段。这带来一个图形界面没有的问题：声音本身在传递身份信息——是不是人、是不是某个特定的人、是不是真的在共情。这些信息在用户还没听清内容之前就已经生效了。本原则管辖合成声音所承载的身份与情感，它同时是本规范中受法定义务约束最直接的一组规则。

V5-1AI 身份首次交互即披露必须¶

一句话：AI 在回应时就说清这是 AI，用用户在用的那条通道说；用了合成音不等于对方是 AI。

适用AI 实际承担对话回应的产品，尤其是外呼、接听、客服与代表机构与用户沟通的场景。判据是"谁在作出回应"，不是"声音是否由合成产生"：真人坐席借助 TTS、用户使用 AAC 以个人音色表达、单纯朗读由人撰写的固定内容，均不因使用了合成语音而落入本条的"AI 对话"范围；这类情形按本条末段如实说明。合成音频本身的标识义务另由 V5-2 承担。

规则用户必须在首次交互时即得知正在与 AI 系统对话，披露必须通过用户当前实际使用的、可访问的输出通道给出：启用语音播报且用户依赖听觉时即为可听的表述，禁止仅以视觉标识、条款说明或事后告知代替；用户已选择文字输出或使用辅助技术时，披露随该通道提供，禁止为完成披露而强行开启声音输出（承接 V7-7 的输入输出分别选择）。披露不得因为合成语音自然度提高或对话简短而省略。已完成披露且身份连续可知的同一对话无需逐轮重播；新外呼、对话方变更或身份连续性丢失时重新披露。用户在对话中询问对方是否为人时，必须得到如实回答，禁止回避、含糊或否认。产品还必须使该披露在对话中可被再次获取（用户随时可以问）。真人借助合成方式表达时，必须如实说明真人参与与合成方式，禁止将其标注为 AI 对话；反之也禁止以"有真人参与"为由免除 AI 承担回应时的披露，或免除 V5-2 的合成内容标识。

边界条件本条规定的是体验承诺，不构成对任何法域法定义务的合规判定；适用法规可能提出更严格或更具体的要求（如披露的时点、措辞与留证），以其为准。

设计应用把披露做成一句自然的开场而不是一段法务声明——冗长的合规话术会被用户直接打断，反而降低实际到达率。这是 V3-2「结论先行」的明示例外：身份披露属于必须前置的内容。

验证示例

• 用户侧：让未被告知的参与者与系统交互一轮，随后询问他们认为对方是谁，统计误认率。
• 实现侧：遍历所有可发起对话的入口（外呼、接听、唤醒、深链），验证披露在每一条路径上都发生；验证"你是真人吗"的应答路径如实。

反例做不到——外呼机器人用高度拟人的声音自称"我是小李"，全程不说明是 AI；做过头——每一轮回应前都重复一次"我是人工智能助手，我的回答仅供参考"。

V5-2合成语音可被机器识别必须¶

一句话：合成音频带机器可读标识，不只靠人耳分辨。

适用产生可被录制、转发或存档的合成语音输出的产品。

规则产品生成的合成语音必须携带可被机器识别为合成内容的标识（音频水印、元数据或等效机制之一以上），且该标识在常规的传输、录制与转码后应当尽可能保留。标识的存在与形式必须可被说明，禁止以"人耳听得出来"作为替代。标识机制不得附带与标识目的无关的个人信息；法定制作要素应按适用要求保留，其余内容必须最小化。

产品必须分别验证原始输出、下载导出、平台转发、转码及扬声器重录等声明支持的链路。元数据在扬声器重录中不会随声波保留，不得仅配置元数据就承诺“录下来仍可识别”；不可覆盖的链路必须说明限制。适用法规要求特定文件元数据或显式标识时，不得以其他单一机制替代。

边界条件本条不要求标识在任意程度的对抗性处理后仍然存活——现有技术做不到；它要求的是标识存在、机制明确、常规链路下有效。

设计应用这一层与 V5-1 分工明确：V5-1 面向当下正在对话的人，本条面向这段音频之后的流转。两者不能互相替代。

验证示例

• 实现侧：对输出音频做标识检出验证；测试常见录制与转码链路后的留存率并记录实际结果。

反例做不到——生成的语音在任何环节都无法被判定为合成；做过头——在标识中嵌入用户标识符或会话内容，制造新的隐私风险。

依据与参考合成内容标识的法定要求见 reference.md 第五节（区分适用主体、内容类型与例外）。

V5-3用真人的声音要有本人授权必须¶

一句话：谁的嗓子，谁说了算，范围和期限写清楚。

适用使用基于真实人声训练或克隆的语音的产品，包括声库、定制音色与用户自建音色。

规则使用可识别为特定真人的合成声音，必须具备该本人的明确授权，且授权必须可解析到用途范围、内容范围与有效期限。禁止在授权范围之外使用，禁止以已获得录音素材为由推定授权。授权撤回后必须停止新的生成；已生成内容的处置必须有明确规则并告知本人。用户为自己创建的个人音色属于其个人数据，必须可查看、可删除，删除后不得继续用于生成。

边界条件本条不涉及授权的法律形式与效力认定，那属于合规范围；本条要求的是产品侧存在可解析的授权记录与可执行的撤回机制。

设计应用把"音色"做成有主体、有期限的对象，而不是一个配置项里的枚举值。

验证示例

• 实现侧：抽取在用音色，验证每一个都可解析到授权主体、范围与期限；执行一次撤回，验证新生成被阻断。

反例做不到——拿公开演讲录音训练音色用于商业外呼；做过头——把用户为无障碍目的自建的个人音色也纳入繁琐的逐次授权流程，使其无法实际使用。

V5-4情感表达不制造虚假状态必须¶

一句话：不用语气伪造共情、紧迫和确定性去促成决定。

适用具备情感、语气或风格控制能力的语音输出产品。

规则情感与韵律不得使输出声称超出实际证据的确定性，不得虚构紧迫时限或后果，也不得以系统模拟的担忧、失望或依恋为理由要求用户让步。必要的“不确定”“尚未提交”等限定必须在最终音频中清晰可辨，不能被音量、重音、语速或音效掩盖。友善、关切与有起伏的语音本身不被禁止。

评审判据：先核对事实，再检查表达，最后检验用户是否理解；三类证据不可相互替代。

边界条件不要求推断与查证结果必须采用不同音高或韵律，也不以“中性语调”直接判合格。对语调是否造成误导仍有争议时，记录目标语言、用户群体、对照音频、理解问题和预先约定的通过条件；证据不足标为待验证，不凭风格标签裁决。

设计应用先让“预计周五到，尚未收到承运方确认”在最终音频中完整可懂，再选择合适的语气。用户可要求平缓风格，但关闭情感风格不能删除事实限定。

验证示例

• 用户侧：听取查证／推断、真实期限／虚构催促的成对材料，回答“现在知道什么、还不能确定什么、是否必须立刻行动”；按预设理解目标评估，不以转化率代替。
• 实现侧：将音频和事实依据逐项核对；包含错误状态、不可感知限定或情绪施压的输出不能通过。

反例做不到——用“最后一分钟”催促用户办理，实际没有截止时间；做过头——强制所有推断改成同一种低沉语调，却不说出真实的不确定性。

依据与参考可理解表达的需求见 reference.md 第二节；以上判据是本规范的设计要求，资料不提供通用的语调诚信阈值。

V5-5人格不越过能力边界应当¶

一句话：人设可以有，但不能声称产品做不到的事。

适用为语音助手设定名称、性格或人格设定的产品。

规则语音人格的表述应当与产品的实际能力与身份一致。人格禁止声称产品实际不具备的能力、身份或权限（自称能够办理实际无法办理的事项、自称具有并不具有的职务或资质、自称记得实际未被保存的内容）。人格设定不应当被用于回避能力披露义务：用户询问能做什么时，应当得到基于实际能力的回答，而不是符合人设的回答。人格在跨会话中应当保持一致，其变化应当可被用户感知。

边界条件本条不禁止人格化的表达方式、名字与语气风格；约束的是人格所声称的事实。

设计应用人设的边界应当与能力清单同源维护——能力变了，人设能说的话也要跟着变，而不是各自维护两份文档。

验证示例

• 用户侧：让用户依据一轮对话推测系统能做什么，与实际能力清单比对。
• 实现侧：审查人格提示与能力清单的一致性；构造超出能力的请求，验证回应不以人设话术掩盖无法完成的事实。

反例做不到——助手自称"您的专属顾问，什么都能帮您办"，实际只能查询；做过头——每次交互都先声明一遍能力边界清单。

V5-6人机交接明示必须¶

一句话：从 AI 转到真人、从真人转回 AI，都要说一声。

适用同时存在 AI 与人工坐席，或存在人工介入 AI 对话能力的产品。

规则对话方在 AI 与人之间切换时，必须明确告知用户，禁止在用户不知情的情况下由 AI 接替人或由人接替 AI。人工介入 AI 对话（人在幕后审阅或改写 AI 回应）时，必须让用户知道这一安排的存在。交接时此前提供的信息必须被携带（承接 V4-5），交接失败时的处置按 V7-3 处理。交接后的责任归属与记录归属必须可解析——用户事后应当能够知道某一段对话由谁作出。

边界条件本条不要求披露具体坐席的个人身份；要求的是"人还是 AI"这一区分可知。

设计应用交接是语音服务里信息与信任最容易同时丢失的一处。把"我现在把您转给同事，您刚才说的订单号我已经同步过去了"做成标准交接语，同时解决身份告知与信息携带两件事。

验证示例

• 用户侧：完成一次含交接的对话，检验用户能否正确指出交接发生的时点与前后各是谁。
• 实现侧：验证交接事件被记录且对话归属可解析；验证交接时任务信息被携带。

反例做不到——用户以为一直在和人说话，其实前半段是 AI；做过头——每次坐席内部转接都完整播报一遍身份与工号说明。

3.6 V6 在场可知¶

麦克风采集的不是"用户的输入"，是一段物理空间里的声音。喇叭播出的也不是"给用户的输出"，是这段空间里所有人都能听到的内容。这个差别使语音产品天然涉及从未同意过的第三方，也使"私密内容"的判定不能只看设备归属。本原则管辖麦克风与扬声器所处的空间。

V6-1何时在听是可感知的必须¶

一句话：采集状态让在场者随时可核对，包括中途进来的人。

适用具备语音采集能力的产品。

规则音频正在被采集时，产品必须以下列两种方式之一使采集状态可被在场者核对：

1. 持续指示：提供在采集全程持续可感知的指示；至少一种方式不依赖用户注视屏幕。
2. 等效替代（仅限经验证确实无法提供持续指示的设备形态）：可靠的起止告知、任意时刻可查询当前采集状态、以及中途进入者可发现的说明或伴随指示，三者必须齐备。

指示必须真实反映采集状态：未采集时禁止呈现采集中，采集时禁止无指示。指示不得被应用层静默关闭；用户可调整其形式（如从声音改为灯效），但不得取消到无任何可感知指示的状态。状态查询不得以开启采集为前提，查询本身也不构成重新开麦的授权。

边界条件本条不要求持续发声——持续的视觉或灯效指示对有屏与有灯设备即可满足。采用等效替代的设备必须登记其形态与验证记录；若在目标场景中，错过起音者、开机即常听的情形或中途进入的第三方无法据此判断采集状态，则等效替代不成立，产品不得承诺在开放空间常听。

设计应用把"采集中"与"在听（等待指令）"设计成可区分的两件事：前者是隐私事实，后者是话轮状态（V2-5）。二者常被合并，导致用户以为不在听的时候其实在采集。

验证示例

• 用户侧：请用户在一段使用过程中标记他们认为设备在采集的区间，与真实采集区间比对。
• 实现侧：验证指示由真实采集状态驱动；验证应用层无法关闭指示。

反例做不到——唤醒时亮一下随后熄灭，实际持续采集数十秒；做过头——每一次唤醒词检测（包括本地未上传的）都发出提示音，设备整天响个不停。

V6-2常听范围显式且可退出必须¶

一句话：说清什么在本地、什么上了云、留多久、怎么关。

适用具备唤醒词检测或常态监听能力的产品。

规则产品必须显式声明其常态监听的范围：哪些处理在设备本地完成、哪些音频离开设备、离开的音频保留多久、用于什么用途。用户必须能够关闭常态监听（可以以功能受限为代价），关闭后必须实际停止采集而不仅是停止响应。声明必须以用户可获取的形式提供，禁止仅以隐私政策条款满足本条——产品内必须有可达的说明。用途发生变化时必须重新告知。

待机本地检测、唤醒前缓冲、会话采集、上传处理与持久保留必须分别说明。采集模式与处理位置是两个独立维度，不得合并为一个"监听档位"来声明：持续本地识别等不离开设备的音频处理同样必须写明，不因其在本地而略去。关闭的作用范围（本设备／本账号／全部关联设备）必须一并声明。产品声称“关闭麦克风”或用户撤销采集权限时，所有依赖该入口的采集必须停止；仅结束本次会话是否恢复已获授权的本地唤醒检测，按 V7-6 明示，不得把两种关闭操作混为一谈。

边界条件本条不要求披露唤醒词检测的技术实现；要求的是数据边界（本地／离开设备）、保留期限与用途这三项可知。

设计应用把"关闭"做成真实的采集停止而不是响应屏蔽——两者对用户的承诺完全不同，混淆会直接构成虚假陈述。

验证示例

• 用户侧：让用户依据产品内的说明回答"设备什么时候会把声音传出去"，统计正确率。
• 实现侧：关闭常态监听后验证无音频采集与上传；验证声明的保留期限与实际存储一致。

反例做不到——"为了提供更好的服务，我们可能会收集语音数据"，无范围无期限；做过头——每次唤醒都弹出一次数据处理说明要求确认。

V6-3旁人从未同意必须¶

一句话：第三方的声音不默认用于个性化与训练。

适用可能在多人环境中采集音频的产品。

规则采集到的非用户本人的语音，禁止默认用于个性化、画像构建或模型训练；确需此类用途时必须具备相应的同意基础，且该基础不得由设备所有者代第三方给出。第三方语音的保留期限必须不长于完成当前任务所必需，禁止以"无法区分说话人"为由把全部音频按用户本人数据处理——不具备区分能力时应当对整体采取更保守的处理，而不是更宽松的处理。产品必须说明其对第三方语音的处理方式。

边界条件本条不要求产品具备说话人分离能力；不具备时按上述保守方向处理即可。本条也不禁止为完成当前任务而处理第三方语音（如会议中的多人发言，前提是该场景本身已获得相应同意）。

设计应用这是语音产品与图形界面产品最根本的差异之一：图形界面的输入来自用户的手，语音的输入来自房间。与 V1-6 的分工：本条管这段声音能不能被留存和使用，V1-6 管它算不算指令。

验证示例

• 实现侧：验证非本人语音不进入个性化与训练管线；验证不具备区分能力时走的是保守分支而非默认合并。

反例做不到——家中访客的对话被纳入用户画像；做过头——因担心第三方数据而关闭全部语音改进机制，产品长期无法修正识别错误。

V6-4外放输出按空间降级必须¶

一句话：客厅音箱念的是"有一条新消息"，不该念的连"有"都不念。

适用通过扬声器外放语音输出，且输出可能包含私密内容的产品。

规则语音输出的呈现级别必须以所处空间的私密性为输入解析，至少区分完整播报、摘要播报、仅告知存在性、不播报四档。先取得目标端允许范围，再按语音空间限制收紧；两者无共同允许范围、或目标端裁决结果为"不呈现"时，结果是"不播报"，不得回退到"仅存在性"。"不播报"时不得暴露该事项的存在、类别或来源；必要的控制回执通过已获准、可访问的其他方式提供。设备私密级别未知、或设备属于共享类别时，必须仅输出已经确认可公开的内容，禁止默认完整播报；摘要或存在性本身仍敏感时取不播报。验证码、金额与收款方、健康信息、私人消息正文属于必须受此约束的内容，且这类内容的保守处理不因用户的通用配置而放宽（见配套字典第十节）。用户接入私人收听设备（耳机）时可解析为更高的呈现级别；接入状态未知时按外放处理。

收听路径在播报中变化时，必须在新的输出端开始播放私密内容前暂停并重新裁决，清理可能转至外放的缓存。耳机断连、蓝牙切换、音频焦点丢失和设备重连都必须纳入验证；不能等到下一条回答才应用新的私密级别。

边界条件本条不要求产品自行判定房间里有没有人——技术上不可靠；它要求的是以设备类别与收听方式这两个可解析的输入作出保守裁决。

设计应用将内容敏感性、当前操作者权限、设备共享属性与收听方式共同作为播报依据。摘要也可能泄密；无法生成符合当前许可的摘要时直接不播报，不机械地“降一级”。耳机接入只改变收听方式，不证明操作者有权查看内容。

验证示例

• 用户侧：向客厅音箱发送含验证码的消息，观察默认播报内容。
• 实现侧：验证未知设备走共享分支；验证耳机接入状态变化触发重新解析。

反例做不到——音箱在客人面前朗读完整的银行验证短信；做过头——用户独自在家戴着耳机，系统仍然只肯说"您有一条新消息"。

V6-5误唤醒可查可删必须¶

一句话：被误触发录下的片段，用户看得到也删得掉。

适用具备唤醒词触发采集能力的产品。

规则因唤醒判定而产生的采集记录必须可由用户查看与删除，误唤醒产生的记录不得被排除在可查看范围之外。删除必须实际生效于可由产品控制的副本，且必须说明哪些部分（如已进入不可逆的聚合统计）无法删除及其原因，禁止以"已匿名化"为由笼统拒绝。产品应当提供减少误唤醒的手段（灵敏度调整、唤醒词更换或替换为按键触发）。录音、转写、任务状态与长期个性化信息必须分别说明用途和删除范围，不能以删除其中一类冒充全部删除。

边界条件本条不要求保留全部音频以供查看——产品可以选择不保留；不保留时须如实说明，此时"可查看"的对象为记录的存在与时间而非音频内容。"不保留音频"仅指音频这一类数据，不等于不保留任务事实：任务进度与已提供信息的保留按 V7-3 独立成立，删除音频不连带删除接续所需的任务状态，保留音频也不延长该状态的承诺期。

设计应用误唤醒是可测量的产品指标而不是意外。把误唤醒记录的可见性与灵敏度调整放在一起，用户在发现问题的地方就能处理问题。

验证示例

• 用户侧：制造一次误唤醒，检验用户能否在记录中找到并删除它。
• 实现侧：验证删除操作在各存储副本上生效；验证不可删除部分被显式说明。

反例做不到——记录里只列出用户主动发起的对话，误唤醒的片段不出现也删不掉；做过头——把每一次本地唤醒词检测都记录为条目，列表长到无法使用。

V6-6声纹是便利不是凭据必须¶

一句话：声音像不像本人，不能作为高后果操作的唯一认证。

适用使用语音生物特征进行识别、个性化或身份验证的产品。

规则语音生物特征禁止作为不可逆或高后果操作的唯一认证依据；此类操作必须具备额外的验证要素。声纹用于识别使用者以提供个性化时，必须提供不依赖声纹的等效路径，禁止因声纹不匹配而使用户无法完成本可完成的任务（承接 V1-4）。声纹数据的采集必须经用户明确同意，可被查看与删除，删除后不得继续用于识别。声纹不匹配时的处置必须给出可执行的下一步，而不是仅拒绝。

边界条件本条不作声纹可用于认证的普遍许可。采用 NIST SP 800-63B-4 的认证体系禁止基于声音进行生物特征比对，不能以另加一个要素绕过；其他体系须按其适用标准判断。低后果便利识别（如音乐偏好）仍受同意与非语音替代要求约束。

设计应用声纹在噪声、感冒、变声期与老龄化下的稳定性不足以承担单独认证。把它定位为"减少输入"的便利手段，而不是"替代验证"的安全手段。

验证示例

• 用户侧：模拟声音变化（感冒、噪声环境）后尝试完成任务，验证替代路径可用且成本可接受。
• 实现侧：遍历高后果操作，验证不存在仅凭声纹放行的路径。

反例做不到——仅凭声纹匹配即可语音转账；做过头——把所有语音功能都置于声纹注册之后，未注册者无法使用基础能力。

依据与参考W3C NAUR 的用户需求草案提出非语音替代；认证采用的 NIST SP 800-63B-4另有更严格的声音比对禁用要求（见 reference.md 第二、五节）。

V6-7声音推断用途单独说明必须¶

一句话：允许听清指令，不等于允许从声音判断情绪、健康或身份特征。

适用从音高、韵律、语速或其他声学特征推断情绪、健康、年龄等个人属性，并据此改变服务或保留画像的产品。

规则产品必须把这类推断与完成当前指令所需的识别分开说明，明确推断什么、为什么使用、会改变什么，以及是否保存或提供给其他方。不得仅凭麦克风权限或语音服务开启状态推定用户同意附加推断；启用前须满足适用的许可条件和独立选择要求。用户须能够拒绝或关闭非任务必需的推断，并继续使用基本语音功能。推断结果必须保留不确定性，不得当作用户已陈述或已确认的事实；不得仅凭声音推断作出影响权益的决定，必须有可核对依据和可纠正路径。派生特征与推断记录须纳入查看、删除与用途限制，原始录音删除不代表这些记录已删除。

边界条件检测语音活动、抑制噪声或按用户明确请求调整语速，不因使用声学特征就自动属于本条；只要结果被用于个人属性判断或画像，就不能以“音频优化”规避。是否允许具体推断用途须独立判断，告知与同意并不能使被禁止的用途成立。

设计应用用户说话较慢时，可以提供“需要更多时间吗”的控制；不要直接记录其健康状况。调节应答时间与给用户贴标签是不同决定。

验证示例

• 用户侧：关闭附加推断后仍能办理同一任务，并能了解已形成记录如何更正和删除。
• 实现侧：检查原始音频、派生特征与下游决策各条路径；未启用时不产生对应画像，关闭后不继续使用缓存推断。

反例做不到——以通话录音许可为由自动生成情绪画像；做过头——关闭情绪推断也一起禁用基本降噪或语速控制。

依据与参考个人属性推断与语音任务的用途区分是本规范的设计要求；适用透明度义务与范围限制见 reference.md 第五节。

3.7 V7 有退路¶

语音会失败。环境太吵、用户不便出声、识别不了这个口音、这件事本来就不适合用说的办。V2 管的是在语音通道内收回话轮，本原则管的是离开这条通道：还能去哪、进度还在不在、必要的话有没有真的送到，以及用户说完"不聊了"之后系统是不是真的停了。

V7-1随时可切换输入方式必须¶

一句话：对话进行到一半也能改用打字、按键或触屏。

适用具备一种以上输入方式的产品，或可与具备其他输入方式的设备协同的产品。

规则用户必须能够在语音对话进行中的任意时刻切换到其他输入方式，禁止要求用户先结束或放弃当前对话才能切换。切换后此前提供的信息必须保留并可继续使用（承接 V4-5）。产品必须使切换手段可被发现，且其发现不依赖用户先经历失败。切换的目标模态不可用时，必须如实说明并给出其他出路，而不是静默维持在语音。

边界条件本条不要求产品必须具备多种输入方式——纯语音设备可以没有；此时本条通过与其他设备的协同满足（转到手机继续），接续前核对目标入口的操作者与查看权限，携带仍有效的任务信息，接续失败保留原进度且不重复提交。确实不存在任何其他模态时，产品必须在 V7-5 下声明这一限制及其影响范围。

设计应用把"改用打字"做成入口而不是错误恢复的分支。在办理类流程中，需要输入地址、编号与自由文本的环节是切换需求最集中的地方，应当主动提供。

验证示例

• 用户侧：在流程中途请求改用其他输入方式，观察是否需要重新开始与重复已提供信息。
• 实现侧：验证切换在所有环节可用；验证任务状态跨模态携带。

反例做不到——语音办理到一半想改用打字，只能挂断重来；做过头——每个环节都同时呈现四种输入方式的提示，把简单问答变成模态选择菜单。

依据与参考W3C NAUR 明确要求"允许用户在任何时候决定切换输入方式，即使语音对话已在进行中"（见 reference.md 第二节）。

V7-2转人工通道存在且可达必须¶

一句话：代表机构办事的语音产品，必须留一条通向人的路。

适用代表机构与用户处理事务的语音产品（客服、办理、预约、投诉、催收、售后等）。

规则此类产品必须存在通向人工处理的路径，该路径必须可被发现、可在任意环节到达，且不以先完成若干轮自助尝试为前提。禁止把转人工入口隐藏在深层菜单、要求特定措辞才能触发，或在识别失败时反而失去该入口——识别失败恰恰是最需要它的时刻。人工不可得时（非工作时间、排队超限）必须如实告知并给出可执行的替代（回拨、留言、其他渠道），且用户已提供的信息必须被保留并携带至该替代路径。

转人工必须保留用户当前可用的沟通方式；用户以文字办理时，不得把只能说话和听电话的坐席当作唯一终点。转接后仍需重复口述的替代渠道不满足非语音路径要求（V7-5、V7-7）。

边界条件不代表机构处理事务的产品（设备控制、内容播放、个人助理）不适用本条，但仍受 V1-3 的升级序列终点要求与 V7-5 的非语音路径要求约束；此类产品必须在其升级序列中显式声明终点形态，不得以静默失败代替。

设计应用把转人工做成常驻能力而不是失败兜底。用户主动要求转人工时不应当被要求先说明理由或先尝试自助。

验证示例

• 用户侧：在流程的多个环节（含识别失败状态）请求转人工，统计到达所需轮次与失败率。
• 实现侧：验证入口在识别失败分支中仍然存在；验证转接时已收集信息被携带。

反例做不到——自助语音菜单里没有转人工选项，说"转人工"被回答"抱歉我没有理解"；做过头——每一轮都主动提示"需要转人工吗"，让本可自助完成的事全部涌向坐席。

依据与参考W3C COGA 语音模块要求保留固定路径（通常为某个单一按键）用于到达人工，并把"简单的错误恢复应转向人工而非制造挫败循环"列为明确需求（见 reference.md 第二节）。

V7-3对话中断不吞任务必须¶

一句话：掉线、超时、说不下去了，进度还在，别处接得上。

适用语音对话承载多步任务、产生外部影响或需要跨会话延续的产品。

规则语音对话因掉线、超时、用户中止或转接失败而结束时，任务的进度与已提供的信息必须被保存，用户必须能够在重新接入时（同一通道或其他通道）接续，禁止出现任务既未完成也无处可查的状态。中断时已经产生的外部影响必须可被用户获知，重新接入后禁止重复已经发生的外部影响。恢复时必须核对当前实际状态而不是仅凭对话记录推测。结果缺失或超时标为“未知”，先查询原操作的真实结果；确认未生效且可安全重试后才重试。播放重复、用户重说和重新连接都不得单独触发重复提交。产品必须声明进度的保留期限，且该期限自"进入等待、暂停、中断或本次运行结束"起算，不自"语音侧最后一次状态写入"起算；执行中持续保有必要状态，读取不续期。一次连续非运行区间只从首次进入等待、暂停、中断或结束起算，状态之间切换不反复续期；恢复实际执行后再次进入该区间，按新起点计算。用户明确删除进度时说明不可接续的后果，法定留存的事实与可继续办理的状态分别处理。声明的是最短保障，不是最长保存上限。存储用途上限不足以覆盖拟作出的承诺时，必须在用户依赖该承诺前缩窄声明或提供其他接续方式；已经作出的承诺不得静默缩短，禁止静默删除。承接任务状态保留策略时，直接沿用该策略的起算与到期语义，不另立时钟。

边界条件本条不要求为纯查询类的一次性交互保存进度；适用范围限于会改变状态或需多步完成的任务。

设计应用电话掉线、静音和转接失败都可能中断办理，应把进度保存纳入任务主路径。与 V7-2 的转人工、V7-1 的转模态共用同一份任务状态。

验证示例

• 用户侧：在流程中途挂断后重新接入，观察是否需要从头开始、是否出现重复扣款或重复提交。
• 实现侧：验证中断点的状态被持久化；验证恢复路径核对外部实际状态。

反例做不到——办理到最后一步掉线，重打进来一切从头，而上一次的提交其实已经生效；做过头——为每一次未完成的查询都建立待办并反复提醒用户回来完成。

V7-4无屏场景的必要告知有补达应当¶

一句话：费用、法律和错误告知不能只靠念一遍就算送到；补不了就别在这条路上提交。

适用无可用屏幕或用户不便查看屏幕，且交互涉及费用、法律义务、权利告知或错误后果的产品。

规则此类告知禁止仅以一次性语音播报作为送达手段。产品应当提供可留存、可复查的补达形式（短信、邮件、应用内记录、账单条目之一以上），并使用户知道补达将以何种方式在何时到达。补达内容应当与语音播报的实质一致，不得以补达形式承载语音中被省略的关键条件。无法提供补达渠道时，告知该限制不构成豁免：以该告知为前提的办理动作不得在当前路径提交；产品必须在动作发生前告知限制、提供可完成的替代渠道并保留已有进度（承接 V7-1、V7-3）。错误后果已经发生时，无法事先阻断，产品必须如实说明影响范围与补达失败的事实，并提供可查询记录或可访问的人工处理路径，禁止把"已安排发送"表述为"用户已收到"。受限的是需要该告知的办理动作，不是整个服务：不受影响的其他路径应当保持可用。

边界条件本条不要求把每一句系统输出都留存；覆盖范围限于费用、法律义务、权利告知与错误后果这四类。本条为【应当】级，但其中的"禁止仅以一次性语音播报作为送达手段""无补达渠道时不得提交以该告知为前提的动作""禁止声称已完成送达"是硬约束。补达也不得成为额外收集联系方式的理由：用户拒绝提供联系方式时，按上述替代渠道处理。

设计应用语音里的告知义务和屏幕上的不同：屏幕上内容留在那里，语音里说过就没了，而且可能被打断（V2-2 已规定未播出内容不计为已送达）。补达是这两条规则共同的落点。

验证示例

• 用户侧：完成一次涉及费用的语音办理，检验用户事后能否找到费用条款的可复查记录。
• 实现侧：验证被打断的必要告知触发补达；验证补达内容与语音实质一致。

反例做不到——语音开通一项收费服务，费用条款只在通话中念过一遍，用户手上什么也没有；做过头——每一次普通查询都发送一条内容冗长的确认短信。

依据与参考V2-2 规定播放事实，V7-4 规定必要告知的可复查路径。

V7-5语音不是唯一路径必须¶

一句话：能用语音办成的事，存在不用语音也能办成的路。

适用面向一般公众的产品与服务。

规则可以通过语音完成的任务，必须存在不依赖说话与不依赖听觉的完成路径；该路径可以在其他设备或其他渠道上，但必须可被发现且其成本不显著高于语音路径。禁止把语音作为某项服务的唯一可用入口。产品形态确实只有语音时（纯语音硬件），必须声明这一限制，并说明用户通过何种其他渠道完成同类事务。无障碍相关的法定要求以适用的无障碍标准与法规为准，本条不替代其判定（见附录 B）。

边界条件本条不要求每一项功能在每一个渠道上都可用；要求的是任务可完成，而不是界面等价。

设计应用这一条是 V1-4、V6-6、V7-1、V7-2 的共同底线：它们各自提供的替代路径，最终都汇入这一条。

验证示例

• 用户侧：邀请无法使用语音的参与者（聋人、言语障碍、身处禁声环境）完成同一任务，比较可完成性与成本。
• 实现侧：遍历主要任务，验证每一项都存在非语音完成路径且入口可被发现。

反例做不到——某项业务只能通过语音客服办理，网页与应用内均无入口；做过头——为保证等价而在纯语音设备上强行塞入一套难以使用的按键交互，替代路径名存实亡。

V7-6退出即停止必须¶

一句话：用户结束对话之后，不再采集，也不再执行没确认的动作。

适用任何语音交互产品。

规则用户结束对话或退出语音交互后，产品必须停止音频采集（常态监听按用户在 V6-2 下的设置解析），并停止执行尚未获得确认的动作；已提交且无法撤销的动作必须让用户知道。禁止在对话结束后继续推进用户未确认的流程，也禁止把对话结束理解为对未决事项的默认同意（承接 V4-3）。退出必须有可感知的回执，使用户知道系统确实已经结束而不是仍在等待。用户可以要求保留进度以便之后接续（V7-3），但保留进度不等于继续执行。

边界条件本条不禁止在用户明确授权的前提下继续后台执行已确认的任务；必须事先说明离开后继续的工作、范围、结束条件与查询或取消入口；实际进度和结果可查，退出不得扩大已获授权。

设计应用"结束"在语音里比在图形界面里模糊得多——用户走开、不说话、说"就这样吧"，都可能意味着结束。把结束设计成有明确回执的事件，而不是靠超时推断。

验证示例

• 用户侧：在一项未确认的操作待决时结束对话，验证该操作未被执行且用户得到明确回执。
• 实现侧：验证退出后采集实际停止；验证未确认动作不进入执行队列。

反例做不到——用户说"算了不订了"就挂断，订单在后台照常提交；做过头——每次结束都要求用户逐项确认放弃了哪些未完成事项。

V7-7输入输出可以分别选择必须¶

一句话：输入输出可以分别选择。

适用具备语音与文字能力，或可借助辅助技术提供这两类能力的产品。

规则产品必须允许分别选择输入与输出方式，使“说话输入、文字接收”和“文字输入、语音接收”在实际支持的组合中可用；不得把关闭播报等同于关闭输入，或把开启字幕等同于重新开启麦克风。承诺同步文本时，必须区分临时转写、最终转写与任务确认结果，修订与播放中断必须反映到相应呈现中。文字与语音可详略不同，但关键对象、金额、否定、条件与执行结果必须一致。关闭声音后，必要状态、控制回执和错误不得只通过声音给出。

边界条件本条只处理通道选择与语音对应文本的一致性，不规定手势、注视等多模态融合。无屏产品可通过可访问的协同渠道满足；不得承诺实际不可用的组合。

设计应用语音输入可保留而播报关闭；用户可用字幕读结果。屏幕阅读器使用时可关闭重复的产品播报，避免两路声音同时争夺听觉。

验证示例

• 用户侧：分别使用两种混合组合完成任务，在播报中关闭声音或修订转写，核对关键值和回执是否仍可访问。
• 实现侧：注入字幕先到、音频延迟和中途打断，检查未播内容不被标为已播放；确认文字通道不会丢失错误反馈。

反例做不到——“静音”按钮顺带关闭麦克风，却仍显示可以说话；做过头——为了同步强迫用户同时开启字幕、麦克风与播报。

依据与参考W3C NAUR，REQ 3–9支持输入输出组合与同步文本；本条的状态区分为防止流式输出误导而作的设计推导。

4. 术语和定义¶

附录 A：故障注入验证清单¶

按原则给出可执行的故障注入项。每项验证的是规则在失败条件下是否仍然成立——通过不代表符合全部要求，不通过即存在明确缺口。

V1 识别

1. 在背景噪声下发出会触发不可逆动作的指令，验证系统转为确认而非直接执行。
2. 连续给出无法识别的输入，记录到达可用出路所需的轮次，以及此前信息是否保留。
3. 由带明显口音、构音障碍或非母语的参与者完成同一任务，比较完成率与替代路径成本。
4. 说出不常见的人名与一串编号，核对系统最终记录是否逐字一致、有无同音替换。
5. 播放含唤醒词与指令的媒体音频，验证设备未被触发执行。
6. 将系统自身播报回灌至麦克风，验证不产生自触发。

V2 轮次

1. 在长段播报中打断，在弱网与高负载下重复测量停声时延是否仍在承诺内。
2. 在"正在提交"播报中打断，验证用户能否得知提交是否已发生。
3. 说一句中间带思考停顿的长指令，验证未被截断；截断后验证可续说且前半句保留。
4. 制造后端长延迟，验证处理中信号被触发、内容不实的填充语不出现、取消可用。
5. 蒙眼或在驾驶模拟中完成一次对话，多次询问"现在轮到谁说"，统计正确率。
6. 在一位用户对话中由另一人插入一句无关语句，验证其未进入任务。

V3 输出

1. 遍历各场景输出路径，验证不存在绕过单话轮长度上限的分支；V3-1 明示的"用户主动请求连续朗读"不计为绕过，对该路径改为验证暂停与定位可用。（V3-1）
2. 播报达到上限数量的选项后请用户选择，统计重复播报比例与选错率。
3. 对语音输出做格式扫描：默认模式验证不含标记、路径、表格结构等不可听内容；用户明确请求精确朗读时（V3-4）验证保真输出确实可得且未被简化。两侧分别记录，缺任一侧不算通过。（V3-4）
4. 播报一串编号后请用户复述；在下一环节请求逐字重复，验证仍可用且值一致。
5. 给出一个只能推断的问题，检验用户听完能否正确判断这是推断而非查证结果。

V4 记忆

1. 在被打断后分别验证四项：已播出片段可重听且逐字一致；未播出片段可得且未被计为已送达；私密级别在重听时重新裁决（V6-4）；缓存删除后系统如实说明不可得，而不是静默略过。"重复"与"继续"分别测试，不混为一项。（V2-2、V4-1、V6-4）
2. 在流程末尾请求修改中途某一项，验证无需重新回答全部问题。
3. 由需要更长应答时间的用户完成同一任务，统计因超时失败的比例；遍历超时分支，验证不存在"超时即同意"的路径。
4. 提出一个含三项的复合问题，用户只答其一，验证未答项不被填充默认值。
5. 在流程中途转人工或转屏，验证此前提供的信息无需重说。

V5 声音

1. 让未被告知的参与者交互一轮后指认对方是谁，统计误认率；遍历所有发起入口验证披露均发生。
2. 询问"你是真人吗"，验证如实回答。
3. 对输出音频做合成标识检出；测试常见录制与转码链路后的留存率。
4. 抽取在用音色：可识别真人音色（V5-3）验证可解析到授权主体、范围与期限，并执行一次撤回验证新生成被阻断；完全合成音色验证 persona.source 的来源类别真实，不要求提供真人授权主体。（V5-3）
5. 按 V5-4 分别核对事实依据、最终音频的限定可感知性与情绪施压；以用户理解测试评估争议样例，不以韵律是否不同判定通过。
6. 构造超出能力的请求，验证回应不以人设话术掩盖无法完成的事实。
7. 完成一次含人机交接的对话，检验用户能否指出交接时点与前后各是谁。

V6 在场

1. 请用户标记他们认为设备在采集的区间，与真实采集区间比对。
2. 关闭常态监听后，验证无音频采集与上传，而不仅是停止响应。
3. 在多人环境中采集后，按 V6-3 分三种基础情形验证：无有效同意基础时第三方语音被拒绝进入个性化与训练管线；具备相应同意基础时按已声明范围处理且范围可解析；无法区分说话人时按更保守方向整体处理。不以"一律不得进入训练"为单一判据。（V6-3）
4. 向共享设备发送含验证码的消息，验证默认播报为保守档；切换耳机接入状态，验证重新解析。
5. 制造一次误唤醒，验证记录可见且可删除，删除在各副本生效。
6. 模拟声音变化后尝试高后果操作，验证不存在仅凭声纹放行的路径且替代路径可用。另按产品声明的适用体系分支检查：声明采用 NIST SP 800-63 体系的，验证声音比对未被用作该体系下的认证要素——包括"声纹＋其他因素"的组合；未声明该体系的，按其实际声明的适用要求检查并记录依据。（V6-6）

V7 退路

1. 在流程中途请求改用其他输入方式，验证无需重新开始。
2. 在识别失败状态下请求转人工，验证入口仍存在且已收集信息被携带。
3. 在流程中途挂断后重新接入，验证进度保留且无重复扣款或重复提交。
4. 打断一段费用告知，验证触发补达且补达内容与语音实质一致。
5. 遍历主要任务，验证每一项都存在非语音完成路径且入口可被发现。
6. 在一项未确认操作待决时结束对话，验证该操作未被执行、采集已停止、回执明确。

补充场景：

1. 将临时转写中的收款人或日期修订，验证旧确认失效；未知置信不能被模型自评分替代。

2. 用户在“提交订单”期间说“停”，验证先暂停未提交动作，再澄清停止范围；播放缓冲随之清理。

3. 输入带思考停顿的长句与仅有“嗯”的短回答，分别核对端点计时、附和分类和误打断恢复。

4. 提示音立即到达但实质回答延迟，验证两项时延分开记录；按语言、设备和网络检查尾部表现。

5. 测试中英混说、同音姓名、前导零编号和跨时区日期；请求逐字朗读链接与放慢语速。

6. 播报私密信息时拔出耳机，验证先暂停、清理缓存，再裁决外放内容；重听也重新裁决。

7. 分别用语音输入／文字接收、文字输入／语音接收完成任务，并在转人工后保持可用沟通方式。

8. 撤销麦克风权限后请求停止或重听，验证非语音控制可用且采集不被暗中恢复。

9. 麦克风被拒绝授权、被其他应用占用或中途拔出时，验证“在听”不成立，用户不被要求反复重说；恢复权限后也不自动提交残缺输入。（V1-3、V2-5）

10. 确认“是的，不对，改到周五”这样的整句，验证只处理完整修正；旧确认、退出后的迟到转写和旧音频回包不能推进新任务。（V1-1、V1-2、V2-2、V7-6）

11. 提交成功但回执丢失时断线重连，验证先查询原动作，结果未知不盲目重试；播报重听不再次预约。（V7-3）

12. 关闭声音属性推断后，验证基本任务仍可用、缓存画像不再影响决策；分别删除录音与派生数据，确认效果与声明一致。（V6-7）

13. 长等待后中断，核对保留起点；等待转暂停不续期，恢复实际执行后再次挂起按新起点计算。用户明确删除进度后不假称仍可接续。（V7-3）

14. 安全时限到期只触发有依据的后备动作，不记录为用户同意；必要告知被中断不计为已送达，也不阻止退出。（V2-1、V4-3）

15. 改用更慢语速后检查输出时长重新分段，并请求“说简单点”；关键条件仍在，音频、字幕和真实执行值一致。（V3-1、V3-2、V3-7、V7-7）

清单使用约定：每一项检查都绑定其规则 ID 与该规则的适用条件与边界；规则明示的合法例外必须作为正向用例进入清单，不得被检查项判为失败。蒙眼、静音等模拟条件可用于验证无视觉路径，但不替代目标视障、认知或言语障碍用户的实际参与。

分类检验（检验原则切分的一致性）：随机抽取产品中的 10 条具体要求，由三名以上未参与本规范撰写的评审者独立判断其归属的原则。分歧比例的分母为抽取的条目数（10 条），一条要求只要存在评审者之间的归属分歧即计为一条分歧条目；分歧条目超过三成（即 4 条及以上）时，检验不通过——此时应当调整原则的切分或规则的粒度，而不是增设中间层或映射说明。该三成为试行的维护触发线，按实际使用情况复核，不作为通过率承诺。本规范已知的三处高风险边界（V1／V6、V3／V4、V2／V7，见第 1 章）应当在抽样中被覆盖。

完整任务走查（检验覆盖的完整性——分类检验不承担这一职责）：选取两到三条贯通 V1–V7 的真实任务（例如一次含费用告知的语音办理、一次多人环境中的私密消息播报），逐步记录每一步所依据的规则；出现无处归属的需求时，记录该需求并作为规则缺口处理，不就近塞入某条现有规则。归属一致率高不等于覆盖完整，两项检验分别记录结论。

附录 B：论据边界与来源类型¶

本规范的条款依据分为四类，分别记录约束效力与证据用途，不按发布机构简单排序，全部条目见 reference.md：

本规范尚未收敛的部分，在此显式声明，不以条款语气掩盖：

• 不设通用性能阈值。首音时延（V2-6）、端点静音阈值与最大等待（V2-3）、单话轮长度上限（V3-1）、并列项上限（V3-3）、进度保留期限（V7-3）——规范只要求"有明确定义、有依据、可验证"。这些数值随语言、任务类型、用户群体与部署环境差异极大，现有引用资料不足以支持通用性能阈值。工程参数记录在 reference.md 第四节，是机制参照，不是推荐值，更不是合规依据。
• 韵律效果依赖情境。V5-4 可核对事实与限定是否真实、可感知，但不能给音高或情感标签设置通用诚信分数；仍需目标语言和用户研究支持。
• 多模态融合不在范围内。本规范只管语音这一通道。语音与屏幕、手势、注视的融合语义，跨模态的时间同步（唇音同步、触觉延迟），以及模态间的冲突裁决，均未被覆盖。V3-4、V7-1 与 V7-7 只触及了通道之间的边界，不构成融合规范。
• 车载语音未单独处理。驾驶场景的视觉—手动干扰、注意力预算与接管时限由领域标准与法规规定，本规范让位于它们；V2 与 V3 在车载场景下的参数解析必须以那些标准为准。
• V1／V6、V3／V4、V2／V7 三处边界：见第 1 章的明示。若在实践中反复出现归属争议，应当调整原则的切分。

配套的 Token 词汇表见 Design Token.md；本规范不通过 Token 字典产生新的义务，字典也不替代本规范。

附录 C：完整任务示例与验收记录¶

以下为设计示例，不是已完成的产品实验；其中任务信息仅用于说明交互，不能作为性能或能力证据。

C.1 办理预约：从查询到可复查结果¶

场景：用户在带屏手机上预约机构服务，可用语音或文字，费用需留存确认，支持人工文字服务。任务完成的条件是：日期、地点和费用被正确理解并确认，机构返回唯一预约结果，用户能查到记录；一声“好的”不表示预约完成。

对照分支：低后果的时间查询不加确认；用户一次说全日期和地点不拆开重问；最终确认前改值只重核受影响内容；没有可访问的费用记录路径时不提交预约。这样同时检查遗漏和过度确认。

C.2 一张可执行的验收记录¶

C.3 指标与通过条件¶

以下是测量口径。数值门槛由项目在测试前设定；不同指标不加权平均成一个“语音质量分”。

按语言／口音、听说或认知需求、设备及收听方式、噪声和网络分组报告样本量与不确定性；小样本标明不足，不由总体高分推断各组达标。性能样本中没有观察到错误不证明错误永不发生。

验收分三路：内容和规则的静态检查；采集、路由、停声、提交与恢复的系统实验；目标用户的可理解性和完成成本研究。硬底线失败不得被速度、满意度或总分抵消。证据不足时明确限制支持范围或保留待验证结论；模型、声线、处理用途或环境变化后，只沿用仍覆盖实际条件的证据。

---

实施验收场景¶

以下场景把已有条款转成可复核的验收输入，不另设通用性能阈值。按产品适用能力选取，补充真实设备、用户、输入序列和证据；不适用记录原因，未执行不得记为通过。

每个场景分别核对配置的有效值、执行记录与用户可理解的结果。保留版本、目标、事件时点、失败范围和恢复结果；外部结果未知不填作成功或失败。