正式发布计划

部署成功只是技术上线。正式发布是你有计划地邀请一批合适的人完成一个动作，并在短时间内观察、支持、记录结果。

第一轮发布不追求声量，追求高密度反馈。

快速版

1. 先写一句发布假设：发给谁、希望他做什么、用什么证据判断。
2. 首发名单不超过 20 人，优先访谈过的人。
3. 发布包只要五样：定位、链接、一个具体任务、反馈入口、已知边界。
4. 发布物料提前准备，不要上线那天临时想文案。
5. 不同渠道换不同表达，不要把同一段硬广复制到所有地方。
6. 集中观察 24–72 小时，先修阻断主路径的问题。
7. 止损方案提前写好，包括怎么暂停支付入口。

先写发布假设

发布前写一句话：

我把产品发给____这类人，希望他们完成____这个动作，以____作为值得继续的证据。

举个例子："邀请正在手工整理访谈记录的独立开发者上传一份真实材料，观察是否愿意保存结果并再来一次。"

没有这句话，浏览量涨了你仍然不知道产品是否成立。 一千个人看过首页却没人完成核心动作，这个信息比"有一千次访问"重要得多。

选一小批发布对象

第一轮优先找：

• 你访谈过、并且确认有这个问题的人
• 正在用某种替代方案（哪怕是手工）解决的人
• 能提供真实材料、给具体反馈的人
• 出问题时愿意继续和你沟通的人

不要先把链接扔进十个大群。 大量不匹配的访问会带来客服噪音，却不能验证核心假设——他们不完成动作，你分不清是产品不行还是人不对。

发布包只需要五样

1. 一句说明：给谁、解决什么问题
2. 一个能直接打开的链接
3. 一个建议完成的具体任务（不是"随便看看"）
4. 一个反馈入口
5. 已知边界和数据使用说明

长篇创业故事可以以后写。第一批用户需要知道的是自己为什么值得花十分钟。

第 3 项最关键。"你看看有什么建议"会得到"挺好的"；"你把上周那份访谈记录传进来试试"会得到真实的卡点。

发布物料提前准备

不要等网站做好了才临时想文案。提前准备这些，都可以反复改写：

截图那条要强调：只放首页的截图无法让人判断产品有没有用。放核心流程的中间步骤和结果页。

不同渠道换不同表达

同一段文案发到所有地方，效果通常都不好。

私聊邀请通常转化最高，也最费时间。第一轮就该费这个时间。

设发布观察窗口

发布后 24–72 小时集中观察：

• 链接是否正常打开，来源是否可识别
• 有多少目标用户开始并完成了核心动作
• 第一个停顿和失败发生在哪里
• 哪些问题需要人工支持
• 是否有人愿意继续使用、留联系方式、付费

准备止损方案

正式发布前明确这五件事：

1. 支付或权益异常时，怎么暂停购买入口：____________
2. 结果质量不稳定时，怎么降级或改人工确认：____________
3. 数据泄露或错误发送时，联系谁、怎么通知用户：____________
4. 服务器压力超出能力时，先限制哪些功能：____________
5. 怎么回滚到上一个可用版本，需要多久：____________

这不是悲观。是在你最忙的时候减少临场决定。 具体做法见发布与回滚。

上线那天不会有人来

这句话要提前接受。

第一轮发布的目标不是"爆"，是拿到真实反馈、第一批用户、可复用的发布经验。上线只是让你具备了被使用的资格。

如果发布后完全没有反应，先检查三件事：发给的人对不对、有没有给出具体任务、他们打开链接后第一屏说清楚了没有。多数情况问题在这三个里，不在"曝光不够"。

常见卡点

验收标准

• 发布假设写成了一句话，包含对象、动作、判断证据
• 首发名单不超过 20 人，且都是有相关性的人
• 发布包五样齐全，任务是具体的
• 物料准备好了，截图包含核心流程不只有首页
• 按渠道准备了不同表达，不是一段通用文案
• 观察窗口定了具体时长，期间不做非必要发布
• 止损五项都填了具体做法
• 发布结束后能回答：谁完成了、谁卡住了、谁愿意再来

本章动作

定一批不超过 20 人的首发名单，给他们同一个核心任务，设三天观察窗口。

结束后只回答三个问题：谁完成了、谁卡在哪、谁愿意再来或付费。

回答不出来，说明这次发布没有设计成一次实验。

下一步

1. 发布与回滚——止损方案的技术准备
2. 先找到前十个用户——首发之后怎么继续
3. 主动出击：直接联系——私聊邀请怎么写
4. 基础数据分析——观察窗口里看什么数据