Soulframe 反馈与 Bug 报告指南

有效报告应包含

即使官方表单很短，也按这些字段整理；这会让问题更容易复现。

为什么 Preludes 阶段反馈很关键

Preludes 是公开开发过程，反馈本身就是产品的一部分。精确报告能区分玩家操作、平衡问题、网络问题和可复现缺陷，而模糊抱怨恰恰会丢掉这些信息。

把步骤写得让陌生人能复现

假设读者没有看过你的游玩过程。不要写“坏了”，而写具体路线、菜单、输入、敌人状态和观察结果。写清第一次注意到问题的时间点，以及重复同样顺序是否出现同样结果。

区分 Bug 与偏好

Bug 是预期行为与实际行为之间存在可观察差异；偏好是机制不舒服但仍按设计运行。两者都有效，但正确标注能帮助开发团队分派报告。

避免有害捷径

不要修改文件、注入工具、使用非官方客户端或测试漏洞来验证猜想。只报告正常游玩中能观察到的内容，并说明观察边界。危险复现可能破坏数据，也会让报告失去价值。

描述影响但不夸大

说明问题对本次会话的影响：阻碍进度、干扰判断、中断安装，还是只造成视觉噪音。除非能展示范围，避免“游戏坏了”这类全局结论。准确影响有助于开发判断严重程度，也不会把单次异常扩大成全平台问题。

等待回复时做什么

不要持续修改多个变量。保留报告编号，记录每个官方更新后问题是否仍存在，并继续正常游玩。如果问题消失，简短更新说明哪个补丁解决；这在 Preludes 阶段同样有价值。

整理一页复现记录

如果字段具体，一页通常足够写出有用报告。先写观察到的行为，再按实际操作顺序写具体步骤，最后写可能影响结果的环境。包括补丁或构建日期、界面语言、硬件级别、相关时的驱动系列、连接类型，以及叠层或输入软件是否启用。间歇性问题记录尝试次数和最近一次成功时间，不要只写“偶尔”。视觉问题说明出现在屏幕哪个位置及周围变化；进度问题说明目标、预期下一步和实际停在哪一步。提交前删除无关猜测，只保留观察事实，或明确标注知识边界。若其他玩家报告过相同行为，可以链接该报告，但不要把对方硬件细节复制成你的证据。最后留一行不确定信息。说明你没有测试另一个账号、地区或硬件设置，比假装报告覆盖所有情况更可信。

• 行为：发生了什么、在哪里、何时开始。
• 步骤：仍能触发问题的最短顺序。
• 环境：补丁日期、硬件级别、连接和相关软件。
• 预期与实际结果：各一句话。
• 边界：没有测试什么，以及原因。
• 参考：若已有相同行为报告，单独链接。
• 不确定：一个无法控制的变量。
• 会话长度：足以显示问题是否重复。
• 恢复方式：若有，说明什么恢复正常。
• 附件：一张截图或短录制，不要整文件夹。
• 语言：测试时使用的界面语言。
• 客户端构建：当前补丁标识。

常见问题