企业官网建设流程全解析

AI 陪伴类应用这两年从"能聊天"卷到了"有形象、有声音、有场景"，但真正动手做过的人都知道，把大模型、语音合成、形象换装这三件事塞进一个应用里，最直接的做法是全部堆在本地——结果就是显存不够、风扇狂转、手机发烫。我前后折腾过三套方案，最后稳定下来的架构是：推理放在远程服务器，语音和场景换装留在本机。这套分工不是拍脑袋定的，而是被硬件成本和响应延迟逼出来的。下面把我踩过的坑、选型的理由、以及可以直接抄的配置流程完整写一遍，适合有一定开发基础、想自己搭一个 AI 陪伴应用的朋友参考，小白也能跟着理解每一步在干什么。

1. 为什么要把大模型推到远程、把语音和换装留在本机

1.1 先算一笔账：本地跑大模型的真实成本

很多人第一反应是"本地部署大模型让个人电脑智能化"，这个想法本身没错，但要看模型规模。一个 7B 参数量的模型，用 4bit 量化后大约需要 4-5GB 显存，听起来还行；但 AI 陪伴应用不是单轮问答，它需要维持上下文、需要流式输出、还要同时跑语音识别和语音合成。我实测过在一台 16GB 显存的机器上同时跑 7B 模型 + 语音识别 + 语音合成，显存直接爆掉，系统开始用共享内存，token 生成速度从每秒 30 个掉到每秒 4 个，对话体验直接崩了。

更现实的问题是：陪伴类应用的使用场景往往是长时间挂着，用户可能一聊就是半小时。本地满载运行意味着风扇持续高转、笔记本续航腰斩、台式机电费肉眼可见地涨。而如果换成 13B 甚至更大的模型，消费级显卡基本没戏。所以"远程跑大模型"不是偷懒，是把最重的计算负载放到有专业显卡的机器上，本机只负责它擅长的事。

1.2 语音和换装为什么必须留在本机

语音这块，涉及麦克风采集、实时降噪、语音活动检测（VAD）、语音转文本，这些环节对延迟极其敏感。你把音频传到远程、等识别结果传回来，一来一回哪怕只有 200ms，用户说话和界面响应之间就会产生明显的"脱节感"。而且音频流持续上传对带宽也是浪费。本机做语音采集和预处理，只把识别后的文本发给远程模型，这是最合理的分工。

场景换装（也就是根据对话内容切换角色形象、背景、表情）本质上是渲染任务，依赖本机的 GPU 或 CPU 图形能力，而且要和界面刷新同步。放到远程渲染再传视频流回来，延迟和带宽都不可接受。所以换装逻辑必须在本机，远程只负责"告诉本机现在该换什么"。

1.3 这套架构的核心数据流

理清楚分工之后，整个数据流是这样的：

1. 本机麦克风采集音频，本地做 VAD 和降噪
2. 本地语音识别把音频转成文本
3. 文本通过 Web 服务发给远程大模型
4. 远程模型流式返回回复文本
5. 本机拿到文本，一边做语音合成播放，一边解析文本里的场景指令
6. 本机根据指令切换形象和背景

这个链路里，只有第 3、4 步走网络，而且走的是纯文本，数据量小、延迟可控。下面逐个环节拆开讲。

2. 远程大模型服务的搭建与接口设计

2.1 模型选择：不是越大越好

远程跑模型，第一个决策是选哪个模型。我的建议是分两档：日常对话用 7B 到 14B 的指令微调模型，需要复杂推理或角色扮演深度时再切到更大的模型。原因很简单，陪伴类应用 90% 的对话是闲聊、情绪回应、日常问答，这些任务 7B 模型完全够用，而且响应快。你上一个 70B 模型，首 token 延迟可能就要两三秒，陪伴感反而变差。

选模型时重点看三个指标：中文对话自然度、指令遵循能力、以及是否支持流式输出。中文自然度决定了它说话像不像人，指令遵循决定了它能不能稳定地按格式输出场景指令，流式输出决定了用户体验。我试过几个开源模型，最后日常用的是一个 7B 的中文优化版本，复杂场景再调大模型。

2.2 用 Web 服务把模型包起来

远程模型不能直接暴露原始接口，要用一层 Web 服务封装。我用的是 FastAPI，原因是它原生支持异步和流式响应，写起来干净。核心接口设计成一个流式对话端点：

