数字人链路从 0 到精通：新人也能看懂的学习总结

写这篇文章的动机很实际：数字人（Digital Human）这个方向资料多但碎，新人很容易被各种名词（ASR、TTS、Viseme、Blendshape、WebRTC、中之人、MetaHuman）淹没，看了很多文章还是拼不出一张完整的图。

本文的目标：一篇文章讲清楚数字人是什么、整条技术链路怎么跑、每环有哪些坑、新人按什么顺序学。假设读者有基本编程能力，但不要求任何音视频或图形学背景。

1. 先搞清楚：数字人到底是什么

1.1 从元宇宙说起

2021 年「元宇宙（Metaverse）」概念爆火时，有一个被广泛引用的定义：元宇宙是一个持久在线的、可沉浸交互的虚拟世界。热闹过后概念降温，但它留下了几样真正落地的资产：

• 虚拟形象（Avatar）：人在虚拟世界里的「身体」，从游戏捏脸到 Meta 的虚拟人，再到苹果的 Persona。
• 数字身份（Digital Identity）：虚拟世界里的「你是谁」，关联账号、资产、社交关系。
• 实时渲染与交互引擎：Unity、Unreal（含 MetaHuman）、WebGL 这些让虚拟世界「看得见」的技术。
• XR 入口：VR/AR 设备作为进入虚拟世界的「门」。

数字人就是元宇宙沉淀下来最值钱的那部分：一个「有形象、能说话、能交流」的虚拟实体。元宇宙讲的是一个世界，数字人是这个世界里最先实现商业闭环的单元——你不需要一整个虚拟世界，只需要一个能 7x24 小时直播带货、能接客服电话、能当虚拟偶像的数字人，就有客户愿意付钱。

1.2 数字人的三个分类维度

新人最容易混淆的是「数字人」一词涵盖了很多完全不同的技术路线。按三个维度拆开看：

flowchart TB
    DH[数字人] --> A[按形象分]
    DH --> B[按驱动方式分]
    DH --> C[按交互方式分]

    A --> A1[2D 卡通 / Live2D]
    A --> A2[3D 写实<br/>MetaHuman / 捏脸]
    A --> A3[真人形象克隆<br/>照片/视频驱动]

    B --> B1[真人驱动<br/>中之人 + 动捕]
    B --> B2[AI 驱动<br/>文本/语音全自动]
    B --> B3[混合驱动<br/>AI 为主 真人兜底]

    C --> C1[离线内容型<br/>录播视频/短视频]
    C --> C2[实时交互型<br/>对话/直播/客服]

• 形象维度：Live2D 成本最低（一张立绘就能动），3D 写实最重（建模 + 绑定 + 渲染），真人克隆最像真人（用真人的照片或视频训练）。
• 驱动维度：虚拟主播圈常说的「中之人」就是真人在幕后戴动捕设备驱动皮套；AI 驱动则是全自动化，这也是本文的重点。
• 交互维度：离线内容型（批量生成口播视频）对实时性没要求，工程难度低一个量级；实时交互型（你说一句它答一句）才是技术深水区。

典型应用场景对号入座：虚拟主播直播（实时 + 真人/AI 驱动）、AI 客服数字人（实时 + AI 驱动）、短视频口播矩阵（离线 + AI 驱动）、数字分身/数字永生（真人克隆 + 实时）、企业数字员工大屏（实时 + 3D）。

2. 一张图看懂整体链路

数字人系统本质上是把一个真人的沟通能力拆成流水线，每个环节用一个技术组件替代：

flowchart LR
    subgraph 感知["感知（耳朵 + 眼睛）"]
        MIC[麦克风] --> VAD[VAD 语音检测] --> ASR[ASR 语音识别]
        CAM[摄像头] --> VIS[视觉感知<br/>人脸/唇动/表情/手势]
    end

    subgraph 认知["认知（大脑）"]
        ASR --> LLM[LLM 对话引擎<br/>+ RAG + 记忆 + 工具]
        VIS -.情绪/注意力标签.-> LLM
    end

    subgraph 表达["表达（嘴巴 + 脸 + 身体）"]
        LLM --> TTS[TTS 语音合成]
        TTS --> DRIVE[驱动引擎<br/>口型/表情/动作]
        DRIVE --> RENDER[渲染引擎<br/>2D/3D 形象]
    end

    subgraph 传输["传输（神经）"]
        RENDER --> RTC[WebRTC 低延迟推流]
        RTC --> USER([用户屏幕/音箱])
    end

    USER -.用户说话.-> MIC
    USER -.用户在镜头前.-> CAM

