# AI 驱动虚拟形象渲染方案 v5.1
## 跨产品形态统一架构调研

| 项目 | 内容 |
|---|---|
| 产品形态 | ① 罐子（Unity 3D + RK + 全息光仓，洛天依形象在跑）<br>② 洛天依 APP（独立 APP，Unity）<br>③ 小型硬件统一 APP（多设备入口，统一流量与用户）<br>④ ESP32-S3 小硬件（序列帧形态）<br>⑤ 未来 Live2D 形态 / 虚拟明星 / 写实数字人 |
| 当前底座 | **火山 RTC AIGC 全平台已跑通**（手机 / 罐子 / ESP32-S3）<br>整套 ASR + LLM + TTS 在云端打包，端到端延迟 < 2s |
| 当前痛点 | 形象层 3D 建模 + 手 K 动画，美术资产成本高，新对话/新场景都要手 K 衔接 |
| 调研目标 | 用 AI 驱动取代手 K，复用 RTC 已有底座，覆盖跨产品形态 |
| 调研日期 | 2026-05-09 |
| 适用主体 | 杰森气元科技 / 气元科技 |
| 优先级 | **P0 - 立即启动** |

---

## 阅读指引

> 本文是给彭铭聪 / 张业昌 / 张文琦 review 的方案文档。Air 主导方向，**实操细节由你们决定**。
>
> **核心思路**：RTC AIGC 已经原生下发字幕、AI 状态、情绪、Function Calling 等信号，Unity 端 / 各端在已有 RTC 回调里多解析这些事件，就能把动作衔接、表情切换、嘴型驱动从"手 K"切换到"AI 驱动"。
>
> 罐子的洛天依 3D 模型、Animator、shader 全部保留，**不动**；只在事件消费层加东西。
>
> 文档结构：
> - **第一~二章**：架构主线，先看
> - **第三章**：罐子（洛天依）的具体落地路径，彭铭聪重点看
> - **第四~六章**：其他产品形态参考，未来要做时再翻
> - **第七章**：风险和待验证项
> - **第八章**：P0 行动清单
> - **第九章**：未来技术栈迁移路径（中长期成长方向，彭铭聪也建议看）

---

## 一、关键结论

> **核心架构：协议层复用 RTC 信令，渲染层按形态分化。**
>
> 火山 RTC AIGC 已经把 ASR + LLM + TTS 整套打包跑在云端，TTS 输出的字幕（Subtitle）、AI 对话状态、情绪标签、Function Calling 事件**通过 RTC 房间内的标准消息回调下发到端侧**——跟音频流走同一条链路，天然时间对齐。
>
> 各端（Unity / 手机 / RK / ESP32-S3）已有的 RTC SDK 已经具备接收这些消息的能力。**不需要自建 WebSocket 协议，不需要新连接管理**——只在已有 RTC 回调里加一层事件解析。

### 1.1 三件事必须分开讨论

很多技术争议来自把这三件事混在一起：

| # | 概念 | 跑在哪 | 我们的方案 |
|---|---|---|---|
| 1 | **AI 推理**（LLM/TTS/ASR） | 云端 | 火山 RTC AIGC（已跑通） |
| 2 | **驱动信号下发** | 云端 → 端侧 RTC 信令 | 复用 RTC 已有通道 |
| 3 | **形象渲染**（每帧画面） | **端侧本地** | Unity / Cubism / 序列帧 |

「AI 驱动」指 #1 输出的语义信号通过 #2 送到端侧，驱动 #3 自动渲染。**渲染本身仍在端侧本地跑**——跟所有 VTuber 软件、SEKAI、明日方舟一样的架构。

### 1.2 火山官方"数字人"功能 ≠ 我们要的方案，明确排除

| 维度 | 火山数字人 | 我们的需求 |
|---|---|---|
| 渲染位置 | 云端渲染，推 H264 视频流到端 | 端侧自渲染 |
| 形象库 | 火山预制 2D 真人 / 3D 超写实 / 3D 卡通 | 自建 3D（洛天依）/ 未来 Live2D / 序列帧 |
| 计费 | 按并发独立计费（付费资源） | 不需要，省钱 |
| 灵活度 | 形象由火山管 | 形象、动画、风格我们完全控制 |
| 商务限制 | 文档明确"提交工单咨询售前" | 标准 RTC AIGC 不需要额外谈判 |

> **判定依据**：火山数字人文档明确"SubtitleConfig.SubtitleMode 必须设置为 1（不对齐时间戳）"——启用云端数字人时字幕只是显示用、不携带音频对齐信息（因为云端已经把口型烧进视频流了）。我们要的恰恰是 **SubtitleMode=0（对齐音频时间戳）**——给端侧自渲染用的字时间戳信号。

**判断技巧**：凡是火山文档里需要"独立计费 / 提交工单咨询 / 数字人 AppId / 并发限制"的能力——是云端付费功能。凡是 RTC AIGC 已经原生支持的能力（字幕、AI 状态、情绪、Function Calling）——是 RTC 标准能力，已经在订阅里。

