SteamPipe 上传与版本记录：2021 年 1 月个人游戏构建上架实操

构建上传要变成固定流程

个人开发者在本地打包游戏时，通常习惯把构建发给朋友：压缩包、网盘、聊天软件、临时链接都能用。但 Steam 上架阶段不能继续靠这种方式。SteamPipe 上传关系到 Depot、分支、包、运行库、启动项、审核和玩家下载。如果没有固定流程，最后一周很容易出现“本地是新版，Steam 上是旧版”“审核拿到的不是发售版本”“测试人员下载了错误分支”。

2021 年 1 月准备发售时，建议把 SteamPipe 当成正式构建系统的一部分，而不是发布前最后一步。只要游戏有一个可跑通主循环的版本，就应该上传一次内部测试分支，验证从本地构建到 Steam 客户端安装的全链路。

分清 App、Depot、Branch、Package

Steamworks 后台里几个概念容易混在一起。个人项目越小，越要写清楚，因为没有专人帮你记。

如果你的游戏只有 Windows 版本，也可以从简单配置开始：一个主 App，一个 Windows Depot，一个默认分支，一个测试分支。但“简单”不代表可以不记录。只要涉及审核和发售，就要知道每个构建去了哪里。

本地构建目录要干净

SteamPipe 上传前，先规范本地构建目录。不要从游戏工程目录直接上传，也不要把开发文件、源素材、日志和测试存档一起打进去。建议使用固定目录：

builds/
  steam/
    win64/
      2021-01-14_v0.8.0_review/
      2021-01-16_v0.8.1_beta/
  notes/
    build-log.md

每个构建目录只放玩家需要下载的内容。上传前检查：

个人开发者经常因为“反正包体不大”忽略清理，但公开包里出现源素材或临时文件会带来版权、隐私和专业性问题。

版本号要同时服务开发和玩家

Steam 后台会有构建编号，但玩家、测试者和开发者沟通时仍然需要自己的版本号。建议使用简单版本规则，例如 0.8.0、0.8.1、1.0.0。版本号不需要复杂，但要稳定。

版本记录可以写成：

版本：0.8.1
上传日期：2021-01-16
目标分支：beta
对应提交：如果有 Git 则填写
主要变化：
- 修复第一章读取存档后任务目标丢失
- 调整低画质粒子数量
- 更新英文教程文本
已知问题：
- 窗口模式切换后部分机器需要重启
测试重点：
- 新存档、旧存档、首次启动、手柄设置

这份记录很朴素，但在发售前非常有用。玩家反馈“新版坏了”时，你可以快速知道他说的是哪个版本；审核要求重新提交时，也能确认提交内容。

分支策略要少而清楚

不要创建太多分支。个人项目维护能力有限，分支越多越容易混乱。建议最多保留：

每次推送分支时写清备注。不要让 beta 长期指向一个不知道内容的构建，也不要在发售当天临时把没测试的版本推到 default。分支是给人用的，不只是给系统用的。

测试包要从普通玩家视角验证

开发者账号通常有更多权限，所以“我能启动”不代表玩家能启动。测试包配置后，要找一个没有后台权限的账号按普通玩家路径安装。确认他能看到游戏、下载正确分支、启动正确版本。

测试包检查：

1. 测试账号是否获得正确包。
2. 包里是否包含正确 App 和 Depot。
3. 测试分支密码或访问方式是否清楚。
4. 下载后游戏内版本号是否与记录一致。
5. 测试结束后是否需要回收 Key 或权限。

如果测试人员很多，可以让他们截图主菜单版本号和 Steam 客户端分支。这样你不会把不同版本的反馈混在一起。

上传后必须做客户端测试

本地能运行不等于 Steam 客户端能运行。上传后至少做这些测试：

尤其要注意运行库。开发机装了很多组件，普通玩家机器没有。缺运行库导致无法启动，是发售初期很常见的问题。不要等差评出现才发现。

回滚记录从第一个候选版开始

很多人只准备上传，不准备回滚。回滚不一定会用到，但首发热修复时很重要。每个候选构建都应该知道能不能回退、回退后存档是否兼容、公告怎么说明。

回滚表：

如果某个版本改了存档结构，要特别标记。不能轻易回退到旧版本，否则玩家可能读不了新存档。

把上传动作写成固定脚本说明

即使你暂时没有自动化构建，也应该写一份上传说明。说明里不要只写“运行上传脚本”，要写清准备条件、目录、目标分支和验证方式。很多个人项目只有开发者本人知道怎么上传，但发售前一紧张，很容易漏掉清理文件、忘记改版本号，或者把构建推到错误分支。

一份可用说明可以包含：

1. 从引擎导出 Windows 64 位构建到指定目录；
2. 删除调试日志、测试存档、源素材和临时配置；
3. 打开游戏确认主菜单版本号；
4. 运行 SteamPipe 上传配置；
5. 上传到 beta 分支，不直接推 default；
6. 在另一台机器通过 Steam 客户端安装；
7. 截图保存版本号和启动结果；
8. 通过后再标记为 review 候选。

这份说明不需要复杂，但要能让一个月后的你看懂。发售后做热修复时，你会感谢自己把流程写清楚。

上传说明旁边还可以放一张“不要做”清单：不要从工程目录上传、不要跳过普通账号测试、不要把未验证构建推到默认分支、不要在没有记录的情况下覆盖候选版本。这类反向清单在压力下很有用。

构建上传最终清单

SteamPipe 的价值不只是上传文件，而是让你的游戏进入可追踪、可测试、可回滚的发布状态。个人开发者不需要复杂 CI 系统，也应该有清楚的版本记录。这样发售当天遇到问题时，你不是凭记忆猜，而是能沿着构建记录做判断。