游戏出了问题，却连该问谁都不清楚时，写求助内容可能比处理游戏本身更先卡住。在 Steam 买的游戏，好像应该找 Steam；但眼前的问题又可能属于开发商负责的范围。与其先猜原因，不如先决定应该把哪个场景告诉哪个渠道。
下面的拼图游戏、版本 1.2.0、三次结果和求助文字，全部是为了说明而设定的虚构案例。本文没有实际运行游戏，也没有向支持团队发送消息或文件。官方渠道以 Steam、Factorio 和 Larian 的公开说明为依据，但修改求助文字的过程只围绕这个虚构场景展开。
即使在 Steam 买的游戏，也要按问题类型选择求助渠道
这是开发商未设定的虚构案例，实际没有发送求助。
Valve 开发的游戏出现问题时，Steam 的官方说明建议直接联系 Steam 支持。Steam 账号和购买问题、出现在 Steam 对话框中并导致游戏无法启动的错误，以及游戏载入后的身份验证或 CD 密钥错误，也在这份支持说明的范围内。第三方游戏启动后出现的 bug 或异常行为，如果不属于 Steam 身份验证或 CD 密钥问题，则应联系开发商或发行商。Steam 的第三方游戏支持说明
同一份说明还给出了从库中的对应游戏支持项查找开发商联系方式的路径。找不到第三方支持渠道时，可以向 Steam 支持询问联系信息。
实际求助时，最好写上游戏名称。在某款游戏的专属版块里，省略名称也许还能看懂；但在同时接收多个游戏问题的渠道中，读者可能不知道你在说哪一款。没有错误代码时，也没必要把“画面没有变化”改写成“服务器出错”。不要编造不存在的提示，直接描述眼前的场景即可。
官方论坛里，问题也可能对应不同的受理入口
这是区分两类问题的虚构示例，不表示一边的对话会自动转交给另一边。
Factorio 帮助页把 bug 和崩溃反馈引向官方论坛的 bug 报告区；关于游戏进程或操作方法的问题，则引向寻求其他玩家帮助的区域。联系页面也分别列出了 bug 报告、游戏帮助，以及想法和建议。即使找到了技术支持地址，也要读完与这次投稿内容有关的说明。Factorio 的帮助页 · Factorio 的官方联系渠道
Larian 在 2023 年发布的开发者论坛公告，要求把 Baldur’s Gate 3 的问题和 bug 发给支持团队，同时把相应论坛版块划为玩家互相求助、交流临时应对方法的地方。这份资料展示的是当时的角色区分，不能据此推断回复要等多久，也不能扩展成当前所有受理政策。Larian 的 bug 受理说明
因此，公开讨论和官方渠道要问的内容并不一样。可以向其他玩家问“你也见过这个画面吗？”，向开发商问“这种行为是原本设计的吗？”。无论问哪一方，都不必假设对方已经读过前面的对话。
标题先写清观察到的画面，不要急着猜原因
版本 1.2.0 是专为这个例子设定的数值。
这份虚构求助最初的标题是“游戏坏了”，正文是“进不了下一个。是 bug 吗？快修好吧”。即使把语气改成“请尽快处理”，对方获得的场景信息也不会增加。先在标题里写出位置和动作更重要。
Factorio 的报告指南要求在标题中写明实际遇到问题的版本和发生情境。这份指南首次发布于 2014 年 5 月 16 日，并不是 Steam 所有游戏通用的统一格式。Factorio 的 bug 报告指南
在本文的虚构场景中，从拼图列表中选择第三个拼图，拼好全部碎片后，在结果画面按下“下一个拼图”按钮。结果画面仍然停留在原处。之所以预期会进入下一个拼图，是因为按钮名称这样写。示例没有查阅说明书，也没有确认是否需要额外的准备步骤，所以不能把这些未知内容写成原因或规则。
观察范围也要保持在实际知道的部分。音乐还在播放，光标可以移动；其他按钮是否有反应、等待了多久，都不知道。因此，应该写“按下按钮后结果画面仍然停留”，而不是“整个游戏都卡死了”。这个虚构案例也没有设定输入设备或真实游戏名称。
次数可以统计，不确定的就原样保留
这是为说明而设定的三次结果，不是实测出错概率。
例子设定为沿着同一操作路径进行了三次：两次停留在结果画面，一次进入下一个拼图。哪一次停留、哪一次进入，没有设定具体顺序。三次中两次这样的数字，是为了说明而创作的条件，不是实际测试结果。
因此，不要写成“总是进不去”。既然有一次进入过下一个画面，就可以区分“完全无法打开下一画面”和“相同操作并非每次都得到相同结果”这两种情况。把这段虚构记录改写成百分比或整款游戏的出错概率，含义范围就变了。
也不必为了写出一份认真求助，先增加确认次数。实际只遇到一次，就把那一次写下来；如果后来又确认了什么，就把动作和结果放在一起。没有确认的等待时间或环境条件，就保留为空白。
附件只放与场景有关的内容，提问尽量简短
下面的求助文字和示意图都不是实际发送的消息或取得的文件。
结果画面的截图可以显示按钮名称和仍然停留的画面，但只看一张静止图片，无法判断它是在按按钮前还是按按钮后截取的，也看不出等待了多久。如果附上多张图片，就要写清哪一张在前，以及两张画面之间做了什么。实际需要哪些附件，应以提交渠道的说明为准。
假设虚构画面的一角出现了聊天软件通知或其他人的姓名，它们并不能说明拼图按钮的问题。Steam 的《在线行为准则》禁止公开他人个人信息、骚扰和垃圾信息，以及不当收集或传播他人信息。Steam《在线行为准则》
Factorio 官方 Wiki 说明，日志包含会话日期和时间、更新程序的登录用户名，以及部分文件的完整路径，并称这些通常不是敏感信息。这是文档列出的通用信息，不是检查读者文件得到的结论。本文不规定如何生成日志，也不规定如何删除或遮盖个人文件。Factorio 日志文档的信息范围
> 在示例版本 1.2.0 中，按下“下一个拼图”按钮后，结果画面仍然停留在原处。我从拼图列表中选择第三个拼图，拼好全部碎片后，在结果画面按下“下一个拼图”按钮。按相同操作路径设定的三次示例中，两次停留在结果画面，一次进入下一个拼图。画面停留时，音乐仍在播放，光标也能移动。其他按钮是否有反应、等待了多久，都没有确认。我原本以为会进入下一个拼图，但不知道是否还需要额外的准备步骤。想请问，这种行为是原本设计的吗？如果不是，还需要提供哪些信息？
游戏名称和设备信息在这个例子中都没有设定。实际要填写什么、附上什么，应查看提交渠道的要求。这段简短的求助文字和示意图一样，是把观察到的内容、预期和未确认事项放在一起的虚构示例，不是可以直接发布给真实游戏的 bug 报告。
相似标题只能作为比较的起点
这是一个假设比较，不表示实际找到了同一问题的帖子。
如果搜索到标题为“下一个按钮没反应”的帖子，登录画面上的按钮和拼图结果画面上的按钮仍可能是两个不同的场景。Factorio 的报告指南也要求在确认确实是同一个问题后，为原有报告补充内容。仅凭标题相似，不能把自己的操作路径和结果改写成与前文一致。
帖子正文没有写出的条件，可以留作问题，例如：“直接从列表里选择时，也会这样吗？”不要把“我也是”的回复数量抄成受到同一个 bug 影响的人数，也不要把一位玩家说明的操作方法扩大成“大家都确认没问题”。应当只保留评论和正文实际说到的范围。
收到后续问题时，不必重新贴出第一篇求助，只补充被问到的部分。如果对方问是否经过拼图列表，就回答自己是直接选择第三个拼图；如果问等待了多久，而你没有计时，就照实说明没有测量。后续确认的内容要带上当时的条件，不能把不同场景拼成一个结果。
“看到了相同画面”“正在调查原因”“计划修复”和“修复已经完成”是不同的说法。没有回复，不能单凭这一点断定对方在故意忽视你，或断定这不是 bug；有修复计划，也不能承诺修复版已经发布或给出解决日期。
把这些区别保留下来，最初求助需要的信息和仍然未知的部分就能同时留在文字里。