**设计原则：只用 RTC 标准能力，不依赖任何独立付费资源**。

### 1.3 各产品形态可行性

| 形态 | 渲染技术 | 硬件 | 状态 |
|---|---|---|---|
| **罐子（洛天依）** | Unity 3D + BlendShape + Animator + 全息光仓 | RK3566 / RK3588S | **已在跑，下一步加 AI 驱动事件层** |
| **洛天依 APP**（独立） | Unity（与罐子同一份工程） | iOS / Android | 已有 demo，与罐子同步加 AI 驱动 |
| **小型硬件统一 APP** | Flutter + 多渲染层（按设备角色卡热加载） | iOS / Android | 待立项，**不用 Unity** |
| ESP32-S3 小硬件 | LVGL + sprite sheet 状态机 | ESP32-S3 | 方案已定，未来按 RTC 信令驱动 |
| 未来 Live2D 形态 | Cubism Native SDK | 待定 | 储备方案 |
| 未来虚拟明星 / 写实数字人 | Unity 或 Cocos / VRM 标准 | 高端硬件 / 手机 | 储备方案，见第九章 |

### 1.4 立即启动的 P0 工作

**这是现在就要开始做的事**：

1. 服务端在 RTC AIGC 配置里启用 SubtitleConfig，SubtitleMode 设为 0（对齐音频时间戳）
2. Unity 端打印 subtitle 消息 JSON，验证时间戳精度（决定后续嘴型驱动算法）
3. Unity 端最小可用 demo：罐子上洛天依 AI 对话时嘴型自动同步（取代当前手 K）

详见第八章。**总工时 3-4 人天，本周可全部完成**。

---

## 二、修订后的数据流

```mermaid
sequenceDiagram
    participant U as 用户
    participant App as 端侧 App<br/>(Unity罐子/手机/RK/ESP32)
    participant R as 本地渲染引擎<br/>(Unity / Cubism / LVGL)
    participant RTC as 火山 RTC<br/>(全平台 SDK)
    participant AIGC as 火山 AIGC 云<br/>(ASR+LLM+TTS)

    Note over App,R: 模型/资产端侧本地常驻

    U->>App: 说话
    App->>RTC: 音频上行
    RTC->>AIGC: 路由到 AIGC 服务
    AIGC->>AIGC: ASR → LLM(豆包) → TTS

    par 同一条 RTC 房间链路
        AIGC-->>RTC: TTS 音频流
        RTC-->>App: 订阅音频流
    and
        AIGC-->>RTC: Subtitle 字幕(对齐时间戳)
        RTC-->>App: onRoomMessageReceived
    and
        AIGC-->>RTC: AI 状态事件 / 情绪 / Function Call
        RTC-->>App: onUserMessageReceived
    end

    App->>App: 扬声器播放音频
    App->>R: 字时间戳 → 嘴型参数
    App->>R: 情绪 → 切换 expression
    App->>R: Function Call → 触发 motion
    R-->>U: 屏幕渲染
```

**关键点**：所有 AI 输出走的是同一条 RTC 房间链路，跟音频流天然时间对齐。无独立 WebSocket，无独立连接管理，无新协议设计。

### 2.1 RTC AIGC 能用的信号（重要：直接对接列表）

| 信号类型 | 来源 | 用途 |
|---|---|---|
| **字幕（Subtitle）** | TTS 流式输出 | 驱动嘴型（最关键） |
| **AI 状态事件** | 对话状态机 | 触发 idle / listening / thinking / speaking 状态切换 |
| **AI 对话任务事件** | 任务级回调 | 错误处理、对话开始/结束 |
| **情绪识别与生成** | 情绪模型输出 | 触发 expression 切换 |
| **Function Calling 结果** | LLM 工具调用 | 触发预设 motion / 业务动作 |
| **自定义 Message** | LLM 通过结构化输出 | LLM 主动插入 motion tag |

这些能力**已经在你们的 demo 里跑通的 RTC SDK 里**——不需要任何新连接。

### 2.2 端侧通用消费模式

每个端的 RTC SDK 都有这两类回调：

```
onRoomMessageReceived(msg)         // 房间广播消息（字幕通常走这里）
onUserMessageReceived(uid, msg)    // 点对点消息（AI 状态事件通常走这里）
```

端侧实现 = 在这两个回调里加一层 JSON 解析 → 写入时间轴消费器 → 驱动渲染层。

### 2.3 端侧时间轴示例

```mermaid
gantt
    title 端侧 1 秒内的渲染时间轴：「今天天气真好」
    dateFormat  X
    axisFormat %Lms

    section 音频播放
    PCM 解码播放                :a1, 0, 1000

    section 嘴型 (字 → viseme)
    今 (j-in)                   :p1, 0, 200
    天 (t-ian)                  :p2, 200, 400
    是 (sh-i)                   :p3, 400, 600
    好 (h-ao)                   :p4, 600, 1000

    section 表情
    expression= happy           :e1, 0, 1000

    section 动作
    motion= idle.smile          :m1, 0, 1000
```

