前言
在传统 Web 应用中，前端往往被视为'页面层'或'展示层'，主要职责是将后端数据以合适的形式呈现给用户。然而，当应用场景进入 AI 具身交互领域，这一认知将彻底失效。在该具身 AI 系统中，前端不再只是界面渲染工具，而是整个系统的实时交互中枢：它需要同时协调语音输入、虚拟人状态、大模型流式输出以及复杂的训练逻辑反馈。
这意味着，前端工程必须具备高度的结构化、强类型约束和可维护性，否则系统复杂度会迅速失控。本文将结合该具身 AI 系统的实际设计，系统性拆解其前端技术架构，重点说明 Vue 3、TypeScript 与 Vite 如何协同工作，支撑一个高实时性、高复杂度的 AI 交互系统。
1 为什么前端在 AI 具身系统中如此关键
1.1 前端不只是'页面'，而是交互中枢
在具身 AI 系统中，用户感知到的'智能程度'，很大一部分并非来自模型本身，而是来自前端对多种异步能力的协调效果。语音输入是否顺畅、AI 回复是否即时呈现、虚拟人是否与语言节奏同步，这些体验全部发生在前端层。
前端需要承担的职责包括但不限于：
- 对多模态输入进行整合
- 对系统状态进行实时反馈
- 对 AI 输出进行渐进式展示
- 对虚拟人行为进行精确控制
这使得前端从'被动渲染者'转变为'主动调度者'。
1.2 实时性与复杂状态管理的双重挑战
具身辩论系统的交互具有明显的实时特征。语音识别、流式大模型响应、虚拟人动画状态，往往同时发生并相互影响。任何一个环节处理不当，都会导致体验割裂，例如字幕延迟、语音与口型不同步，或状态错乱。
因此，前端不仅要处理 UI 更新，还要承担复杂状态同步与生命周期管理的任务，这对架构设计提出了远高于普通业务系统的要求。
2 整体前端架构分层设计
2.1 分层设计的总体思路
为了应对复杂度，该系统前端采用了明确的分层架构，将不同关注点进行隔离。其核心目标并非'代码好看'，而是确保在多种异步交互并行的情况下，系统依然具备可读性、可维护性和可扩展性。
整体上，前端架构可以划分为组件层、Services 服务层、Composables 逻辑复用层以及 Store 状态层。
2.2 组件层：界面与交互承载
组件层负责具体 UI 呈现，包括虚拟人渲染区域、配置面板、输入控制区以及反馈弹窗等。这一层遵循'轻逻辑'原则，组件尽量只关心展示与用户交互事件的触发，而不直接处理复杂业务逻辑。
通过这种方式，可以避免组件膨胀为'巨型组件'，同时也使得 UI 更容易调整和重构。
2.3 Services 服务层：外部能力的统一封装
Services 层是前端与外部世界的连接桥梁，主要用于封装虚拟人 SDK、语音识别服务以及大语言模型接口。通过统一的服务接口，前端其他部分无需关心具体 SDK 的调用细节，从而降低耦合度。
在具身 AI 系统中，这一层尤为重要，因为外部能力往往变化频繁，服务层的存在为替换和升级提供了缓冲空间。
2.4 Composables 层：逻辑复用与状态协同
Composables 是 Vue 3 组合式 API 的核心优势所在。系统中诸如语音识别控制、流式回复处理、虚拟人状态监听等逻辑，都被抽离为独立的组合式函数。
这种设计使复杂逻辑可以在多个组件之间复用，同时又不破坏响应式系统的一致性，是构建复杂交互系统的关键技术手段。
2.5 Store 层：全局状态与业务中枢
Store 层承担全局状态管理职责，集中维护虚拟人连接状态、当前训练模式、语音识别状态以及对话历史等关键信息。通过统一的状态源，各组件和服务可以在不直接依赖彼此的情况下完成协作。
3 Vue 3 Composition API 的工程价值
3.1 逻辑拆分与复用能力
在具身 AI 系统中，逻辑复杂度主要体现在'流程'而非'页面'上。Composition API 允许开发者以功能为单位组织代码，而不是被组件结构所限制，从而更贴合真实业务模型。
例如，语音识别的启动、暂停、结果回调等逻辑，可以被完整封装在一个 composable 中，在不同组件中按需引入。
3.2 与 Options API 的对比优势
相较于传统 Options API，Composition API 在复杂系统中更具可扩展性。Options API 往往导致逻辑分散在 data、methods、watch 等多个选项中，而组合式 API 可以将同一业务逻辑聚合在一起，显著提升可读性。