记住这个拟人化口诀：耳朵（ASR）听清、眼睛（视觉感知）看懂 → 大脑（LLM）想好 → 嘴巴（TTS）说出 → 脸（口型驱动）对上 → 神经（WebRTC）送达。

整条链路分两大形态：

离线形态是实时形态的子集（少了 ASR 和 RTC，渲染换成离线出片），所以下面重点拆实时链路。

3. 实时交互链路逐环拆解

先看一次完整对话的时序，建立整体感觉：

sequenceDiagram
    participant U as 用户
    participant E as 边缘采集端
    participant A as ASR 服务
    participant L as LLM 服务
    participant T as TTS 服务
    participant D as 驱动+渲染
    participant R as RTC 网络

    U->>E: 说话（语音流）
    E->>E: VAD 检测说话起止
    E->>A: 流式发送音频
    A-->>L: 边说边出识别文本
    L-->>T: 流式输出回答（按句切分）
    T-->>D: 流式合成音频（边收边播）
    D->>D: 音频驱动口型/表情
    D->>R: 音视频帧推流
    R-->>U: 看到听到数字人回答
    Note over U,R: 用户感知延迟 = 最后一个字说完到数字人开口的时间

关键设计原则：每一环都是流式（streaming）的。如果等 LLM 把整段话说完再送 TTS、等 TTS 合成完整段再播放，延迟会叠加到无法接受。流式的含义是「边产生边消费」，像水管一样一环接一环地流。

3.1 耳朵与眼睛：VAD + ASR + 视觉感知

VAD（Voice Activity Detection，语音活动检测）：判断用户什么时候开始说、什么时候说完了。它是交互节奏的总开关——判早了会把用户一句话切成两半，判晚了用户会觉得数字人反应迟钝。

ASR（Automatic Speech Recognition，语音识别）：把语音流实时转成文字。

3.1.1 VAD 到底怎么判断「开始说」和「说完了」

VAD 把音频切成 10-30ms 的小帧，对每一帧打一个「是语音的概率」，然后用状态机做判定：

stateDiagram-v2
    [*] --> 静音
    静音 --> 可能说话: 连续 N 帧概率超阈值
    可能说话 --> 说话中: 确认（防突发噪音）
    可能说话 --> 静音: 概率回落（是咳嗽/关门声）
    说话中 --> 可能结束: 出现连续静音帧
    可能结束 --> 说话中: 重新检测到语音（句中停顿）
    可能结束 --> 静音: 静音持续超 hangover 阈值

算法分三代，了解演进就知道怎么选：

1. 能量 + 过零率：最原始的做法，能量突增判说话。安静机房能用，真实环境（空调声、键盘声）全是误判。
2. 统计模型：代表作是 Google 的 WebRTC VAD（GMM 高斯混合模型），内置 0-3 四档灵敏度，免费、极快，至今仍是很多项目内置的默认项。
3. 神经网络模型：工业主流。开源首选 Silero VAD（几 MB 的 ONNX 模型，CPU 上实时跑，自带 30ms 帧判定）；国内还有阿里的 FSMN-VAD（FunASR 自带）、TEN-VAD。抗噪能力比前代强一个量级。

三个必须知道的工程细节：

• 判起要有「提前量」：VAD 确认「开始说话」需要连续若干帧，如果确认后才把音频送 ASR，句首会被吃掉（「你好，数字人」变成「数字人」）。解法是预滚动缓冲（pre-roll buffer）：始终缓存最近 200-300ms 音频，VAD 触发时把缓冲一并送出。
• 判停（端点检测）是延迟与完整的权衡：静音持续多久算「说完了」，默认 500-800ms。设太短切断用户的长句停顿（「那个……我想问一下」被切成两段），设太长每轮对话白等几百毫秒。
• 语义 VAD 是高阶玩法：不只看静音时长，还结合 ASR 的中间识别结果判断语义是否完整——识别文本还没形成完整句子就延长等待。大模型语音产品（GPT-4o 类）和商用方案普遍在用，纯声学 VAD 容易被「思考停顿」骗过。

