AI语音助手原型要画清“现在有没有在听、识别到了什么、正在处理还是正在播报，以及用户能怎样打断和纠正”。只给聊天页增加一个麦克风图标，会遗漏权限拒绝、没有听到声音、误识别、说话打断播放和任务取消等关键状态。先把一轮语音任务的状态连起来，再设计波形、动效和声音提示。
可以用墨刀AI生成交互原型建立页面和状态，再在可编辑原型中连接听取、确认与恢复路径。下面用“通过语音预约会议室”讲解：原型先验证用户是否理解流程和操作，不把页面演示当成已经接入了语音识别、语音合成或会议室服务。
先选清楚语音模式，再安排按钮
不同语音模式会改变用户预期。按住说话有明确的开始和结束动作，适合一次短指令；点击开始、再次点击结束适合稍长输入；连续对话则需要让用户知道什么时候轮到自己、麦克风是否仍开启。不要在同一个按钮上无提示地切换模式。
| 模式 | 适合的任务 | 原型要补的细节 |
|---|---|---|
| 按住说话 | 发出一条短指令、填入简短内容 | 按下开始、松手结束、取消手势或取消按钮 |
| 点击开始／结束 | 较长描述、需要停顿的输入 | 清楚的录入状态、结束按钮、文字编辑入口 |
| 连续对话 | 需要多轮补充的助手任务 | 轮次交接、打断、关闭麦克风、结束会话及恢复 |
本例采用点击开始的输入方式，用户可以补充下一轮语音，也可以切换文字。当系统正在播报时，页面提供“停止播报”和“补充要求”两个明确入口；如果计划支持用户直接开口打断，还需要与语音方案一起验证实际识别与停止播放的效果。
把语音输入拆开：没有听到、没听懂和服务失败不同
用户点击麦克风之后，并不一定马上进入识别。首次使用可能需要系统许可；已经许可也可能没有可用设备。MDN对浏览器媒体输入的说明明确区分了许可拒绝、设备不可用等情况，而且用户可以暂时不回应许可请求。因此，原型应包含等待许可、拒绝后引导和文字输入替代路径。
| 状态 | 用户看到什么 | 可执行的动作 |
|---|---|---|
| 未开始 | 麦克风入口、可以提出的任务 | 开始说话或输入文字 |
| 等待许可 | 说明需要麦克风才能听取指令 | 继续授权、暂不使用语音 |
| 正在聆听 | 持续的状态提示，可见的结束与取消 | 继续说、结束输入、取消这轮 |
| 识别文字 | 已经识别的文本；尚未定稿时清楚表达 | 等待、编辑或重说 |
| 理解与处理 | 本轮指令和正在处理的反馈 | 取消任务或补充条件 |
| 结果确认 | 关键时间、地点、对象和将执行的动作 | 确认、修改、放弃 |
| 正在播报 | 文字结果、播放状态、停止播报入口 | 停止声音、补充要求、查看完整结果 |
| 失败或结束 | 具体原因和已保留内容 | 重试当前步骤、改用文字或结束会话 |
语音波形不能独自承担这些含义。用户可能看不懂动效，也可能听不到提示音，所以关键状态同时用文字和可操作按钮表达。录音进行中、只是已获得麦克风许可、语音已停止但任务仍在处理，也不能使用完全相同的界面。
用一次会议室预约，把完整对话跑通
用户说：“帮我订明天下午三点的会议室。”系统还缺会议时长、人数等会影响结果的条件。先把已识别文本显示出来，再追问缺少的信息，而不是要求用户把整句话重说一遍。
- 用户点击麦克风，页面进入“正在聆听”，显示结束和取消。
- 用户说完并结束输入，页面显示识别文本“帮我订明天下午三点的会议室”。
- 助手询问：“会议预计多久，有几位参加？”已知的日期和开始时间留在任务摘要中。
- 用户回答：“一小时，六个人。”摘要更新为具体日期、15:00—16:00、6人，并开始查询。
- 找到可用会议室后，展示会议室、日期、时间、人数和是否发送邀请。
- 用户确认后再提交，按实际结果显示预约成功、资源冲突或提交失败。
“明天”应在确认区转换成具体日期，并明确系统使用的时区；口头表达的“三点”有歧义时需要确认。原型可以使用固定日期和预设结果演示，但需求说明要写清真实系统怎样决定日期和时区，不能让研发从截图猜规则。
对于会占用资源或通知其他人的操作，确认内容应覆盖有影响的字段。本例中“找到一个可用会议室”和“已经预约成功”是两个状态；只有服务确实返回成功后才显示成功信息。自动生成一句“已帮你订好”并不等于预约动作发生。
误识别怎么改：修改一个字段，而不是重来一遍
假设系统把“六个人”识别成“两个人”。如果界面只播放一句答复，用户可能直到进入小会议室才发现错误。把人数、日期、时间等关键条件整理成可编辑摘要，用户可以直接点人数修改，也可以说“不是两个人，是六个人”。
纠正后，页面要确认具体变化：“人数已改为6人。”保留仍有效的日期和时段，重新检查房间容量。如果此前展示的会议室只容纳4人，旧结果应失效并重新查询，不能只改摘要数字却继续保留不适用的推荐。
| 误识别或含糊情况 | 建议处理 | 避免出现 |
|---|---|---|
| 人数被识别错误 | 允许直接编辑字段，更新相关容量条件 | 让用户重述完整预约要求 |
| 时间存在歧义 | 确认具体日期与时段 | 未经确认默认上午或下午 |
| 会议室名称有近音词 | 展示匹配候选，让用户选一个 | 把第一项匹配直接当成确定目标 |
| 一句话中途自我纠正 | 明确最后采用的字段，再执行查询或提交 | 同时保留互相冲突的条件 |
识别文本是让用户纠错的入口，但不必把所有技术细节搬上页面。面向普通用户，用“请确认人数”比展示一个没有解释的置信度分数更容易采取行动。
打断、静音、取消：三个操作不能混成一个
语音助手一边播报，一边允许用户继续说话时，必须约定“打断后发生什么”。最常见的混乱是：用户只想停止声音，系统却取消了预约；或者用户说取消，界面停止播报，但后台仍提交。原型应分别定义操作对象。
| 操作 | 影响对象 | 本例中的预期 |
|---|---|---|
| 停止播报 | 当前音频播放 | 停止声音，文字结果与待确认预约仍保留 |
| 关闭麦克风 | 接收新的语音输入 | 不再听取新语音，仍能查看结果或输入文字 |
| 取消本轮输入 | 正在录入的这段内容 | 丢弃当前输入，保留此前已确认的任务条件 |
| 取消预约任务 | 尚未完成的预约流程 | 停止后续提交，告知哪些内容已取消 |
| 结束会话 | 当前交互会话 | 关闭收音与播放，按产品规则保留记录或草稿 |
如果用户说“等一下，改成四点”，系统应停止当前播报，更新开始时间，并重新查询可用房间。若预约还没提交，可以直接更新待确认任务；若已经提交成功，就应进入修改已有预约的流程。请求已发出但结果尚未确定时，应先查实际状态，再决定取消或修改，不能仅凭界面停止播放就声称预约已取消。
“静音”一词可能指停止扬声器，也可能指关闭麦克风。页面尽量写清“停止播报”和“关闭麦克风”，配合不同图标，避免用户以为已经停止收音。连续对话还要始终提供容易找到的结束入口。
失败恢复：保留用户已经说清楚的内容
Google的对话设计方法把无输入、未理解和系统错误分别处理。这个区分对原型很实用：没有收到声音时应检查录入过程；听到但不理解时应补问；服务故障时则不应反复要求用户换一种说法。
| 失败情形 | 页面反馈 | 恢复路径 |
|---|---|---|
| 没有收到声音 | 提示本轮没有收到可用语音，保留清楚的开始入口 | 重新说话、检查麦克风或改用文字 |
| 有声音但没有理解 | 针对缺失字段补问，例如“你希望几点开始？” | 补充这一项，不清空其他条件 |
| 多次识别不成功 | 给可选项或文字输入，减少重复播报 | 更换输入方式，允许结束当前任务 |
| 查询房间失败 | 说明暂未获得查询结果，保留日期、时段与人数 | 重试查询或打开手动选择入口 |
| 提交后网络断开 | 显示结果待确认，而非直接显示失败或成功 | 先查已有预约记录，避免重复预订 |
| 权限被关闭 | 告知当前不能接收语音 | 引导重新授权，并保留文字操作 |
连续失败时，重复同一句“请再说一遍”会让用户陷入循环。应逐步缩小问题、提供候选或换输入方式。重试次数、停顿时长和播报速度需要按设备、环境和任务验证，不把某一组固定数值当成所有语音产品的标准。
怎样在墨刀里做出可评审的语音原型
先列状态，再画界面。把首页、等待许可、正在聆听、识别文本、补充条件、确认预约、播报、纠正和失败恢复建成一组画布。用相同的麦克风按钮、任务摘要和状态提示保持连续性，通过点击和页面跳转演示各条路径。
给墨刀AI的需求可以这样写：
为企业会议室语音预约助手生成手机端原型。
主要任务：说出日期、时间、时长和人数，查询房间，确认后提交预约。
生成状态：待输入、等待麦克风许可、聆听、识别文本、追问、
房间结果、预约确认、播报、纠正人数、查询失败和提交结果待确认。
交互规则：
1. 录入时显示结束和取消；允许切换文字输入。
2. 识别文字与任务摘要可查看，日期、时间和人数可以修改。
3. 改人数后重新检查房间容量，保留有效的日期和时间。
4. 停止播报不取消预约；关闭麦克风不隐藏文字结果。
5. 提交前显示完整摘要；结果未知时先查预约记录，不立即重复提交。
视觉：中文移动办公界面，文字清晰，状态不仅靠颜色或波形区分。
将按钮连接到对应画布，便于逐步演示。这套原型用预设转写、回答和结果来验证设计；是否能真正采集声音、边说边转写、开口打断以及播放语音，需要在接入相应服务的实现中继续验证。交付说明分别写清界面规则和服务依赖，避免把“原型按钮能跳转”误当成语音链路已经可用。
走查时，让参与者完成三件事：正常预约一间6人会议室；把识别错的人数改回来；在系统播报时修改时间并恢复流程。观察他是否知道系统正在听、停止声音是否会误取消任务，以及遇到失败能否继续。测试记录应分别写理解问题、操作问题和语音识别问题，后续才能找到对应改法。
AI语音助手的体验最终落在清楚的轮次和可恢复的任务上。先把听取、确认、纠正和恢复连成一条能走通的原型，再逐步加入真实语音服务和复杂场景。
