Steamworks 账号与上架资料准备：独立游戏上线前的第一张清单

为什么账号资料会拖慢发行

很多个人开发者第一次做 Steam 上架时，最容易低估的不是构建上传，也不是商店页文案，而是账号、税务、收款和权限这些“看起来只要填表”的事情。它们不像游戏 Bug 那样直观，却很容易在发售前两周变成真正的阻塞：公司名和银行账户名对不上、税务表格需要重新确认、应用名称临时改动导致素材全部重做、团队成员不知道谁有发布权限，最后大家在 Steamworks 后台里互相等。

Steamworks 的后台流程本质上是一套发行项目管理系统。你要先确认开发者身份，支付每个应用的 Steam Direct Fee，然后给应用创建商店页、上传构建、提交审核、设置定价和发布日期。只要其中一个环节的信息前后不一致，后面就会不断返工。对个人团队来说，返工最贵的地方不是多花几小时，而是打乱发售节奏：媒体邮件已经发出，Demo 也已经公开，但商店页仍然在等资料修正。

这篇文章只讨论上架资料和账号准备，不讨论营销文案和构建细节。把这部分做好，后续发行会顺很多。

先决定发布主体

发布主体通常有三种选择：个人、已注册公司、临时准备注册的工作室或公司。不要只从“看起来专业”出发选择主体，应该从税务、收款、长期维护和品牌资产四个角度判断。

一个实用判断是：如果这款游戏只是验证市场，个人主体通常更快；如果你已经在做第二款、第三款，或者需要和美术、音乐、发行伙伴签正式合同，公司主体更方便。不要在上架中途频繁切换主体，因为合同、收款和税务信息的变动会牵连后台资料，也会影响内部归档。

Steam Direct Fee 不只是付款动作

Steam Direct 要求每个新应用支付一次费用。官方文档说明，这笔费用在产品达到一定调整后总收入门槛后可以通过后续付款抵扣。对独立开发者来说，关键不是这笔费用本身，而是它代表“你已经开始为某个 App ID 建立正式发行资产”。

支付前至少确认四件事：

1. 游戏名称是否已经比较稳定；
2. 你是否确定这个 App ID 用于正式游戏，而不是测试项目；
3. 开发者主体资料是否已经决定；
4. 发行计划是否允许你提前几个月开放 Coming Soon 页面。

不要把 Steam Direct 当成“最后上传前再买”。更好的节奏是：核心玩法可展示、游戏名基本确认、首批商店素材能在 2-4 周内完成时，就开始准备。这样你可以尽早获得商店页草稿和后台配置空间，而不是等营销节奏启动后才补手续。

税务和收款资料的准备方式

税务和收款最怕“边填边查”。建议在打开后台表格前，先准备一个只供团队内部使用的资料包，里面放清楚以下信息：

资料包不需要复杂，但要有版本号。比如 steamworks-payout-info-2023-01，后续每次修改都记录原因。很多小团队到发售后才发现，后台收款账户是谁填的、什么时候改过、为什么改，没人说得清。这个问题在第一款游戏可能不明显，一旦你有 DLC、原声集、捆绑包、退款对账和外包分成，就会变成麻烦。

权限分配不要只给“最懂技术的人”

Steamworks 后台涉及商务、商店页、构建、公告、折扣、用户支持等多个模块。个人团队往往把所有权限都放在程序员账号上，因为程序员负责上传 Build。但发行过程中，最常操作后台的人未必是程序员。

建议把权限按角色拆开：

如果只有一个人，也要给自己做一份权限操作清单。Steamworks 后台的某些操作不像本地 Git 那样容易回滚。正式发布前，最好用“谁可以点发布、谁可以改价格、谁可以切默认分支、谁负责最终确认”的方式写下来。

应用资料要先建信息表

进入 Steamworks 后，你会看到很多字段：应用名称、类型、支持语言、平台、系统需求、商店描述、标签、年龄分级相关信息、成就、云存档、控制器支持、社区功能等。不要等后台要求你填时才开始想。更高效的方法是先建立一张应用资料表。

应用资料表可以包含这些字段：

• 游戏正式中文名、英文名、内部代号；
• 一句话描述、短描述、长描述；
• 类型、核心玩法、相似游戏、差异点；
• 支持平台：Windows、macOS、Linux、Steam Deck 计划；
• 支持语言：界面、字幕、语音分别标注；
• 年龄内容：暴力、恐怖、酒精、成人内容、赌博元素；
• 预计价格、首发折扣、地区定价策略；
• Demo、试玩版、原声集、DLC 的计划；
• 外部链接：官网、Discord、微博、B 站、YouTube、新闻包。

