每轮试玩先解决一个问题
想让网页游戏收到有用反馈，先提供可玩的链接，说清希望测试哪一部分，再围绕一个具体时刻提问。每条回复保留对应版本，然后挑出下一版本能验证的改动。只说“帮我试试，什么意见都行”，会把设计测试的负担留给玩家。
可以先检查新玩家能否完成第一局、看懂重开提示，或学会一个移动动作。说明目标，但别提前教出解法。允许真实反应，也允许随时停下：玩家卡住本身就是值得调查的信息。这是一套建议工作方法，不是对回复数量或效果的实测承诺。
找可能喜欢这类游戏的人
从对类型有兴趣的人开始：已有玩家、你平时参与的开发者小组，或明确允许征集试玩的社区。发帖前阅读当前规则，不清楚该发在哪就先询问管理员。说明适合谁、哪些内容尚未完成，以及怎样的回答最有帮助。一份相关且明确的邀请，比重复发送宣传更容易让人接话。
朋友能帮你检查链接能否打开，但应把他们的反馈与首次接触作品的人分开记录。动作游戏的新手和熟练玩家可能遇到不同问题，保留这些背景，不要混成一个分数。不要用赞美换奖励，也不要把自愿参与者的意见包装成具有代表性的调查。
围绕实际游玩问三个问题
任务和问题应清楚，也别暗示你期待的答案。GOV.UK 的主持式可用性测试指南说明了这个原则；这里的游戏问题是我们自己的例子。先让玩家尝试目标，再解释设计。中途如果帮助他们继续，记下你在哪一步介入。
“好玩吗”可以打开话题，但追问具体时刻更容易形成行动。问清什么让他想继续、他原本期待什么、实际发生了什么。对难度的不满可能来自操作提示不清、刻意设置的挑战，或单纯不合口味；它们需要不同处理。
一份可以改写的试玩邀请
下面是虚构模板。替换所有占位内容，在全新会话中检查游玩链接，只保留与当前版本一致的说法。做这款游戏的个人原因可以留下，但玩家也需要知道玩什么、如何开始，以及在哪里回复。
给出清楚的停止点，别把注册账号、录屏或长问卷变成帮助你的前提。如果录屏对研究有用，单独征得同意，也接受拒绝。回复地址应是你真正会查看的地方，例如自己的反馈表或游戏讨论页。模板不会替你发送邀请或招募玩家。
[游戏名] 是一款网页[类型]游戏，你要[动作]来达成[目标]。
我做它是因为[一句自己的故事]。
游玩：[公开可玩地址] · 版本：[版本号/日期]
请试试：[一个任务] · 时间：[真实预估]
操作/设备：[已测试情况] · 内容提示：[相关说明]
哪里让你犹豫？什么让你想继续或停下？
你最想先改什么，为什么？
请回复到：[反馈入口]。谢谢你愿意试试！分清浏览器问题与游戏偏好
遇到崩溃、白屏、按键无响应或卡顿，先询问版本、设备、浏览器、模式及发生前的步骤，再问期待和实际结果。如果对方愿意提供截图，提醒隐藏私人标签页、账号资料及无关内容。不需要密码、登录链接或完整浏览器资料。
这些记录与口味建议分开。“关闭帮助后无法移动”可能是交互故障；“我希望移动慢一些”在弄清场景前只是偏好。这两个例子都不是对本站游戏的实际观察。先复现，再宣称修复，记录真正验证过的环境，不猜测全面兼容。
版本/日期：
设备/操作系统/浏览器版本：
游戏模式/关卡：
复现步骤：
期待结果：
实际结果：
重开后是否再次出现：
可选截图或短片（移除私人信息）：把回复变成可以验证的更新
保留一份小记录：版本、玩家背景、发生时刻、期待表现和下一步。优先调查打不开或无法开始的问题，再选择与本轮目标相关的改动。重复出现的反馈值得调查，却不能证明所有玩家都如此。没有采纳的建议也记一句原因，避免后来失去判断背景。
一条有用的更新会说明改了什么、在哪个版本，以及还需要验证什么。例如：“重开提示现在写明了按键，请再看看能否不靠帮助开启第二局。”这是虚构更新，并不代表我们测试过某款作品。只邀请已同意再次联系的玩家回来，在新版本重复相同任务。
把 PixelGamesHub 作品页作为起点
创作者投稿时可以选填最多三个希望玩家回答的问题。它们会出现在公开作品信息中，并链接到讨论区。阅读开放，发表评论需要登录，评论公开前会经过审核。邀请玩家前先准备好问题和可玩链接；作品上架不保证有人试玩、回复或获得编辑精选。
版本变化后，通过“我的游戏”维护自己的介绍、操作、联网说明和反馈问题。编辑可能让作品重新进入审核，分享更新后的页面前应检查当前状态。试玩发现仍应单独记录：作品页访问和游玩链接点击，并不能证明玩家完成了一局或喜欢这款游戏。
官方参考资料
资料核对日期： . 封面是保留署名的真实游戏截图，不是这篇教程的输出示例。