企业官网建设流程全解析

1. 整体方案设计：为什么是UE + Vue，以及三条技术路线的取舍

先说结论：UE负责“长得像人”，Vue负责“像人的业务逻辑”，AI负责“说人话”。这三个东西凑在一起，本质上是把实时渲染的数字人形象，嵌入到一个业务系统里，让用户在网页上就能和它对话、办事。项目启动之前，最先要定的不是模型怎么做，而是数字人渲染画面怎么传输到浏览器，这一步直接决定整个项目的技术栈和工期。

主流的传输方案有三条路，我分别踩过，说下实际感受。

方案一：UE像素流送（Pixel Streaming）

这是官方支持最成熟的路线。UE里跑一个渲染进程，把画面实时编码成视频流，浏览器端用WebRTC拉流播放。优点是画面质量无损、模型效果完全保留，UE生态里的所有渲染特性都能直接用；缺点是并发吃显卡，一个数字人实例就要占一张卡，十个人同时访问就要十张卡，成本直接起飞。适合对画面要求极高、并发量低的场景。

方案二：UE WebUI插件 + 嵌入式页面

这个方案是把UE当成一个“嵌入式应用”塞进浏览器窗口。UE的WebUI插件会在引擎内部拉起一个Chromium浏览器控件，你可以在这个控件里加载Vue页面，同时通过插件提供的绑定接口和UE侧通信。好处是Vue页面和UE数字人不在同一进程，互不干扰，而且UE的数字人还是在本地渲染，不占服务器显卡；坏处是它本质上是“Vue被UE包裹”，而不是“UE被Vue包裹”——你蒙在鼓里，用户分不清网页和引擎的边界，但如果你要的效果就是“打开网页就是一个全屏数字人”，这个方案极其合适。

方案三：UE渲染成透明视频流，叠加到Vue页面上

这个方案用在“数字人只是页面里的一块浮层”的场景。UE端输出带透明通道的视频（比如绿幕抠像或RGBA流），Vue端用canvas或video标签叠加到页面指定位置，AI对话消息通过WebSocket中转。优点是灵活，数字人只是页面的一部分，系统本身还是正常的Web应用；缺点是透明视频的编码延迟和解码性能是个坑，绿幕抠像边缘会有毛刺，得耐心调。

综合对比下来，我最终选的是“UE像素流送 + Vue嵌入”的组合，但在业务系统内部，用WebUI插件方案做了内部演示版本。这篇文我会把两条线都讲清楚，先讲Vue嵌入UE像素流送的标准路径，再讲WebUI插件模式怎么和Vue系统做消息桥接。你根据自己场景选，不用纠结哪个更好，只有哪个更适合。

2. UE端数字人制作与AI交互链路搭建

2.1 数字人本体：从建模到MetaHuman的选型

我建议直接使用MetaHuman，除非你有定制的高模需求。MetaHuman在UE里已经是行业标杆，面部绑定、表情系统、口型动画都是现成的，开发周期至少省一个月。如果是超写实风格项目，可以用Character Creator或者C4D建模再导进UE，但绑定和表情重做的工作量非常大，不是个人或小团队能扛的。

在UE里创建MetaHuman之后，要做三件事：

• 拖入场景，调整灯光和后期处理，因为数字人好不好看，七分靠材质三分靠光。
• 配置动画蓝图，把空闲待机、眨眼、呼吸、微表情做成状态机，让角色在等待用户输入时也不会像蜡像一样死板。
• 配置口型同步，MetaHuman自带基于音频驱动的ARKit表情绑定，可以直接接收音频流计算口型。

2.2 AI交互链路：语音识别、大模型、语音合成三件套

AI交互的核心链路是：用户语音 -> ASR转文字 -> LLM生成回复 -> TTS合成语音 -> 数字人口型播放。这条链路在UE端可以全流程处理，也可以拆开放在服务端，两种我都试过。

如果是全流程在UE端做，UE里有现成的语音识别插件（比如基于Whisper的本地推理插件），大模型调用可以通过HTTP请求发给云端API（GPT、通义千问、文心一言等），TTS建议本地部署Edge-TTS或者传统的讯飞、百度TTS接口。这样做的好处是延迟低，坏处是UE项目本身会更重，打包体积和内存占用都上去了。

