Steam 上架前 90 天计划：个人游戏如何把发行拆成可执行日程

90 天计划解决的是顺序问题

个人开发者做 Steam 发行时，经常不是不知道要做什么，而是不知道先做什么。商店页要改，截图要补，Demo 想做，构建还没测，媒体名单没整理，社区没人运营，发售日又快到了。所有事情混在一起，最后就会变成“每天都很忙，但没有一个环节真正完成”。

发售前 90 天计划的意义不是制造仪式感，而是解决顺序问题。Steam 上架有明显依赖关系：商店页公开后才能更有效积累愿望单；素材清楚后媒体才方便理解；构建稳定后审核和 Demo 才可靠；价格、日期、语言和支持渠道确定后，发售周才不会临时失控。把这些环节拆开，你会发现很多事情并不难，难的是不要把它们都拖到最后两周。

下面这套计划适合一人或两三人的小团队。它假设游戏核心内容已经接近可玩，距离正式发售约三个月。如果你的游戏还没有稳定核心循环，不建议先套发行日程，应该先回到产品验证。

T-90 到 T-75：确定公开承诺

发售前三个月，最重要的是确定对外承诺。也就是你准备向玩家说什么，并且确信自己能交付。这个阶段不要急着写长篇宣传稿，先把游戏定位压缩成可执行材料。

需要完成的内容：

很多个人游戏的宣传空泛，是因为发售版本边界不清。比如你想做无尽模式、关卡编辑器、多人合作、手柄支持和多语言，但没有一个完全稳定。此时最好的做法不是全部写进页面，而是区分“首发承诺”和“后续计划”。Steam 玩家可以接受小体量游戏，但很难接受页面承诺和实际内容不一致。

这个阶段还要做一次“砍承诺”会议，即使团队只有你一个人也要写下来：哪些功能不再作为首发卖点，哪些内容可以放到更新，哪些素材暂时不展示。个人发行最需要克制，因为每增加一个公开承诺，都会增加测试、客服和差评风险。

T-74 到 T-60：商店页进入可审核状态

这个阶段的目标是让商店页达到可提交、可传播、可积累愿望单的状态。不要等游戏全部完成才做页面。商店页越晚，愿望单积累窗口越短，媒体和主播也越难提前安排。

商店页需要至少完成：

• 短描述和长描述；
• 真实游戏截图；
• 首版 Trailer 或实机短片；
• 胶囊图和库资产；
• 类型标签；
• 系统需求；
• 语言支持；
• 发售时间显示策略；
• 社区链接或官网链接。

这里的“完成”不是指以后不改，而是指可以让陌生玩家理解游戏。你可以在后续 60 天持续优化截图和文案，但不能让页面一直处于半成品状态。一个常见做法是先提交审核，审核通过后再选择合适时间公开 Coming Soon。这样你不会在准备宣传时突然被页面问题卡住。

同时，建立一个商店页问题表：

这个表的价值在于防止页面修改变成情绪劳动。你不是“觉得哪里不够好”就改，而是根据反馈逐项处理。

T-59 到 T-45：准备 Demo 或可公开验证内容

不是每个游戏都必须做 Demo，但每个游戏都需要可公开验证的内容。这个内容可以是 Demo、封闭测试、实机视频、试玩活动或开发者直播。个人开发者尤其需要验证，因为你的页面和实际体验之间可能存在偏差。

如果做 Demo，需要明确它的任务：

Demo 最大的坑是“把游戏开头剪出来就算完成”。很多游戏开头是教程、剧情铺垫和慢热探索，并不适合代表完整体验。Demo 应该像一次浓缩展示：既不欺骗玩家，也要让玩家看到真正的决策和乐趣。如果你的完整游戏 2 小时后才变好玩，Demo 不应该让玩家等 2 小时。

如果不做 Demo，也要准备一套实机素材：一段 60 秒核心循环视频、几张前后对比截图、一份玩法说明图、一篇开发日志。没有可验证内容，宣传只能依赖形容词，效果会很弱。

T-44 到 T-30：构建审核和外部测试

发售前一个半月，应该把重心转向稳定性。这个阶段不适合再加入大系统。你要提交构建审核，给外部测试者玩 Steam 下载版，并记录阻塞问题。

