QNI 房间功能与 Wira/Laboo 建设优先级研究#

实测日期：2026-08-18（Asia/Hong_Kong）
QNI 版本：1.6.2；包名：com.heartgo.loong
实测房间：霸总的船坞（30180581）
证据口径：界面实测、UI XML、静态资源证据、产品推断分层记录

1. 结论摘要#

QNI 的房间不是单一语音页面，而是一个由“实时房间底座 + 房型插件 + 房主管理台 + 游戏内容 + 经营增长”组成的产品操作系统。若 Wira/Laboo 直接从单个游戏开始复制，容易得到能玩的 Demo，却缺少让玩法持续发生的房间供给、身份权限、麦位实时状态、开局编排和治理能力。

业务上的第一优先不是复制更多游戏页面，而是完成一个可复访的房间开局闭环：发现房间 → 进入 → 上麦 → 开启已有 H5 → 准备/开局 → 结算 → 返回来源房间/再次进入。因此 P0 必须同时覆盖房间生命周期、角色治理、RTC/麦位、游戏容器、统一开局结算、公共列表、异常恢复和核心漏斗监控。任何一项缺失都会让“房间有页面但业务跑不起来”。

用户已明确 24 个玩法 Box 游戏均已在 bluebone-ai/wira-mini-games 开发完成，因此它们不再进入“重做玩法细节”的研发队列；优先级改为“接入房间容器、补实时上下文、补开局/结算/治理”。内容侧需要区分两种第一名：挖宝达人是本轮样本中的业务价值第一，但当前源码目录未同步；引力球是可立即开工第一，已有源码、成绩、排行和播报证据，不应等待挖宝源码而阻塞首期闭环。

本轮房间列表为单时点、单轮限页样本。按“在线人数 60% + 活跃房间数 30% + 曝光位置 10%”计算，挖宝达人以少量房间承载高在线密度居首；音乐杀 2v2 和我猜歌贼6以房间供给和稳定曝光居后。它能指导第一轮验证优先级，不能替代跨时段 DAU、开局率和留存数据。

2. 研究边界与证据等级#

2.1 安全边界#

• 未启动正式多人对局，未邀请用户，未发消息，未送礼或消费。
• 未踢人、未添加管理员、未公开广播；高风险操作只查看入口或确认页。
• 未找到“仅本人、无处罚、无冷却提示”的明确解散入口，因此没有解散并重建房间。
• 遍历结束后已恢复最初的“聊天交友 / 6 麦位”布局，房间玩法已关闭，卡顿优化与免打扰保持 OFF，语音识别保持“默认”，背景音乐为空；最终停留在自己的房间 30180581。系统三项动画倍率均已恢复为 1.0。

2.2 证据等级#

3. 创建房间链路#

3.1 实测流程#

flowchart LR
    A["我的房间"] --> B["我的管理"]
    B --> C["还未创建房间"]
    C -->|"去创建"| D["系统零配置创建"]
    D --> E["自动生成房名与房号"]
    E --> F["房主直接进入房间"]
    F --> G["设置房型、麦位与管理项"]

创建入口没有表单，也没有先选主题、类型或人数；“去创建”是一步完成的强转化动作。系统生成房间“霸总的船坞”（30180581）并直接进入房主视角。创建后，配置动作被后置到房间内设置页。

关键状态与文案：

创建前截图缺口是本轮唯一关键缺口：已有 UI XML 能证明“还未创建房间 / 去创建”状态，但在确认安全解散条件前已经完成创建。为保护账号房间，不进行破坏性重建，也不制作伪造截图。

4. 房间页面的信息架构#

房间主界面可拆成五层：

1. 顶部身份层：房名、房号、在线/成员入口、更多菜单。
2. 场景层：全屏主题背景、房型插画、游戏状态提示。
3. 实时席位层：房主/管理员/玩家席位、空位、准备、上麦与专属席位。
4. 内容操作层：邀请、准备/开局、点歌、加入对局、聊天答题等房型动作。
5. 全局工具层：消息输入、礼物、房间工具、更多菜单、设置。

