发布策略
此技能帮助使用结构化、可重复的框架来计划和执行产品发布。核心洞察：大多数团队只做大规模、轰动的发布。通过将每一次发布（无论其重要性大小）都视为一个潜在的发布时刻，你可以持续建立知名度、获客和激活。目标是建立一个发布引擎，而不是一次性事件。
发布层级
每个发布都映射到三个层级之一。层级决定了在消息传递、资产和分发上投入多少精力。
第一层：重大新产品或平台转变
全面发布。这是你的标志性时刻——新产品、重大品牌重塑、平台扩展。预计准备时间为2-4周。
典型资产： 发布视频（动态设计或创始人叙事）、专属落地页、博客文章、媒体联系、社交活动（所有平台）、面向全部用户的邮件、内部推广推送。
第二层：重大新功能
一个能改变用户能力的实质性新增功能。值得单独发布公告，但不需要全面的媒体推广。预计准备时间为1-2周。
典型资产： 发布推文/帖子、博客文章或变更日志条目、更新后的落地页板块、面向相关用户群体的邮件、2-3个平台上的社交帖子。
第三层：小型改进和迭代
错误修复、UI 打磨、渐进式改进。仍然值得宣布——它们传递出产品正在不断创新和受到关注的信息。准备时间：几小时到一天。
典型资产： 变更日志条目、一个社交平台上的帖子、可选的邮件摘要提及。
如何选择层级
问问自己：“如果一个潜在客户看到这个公告，会改变他们对产品能力的看法吗？”如果会→第一层或第二层。如果更多是关于质量和可靠性→第三层。
拿不准的时候，就升一级。发布不足比发布过度更常见。一个本应是第三层的发布却按第二层来准备，只会多花几个小时。而一个本该以第一层发布的重大更新被降级为第三层，则是错失的增长机会。
消息传递框架
消息传递优先于其他所有事项。在消息锁定之前不要开始制作资产。一段普通的视频配上一个优秀的消息传递，其效果远超一段精美视频配上混乱的定位。
消息传递简报
对于每一次发布（任何层级），请定义：
-
名称 — 你叫它什么？对于有 SEO 潜力的功能，使用搜索数据来选择。查看人们实际搜索的内容（例如，“speech to text” vs. “transcription API”——如果受众匹配，选择搜索量更大的）。Google Trends 和关键词研究平台可以提供帮助。
-
受众 — 谁具体受益？要精确。“开发者”太宽泛。“构建实时语音应用的后端工程师”为您提供了明确的写作目标。
-
主要价值主张 — 一句话。他们现在能做之前不能做什么，或者有什么显著改善？这将成为所有地方的标题。
-
次要价值主张 — 2-3 个支持点。这些内容填充博客文章、落地页板块和推文/帖子。
-
证明点 — 数据、基准、对比、客户引用。任何能让价值主张具体而非空想的东西。
消息传递测试
大声读出你的主要价值主张。如果它也同样适用于描述竞争对手的产品，那说明它太泛泛了。最好的价值主张足够具体，能让目标受众中的某个人立即知道这是否适合他们。
发布清单系统
创建一个包含所有可能发布动作的主清单，并按层级组织。对于每次新发布：
- 将主清单复制到一个新实例（新标签页、新工单、新页面）
- 删除不适用于此层级/发布的行
- 为剩余的行分配负责人和截止日期
- 将其作为发布日当天唯一的真实信息来源
工具选择
选择一个系统并坚持使用。具体工具比坚持使用本身的重要性要低。
- 电子表格（Google Sheets、Notion 数据库）— 最简单。适用于小团队。一个主表，每个发布一个标签页。缺点：没有内置的分配或通知功能。
- 项目管理工具（Linear、Asana、Notion）— 更适合团队。创建一个发布模板项目。每个发布都获得一个副本，其中包含可分配的任务和截止日期。Linear 标签或 Asana 版块可以映射到下面的层级列。
- 文档 + 清单（Notion、Google Docs）— 折中方案。带复选框的模板文档。易于复制，但跨发布的状态跟踪更难。
无论你使用何种工具，每次回顾后都要更新主模板。模板是一个活的文档——它会随着每次发布而变得更好。
清单模板结构
| 类别 | 操作 | 第一层 | 第二层 | 第三层 | 负责人 | 截止日期 | 状态 |
|---|---|---|---|---|---|---|---|
| 消息传递 | 编写消息传递简报 | ✓ | ✓ | ✓ | |||
| 消息传递 | 为命名进行 SEO 关键词研究 | ✓ | 可选 | — | |||
| 资产 | 发布视频 | ✓ | 可选 | — | |||
| 资产 | 落地页（新建或更新） | ✓ | ✓ | — | |||
| 资产 | 博客文章 | ✓ | ✓ | 可选 | |||
| 资产 | 变更日志条目 | ✓ | ✓ | ✓ | |||
| 社交 | 发布推文/帖子 | ✓ | ✓ | ✓ | |||
| 社交 | LinkedIn 帖子 | ✓ | ✓ | 可选 | |||
| 社交 | 其他平台（BlueSky、Threads） | ✓ | 可选 | — | |||
| 分发 | Product Hunt 提交 | ✓ | 可选 | — | |||
| 分发 | Hacker News 帖子 | ✓ | 可选 | — | |||
| 分发 | 媒体/记者联系 | ✓ | — | — | |||
| 分发 | 邀请影响者/网络转发 | ✓ | ✓ | — | |||
| 邮件 | 全量用户公告 | ✓ | — | — | |||
| 邮件 | 特定用户群体邮件 | 可选 | ✓ | — | |||
| 邮件 | 变更日志摘要提及 | — | 可选 | ✓ | |||
| 内部 | #amplify 频道发布 | ✓ | ✓ | 可选 | |||
| 内部 | 团队简报 | ✓ | 可选 | — | |||
| 追踪 | 为所有链接设置 UTM 参数 | ✓ | ✓ | 可选 | |||
| 追踪 | 验证分析事件是否触发 | ✓ | 可选 | — | |||
| 追踪 | 捕获基准指标 | ✓ | ✓ | — | |||
| 发布后 | 安排回顾（一周后） | ✓ | ✓ | — |
发布时间线
第一层时间线（2-4周）
第3-4周之前： 锁定消息传递简报。开始落地页和视频制作。开始媒体联系（记者需要提前准备时间）。
第1-2周： 确定所有资产。撰写社交文案。准备邮件。向内部团队简要介绍。设置追踪（UTM参数、分析事件）。对分发序列进行预演。
发布日： 按顺序执行分发——首先社交（早上），然后邮件，然后媒体禁令解除。全天监控并回复评论/回复。
发布后一周： 进行回顾。
第二层时间线（1-2周）
第2周之前： 锁定消息传递。开始博客文章和落地页更新。
第1周： 确定文案。撰写社交帖子。准备邮件用户群体。
发布日： 发布社交内容、发布博客、发送邮件。回复互动。
第3-5天后： 快速回顾（异步，例如 Slack 线程）。
第三层时间线（当天或次日）
发布。编写变更日志条目和一篇社交帖子。完成。如果是批量小型改进的一部分，将它们捆绑到每周摘要中。
发布后回顾
不要跳过这一步。回顾是将单个发布转变为复合发布引擎的关键。
涵盖内容
- 哪些有效？ 哪些渠道带来最多流量、注册或互动？哪些消息传递引起了共鸣？
- 哪些无效？ 哪些资产表现不佳？时间线在哪方面出现延误？
- 意外情况？ 是否有意料之外的渠道爆发？是否有特定的表述效果超出预期？
- 数据 — 流量、注册、激活、社交互动、媒体报道。如果可以，与之前的发布进行比较。
- 清单更新 — 根据学到的经验，从主清单中增加或删除项目。
回顾形式
保持轻量。对于第二层发布，一个 Slack 线程或 15 分钟的电话就足够了。第一层发布值得一份简短文档。关键产出是对清单和流程的具体更改，而不是一篇回顾性论文。
“一切都是发布”的理念
如果你每月发布多次，但每季度只正式推出几次，那你就是在将增长机会拱手让人。每一次发布都是一个讲述你的故事、提醒人们你的存在并展示产品动力的机会。
这并不意味着每个错误修复都需要一份新闻稿。它意味着每次改进都应该得到某种程度的公告，并根据其重要性进行缩放。第三层发布只需几分钟。持续可见性的复合效应是巨大的。
养成习惯：当 PR 合并时，发布清单就应打开。
与配套技能协作
此技能负责策略和规划。具体执行方面，请参考：
- launch-tweet — 撰写社交文案（推文、帖子、LinkedIn、跨平台）
- launch-email — 邮件主题行、公告结构、用户细分、变更日志摘要
- launch-blog-post — 撰写公告博客（结构、SEO、AEO）
- launch-video — 演示视频、GIF、截图以及使用 Remotion 制作的程序化视频
- launch-landing-page — 构建落地页（结构、紧迫性机制、SEO、转化）
- launch-distribution — 按渠道分发和发布日序列
- launch-metrics — UTM 设置、按层级的 KPI、基准预期、回顾数据框架