赛博小雅
全技术栈调查

结论先行

“赛博小雅”不是一套已经公开、可一键还原的单体项目。现有证据应拆成三部分：

1. 实时语音对话主链已经可以高置信度还原。作者教程画面显示的实际链路是：浏览器前端 hf-realtime-voice → Hugging Face speech-to-speech → Silero VAD → Transformers Whisper Large v3 → Responses API → llama-cpp-turboquant 的 llama-server → Gemma 4 E4B IQ4_XS → Qwen3-TTS（Torch/CUDA 后端）→ 浏览器播放。
2. 群内的高质量数字人教程路线是 SoulX-LiveAct。作者教程视频中的群收藏直接出现了文件名开头为 RTX5090_SoulX_LiveAct_数字女孩系统_最终完整版…方案.md 的约 50.75 KB 文档；群成员在复现视频评论中也独立指向 LiveAct。这证明的是“群内教程/复现路线”，不能反推原始爆款成片实时运行了 LiveAct。
3. 作者给 16 GB 家用显卡提出的可行降级方案是“已有视频，只实时换嘴”。作者没有公开所用口型模型名，也没有证据表明是 MuseTalk、Wav2Lip、LatentSync、HeyGem 或其他具体模型。
4. 没有找到公开代码证明 LLM 会自动把回答语义转换为角色表情和动作。LiveAct 本身确实支持文字 prompt/edit_prompt 控制表情和动作，也以音频驱动口型；但“LLM 情绪/动作标签 → TTS 时间轴 → LiveAct 分块提示词”的胶水层仍未公开。
5. 原始高完成度演示不能被描述为“本地实时数字人”。作者在视频简介中明确说受显存限制，实时数字人没有跑起来。逐帧观察只能证明画面使用了固定姿态的角色素材，并有嘴、眼和小幅面部变化；“预生成视频”“视频驱动头像”属于合理推断，具体生成模型未被作者确认。

因此，最准确的总判断是：

语音对话栈已确认；LiveAct 是作者群内确认的高质量数字人教程路线；家用显卡路线是已有视频加口型替换；原始成片的生成工具和语义到表情的自动编排器仍未公开。

一、证据等级

调查覆盖与边界

本次实际检查了：作者五个相关视频的简介、画面与评论楼中楼；四个主要复现视频及技术讨论；B 站公开接口返回的稿件、分 P 和评论数据；作者教程画面里露出的群消息和群收藏；GitHub、Hugging Face、arXiv 上游源码/权重说明；Penpos 的飞书资料入口及公开仓库；以及项目名、作者名、模型名、群文件名等组合关键词的公开网页索引。

本次没有加入或绕过权限读取私人 QQ/微信群，也没有下载来源不明的一键大包。群文件正文仍属不可见材料；报告只采用作者公开视频里能直接读到的文件名，以及群成员在公开评论中的旁证。公开搜索没有找到该群文件的可信镜像。因此，“已筛查公开论坛和可见群线索”不等于“穷尽所有私聊和封闭群记录”。

二、项目身份与视频时间线

作者规划过五个方向：Speech-to-Speech、llama.cpp、本地声音克隆、数字人、Vibe Coding。公开内容尚未构成一个完整仓库。

三、此前报告中需要修正的地方

四、已确认的完整语音与应用技术栈

4.1 总链路

浏览器麦克风
  │  Web Audio / PCM
  ▼
hf-realtime-voice（HTML + 原生 JavaScript + CSS）
  │  OpenAI Realtime 风格 WebSocket，端口 8765
  ▼
Hugging Face speech-to-speech（realtime 模式）
  ├─ Silero VAD：说话开始/结束检测
  ├─ Whisper Large v3：中文语音转文字
  ├─ Responses API 客户端：流式请求本地 LLM
  │    ▼
  │  llama-server.exe，端口 13631
  │  Gemma 4 E4B IQ4_XS + mmproj
  └─ Qwen3-TTS，Torch/CUDA：文字转语音
       │
       ▼
浏览器播放 + 可打断会话

4.2 分层清单

公开可对应的模型文件：Gemma 4 E4B IQ4_XS GGUF。教程中的 mmproj-Huihui... 本地文件没有找到完全同名的可靠公开页面，因此不能替作者指定下载源。

4.3 教程参数的可复核重建

本地 LLM 服务的可见要点：