from fastapi import FastAPI from fastapi.responses import StreamingResponse import json app = FastAPI() async def generate_stream(messages): # 这里对接实际的大模型推理后端 # 逐 token 产出，用 SSE 格式返回 for token in model_stream(messages): yield f"data: {json.dumps({'token': token}, ensure_ascii=False)}\n\n" yield "data: [DONE]\n\n" @app.post("/chat/stream") async def chat_stream(payload: dict): messages = payload.get("messages", []) return StreamingResponse( generate_stream(messages), media_type="text/event-stream" )

这里用 SSE（Server-Sent Events）而不是 WebSocket，是因为对话场景是单向流式返回，SSE 更轻量、更容易穿透各种网络环境、断线重连逻辑也简单。WebSocket 更适合双向实时通信，这里用不上。

2.3 提示词工程：让模型输出可解析的场景指令

这是整个项目里最容易被低估的一环。陪伴应用不只是要模型说话，还要模型在合适的时候"触发换装"。做法是在系统提示词里约定一套轻量标记，让模型在回复里嵌入场景指令。比如：

你是一个陪伴型角色。在回复时，如果场景或情绪发生变化， 请在回复末尾用 [SCENE:场景名] 的格式标注，例如 [SCENE:咖啡厅]。 可选场景：卧室、咖啡厅、公园、雨天窗边、夜晚星空。

模型输出就会变成"今天有点累呢……[SCENE:卧室]"。本机拿到文本后，用正则把标记提取出来，剩下的纯文本送去语音合成，标记用来触发换装。这样做的好处是模型和渲染完全解耦，换装逻辑不需要模型知道任何渲染细节。

注意：标记格式一定要选模型不容易自然生成的符号组合，方括号加全大写关键词是比较稳的选择。我一开始用圆括号，结果模型在正常对话里也经常用括号，误触发了好几次。

2.4 上下文管理：别让对话历史无限膨胀

陪伴应用是长对话，如果不做上下文管理，token 消耗会线性增长，延迟也会越来越大。我的做法是滑动窗口加摘要：保留最近 N 轮完整对话，更早的对话压缩成一段摘要放在系统提示词里。N 取 10 到 15 轮比较合适，再多了模型注意力也会分散。

摘要的生成可以异步做，不阻塞主对话。具体就是当对话轮数超过阈值时，后台起一个任务把最老的几轮丢给模型总结成两三句话，然后替换掉原始记录。这样既保留了长期记忆的感觉，又控制了上下文长度。

3. 本机语音链路的完整实现

3.1 语音采集与活动检测

本机语音的第一步是采集。浏览器端用 Web Audio API，桌面端可以用系统音频接口。关键是要做语音活动检测，也就是判断用户什么时候开始说话、什么时候说完。不做 VAD 的话，要么一直录音浪费资源，要么靠按钮控制，体验很差。

VAD 我用的是基于能量的简单方案加一个静音计时器：音量超过阈值开始记录，连续静音超过 800ms 认为一句话结束。这个方案实现简单、延迟低，对大多数场景够用。如果环境噪音大，可以叠加一个轻量的神经网络 VAD 模型，但会增加一点延迟，看你的取舍。

// 浏览器端基于 AudioWorklet 的采集示意 const threshold = 0.02; let silenceFrames = 0; const SILENCE_LIMIT = 48; // 约 800ms function processAudio(samples) { const energy = samples.reduce((s, v) => s + v * v, 0) / samples.length; if (energy > threshold) { silenceFrames = 0; recording = true; buffer.push(...samples); } else if (recording) { silenceFrames++; buffer.push(...samples); if (silenceFrames > SILENCE_LIMIT) { onUtteranceEnd(buffer); // 一句话结束，送去识别 buffer = []; recording = false; } } }

3.2 语音识别：本地还是远程

语音识别有两个选择：本地模型或远程接口。本地模型的好处是隐私好、无网络依赖，坏处是占资源、中文方言支持参差。远程接口识别准、支持方言，但有网络延迟和隐私顾虑。

我的折中方案是：默认用本地识别模型处理常规对话，识别置信度低的时候再走远程接口兜底。本地模型选一个轻量的中文识别模型，几百 MB 那种，CPU 就能跑，延迟在几百毫秒内。这样大部分对话不出本机，隐私和速度都兼顾了。

3.3 语音合成：让角色有稳定的声音

