先确定“这一轮究竟要证明什么”
直播互动化同时跨越内容设计、外部消息、游戏运行和直播现场。把所有结果压缩成“已完成”会掩盖真正缺口。更可靠的方法是把验证拆成层级，每层只陈述实际观察到的结论。
六层验证门槛
| 层级 | 主要问题 | 可以形成的结论 | 不能替代的下一层证据 |
|---|---|---|---|
| 设计与静态检查 | 规则、状态和边界是否完整 | 方案或源码在静态层面一致 | 代码运行与目标环境行为 |
| 本地构建与模拟 | 代码能否生成，模拟事件能否通过局部链路 | 本地实现和指定模拟场景成立 | 目标游戏加载与真实输入 |
| 目标游戏运行 | Mod 或接口能否在指定游戏版本中加载和通信 | 目标运行环境中的接入路径成立 | 游戏世界内具体动作成功 |
| 游戏内生效 | 角色、资源或事件是否按预期改变并反馈 | 指定版本、存档和场景中的动作成立 | 真实主播和观众现场表现 |
| 真实直播 | 平台输入、主播承接和现场节奏是否成立 | 当次直播条件下的完整流程成立 | 多场次稳定性和持续运营 |
| 持续运营 | 多场次、版本变化、异常和规则迭代是否可控 | 已覆盖周期内具备持续运行证据 | 更大规模、商业发布或其他环境 |
层级不是越多越好，而是防止结论越过证据。例如，进程存在只能说明程序启动；连接握手只能说明通信建立；游戏内一次动作成功也不能推定真实直播已经稳定。
每条验收记录至少包含什么
一条可复核记录应包含：
- 验证目标：本轮只证明哪个动作、链路或场景；
- 环境：游戏版本、Mod 或客户端版本、运行方式和必要前置条件；
- 输入动作：由谁、通过什么方式触发了什么；
- 预期结果：游戏、画面、反馈或主播侧应该看到什么；
- 实际结果：成功、拒绝、失败或超时，以及可观察差异；
- 原始证据：截图、视频、日志或结构化回执的位置；
- 尚未验证：这条记录没有覆盖的场景和更高层门槛。
只写“测试通过”而没有环境、动作和边界，后续很难判断结论是否仍适用于新版本或其他直播条件。
技术验收要覆盖正常与失败路径
正常路径至少验证输入识别、规则映射、排队、游戏执行和结果反馈。失败路径应根据项目风险选择，常见项目包括：
- 重复或乱序事件是否被正确处理；
- 短时间集中输入是否超过容量；
- 当前游戏状态不允许时是否明确拒绝；
- Mod、接口或游戏尚未就绪时是否隔离失败；
- 连接中断、游戏重启或版本变化后能否安全恢复；
- 错误是否影响游戏主流程或阻塞后续事件。
模拟故障可以提前发现设计问题，但模拟结果仍需在目标环境中验证关键风险。
游戏内验收要看到动作与反馈
只确认消息被接收或日志出现记录还不够。游戏内验收需要观察目标对象是否存在、状态是否按规则改变、结果是否与原事件对应，以及画面或提示是否足够清楚。
当动作依赖特定地图、存档、阶段或角色时，记录必须说明这些前置条件。否则一次成功容易被错误扩大到所有场景。
真实直播验收要同时观察三方
真实直播不只看系统是否运行，还要同时观察：
- 观众侧：是否理解参与方式和结果，是否愿意继续参与；
- 主播侧：是否能及时看见、理解和承接事件；
- 游戏侧：集中输入下是否仍然稳定，异常是否可以恢复。
真实直播使用的平台账号、凭据和验证码应由授权人员控制，不能写入源码、普通发布产物或公开证据。
持续运营不是一次成功的放大
一次真实直播只能证明当次环境。持续运营需要覆盖多场次、不同节奏、版本更新、异常恢复和玩法调整，并记录哪些问题已经修正、哪些仍然限制扩大范围。
如果未来涉及客户交付、生产部署、商业发布或公开案例，还应分别建立对应候选、回滚、发布和授权证据，不能从本地或直播测试直接推定。
适用边界
这套方法用于组织验收结论，不代表仓库中现有实验已经通过所有层级。萌游互动实验室明确属于浏览器本地机制演示，不是目标游戏、真实抖音直播或商业项目案例。
可以先查看从直播间消息到游戏内事件确定技术验收点，再结合萌游事实与技术验证查看公司、公会和客户端现有证据的公开边界，最后通过互动化服务评估目标游戏的实际条件。