房型切换并非只换皮肤：它会重建席位结构、开局规则和底部动作，部分切换明确提示“其余麦序会清空”。因此在技术模型中，roomType 应是驱动房间状态机和插件装配的一级字段，而不是普通展示标签。

5. 房型、文案与玩法逻辑#

5.1 房型总览#

完整 14 条房型/子模式记录见 room_types.csv。

5.2 共用状态机#

stateDiagram-v2
    [*] --> 房间空闲
    房间空闲 --> 招募中: 邀请/加入/上麦
    招募中 --> 准备中: 玩家进入席位
    准备中 --> 可开局: 满足人数且必要玩家已准备
    可开局 --> 对局中: 房主或管理员开始
    对局中 --> 结算: 玩法结束
    结算 --> 房间空闲: 再来一局/返回房间
    房间空闲 --> 类型切换确认: 房主修改房型
    类型切换确认 --> 房间空闲: 重建玩法壳与麦位

这套共用状态机比具体游戏更值得优先实现。小游戏只需要提供人数、准备条件、房型组件、对局同步和结算适配，就能挂到统一房间壳里。

6. 房主管理工具：细节与逻辑#

已记录房主管理设置、14 个“房间玩法”、8 个“房间工具”、8 个“基本功能”和 5 个独立经营入口。旧版报告把经营活动误归到“房间玩法”，本轮已按真实菜单层级纠正。完整覆盖见 menu_coverage_matrix.csv，管理设置见 management_tools.csv。

6.1 生命周期与基础配置#

• 房间名称：“霸总的船坞”，字符计数 5/14。白色居中弹窗，确定前不落库。
• 房间公告：“输入房间公告”，最大 0/1000，右上“发布”。它适合长文本规则，不等同短房名。
• 房间密码：限定 1–8 位数字。应在加入链路拦截，而非只做房内设置。
• 房间背景：双列大图卡片，包含免费/持有/锁定和动态标记；背景同时是装扮资产和经营入口。
• 公开展示、专属席位等使用系统式开关；修改是即时状态，不进入二级保存页。
• 房间类型和麦位布局使用底部选择面板，重要变更出现二次确认。

6.2 成员、角色与安全治理#

• 管理员列表为空；入口证明房主可委派管理角色，但本轮未添加真实用户。
• 管理日志实际记录了“开启房间”和所有房型切换，说明高影响操作进入审计链路。
• 黑名单空态文案“无人被流放至此”，采用拟人化世界观表达，同时承担封禁名单功能。
• 房主/管理员拥有切换房型、开局等关键权限；普通玩家受准备、上麦和人数规则约束。

6.3 音频、麦位与实时互动#

• 上麦权限有“需申请 / 自由上麦”，它决定排麦流量是否进入管理员审批。
• KTV 进一步出现点歌权限，表明“在房间里”和“能上麦”“能点歌”是三层不同权限。
• 专属席位默认开启，房间头部提供两个特殊座位；静态文案表明房主/管理员可落座。
• “蓝牙设置”在当前设备状态下置灰，“卡顿优化”独立提供，说明音频路由和弱网治理被暴露为用户工具。

6.4 房间工具：8 项完整清单#

投票和 AI 计分攻略的 WebView 本轮均出现真实黑屏，不能据此推断为“没有功能”，只能记录“当前版本/网络下内容未加载”。

答题器实测字段包括：

• 题目输入 0/20。
• 参与范围：“全部用户 / 麦上用户”。
• 结束方式：“手动结束 / 倒计时结束”，倒计时上限 120 分钟。
• 允许多个答案。
• “展示用户答案”默认开启；帮助文案：“开启后用户可看到他人回答”。
• 主动作“创建”，只有创建后才进入进行态。

