2020 年个人开发者准备 Steam Direct 资料：从账号、税务到收款的上架前检查

为什么资料准备要先于商店页

很多个人开发者第一次上架 Steam 时，会把注意力放在商店页截图、预告片和愿望单上，直到临近公开页面才发现账号资料、税务问卷、银行信息或权限没有处理完。2020 年做独立游戏发行，远程协作已经很常见，开发者可能一个人在家里写代码，外包美术在另一个城市，发行协助只偶尔帮忙看后台。这个情况下，如果 Steamworks 的基础资料没有整理好，后续每一步都会被打断。

资料准备的目标不是“尽快填完表”。更准确的目标是：让游戏从应用创建、商店页审核、构建审核、收款、客服联系到日后打折，都能被同一套清晰资料支撑。一个个人项目越小，越不能靠口头记忆。因为项目里通常没有专门的运营、财务或法务，所有小遗漏都会回到开发者自己身上。

比较稳妥的做法，是在正式写 Steam 商店页之前先建立一份“上架资料包”。它不需要复杂系统，一个本地文件夹或私有云盘就可以，但结构要固定：

资料包不是为了“看起来专业”，而是为了减少后续返工。个人开发者的发行时间很容易被代码问题吞掉，如果行政资料再反复卡住，发布节奏就会完全失控。

先区分个人身份、品牌名和游戏名

Steamworks 后台里会出现几类名字：开发者法律主体、开发商显示名、发行商显示名、游戏名、包名、构建描述。个人开发者最容易混淆的是“真实收款主体”和“玩家看到的品牌”。如果你以个人身份注册，税务和银行信息通常需要对应真实个人信息；但商店页上可以显示工作室品牌名或开发团队名，前提是这个名字不要引发版权、商标或误导问题。

一个实用判断是：凡是和收款、税务、合同、后台账号恢复有关的信息，优先保持真实、可验证、可长期联系；凡是玩家看到的信息，优先保持清晰、易记、和游戏定位一致。不要为了显得像公司，在后台资料里随意写不存在的公司名。短期看似更正式，长期会在收款、税务证明、平台沟通里制造麻烦。

建议建立一张名称对照表：

这张表能避免一种常见问题：商店页、预告片结尾、新闻稿、官网页脚、客服邮箱签名各叫一个名字。玩家不会帮你理解内部历史，他们只会觉得信息不可靠。

账号权限不要只靠主账号

个人开发者常说“只有我一个人做，用一个账号就够了”。如果项目真的完全一个人完成，这个说法在开发阶段没问题；但到了上架阶段，你可能会让朋友帮忙看商店文案，让外包上传胶囊图，让测试人员下载测试分支，让本地化译者检查页面文本。此时如果所有人都用主账号，风险很高。

更合理的方式是按任务分配权限，而不是按关系分配权限。给每个协作者一个明确范围：谁能编辑商店页，谁只能看销售数据，谁能管理构建，谁能生成 Key，谁能发公告。权限越具体，误操作越少。尤其是 Key、包、价格、发布按钮这些功能，不应该为了“方便”开放给临时协作者。

个人项目可以采用三层权限：

1. 所有者层：只保留给项目负责人，用于账号资料、付款、税务、最终发布等高风险操作。
2. 制作层：给技术或发行协作，用于上传构建、查看审核状态、编辑部分商店资料。
3. 观察层：给顾问或测试负责人，用于查看页面、构建状态、统计数据，不允许改核心设置。

权限分配后要记录下来，至少写清楚“账号、用途、授予日期、计划收回日期”。很多安全问题不是来自恶意，而是来自项目结束后忘记回收权限。半年后你做 DLC 或折扣活动，才发现一个早已不参与项目的人还可以改商店资料，这就是管理缺口。

税务和银行信息要留出缓冲

Steam 的收款和税务资料不是上线当天才需要关心的事。即使你的游戏还没产生收入，平台也需要知道付款主体和税务信息。个人开发者尤其要注意三个细节：姓名拼写是否与银行账户一致、地址是否能被稳定联系、收款银行是否支持对应的跨境路径。