这张表的价值不在于“看起来专业”，而在于减少不同页面之间的口径不一致。比如短描述说游戏是“生存建造”，标签却主要选“解谜”和“休闲”；截图展示战斗，长描述强调剧情；中文页面写支持手柄，英文页面漏写。这些不一致都会降低玩家信任。

名称、商标和搜索结果要提前检查

游戏名不是只要你喜欢就可以。上架前至少做三层检查：

1. Steam 内搜索是否已有高度相似名称；
2. Google、Bing、YouTube、TikTok、B 站等平台是否已有同名作品或强势品牌；
3. 域名、社媒账号、新闻包文件名是否能保持一致。

如果游戏名由常见词组成，搜索会很吃亏。比如一个游戏叫 Echo，玩家很难通过搜索直接找到你；如果叫 Echoes of the Salt Rail，虽然长一点，但更容易建立唯一性。中文名也要考虑口口相传：太文艺但无法记住、太长导致主播读不顺、和已有热门作品相似，都会影响传播。

更稳妥的做法是把“正式名、短称、社媒标签、文件夹名、预告片标题”一起确认。这样后续做 Steam Capsule、Press Kit、UTM 链接和客服模板时，不会每个地方都出现不同命名。

上架前的内部资料夹结构

一个小团队也应该把发行资料放在统一位置。推荐结构如下：

steam-release/
  00-admin/
  01-store-copy/
  02-capsules/
  03-screenshots/
  04-trailers/
  05-build-notes/
  06-press-kit/
  07-support/
  08-postmortem/

00-admin 放不含敏感明文密码的账号、主体、收款资料记录；01-store-copy 放多语言文案；02-capsules 放 Steam 要求尺寸的图；05-build-notes 放每次上传构建的版本号、提交时间、改动、测试结果；07-support 放常见问题和客服回复。这样做的好处是，发行当天有人问“最新启动项是什么”“英文短描述是哪版”“媒体包里有没有透明 Logo”，你不用翻聊天记录。

时间线：至少提前 90 天处理资料

如果计划 2023 年 6 月发售，一个比较稳的资料时间线是：

这个时间线看起来保守，但它给你留出了返工空间。上架不是写完表格就结束，审核反馈、素材调整、构建测试、定价确认都会占时间。独立团队人少，最怕所有事情都在最后一周汇合。

常见错误和修正办法

错误一：商店页署名和后台主体混乱。
页面写的是某某工作室，后台主体是个人，新闻稿又写另一家公司。修正方法是定义三个概念：法律主体、开发品牌、发行品牌。法律主体用于合同和收款，开发品牌用于玩家识别，发行品牌用于商店页展示。三者可以不同，但要能解释。

错误二：把收款账户当成发售后再处理。
发售后才处理收款，通常会影响对账和团队信任。即使第一笔收入还很远，也要在发售前完成资料验证。

错误三：权限没有备份。
只有一个成员拥有关键权限，结果发售当天账号登录异常。至少准备一位备用负责人，并确保邮箱、双重验证和紧急联系方式可用。

错误四：没有记录应用配置决策。
为什么只发 Windows？为什么暂不支持中文语音？为什么不做 Linux？这些决定如果没有记录，后续社区提问时就会反复解释。建议在应用资料表中加入“暂不支持原因”和“未来评估条件”。

最后一份上架资料清单

正式进入商店页和构建阶段前，可以按这份清单自查：

• 开发者主体已确定，资料名称和收款账户一致；
• Steam Direct 费用预算、App ID 归属和内部记录完成；
• 税务、收款、联系邮箱、后台权限已经确认；
• 游戏名、短称、英文名、社媒账号和搜索结果检查过；
• 应用资料表已经覆盖语言、平台、系统需求、年龄内容和价格；
• 商店素材文件夹已经建立，文件名按用途和尺寸命名；
• 团队知道谁负责商店页、构建、财务、客服和发布确认；
• 预计 Coming Soon、Demo、正式发售的时间线已经写入日历。

Steam 上架不是一次表单提交，而是一组相互依赖的发行准备。账号资料做得越清楚，后面的商店页、Demo、构建、定价和首发运营越不容易失控。对个人游戏来说，这些看似行政的事情往往决定了你能不能在发售窗口把精力放回游戏和玩家本身。