更推荐的做法是把AI链路拆到服务端。UE只负责采集麦克风音频、播放音频、渲染数字人；服务端负责ASR、LLM、TTS，通过WebSocket或者其他长连接协议和UE通信。这样做的好处有三个：

• UE项目保持精简，启动快、占显存少。
• AI服务端可以独立扩展，换大模型换语音包都不需要重新编译UE。
• 日志和调试集中在服务端，出问题好排查。

我在实际项目里用的是后者。服务端负责音频流和文本流中转：UE把麦克风采集的16kHz PCM音频推给服务端，服务端识别成文字后，调用大模型得到回复文本，再把回复文本合成音频并转换为Base64回传，同时将文本通过WebRTC的数据通道传给Vue端做字幕展示。异步链路全部走消息队列，避免UE端UI线程阻塞。

2.3 UE如何播放音频并驱动口型

音频播放这块有个关键点：TTS合成之后的音频格式和采样率要统一，否则数字人口型会延迟。我建议统一使用16kHz或24kHz单声道PCM，或者直接输出WAV/M4A格式，UE端用AudioComponent播放，同时把音频数据实时送到MetaHuman的表情节点驱动。

如果是流式音频，UE端要用SynthComponent或者自定义的音频解码插件接收流式数据。每一段音频块到达后，边播放边驱动口型，这样用户听到的声音和看到的口型是同步的。这里有个容易踩的坑：TTS响应时间如果超过500ms，用户感知会很明显，所以最好做“流式TTS”，也就是不用等整段音频合成完再播放，而是合成一段就播放一段。

口型驱动方面，MetaHuman的Lip Sync节点接上音频后会自动计算音素，不需要手动K帧。但要注意不同语言的口型差异，英文和中文在元音和辅音上的口型还是有区别的，最好根据业务语言单独校准。

3. UE与Vue的通信桥接层：WebSocket、WebRTC、JS消息总线

3.1 为什么通信层是核心难点

很多做前端的人以为UE数字人接进来，就是写个<iframe>或者<video>标签的事。实际上UE和Vue之间没有原生的JS协议通道，你必须在中间搭一座桥。这座桥就是整个项目最核心的工程部分。

• 用户点了Vue页面的“开始咨询”按钮，Vue怎么告诉UE让数字人进入待机唤醒状态？
• 用户在UE的麦克风里说话，Vue页面上的字幕怎么同步？
• 用户在Vue页面上点击“结束会话”，UE怎么停止当前的动画和音频？
• 如果在UE里触发了某个业务事件（比如数字人引导用户完成后台操作），Vue怎么感知并更新页面状态？

这些都属于“桥”的责任范围。桥的设计质量直接决定项目的稳定性和开发效率。

3.2 方案A：UE像素流送 + WebSocket控制桥

这套方案适合“UE作为远端渲染，Vue作为前端壳”的架构。像素流送的画面通过WebRTC传给浏览器，但控制信号和业务数据不走WebRTC，而是单独建一个WebSocket通道。

具体架构是：

• Vue页面加载像素流送播放器（官方提供的player.js，会生成一个<video>标签渲染视频流）。
• Vue同时建立一条WebSocket连接到信令服务，这个信令服务就是UE像素流送的Signaling Server（默认端口80）。
• 当Vue需要控制UE时，发送JSON消息到Signaling Server，信令服务器转发给UE进程。
• UE端收到消息后，通过蓝图或者C++函数处理，执行对应的数字人动作。
• UE端想返回状态时，走同一条链路反向发回，Vue监听message事件接收。

消息格式一定要在项目一开始就约定好。我这里给一个简单但够用的协议模板：

{ "type": "request", "action": "start_session", "payload": { "userId": "U123456", "userName": "张三", "sessionId": "S789" }, "requestId": "req_001", "timestamp": 1690800000000 }

响应格式：

{ "type": "response", "status": "success", "code": 200, "data": {}, "requestId": "req_001", "timestamp": 1690800001000 }

Vue端在message事件里解析type字段，区分是“响应”还是“事件推送”。比如UE端检测到用户长时间不说话，主动推送一个inactivity_warning事件，Vue收到后可以弹出提示。