对应截图：答题器配置、帮助文案、倒计时。

6.5 玩法 Box：24 项基础玩法与房间接入逻辑#

按最新范围，24 个玩法 Box 游戏不再在 QNI App 内逐项启动和深挖；基础玩法改为直接读取用户已完成的 wira-mini-games 实现。本轮本地源码快照可核验 20 个目录：其中 13 项同名映射、2 项品牌替换映射、5 项概念/命名映射待产品确认；挖宝达人、剪影墙、成分鉴定瓶、雪战上海滩 4 项尚未出现在本地 catalog/games.json，因此只记录用户确认“已开发”和 QNI 卡片顺序，不凭名称补写规则。

逐项的目标、操作、人数/关系、结束结算、房间联动、限制与源码路径见 game_box_basic_gameplay.csv。以下是可直接放入 PRD 的基础玩法摘要：

从代码而不是游戏名称出发，可将 20 个已核实现抽象成六类能力包：

1. 单人计分与闯关容器：击飞喵、碰壁弹球、摩天楼、引力球、奔向 Qni 星、熊猫上树、双人成行、高雅企鹅下楼、牛马快跑、乌萨奇报到。共用开始/暂停/失败/重开、成绩上传、排行榜、房间高光和结果播报。
2. 单人经营与长期进度：水果串串、色块消消乐。除单局状态外还需要图鉴、积分、道具/商店、皮肤和存档，房间榜必须区分新开局与读档局。
3. 图片 UGC 与社交表达：我拼你猜、奖状打印机、表情合成工坊、拼好图。共用 Canvas/图片生成、上传、房间图片消息、审核、删除和失败重试。
4. 内容驱动测试/叙事：QniTI、平行人生。规则主要由题目、结果、事件、天赋和成就 JSON 驱动，适合复用结果卡、分享与召回，而非做实时对战。
5. 异步陌生人互动：漂流瓶。它本质是带次数、消息和治理的内容社区，不是普通单机小游戏。
6. 房间多人服务工具：房间抽奖工具。它直接读写房间成员和角色状态，需要后端权威时钟、定时开奖、幂等结果与创建者治理。

共同接入状态机应统一为：房间入口 → 规则/配置 → 开始或创作 → 过程状态 → 结算/产出 → 排行/广播/分享 → 返回来源房间。其中单人游戏只上行事件和成绩；UGC 工具上行图片/内容；漂流瓶和抽奖工具必须由后端维护权威业务状态。这个分层能避免为了“房间化”错误地把 20 款单机游戏全部改造成多人同步游戏。

6.6 房间玩法：14 项与共用结构#

真实“房间玩法”不是魔法许愿池等商业活动，而是以下 14 项：歌手PK、翻牌小铺、呼噜噜派对、飞行棋、谁是卧底、命悬一线、女巫的毒药、找猫猫、谐音梗猜图、马赛克猜图、图片猜猜猜、脑筋急转弯、图形推理、巧算24点。逐项规则、角色、人数和证据见 room_gameplay_activities.csv。

共用逻辑：

• 房间同一时间只能运行一个房间玩法；切换时必须确认，聊天区会出现“已开启房间玩法-xxx”。
• 已开启玩法的三点菜单固定为“切模式 / 换游戏 / 关闭”，关闭仍需二次确认。
• 找猫猫及后续六个题库型玩法复用同一主持容器：标题、红色“主持”徽标、题面、“答案”“下一题”和 1–3 秒倒计时。
• 主持题库引擎有两种模式：“主持模式”可直接查看答案；“主持同玩模式”需要公布答案后主持人才可看到答案。
• 飞行棋、谁是卧底、命悬一线、女巫的毒药是多人实时玩法；空房只验证参与/观战落地页，不启动正式对局。
• 歌手PK是两人正式会话，空房仅验证入口、规则和最近 7 天历史空态。