端侧只是一个**时间轴消费器**：音频播放线程独立、嘴型按字时间戳改 BlendShape、表情按 emotion 区间切换、motion 按 Function Call 触发。

### 2.4 「渲染跑在端侧」是工业标准

需要向团队说明的一件事——这不是新架构，是行业惯例：

- 全球所有 VTuber 直播软件（VTube Studio、PrprLive、Animaze）都是端侧本地跑
- Project SEKAI、明日方舟、原神信箱里的角色，端侧本地渲染
- Unity 跑在 Android RK 板上是产业标准做法（车载、零售、家电常见）

**「AI 驱动虚拟人」的新意不在「跑在云端」，而在驱动信号源**：

| 传统形象渲染 | AI 驱动 |
|---|---|
| 主播说话 | LLM 输出文本 |
| 主播按表情按钮 | LLM 输出 emotion tag |
| 摄像头面捕跟踪嘴型 | TTS 输出字时间戳 |
| 主播按动作快捷键 | LLM 输出 Function Call |
| 动画师手 K 衔接 | RTC AI 状态事件驱动状态机 |

---

## 三、罐子（洛天依）落地路径

**这是 P0 的核心工作。彭铭聪重点看本章。**

### 3.1 当前状态梳理

- Unity 工程已有洛天依 3D 模型（手动建模）
- 动画师做了多套动作，彭铭聪在 Unity 里做动作衔接
- 已经加了"张嘴"——但应该不是真正的 viseme 嘴型，是简化版张/合（Q 版卡通形象上够用）
- RTC + AI 对话已经跑通

### 3.2 不变的部分

- 3D 建模 ✅ 保留
- BlendShape / 骨骼绑定 ✅ 保留
- 现有 Animator 和动作衔接 ✅ 保留
- shader 和全息光仓适配 ✅ 保留
- RTC 集成 ✅ 保留

### 3.3 要加的部分

在 Unity 工程里加一个事件消费层：

```
[业务逻辑层]  ← 纯 C# 逻辑，不绑 Unity API，可移植
  ├─ RTCMessageParser.cs        // RTC 消息 JSON 解析
  ├─ TimelineConsumer.cs        // 事件队列 + 时间轴消费
  └─ CharacterStateMachine.cs   // 角色状态抽象（idle/listening/speaking...）
       ↓ 通过接口调用
[渲染适配层]  ← 绑 Unity，未来换技术栈时只重写这一层
  └─ UnityCharacterRenderer.cs  // BlendShape / Animator 写入
       ↓
[已有 Unity 资产]  ← 完全不动
  ├─ 洛天依 3D 模型
  ├─ Animator 状态机
  └─ shader / 全息光仓适配
```

**关键设计原则：业务逻辑层和渲染适配层解耦**。具体做法：
- 业务逻辑层不直接调 `Animator.SetTrigger()` 或 `SkinnedMeshRenderer.SetBlendShapeWeight()`
- 改成调一个接口 `ICharacterRenderer`，方法是 `SetMouthOpen(float v)` / `PlayMotion(string name)` / `SwitchExpression(string name)` 这种语义化 API
- Unity 实现 `UnityCharacterRenderer : ICharacterRenderer`
- 未来想换 Cocos / Three.js / 其他，只重写一个 Renderer 实现，业务逻辑零改动

> **这个分层在当下不显眼，未来换技术栈时值千金**。详见第九章「未来技术栈迁移路径」。

完整 Unity 工程结构：

```
[Unity 主线程]
  ├─ RTCEngine（已有）
  │   └─ OnRoomMessageReceived / OnUserMessageReceived  ← 转发给 RTCMessageParser
  ├─ 业务逻辑层（新增，纯 C#）
  │   ├─ RTCMessageParser
  │   ├─ TimelineConsumer
  │   └─ CharacterStateMachine
  ├─ 渲染适配层（新增）
  │   └─ UnityCharacterRenderer : ICharacterRenderer
  └─ AudioPlayback（已有，作为时间基准）
```

**改动量很小**，3D 资产和现有动画状态机一行不动。

### 3.4 全息光仓适配

LCD 拆背光后，黑色像素 = 透明（光不发出去），亮色像素 = 发光。渲染要求：

- **纯黑背景**（不要天空盒，不要环境光）
- **角色用发光材质**：emission map + Bloom 后处理强化
- **避免大面积低亮度区域**（在光仓里看不见，会显得角色少了一块）
- **轮廓光强化**：rim light 让角色边缘更清晰
- **慎用半透明**：alpha blend 在拆背光后效果难预测，先做实验
- **色彩偏向高饱和、亮色调**（青色/紫色/品红在全息感下最强）

