软发布

在完整公开发布前向有限受众（beta 用户、等候名单、单一市场）发布 — 在无公众聚光灯下验证产品承受真实负载。

为什么

软发布把"产品对用户就绪"与"产品对所有人就绪"解耦。你向 100 个 beta 用户或单一地区市场发布，获得真实使用数据、真实 bug 报告、真实基础设施负载 — 但无 Product Hunt 发布或新闻稿的审视。这让你在低风险时修只在真实使用（非 staging）下出现的 top 10 问题：影响 100 beta 用户的 bug 是私下道歉，同样 bug 影响 10,000 Product Hunt 访客是公开危机。软发布还在流量峰值前验证基础设施扩容假设，让你为硬发布正确配服务器而非猜。跳过软发布的产品往往在最高流量日出最高调的 bug。

何时使用

产品功能完成且内部 dogfood 之后、任何公开公告之前。典型软发布窗口：硬发布前 1-4 周，50-500 beta 用户或单一低风险市场。

如何做

1. 定义软发布受众：等候名单中 100-500 beta 用户，或单一低风险市场（如本国、友好社区）
2. 设 beta 访问门：feature flag、邀请制注册、或独立 beta URL — 产品是真的但访问受限
3. 埋点一切：分析、错误监控、反馈组件 — 软发布的目的是数据，每次交互必须捕获
4. 向 beta 受众发布并附个人信（"你们是我们的首批真实用户，请尽情破坏并告诉我们"）；设 1 周反馈窗口
5. 每日监控：错误率、核心动作完成、NPS/反馈、基础设施负载；修影响 > 5% beta 会话的任何 bug
6. 软发布窗口结束：汇总 top 10 问题、top 5 功能请求、基础设施扩容数据
7. 修 top 10 问题、按软发布峰值负载 10 倍配基础设施、然后排硬发布
8. 用福利（终身折扣、公开致谢）感谢 beta 用户并转为硬发布队列

示例

# 软发布 — ez4code v2.0 beta
窗口：2026-09-20 至 2026-09-27（1 周）
受众：247 等候名单注册（邀请制）

## 访问门
Feature flag：beta_access=true 对 247 个用户 ID
注册：关闭（仅邀请链接）

## 每日监控
第 1 天：89 活跃，2 bug（OG 图、暗色对比度）
第 3 天：162 活跃，NPS 42，1 bug（Stripe webhook 超时）
第 7 天：203 活跃，NPS 48，0 新 bug

## 发现的 top 10 问题
1. Twitter 上 OG 图 404  → 第 1 天修
2. /launch 暗色对比度  → 第 2 天修
3. Stripe webhook 5 秒超时  → 第 4 天修（增至 30 秒）
...

## 基础设施数据
峰值并发：47 用户 → 0.4 CPU
=> 为硬发布配：500 并发 → 4 CPU，2 副本

## 结果
修 10 问题，配好基础设施，NPS 48
=> 2026-10-05 硬发布就绪

常见问题

⚠无埋点软发布 — 向 beta 用户发布但忘接分析或反馈，啥也学不到；软发布的全部目的是数据，邀请前先埋点。
⚠把软发布当营销事件 — 软发布期邀媒体或上 Product Hunt 违背目的；软发布是私密的，硬发布是公开的，绝不混。
⚠硬发布前不修 top 问题 — 软发布找到 10 bug 但团队去做新功能，硬发布把同样 bug 发给 100 倍受众；修复清单是硬发布门禁。
⚠按软发布峰值配基础设施 — 47 并发 beta 用户不是 5000 Product Hunt 访客；为硬发布乘 10-100 倍否则服务器首日熔化。

最佳实践

✓招像目标用户的 beta 用户而非朋友 — 朋友太宽容不报真实目标用户会报的摩擦；用按画像过滤的等候名单。
✓设固定软发布窗口（1-2 周）加明确退出条件（top 10 问题修、NPS > 30、基础设施配好）；无窗口软发布漂移而硬发布永不开。
✓加私密 beta 反馈频道（Slack/Discord 邀请）并 4 小时内回每条报告 — beta 用户在帮你，沉默杀死他们报下一个 bug 的意愿。
✓用软发布专门验证新手引导流 — top 10 问题几乎总含内部 dogfood 漏掉的新手摩擦，因为团队已熟悉产品。