推荐用vue-bus（一个事件总线库）在Vue内部转发这些消息，避免在组件里堆一大坨WebSocket逻辑。我把socket实例封装成useUESocket()组合式API，在需要和UE通信的组件里直接调用，可维护性高很多。

3.3 方案B：UE WebUI插件 + 原生JS桥接

如果你选的是WebUI插件方案，那通信方式会更加“原生”。WebUI插件会在UE里内嵌一个Chromium浏览器，它提供了一个C++/蓝图侧和JS侧的双向通信绑定。

• Vue页面通过window.ue对象（插件注入的全局对象）调用UE侧函数。
• UE侧通过插件的ExecuteJavascript方法调用Vue侧的全局函数。
• 关键点：WebUI插件里有“绑定”的概念，你要先注册一个WebInterfaceObject，把UE侧的函数暴露给JS，同时把JS侧的回调函数注册到UE侧。

我自己的做法是：在UE蓝图里写一个BrowserBridge蓝图类，把所有需要暴露给Vue的函数（比如StartListening、StopListening、PlayTTS）都用UFUNCTION标记，然后绑定到WebUI窗口。在Vue端则封装一层ueBridge.js，统一做参数校验和错误处理，不直接操作window.ue。

这个方案的好处是通信延迟低，因为进程内通信不需要走WebSocket的网络往返。坏处是跨进程的模块依赖更难管理，UE项目里如果导入WebUI插件后出现了渲染异常，排查起来会比纯像素流送麻烦很多。

3.4 通信协议的版本管理

项目团队超过两个人的时候，通信协议一定会变。从一开始就要给协议加version字段，并且维护一份Markdown或者JSON Schema文档。我见过最崩溃的情况是：服务端改了action名，UE端改了函数名，Vue端改了字段名，三个地方各改各的，线上出了Bug还互相甩锅。我现在的做法是：把所有消息定义放在一个公共的protocol.json里，三个端共用，改协议时同步更新，CI里加一个格式校验，防止有人改坏了不提交。

4. Vue端组件的完整实现：从初始化到消息流的闭环

4.1 封装一个UEDigitalHuman.vue组件

在Vue系统里嵌入数字人，不要在每个页面都裸写一套逻辑，而是要封装成一个全局组件。这个组件的职责是：

• 加载像素流送播放器（或者WebUI的桥接脚本）
• 管理生命周期（创建、连接、销毁）
• 接收和发送UE协议消息
• 暴露可视界面（视频区、交互按钮、字幕区）

组件核心结构大致如下：

<template> <div class="digital-human"> <div class="player-container" v-show="visible"> <!-- 像素流送的video标签会被播放器动态创建并插入到这里 --> </div> <div class="subtitle">{{ currentSubtitle }}</div> <div class="controls"> <button @click="handleStart">开始对话</button> <button @click="handleMute">静音</button> </div> </div> </template>

4.2 初始化链路的坑：加载顺序、鉴权、重连

初始化那段逻辑，踩过的坑最多，列几个核心注意点：

• 播放器脚本加载顺序：像素流送的player.js必须放在Vue应用挂载之前，或者至少要在调用new Player()之前确保window.Player存在。我建议在index.html里用<script>标签同步加载，不要异步动态加载，否则会出现“偶尔能显示偶尔黑屏”的诡异现象。归根结底：WebRTC的连接时机非常敏感，延迟几秒加载脚本都可能错过信令握手。

• 鉴权：像素流送的信令服务默认没有鉴权，谁拿到地址就能连，这对业务系统是不可接受的。需要在信令服务前面挂一层鉴权中间件，Vue端在初始化时先拿到token，连接信令时带上token，信令服务校验通过才转发连接请求。Vue组件里要处理401和403的回调，自动跳转登录页。

• 重连机制：像素流送的WebSocket连接很脆弱，服务器重启、网络抖动都会断开。我的做法是在Vue端封装一个withReconnect的socket包装器，断线后指数退避重连（1s、2s、4s、8s，最大30s），同时向用户展示一个“正在重连”的浮层。重连成功后，要重置UE会话状态，不能直接接着上次的上下文继续对话，否则数字人的状态和页面的状态会对不上。