这些规则彭铭聪应该已经在做了，列在这里供未来其他人参考。

### 3.5 RK 性能预期

| 板子 | 屏幕 | 单角色 PBR | Unity URP | 全息 shader |
|---|---|---|---|---|
| RK3566 Mali-G52 2EE | 720p | 30fps（顶点 < 30k） | URP 简化版 | 简单 Bloom |
| RK3588S Mali-G610 | 1080p | 60fps 轻松 | URP 完整 | Bloom + 体积光可选 |

**RK3566 优化注意点**：
- 顶点数严控（< 30k），骨骼 < 50
- shader 不要用复杂 PBR，半 Lambert + matcap + 发光通道即可
- URP 关闭 SSR / SSAO / DOF；Bloom 用低质量档
- 720p 是合理目标，强求 1080p 会掉帧

### 3.6 关于嘴型精度的讨论

> Air 提到："洛天依现在嘴型只是张/合，不是真嘴型，对 Q 版卡通形象其实够用。但未来做虚拟明星、真人写实数字人时，真嘴型才比较重要。"

这个判断对：

| 形象类型 | 嘴型精度要求 | 实现路径 |
|---|---|---|
| Q 版卡通（洛天依） | 张/合 + 表情即可 | 字时间戳 → 1 个 BlendShape 开合度，足够 |
| 写实/半写实虚拟艺人 | 6 viseme（A/I/U/E/O/sil） | 字 → viseme → 5+ 个 BlendShape 加权 |
| 顶级写实数字人 | 15 viseme + 协同发音 | 接 NVIDIA Audio2Face 或类似方案 |

**当前阶段（洛天依罐子）做最简实现就够**：字时间戳到了 → BlendShape 开合度 = 1（讲话中）；字时间戳间隙 → 开合度 = 0；用 LERP 平滑过渡。一个 BlendShape 解决问题。

未来做虚拟明星（CYBER STAR 那条线）时，再升级到完整 viseme 集，**那时候方案不变，只是 CharacterController 里多写几行映射代码**。

### 3.7 AI 驱动的真正价值不只在嘴型

**这里要纠正一个可能的认知偏差**：洛天依嘴型确实不重要，但这不等于 AI 驱动方案对洛天依不重要。

AI 驱动信令的真正价值在**动作 / 表情 / 状态切换**：

- 不再手 K 每段对话的动作衔接
- AI 说话内容触发情绪 → 自动切表情
- LLM 输出 Function Call → 自动播预制动作（挥手、点头、托腮、唱歌起手...）
- idle / listening / thinking / speaking 状态机由 RTC AI 状态信号驱动

**美术资产成本无限堆高的核心问题，是动作和动画**，不是嘴型。彭铭聪现在每加一段新对话就要手 K 衔接的痛点，AI 驱动信令解决的就是这个。

罐子上**最容易出效果的不是嘴型**，是：
1. AI 在思考时（状态 = thinking）→ 自动播"歪头思考"动作
2. AI 在听用户说话时（状态 = listening）→ 自动播"侧耳倾听"动作
3. AI 说到开心内容时（情绪 = happy）→ 自动切笑脸 + 播"拍手"动作
4. 用户问"你会唱歌吗"，LLM 触发 Function Call `play_song` → 播预录的唱歌动画

这些都是预制好的 motion clip，AI 只是按语义触发——美术做一次，无限复用。

---

## 四、其他产品形态参考

> 这一章是知识储备。当前不需要立即用，但未来做新产品时直接拿来用，不用重新调研。

### 4.1 当前手机 APP 架构

**两个 APP 分立**：

| APP | 形态 | 当前技术栈 | 维护人 |
|---|---|---|---|
| **洛天依 APP**（独立） | 单 IP 独立产品，3D 形象 | **Unity**（与罐子同一份工程） | 彭铭聪 |
| **小型硬件统一 APP** | 多产品入口，承载 ESP32-S3 等小硬件 | 原生（Flutter / 待定） | TBD |

**为什么分立**：
- 洛天依是单一 IP 产品，沉浸式体验，Unity 重资产合理
- 小型硬件整合成一个 APP 是为了**统一流量入口和用户管理**，调性轻快，不适合塞 Unity 这种重容器

### 4.2 小型硬件统一 APP 的渲染方案

按硬件对应的形象类型，APP 内嵌不同渲染层：

```
[小型硬件统一 APP（Flutter 推荐）]
  ├─ 用户中心 / 流量入口 / 统一登录
  ├─ 设备管理 / 配网 / 固件升级
  ├─ 多产品入口（卡皮巴拉、桌面机器人...）
  └─ 形象渲染层（按设备角色卡热加载）
       ├─ Cubism Native（如果设备角色是 Live2D）
       ├─ WebView + three.js + three-vrm（如果是 VRM 3D 形象）
       └─ SpriteRenderer（如果是序列帧形象，与 ESP32-S3 资产一致）
  └─ 火山 RTC Flutter SDK（已有）
```

