发出试玩版以后：版本说明、反馈归并与修复复核

试玩包说明应写目标、可体验范围、预计操作流程和明确未包含的内容。独立练习房就称练习构建，不包装成完整游戏试玩；早期原型也不承诺不存在的剧情与功能。测试者需要知道自己在帮忙验证什么，而不是拿着一个压缩包猜作者的意思。

每次发出的文件必须有唯一版本标识，最好能对应提交与构建日期。不要反复覆盖同一个文件名却不改版本；否则玩家说“最新版仍坏”，你无法判断他拿到的是哪一份。

用固定的轻量结构：新增与变化、修复、已知问题、操作方式、存档兼容说明、反馈入口。变化从玩家角度写，例如“对白开启时不再触发门”，而不是只写“重构输入模块”。没有变化的栏目可以省略，不必为了格式编造内容。

如果旧存档不能使用，明确影响和处理方式，不能让玩家启动后才发现进度归零。首次发布应说明如何退出、测试数据保存在哪里，以及需要反馈的重点；不要把源码目录结构当成玩家说明书。

在主菜单或暂停页放可复制的版本号，反馈表只要求必要内容：版本、设备与系统概况、步骤、预期、实际和是否重复发生。截图、录屏、日志作为可选证据，不强迫玩家上传完整电脑信息。公开提交前提醒遮住个人路径、账户名和其他敏感内容。

收到“打不开”先区分下载损坏、解压位置、启动失败和进入游戏后退出，不要第一反应让对方重装一切。把需要补充的问题集中问清，已提供的信息不反复索取，让玩家更愿意协助。

同一个门打不开的报告可能来自缺少物品、输入穿透或旧版本存档。先保留每份证据，再按已确认根因合并，而不是仅凭标题相似关闭重复项。记录影响人数时区分报告数量与已验证复现数量，不把一个热闹讨论串当成可靠发生率。

给问题标记新收到、待复现、已定位、待验证、已发布等状态。明确负责人或下一步，并留下当前判断依据。修复代码后先进入待验证，不直接回复“已经解决”让测试者误以为手里的版本自动变好了。

先在修复版本重走原始步骤，再测受影响的相邻路径。之后从最终压缩包重新解压，独立启动，核对版本号和修复行为；不要只测试工作目录里的可执行文件。构建、上传和链接更新都可能让正确代码没有进入玩家下载的版本。

保留上一个已知可用构建与对应说明，必要时能明确退回；涉及存档格式变化时先核对兼容边界，不让回退程序破坏较新存档。回退是一条经过检查的发布路径，不是临时随便找个旧 exe 覆盖。

用练习版制造一条无害的问题，例如某提示显示旧按键。发布版本 A，按表记录反馈，修复后发布版本 B，在说明中写清变化。请测试者确认自己启动的是 B，再按原步骤复测。若仍出现问题，保留报告继续定位，不用“我这里没问题”结束讨论。

验收应留下两个可区分的构建、一条能追到修复的报告、原路径与边界复测记录，以及最终下载包的验证结果。反馈循环的目的不是把问题列表清空，而是让每项重要变化都有真实、可追踪的交付结果。