先界定需求边界
这次审计的起点不是比较方案，而是把“爱游戏”在你的场景里到底指什么写清楚。边界不清，后面的对比就会变成各说各话。先回答三个问题：使用者是谁、在什么设备上进入、失败时谁来兜底。
- 使用人群是否明确到具体岗位或角色，而不是笼统的“用户”。
- 主要入口是客户端还是网页端，是否允许两者并存。
- 单次使用时长与并发规模是否有可描述的区间。
- 账号来源是自建还是第三方登录，责任归属是否写进文档。
- 出现无法进入或中途断开时，第一响应人是否已指定。
- 预算口径是否包含后续维护，而不只是首次投入。
边界写完后再往下走，否则清单只会变成愿望列表。
必备项与加分项分开列
把需求分成两栏：不满足就不能选的必备项，以及满足更好、缺了也能接受的加分项。混在一起，是最常见的选型失误。
- 必备：能在目标设备上稳定进入，且异常时有明确提示。
- 必备：账号与权限可追溯，谁在什么时候进入有记录。
- 必备：有可执行的工单或反馈通道，而不是只有一个邮箱。
- 必备：版本更新有说明，回滚路径可描述。
- 加分：界面自定义程度高，减少重复操作。
- 加分：支持多端同步进度，切换设备不中断。
- 加分：提供使用数据看板，便于内部复盘。
每写一条必备项，都要能回答“怎么验证”。验证不了的条目，先降级为加分项。 爱游戏攻略
评估阶段要问的问题
评估不是听介绍，而是用同一组问题去问每个候选方案，让回答可以横向对照。问题要具体到可复述。
- 进入失败时，用户看到什么，内部收到什么。
- 账号异常的处理流程分几步，每步由谁负责。
- 更新频率与通知方式是什么，能否提前获知。
- 数据存放在哪里，导出是否受限。
- 出现争议时，依据哪份文档判定责任。
- 试用期能覆盖哪些场景，未覆盖的部分如何补。
把回答记在同一张表里，不要只记结论。回答含糊的地方，往往就是后续扯皮的地方。
取舍时先看哪一头
候选方案很少全面占优，取舍要有固定顺序，避免每次讨论都从头争。
- 第一优先：必备项是否全部可验证，缺一项即出局。
- 第二优先：异常处理链路是否清晰，出问题时能否快速定位。
- 第三优先：维护成本是否落在可承受的人手上。
- 第四优先：加分项带来的体验提升是否值得额外投入。
- 第五优先：切换成本，包括数据迁移与使用习惯改变。
顺序固定后，讨论会从“我觉得”转向“按第几条判定”。这正是清单的价值。
推荐框架与下一步
推荐不是拍板，而是把判断依据写成可复核的结论。建议用一页纸承载：需求边界、必备项核对结果、评估问题回答摘要、取舍顺序与最终建议。
- 本周内完成需求边界一页纸，交由实际使用者确认。
- 把必备项逐条标注验证方式与验证人。
- 用同一组评估问题访谈候选方案，记录原始回答。
- 按固定取舍顺序形成推荐，并写明被放弃项的原因。
- 设定复核时间点，用实际使用情况回填清单。
清单不是一次性的表格，而是每次复核都能复用的核对底稿。