**关键决策**：小型硬件 APP **不用 Unity**——理由：
- APP 体积要小，启动要快（用户用完即走的轻量场景）
- 形象层多样化，要能热切换不同渲染方案
- Unity 编出的 APP 包大、启动慢，跟"流量入口 + 用户管理"调性不符

### 4.3 洛天依 APP 的演进

当前 Unity 工程在跑，下一步同步加 AI 驱动事件层（与罐子代码尽量复用）。

未来可能的演进方向：
- 短期（2026）：保持 Unity，专注 AI 驱动改造
- 中长期：见第九章「未来技术栈迁移路径」

### 4.4 Live2D 形态（未来）

如果未来某个产品定位需要 Live2D（2D Q 版陪伴角色、复古二次元风格）：

- **渲染**：Cubism Native SDK Android Java / iOS Objective-C++
- **嘴型驱动**：字时间戳 → `ParamMouthOpenY` / `ParamMouthForm`
- **资产生产**：外包 Live2D 师，5k-3w/形象（2 头身偏便宜）
- **商用授权**：见第六章

### 4.5 3D / VRM 路径（未来虚拟明星 / 写实数字人）

**适用场景**：未来立项的独立 IP 产品（如 CYBER STAR 虚拟艺人）、批量生产的标准化 3D 形象、jalab.ai 网页端展示。**不替代**罐子/洛天依 APP 现有 Unity 路径。

如果未来要做：
- 全身 / 360°视角的形象
- 多角色复用（VRoid Studio 出 VRM，pixiv 标准）
- 跨产品形象互通

**三条集成路径**：

| 路径 | 出活速度 | 性能 | 推荐场景 |
|---|---|---|---|
| **A. WebView + three.js + three-vrm** | 快（1-2 周） | 手机 60fps | 默认起步，可嵌入小型硬件统一 APP |
| **B. Unity as a Library + UniVRM** | 慢（4-6 周搭基建） | 最好 | 3D 是核心体验、独立 APP |
| **C. Filament（thermion）** | 中 | 好 | 2027 年再看 |

**Path A** = three-vrm 是 pixiv 官方维护，VRM 标准 blend shape / SpringBone / LookAt 全部内置。**这条路径与第 4.2 节的小型硬件统一 APP 渲染层兼容**——VRM 形象可以通过 WebView 容器嵌进去。

**重要澄清**：
- 洛天依**不需要**切到 VRM——Unity 自建模型已经在跑，继续用
- VRM 是给**未来批量生产 3D 形象**时用的标准，不是替代当前路径

### 4.6 序列帧（ESP32-S3）

ESP32-S3 没有 GLES 跑不了 Live2D / 3D。方案：

- 云端按形象 ID 预渲染 sprite sheet（emotion × 4-8 帧 + motion × 多个）
- 端侧 LVGL 状态机消费 emotion / motion frame
- **忽略字时间戳精度**（用音频包络替代驱动嘴型 3 档：闭/半开/全开）
- 简化下行带宽

**关键简化**：火山 RTC ESP32-S3 SDK 已经把信令回调暴露出来——不需要自写 mbedTLS WebSocket Client，直接挂回调即可。预估 C 代码量 < 200 行。

---

## 五、目标硬件能力参考

| 项目 | CPU | GPU | NPU | 含义 |
|---|---|---|---|---|
| **RK3566** | 4× A55 @2.0GHz | Mali-G52 2EE | 1 TOPS | 跑单 Unity 3D 角色 + 简单 UI 可，720p 30fps |
| **RK3568** | 4× A55 @2.0GHz | Mali-G52 2EE（同 3566） | 0.8 TOPS | 工业版，外设丰富，渲染等价 |
| **RK3588S** | 4× A76 + 4× A55 | Mali-G610 MC4 | 6 TOPS | 1080p 60fps 轻松，可叠加端侧 ASR/VAD |
| 中端手机 | 骁龙 6/7 系或天玑 7/8 系 | Adreno 6xx / Mali-G68+ | >2 TOPS | 性能远超需求 |

> **命名澄清**：Rockchip 没有「RK3568S」型号。RK3566 是消费级，RK3568 是工业级，两者 GPU 同款（Mali-G52 2EE 双核）。

---

## 六、Live2D 商用授权评估（未来用得上时再翻）

> 当前不立即用，但 Live2D 做商业产品需要提前 6 个月走法务流程。储备信息。

Cubism SDK 商用必须签 Publication License Agreement。

### 6.1 企业规模分级（按年销售额）

| 分级 | 年销售门槛（日元） | 约合人民币 |
|---|---|---|
| General User（个人） | < 1000 万 | < 50 万 RMB |
| Small（小企业） | < 1000 万 | 免授权费（部分 AI App 除外） |
| Middle（中企业） | 1000 万 ~ 1 亿 | 50 万 ~ 500 万 RMB |
| Large（大企业） | ≥ 1 亿 | ≥ 500 万 RMB |