准备银行信息时，不要只复制一段银行 App 里的账户号。你应该确认这些字段：账户名、银行英文名、银行地址、SWIFT/BIC、账号或 IBAN、收款币种、中转行信息是否必要。不同银行后台显示方式不同，如果不确定，就去银行官方渠道查询跨境收款资料，而不是参考论坛里另一个人的截图。

税务问卷的原则也类似：不要猜。看不懂的问题先查官方解释或咨询专业人士，尤其是涉及税收协定、身份类型和地址证明的部分。个人开发者通常希望尽快跳过这些步骤，但这里填错后，后续更正会比一开始慢一点更麻烦。

建议给这些事项至少预留两周缓冲。缓冲不是说一定会花两周，而是给不可控情况留空间：银行信息被退回、税务问卷需要重新确认、两步验证设备丢失、收款名称和账号名称不一致。上架流程里，越接近发布日的阻塞越贵。

创建应用前先写清内部编号

拿到 Steamworks 访问权限后，开发者会创建应用。这里容易犯的错误是把 AppID 当成“后台自动生成的东西”，没有纳入项目管理。实际发行中，AppID 会出现在构建上传脚本、测试快捷方式、崩溃日志、官网链接、愿望单引导、公告草稿、客服模板里。如果你做了 Demo、原声带、DLC 或测试应用，多个 ID 更容易混乱。

在创建第一个应用时，就应该建立一张 AppID 表：

这张表可以很简单，但要和构建上传脚本放在一起。不要让程序员在脚本里写一个数字，运营在表格里写另一个数字，最后谁也不知道哪个是正式 AppID。

上架资料包的实际清单

下面是一份个人开发者在创建商店页前可以逐项检查的清单。它不是法律或财务建议，而是发行执行层面的“别漏项”工具。

这份清单最好在商店页公开前完成。如果等到发布前一天再补，任何一个问题都会变成“能不能按时发售”的问题。

一个小团队的真实执行节奏

假设你是一个 1 人程序加 1 名兼职美术的项目，计划 2020 年 12 月发售，8 月开始准备 Steam。比较现实的节奏是：

8 月第一周完成账号、身份、银行和税务资料；第二周创建应用，整理 AppID 表和权限记录；第三周准备商店页素材需求；第四周提交 Coming Soon 页面审核。9 月开始上传第一个可运行构建，同时准备 Demo 或测试分支。10 月集中处理页面转化、愿望单和外部曝光。11 月做正式构建审核、价格设置、发布公告、客服模板。12 月只保留修 Bug、确认发布按钮和上线后支持。

这个节奏看起来保守，但个人开发者最需要的就是保守。因为没有冗余岗位，任何一个突发问题都会占用开发者本人。提前两个月处理资料，不会让游戏质量下降；临近发售才处理资料，却很可能让你在最需要专注修 Bug 的时候反复切换到行政事项。

最后要避免的三种心态

第一种是“等游戏做完再管发行”。Steam 上架不是最后一天上传一个压缩包，而是从资料、页面、构建、测试、审核到玩家沟通的连续流程。越晚开始，越容易把所有风险堆到同一周。

第二种是“个人项目不用文档”。恰恰因为是个人项目，才需要文档。大公司可以靠岗位流程兜底，个人开发者只能靠清单和记录保护自己。

第三种是“后台能改就随便填”。很多字段虽然能改，但改动成本并不相同。玩家看到的品牌、商店 URL、游戏名、开发者名称、收款主体，都应该在发布前想清楚。随手填写会让后面的宣传和客服变得不稳定。

把 Steam Direct 的资料准备当成正式制作的一部分，而不是麻烦的杂事。这样做不会直接带来愿望单，但会让你后面每一次审核、构建上传、对外宣传和收款排查都有依据。对个人游戏来说，这种确定性本身就是发行能力。