语音入口开始替人办事，授权要落在动作上而不是转写上
一、键盘有一道天然的闸口，语音没有
把语音入口从只会对话推进到可以执行任务，能力清单看着只是多了几项：查邮件、改动会议、制作演示文稿、搭建网站，甚至代用户写一封信去追讨被重复扣掉的订阅费。真正变了的不是能力数量，而是输入介质本身的性质。语音相对键盘有四个结构性差异。
- 不可撤回。话已经出口，转写已经进会话，删掉那句话并不能收回它触发的动作。
- 同音与口音造成语义歧义。字面对不上时，语义仍可能被合理地补全，于是错得很像对。
- 周围人声与环境噪声造成误触发。说话的未必是这台设备的使用者，甚至未必是对着设备说的。
- 缺少草稿状态。键盘输入有一个尚未提交、可以回看、可以局部修改的对象，语音通常说完就进入执行。
第四点最关键。键盘上的回车是一个明确的、由人主动做出的提交动作，所有下游的权限设计都可以挂在这一个闸口上。语音没有这个闸口，或者只把一个不可靠的静音检测当成闸口。于是那条默认假设——模型理解对了就可以执行——在语音场景里站不住。授权对象必须改写：不再问识别到的这句话是什么，而是问这一步会产生什么后果。
二、按后果分四档，不按命令分档
按命令分档是走不通的，因为同一类命令的后果完全取决于参数：把会议挪到另一个时段和把会议连同参会人一起取消，是两件事。按后果分四档，才有可能穷举。
| 档位 | 典型动作 | 授权要求 | 必须留下的东西 |
|---|---|---|---|
| 读取类 | 查未读邮件、播报今日安排 | 可静默执行 | 查询范围与数据来源 |
| 可逆写类 | 改标题、把会议挪到另一时段 | 执行后立刻给出明显的撤销入口 | 原值与新值 |
| 不可逆写类 | 删除、覆盖、对外发出 | 执行前显式确认 | 确认时刻与确认内容 |
| 涉资金或对外发送 | 提交退款申请、代用户致函第三方 | 二次确认，且关键参数要念出来 | 参数快照与接收方 |
这张表有两个连带写法。第一，档位要绑在真正执行的那个写接口上，而不是绑在语句分类上；只在语句层面定档，换一种说法就可能落进低档。第二，定档要有责任人：新接入一类动作时必须先定档，未定档的一律按最高档处理，这张表要进变更流程，而不是留在实现注释里。
可逆与不可逆之间还有一条容易忽略的分界：撤销的可行性取决于对方系统是否支持，而不是取决于我方是否记录了原值。写入外部系统的动作，即使我方留有原值，也不应归入可逆写类。
三、参数复述：三项必念
免视场景下，人没法核对屏幕上写了什么。能拦住错误的手段只剩一个：把决定后果的三个参数用语音复述一遍，让使用者在听觉通道上完成一次校验。这三项是金额、收件人、时间。选取原则是哪一个错了最贵，而不是界面上恰好显示了什么。
复述要满足三条才算有效。一是数值本身要念清楚，不能说成按刚才说的执行；二是念出来的内容必须与最终提交的参数同源，不能念一套写一套；三是打断要真生效，使用者任何插入都应中止执行，而不是把打断当成新的语音继续解析。第三条最容易做错，因为在安静环境里演示不出被打断之后到底停了没有。
念参数还带来一个副作用：金额、收件人、时间这三项，往往正是当事人不想被旁人听到的内容。设计上要给出等价文本这条退路，也就是把同一组参数显示在界面上而不是播出来，但这条退路不能用在涉资金与对外发送那两档——那两档要求听觉与视觉至少有一处完成确认，两处都没有就不算确认。免视状态下（走路、开车、手上在忙）只能靠听觉，这一点要在产品说明里写明，而不是让用户自己去试。
四、误唤醒三类场景与幂等三件
误唤醒大致三类场景：他人说话，包括影视内容与开放办公区里的对话，说的是另一件事；自言自语与转述，使用者把刚听到的内容复述一遍，恰好命中了指令形态；跨语言同音词，一种语言里的普通词是另一种语言里的触发词。对应的降代价措施也是三条：唤醒之后加一道前置校验，要求紧随其后的确有针对该设备的意图；执行前留一个可打断的等待窗口；连续误触发之后自动降级为只读或仅给建议。降级必须有明确的恢复路径，不能一路降到底变成永久禁用。
幂等是语音比键盘难得多的一层。同一句指令被重复说完、说到一半被打断又重说、因为没听到回应而再说一次，三种情况都会把一个意图变成两次动作，结果是两封致函、两次会议改动。落地要三件东西。
- 会话意图标识：一个意图从第一次被识别起就带稳定标识，重说只更新这个意图，不新建一个。
- 动作去重表：以意图标识、目标接口与关键参数共同做键，重复命中不再执行。
- 以业务键做幂等：改动某一场会议要落到该会议的业务标识上，落到转写文本上必然失败。
三件里第三件是根，前两件是为了让第三件能被触发。去重表要有过期策略，否则一次被误判为重复的正常请求会永久挡掉后续同类操作；过期时间要按业务对象定，而不是按会话定——同一封信不该因为去重记录还活着就发不出去，也不该因为记录过期就在同一分钟内发两封。被打断这件事本身也要进日志，它既是排障线索，也是判断打断是否真生效的唯一材料。
五、可回看列表与跨系统授权链
语音任务的可回看状态要人为补回来，办法是把每一次执行的动作、参数与结果写进一个可查列表，并且这个列表以任务为中心组织，不以对话气泡为中心。以气泡为中心时，用户复盘不了刚才那条指令到底做了什么，他得先把散在长流里的片段重新拼起来。列表至少要回答四项：做了什么动作、参数是什么、影响的是哪一个对象、现在还能不能撤销。
跨系统授权链在语音场景里多出一个问题：这一句话可能来自一台并没有登录的设备。这时必须能回答三问——代谁执行、用哪份凭证、这份凭证的权限范围由谁授予。答案要落到可查询的主体上，不能停在会话上下文里有登录态这种描述。设备与主体分开记账，是这类接入最容易漏的一项。
留痕的内容也要挑。要复盘一次误执行，需要的是意图标识、动作、参数快照、执行结果与确认方式这几项，原始终录音频并不在其中；把音频长期留存只会扩大敏感信息的暴露面，而它并不能回答这一条到底改了什么。参数快照按字段存，敏感参数按最小必要存，这一条要和可回看列表一起定下来，否则前端做了列表、后端却在存全部。
六、企业交付三问与验收四类场景
把这类功能交付给企业客户，有三个问题要在方案阶段谈清，不能留到出事之后。一是谁的动作可以被语音触发，要按角色界定而不是按安装用户界定；二是触发记录保留多久、保留哪些字段、谁有权读；三是错误触发之后的赔付与恢复责任怎么切。恢复要比赔付先谈，多数误执行是可撤销的，撤销成本远低于争议成本。
验收至少覆盖四类场景，缺一类都不算通过：嘈杂环境、旁有他人说话、口音偏离、被打断后重说。四类看同一个指标面：该执行的执行了几次、不该执行的拦下了几次、被拦下之后有没有给出清楚的告知。只演示安静环境的报告，洹拓不接受，因为它测的是识别，不是授权。
最后是一条分工边界：语音适合发起，不适合确认。发起一个任务可以靠一句话；决定后果的那一步，仍然需要一个可复核的可视化确认。我们把它写进接入约束，而不是写在免责声明里。