AR-Test-Demo/AI驱动虚拟形象渲染方案_v5.1.md

AI 驱动虚拟形象渲染方案 v5.1

跨产品形态统一架构调研

项目	内容
产品形态	① 罐子（Unity 3D + RK + 全息光仓，洛天依形象在跑） ② 洛天依 APP（独立 APP，Unity） ③ 小型硬件统一 APP（多设备入口，统一流量与用户） ④ ESP32-S3 小硬件（序列帧形态） ⑤ 未来 Live2D 形态 / 虚拟明星 / 写实数字人
当前底座	火山 RTC AIGC 全平台已跑通（手机 / 罐子 / ESP32-S3） 整套 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 人天，本周可全部完成。

---

二、修订后的数据流

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 端侧时间轴示例

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 类应用的特殊分类，需单独审核签约