前面在做一个面向展厅和线上客服的虚拟人项目，需要让一个数字人在网页上开口说话、对口型、做简单动作。最初想得比较复杂，打算上完整的实时对话链路，结果把大量时间耗在了对接、调参和排队等审核上。后来退回一步，先把“虚拟人简单交互”跑通，也就是：输入一段文本，虚拟人开口播报，口型基本对上，表情和头部动作跟着走。这个思路反而很快定型，后面所有复杂功能都在这套骨架上迭代。
这篇就把这套最简单的讯飞虚拟人交互实现完整拆开，覆盖选型思路、鉴权细节、参数换乘、音频合成、流式展示和常见问题排查。整个过程不依赖自建推理服务器，也不要求复杂的神经网络知识，适合已经有基础 Web 开发经验、又不想从零折腾数字人的团队参考。
1. 先把需求定清楚：你要的虚拟人交互到底是什么
“虚拟人交互”这几个字在市面上意义太多了。有的产品主打实时语音对话，有的主打数字人视频生成，有的主打直播间7x24小时带货。但讯飞开放平台上的虚拟人相关能力，更适合先理解成“按文本/音频驱动数字人播报”。也就是说，你给它一段话，它能把这段话用预设形象说出来，口型、表情、头部动作基本自然。这个定位决定了后面的技术路线和参数调优方向。
1.1 标题背后的真实需求和能力边界
标题叫“简单交互实现”，我理解的核心需求有三条。
第一，输入要简单。最好能直接给文本，平台后台完成语音合成和动作驱动，而不是自己先合成本地音频再传文件。讯飞的接口恰好支持文本直接进，这大大降低了门槛。
第二，展示要轻量。虚拟人不能只生成一个离线视频文件，最好能实时播放在网页或客户端里。这就涉及流式返回或预生成后快速播放的问题，也和费用、延迟强相关。
第三，交互要能接力。不是只有单向播报，最好播完后能回调，能串联下一句，能根据用户输入切换内容。这决定了接口的响应格式里必须带任务ID和状态，也必须支持查询和中断。
这里要强调一下容易误解的地方：讯飞的虚拟人交互能力，并不是把一套完整的对话管理（如意图识别、多轮状态机）都给你解决了。语音合成、形象渲染、口型驱动是它擅长并且直接封装好的部分，但“先理解用户说什么、再决定虚拟人回什么”这部分，仍然需要你自己的业务系统或第三方对话引擎来完成。所以，技术架构上建议拆成三层：
- 交互层：你的页面/客户端，负责收集用户输入和展示虚拟人画面。
- 逻辑层：你的服务端，负责拦截用户输入、调用对话引擎或规则脚本生成回复文本，再决定是否调用虚拟人生成接口。
- 渲染层：讯飞虚拟人服务，负责把回复文本变成带动作、带口型的音视频流。
把这三层分清楚，你就不会把“简单的虚拟人播报”误认为“完整的虚拟人智能体”。
1.2 哪些团队适合直接这么干
我自己遇到过两种情况，一种是团队里全是后端和前端，没有算法工程师，也没有渲染引擎经验；另一种是已经有现成的语音机器人，只想加一张数字人皮。
这两种情况都适合“讯飞虚拟人简单交互实现”这种轻量路线。因为它把最重的两块——声音合成和形象渲染——都收敛到了云API，本地只需要会拼请求、传参数和播放返回流。至于自研3D形象、自研口型驱动、自研表情动作等，那是另一个量级的工作，至少需要熟悉图形学、运动合成和实时渲染的团队，不适合快速验证。
所以如果你也属于“想评估数字人到底能不能用在业务里、但不想一开始就投入重兵”的阶段，这套方案是一个比较理性的起点。
2. 快速搞清讯飞虚拟人交互的三种接入方式
讯飞开放平台上，虚拟人相关能力其实有不止一套接口。最常被提到的包括虚拟人视频合成、虚拟人实时交互、以及配合语音合成使用的形象渲染。它们的侧重点差异很大，入门时一定先分清楚，否则对接文档容易看乱。
2.1 离线和在线两种主要路径对比
离线路径的逻辑是：提交一段文本或音频，等待一段时间，平台渲染出一个完整的视频文件，你再下载播放。这种方式的优点是画质稳定、表现力强，适合短视频制作、广告片、离线课件；缺点是延迟高（一般几秒到几十秒），而且通常不适合做实时对话。
在线路径的逻辑是：提交文本或音频后，平台通过流式或准实时方式返回音频流、动作数据或视频流，播放端同步渲染数字人。这种方式的优点是延迟低，适合客服、展厅引导、在线教学等需要“你问我答”的场景；缺点是画质可能受网络带宽影响，同时接口调用频次和并发设计要更小心。
如果你看到“虚拟人交互”这个字眼，智能程度和实时性通常比离线合成要高，但也要确认返回的是“音视频流”还是“动作数据+音频数据”。前者播放简单，后者需要配合客户端渲染引擎。这两者的开发量差三到五倍。
2.2 我最终选择的方案及原因
我自己最终选择的是在线路径里的“文本驱动+流式返回”方案——把文本丢给接口，接口返回可播放的媒体流以及动作驱动信息，网页端用一个视频播放器直接呈现。选这个方案的核心原因是：
- 不需要在客户端集成复杂的渲染SDK，部署门槛低。
- 延迟处在可接受的范围内，一般从发起请求到首屏有画面能控制在2秒左右。
- 接口返回的数据结构比较规整，后续如果要接入“先理解后播报”的对话逻辑，只需在服务端替换文本来源，不会动到展示链路。
当然，这里要说清楚，不同账号、不同套餐可能看到的接口名称和参数不完全一致。有的是老版虚拟人合成，有的是新版数字人交互，有的还区分普通话、多语种或特定形象。所以不要死记接口名，要理解两类核心差异：是异步任务还是同步流式，是纯视频返回还是音视频分离返回。理解了这两点，接哪版都能快速上手。
3. 核心参数与鉴权细节解析
无论是哪个版本的交互接口，最核心的两件事都躲不开：一是鉴权怎么过，二是参数怎么填。很多刚接触的开发者以为难在形象驱动，其实大部分时间都耗在鉴权签名和参数调试上。
3.1 鉴权方式与签名生成
讯飞开放平台的老牌鉴权方式是HMAC-SHA256签名。你需要准备三个东西：APPID、APIKey、APISecret。这三个都能在控制台的应用管理里找到。签名生成流程不复杂，但每一步都有坑：
- 拼接鉴权字符串。一般是请求方法（GET/POST）+ 请求路径（如 /v3/virtualhuman/chat）+ 当前UTC时间（格式要求严格）。
- 用APISecret作为密钥，对拼接结果做HMAC-SHA256，得到签名。
- 把签名、APIKey、时间戳、APPID拼成鉴权头，放进请求头或URL里。
举一个实际可参考的思路：
import base64 import hashlib import hmac import time api_key = "your_api_key" api_secret = "your_api_secret" host = "your_host" path = "/v3/your_virtual_human_path" # 时间格式需与文档严格一致 utc_time = time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime()) # 鉴权字符串，注意大小写和换行符 signature_origin = f"host: {host}\ndate: {utc_time}\nrequest-line: POST {path} HTTP/1.1" # HMAC-SHA256 签名 signature = hmac.new(api_secret.encode("utf-8"), signature_origin.encode("utf-8"), digestmod=hashlib.sha256).digest() signature_encoded = base64.b64encode(signature).decode("utf-8") authorization = (f'api_key="{api_key}", algorithm="hmac-sha256", ' f'headers="host date request-line", ' f'signature="{signature_encoded}"')注意点在于：
- UTC时间不能省，不能直接用自己的本地时间。一个团队曾因为时区差8小时卡了整整半天。
- host和path必须和实际请求完全一致，尤其是path里如果有版本号，写错一个单词签名就无效。
- 鉴权头里的headers声明要和你真正参与签名的字段一致。声明了三个，签名拼接里就必须包含三个。
我在实际调试中遇到最隐蔽的问题是：本地测试用http，线上用了https，虽然不影响签名，但某些网关为了安全会禁止非标准端口或强制重定向，导致鉴权头被丢弃。所以建议一开始就统一协议。
3.2 交互请求参数与每个字段的深意
请求参数这块，不同接口差异很大，但有几类参数基本绕不开。
一是形象参数。一般有虚拟人ID或形象ID，决定你用哪个预设形象。默认可选的形象通常有编号或名称，但要注意，某些形象支持的声音范围是固定的，某些声音又只能配特定形象。如果选了不匹配的组合，接口可能报错，也可能默默降级。
二是声音参数。包括音色、语速、音量、音调。语速一般建议先设成1.0，也就是不加速不减速。如果设成1.2以上，口型驱动的匹配度会下降，因为虚拟人的口型模型是按常规语速训练的。音调也不要随便调太高，否则声音容易发尖，和形象气质不匹配。
三是文本内容参数。这里最关键的是文本长度限制。不是说你把一大段文章丢进去一定会失败，而是超长文本可能触发分段限制或者异步模式，响应结构就变了。所以更稳妥的做法是，服务端先对文本做长度预检，超过阈值就切成多句，逐句驱动虚拟人播报，而不是一次性提交。
四是交互ID或任务ID。有些接口允许你传入自定义会话ID，用来关联上下文或做断点续播。强烈建议你生成会话ID时使用统一的规则，比如session_加用户ID加时间戳，方便后续排查请求链路。
五是返回格式参数。有的接口支持选择返回纯音频、音频加动作、或视频流。初学者最容易忽略这个，以为返回的就是视频。实际上，如果你选了“音频加动作数据”，客户端又没有对应的渲染插件，画面就是黑的，声音却是正常的。这个排查过程很容易让人误判是鉴权问题。
3.3 说一个容易被忽略的“并发和配额”问题
鉴权和参数都正确后，另一个隐形约束是并发数。讯飞这类云平台通常不会让你无限并发，账号下的虚拟人服务有默认的QPS限制。如果你在业务高峰期同时发起几十路请求，就会触发限流。
我自己的习惯是：在服务端加一个本地信号量或队列，同一时刻最多保持2个虚拟人交互任务在途；其他请求排队等待。这样虽然牺牲了一点并发吞吐，但大大降低了被限流的概率。对“展厅里同时只有一两个访客操作”这类场景，2个并发完全够用。
另一个隐蔽的配额是“音频合成时长”。有的套餐不是按调用次数计费，而是按合成的音频时长计费。你调了100次接口，每次只合成1秒，费用不高；但如果一次合成30秒，费用会明显上升。所以从省钱角度，也要控制单次文本长度。
4. 实操过程：从文本输入到虚拟人开口的完整链路
这部分把完整的调用流程串起来，按实际项目中的操作顺序来讲。
4.1 第一步：准备账号、创建应用并领取资源
先到讯飞开放平台控制台注册账号，然后在“我的应用”里创建一个新应用。创建后会生成APPID、APIKey、APISecret。接着找到虚拟人相关产品页，领取试用套餐或购买正式资源。注意，部分虚拟人交互能力不是默认开通的，需要单独申请开通，审核周期有的快有的慢。
开通后建议先下载官方SDK或参考文档里的示例代码，先用示例跑通一次，确认账号下确实有可用的虚拟人调用权限。这一步别看简单，能过滤掉一大半“我对接不上”的问题——很多是账号没开通或套餐过期导致的。
4.2 第二步：准备音频或直接提交文本
接下来你要决定：到底是直接传文本，还是本地先生成音频再传音频。两种方式的效果有微妙区别。
- 直接传文本：虚拟人服务内置的语音合成模块自己生成音频，再驱动口型。优点是链路短，你只管业务文案；缺点是声音风格受限，只能选平台提供的音色。
- 本地合成音频再传入：你使用讯飞语音合成或其他合成工具，生成质量更好或者更符合预期的音频文件，再作为虚拟人接口的输入。优点是音色可控，甚至支持自定义录音音色；缺点是要自己维护音频文件生成和上传逻辑，且音频编码格式要求严格。
“简单交互”阶段，我推荐优先用直接传文本。你只要把注意力放在文案和接口参数上，形成和口型的匹配由平台负责，省掉中间环节。若后续要做品牌定制音色，再迁到方案二。
4.3 第三步：组装请求并处理好鉴权头
组装请求时，除了前面说的鉴权签名，还要注意请求头的Content-Type，一般要求是application/json，不要传成application/x-www-form-urlencoded。有的接口还需要在URL里带上query参数，比如鉴权参数本身。
推荐把这部分做成一个独立的服务端模块，不放在浏览器里。原因有两个：一是密钥不能暴露在浏览器端，否则任何人拿到都能刷爆你的额度；二是签名逻辑跨语言复用时问题很多，集中管理便于替换密钥和升级算法。
参考的Python服务端伪代码结构：
import json import requests def build_headers(api_key, api_secret, host, path, body): # 生成鉴权头，返回完整header字典 pass def send_virtual_human_request(text, session_id): url = "https://your_host" + "/v3/your_path" body = { "session_id": session_id, "text": text, "voice": "default_voice", "virtual_human": "default_human", "speed": 1.0, "volume": 50, "return_type": "video_stream" } headers = build_headers(...) resp = requests.post(url, json=body, headers=headers, stream=True, timeout=15) return resp这里把stream设为True很重要，因为虚拟人接口返回的往往是流式数据，你不开启流式接收，可能等所有数据完整后才拿到，体验大打折扣。timeout也不能设太短，有些任务首次调用需要冷启动，可能要5到10秒。
4.4 第四步：解析响应，拿到可播放的媒体流
响应解析是环节里最杂的一步，因为不同接口返回结构差异大。一种常见结构是：最外层JSON，内含code、message、data，data内含taskId、status、audioUrl或videoUrl。另一种是直接返回二进制流，需要用播放器直接解码。
如果你拿到的是URL，那较稳妥的做法是：先下载或重定向到临时文件，再用播放器加载；不要直接把URL写给前端播放器，因为有些URL带签名、有时效，且受CORS限制。
如果你拿到的是分片数据，比如音频pcm小块+动作参数块，那就要在客户端做拼接。这种形态虽然开发量更大，但能实现更低延迟，因为不需要等服务端全部生成完毕。
在“简单交互”阶段，最省心的还是让服务端把流收完，再暴露一个稳定的HTTP地址给前端播放。代价是延迟会高一点，但排查起来方便，也不容易受断流影响。
4.5 第五步：前端播放与场景衔接
前端播放虚拟人画面，本质上是播放一段视频或动画流。最常见的做法是用Video标签，把服务端返回的流地址或临时文件地址塞进src。另一种做法是使用WebGL播放器配合动作数据渲染，但这种对前端团队能力要求较高，不是“简单交互”的首选。
我用过的较稳的前端方案是：
<video id="virtual-human-player" width="720" height="1280" autoplay muted playsinline></video>注意几个细节：
- muted属性要设，否则浏览器自动播放策略会拦截有声视频。你可以默认muted，待用户点击“开启声音”后再取消muted。
- playsinline在iOS上很重要，否则播放器会强制全屏，体验很割裂。
- autoplay配合muted，才能做到进页面后虚拟人主动开口，而不需要用户先点一下。
如果不想直接暴露后台视频流地址，你还可以在后端用Nginx或对象存储中转一下，临时代理一个路径给前端。这样即使视频URL过期，也能在代理层重新换取。
4.6 一句话总结完整闭环
从用户角度看，整个闭环就是：页面输入一句话 -> 服务端接收并组装文本 -> 请求讯飞虚拟人服务 -> 拿到媒体流 -> 前端Video播放 -> 虚拟人口型动作与音频同步。一旦这条链路跑通，后续增加“语音识别输入”和“对话引擎生成回复”就是在它前面再接两层的问题。
5. 交互设计：让虚拟人表现得像“活着”而不是“播放器”
实现基础播报不难，难在让用户觉得有交互感。单纯放一段视频，那不是交互。要让虚拟人在对话场景里显得自然，要在几个体验节点上做设计。
5.1 回应动作与过渡状态
虚拟人开始说话前，最好有一小段“准备”表现，比如轻微点头或看向镜头。这个功能往往不是靠额外接口实现的，而是靠前端控制播放时机来实现。比如在调用服务端接口时，先把虚拟人画面切到一个待机动画（可以是一个静默短视频循环），等返回真正的播报流后，再无缝切换。
我在项目中是这样处理的：准备两路播放源，一路是无声待机动画，一路是交互播报流。默认播放待机动画，当新文本请求发出时，保持待机画面不变；等服务端返回可播放地址后，再快速切换。用户看起来就是虚拟人顿了一下，然后开始说话，不会看到黑屏或加载转圈。
5.2 会话关联：支持多轮追问
要让虚拟人支持“上一句问完，再问下一句”这种多轮体验，不一定要依赖复杂的记忆系统。最简单的方式是：前端记录完整的问答历史，每次请求时把最近几轮文本拼到Prompt里，或作为会话上下文传给你的对话引擎。虚拟人接口本身不负责记忆，它只负责“把当前要播报的文本播出来”。
所以，会话ID虽然可以保证链路可追踪，但真正的内容记忆还要自己在业务层维护。我踩过这个坑，以为传同一个session_id，虚拟人就能记得之前说过什么，实际上并不是。这一点在与业务方沟通时要特别讲清楚，避免需求错位。
5.3 打断与快速切换：用户说了新的话怎么办
真实交互中，用户经常会在虚拟人还没说完时就提问。如果此时还让它按原有节奏播报，体验会很差。实现“打断”不需要复杂算法，做法是：前端把当前播放器暂停或清空，然后立刻发起新请求；服务端也把上一轮的流式请求取消或忽略，不再消费其返回数据。
但要注意配额浪费：如果你把请求发出去了，平台已经在合成音频，即使你前端不要了，费用照扣。所以，更合理的做法是前端加防抖——比如用户停顿1.5秒后再真正发起虚拟人请求，而不是每输入一个字符就触发一次。另外可以在服务端引入类似“当前任务优先级”的机制：当新请求到达时，直接覆盖未开始或已开始的任务。
5.4 字幕与提词增强可用性
展厅嘈杂环境里，光靠虚拟人说话，用户可能听不清。加字幕不只是辅助，更是刚需。而且字幕是前端自己根据提交的文本渲染的，不需要等接口返回，所以几乎零成本。
我通常把字幕设计在虚拟人画面下方，字体偏大，高对比度，支持关键词高亮。这样哪怕虚拟人用的是普通音色，用户也能通过字幕快速获取信息。这个细节往往被忽略，但在实际展厅落地时非常加分。
6. 常见问题与排查技巧实录
做这类平台对接，几乎每一个环节都有可预见的坑。下面按我实际遇到的高频问题整理出来，方便你排查时对照。
6.1 鉴权报错：错误码来回变
症状：请求返回鉴权失败，错误码可能是11200、11201、11202等。
排查步骤：
- 第一，确认服务端时间和你本机时间是否一致，偏差太大时密钥会失效。
- 第二，确认拼接签名用的path和实际请求path完全一致。比如文档里写
/v3/virtualhuman/chat，你不能简化成/virtualhuman/chat。 - 第三，确认APIKey和APISecret没有复制错空格。控制台里的密钥复制出来经常带看不见的换行符，最好先粘贴到纯文本编辑器里检查。
- 第四，不要用GET请求去请求签名里声明为POST的接口，反之也一样。
- 第五，确认你没有把密钥写在浏览器请求里。如果前端直接调用，服务端签名的随机性和浏览器CORS都可能引发鉴权异常。
我的个人习惯是，在服务端加一个“签名调试模式”，把参与签名拼接的原始字符串打印出来，只打前几十个字符和长度，方便在加密传参出错时快速定位。
6.2 返回成功但没有画面
症状：接口返回200，代码也显示正常，但前端播放器黑屏，或只有声音没有图像。
排查步骤：
- 检查接口返回的data类型。如果返回的是
audio_url和motion_data，那你不能把它当视频播。你还需要一个前端渲染层来合并音频和动作数据。这不是接口故障，是方案选型错了。 - 检查播放器协议。如果后台返回的是HLS流，但你的Video标签在部分浏览器上不支持HLS，需要额外引入hls.js这类库。
- 检查视频编码。部分虚拟人视频输出的是特定编码格式，直接塞给Video标签可能不兼容。建议先下载到本地用VLC或浏览器直接播放验证。
6.3 口型对不上或声音快于画面
症状：虚拟人嘴在动，但声音和口型节奏差半拍。
排查方向：
- 先排除是网络抖动导致的播放卡顿。可以先把视频下载到本地播放，如果本地没问题，就是流式传输的问题。
- 如果是使用“先本地合成音频再驱动虚拟人”的方案，检查音频采样率和编码是否在接口要求范围。不匹配时，平台可能做了重采样，音画就会漂移。
- 如果用的是直接文本方案，检查是不是语速参数调太高。语速超过1.2后，口型适配难度加大，建议调回1.0左右测试。
- 某些接口还支持
sync_mode参数，改成“音画同步优先”而不是“低延迟优先”，可缓解轻微漂移。
6.4 页面播放自动被浏览器拦截
症状：Video标签设置了autoplay，但进入页面后不播，要用户点击才开始。
原因：浏览器自动播放策略限制的是“有声视频”。你设置muted后播放，再在用户交互时打开声音，基本都能绕过拦截。另外还需确认，在用户交互回调里再调用播放器.play()，而不是在页面初始化时异步调用。
6.5 并发一高就开始偶发失败
症状：单路测试正常，但压测时偶发超时或限流错误。
排查方向：
- 检查账号的QPS限制。如果是2QPS，就控制同时处理的虚拟人任务数。
- 检查是否在同一时刻对同一形象进行多次冷启动。有些形象首次加载需要额外时间，建议业务低峰期预热一次。
- 为流式请求设置合理的超时时间，并为超时任务做好退避重试。但要避免无限重试，否则限流会更严重。
- 把请求日志按session_id串起来，方便复盘是哪一步耗时最长。
6.6 成本“悄悄”超支
症状：月末发现费用远高于预估。
原因：虚拟人报价往往与合成时长或调用次数相关。有些团队在循环里没加节流，前端每帧都触发文本上报，导致服务端疯狂调用接口。解决办法是前端增加防抖和请求合并，服务端增加单用户并发拦截，并记录每次调用的输入文本长度，方便成本审计。
7. 进一步的花样：让虚拟人更“可用”的进阶技巧
当“简单交互”稳定后，自然要往上加东西。我做过几个低成本且高感知的增强，分享给你。
7.1 接入语音识别实现“开口说话”
在虚拟人播报前加一层语音识别，用户说完话自动转文字，再通过对话引擎生成回复，最后虚拟人开口。这等于把“虚拟人播报”扩展为“语音对话”。
语音识别可以直接用讯飞语音听写接口，也可以接浏览器原生的SpeechRecognition。前端把识别文本发送给服务端，服务端经过敏感词过滤和回复生成后，再走虚拟人链路。这里要加一个状态机：识别中、生成回复中、播报中、空闲。不同状态下，虚拟人的表现要不一样，否则用户会困惑。
7.2 表情和动作的个性化控制
部分接口支持通过参数控制虚拟人的情绪或动作ID。比如设置“开心”“严肃”“惊讶”等情绪标签，虚拟人脸部和肢体会有相应变化。这个功能影响比较明显，但不要每句话都换情绪，那样反而像抽风。推荐策略是：按对话场景固定情绪模板，比如客服场景固定“温和耐心”，教学场景固定“认真专注”。
7.3 与业务系统的“异步播报”结合
如果你的业务流程较长，比如查库存、查订单、计算时间，不可能等结果出来再让虚拟人开口。建议把虚拟人播报改成“先播报一句引导语再说结果”。比如“好的，正在为您查询库存，请稍等”，这句可以在查询发出时立刻播报，等真正结果出来后，再用第二句播报结果。这种两段式播报在体验上比一直沉默到结果返回再开口好得多。
实现上非常简单：在业务请求发起时立即调用虚拟人接口播放引导语，在业务回调里再调用虚拟人接口播放结果。注意在第二轮开始时，要中断第一轮，防止两句话重叠。
8. 几点从实操中沉淀的个人体会
我在做完这个讯飞虚拟人简单交互后，最大的感受是：不要把云API想象成万能的，也别低估它封装好的价值。它帮你省掉了自研语音合成、形象建模和口型驱动的巨大工程量，但它不会主动帮你解决业务编排、会话管理和体验设计。真正让虚拟人“活”起来的，往往是外面那层业务逻辑。
有几个决策如果重来一次，我还会坚持：
- 初期坚持文本直接驱动，不碰自研动作数据。
- 鉴权和请求服务端统一封装，不做浏览器直连。
- 前端播放器固定为Video标签加辅助状态机，不上重渲染方案。
- 从第一天就记录任务ID、sessionID和文本长度，方便对账和排查。
最后再分享一个小技巧：虚拟人第一次集成时不建议直接上“实时交互”，先做一个“输入框提交文本 -> 虚拟人开口”的极简Demo，让业务方看到效果。大多数领导或客户对“虚拟人”的预期都比较抽象，只有看到能跑的Demo，需求和优先级才会快速清晰。后面再往这个Demo上叠加语音识别、对话管理、多轮记忆，整个项目的节奏就不会乱。
这套方案最大的优势只有四个字：稳、简、省、快。希望这篇能在你接入讯飞虚拟人时少走几步弯路。