3.1.2 流式 ASR：现成 API 还是自己改 Whisper

先说结论：商用快速上线选云 API；数据敏感或量大图便宜选自部署开源方案；改造 Whisper 只适合练手和理解原理，别上生产。

现成 API（WebSocket 流式，接入即用）：

• 国内：阿里云实时语音识别、腾讯云 ASR、讯飞、火山引擎——中文效果好、热词支持完善、按量付费，首字延迟可做到 200-300ms。
• 海外：Deepgram、AssemblyAI、Azure Speech、OpenAI Realtime API。

自部署开源方案：

• FunASR（阿里开源）：Paraformer 流式版，自带 VAD + 标点恢复，中文场景首选，社区活跃。
• sherpa-onnx（k2 团队）：流式 Zipformer/Transducer 模型，跨平台，端侧（手机/嵌入式）都能跑。
• SenseVoice（阿里）：多语言、低延迟，还带情感与事件检测。

Whisper 为什么难办：它原生是离线架构——encoder 要吃 30 秒的音频窗口，天然不是流式模型。三种常见改造路线：

选型对照：

新人要点：

• 选流式 ASR（边说边出字），不要选录音文件识别接口。
• 热词（hotword）功能必须用起来：业务专有名词（产品名、品牌名）通过热词表喂给 ASR，否则识别错误会一直污染下游 LLM。
• AEC（回声消除）：如果数字人的声音从音箱播出来又进麦克风，ASR 会把数字人自己的话识别成用户输入，造成「自己跟自己对话」。用扬声器场景必须开 AEC（WebRTC 自带，自研采集端要接 Speex/WebRTC APM 这类模块）。

3.1.3 眼睛：视觉感知，数字人能不能「看到」用户

只有耳朵的数字人，相当于一个闭着眼打电话的人——能用，但离「像人」差一层。加上摄像头这条通道，感知层才完整。视觉信号在数字人里有六个典型用途：

工程实现分三层，按需取用：

• 端侧轻量模型：人脸检测、唇动、手势这类高频低算力任务放端侧跑（MediaPipe、YOLO 系列、厂商人脸 SDK），只把结论标签上传，不上传原始视频流——省带宽、降延迟、利隐私。
• 云端识别：情绪识别等重模型走云端，按帧抽样的低频调用即可，不要全帧率送云。
• 端到端多模态大模型：GPT-4o、Gemini Live 这类音视频直接进模型的路线，跳过「ASR 转文字」环节，能直接听懂语气、看到画面。这是趋势，但目前成本高、可控性弱（不好接 RAG 和业务约束），商用数字人中台主流仍是「ASR + LLM」模块化架构加视觉辅助信号。

视觉信号进大脑的正确姿势：视觉结果不作为对话内容，而是作为低优先级异步上下文标签注入 LLM——比如 [用户皱眉] [用户看向别处] [检测到 3 位观众]，让人格层决定如何反应（加快语速、主动询问、暂停讲解）。直接把视觉识别文本拼进用户输入会污染对话流，是新人常犯的错误。

合规红线：人脸信息在《个人信息保护法》里属于敏感个人信息，采集需单独同意、明示用途。门店大屏这类被动采集场景尤其要小心，能端侧处理就不要上传原图，能用人形检测就不要做人脸识别。

回答「数字人要不要眼睛」这道题的思路：不是必须，但它是从「语音机器人」到「数字人」的分水岭——语音通道解决「听懂」，视觉通道解决「看懂场合」，两者融合（多模态感知）才有真正的临场感。在技术评审或方案讨论中，能讲清视觉信号作为异步标签注入、端侧优先、隐私合规这三点，就说明理解到位了。

3.2 大脑：LLM 对话引擎

这一环是大家最熟悉的：把识别文本丢给大模型，拿回答。但在数字人场景有几个特殊要求：

