红星智政：数字人开口之后，系统才刚刚开始

最开始看到数字人跟随语音张嘴时，我以为画面生成会是整个项目里最难的部分。

真正把系统串起来之后，我才发现，数字人能开口只是最显眼的一环。语音有没有被正确识别，知识库找到了什么，模型是否根据材料回答，音频能不能被下一模块读取，页面有没有告诉用户系统正在处理，这些看不见的连接才决定了体验是否成立。

“红星智政”面向党建宣传、政策解读、政务咨询和基层服务等场景。它让我第一次比较完整地接触语音、知识库、大语言模型、数字人驱动与 Web 交互的系统集成。

一次提问要走过七个环节

从用户说出问题，到数字人给出回答，请求大致经历以下路径：

知识库使用数据库与 FAISS 向量索引组织内容。这里并不是把文档塞进去就结束了，文本如何切分、向量怎样生成、返回多少片段、上下文按什么顺序交给模型，都会改变最终回答。

单独测试语音识别时，它能返回文字；单独调用模型时，它也能生成答案。但把模块连成一条链路后，新的问题会从连接处冒出来。

模型首次加载需要等待，音频模块要求特定格式，路径在不同系统下表现不同，接口返回字段稍有变化就会让前端取不到数据。数字人视频生成时间较长时，页面如果没有状态反馈，用户只会看到一个像是卡死的按钮。

我后来不再盯着最终页面猜问题，而是给每个阶段保留可验证的输入与输出：

这样做以后，一次“没有反应”就能被拆成更小的问题。它可能发生在输入、检索、生成、合成或展示，而不是一句模糊的“数字人坏了”。

政务服务场景不能只追求语言自然。模型说得流畅，却没有可靠依据，反而会放大风险。

因此，RAG 的价值不是给系统增加一个热门名词，而是让回答尽量回到经过整理的材料上。后续仍需要完善资料更新、来源展示、无法回答时的边界提示，以及对敏感问题的处理方式。

我为项目选择了偏暗红色的服务大屏风格，但视觉风格只是表面。更重要的是让用户知道当前发生了什么：麦克风是否工作，系统是否正在检索，回答是否生成，视频还需要等待多久，失败后应该怎样重试。

如果页面只展示一个数字人窗口，后台再完整的链路也很难被理解。交互状态、错误提示、信息层级和文字可读性，都应该从一开始就进入系统设计。

人工智能应用开发不是把多个模型名称写进架构图。真正的工作发生在模块边界、数据流、异常处理、资源消耗和部署环境里。

下一步，我希望继续改进检索质量、对话状态与流式反馈，也想探索更实时的语音和多模态交互。但无论增加什么模块，我都会先问一句：它解决了用户链路中的哪个具体问题？