这 14 项不应按 14 个独立项目实现。建议抽象成四个引擎：主持题库引擎、多人房间状态机、双人PK引擎、低实时活动容器。其中找猫猫到巧算24点的 7 项可由同一题库 Schema 驱动，优先级显著高于逐页复制。

6.6.1 游戏题库：6 类 56 条全量目录与深层内容#

本轮从房间看板“更多 → 题库”进入独立的“游戏题库”页面。除“我的”空态外，公共题库共有 6 个分类；各分类均持续滚动到“没有更多了”，因此下表是 2026-08-18 当前账号、当前版本可见目录的单时点全量快照，不是静态资源推断，也不保证服务端以后不增删。

关键状态与原始文案：

• 列表卡片由“标题 + 使用次数 + 图片或简介 + 右箭头”构成；选中后变为白色描边，并出现白色 CTA“就玩这个”。视觉证据见 题库总入口 和 海龟汤列表。
• 房间已有题目时切换会提示“看板已有题目，是否使用新的题目？”，按钮为“否 / 是”；这证明题库遵循单看板、替换式状态机，而不是并行挂载多题。
• 房间看板使用“题目 / 答案 / 对局介绍”，编辑页使用“题目 / 答案 / 游戏介绍”；编辑页提供原始文本和字符上限，是最稳定的内容证据入口。
• 海龟汤答案固定包含“组织者手册 → 可提示 → 汤底”，主持人只能通过提问引导玩家还原真相，不应直接提示。完整样例证据见 兄弟答案；其余 19 条见 181–199 截图/XML。
• 看图猜词答案分别保存为“台北/桃园”“一见钟情/胸有成竹”“汤唯/周杰伦”“香水百合/爱的主打歌”，并统一提示可逐级给线索、可设置奖励；证据见 201–204。
• 谁是卧底要求主持人私聊发词，以骰子或猜拳决定首位发言者；每轮用投票器淘汰，卧底数等于平民数时卧底胜，卧底全淘汰时平民胜，还可启用“卧底出局后猜中平民词仍获胜”的特殊规则。证据见 205–210。
• 关闭入口位于“更多 → 关闭”，最终确认文案为“确定关闭玩法Box吗？”。关闭后题目看板消失、房间恢复 6 麦位，证据见 关闭确认 和 恢复房间。

产品抽象上，这 56 条内容应统一进入 QuestionBank / QuestionItem / Answer / HostHint / Media / RuleSet / Version 七层模型；海龟汤、看图猜词和主持问答可先走低实时内容引擎，谁是卧底再叠加私密发词、角色、轮次、投票和权威结算。Pia戏与情景模拟属于长文本内容模板，不应和实时对局状态硬编码在同一页面。

6.7 基本功能：8 项#

证据：完整菜单、分享、我想玩帮助、卡顿优化、语音识别。

6.8 经营、商业化与增长#

• 基本功能顶部横向承载 5 个独立经营入口：魔法许愿池、对对碰、实物对对碰、绮遇衣橱、礼品兑换。它们不是“房间玩法”。
• 魔法许愿池：50/500/1500 钻石许愿 1/10/30 次；心愿值、概率表、可赠送物品和活动后保留的心愿商店构成完整抽奖循环。
• 对对碰：以钻石购买福蛋并选择幸运色；888/1288 钻石档，提供奖励、成就、排行、装扮匣与概率公示。
• 实物对对碰：先用实物币购买“喵布袋”，九宫格对碰后实物奖励进入储物袋；发货必须填写地址并另付运费。
• 绮遇衣橱：50/475/2250 钻石抽 1/10/50 次；523 幸运值保底，抽中套装即归零；奖池幸运值相互独立；支持赠送、装扮匣与心愿水晶商店。
• 礼品兑换：输入有效兑换码后“立即兑换”才可用；本轮无兑换码，保持禁用。
• 对对碰返回时实测发生一次“原房间上下文丢失”：容器落到公共房间并弹出等级奖励/6元福利层。未购买或领取，随后通过房间切换器退出公共房间并恢复 30180581。这应被视为宿主容器返回栈的 P0 风险。
• 房间支持按周统计贡献；任意用户在房间内消费均可计入，周一 0 点结算。门槛从 20 万、60 万、100 万、200 万、400 万逐级上升，奖励包括 K 豆、限时装扮和礼物。
• 收藏页同时展示累计收藏、今日新增和派对邀请；邀请频率为每天一次，并以最近 7 天关系作为召回线索。
• 礼物、宝箱、排行、贡献奖励与小游戏不是孤立模块，它们共同构成“进房—互动—消费—贡献—召回”的经营循环。