• System Prompt 分层：人格设定（你是谁、什么性格）、业务知识（RAG 注入）、表达约束（口语化、每句别太长）分三层管理，不要揉成一大段。人格一致性是「数字人」区别于「聊天框」的核心。
• 输出要为「说」优化：prompt 里明确要求口语化短句、不要 markdown、不要列表符号——TTS 会把「1.」「**」念出来。
• 长时记忆：多轮对话靠上下文窗口，跨会话的「记住用户」要靠记忆系统（如 Mem0 这类长时记忆中间件：向量检索 + 用户画像 + 摘要）。
• Function Calling：查天气、下单、转人工这类动作走工具调用，返回结果再让 LLM 组织成口语。

3.2.1 RAG：给大脑喂业务知识的标准流程

数字人要回答企业业务问题，靠模型自身的知识不够，必须外挂知识库。RAG（Retrieval-Augmented Generation，检索增强生成）的标准流程新人必须掌握：

flowchart LR
    subgraph 离线建库["离线：建知识库"]
        DOC[业务文档] --> CHUNK[切分 Chunking] --> EMB[Embedding 向量化] --> VDB[(向量数据库<br/>Qdrant/Milvus/Chroma)]
    end

    subgraph 在线检索["在线：问答时"]
        Q[用户问题] --> REWRITE[Query 改写/补全] --> SEARCH[混合检索<br/>向量 + BM25 关键词]
        VDB -.相似度召回.-> SEARCH
        SEARCH --> RERANK[Rerank 重排序]
        RERANK --> PACK[拼装 Prompt<br/>system + 知识 + 历史 + 问题]
        PACK --> GEN[LLM 流式生成]
    end

核心要点（方案讨论和实战都绕不开）：

• 切分（Chunking）：按语义/段落切，块太大噪音多、块太小上下文断裂，常用 200-500 字加 10% 重叠。
• Embedding 选型：中文场景主流 BGE 系列（BGE-M3 支持多语言与稠密稀疏混合），决定了召回质量的上限。
• 混合检索：纯向量检索对「型号、编号、专有名词」这类精确匹配很差，向量召回 + BM25 关键词召回合并是工业标配。
• Rerank：召回 topK 比如 20 条，用 Rerank 模型（如 bge-reranker）精排取前 3-5 条进 prompt，显著降噪。
• 评估闭环：召回命中率、答案忠实度（有没有幻觉）要有评估集回归，改任何一环都跑一遍。

3.2.2 核心问题：首 token（TTFT）怎么做到最快

数字人场景里，LLM 是整个链路的延迟黑洞，而用户感知的快慢主要看 TTFT（Time To First Token，首 token 延迟）——因为输出是流式的，第一个 token 出来，后面的 TTS 就能开工。先把公式摆出来：

TTFT = 检索耗时 + 网络与排队耗时 + Prefill（预填充）耗时

理解三个组成部分，优化手段就是对号入座：

flowchart LR
    A[用户说完话] --> B[RAG 检索<br/>50-300ms]
    B --> C[网络 RTT + 排队<br/>50-500ms]
    C --> D[Prefill 预填充<br/>随 prompt 长度线性增长]
    D --> E[首 token 吐出]
    style D fill:#fee,stroke:#c00

第一路：让检索更快

• 向量库用 HNSW 这类内存索引，召回压到几十毫秒；向量检索和 BM25 关键词检索并行发，取并集。
• Embedding 模型本地/就近部署，别为一次向量化跨地域调 API。
• 高频问题语义缓存：命中缓存直接跳过检索和生成（客服场景命中率可以做到很高），甚至直接返回预生成的音视频片段，TTFT 趋近于零。

第二路：让 prompt 更短（砍 Prefill）

Prefill 耗时随输入 token 数近似线性增长，prompt 每砍一半，这部分就快一半：

• system prompt 精简，人格层/业务层/约束层按需加载，不要每次都全量带上。
• RAG 注入的 chunk 控制在 3-5 条，靠 Rerank 保证质量而不是靠堆数量。
• 历史对话做摘要压缩，多轮后只带摘要 + 最近几轮原文。

第三路：让前缀可缓存（KV Cache / Prompt Caching）

• 把不变的内容放 prompt 最前面（人格设定、业务规则），变化的内容（检索结果、用户问题）放最后。主流推理框架（vLLM 的 Automatic Prefix Caching）和商用 API（Claude/DeepSeek 的 prompt cache）都能复用前缀的 KV Cache，命中后 Prefill 几乎免费。
• 反面教材：在 system prompt 里塞时间戳、随机 ID——前缀每次都变，缓存永远miss。