语音合成这块，选择比识别更多。系统自带的语音包最省事，比如 Windows 上的 SAPI 语音，中文语音包质量这几年提升明显，延迟极低，直接调用就行。缺点是音色选择少、情感表达弱。

想要更好的效果，可以用神经网络语音合成模型，音色自然、支持情感，但需要一定的算力。我的做法是双轨：日常对话用系统语音包保证低延迟，角色需要表达强烈情感（比如开心、难过）时切换到神经网络合成。切换逻辑根据模型返回文本里的情绪标记来触发。

import pyttsx3 engine = pyttsx3.init() # 选择中文语音 voices = engine.getProperty('voices') for v in voices: if 'chinese' in v.name.lower() or 'zh' in v.id.lower(): engine.setProperty('voice', v.id) break engine.setProperty('rate', 180) # 语速 engine.setProperty('volume', 0.9) # 音量 engine.say("今天过得怎么样呀") engine.runAndWait()

提示：语速别设太快，陪伴类应用语速 170 到 190 比较自然，太快会显得急躁，太慢又显得迟钝。这个参数值得花时间调。

3.4 打断处理：让对话像真人

真人对话是可以打断的。用户不等角色说完就开口，应用应该立刻停止播放、开始录音。实现上就是在播放语音的同时保持 VAD 监听，一旦检测到用户说话，立即调用播放器的停止方法，并清空待播放队列。这个细节做好了，陪伴感会提升一大截，做不好就会显得很"机器"。

4. 场景换装的触发机制与渲染

4.1 场景资源的组织方式

换装本质上是切换资源。我建议把每个场景做成一个独立配置，包含背景图、角色立绘、可选的背景音乐、以及环境音效。用一个 JSON 描述：

{ "bedroom": { "background": "assets/bg_bedroom.webp", "character": "assets/char_default.webp", "bgm": "assets/bgm_calm.mp3", "ambient": "assets/ambient_room.mp3" }, "cafe": { "background": "assets/bg_cafe.webp", "character": "assets/char_smile.webp", "bgm": "assets/bgm_lively.mp3", "ambient": "assets/ambient_cafe.mp3" } }

这样新增场景只需要加配置和资源，不用改代码。资源格式优先用 WebP，体积比 PNG 小很多，加载快。

4.2 从模型输出到场景切换的解析链路

前面提到模型会在回复里嵌入[SCENE:场景名]标记。本机拿到流式文本后，需要一个增量解析器，因为标记可能跨多个数据块到达。简单做法是先把完整回复拼起来再解析，但这样要等模型说完才能换装，延迟大。更好的做法是边收边解析，用一个缓冲区检测是否出现完整的标记。

import re SCENE_PATTERN = re.compile(r'\[SCENE:([^\]]+)\]') class SceneParser: def __init__(self): self.buffer = "" self.clean_text = "" def feed(self, chunk): self.buffer += chunk # 提取已完成的场景标记 scenes = SCENE_PATTERN.findall(self.buffer) # 移除标记后的纯文本用于语音合成 self.clean_text = SCENE_PATTERN.sub('', self.buffer) return scenes

实际使用时要处理标记被拆散的情况，比如[SCE和NE:卧室]分两次到达。我的做法是检测到左方括号时先缓存，等右方括号出现再整体解析，超时没等到就当作普通文本处理。

4.3 换装动画与过渡

直接硬切背景会很突兀。加一个 300ms 的淡入淡出过渡，观感会好很多。实现上就是两层图层，新场景先加载好放在底层，然后上层透明度从 1 渐变到 0。角色立绘的切换同理，如果角色表情变化，可以用简单的交叉淡化。

如果要做更精细的效果，比如角色从站立到坐下的动作过渡，那就需要序列帧或者骨骼动画了，成本会高不少。我的建议是先用静态立绘加淡入淡出跑通全流程，有精力再升级动画。

4.4 场景切换的时机控制

不是模型一输出标记就立刻切。要考虑语音播放的进度，最好让场景切换和语音内容对齐。比如模型说"我们到公园吧 [SCENE:公园]"，理想效果是说到"公园"的时候画面刚好切过去。实现上可以把场景切换排进一个和语音播放同步的时间队列，根据标记在文本中的位置估算触发时间。

5. 远程与本机的通信协议设计

5.1 为什么选 HTTP 流式而不是长连接