> ⚠️ 杰森气元和火山 1000 万 CNY/年 框架已签，按汇率约合 2 亿日元，已达 Large-Scale。需要法务介入正式评估。

### 6.2 AI / Chatbot 应用：Expandable Application 特殊审核

Live2D 官方明确：「使用 Cubism SDK 作为 AI 或 chatbot 接口的内容」需要走 Expandable Application 流程，**需要 Live2D Inc. 单独审核批准并签订专属 Publication License**。情感陪伴 Agent / 虚拟伴侣类产品**不能套用普通 plan**。

### 6.3 费用结构参考（Running Royalty Plan）

- **Large-Scale**：初始费 30 万日元/Region；月费 10 万日元/平台/Region（iOS / Android / HarmonyOS / Web 各算一个平台）
- **Middle-Scale**：初始费 5 万日元/Region；月费 2 万日元/平台/Region
- 显示 Live2D logo + Showcase 列出可享折扣价

> **建议**：PoC 阶段不走商用 license，先确认技术路径和形象效果。商业化前 6 个月让法务联系 Live2D 中国区代理，按 Expandable Application 流程提交方案。

---

## 七、风险与待验证项

修订后剩下的不确定项收敛到很少：

### 7.1 必须 PoC 验证的（决定算法选型）

**SubtitleMode=0 实际下发的时间戳精度**：
- 是字级（每个字带 begin_ms / end_ms）？还是只到句级？
- 时间戳与音频流的实际对齐误差（理想 < 50ms）

**验证方法**（半天工作量）：
1. 服务端启用 SubtitleMode=0 调用 StartVoiceChat
2. 端侧打印每个 subtitle 消息的完整 JSON
3. 同时录音频流
4. 用 Audacity 对比字幕时间戳与音频实际发声时间

**结果分支**：
- **结果 A：字级对齐**（最佳）→ 直接驱动嘴型，精度满足 lip sync
- **结果 B：只到句级** → 端侧加音量包络辅助：句级时间戳确定开始/结束，音量包络驱动开合度
- **结果 C：完全不返回时间戳** → 退回纯音量驱动（精度仍够洛天依的 Q 版张合用）

无论哪种结果，**整体架构都不变**，只是端侧驱动算法层换实现。

### 7.2 实操中需要彭铭聪 / 业昌 / 文琦决定的

- 现有 Animator state 能否被 RTC AI 状态事件直接驱动？（需要 review 现有状态机设计）
- Function Calling 触发预制 motion 的工程实现路径（在 Unity 端怎么 dispatch）
- 第 3.3 节 `ICharacterRenderer` 接口的具体方法集和签名（这是未来跨引擎可移植性的关键）
- 全息光仓 shader 在 RK3566 上的实测帧率和热表现

### 7.3 已被消除的不确定项（不再需要验证）

- ~~豆包 TTS 是否独立返回 phoneme 时间戳~~ → RTC AIGC 把 TTS 包了，我们用 Subtitle
- ~~自建 WebSocket 协议设计~~ → 不需要，复用 RTC 信令
- ~~端侧自管理连接、心跳、重连~~ → RTC SDK 已处理
- ~~phoneme 编码 → IPA 映射表~~ → Subtitle 直接出可读文本

### 7.4 长期风险

- **Live2D Expandable Application 审核结果不确定**（未来用 Live2D 时再面对）
- **Live2D license 费用对中型企业较高**（同上）
- **Open-LLM-VTuber license 变更**（如果未来参考其架构需要注意 v1.2 之前是 MIT）
- **Unity 中国长期不确定性**（详见第九章）——这是 1-3 年维度的战略风险，当下通过分层架构防御

---

## 八、P0 行动清单

### 8.1 本周启动（5 月 12 日 ~ 5 月 16 日）

| # | 任务 | 负责人 | 工时 | 交付 |
|---|---|---|---|---|
| **P0-1** | 服务端 RTC AIGC 启用 SubtitleConfig，SubtitleMode=0 | 罐子组 / 业昌 | 0.5 天 | StartVoiceChat 配置就绪 |
| **P0-2** | Unity 端打印 subtitle 消息 JSON，验证时间戳精度 | 罐子组 | 0.5 天 | 时间戳精度报告（5 测试句对齐误差） |
| **P0-3** | Unity 端 TimelineConsumer + BlendShape 嘴型驱动 demo | 彭铭聪 | 1-2 天 | 罐子上洛天依 AI 对话时嘴型自动同步 |
| **P0-4** | Unity 端 RTC AI 状态事件 → Animator state 桥接 | 彭铭聪 | 1 天 | listening/thinking/speaking 自动切动作 |

**总工时**：3-4 人天，本周内可全部完成。

