微信小游戏可用性测试，可以先从客服求助提取玩家目标，再准备不提示答案的任务，观察用户如何寻找入口、理解信息并继续操作。TRAE可用AI整理授权原话和研究脚本；实际页面与观察由团队准备，聊天里说没找到，不等于已经知道玩家点过哪里。
运营熟悉页面，往往一上来就说点哪里，再看玩家能不能照做。这样的过程可以检查说明是否清楚，却看不到用户在没有提示时如何理解页面。想知道入口为什么难找，应先给真实任务，再观察他会找什么、停在哪里。
例如原话是“这周的活动什么时候结束，我找了半天”。研究目标可以是玩家能否自己找到当前活动的结束信息；不要直接改成点击活动页右上角查看时间，那已经把要观察的路线教出去了。
先选常见任务，参与者经历由本人说明或按招募条件确认，不按咨询次数推断熟练程度。
知你AI助手可查询授权客户、历史会话和消息。TRAE完成当前通用MCP配置与授权后，读取指定小游戏的相关求助，列出玩家想做什么、明确遇到的困难及客服后来怎样解释。运营另行提供当前页面或原型、可测试范围和预期结果。
可提出：“从这组授权求助准备体验观察任务。每项写用户目标、适用背景、中性任务话术、主持人预先知道的完成依据和观察点。任务不给按钮名称或操作路径，不把历史描述改成真实点击记录；缺少页面依据的先交我补充。”
GOV.UK的可用性测试指南建议任务有清楚目标、符合参与者情境，且不泄露答案。脚本也应先和同事试走，确认任务本身说得明白，再邀请目标用户参与。
下图为MCP连接后台布局示意，脚本在AI客户端准备；游戏页面与研究执行不在此后台中。
以下游戏、页面与研究安排全部虚拟。团队准备了可点击的示例游戏原型及虚拟资料，没有真实充值或账户变动；运营已核对活动信息与求助入口可以正常查看。
开始说明：“我们想了解这套页面是否容易使用，不是在考您。请按平时方式尝试，也可以说出您正在想什么；不清楚时直接停下来告诉我们，不需要猜一个让我们满意的答案。”
| 任务 | 对参与者怎样说 | 主持人怎样观察 |
|---|---|---|
| 找活动结束信息 | 您想知道这周活动什么时候结束，请找到信息并告诉我 | 先看哪里、怎样理解日期、是否找到对应活动 |
| 找继续求助方法 | 您有一个玩法问题，想知道怎样联系人员继续问，请找到办法 | 能否找到入口、是否理解它用于什么求助 |
主持人的完成依据另行保存，不印在参与者任务旁。例如第一项要求找到本例当前活动的结束说明并正确复述，不是只进入了某个活动页面。第二项只观察找到可继续咨询的方法，不要求向真实客服发送测试信息。
中性追问例：参与者说这里应该有时间，主持人可以问“您为什么会这样想？”；不要问“是不是右上角太难找”，也不立刻指位置。确需帮助才能继续，就记录何时给了什么帮助，后面的完成标为有协助，不混作独立完成。
下图为AI客户端辅助准备流程，任务均为虚拟示例，实际操作观察由团队另行记录。
记录表可以保留任务、参与者实际动作、原话、停点、是否协助及最终表现。把“看了三个栏目后停下”和“入口设计差”分开，前者是观察，后者还需结合页面与更多证据讨论。
知你AI助手帮助从真实求助选出值得观察的任务，TRAE辅助组织脚本。研究结论来自实际观察，不是AI对聊天的猜测。保留必要记录，先改一个有依据的障碍，再看用户能否更顺畅地完成工作。
不能，先作为观察线索，结合当前页面和实际使用过程核实。
观察自主使用时给目标，不预先透露操作路径或答案。
可以记录，但注明协助内容，不能与独立完成混在一起。
本文查询客服沟通，实际行为由测试人员在研究中观察记录。
不应这样推广，报告说明招募、任务和版本，作为改进线索继续验证。
小游戏体验观察从玩家目标开始，用中性任务看实际找法，记录原话、停点与帮助。先让AI从授权求助准备脚本，再由运营在明确环境中执行，验证具体体验问题。
如果团队从客服记录看见了卡点，却还不知道该怎样观察玩家实际使用，可以了解知你AI助手官网，用AI先准备基于授权问题的测试任务，再由运营开展真实观察。
也可以扫码交流你的客服数据整理需求：
全渠道智能客服系统，聚合微信、小红书、抖音等平台咨询，支持自动回复与多客服协同。
知你AI助手官网 >AI 驱动的智能接待助手，基于知识库生成可确认的推荐回复，提升响应效率。
知你快回官网 >浏览器插件，为小红书、抖音、网页客服场景提供快捷话术库与 AI 自动回复。
