Steam 发布审核到上线按钮：2020 年个人游戏发售前 14 天清单

最后 14 天要停止发散

个人游戏进入发售前两周时，最重要的不是再加一个系统、再补一个关卡、再重写一段文案，而是让所有发布要素对齐。Steam 的发布审核、商店页信息、构建分支、价格、折扣、公告、客服、社媒、主播版本、崩溃处理，都必须指向同一个稳定版本。这个阶段继续发散，会让风险急剧增加。

上线按钮本身并不复杂，复杂的是按钮背后的承诺。玩家点击购买后，会下载你指定的构建，看到你页面承诺的内容，用你设置的语言和价格进入游戏，然后在遇到问题时通过你准备的渠道反馈。如果其中任何一环不一致，发售当天就会被放大。

所以发售前 14 天要切换心态：从“继续制作”切到“发布控制”。你可以修 Bug、调数值、补说明，但不应该再做结构性改动，除非不改会导致游戏无法发布。

第 14 到 10 天：确认候选构建

发售前两周，应该确定一个 Release Candidate，也就是候选发布构建。它不一定是最终版本，但应该已经能完整完成主流程，没有已知阻塞问题。候选构建要上传到明确分支，例如 review 或 release-candidate，并记录版本号。

候选构建检查：

候选构建确认后，要限制改动范围。可以建立三类问题：

这套分类能帮你抵抗“顺手再改一点”的冲动。发售前每一次改动都可能引入新问题。

第 10 到 7 天：对齐商店页和构建

商店页必须描述真实构建。检查页面时不要只看文字有没有错别字，而要逐项对照游戏内内容。

特别注意删除过时承诺。开发过程中删掉的系统，如果还留在长描述或预告片里，会变成发售后的争议点。个人开发者没有大型客服团队，最好在发售前把预期清理干净。

第 7 到 5 天：价格、折扣和包检查

价格和包配置是发售前容易被忽略的风险点。你要确认玩家购买后拿到正确内容，首发折扣时间正确，测试包和正式包没有混淆。

检查清单：

1. 正式商店包包含正确 App 和 Depot。
2. 测试包没有被误设为公开购买。
3. 首发折扣比例和开始结束时间与公告一致。
4. 地区价格没有明显异常。
5. Demo、原声带、DLC 如存在，入口和描述清楚。
6. 发布日期和时区理解一致。

个人开发者常见错误是自己能访问所有包，于是误以为玩家也能正常购买。一定要用非开发者视角预览购买路径，至少让没有后台权限的人帮忙检查页面显示。

第 5 到 3 天：准备公告和客服模板

发售当天不要临时写公告。你应该提前准备三类文本：发售公告、已知问题说明、客服回复模板。

发售公告包含：

游戏正式发布；
当前版本包含的主要内容；
首发折扣和结束时间；
反馈渠道；
已知问题和下一步计划；
感谢测试者或社区。

已知问题说明要诚实，但不要吓人。比如：

我们正在跟进少数低配机器首次加载较慢的问题。如果启动后黑屏超过 30 秒，请尝试更新显卡驱动并通过邮件发送日志文件。

客服模板可以准备：

模板不是为了机械回复，而是确保忙乱时不漏问关键信息。

第 3 到 1 天：做发布演练

发布演练就是假装今天要上线，从头走一遍流程：

1. 确认最终构建上传到了正确分支。
2. 在干净机器上卸载旧版本，重新安装。
3. 新建存档，玩过前 30 分钟和一个关键中后期场景。
4. 检查商店页、价格、截图、公告草稿。
5. 确认社媒文案、媒体包、主播邮件已经准备好。
6. 确认发售后 72 小时的工作时间。
7. 准备热修复分支和回滚记录。

演练中发现的问题要分类处理。阻塞问题立即修；非阻塞问题记录到首日补丁或后续更新。不要因为一个小问题重新打开大范围改动。

提前准备回滚方案

发布前还要准备回滚方案。很多个人开发者只想着“发出去”，没有想过首日补丁如果出错怎么办。回滚不一定真的会用到，但需要知道旧构建在哪个分支、对应版本号是什么、是否还能正常读取存档、公告该怎么写。尤其是存档结构发生变化时，不能随意退回旧版本，否则玩家可能从一个问题进入另一个问题。

一个简单回滚表可以这样写：1.0.0 是正式首发构建，保留在 archive-1.0.0；1.0.1 是首日热修复，修改启动问题，不改存档；如果 1.0.1 出现新崩溃，可以把 default 临时指回 1.0.0，同时公告说明热修复正在重新验证。这个表不是为了显得复杂，而是让你在压力下仍然有清楚选择。

发售当天：先稳住，再扩散

上线当天，顺序很重要。建议先完成平台侧检查，再开始外部扩散：

1. 确认商店页已经可购买。
2. 用普通账号查看页面、价格、折扣和下载。
3. 下载正式版本并启动一次。
4. 发布 Steam 发售公告。
5. 发布社媒和社区消息。
6. 给主播、媒体和测试者发送上线提醒。
7. 开始监控评论、论坛、邮件和崩溃反馈。

不要在没有确认购买和下载正常之前大规模宣传。否则玩家第一波点击遇到错误，会损害首发印象。

热修复要有边界

发售当天如果出现问题，开发者容易慌。热修复应该优先处理启动、崩溃、坏档、卡死、严重性能和购买后无法正常游玩的情况。普通平衡、文案、内容建议可以记录，但不应马上大改。

热修复流程：

1. 收集复现信息和日志。
2. 在本地复现或尽量构造相近环境。
3. 修复后上传到测试分支。
4. 用至少一台干净机器验证。
5. 再推到默认分支。
6. 发布简短补丁说明。

不要直接把未测试修复推给所有玩家。首日热修复的目标是止血，不是展示勤奋。

发布后 72 小时关注什么

发售后前三天，关注重点不是销量截图，而是体验风险：

个人开发者要避免和玩家争辩。即使玩家表达不准确，也先提取可用信息。发售初期每条反馈都是定位问题的线索。

最后一张总清单

Steam 发布不是按下按钮就结束。对个人游戏来说，发售前 14 天的控制力决定了首发体验是否稳定。把商店、构建、价格、公告和支持流程对齐，你不会消除所有风险，但能把可预见的问题提前处理掉。