这是「数字伴侣建造记」的第七篇。前几篇解决了记忆、声音和内容生成；接下来的问题是，这些能力换到桌宠上之后，用户还能不能正常使用。
本文按八月的设计与交接记录复盘。早期桌宠迁移方案后来被 Unity 接入总设计取代，不能把两份方案拼成同一个最终界面。交接记录确认了部分控制台接线与修复，但不足以逐项证明整个迁移计划都已验收。
消息到了，不代表功能到了
8 月 17 日的清点发现，桌宠能接到多种事件，却只真正处理了其中一部分。图像、视频、输入回显和录音状态等消息，进入了隐藏的日志区域。连接没有断，角色也在动，但发来的内容在这个界面里看不见。
这类故障很容易被“WebSocket 正常”掩盖。只验证事件送达，不验证它最后出现在哪里，仍会交付一个缺失功能的界面。
因此迁移清单要按用户能完成的事写：看见新消息、打开图片、输入并发送、得知录音状态、打断语音、回来补看。每件事都要追到可见的结果。
角色窗口和内容窗口分开
最初方案准备把媒体卡片放在角色气泡附近。后续 Unity 总设计改了方向：角色窗口负责桌面上的形象、动作与简短提示，图片、视频和历史交给独立内容窗口，角色侧只提示有新内容。
这样分工有两个直接好处。角色周围不必长期挂一整套应用界面；内容窗口则可以正常承载列表、灯箱和历史，而不必迁就角色轮廓。
输入条、麦克风、托盘与控制台也需要明确入口。透明区域应允许点击桌面，真实控件必须可点；输入时需要焦点，收起后又要恢复。崩溃或失焦后，同样不能留下挡住桌面的透明区域。
这些都是验收行为，不是把窗口设成透明就自动获得的能力。
更换渲染器，保留服务端职责
Unity 接入的目标是替换角色显示前端。记忆、对话、语音识别、语音生成和内容管线继续由服务端承担，Electron 保留托盘和内容界面。设计还提出少量向后兼容的端点与身份标签；因此“服务端不动”更准确的含义是保留核心职责，而非字面上的零行修改。
这个边界让迁移可以分阶段推进：先确认角色与透明窗口，再接说话、输入、通知和调校。每一阶段都应能退回旧前端，不必同时重写整个系统。
旧的预渲染舞台与模型转换配方也有保留价值。它们可以作为历史资产、映射依据或回退路径归档，而不必为了更换显示方式立即删除。
多个客户端，必须分清谁消费什么
同时开旧页面、桌宠与内容窗口，最危险的问题往往不是画面，而是重复或遗漏的副作用。
| 职责 | 记录中的问题或设计约束 | 验收时要看到什么 |
|---|---|---|
| 音频 | 服务端已播放时，新渲染器不应再播放一遍 | 一次发言只有一路声音，打断同步结束 |
| 连接恢复 | 原事件流没有序号与重放，重连不等于状态恢复 | 重连后重新拉取当前状态，界面与服务端一致 |
| 未读 | 有角色窗口连接，不代表用户正在阅读内容 | 按内容窗口的阅读状态计数和清零 |
| 积压消息 | 多个客户端都清空同一队列，会互相抢走内容 | 只有约定的消费者执行清空 |
| 模型调校 | 两套模型的键名不同，整份覆盖可能恢复或误改其他项 | 写入前比对键名，必要时分开模型命名空间 |
其中未读、运行时模型结构等服务端通道，在设计的 8 月 19 日补记中已有实现与实测记录。Unity 侧如何上报、显示和响应，则仍要按对应阶段单独验收。服务端端点存在，并不自动证明客户端行为成立。
这也是为什么“两个窗口都打开了”不能充当迁移成功的标准。需要断线、重连、开关窗口、切换模型，再看最终状态有没有重复、丢失或互相覆盖。
模型能导出，不代表在桌宠里正确
VRChat 模型转 VRM 的流程记录提供了另一组教训：文件生成成功，只是格式层面的结果。表情绑定、眨眼、口型、材质、骨骼与次级运动，还要在实际目标运行时检查。
检查分两层。结构审计确认引用与参数有没有缺失或非法值；视觉和动态回归则检查中性脸、各个表情、侧面与背面，以及转头、急停、抬手后回到待机的表现。数量多或少本身不是合格标准。
遇到物理异常，也不要立刻修改摇骨参数。先查可见对象和默认形变，再看蒙皮、静止姿态与约束，最后才到物理与碰撞。否则只是拿一层补丁掩盖另一层错误。
运行时专用修补还必须标清边界：它可能只在这个桌宠里生效，不代表导出的文件在其他查看器里已经修好了。Unity 原生显示和 VRM 转换是不同路线，也不能把一条路线的物理或材质行为直接套到另一条上。
把迁移验收写成一组动作
这批设计里值得延续的，是每一步都能独立检查与回退：
- 从干净启动开始，角色可见，透明处穿透，控件可操作。
- 输入一次，确认回显、声音和口型；中途打断，再看是否一起结束。
- 收到媒体后，打开内容窗口查看，再验证未读状态。
- 断开并恢复连接，检查状态重新对齐。
- 同开旧前端与新前端，确认音频、积压和调校不会互相争夺。
- 新方案失败时，能按记录恢复旧方案。
8 月 21 日的交接还记录了一个具体修复：动作停止指令使用了写死的 ID，切换动作时可能卡住，随后改为匹配实际动作。它提醒我，检查不能只看“第一个动作能播”，还要覆盖切换、停止和恢复。
从舞台走向桌宠，最值得保存的不是某个渲染器的名字，而是这些职责与验收条件。下一次换显示前端时，可以继续使用它们判断系统到底有没有接完整。