**P0 完成后的可见效果**：罐子上现有洛天依 3D 模型，AI 对话时嘴型自动驱动 + 状态自动切动作，**无需任何手 K 嘴型/动作衔接**。这就是从"美术资产成本无限堆高"切换到"AI 驱动"的关键拐点。

### 8.2 P1 - 2 周内

- 情绪事件接入：RTC AIGC 情绪信号 → Animator BlendTree（happy/sad/surprised...）
- Function Calling 触发预设 motion：定义第一批工具（挥手、点头、托腮、唱歌起手）
- 洛天依 APP 同步获得 AI 驱动能力（与罐子是同一份 Unity 工程，自动获益）
- 全息光仓适配在 RK3566 / RK3588S 上量化帧率

### 8.3 P2 - 1 个月内

- 端侧 SDK 抽象：把事件消费层封装成可复用模块（Unity Package / 各端 lib）
- 形象资产规范：motion 命名 / expression 集合 / BlendShape 标准化（为未来批量产形象做准备）
- ESP32-S3 sprite sheet 云端预渲染管线设计

### 8.4 未来项（按需启动）

- Live2D 商用授权流程启动（决定要做 Live2D 产品时提前 6 个月）
- VRM 标准接入（决定要批量 3D 形象时）
- 虚拟明星形象的高精度 viseme 升级（CYBER STAR 立项时）
- 端侧 Whisper + VAD 打断（RK3588S 高端方案，提升交互自然度）

---

## 九、未来技术栈迁移路径

> 本章是给彭铭聪等核心开发者的中长期成长方向。Air 与彭铭聪已就此有过深谈：**核心开发者要跟着团队成长，不能永远只做 Unity**。本章把可能的迁移方向和触发条件写清楚，作为长期参考。

### 9.1 为什么要考虑迁移

Unity 当下是最优解，但 1-3 年维度有几个不确定项：

- **Unity 中国（团结引擎）独立运营路径不明朗**——版本分裂、定价模型、政策影响、海外版功能同步存在变数
- **Unity 商业模式变化历史**：2023 年的 Runtime Fee 风波说明商业政策可能突变
- **国产引擎政策导向**：信创、国产替代趋势可能影响 ToB 产品选型
- **Web 化与跨端化趋势**：Three.js / 小程序 3D / 浏览器 WebGPU 在变强，移动端原生不再是唯一答案

**我们不需要现在就换，但需要现在就让架构能换**。

### 9.2 触发迁移的信号

出现以下任一情况，启动迁移评估：

1. Unity 中国版收费模式或政策对我们形成实质成本/合规压力
2. 跨端复用需求超出 Unity 能力边界（小程序、Web、HarmonyOS NEXT 等）
3. 国产化要求（ToB 项目、政府采购场景）明确排除海外引擎
4. 团队增长后多人维护 Unity 工程的协作成本超过迁移成本
5. 出现某个新形象类型，Unity 不是最优解（如 Live2D / VRM 标准 / 复杂 Web 场景）

### 9.3 候选技术栈对比

| 候选 | 适配场景 | 优势 | 劣势 | 切换难度 |
|---|---|---|---|---|
| **Cocos Creator 4** | 主推备选 | 国产、政策最稳；团队已有 Cocos 能力（Avatar Social 在用）；3D 能力够用 | 3D 生态不如 Unity 成熟；shader / 物理 / 后处理需重写 | 中（资产可部分复用，逻辑层完全可移植） |
| **Three.js + three-vrm** | 走 Web / 跨端轻量化 | 跨平台、Web 化、VRM 标准化、生态活跃 | 性能不如原生；复杂角色掉帧；需要 WebView 容器 | 低（如果走 VRM 标准） |
| **Godot 4** | 完全开源场景 | MIT 开源、免费、跨平台 | 国内生态弱、找开发者难、3D 工具链一般 | 中 |
| **Unreal Engine** | 顶级画质场景 | 顶级 PBR / 物理 / 影视级渲染 | 包体大、移动端 / 嵌入式不友好；学习曲线陡 | 高 |
| **自研 + Three.js / Filament** | 完全可控 | 100% 自主 | 投入巨大，不适合现阶段 | 不考虑 |

**主推备选是 Cocos Creator 4**：
- Avatar Social 项目团队已经在用，能力沉淀可复用
- 国产引擎政策最稳
- 资产工作流（建模 → 导入 → 动画）和 Unity 接近，迁移学习曲线低
- 嵌入式（罐子 RK 板）和手机都能跑

**Three.js / three-vrm 是另一类备选**：
- 不是替代 Unity 做主力，而是补充
- 跨端 Web 容器 / 小程序 / VRM 标准角色 用它最合适
- 未来如果做 jalab.ai 网页端虚拟艺人展示，必然走 Three.js

### 9.4 迁移成本估算（以 Cocos 为例）

按"洛天依完整迁移到 Cocos"测算：