7. 截图样式与原型规范#

7.1 视觉层级#

7.2 组件规律#

• 顶部房间信息始终压在背景上，不单独占白色导航栏。
• 房型/模式选择优先使用图示卡片，而权限、布尔项使用开关或单选行。
• 可逆低风险项倾向即时开关；会清麦序、改变玩法壳的操作必须确认。
• 空态文案带世界观和情绪，例如“无人被流放至此”，降低管理后台的冰冷感。
• 玩法规则通过短 Tips 就近呈现，例如最少人数、谁能换牌、谁能开始，不把玩家赶到长规则页。
• 重要操作的主按钮保持单一、高对比；房型切换到聊天时使用更有情绪的“狠心切换”。

7.3 截图使用建议#

原始截图适合事实核验；screenshots/prd/ 中的精选截图适合 PRD 页面拼贴。做正式外发文档时，应再遮盖第三方昵称、头像和房号。本素材包保留原始界面，以免脱敏破坏位置、字号、截断和状态判断。

8. 房间列表单轮热度采样#

8.1 口径#

• 采样时间窗口：约 2026-08-18 11:09–11:16（HKT），依次切换标签，不是并发快照。
• 覆盖 7 个可访问标签：热门、KTV、闲聊唠嗑、创意玩法、音乐杀、我猜歌贼6、其它游戏。
• 原始 90 条曝光记录，按“分类 + 房间号”去重后 66 条。
• 短列表连续页面无新房号时停止；长列表执行一轮限页采样。热门 4 页，其余 3–4 页。
• 同一房间可在不同标签重复曝光；游戏热度汇总时按房号去重，在线人数取本轮窗口内可见最大值，曝光取最佳位置。

8.2 标签样本#

注意：这些在线数是页面中可见房间的合计，不是分类全站并发，也不能跨分类直接相加为平台总在线。

8.3 游戏热度榜#

完整榜单和可复算分项见 game_heat_scores.csv，原始观测见 room_observations_raw.csv，去重表见 room_observations.csv。

9. 六大能力模块抽象#

flowchart TB
    R["房间产品操作系统"] --> A["1 生命周期与基础配置"]
    R --> B["2 成员、角色与安全治理"]
    R --> C["3 音频、席位与实时互动"]
    R --> D["4 游戏与内容编排"]
    R --> E["5 房间经营与商业化"]
    R --> F["6 增长、分发与数据运营"]
    A --> A1["创建/进入/退出/公开/密码/公告/背景"]
    B --> B1["房主/管理员/权限/黑名单/日志"]
    C --> C1["RTC/上麦/排麦/音频路由/专属席位"]
    D --> D1["房型插件/准备/开局/规则/结算"]
    E --> E1["礼物/宝箱/贡献/排行/活动奖励"]
    F --> F1["分享/收藏/邀请/曝光/召回/反馈"]

模块之间的依赖顺序是 A+B+C → D → E+F。经营和增长并不是不能提前设计，但在没有稳定的进入、语音、身份和开局闭环前，不应成为研发主线。

10. QNI → Wira/Laboo 能力映射#

逐项映射见 wira_mapping.csv。这里的“现状”只依据当前本地 Wira H5 仓库，不推断未纳入仓库的原生客户端能力。