前面提到用 SSE，这里展开说下理由。陪伴应用的通信模式是"用户说一句，模型回一段"，是典型的请求-响应模式，只是响应是流式的。HTTP 流式天然契合这个模式，而且实现简单、调试方便、对网络环境要求低。长连接（WebSocket）适合双向高频通信，比如实时游戏，这里用不上，反而增加了连接管理的复杂度。

5.2 消息格式与错误处理

请求体用 JSON，包含对话历史和当前用户输入。响应是 SSE 流，每个事件是一个 token 或一个控制指令。错误处理要分两类：网络错误和模型错误。网络错误要支持自动重试，模型错误要把友好提示返回给用户而不是抛异常。

async function streamChat(messages, onToken, onScene) { const resp = await fetch('/chat/stream', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ messages }) }); const reader = resp.body.getReader(); const decoder = new TextDecoder(); let buffer = ''; while (true) { const { done, value } = await reader.read(); if (done) break; buffer += decoder.decode(value, { stream: true }); const lines = buffer.split('\n\n'); buffer = lines.pop(); for (const line of lines) { if (!line.startsWith('data: ')) continue; const data = line.slice(6); if (data === '[DONE]') return; const parsed = JSON.parse(data); if (parsed.token) onToken(parsed.token); if (parsed.scene) onScene(parsed.scene); } } }

5.3 断线重连与状态恢复

网络不可能永远稳定。断线后要能恢复，关键是保存对话状态。我的做法是每次请求前把当前对话历史存到本地，断线重连时带上历史重新请求。如果模型已经生成了一部分，重连后可能会重复，这时候可以用一个请求 ID 让服务端做去重，或者简单点，重连后重新生成，用户感知上就是"重新说了一遍"。

6. 实测中踩过的坑与性能调优

6.1 首 token 延迟是体验杀手

用户说完话到角色开口，这个间隔超过 1.5 秒就会明显感觉卡。优化手段有几个：一是模型侧开启流式输出，让第一个 token 尽快出来；二是语音合成也做流式，拿到前几个字就开始合成播放，不用等整句；三是本机的 VAD 结束判定别设太长，800ms 是个平衡点。我实测下来，这套组合能把感知延迟压到 1 秒以内。

6.2 语音和换装的资源竞争

本机同时做语音合成和场景渲染，如果都吃 GPU，会互相抢资源。我的做法是语音合成尽量走 CPU，把 GPU 留给渲染。如果语音合成必须用 GPU，那就把渲染降帧，陪伴应用的背景渲染其实不需要 60 帧，30 帧完全够看。

6.3 内存泄漏的排查

长时间运行的应用最怕内存泄漏。我遇到过音频缓冲区没释放导致内存持续增长的问题，表现是跑几个小时后应用变卡。排查方法是用浏览器的性能面板或者系统的内存监控，观察内存曲线是否持续上升。定位到是音频 buffer 数组只 push 不清理，加了定期清理逻辑后解决。这类问题在陪伴应用里特别重要，因为用户会长时间挂着。

6.4 场景资源的预加载

换装如果等切换时才加载资源，会有明显卡顿。做法是预加载：应用启动时加载常用场景，对话过程中根据上下文预测可能要用的场景提前加载。比如模型提到"下雨"，就提前把"雨天窗边"场景加载好。这个预测不需要很准，多加载几个也无所谓，资源不大。

7. 一些关于扩展方向的个人经验

这套架构跑通之后，扩展空间其实很大。我后来加了一个"记忆"模块，把用户提到的重要信息（名字、喜好、最近发生的事）存到本地数据库，每次对话时检索相关记忆注入提示词，角色就能记住用户说过的话，陪伴感提升非常明显。这个模块完全在本机，不涉及远程，隐私也放心。

另一个方向是情绪识别。本机分析用户语音的音高、语速、能量，粗略判断情绪状态，然后把这个状态作为提示词的一部分发给模型，让角色的回应更贴合用户情绪。这个不需要很准，哪怕只有 60% 的准确率，也能让对话更有温度。

最后说个务实的建议：别一上来就追求完美。先把"能对话、有声音、能换装"这条最小链路跑通，哪怕场景只有两个、语音用系统自带的，跑通之后再逐个环节优化。我见过太多人卡在选模型、调音色上，结果整个项目一直没跑起来。先让它动起来，再让它好起来。