先定审计范围：好友约战场景到底要审什么
这份清单不讨论谁家更好，只解决一个问题：在把喜盈棋牌纳入好友约战场景之前，团队该拿哪几把尺子去量。审计对象是场景需求与产品能力的匹配度，而不是营销话术。先把范围锁死，后面的必备项、可选项和红旗信号才有意义。
审计范围建议只覆盖三类使用面：一是好友约战的房间创建与加入流程，二是对局过程中的连接稳定性与异常提示，三是出问题后的回滚与记录能力。范围之外的功能，例如社交扩展、活动运营，一律归入可选项，不参与必备项判定。
- 确认审计对象是“好友约战”这一具体场景，而非全量功能面。
- 确认参与审计的角色：发起人、普通参与者、负责善后的管理员。
- 确认审计产出是一份可签字的核对表，而不是口头印象。
- 确认审计结论只对当前场景有效，换场景需重新走一遍。
必备项清单：不满足就不建议采购
必备项的定义很硬：任何一条不满足，采购流程就应暂停，而不是打折通过。下面每一条都要求可现场验证，不接受“理论上支持”这类答复。 好友约战
- 房间创建可复现：同一操作连续执行多次，结果一致，不依赖特定时段。
- 加入路径清晰：参与者能在不求助他人的情况下完成加入，步骤可被复述。
- 断线有可见提示：连接异常时界面有明确反馈，而不是静默卡住。
- 异常后可回到原局：中断恢复后能判断自己处于哪一局、哪一状态。
- 操作记录可查：关键动作留有痕迹，便于事后核对而非凭记忆。
- 权限边界明确：谁能建房、谁能移除参与者，规则写清楚且执行一致。
可选项清单：按场景取舍的加分项
可选项不是“有就买”，而是“按使用频率决定是否付费”。审计时把每条可选项标注为高频、低频或不用，避免为低频能力付出长期成本。
- 房间参数的可调范围，是否覆盖你们常用的对局形式。
- 参与者规模上限，是否与你们实际约战人数匹配。
- 多房间并行时的管理视图，是否减轻发起人负担。
- 异常后的通知方式，是否与团队现有沟通习惯兼容。
- 记录导出的便利程度，是否方便复盘时引用。
评测提问清单：向供应方要哪些可验证答复
评测阶段的核心不是听介绍，而是把问题问成可验证的形式。以下问题建议逐条记录答复，并标注“已现场验证”或“仅口头说明”。
- 断线恢复的具体表现是什么，能否现场演示一次中断与恢复。
- 房间创建失败时，系统给出什么提示，用户下一步该做什么。
- 权限变更后多久生效，是否需要重新进入房间。
- 记录保留的范围与时长，能否按需导出。
- 出现异常时的支持路径是什么，响应由谁承接。
红旗信号：出现这些就先别签
红旗信号的作用是止损。它们不一定意味着产品不可用，但意味着当前阶段不适合推进采购，应先补齐信息再谈。
- 关键能力只能用“应该可以”“一般没问题”来回答，无法现场演示。
- 必备项中有任意一条被建议“先用着看”，而不是先验证。
- 权限与记录规则在不同人嘴里说法不一致。
- 异常处理没有明确承接方，只能靠发起人自行协调。
- 可选项被包装成必备项，用来抬高采购范围。
整改与复购顺序：把审计结论落到行动
审计结束后，按“先补必备、再谈可选、最后定复购”的顺序推进。必备项缺口未补齐前，不进入价格谈判；可选项按使用频率排序，低频项直接划掉；复购判断只看一件事：上一轮审计中的缺口是否真的被补上。
- 第一步：列出必备项缺口，逐条指定验证方式与责任人。
- 第二步：把可选项按高频、低频分组，低频项本轮不采购。
- 第三步：对红旗信号逐条给出书面答复，未答复即视为未通过。
- 第四步：复购前重跑一次本清单，用同一把尺子对比前后差异。
清单的价值不在条目多少，而在每一条都能被现场验证。凡是无法验证的条目，都应从结论中剔除，而不是折中保留。