用语音控制做自动化：从小游戏到业务流程

语音控制并不“浪漫”，它更像一个触发器：一句话进来，系统就该把后续动作跑完。很多团队把语音当成锦上添花的交互（比如智能音箱），但我更愿意把它当作低门槛的自动化入口——尤其对小企业来说。

Deepgram 的一个 P5.js 语音控制小游戏教程，恰好把这件事讲透了：画布中心的玩家不动，敌人从四个方向靠近；你只要说对对应方向的词，就能发射子弹。它是游戏，但更像一段现实业务的缩影：事件出现 → 识别意图 → 触发动作 → 更新状态 → 反馈给人。

这篇文章属于「人工智能在游戏与数字娱乐」系列。我们会借这个小游戏的结构，拆解“语音识别 + 状态机 + 工作流”的通用模式，并把它重新定位成：小企业如何用 AI 语音助手把日常流程自动化（客服分流、工单创建、仓库提醒、门店巡检记录等）。

语音控制游戏的核心，其实是一条可复用的自动化链路

这类项目最有价值的地方不是“能用嘴打怪”，而是它提供了一个清晰的架构：

1. 输入层：麦克风音频流（持续）
2. 识别层：实时语音转文字（WebSocket）
3. 决策层：把文字映射到意图（命中哪个方向的词）
4. 执行层：触发动作（创建子弹对象）
5. 状态层：实体管理/碰撞检测/得分/失败
6. 反馈层：UI 提示“系统听到了什么”

把它替换到业务场景里也完全成立：

• 输入层：电话、前台麦克风、会议录音、门店对讲
• 识别层：Deepgram（或同类 ASR）输出转写
• 决策层：规则匹配/关键词/轻量意图分类
• 执行层：调用 CRM、工单、ERP、Webhook、RPA
• 状态层：工单状态、订单状态、客户标签、SLA 计时
• 反馈层：在工作台里展示“听到的内容 + 执行动作 + 可撤销”

你真正需要的不是“会说话的应用”，而是能被一句话可靠触发的工作流。

用 P5.js 把“状态管理”练熟：为什么这一步决定能不能自动化

教程里一开始就做了三件很工程化的事：score、gameOver、playerSize，再加上 translate(width/2, height/2) 把坐标原点移到中心。看起来是游戏技巧，实际是在训练你处理自动化系统最常见的难题：状态到底在哪里、什么时候改变、由谁改变。

用实体数组管理业务对象：enemies 与 bullets

游戏里有两个数组：

• enemies[]：外部事件，随机从四个方向出现并逼近（风险/需求/来电/异常）
• bullets[]：你采取的动作，从中心向外发射（创建工单/通知供应商/拦截支付/触发复核）

这套结构对应到业务自动化，建议你也用“实体列表 + 生命周期”思路来设计：

• 每个事件对象都有：id、source、timestamp、status、priority
• 每个动作对象都有：type、target、payload、result、retryCount

然后像游戏的 draw() 循环一样，在系统里跑一个“调度循环”（可能是定时任务、队列消费者、流式处理器）：

• 拉取新事件
• 更新事件状态
• 如果命中规则则创建动作
• 回写结果并展示给人

“碰撞检测”就是业务里的匹配与拦截

教程用 dist() 判断子弹是否击中敌人。业务里当然不是算距离，但本质仍是匹配条件：

• 订单金额 > 5000 且客户为新客 → 触发人工复核
• 来电转写里包含“退款”“不到账” → 直接创建售后工单并优先级 +1
• 仓库巡检语音里包含“缺货”“破损” → 触发补货/报损流程

把“碰撞检测”写清楚，你的自动化才会稳定。否则就会出现最常见的问题：误触发与漏触发。

语音识别接入：最关键的是“持续连接 + 最终结果”

教程的语音部分采用浏览器端：

• getUserMedia({audio:true}) 拿麦克风
• MediaRecorder 每 1000ms 发送一次音频 chunk
• WebSocket 连到实时识别服务
• 只在 received.is_final 时处理转写

这几步值得你在做企业语音自动化时直接照抄它的设计原则。

为什么一定要用 is_final（最终结果）驱动动作

实时转写通常会先给出临时结果（partial），再给最终结果（final）。如果你用 partial 触发自动化，系统会：