4.3 基于消息总线的会话管理

一旦UE连接成功，Vue组件就要围绕“会话”这个概念来组织消息流。一个会话的生命周期是：

1. 用户点击“开始对话”，Vue发送start_session请求。
2. UE端唤醒数字人，返回session_ready事件。
3. 用户对麦克风说话，UE把ASR识别的文字推送给Vue显示。
4. UE继续完成LLM和TTS，同时把完整回复文本推给Vue。
5. 用户点击“结束对话”，Vue发送end_session，UE复位数字人到待机状态。

Vue端用vue-bus或者Pinia来管理这个会话状态机。关键状态包括：idle、connecting、listening、thinking、speaking、ending。每个状态都对应UI的不同表现，比如listening状态下显示“聆听中”动画，thinking状态下显示加载图标，speaking状态下显示字幕和声波动画。如果这个状态机不做，交互体验会非常生硬，用户根本不知道数字人是不是在等他说话。

4.4 多页面嵌入时的组件复用

如果数字人需要出现在多个路由页面（比如首页、咨询页、订单页），只需要把UEDigitalHuman组件挂到根组件里，用provide/inject或者Vuex/Pinia全局控制它的显示和隐藏。不要把同一个数字人实例在多个页面分别初始化，那样会导致多个WebRTC连接，消耗多倍带宽和显卡资源。

我踩过一个跟路由相关的坑：Vue Router跳转时，如果数字人组件没有做keep-alive处理，每次切换页面都会销毁重建组件，导致WebSocket断开重连、数字人重新加载，体验非常差。解决方案是在根组件里对数字人组件做keep-alive包裹，并且手动控制它的show/hide，不要在路由销毁时卸载整个组件。

5. 性能优化与常见问题排查实录

5.1 延迟优化：从音频采集到口型播放的链路调优

用户最直观的感受就是“我说完话，数字人多久能回”。整个链路延迟的构成大约是：

• 麦克风采集 + 网络上行：50~100ms
• ASR识别：200~500ms（取决于云端还是本地）
• LLM生成：500~3000ms（取决于模型大小和prompt复杂度）
• TTS合成：300~1000ms（流式合成可减少到首包延迟）
• 网络回传 + 播放：100~300ms

合计下来，最快的场景也要1秒左右，普通场景2~3秒，如果LLM和TTS都在云端且网络不好，5秒以上也不奇怪。

针对这个，我做了三件事：

• LLM接入流式输出（SSE），拿到第一个token就可以让数字人先产生“正在思考”的微表情，同时把已经生成的部分文本推给Vue显示，用户感知会明显快很多。
• TTS用流式合成，合成一小段就回传一段，不要等全部合成完。
• UE端提前进入thinking状态，在发送ASR请求的同时就让数字人播放轻微的点头、眼神移动动画，掩盖处理等待的空白期。

5.2 画面卡顿和播放延迟排查

如果你是像素流送方案，画面卡顿通常不是网络问题，而是编码和渲染节奏不匹配。排查顺序是：

1. 先看CPU和GPU占用，如果GPU编码器已经满负载，降低编码分辨率或帧率。
2. 看WebRTC连接的stats面板，关注packetsLost和jitter，如果这两个值高，就是网络问题。
3. 如果只是第一次打开页面卡，后面正常，可能是GPU初始化慢，需要预热。

另外注意：像素流送默认是30FPS，但数字人说话时嘴型动画30FPS会显得不自然，建议开到60FPS。代价是码率翻倍，但如果内网部署或者带宽够，画面流畅度提升很值。

5.3 声音问题的三个坑

我做测试时遇到过三个声音相关的坑，都很典型：

• 回声：用户端扬声器播放数字人的声音，同时麦克风又把扬声器的声音采进去了，导致ASR识别出数字人自己说的话。解决方式是在UE端做AEC（回声消除），或者在采集端要求用户戴耳机。如果不做AEC，对话会越聊越乱。
• 双音轨：TTS音频同时在UE端播放，又在Vue端通过video标签播放，导致用户听到两个声音，重叠且有延迟差。像素流送方案里，UE的声音会通过WebRTC传到浏览器播放，所以Vue端绝对不能再播放一遍TTS音频，只做字幕。
• 音频设备切换：用户插拔耳机时，麦克风设备变了，UE端采集到的音频可能会空。需要在服务端做静音检测，连续3秒静音就自动让数字人提示“我听不到你的声音”。