11. 业务优先级与建设路线图#

11.1 全局第一优先：先跑通一个可复访的真实房间#

首期只用一个结果验收：6 名用户可以从公共列表进入同一房间，上麦并启动一款已有 H5 游戏，完成准备、开局、结算、再来一局或退出；断线后能恢复，退出游戏后回到来源房间。

flowchart LR
    A["P0 房间闭环与安全"] --> B["P1 首批内容供给"]
    B --> C["P1 互动与留存"]
    C --> D["P1-P2 增长与召回"]
    D --> E["P2 商业化"]
    A --> F["P0 数据可观测"]
    F --> B
    F --> C

P0 内部严格顺序如下；这些是一个上线闸门，不建议拆成相互独立的“以后再补”项目：

板块一：房间核心闭环与安全#

11.2 分板块业务排序#

板块二：游戏与内容供给#

板块三：房间互动与留存#

1. 主持题库引擎：同一套题库、答案权限、主持/同玩、下一题和广播，一次覆盖找猫猫到巧算24点 7 个玩法；现有 56 条目录、20 条海龟汤、4 类看图答案可直接作为首批验收数据。
2. 投票、答题器、AI 计分器插件：不绑定单个游戏，为主持、活动和普通语聊房提供随时可用的互动工具。
3. 题库 CMS 与版本治理：分类、排序、图文/音频题面、答案、主持提示、上下线、版本、审核与数据反馈；先支持低实时主持题库，再扩长文本剧本。
4. 图片 UGC 能力包：统一图片生成、上传、公屏图片、审核、删除和失败重试，一次覆盖我拼你猜、奖状打印机、表情合成工坊、拼好图。
5. 多人玩法公共引擎：角色私密信息、轮次、投票/输入、观战、重连和权威结算；其中 90 组谁是卧底词对可复用内容层，但私聊发词、投票与结算必须使用后端实时能力。
6. 基本功能完善：私聊、免打扰、我想玩、蓝牙/耳返、卡顿优化和语音识别偏好，不阻塞首个开局闭环。

板块四：增长、分发与召回#

1. 分享、邀请与 Deep Link 回房：外部/站内邀请直接落到目标房间，失败时给出房间关闭、满员或密码兜底。
2. 收藏、访问历史和再次进入：解决用户离开后找不到原房的问题，承接 7 日访问记录和房间失效状态。
3. 房主运营反馈：先埋曝光、进房、上麦、开局、结算、邀请和收藏转化，面板可在数据稳定后上线。

板块五：经营与商业化#

1. 礼物、钱包、资产账本和风控：先建立扣款、到账、失败/退款和资产记录，作为所有房间经营的可信底座。
2. 房间支持与贡献奖励：礼物账本稳定后再做周贡献、等级、K豆/奖励选择、分配窗口和历史领取。
3. 房间背景与装扮：轻量增强辨识度和付费表达，但不优先于开局和留存。
4. 许愿池、对对碰、衣橱等付费活动：涉及概率、赠送、储物袋、实物履约和客服，放到房间留存及账本稳定之后。

板块六：数据运营与质量#

1. 核心漏斗与故障监控随 P0 同期上线，而不是版本结束后补埋点。
2. 内容与 UGC 治理必须早于漂流瓶、图片 UGC 和公共房间全面开放。
3. 运营配置与灰度先提供房型/游戏最小开关，内容规模增长后再扩展分类排序、题库版本和灰度人群。

完整 29 项分板块排序、首期范围、依赖和可开工状态见 business_priority_by_module.csv。

11.3 首期范围与明确不做#

首期建议只覆盖 P0 闭环，并选两到三款内容验证容器：引力球 + 房间抽奖工具 + QniTI。若挖宝达人源码及时同步，则把挖宝加入首期经营型样板，但不等待它阻塞容器和房间底座。