| 项 | 工作量 | 备注 |
|---|---|---|
| 3D 资产重新导入 + 材质适配 | 1-2 周 | FBX 可直接导入，shader 要重写 |
| Animator 状态机重建 | 1 周 | Cocos animation system 不同 |
| 全息光仓 shader 重写 | 1 周 | 后处理管线不同 |
| 业务逻辑层接入 | 0.5 天 | **如果做了第 3.3 节的分层，这一步几乎零成本** |
| RTC SDK 适配 | 0.5 天 | 火山 RTC Cocos 集成已有 |
| 联调与优化 | 1-2 周 | 性能调优、bug 修 |
| **总计** | **4-6 周** | 一个工程师全职 |

**关键洞察**：业务逻辑层（RTC 解析、TimelineConsumer、CharacterStateMachine）的迁移成本几乎为零——因为它们是纯 C# 逻辑，不绑 Unity API。**前提是第 3.3 节的分层设计严格执行**。

### 9.5 给彭铭聪的成长方向

短期（2026 年）：
- 把洛天依 Unity 工程做深做透
- AI 驱动事件层是这一年的核心 milestone
- 通过分层设计积累"引擎无关"的工程思维

中期（2027 年）：
- 学习 Cocos Creator 4，参与 Avatar Social 等 Cocos 项目交叉协作
- 评估某个新产品形态用 Cocos 实现的可能性
- 主导一次小规模技术栈迁移试点（不动洛天依，从新立项的小产品开始）

长期（2-3 年后）：
- 成为"形象渲染层"的技术决策者，能根据产品需求选最合适的引擎
- 不被 Unity 这一个工具锁死，技能围绕"3D / 实时渲染 / 角色驱动"这个领域而非"Unity 这个引擎"

**这是一个工程师从"工具使用者"到"领域专家"的转变路径**。

### 9.6 当下要做的事

1. ✅ **架构上做防御**：第 3.3 节的分层设计严格执行
2. ✅ **业务逻辑不绑引擎 API**：所有渲染调用走 `ICharacterRenderer` 接口
3. ⚠️ **不要现在迁移**：当前痛点是美术资产成本，不是引擎选型，先做完 P0 AI 驱动改造
4. ⚠️ **不要在两个引擎间来回切**：决定迁移时一次切换到位，不要并行维护两套

---

## 附录 A：参考项目链接

**核心参考（直接对接）**：
- 火山 RTC AIGC Demo（重点参考）: <https://github.com/volcengine/rtc-aigc-demo>
- 火山 RTC AI 实时字幕文档: <https://www.volcengine.com/docs/6348/1337284>
- 火山 RTC 获取 AI 状态文档: <https://www.volcengine.com/docs/6348/1415216>
- 火山 RTC 情绪识别与生成: <https://www.volcengine.com/docs/6348/2139328>
- 火山 RTC Function Calling: <https://www.volcengine.com/docs/6348/1554654>
- 火山 RTC 嵌入式硬件集成: <https://www.volcengine.com/docs/6348/1438400>

**反例（已排除，仅作判断依据）**：
- 火山 RTC AI 数字人形象文档: <https://www.volcengine.com/docs/6348/1848567> ← 这是云端渲染推视频流方案，**我们不用这个**，但通过它的文档反推出 SubtitleMode=0 是给端侧渲染用的

**储备方案参考**：
- Cubism SDK 下载: <https://www.live2d.com/en/sdk/download/native/>
- Cubism License: <https://www.live2d.com/en/sdk/license/>
- three-vrm（pixiv 官方）: <https://github.com/pixiv/three-vrm>
- TalkingHead（VRM lipsync 参考）: <https://github.com/met4citizen/TalkingHead>
- Open-LLM-VTuber（参考架构）: <https://github.com/Open-LLM-VTuber/Open-LLM-VTuber>
- Cocos Creator 4 文档: <https://docs.cocos.com/creator/manual/zh/>

---

## 附录 B：术语速查

- **BlendShape / Morph Target**：3D 模型的形变权重，控制嘴型 / 表情 / 五官变化
- **Animator / Mecanim**：Unity 的状态机动画系统
- **Viseme（视位）**：发音对应的视觉嘴型，多对一映射音素
- **Subtitle**：火山 RTC AIGC 下发的字幕事件，包含字内容和时间戳
- **SubtitleMode**：火山 RTC 配置项，0 = 对齐音频时间戳（端侧渲染用），1 = 不对齐（云端数字人用）
- **Function Calling**：LLM 调用工具/函数的能力，可被业务端解析触发动作
- **Cubism**：Live2D 公司的 SDK 品牌
- **VRM**：基于 glTF 的 3D 角色文件标准，pixiv 主导
- **全息光仓**：LCD 拆背光后的伪全息显示形态，黑像素=透明，亮像素=发光
- **Expandable Application**：Live2D 官方对 AI/Chatbot 类应用的特殊分类，需单独审核签约
