Steam 正式发布前总验收：独立游戏上线前 7 天检查表

最后 7 天最怕临时发挥

独立游戏发售前最后 7 天，开发者通常非常忙：修最后几个 Bug、确认商店页、准备公告、回复主播、检查价格、上传 Build、设置折扣、安排直播、写补丁说明。这个阶段最危险的不是事情多，而是所有事情都靠记忆。一个漏项就可能在发售当天变成公开事故。

总验收的目标不是追求完美，而是确认“可以发布”和“出问题能处理”。本文提供一套上线前 7 天检查表，适合个人开发者或小团队使用。

D-7：冻结范围

发售前 7 天，应该冻结功能范围。除非发现阻塞问题，不再加入新功能、新内容、新系统。冻结后仍可做：

• 崩溃修复；
• 文本错误；
• 配置修正；
• 页面信息更新；
• 客服和公告准备；
• 构建测试。

不应再做：

• 新关卡；
• 新机制；
• 大规模平衡重做；
• UI 框架替换；
• 存档结构重写；
• 未测试平台支持。

冻结范围要写进团队频道。否则总会有人觉得“这个小功能很快”。

D-6：构建验收

构建验收必须从 Steam 客户端安装开始。

检查表：

每项都要有负责人和证据。不要只写“应该没问题”。

D-5：商店页验收

商店页验收重点是承诺一致。

• 短描述是否准确；
• 长描述是否包含当前版本内容；
• 截图是否来自当前构建；
• 预告片是否没有过时功能；
• 标签是否符合实际玩法；
• 语言支持是否准确；
• 系统需求是否经过测试；
• Steam Deck、手柄、云存档等功能是否真实支持；
• Demo 和正式版差异是否说明；
• 外部链接是否有效。

把页面当作玩家合同来检查。页面写出去的东西，玩家会拿它判断你是否可信。

D-4：价格、折扣和地区

价格设置需要提前确认，不要发售当天才看。

检查：

• 基础价格；
• 首发折扣；
• 折扣开始和结束时间；
• 重点地区价格；
• DLC、原声集或捆绑包；
• 页面和公告里的价格表述；
• 是否和创作者、媒体信息一致。

如果价格临时改动，要同步所有外部材料。媒体稿写 14.99 美元，页面显示 19.99 美元，会制造不必要的混乱。

D-3：公告和客服

准备至少四份文本：

1. 正式发售公告；
2. 已知问题公告；
3. 首个补丁说明模板；
4. 常见问题和客服回复。

FAQ 至少覆盖：

• 支持语言；
• 支持平台；
• 存档和云存档；
• Demo 是否继承；
• 手柄和 Steam Deck；
• 崩溃日志在哪里；
• 如何反馈 Bug；
• 未来更新计划。

客服回复要有路径，不要只说“请重装”。玩家遇到问题时，需要明确步骤和联系入口。

D-2：回滚和热修复演练

发售前两天，确认最坏情况怎么处理。

• 如果 Build 崩溃，如何切回旧版本；
• 如果价格错误，谁能修改；
• 如果商店页信息错误，谁负责；
• 如果论坛爆出 P0 问题，谁发公告；
• 如果服务器挂了，谁处理；
• 如果主播遇到 Bug，谁联系。

最好做一次桌面演练：假设发售后 1 小时大量玩家无法启动，团队按流程走一遍。你会发现很多权限、账号、文档和沟通链路问题。

D-2 同步检查外部材料

很多发售事故不是游戏本身，而是外部信息不同步。发售前两天要检查所有公开材料：

• Steam 页面；
• 新闻包；
• 官网；
• Discord 置顶；
• B 站或 YouTube 简介；
• 媒体邮件；
• 主播说明文档；
• 社媒倒计时图；
• Demo 页面和公告。

这些地方的发售日期、价格、支持语言、Demo 继承、平台支持必须一致。尤其是延期或改价后，旧素材很容易残留。玩家不会区分“这是旧邮件”还是“这是最新页面”，他们只会觉得开发者信息混乱。

数据记录表也要提前建好

发售当天不要临时想怎么记数据。可以提前建表：

记录表不是为了做漂亮报告，而是为了首周判断。没有事件记录，你很难知道销量变化来自公告、主播、折扣、补丁还是自然流量。

权限和账号也要验收

最后 7 天还要确认谁能登录哪些后台。很多小团队只检查内容，不检查权限，结果发售当天负责公告的人没有权限，负责热修复的人无法切分支，负责客服的人看不到论坛管理入口。

权限清单可以写成：

同时确认双重验证、备用邮箱、密码管理器和紧急联系方式。发售日不是找权限的时间。

权限验收还要包含“不能做什么”。临时协作者、翻译、外包美术和主播联络人员不应该拥有发布、改价、切分支或删除内容的权限。越接近发售，越要减少后台误操作的可能性。小团队常常因为互相信任而权限过宽，但发售日压力大，误点一次就可能影响所有玩家。

总验收还要检查本地文件和云端文件是否一致。发售公告、截图、预告片、新闻包、客服模板如果散落在不同成员电脑里，很容易上传旧版。建议最后 7 天只认一个发行资料夹，所有公开材料从那里取，不从聊天记录里临时下载。

验收结束后可以生成一份只读记录，写明最终 Build、页面版本、价格版本和公告版本。发售后复盘时，这份记录能告诉你首发时玩家看到的到底是哪一版，而不是凭记忆回想。

如果团队只有一个人，也要做这份记录。单人开发者更容易在发售前疲劳操作，记录能迫使你停下来逐项确认。它不需要复杂工具，一张表就够：文件、当前版本、确认时间、下一步。真正出问题时，这张表能快速缩小排查范围。

这份记录还可以作为下一款游戏的模板。第一次发售时花时间整理，第二次就不用从零开始。

D-1：最终确认

发售前一天只做确认，不做创造。

最终清单：

• Steam 客户端安装候选版本；
• 完成一次核心流程；
• 商店页逐项检查；
• 发售时间和时区确认；
• 折扣确认；
• 公告排版确认；
• 社媒素材确认；
• 创作者和媒体提醒；
• 数据记录表准备；
• 团队值班时间确认；
• 睡眠和备用设备确认。

最后一项看似玩笑，但很实际。疲劳会导致误点后台、漏看反馈和错误判断。

D-0：发布当天不要乱改

发布当天只处理三类事：

1. 确认发布状态；
2. 处理阻塞问题；
3. 记录数据和反馈。

不要因为前两条差评就改标签，不要因为销量低于预期就改价格，不要因为一个主播建议就加功能。首日数据噪声很大，除非是明显错误，否则重大调整放到首周复盘。

总验收清单

• D-7 冻结功能范围；
• D-6 构建从 Steam 客户端完整测试；
• D-5 商店页承诺和实际状态一致；
• D-4 价格、折扣和地区设置确认；
• D-3 公告、FAQ、客服模板准备；
• D-2 回滚和热修复演练；
• D-1 最终确认，不再创造新内容；
• D-0 只确认、响应和记录；
• 首周复盘时间已安排。

Steam 正式发布前，最有价值的不是再多加一个功能，而是把所有已经承诺的东西检查到位。个人开发者的精力很有限，最后 7 天应该从开发者切换成发行负责人。你要确保玩家能买、能玩、遇到问题有人回应；也要确保团队知道如果出错，下一步是什么。