第四路：让引擎和部署更快

• 推理框架选 vLLM/SGLang 这类支持 continuous batching 的，吞吐和排队时间都受益。
• 模型分级：简单问答走小模型（几百毫秒出首 token），复杂问题再路由大模型；或对延迟敏感的数字人场景直接上中小尺寸模型。
• 就近部署 + 长连接连接池 + 定期预热，避免冷启动和跨地域 RTT。
• 进阶要点：投机采样（speculative decoding）加速的是解码阶段，对 TTFT 帮助不大——能分清「首 token 快」和「整体生成快」是两套优化，说明真懂推理过程。

第五路：感知层兜底

• 优化到头也压不进目标时，用填充音（「嗯，我想想」）先开口争取 500-800ms，用户感知立刻好转。
• 记住目标：流式架构下 TTFT 就是用户感知的全部，后续 token 只要比语速快（TTS 会按说话节奏消费），生成总时长不影响体验。

一句话总结：「TTFT 等于检索加排队加 Prefill。我的优化顺序是：语义缓存先拦截高频问题，RAG 检索并行化并本地部署 Embedding，prompt 精简加 Rerank 控量，稳定前缀前置吃满 KV Cache，小模型分级响应，最后填充音兜底感知。」

3.3 嘴巴：TTS 语音合成

TTS（Text To Speech） 决定数字人「听起来像不像人」。新人要点：

• 同样必须选流式 TTS，而且关注一个核心指标：首包延迟（TTFB，Time To First Byte）——从给文本到第一帧音频出来的时间，主流云服务在 200-400ms。
• 分句策略：LLM 流式输出的文本按标点切成短句送 TTS，句与句之间流水线并行。怎么切是个真问题，展开见 3.3.1。
• 音色克隆：商用数字人大多需要定制音色（克隆老板、克隆主播）。主流方案（火山、阿里 CosyVoice、GPT-SoVITS 开源）只需几分钟到几小时的样本。注意合规红线：音色克隆必须取得本人授权，国内已有相关判例和《生成式人工智能服务管理暂行办法》的约束。
• 韵律和情感：检查 TTS 是否支持 SSML 或情感标签，数字人「说话像念经」多半是没做韵律控制。

3.3.1 从首 token 到首包：LLM 和 TTS 怎么衔接

工程上绕不开的一道题：LLM 通过 SSE（Server-Sent Events）逐 token 往外吐，TTS 在另一头等着合成——中间这段，是攒够 N 个 token 就送一次 TTS，还是有更好的方案？

先纠正一个概念：SSE 只是传输管道，它决定的是「token 一个一个到达」这个事实，不包含任何切分策略。真正要做决策的是服务端的聚合层（aggregator）——它消费 SSE 流，决定什么时候把一段文本交给 TTS。

三种方案的对比：

按句切分（方案二）的工程细节，这是自建聚合层必须写对的：

flowchart TD
    T[SSE 收到一个 token] --> BUF[写入缓冲区]
    BUF --> C1{命中句末标点<br/>。！？ 且长度达标?}
    C1 -- 是 --> FLUSH[flush：送 TTS 队列]
    C1 -- 否 --> C2{缓冲长度超上限?}
    C2 -- 是 --> C3{回找最近的<br/>逗号/顿号}
    C3 -- 找到 --> FLUSH
    C3 -- 没有 --> WAIT[继续等<br/>到硬上限强切]
    C2 -- 否 --> C4{缓冲超时<br/>300-500ms?}
    C4 -- 是 --> FLUSH
    C4 -- 否 --> T
    WAIT --> T
    FLUSH --> NEXT[句子带序号进 TTS 队列<br/>并发合成 按序播放]

四条规则记牢：

• 首句激进，后续放宽：第一句是首音延迟的关键，切得短（命中第一个逗号、8-15 字就 flush，甚至 LLM prompt 里直接要求「第一句简短应答」）；后续句子放宽到 20-80 字保证韵律。首音快 200ms，用户感知就高一档。
• 切点优先级：句号/问号/叹号最优先，分号/冒号次之，逗号只在超长兜底时用。顿号不切。
• 标点陷阱：小数点（「3.5 秒」）、省略号、引号内标点、英文缩写（「e.g.」）都会造成误判，正则切分前先做这些特例清洗；markdown 符号（**、#、1.）在进缓冲前就要剥掉，否则 TTS 会念出来。
• 并发合成、按序播放：切出来的句子打上序号进队列，多个 TTS 请求可以并发，但播放端必须按序号拼接，乱序就出「先说第二句」的事故。