首期明确不做：一次性接完 24 款游戏、完整 KTV 曲库、音乐杀 2V2、复杂多人棋盘/身份局、房间贡献奖励、概率付费活动、实物兑换和全量装扮商城。这些功能不是价值低，而是会把首个可验证闭环拆散。

11.4 玩法 Box 24 项房间化接入排序#

用户已完成玩法 Box 游戏开发，因此这里排序的是“接入房间体系的先后”，不是重做游戏。评分口径为：本轮列表热度 35% + Box 展示位置 15% + 核心互动价值 20% + Wira 复用度 20% + 实现成本反向分 10%。Box 位置只代表 QNI 产品供给侧强调程度，不当作用户热度。

没有游戏达到 P0：P0 留给房间生命周期、角色权限、RTC/麦位、游戏容器与实时状态协议。24 项逐项分数、判断和置信度见 game_integration_priority.csv。

11.5 P0 能力评分补充#

1. 房间生命周期与基础配置（90）：一键创建、进入、退出/最小化、公开列表、房名、公告、密码、背景、房型。
2. 成员角色、安全与管理日志（82）：房主/管理员/成员权限矩阵、黑名单、敏感动作确认和审计。
3. 语音、麦位与实时状态（80）：RTC、上麦申请、自由上麦、排麦、主持席、音频路由、弱网状态。
4. 游戏容器与房间内启动编排（93）：把现有玩法接入统一房间上下文 Bridge，定义准备/开局/结算协议、断线重连和多端生命周期。

这里的分数衡量综合价值，不等于研发串行顺序；真正的业务实施顺序以 11.1 的 P0 闸门表为准。P0 验收不以“页面做完”为准，而以 6 人房间可以创建、进房、上麦、准备、启动已有 H5 游戏、结算并安全退出为准。

11.6 P1：先接入已有游戏，再做共用玩法引擎#

1. 挖宝达人 + 引力球首批房间化：前者是本轮热度第一，源码同步后验证经营型玩法；后者本地目录可直接核对，可先行验证实时操作型玩法，不互相阻塞。
2. 主持题库引擎：一次支持找猫猫、谐音梗猜图、马赛克猜图、图片猜猜猜、脑筋急转弯、图形推理、巧算24点，统一题库、答案权限、下一题倒计时和房间广播。
3. 音乐杀 1V1/2V2：验证同步对战、AI 补位、曲目风格和双模式房型。
4. 我猜歌贼6：验证双队、文本旁路答题和题库运营。
5. 宿主返回栈修复：经营活动退出后必须回到来源房间，不得落入公共房间或触发无关付费/等级弹层。

11.7 P2：提升复用、经营和召回#

• 投票、答题器与 AI 计分器：做成房间工具插件，而不是某游戏私有功能。
• 收藏、邀请与房间召回（51）。
• 房间背景与装扮资产（47）。
• 房间支持与贡献奖励（43）：待礼物/消费链路稳定后上线。

11.8 P3：长尾和高成本内容#

• KTV 完整点歌体系（39）：本轮样本热度低，且受曲库版权、音频链路和演唱体验影响，先保留房型接口。
• 盖个摩天楼房间化（38）：已有资产可低成本接入，但本轮热度较低，排在主验证玩法之后。

评分明细见 feature_priority.csv。优先级公式为：关联房型热度 45% + 核心链路依赖 25% + Wira 复用度 20% + 实现成本反向分 10%；P0 ≥ 80、P1 60–79、P2 40–59、P3 < 40。

12. 建议的 PRD 数据模型#

Room
├── identity: roomId, name, ownerId, createdAt
├── configuration: roomType, subMode, seatLayout, password, public, background
├── governance: roles, permissions, blacklist, operationLogs
├── realtime: members, seats, micQueue, audioState, connectionState
├── session: phase, readyUsers, minimumPlayers, starterRole, gameContext
├── economy: gifts, contribution, rewards, ranking
└── growth: collection, invitations, exposureSource, revisitState