5.4 多用户并发与显存容量规划

像素流送方案最痛的就是并发。

单张显卡能撑几个数字人实例，没有定论，但大致可以参考：一个4K分辨率的MetaHuman实时渲染实例，大概需要6~8GB显存。如果你的显卡是24GB显存的专业卡（如RTX 6000 Ada），最多同时跑3个实例；如果是消费级卡（如RTX 4090的24GB），同样3个，但稳定性存疑。

实际项目中，不要单机扛所有并发。用K8s部署多个像素流送节点，每个节点分配一张卡，Vue端通过NodePort或者Ingress负载均衡到不同节点。每次用户连接时，先调一个调度API获取可用的节点地址，再发起WebRTC连接。

如果不采用像素流送，而是用WebUI插件方案，并发压力就小很多——因为数字人渲染发生在每个用户自己的设备上，服务器只跑信令和AI服务，对高性能显卡的需求降为零。这也是为什么WebUI方案在成本上更具吸引力。

5.5 常见问题速查表

5.6 部署架构的最终形态

我这个项目的最终部署拓扑大概是这样的：

• Vue应用部署在Nginx里，用户通过浏览器访问。
• 像素流送节点部署了三个，每个节点一张显卡，跑着同一个UE打包好的数字人程序，通过信令服务接收用户连接。
• AI服务端是一个独立的Python服务，跑ASR（Whisper API）、LLM（大模型接口）、TTS（Edge TTS或讯飞），通过Redis队列协调异步任务。
• Vue <-> UE的控制消息走WebSocket，UE <-> AI服务端也走WebSocket，Vue <-> AI服务端不直接通信，所有业务数据统一从UE流转。

这套架构看起来复杂，但每一条链路都是独立的，出了问题可以快速定位到是哪一层挂了。我之前试过把AI服务端和信令服务耦合在一起，结果一个服务挂了全盘崩，后来拆开之后稳定了很多。

6. 从开发到上线的避坑清单与个人体会

最后分享一些写在项目复盘笔记里的心得，可能比前面的技术细节更值钱。

先砍需求，再做技术选型。很多项目死在一开始就想做“全息数字人助理”，又要语音打断，又要手势识别，又要无线穿戴交互。实际上UE的数字人集成第一版只需要三件事：能看、能听、能说。这三件事打通了，后面的增强功能都是锦上添花。

UE项目的构建产出一定要统一管理。打包出的可执行文件放到版本控制系统的制品库，或者专门的构建服务器，不要用开发者的本地构建直接部署。不同的UE版本、不同的显卡驱动、不同的打包选项，产出的程序行为会有微妙差异，线上出了问题很难复现。

Vue侧一定要有容错降级。如果UE连接失败，用户应该还能正常使用信息系统的其他功能，只是在需要数字人的模块看到一个“数字人服务暂不可用”的占位提示。我见过一版方案是UE挂了整个页面白屏，直接把客服系统干瘫痪了，这个代价太大。

日志要贯穿全链路。从Vue的WebSocket消息，到信令服务的连接日志，到UE进程的UnrealLog，到AI服务端的请求日志，每个环节都要有traceId。排查问题的时候，没有traceId串联日志，等于大海捞针。

我在实际项目里养成一个习惯：每天上线前，手动跑一遍“用户全流程”——打开页面、开始对话、说一句话、看字幕、等数字人回复、切换页面、结束对话。这条路径走通，就能保证80%的场景不出问题。剩下20%的偶发性问题，靠日志和监控去兜底。

UE和Vue的组合开发，最难的不是技术本身，而是两个团队之间的语言壁垒。UE工程师不懂Vue的生命周期，前端工程师不懂UE的渲染管线和蓝图通信。如果你是一两个人搞定整个项目，反而有优势——因为你一个人同时掌握了两个世界的逻辑。这大概就是这两年“全栈数字人开发”这个岗位突然吃香的原因吧。