外部测试者不需要很多，5-10 个足够暴露第一批问题。关键是他们不能只说“挺好玩”。你要给任务：

• 从 Steam 安装并启动；
• 不看开发者说明玩前 20 分钟；
• 记录第一次卡住的位置；
• 尝试手柄或键鼠切换；
• 退出重进检查存档；
• 给出一句话理解：这游戏到底在玩什么；
• 标出最想继续玩的点和最想放弃的点。

测试反馈可以按严重程度分类：

个人开发者要特别警惕“最后阶段加功能”。测试者提出的新点子可能很好，但发售前 30 天不是验证新系统的好时间。此时最有价值的工作是让现有承诺稳定兑现。

T-29 到 T-15：对外沟通和愿望单冲刺

发售前一个月，宣传应该进入具体沟通，而不是笼统发动态。你需要准备一套可转发材料：商店链接、简短介绍、截图包、Trailer、Demo 链接、发售日期、联系方式、可直播说明。

媒体和主播邮件不必写得很长。对小项目来说，清楚比华丽重要：

你好，我是某某，正在开发一款关于时间回溯的解谜游戏。
游戏将于 2021 年 X 月 X 日在 Steam 发售，目前已有 Demo。
它适合喜欢短流程、机关推理和低压探索的玩家。
这里是 Steam 页面、Trailer 和媒体素材包。
如果你愿意试玩，我可以提供测试 Key。

不要群发毫无对象感的长邮件。你至少要知道对方是否玩过类似类型，是否接受独立游戏，是否需要提前码，是否偏好短视频素材。个人开发者数量少，时间有限，更应该把沟通做窄。

愿望单冲刺也要有节奏：

每次动态都要有新的信息，不要反复说“快来加入愿望单”。玩家愿意加入愿望单，是因为他看到了更具体的理由。

T-14 到 T-7：发售周演练

发售前两周，开始按发售当天流程演练。检查的不只是游戏，还有后台设置和沟通材料。

演练清单：

• 默认分支是否指向正确构建；
• 商店页价格、语言、系统需求是否一致；
• 发售日期和时区是否确认；
• 社区公告草稿是否写好；
• 首日补丁说明是否准备；
• Key 是否按用途分类；
• 客服邮箱或表单是否可用；
• 已知问题列表是否公开或内部准备；
• 回滚构建是否保留；
• 发售当天谁负责看评论、谁负责修 Bug。

个人开发者可能只有一个人，但也要把角色写出来。比如上午看论坛，中午修启动问题，下午发公告，晚上整理反馈。否则发售当天你会被各种声音牵着走。

T-6 到 T-1：停止制造新变量

最后一周最重要的原则是停止制造新变量。不要换引擎版本，不要重做 UI，不要改存档结构，不要新增未经测试的语言，不要临时接入复杂 SDK。能修阻塞问题就修，不能修但可说明的问题就写进已知问题。

最后一周可以做的事情：

• 校对商店页所有文字；
• 再录一遍发售版前 10 分钟；
• 用干净电脑安装测试；
• 检查退款风险点，例如宣传与实际不一致；
• 准备发售公告；
• 睡觉。

“睡觉”不是玩笑。个人开发者发售当天需要判断很多事情，疲劳会让你把小问题看成灾难，也会把大问题误判成暂时现象。发行是长跑，不是按下发售按钮的一瞬间。

90 天计划的核心是留缓冲

这套计划不会替你决定销量，也不会替你获得推荐算法偏爱。它的价值是把发行拆成一组可完成的动作，并给每个关键环节留缓冲。Steam 上架对个人开发者并不神秘，但它会惩罚拖延和含糊。商店页晚、Demo 晚、构建晚、宣传晚，最后都会堆到发售周，变成难以修复的混乱。

真正可执行的发行计划应该让你每天知道“今天完成什么就够了”。当你能按节奏公开页面、验证内容、稳定构建、沟通玩家，并在最后一周停止新增风险，发售当天就不会只剩祈祷。个人游戏的资源有限，但节奏可以很清楚。清楚的节奏，本身就是小团队最可靠的发行能力。