• 触发多次（同一句话被不断修正）
• 触发错误（临时词被改掉）
• 用户体验崩（刚说一半就被执行）

所以更稳的方式是：

• partial 用来做 UI 提示（“正在听…”、“识别中…”）
• final 才能触发动作（创建工单、发消息、改状态）

业务里别用 includes() 直接匹配关键词（但可以从它起步）

教程用 transcript.includes(currentWords[direction]) 来判断是否命中方向词。做 demo 很合适，但业务里建议升级一层，否则很容易误判。

更可靠的三段式（从易到难）：

1. 同义词表 + 规范化：把“开单/建单/创建工单”统一到 CREATE_TICKET
2. 意图 + 槽位：识别意图（报修/退款/查询），抽取信息（订单号/门店/金额）
3. 置信度与确认：低置信度时让用户确认一次（尤其涉及钱、权限、数据删除）

你可以仍然像游戏一样保留 heard（“我们听到了什么”），但最好再加上：

• intent：系统判断的意图
• action：将要执行的动作
• undo：可撤销/可回滚

在企业场景里，“可解释”比“聪明”更值钱。

从小游戏迁移到小企业：3 个立刻能做的语音自动化模板

下面这三套模板我见过很多团队用得起来，原因很简单：输入明确、动作单一、价值可衡量。

模板 1：语音触发工单（前台/门店/维修）

语音指令：

• “报修，冰箱不制冷，门店 A”

自动化动作：

• 转写 → 识别意图 MAINTENANCE → 创建工单 → 分配负责人 → 发通知

关键字段（槽位）：

• 门店/位置、问题类型、紧急程度、联系人

可衡量指标：

• 工单创建耗时（例如从 2 分钟降到 20 秒）
• 信息缺失率（需要回拨补充的比例）

模板 2：客服分流与优先级（电话/在线语音）

语音指令（客户自然表达）：

• “我这笔订单扣款了但没显示付款成功”

自动化动作：

• 转写 → 关键词/意图识别 → 打标签（支付异常）→ 提升优先级 → 推送给对应队列

关键点：

• 只做分流与打标通常风险低、上线快
• 先别急着自动退款，先把路由做好

模板 3：仓库/巡检“边走边记”（语音记录 → 结构化）

语音指令：

• “3 号货架，纸巾缺货，预计两天用完”

自动化动作：

• 转写 → 抽取 位置/品类/数量/时间 → 生成补货任务 → 汇总日报

价值：

• 减少手写/回到电脑再录入的二次劳动
• 数据更及时，缺货风险更早暴露

安全与上线：别把 API Key 直接丢在浏览器里

原教程也提醒了一个现实问题：如果你在浏览器里直连语音识别服务，API Key 暴露的风险很高。企业场景建议这么做：

• 浏览器/前端只连你的后端（或边缘函数）
• 后端再去连 ASR 服务，并做鉴权、限流、审计
• 需要时给前端发短期 token（例如几分钟有效）

如果你打算把语音触发自动化接到真实系统（CRM/工单/财务），再加三条底线：

• 最小权限：语音触发账号权限要比人工账号更低
• 可追溯：记录“转写文本—意图—动作—结果—操作者/设备”
• 可回滚：支持撤销、二次确认，尤其是删除/付款/发货类动作

这个案例对「AI 在游戏与数字娱乐」意味着什么？

在游戏里，语音是输入方式；在数字娱乐更广的范围里，语音还是：

• 直播间互动的指令入口（“开盲盒”“切镜头”）
• 语音驱动的 NPC 对话与任务触发（语音意图 → 状态机推进）
• 反作弊与风控的信号来源（异常语音、辱骂识别、行为联动）

而对小企业来说，它提供了一个更务实的启发：用一个可玩的 demo 把整条链路打通，再把“子弹”换成工单、消息、标签、Webhook，你就拥有了第一条语音自动化工作流。

接下来如果你想把这个思路落到真实业务，我建议按这个顺序做：

1. 先选一个低风险动作：打标签、分流、创建草稿工单
2. 用 final transcript 触发动作，保留“系统听到了什么”的可视化反馈
3. 把关键词匹配升级为“意图 + 槽位”，并加确认与撤销

语音会成为你团队的下一个自动化入口吗？如果让你从今天就选一个流程用语音触发，你会先从哪个环节下手——客服、巡检，还是工单？