摘要：第一个小游戏能运行后，怎样从试玩中找到具体问题？本文把试玩任务、观察记录、解释与改动分开，给出一份空白记录表和假想例子。适合完成基础案例后的开发练习，不提供实测完成率，也不把少量反馈当作市场结论。
大家好，我是 SiKi老师。
把游戏交给别人，然后问“好玩吗”，可能会得到一句“还行”。这句话可以记录，却很难直接转成下一项开发工作。我更想先知道：对方从哪里开始操作，在哪一步停下，停下之前看到了什么。
这篇讲的是首次试玩的准备与记录方法，不依赖某个引擎版本，也不是 Unity 或 UE 的操作教程。文中的小游戏、对话和观察记录都是假想示例；本次没有组织真实试玩、运行测试项目或统计玩家表现。你可以把表格带到自己的练习中，但需要用实际观察替换示例，不能把它当作已经取得的验证结果。
一、先选一个要观察的问题
第一次试玩不必同时判断难度、美术、音效、留存和付费意愿。我建议先选一个能够通过行为观察的问题，比如：没有口头提示时，试玩者能否从开始界面进入第一关？或者：角色失败后，能否找到重新开始的入口？
这是我针对基础小游戏的练习建议，不是通用的测试样本或时长标准。先限定问题，是为了让记录有明确对象。若你观察的是失败后的恢复，就把版本、关卡起点和失败条件记下来，不要把另一次试玩里的主菜单问题混进同一条结果。
“能完成操作”和“觉得有趣”也应分开。按钮容易找到，不代表关卡有吸引力；玩家喜欢某个角色，也不能证明操作流程清楚。你可以在任务结束后询问感受，但不要用一个总体评分替代具体发生的事情。
二、给出目标，不先说答案
GOV.UK 的主持式可用性测试指南建议围绕具体任务观察参与者，并使用清晰、中立、不暗示操作答案的任务说明。它讨论的是服务可用性，不是游戏乐趣评估；本文只借用这项任务设计原则。
例如，假设要观察失败后重新开始的入口，可以说：“这一局已经结束，请尝试再玩一局。”不要一开始就说：“点右下角那个圆形箭头。”后一种说明已经告诉了对方该点哪里，无法再用结果判断入口是否容易发现。
开始前可以说明：“我在检查游戏是否讲清楚了操作，不是在考你；遇到不明白的地方可以说出来，也可以随时结束。”这是一段可改写的准备话术，不是实际学生反馈。
如果你确实提供了帮助，就把帮助内容记进去。例如“说明圆形箭头表示重开”属于提示，提示之后完成应单独标注，不能记为独立完成。对方长时间卡住、感到不适或不愿继续时，停止该任务也比强行等一个成功更合理。
三、把看到的事情和自己的解释分开
我会把记录拆成三层：发生了什么、对方说了什么、我暂时怎样理解。没有听到原话就不要补写引号；看不清操作顺序就写“未确认”，而不是凭结果倒推。
下面是一个纯假想例子，用来展示写法，数值和对话不是实测：
| 可见行为 | 结算后点了一次分数区域，随后停下；尚未点到重开入口 |
| 假想原话 | “还能再来一次吗？” |
| 暂时解释 | 重开入口可能不够显眼；也可能是没有理解结算状态 |
| 仍需核对 | 是否看到了入口；图形是否被误解；此前有没有接触过这个版本 |
| 不能推出 | 所有玩家都找不到；换颜色一定有效；游戏整体不好玩 |
解释保留多个可能，并不是不作判断，而是防止过早把一个现象归到熟悉的原因上。“没点按钮”未必就是按钮太小，也可能是没有意识到这一局已经结束。
一次观察不清楚时，我会先给问题标上待核对，再考虑是否需要新的观察条件。不要为了让记录显得完整，编出停留秒数、点击次数或参与者想法。
四、用一张表保留上下文
记录表可以很简单。下面是空白模板，所有结果都需要实际执行后填写：
| 游戏版本与运行环境 | 待填；包括构建标识、设备类型和输入方式 |
| 本轮研究问题 | 待填；只写本次真正观察的问题 |
| 任务与初始状态 | 待填；保留原始任务措辞和开始位置 |
| 是否接触过此游戏 | 待填；只记录相关背景，不收集身份资料 |
| 行为顺序与必要原话 | 未执行，待记录 |
| 是否提供提示 | 未执行；有提示时写明内容和时机 |
| 结果 | 未执行；之后区分独立完成、提示后完成、未完成或主动停止 |
| 推测原因与缺口 | 待核对，不能当作已证实原因 |
| 下一步 | 待定；补观察、复现问题或验证一种修改 |
不要只留下“失败”两个字。同样是没有重开，程序崩溃、入口没被发现、主动结束试玩，对开发的含义不同。测试包本身打不开时，先处理启动问题；这轮没有产生关卡体验证据，不应硬给关卡难度打分。
准备记录时使用无个人信息的测试数据。未经同意不要录屏、录音或传播原话；即使获准记录，也只保留与问题相关的内容。不要把聊天账号、姓名、联系方式或完整桌面画面放进公开项目材料。
五、从问题决定下一项工作
收集到一张表后，不用把每个建议都做进去。我会先看是否阻断本轮目标，再看证据是否足以支持改动。
如果是自己能够复现的启动崩溃，下一项工作通常是定位与修复启动路径。如果只观察到一次入口没被发现，可以先检查入口状态，再提出一种明确的改动假设，例如增加文字说明；不要同时换位置、颜色、图标和结算流程，然后把改善归功于其中一个元素。
有人建议增加多人模式时，先记录他希望解决什么体验问题。功能建议和问题本身并不相同，第一次试玩也不等于重新确定整个项目范围。你的练习若只做单机流程，可以把这个建议放进以后评估的清单，不必立即承诺开发。
修改完成后要用新的版本标识记录复查。已经得到提示的人再次操作，可能记住了答案，不能把这次顺利完成完全归因于界面改动。小规模试玩能提供检查方向，但没有足够、可比较的观察，就不要宣称完成率提升、所有新手都能理解，或证明了商业潜力。
小结
首次试玩可以先回答一个很窄的问题。把任务写清楚，保留操作上下文，将行为、原话和推测分别记录，才知道下一项需要验证的是什么。准备表格不是取得结果；改过界面也不是证实改对了，最后仍要回到实际观察。
如果现在把你的小游戏交给第一次接触它的人，你最想观察的是进入游戏、理解目标，还是失败后重开？选一项，试着写一句不透露操作答案的任务说明。
