语音助手类产品的前端远不止一个聊天列表那么简单。以 vivo 的 Jovi 语音助手为例，用户一句唤醒词触发后，前端需要在几百毫秒内完成录音状态切换、流式识别文本上屏、意图识别结果加载对应技能卡片这一整套流程，任何一环卡顿都会被用户直接感知。本文结合 Vue 3 的工程化能力，拆解这类项目在架构分层、状态管理、动态渲染和性能优化上的实践思路。
一、项目分层：把对话逻辑和渲染逻辑解耦
语音助手前端最容易失控的地方，是把音频采集、识别回调、UI 更新全部堆在一个组件里。vivo Jovi 这类规模的项目通常会把代码拆成四层：基础设施层负责封装 Web Audio API 和 WebSocket 通信，领域层管理会话与消息模型，服务层对接技能接口，视图层只做渲染。这样的分层让每一层都能独立测试，也方便后续替换底层实现，比如把录音方案从 getUserMedia 换成原生桥接接口时，上层代码几乎不用改动。
在目录结构上，一个典型的 Vue 3 工程化项目会按照 feature 来组织，而不是按照文件类型组织。每个技能卡片有独立的目录，包含组件、状态和类型定义，配合 Vite 的动态导入能力实现按需加载。这样做的好处是，当技能数量增长到几十个时，主包体积不会随之膨胀，新技能的接入也只是新增一个目录并注册配置，不需要改动核心代码。
类型约束同样是工程化的关键一环。使用 TypeScript 定义统一的消息协议，例如识别中的临时文本、最终识别结果、技能卡片数据、错误信息等，可以让前端和语音服务端的联调问题在编译期就暴露出来，而不是等到联调时才发现字段名对不上。
二、用 Composition API 管理语音流与状态机
p>语音交互本质上是一个状态机：待唤醒、监听中、识别中、思考中、播报中、结束，每个状态对应不同的 UI 和音频行为。Vue 3 的组合式 API 非常适合把这套状态机封装成可复用的逻辑单元。下面是一个简化示例，展示如何用 composable 管理识别状态：import { ref, onUnmounted } from 'vue'
// 会话状态机：idle -> listening -> recognizing -> thinking -> speaking
export function useVoiceSession() {
const state = ref<'idle' | 'listening' | 'recognizing' | 'thinking' | 'speaking'>('idle')
const partialText = ref('')
const messages = ref<Message[]>([])
function startListening() {
state.value = 'listening'
// 开启麦克风并建立 WebSocket 连接
}
function onPartial(text: string) {
// 流式识别的临时结果，频繁更新
partialText.value = text
state.value = 'recognizing'
}
function onFinal(result: SkillResult) {
messages.value.push({ role: 'user', text: partialText.value })
messages.value.push({ role: 'assistant', card: result.card })
state.value = 'thinking'
}
onUnmounted(() => {
// 组件卸载时释放麦克风与连接，避免内存泄漏
})
return { state, partialText, messages, startListening, onPartial, onFinal }
}把状态机抽成 composable 之后，组件只负责根据 state 渲染不同的界面，逻辑层可以单独写单元测试。流式识别的临时文本更新频率很高，每秒可能触发十几次，直接绑定到输入框区域即可，注意不要让整个消息列表跟着重新渲染，可以通过 computed 或虚拟列表控制更新范围。
另一个实践要点是音频资源的生命周期管理。录音实例、AudioContext、WebSocket 连接都必须在组件卸载或会话结束时显式释放，否则在移动端 WebView 里很容易出现麦克风占用不释放、后台连接堆积等问题。用 onUnmounted 统一收口是 Vue 3 里比较优雅的做法。
三、技能卡片的动态渲染方案
语音助手识别出用户意图后，返回的往往不是一段纯文本，而是一张结构化的技能卡片：天气卡片、音乐播放卡片、日程卡片等。前端需要一个通用的渲染机制来承载这些卡片。常见做法是维护一个组件注册表，卡片数据中携带类型标识，渲染层根据标识动态匹配组件。
<template>
<component
:is="cardRegistry[message.card.type]"
:data="message.card.payload"
/>
</template>
<script setup lang="ts">
import { defineAsyncComponent } from 'vue'
// 技能卡片注册表，全部走异步组件实现按需加载
const cardRegistry = {
weather: defineAsyncComponent(() => import('./cards/WeatherCard.vue')),
music: defineAsyncComponent(() => import('./cards/MusicCard.vue')),
schedule: defineAsyncComponent(() => import('./cards/ScheduleCard.vue'))
}
</script>这套方案的核心价值在于扩展性。卡片类型由服务端下发，前端只要保证注册表里有对应组件即可。对于服务端新增的卡片类型，前端可以做一个兜底的通用卡片组件，展示标题和正文，避免出现空白区域。再加上异步组件加载失败的错误边界处理，整个渲染体系就具备了生产级的健壮性。
卡片数据建议与服务端约定版本号字段。当卡片协议升级时，前端可以根据版本号选择不同的解析逻辑，避免老版本客户端在新协议上线后直接崩溃。
四、性能优化与工程化保障
语音助手常驻手机桌面或负一屏，首屏加载速度和运行时内存占用都直接影响体验。工程化层面有几个值得坚持的做法：第一，用 Vite 做构建，利用其原生 ESM 和按需加载能力，把首屏依赖压到最小；第二，消息列表使用虚拟滚动，长会话场景下 DOM 节点数量保持恒定；第三，对高频更新的识别文本采用 v-memo 或直接操作局部 DOM，避免触发大范围的依赖收集。
质量保障方面，单元测试重点覆盖状态机和数据处理逻辑，用 Vitest 对 composable 做纯逻辑测试，不依赖真实麦克风。UI 层则配合 Playwright 编写端到端脚本，模拟完整的唤醒、识别、卡片展示流程。CI 流水线中再加入包体积监控，一旦主包超过阈值就阻断合并，从机制上防止性能退化。
总结来看，语音助手前端的工程化没有太多玄学，关键在于三点：用分层架构隔离变化、用组合式 API 收敛状态逻辑、用动态注册机制支撑技能扩展。无论你做的是手机端助手还是 Web 端对话产品，这套基于 Vue 3 的实践思路都可以直接借鉴。