超时兜底为什么必须有：LLM 有时会输出不带句末标点的长句，如果没有 300-500ms 的缓冲超时强刷，用户会眼睁睁看着数字人「憋着不说话」。

一句话总结：「SSE 只负责把 token 送过来，切分在服务端聚合层做。不按 token 数攒批——按标点加长度双阈值切句，首句切得激进来压低首音时间，后续句放宽保韵律，再加超时兜底；如果 TTS 厂商支持流式文本输入，就直接把 token 流转发进去让引擎自己切，首包还能再快一截。」

3.4 脸：口型与表情驱动

这是数字人区别于「语音助手」的关键一环，也是新人知识盲区最大的一环。

核心技术概念：

• Viseme（视素）：音素（phoneme）对应的口型。比如 /b/ /p/ /m/ 都对应「双唇闭合」这个口型。英文一般归并为十几个 viseme，中文可按韵母口型归类。
• Blendshape（混合形状）：3D 模型的表情通过一组预定义变形（如 jawOpen、mouthSmile）按权重混合出来。音频 → 音素 → viseme → blendshape 权重，就是经典的口型驱动路径。
• 2D 真人形象驱动：wav2lip、SadTalker、MuseTalk 这类模型，输入音频 + 人脸视频/照片，直接生成口型对齐的人脸帧。

flowchart TB
    AUDIO[TTS 音频流] --> PATH{形象路线}
    PATH -->|3D 写实路线| P1[音频提取音素/声学特征]
    P1 --> P2[映射 Viseme / Blendshape 权重]
    P2 --> P3[Unity/UE 实时渲染]
    PATH -->|2D 真人克隆路线| Q1[wav2lip / MuseTalk 等<br/>音频到人脸帧模型]
    Q1 --> Q2[逐帧生成口型对齐画面]
    PATH -->|Live2D 路线| R1[音量/音素驱动<br/>参数开合]
    R1 --> R2[Live2D SDK 渲染]

    P3 --> OUT[合成视频帧推流]
    Q2 --> OUT
    R2 --> OUT

选型经验：

3.5 身体：动作与姿态

只有脸会动的数字人被称为「花瓶数字人」。完整的身体驱动包括：

• 待机动作（idle）：不说话时的呼吸、眨眼、微动作。没有 idle 的数字人在沉默时会「死机感」十足。
• 动作库触发：LLM 输出时打标签（如 [挥手]），引擎播放对应动画片段。
• 动作生成/动捕：高端场景用动作生成模型或真人动捕（光学动捕、惯性动捕、视觉动捕）。
• 视线与点头：根据对话状态做倾听点头、眼神接触，对「像人」的提升性价比极高。

3.6 渲染与呈现

• 客户端渲染：形象资源下发到 App/Web/小程序，本地用 Unity、WebGL（three.js）、Live2D SDK 渲染。好处是不耗服务端 GPU、画面清晰；代价是包体积和端上性能适配。
• 服务端渲染 + 推流：服务端用 UE/Unity 无头渲染成视频流推给端上。好处是端上零成本、形象保密；代价是每路并发一块 GPU，成本高。
• 像素流送（Pixel Streaming）：UE 官方的「服务端渲染 + WebRTC 推流」方案，超写实数字人大屏常用。

3.7 神经：WebRTC 低延迟传输

实时交互必须走 WebRTC（或声网 Agora、腾讯 TRTC、即构 ZEGO 这类商用 RTC SDK，底层同源）。不要用 HLS/RTMP 做交互——它们的延迟是秒级到十秒级，只能用于纯观看的直播场景。

WebRTC 给数字人的价值：

• 端到端延迟可压到 200-400ms；
• 自带弱网对抗（ jitter buffer、NACK、FEC）、AEC、降噪；
• 天然支持双向音视频（用户上行说话 + 数字人下行画面）。