llama-server.exe `
  -m <gemma-4-E4B-it-IQ4_XS.gguf> `
  --mmproj <mmproj-Huihui-gemma-4-E4B-bf16.gguf> `
  -c 16384 -ngl -1 -t 5 `
  --reasoning off --jinja `
  --host <局域网地址> --port 13631

语音服务的可见要点：

speech-to-speech `
  --mode realtime `
  --stt whisper `
  --stt_model_name "openai/whisper-large-v3" `
  --language zh `
  --llm_backend responses-api `
  --tts qwen3 `
  --qwen3_tts_language zh `
  --qwen3_tts_backend torch `
  --init_chat_prompt "<中文人设>" `
  --model_name "<Gemma GGUF 路径>" `
  --responses_api_base_url "http://<局域网地址>:13631/v1" `
  --responses_api_api_key "<占位值>" `
  --responses_api_stream `
  --enable_live_transcription False `
  --min_silence_ms 1800 `
  --thresh 0.7

网页前端另由 Uvicorn 运行在 7860 端口，并连接实时语音服务的 8765 端口。

4.4 应用层已经具备与尚未证明的能力

已确认：

• 初始化人设提示词；
• 单次会话历史；
• 语音开始/结束检测；
• 流式 STT、LLM、TTS；
• 浏览器端音频输入输出；
• 用户打断正在生成或播放的回答；
• UI 中选择 Qwen3-TTS speaker；
• 本地局域网分离 LLM 服务与前端。

尚未找到证据：

• 跨会话长期记忆、用户关系数值、事件日记；
• SQLite、向量数据库、RAG 或记忆摘要服务；
• 工具调用、桌面控制、日历、智能家居；
• 摄像头/视觉信息真正送入 mmproj；
• 情绪状态机、动作规划器、导演时间轴；
• AEC 回声消除、远场麦克风阵列或唤醒词；
• 完整身份验证、设备配对和产品化安全层。

这里必须区分“上游框架可以扩展”与“赛博小雅已经实现”。公开证据只能支持前一部分中的少量能力。

五、人物表现层：实际存在三条路线

5.1 原始高完成度演示：不是已证实的本地实时数字人

直接证据：

• 首个视频简介明确说明，因为显存限制，实时数字人没有跑起来。
• 作者估计若加入更大的本地模型，整套显存会超过 36 GB。
• 后续作者评论进一步表示，完整优化版数字人仍需 40 GB 以上显存。

逐帧观察：

• 角色长期保持手托头的固定身体姿态；
• 镜头、服装、背景和大部分身体像素高度稳定；
• 嘴部、眼睛和局部面部存在小幅变化；
• 视频间还插入表情包或影视画面。

由此只能作 D 级推断：高完成度画面更像预先生成/准备好的固定姿态素材，再与实时语音或局部面部驱动组合。作者没有确认 Seedance、Vidu S1、LiveAct 或其他具体生成器。

5.2 作者群内高质量教程路线：RTX 5090 + SoulX-LiveAct

两条互相独立的证据：

1. “本地大脑搭建”视频画面里的群收藏显示 RTX5090_SoulX_LiveAct_数字女孩系统_最终完整版…方案.md，文件约 50.75 KB；画面还感谢群友提供最难部分的教程。
2. AIwood 复现视频评论中，一名自称在作者粉丝群的成员说明，群教程的数字人采用 LiveAct，并向复现者转交了原文档。复现者随后也说 LiveAct 常驻显存很高。

第一条是作者视频中可见的 B 级直接证据，第二条是 C 级旁证。它们共同确认“群内教程路线”，仍不能证明 7 月 17 日原始演示实时使用了 LiveAct。

5.3 家用显卡降级路线：已有视频 + 实时换嘴

作者本人两次给出相同方向：

• 在数字人教程评论中说明，16 GB 本地即使使用社区优化版也只能动嘴。
• 当有人询问 SoulX-FlashTalk/16 GB 时，作者反问是否可以使用现有视频，只实时替换嘴部。
• 在 AIwood 的技术讨论中，作者再次建议尝试“只换嘴”。

可确认的是架构思想，不是具体模型。当前没有原作者证据支持以下任一项：

• MuseTalk；
• Wav2Lip；
• LatentSync；
• HeyGem/Duix；
• LivePortrait；
• ARKit/OVR LipSync；
• Live2D 参数口型。

MuseTalk 仅由评论者报告过：速度快，但其测试中唇音和下颌形变不理想。这不能归入原作技术栈。

六、最关键问题：语言、口型、表情究竟如何对应

6.1 LiveAct 官方能力给出的真实数据流

SoulX-LiveAct 是约 18B 级音频驱动、可文本编辑的实时长视频数字人系统，核心包含 Wan2.1 I2V 主干、音频模块、Wav2Vec2、UMT5、CLIP、VAE、Neighbor Forcing、ConvKV、DMD 蒸馏及多项 FP8/FP4/注意力优化。论文见 arXiv:2603.11746，模型页见 Soul-AILab/LiveAct。

其人物控制不是单一的“LLM 输出一个 emotion JSON”，而是三路条件合成：

条件图像 ──CLIP / VAE──────────────┐
                                      │  身份、外观、初始姿态和背景
回答文本 ──Qwen3-TTS──语音───────────┼─► LiveAct / Wan2.1 I2V ─► 连续视频帧
                         │            │
                         └─Wav2Vec2───┤  口型、节奏、音频隐含表情
                                      │
场景 prompt / 分块 edit_prompt ─UMT5─┘  显式表情、头部和身体动作

这三路分别承担不同职责：

LiveAct 官方编辑样例使用分块指令控制诸如鞠躬、睁大眼睛、苦笑、疑惑和挥手。JSON 键是生成块索引，不是天然的秒数或单词时间戳。

6.2 口型不是“文字直接对应嘴形”

LiveAct 路线的实际关系是：

LLM 文字
  └─► Qwen3-TTS 波形
        └─► Wav2Vec2 连续音频特征
              └─► 生成模型学习出的逐帧嘴部运动

因此：

• 没有发现汉字/拼音到 viseme 的手写字典；
• 没有发现 ARKit blendshape、Live2D ParamMouthOpenY 或音素时间戳接口；
• 口型由语音波形的神经音频特征驱动，模型从训练数据中学习音画对应；
• 语言文字只有先成为 TTS 音频，才参与这条口型链路。

这解释了为什么同一句话换语速、停顿或音色后，口型和面部节奏也会变化。

6.3 表情有“隐式”和“显式”两层

1. 隐式表情：TTS 的音高、节奏、音量和停顿进入 Wav2Vec2 音频特征，模型可能产生与语气同步的眉眼、头部和嘴角变化。这是生成模型的统计学习结果，不是可审计的情绪状态机。
2. 显式表情/动作：外部程序把动作或表情描述写进 prompt/edit_prompt，由 UMT5 编码，并在指定生成块生效。

Qwen3-TTS 自身支持声音风格和指令控制，但作者公开命令只显示语言、speaker 和 Torch 后端；没有显示参考音频、参考文本或 instruct 参数。因此不能确认“小雅”当前语音使用了克隆样本或专门的情绪提示。

6.4 原作真正缺失的应用胶水层

若要实现用户所说的“语言与口型、表情对应”，还需要以下中间层：

LLM 生成：回答文本 + 情绪/动作计划
            │
            ├─► TTS 生成音频，并返回字/句时间戳
            │
            ├─► 把情绪和动作计划换算成 LiveAct 生成块索引
            │
            └─► 在对应块写入 edit_prompt

调查没有找到以下任一公开实现：

• LLM 输出 emotion/action/intensity 结构的 schema；
• 将中文回答自动分类成表情和动作的导演器；
• 从 Qwen3-TTS 获得词级时间戳并映射到 LiveAct block；
• TTS 流与视频生成流的 A/V 时钟同步器；
• 打断时同时取消 TTS、视频生成和动作队列的状态机；
• 角色表情冷却、动作冲突消解或镜头连续性逻辑。

LiveAct 官方示例里的 edit_prompt 是预先人工编写的。现有“赛博小雅”证据中，没有看到 speech-to-speech 自动输出这些提示词，也没有看到两套服务之间的适配器。因此，不能声称原作已经实现了“LLM 理解语义后自动选择精确表情和动作”。

6.5 原始成片里最可能的对应关系

按当前证据，可作如下分层判断：

七、相关数字人方案对照：哪些属于原作，哪些只是复现候选

LiveAct 的官方单 5090 测试约 6 FPS，这与“5090 群教程能跑”并不矛盾，但与“完整质量 20/24 FPS 实时对话”不是一回事。复现者在 4090 上的量化测试甚至报告生成 1 秒画面约需 15 秒，也说明模型“能启动”与“交互实时”必须分开。

八、几个公开复现实际用了什么

8.1 AIwood 爱屋研究室

复现视频说明其语音链沿用 Hugging Face speech-to-speech，人物层测试过 Duix-Avatar、FlashHead，并讨论 LiveAct。评论中群成员提供了 LiveAct 教程文档，但复现者也明确指出其显存负担很高。

该复现能够证明不同人物后端可接到相同语音链，不能用来证明原作者用了 Duix 或 FlashHead。

8.2 Penpos 一键包

复现视频评论里的运行日志暴露了另一套明确架构：

• Qwen3 LLM；
• Whisper；
• Qwen3-TTS；
• HeyGem GPU 服务 127.0.0.1:8383；
• 口型方案标为“视频驱动”；
• UI 7860、LLM 8080、Realtime 8766、HeyGem 8383。

其公开资料页为飞书文档，相关 penposs/HeyGem.ai 是 HeyGem fork，不等于当前一键包完整源码。仓库显示的 Docker 服务包括 Fun-ASR、Fish-Speech 和 HeyGem SDK，API 接收 audio_url 与 video_url。

这是可运行的第三方应用层替代方案，但模型、端口和后端都与作者教程不完全相同。

8.3 一起 Vibe

复现视频的作者在评论中确认人物层使用 FlashTalk；其 4090 量化单角色版本一次回答需要数分钟，视频剪辑隐藏了生成等待。官方真正实时配置则是多张 H800。

8.4 wangyi_AI_Studio

复现视频使用 RTX PRO 6000 级硬件。作者在评论中明确表示普通 5070/5090 不够其方案运行。这同样不能代表原作者硬件要求。

九、作者评论证据索引

为便于再次核验，以下保留视频与评论 ID；文字采用摘要而非扩写：

这些评论在 2026-08-01 通过已登录的本机 Chrome 与 B 站公开接口交叉查看。评论可能被作者或平台后续编辑、折叠或删除，ID 用于保留本次调查时点。

十、最终技术栈清单

10.1 可归入原作者公开项目

• Windows；
• NVIDIA CUDA、PyTorch；
• Hugging Face speech-to-speech realtime server；
• Silero VAD（具体版本未确认）；
• Transformers Whisper Large v3；
• Responses API 流式客户端；
• llama-cpp-turboquant / llama-server.exe；
• Gemma 4 E4B IQ4_XS GGUF；
• Huihui 命名的 Gemma 4 mmproj 本地文件；
• Qwen3-TTS Torch 后端；
• hf-realtime-voice 浏览器前端；
• HTML、原生 JavaScript ES Modules、CSS、Web Audio、WebSocket；
• FastAPI/Uvicorn 静态页面服务；
• 初始化人设 prompt、会话流和打断；
• 群内数字人教程：SoulX-LiveAct；
• 家用显卡降级思路：已有视频 + 实时局部换嘴。

10.2 不能归入原作者已确认技术栈

• Faster-Whisper；
• Silero VAD v5 的精确版本断言；
• Qwen 27B 作为教程当前 LLM；
• Live2D、VTube Studio、Unity、VRM；
• MuseTalk、Wav2Lip、LatentSync、HeyGem、Duix；
• FlashTalk、FlashHead；
• Seedance 或 Vidu S1 作为原始成片生成器；
• SQLite、向量数据库、RAG、长期记忆；
• 自动 emotion/action JSON；
• LLM 到 LiveAct edit_prompt 的自动导演器；
• “全程由 Codex 完成”。

后一组并非都不可能，而是现有证据不足，不能冒充调查结论。

十一、仍缺的关键材料

若要把“所有技术栈”从高置信度调查提升到源码级确认，还需要以下任一材料：

1. 群收藏中的 LiveAct 完整方案文档；
2. 作者数字人章节的后续公开视频；
3. speech-to-speech 与数字人后端之间的启动脚本或 Python adapter；
4. 原始演示使用的基础视频、参考图和生成任务记录；
5. 口型服务的进程名、端口、模型权重或请求日志；
6. LLM 回答、TTS 音频与视频帧的同一段时间轴日志。

在这些材料出现前，最重要的未决问题不是 LiveAct 本身如何驱动表情——其官方源码已能回答——而是作者有没有、以及如何把 LLM 的语义计划自动转换为 LiveAct 的分块编辑提示词。当前公开证据对此仍是空白。

十二、主要来源

原作者视频

• Vibe Coding 我的赛博女友
• 我的赛博女友才不会这么可爱
• 赛博女友小雅录屏
• 赛博小雅本地大脑搭建
• 赛博小雅教程之二

上游官方项目

• Hugging Face speech-to-speech
• hf-realtime-voice
• llama-cpp-turboquant
• Qwen3-TTS
• SoulX-LiveAct
• SoulX-LiveAct 论文
• SoulX-FlashTalk
• SoulX-FlashHead
• Vidu S1
• Vidu S1 论文
• Duix-Avatar

复现与旁证

• AIwood 爱屋研究室复现
• Penpos 复现
• 一起 Vibe 复现
• wangyi_AI_Studio 复现