所有重要文案应由状态驱动：人数不足显示最低人数；未准备显示谁需要准备；无开局权限时不展示可点击主按钮；切换房型造成麦序损失时必须说明副作用。截图里出现的短 Tips 应作为状态机的输出，而不是写死在各个页面。

13. 限制、风险与下一轮建议#

• 本轮只采样一个时段，且长列表限页，结论是方向性快照；下一轮建议覆盖工作日/周末、午间/晚高峰至少 6 个时点。
• 列表中的人数会在几分钟内变化，同一房间跨标签取本轮最大可见值，只适合比较相对热度。
• 投票与 AI 计分攻略 WebView 内容未成功加载；管理员委派、踢人、付费、礼物和正式多人开局因安全边界未执行。分享已到渠道选择层，但未发送。
• 按用户最新指令，24 个玩法 Box 游戏不再在 QNI App 内逐项启动深挖；QNI 侧保留卡片/排序/预览，基础玩法改由本地 Wira 源码提取。20 项已有源码证据，4 项等待本地目录同步，不把缺少源码的部分按名称推断。
• 本地 wira-mini-games/catalog/games.json 当前只列 20 项；已核对本地 origin/main 与 GitHub 远端 main 指向同一提交，远端也只公布这一分支，仍未发现挖宝达人、剪影墙、成分鉴定瓶、雪战上海滩 4 项。用户确认已开发，但本报告不会猜测未出现在当前远端主线的目录名或规则。
• 经营活动容器返回时曾落入公共房间并弹出等级/付费层，虽已安全恢复，但说明返回栈、来源房间和弹层队列需要专项测试。
• 当前素材包共 224 张原始截图、214 份 UI XML、44 张 PRD 精选图；截图清单记录 213 组同名 XML 和 11 张无同名 XML 的历史/诊断截图。游戏题库新增 47 张过程与结果截图，其中 41 张为可纳入结论的界面实测、6 张为误触或重复诊断。报告不回填或伪造缺失控件树。
• 游戏题库来自服务端当前可见目录；本轮已逐分类到“没有更多了”，但它仍是单时点内容快照。后续若题库增删或运营排序改变，应按题目 ID 和版本号做增量同步，而不是用标题覆盖。
• KTV 点歌权限入口已确认，但全部枚举值主要来自静态文案，需要多人账号实测。
• “未识别玩法”需要下一轮进入房间或做图标 OCR 后拆分，避免把多个长尾游戏聚合。
• 若进入研发，优先补充三份规格：角色权限矩阵、房间实时状态协议、H5 房间 Bridge Schema。它们决定后续玩法能否低成本复制。

14. 交付物索引#

完成度：三组菜单 35 项台账全覆盖；房间玩法 14/14；房间工具 8/8；基本功能 8/8；经营入口 5/5；玩法 Box 24/24 已完成列表与 Wira 映射；游戏题库 6 类 56/56 完成目录保存，其中海龟汤 20/20、看图猜词 4/4、谁是卧底 6/6 完成深层答案采集，并整理出 90 组卧底词对。

• 本地浏览 HTML 版
• 截图索引
• 房型表
• 管理工具台账
• 分类采样摘要
• 原始房间观测
• 去重房间观测
• 游戏热度评分
• 玩法 Box 24 项房间化接入优先级
• 分板块业务优先级与首期范围
• 功能优先级评分
• Wira/Laboo 能力映射
• 三组菜单覆盖矩阵
• 玩法 Box 24 项与 Wira 映射
• 玩法 Box 24 项基础玩法、结算与房间接入明细
• 房间玩法 14 项逻辑台账
• 游戏题库 6 类 56 条总目录
• 海龟汤 20 条完整题库
• 看图猜词 4 类答案
• 谁是卧底 6 类题库与主持规则
• 谁是卧底 90 组词对
• 截图清单
• 项目验收与剩余任务
• ui-xml/：与截图同名的控件树，可检索原始文案和控件状态