Steam 评测期与 Embargo：独立游戏发售前媒体协作流程

Embargo 的目的不是神秘感

Embargo 指媒体或创作者在约定时间前不公开评测、视频或直播。独立游戏不一定都需要严格 embargo，但如果你希望发售日集中释放评测，或者评测版本提前给出，就必须把规则写清楚。Embargo 的目的不是制造神秘感，而是让媒体有时间准备内容，同时让开发者确保公开信息和发售版本一致。

小团队最常见的问题是：给了 Key，却没说能不能公开；说了发售日，却没说具体时区；版本仍有已知问题，却没写说明；媒体写完评测后，游戏又大改。这样会让双方都尴尬。

评测版本必须接近首发

不要把明显不稳定的版本发给媒体，除非你明确说这是 preview，不是 review。正式评测版本应尽量接近首发体验。

评测版本说明应包含：

• 版本号；
• 内容是否完整；
• 是否有未开放功能；
• 已知问题；
• 存档是否会兼容首发版；
• 是否允许截图和视频；
• Embargo 时间；
• 联系方式。

如果你发的是 preview，邮件标题和正文都要写清。不要让媒体用 preview 写正式评测。

Embargo 时间要具体到时区

“发售当天解禁”不够精确。应该写：

Embargo lifts: 2025-08-22 10:00 UTC
Steam release: 2025-08-22 10:00 UTC

如果你的主要媒体在多个时区，最好同时给出 UTC 和本地时间。时间不清会导致提前发布或错过发售窗口。

新闻包要和评测版本一致

新闻包里的截图、预告片、描述、价格、发售日、语言支持必须和评测版本一致。如果评测版本还没有某个语言，不要新闻包写已经支持。媒体通常会复制你的资料，错误会被放大传播。

新闻包至少包含：

• 一句话介绍；
• 长短介绍；
• Steam 链接；
• 发售日期和价格；
• 支持平台和语言；
• 截图；
• Logo；
• 预告片；
• 开发者简介；
• 联系方式；
• Embargo 说明。

已知问题要诚实

给媒体的已知问题不是自曝缺点，而是减少误解。比如：

• 某些字幕仍在润色；
• Deck 字体会在首日补丁改善；
• 第四章某支线暂有文本 Bug；
• 在线匹配压力测试仍在进行；
• 评测版本缺少最终成就图标。

如果问题会影响评分，最好不要发正式评测版本。若问题较小，说明它会在首日补丁修复。不要让媒体自己踩到再来问你。

媒体名单要分层

不是所有媒体都要同一时间、同一版本。可以分：

深度评测需要更多时间，短新闻需要准确信息，主播需要可展示版本。不要用同一封邮件解决所有人。

发售前版本变动要同步

如果评测版本发出后有重大修复，必须通知媒体。邮件要写清：

• 新版本号；
• 修复内容；
• 是否建议重玩；
• 存档是否兼容；
• 是否影响评测结论；
• 新 Build 或 Key 获取方式。

不要假设媒体会自动更新并注意到变化。很多评测内容会提前录制，开发者必须主动同步关键变化。

负面评测的处理

媒体拿到评测版后可能给负面评价。不要试图施压要求修改。你可以做的是：

• 回答事实问题；
• 提供补丁信息；
• 澄清误解；
• 接受主观评价；
• 不在公开场合攻击作者。

如果媒体指出真实问题，把它纳入补丁计划。独立开发者的专业度，会被媒体和玩家长期记住。

评测码批次和撤销计划

评测期发 Key 也要按批次管理。不要把所有媒体、主播和策展人放在同一个 Key 表里。批次至少要记录：对象、用途、版本、是否 embargo、是否已激活、是否产出内容。这样发售后你能知道哪一批带来了有效覆盖，哪一批只是消耗 Key。

如果评测版本出现重大问题，需要能快速通知所有已拿到该版本的人。邮件列表和批次记录会在这时发挥作用。不要等问题出现后才翻聊天记录找“我发给谁了”。

评测指南不是要求好评

