Steam 商店页审核准备：2021 年 1 月个人游戏提交前逐项检查

审核通过不等于页面有效

个人开发者提交 Steam 商店页审核时，常把目标设成“通过审核”。这当然重要，但它只是底线。审核通过说明页面资料和素材大体符合平台要求，不代表玩家能看懂，不代表愿望单会增长，也不代表发售后不会出现预期落差。真正有效的商店页，应该同时满足合规、清晰、可信、可转化。

2021 年 1 月准备上架时，很多项目经历了 2020 年远程开发和节奏变化，页面素材可能来自不同版本：截图是去年 10 月的，预告片是 12 月的，短描述还是早期设想，构建已经改了玩法。提交审核前最该做的是“对齐”，不是“补齐”。如果页面讲的游戏和当前构建不是同一个体验，发售后很容易被玩家指出。

建立页面承诺表

审核前先把页面里的所有承诺列出来。承诺不只是“支持中文”“包含 20 个关卡”这种明确语句，也包括截图、预告片、标签带来的暗示。

这张表会让很多隐藏问题浮出来。个人开发者常因为熟悉项目而忽略页面暗示，但玩家只看页面，不知道开发历史。只要页面给出错误期待，发售后就会转化为退款、差评或反复提问。

短描述先解决“是什么”

短描述最重要的是回答“这是什么游戏”。不要在短描述里写太多抽象情绪，也不要把世界观放在玩法前面。一个可用结构是：类型、核心动作、差异机制。

不建议：

在破碎世界中寻找希望，体验一段关于选择和牺牲的旅程。

更适合：

在每天重排的地下设施里调度三名工程师，用有限氧气修复电力、封堵泄漏并带队撤离的单人资源管理游戏。

后者不一定更华丽，但玩家能立刻判断是否感兴趣。审核前可以让 3 个没玩过的人只读短描述，然后问他们游戏怎么玩。如果答案偏差很大，先改短描述，不要急着提交。

长描述要分层，不要堆功能

长描述不是功能清单，也不是开发者感言。玩家读到长描述时，通常已经对游戏有一点兴趣，但仍在犹豫。你需要按问题组织内容：

1. 玩家每局或每章会做什么。
2. 游戏如何制造变化和压力。
3. 首发版本具体包含什么。
4. 适合哪些玩家，不适合哪些期待。
5. Demo、存档、语言、控制器等关键限制。

一个实用结构：

## 你会做什么
说明核心循环和玩家决策。

## 每次游玩有什么变化
说明地图、资源、敌人、事件、构筑或剧情分支。

## 首发版本包含什么
列出模式、区域、语言、控制器、存档。

## 适合哪些玩家
明确节奏、难度和体验边界。

如果页面只写“丰富内容、精彩剧情、多样系统”，玩家无法判断价值。越是个人游戏，越要用具体内容建立可信度。

截图要从当前构建重截

审核前最好重新截一组核心截图。旧截图常带着过时 UI、未授权临时素材、调试文字、已删除功能或不匹配语言。截图不是美术展示，而是玩法证据。

推荐 6 张核心截图：

截图里可以保留 UI，尤其是策略、模拟、卡牌和经营游戏。隐藏 UI 后虽然画面干净，但玩家看不懂决策。审核前把截图缩小预览，确认文字仍然可读，画面里没有调试面板和占位符。

预告片前 10 秒要出现真实玩法

商店页审核不负责替你判断预告片是否能转化，但玩家会判断。个人游戏常见问题是预告片开头太长：Logo、黑屏、字幕、慢镜头、世界观铺垫占了前 20 秒。Steam 页面里，玩家很可能同时浏览多个游戏，前 10 秒看不到玩法就会离开。

一个 60 秒预告片可以这样安排：

预告片文字卡要少，每张只说一个信息。不要把长描述搬进视频，也不要展示当前构建不存在的功能。预告片越诚实，发售后预期越稳定。

标签和语言要对应真实体验

标签影响玩家如何理解游戏。不要为了曝光填热门标签。一个游戏如果只有轻微随机元素，就不要把 Roguelike 放在前面；如果只是有少量经营菜单，也不要包装成深度模拟。标签应该代表主要体验。

语言也是审核前重点。商店页勾选语言支持时，要问：

1. 菜单、设置、教程是否已翻译。
2. 核心系统文本是否可理解。
3. 剧情和任务是否完成校对。
4. 截图语言是否匹配页面语言。
5. Demo 和正式版语言状态是否一致。

如果英文页面写得很好，但游戏内英文文本明显机器翻译，玩家会觉得被误导。语言支持宁可保守，不要先承诺后补。

成熟内容和版权不要含糊

审核前要检查成熟内容问卷和素材版权。个人项目常用临时音乐、字体、外包图、参考图和素材商店资源。只要进入公开商店页，就应该确认授权。不要把“测试时能用”的素材带到页面里。

成熟内容也要诚实。如果游戏里有血腥、恐怖、赌博元素、药物、性暗示或其他敏感内容，页面资料要对应说明。隐藏这些内容可能短期让页面更干净，但长期会影响玩家预期和审核沟通。

可以建立一份素材来源表：

这张表在上架到其他平台时也能复用。

审核返工要记录原因

如果审核返回修改意见，不要只改完就算了。记录原因、修改内容、提交时间和对应版本。个人开发者经常在几个月后忘记当时为什么改页面，后续又把同类问题加回来。

记录格式可以很简单：

这种记录能让审核变成流程资产，而不是一次性痛苦。

找人做一次盲读

提交前可以找一个没玩过项目的人做盲读。只给他看商店页草稿，不解释背景，让他说出游戏类型、玩家要做什么、是否愿意加入愿望单、还有什么疑问。如果他连续问出页面已经写了但没被注意到的问题，说明信息位置不对；如果他说出的玩法和你的实际玩法不同，说明短描述、标签或首图在误导。盲读十分钟，往往比开发者自己检查一小时更有效。

提交前最后 30 分钟检查

提交前按普通玩家路径走一遍：

1. 只看首屏，能否知道游戏类型。
2. 不播放视频，只看截图，能否理解核心玩法。
3. 只读短描述，能否复述玩家动作。
4. 读长描述，能否知道首发版本包含什么。
5. 检查标签，是否会吸引错误玩家。
6. 检查语言和系统需求，是否与构建一致。
7. 检查开发商、发行商、官网、客服邮箱是否一致。

如果这 7 项都过得去，再提交审核。商店页审核准备的核心不是让页面看起来“丰富”，而是让页面承诺和真实游戏对齐。对个人开发者来说，这种对齐会减少后续解释成本，也会让愿望单更接近真正目标玩家。