工程上通常自建或租用 SFU（Selective Forwarding Unit）做转发，数字人服务端作为一个「虚拟参会者」接入 RTC 房间。

4. 延迟预算：实时数字人的生死线

交互自然度的经验值：用户说完话到数字人开口，超过 1.5 秒就会觉得「卡」，控制在 1 秒内算流畅，500ms 内接近真人。

逐环预算参考（单位毫秒）：

flowchart LR
    A[VAD 判停<br/>300-600ms] --> B[ASR 出字<br/>100-300ms]
    B --> C[LLM 首 token<br/>300-800ms]
    C --> D[TTS 首包<br/>200-400ms]
    D --> E[驱动渲染<br/>50-200ms]
    E --> F[RTC 送达<br/>100-300ms]
    style C fill:#fee,stroke:#c00

注意 LLM 是最大的延迟黑洞，这也是为什么很多产品用「嗯、我想想」这类填充音（filler）先开口争取时间，以及用小参数模型做第一轮快速响应。

5. 离线内容生产链路

做口播短视频、课程录播的场景不需要实时，链路简化为：

flowchart LR
    S[文案脚本] --> T[TTS 合成配音]
    T --> D[wav2lip / 形象克隆<br/>生成画面]
    D --> E[FFmpeg 合成<br/>字幕/背景/BGM]
    E --> V[成品视频]

这条链路的工程重点是批量化和质量控制：文案队列、素材版本管理、抽帧质检（口型错位检测）、FFmpeg 自动化后期。它也是新人练手的最佳起点——没有实时性压力，每一步都可以慢慢调试。

6. 元宇宙视角下的数字人

虽然元宇宙概念已过炒作高峰，但它的知识框架对理解数字人很有帮助：

• 数字人是元宇宙的「界面」：元宇宙的愿景里，人通过 Avatar 进入虚拟世界，而 AI 数字人是这个世界里的 NPC、导游、店员。今天落地的数字人客服、数字人员工，可以看作「没有整个元宇宙、先把 NPC 做出来」的务实路线。
• 数字身份与数字资产：虚拟形象的版权归属、音色的人格权、数字分身的行为授权，都是元宇宙法律框架讨论的核心，做商用数字人绕不开。
• XR 是下一级放大器：目前的数字人主要在手机屏和大屏上，VR/AR 设备普及后，「面对面」的沉浸交互会把实时渲染和低延迟的要求再推高一个量级。
• 技术栈高度重合：游戏引擎、实时渲染、Avatar 系统、RTC——元宇宙基建没浪费，全都迁移到了数字人赛道。

一句话总结两者的关系：元宇宙是「世界」，数字人是「人」；世界还在建，人已经开始打工了。

7. 避坑清单（新人最常踩的十个坑）

1. 用 HTTP 轮询或 WebSocket 传实时音视频：WebSocket 传音频可以，但视频和双向通话必须 WebRTC。架构选错后面全是补丁。
2. 等 LLM 全句生成完再送 TTS：首音延迟直接多出 1-3 秒。必须按句流式切分。
3. TTS 分句切在奇怪的位置：按标点切，且避免切出「的」「了」这种单字句，否则韵律全毁。
4. 忽略 VAD 判停时间：默认 500-800ms 的静音判停在口语场景经常切断用户长句，要按场景调。反过来判起也有坑——不做 200-300ms 预滚动缓冲（pre-roll）会吃掉句首，「你好」变成「好」。
5. 没做 AEC 就上扬声器场景：数字人听见自己说话，无限自答。音箱/大屏场景必查。
6. 口型和音频各走各的时钟：音频流和视频帧必须共用时间戳对齐，否则网络抖动后口型越偏越远。
7. 忽视打断（barge-in）：用户插话时数字人必须能立刻闭嘴并清空播放队列，这是「像人」的及格线，很多 Demo 死在这。
8. 没有 idle 状态：沉默时形象完全静止，恐怖谷效应拉满。眨眼和呼吸是性价比最高的两个动作。
9. 音色克隆不管授权：合规风险，商用前必须签授权。
10. 并发成本没算清就接客：真人克隆路线每路并发都吃 GPU，一路成本可能是纯语音机器人的几十倍，报价前先压测。

8. 典型问题与解决方案