可以给媒体一份评测指南，但它应该解释游戏，而不是暗示结论。指南可以包含：

• 推荐游玩时长；
• 核心系统说明；
• 哪些内容会在后期出现；
• 已知问题；
• 截图和视频规则；
• 禁止剧透范围；
• 联系方式。

不要写“请重点强调我们的创新系统”这类要求。媒体可以不喜欢你的游戏，你能做的是降低误解，让他们评测的是真实作品。

发售日信息同步

Embargo 解禁当天，Steam 页面、新闻包、公告、社媒、Discord、官网都要同步。媒体文章一旦发布，玩家会点击链接进入页面。如果页面仍显示 Coming Soon、价格不一致、Demo 按钮不清楚，媒体流量会浪费。

建议发售前一天做一次“媒体点击路径”测试：从新闻稿链接进入 Steam 页面，确认玩家能看到价格、购买按钮、预告片、语言、系统需求和反馈入口。不要只检查后台状态。

小团队如何设置轻量 embargo

如果没有正式 PR 团队，也可以采用轻量规则。邮件里只写三件事：可公开时间、版本状态、联系方式。比如“你可以从 8 月 22 日 18:00 北京时间后发布视频；当前版本是 1.0 RC，首日会有小文本补丁；如遇到第三章结算问题请直接联系这个邮箱”。简单但明确，比完全不写规则要好。

不要设置你无法执行的复杂 embargo。比如要求所有创作者同一秒发布、禁止任何截图、要求审稿，这对小团队不现实，也会降低合作意愿。规则越少，越要准确。

评测期和首日补丁

如果首日补丁会显著改变体验，评测期要谨慎。媒体评测的版本如果和玩家首日版本差异太大，双方都会不满。可选方案是：推迟评测码、提前给补丁候选、或明确说明某些问题会在首日修复。不要让媒体评测一个你自己也不认可的版本。

媒体问题的答复库

评测期经常会收到重复问题：流程多长、是否有中文、是否支持 Deck、是否允许直播、是否有多人、是否有 DLC 计划、是否能提供额外 Key。不要每次临时回答。可以提前准备答复库，并确保它和商店页一致。

答复库示例：

答复库能减少口径差异。媒体收到清楚回复，也更容易写出准确内容。

常见错误

评测期最常见的错误是把 Key 发得太晚。媒体和主播没有时间体验，只能做浅层内容。第二个错误是 embargo 时间写得含糊，导致有人提前发、有人错过发售窗口。第三个错误是评测版和首发版差异太大，媒体内容发布后玩家看到的游戏已经不同。小团队可以不做复杂 PR，但必须把版本、时间和已知问题写清。

评测期结束后也要复盘：哪些媒体真正覆盖了游戏，哪些问题被反复询问，哪些资料没有被使用。下一次发 DLC 或新作时，这些记录比临时重新找名单可靠得多。

如果某家媒体长期认真覆盖你的品类，要维护关系。发售后发送补丁计划或后续更新信息，比只在需要曝光时联系更专业。

媒体关系不是一次性名单，而是长期信任。你提供的信息越准确，下次对方越愿意打开你的邮件。

发售后也可以给媒体发送一封简短更新，不推销，只说明首周补丁、玩家反馈和后续计划。这能为下一次报道留下上下文。

长期看，这比一次性群发更有效。

也更容易获得后续更新报道。

准确、克制、持续的沟通，比临时追热点更能建立媒体信任。

评测期清单

• 区分 preview 和 review；
• 评测版本接近首发体验；
• Embargo 写明日期和时区；
• 新闻包与评测版本一致；
• 已知问题诚实说明；
• 媒体名单按内容形式分层；
• 版本变动主动同步；
• 负面评测只澄清事实，不施压；
• 发售日检查所有公开信息一致。

评测期的核心是信任。媒体相信你给的是可评测版本，玩家相信媒体看到的接近首发体验，开发者也相信公开时间可控。把这些流程写清楚，独立游戏即使没有大型 PR 团队，也能把发售前媒体协作做得专业。