Q1：口型和声音对不上，越聊偏得越远。 音频帧和驱动帧的时间戳没有同源。方案：以音频流为主时钟，口型权重按音频时间戳生成，渲染帧消费时做对齐；网络侧开启 NACK 减少重传造成的画面跳变。

Q2：数字人响应慢，用户说完要等两三秒。 按第 4 节的预算表逐环打点定位。八成问题在 LLM 首 token 和 TTS 首包：LLM 换更快的模型或精简 prompt，TTS 确认开了流式，两句之间流水线并行。还不行就加填充音。

Q3：用户插话，数字人不理继续说完。 没有 barge-in 机制。方案：ASR 检测到新的用户语音起始 → 立即向 TTS/播放器发中断信号 → 清空待发队列 → LLM 侧中断当前生成（保留已说内容到上下文）。

Q4：声音机械、像念稿。 检查：文本是否带了 markdown 符号（TTS 会念出来）；是否用了支持韵律/情感的模型；分句是否过碎。可以在送 TTS 前加一道「口语化改写」。

Q5：回声、啸叫、把自己当用户。 AEC 没生效。WebRTC 场景确认 echoCancellation: true；自研管线接入 WebRTC APM；硬件上麦克风和扬声器做物理隔离。

Q6：大促/高峰期并发上不去，GPU 烧钱。 真人克隆路线把渲染挪到闲时（离线预生成常见回答视频片段，实时只做拼接）；或降级到 3D/Live2D 路线；LLM 层加意图缓存，高频问题直接命中预置音视频。

Q7：数字人前后人设不一致，聊着聊着「换人」了。 人格 prompt 没有和记忆系统打通。方案：人格定义放 system 层固定不动；用户画像和会话摘要由记忆系统（如 Mem0）注入；定期用人格一致性评估集回归测试。

9. 学习路径：从 0 到精通

flowchart TB
    subgraph S1["第一阶段：跑通（1-2 周）"]
        A1[调通云 ASR + LLM + TTS<br/>做一个语音对话命令行 Demo]
        A2[用 wav2lip 开源模型<br/>离线生成一个口播视频]
    end

    subgraph S2["第二阶段：像人（3-4 周）"]
        B1[全链路流式化改造<br/>打点测延迟]
        B2[实现 barge-in 打断]
        B3[接入一个 2D/3D 形象<br/>完成口型驱动]
    end

    subgraph S3["第三阶段：上线（4-8 周）"]
        C1[WebRTC 推拉流<br/>端到端联调]
        C2[记忆系统 + 人格 prompt 工程]
        C3[压测与成本核算<br/>弱网对抗]
    end

    subgraph S4["第四阶段：精通（持续）"]
        D1[自研/微调 TTS 与驱动模型]
        D2[情感计算与多模态交互]
        D3[中台化：多形象/多租户/编排]
    end

    S1 --> S2 --> S3 --> S4

练手项目建议（按递进排序）：

1. 命令行语音助手：打通 ASR → LLM → TTS，全程流式。
2. 离线口播视频生成器：文案进、成片出，加 FFmpeg 字幕。
3. 网页实时数字人：Live2D 或 wav2lip 形象 + WebRTC，实现打断。
4. 有记忆的数字人：接入长时记忆，连续聊三天还记得用户说过什么。

10. 总结

数字人链路说复杂也复杂，说简单就是一句话：把人的「听、想、说、动」拆成 ASR、LLM、TTS、驱动渲染、RTC 五个流式环节，再把总延迟压进 1 秒。新人入门的正确姿势不是啃论文，而是先跑通最小闭环，再逐环升级——每一环的坑本文都列了，剩下的就是动手。

概念地图有了，想看这条链路在真实开源项目里长什么样，接着读《LiveTalking 源码解剖：一个开源实时数字人是怎么跑起来的》——它把本文的输出侧（TTS、口型驱动、RTC 推流）做成了工业级实现，输入侧和智能侧留着 demo 形态，正好当对照样本。

• AI 工程

• 数字人
• 虚拟数字人
• ASR
• TTS
• LLM
• WebRTC
• 口型驱动
• 元宇宙
• 学习笔记

方糖猫（大可）

18 年后端架构，现在独立做 AI 产品。这里记录 AI 视频、AI Agent 与工程实践。