发布不是按下按钮的那一刻，而是从预热到第一周复盘的一整段动作；按钮只是其中一秒。
一、发布日不是一天，是一段
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
一位开发者把发布当成一天的事。那天他起了个大早，把链接发到 6 个平台：两个社群、一个目录站、一个论坛、两个内容平台。下午看到几十个访问，觉得成了。第二天醒来，6 条帖子全部沉底，访问回到个位数，注册 2 个，付费 0。
他的动作没有错，错在把「发布」理解成「通知」。一次通知的效果可能很短，发布应预留承接和回访时间：有人看到、有人点开、有人注册、有人卡住、有人回来。这些动作可能跨日，也可能在同日发生，应按事件时间记录。
按01篇日历，第68天完成预热与冻结，第69–70天休息，预设内容可自动展示；第71天发布，第72–78天观察首周，第79–80天整理。预热计入61–70阶段，不再算一次发布阶段工时。第 07 篇保证了链路能通，这一篇保证有人真的走上来。
二、发布前 3 天：预热、名单、素材、冻结
| 时间 | 动作 | 完成判据 |
|---|---|---|
| 第68天（D−3） | 列出 30 个「可以直接发消息」的人 | 每个人能写出一句为什么找他，不是群发 |
| 第68天（D−3） | 写三个版本的一句话介绍：给用户、给同行、给社区 | 每版不超过 40 字，无术语 |
| 第68天提前完成；第69天不排工作 | 准备素材：首屏截图、30 秒演示、定价说明 | 不登录也能看懂产品长什么样 |
| 第68天提前完成；第69天不排工作 | 冻结环境：不再合并功能分支 | 只允许修阻断性缺陷 |
| 第68天提前完成；第70天不排工作 | 自己走一遍 12 个冒烟检查点 | 全部通过，截图存档 |
| 第68天提前完成；第70天不排工作 | 写好发布日的动作清单与时间点 | 按可用工作时段，含回复模板 |
| 第68天提前完成；第70天不排工作 | 设好监控与错误告警的接收端 | 测试一条告警能到自己手机 |
「冻结」是最容易被跳过的一步。未经回归的小改动可能引入第一周故障：它没有经过冒烟测试，而你又没有时间再测一遍。
三、发布日：按小时排，不按心情排
| 时间 | 动作 | 目的 |
|---|---|---|
| 07:00 | 打开监控、错误上报、支付后台 | 确认基础链路正常 |
| 08:00 | 发布公告与更新日志 | 给已有关系一个可转发的落点 |
| 09:00 | 一对一通知名单前 10 人 | 这批人最可能给真实反馈 |
| 10:00 | 发 2 个垂直社区，不发第 3 个 | 留一个位置给第二天 |
| 12:00 | 集中回复上午收到的评论与私信 | 及时回应问题；不预设通用算法加权 |
| 14:00 | 看注册与支付是否正常，处理阻断 | 有阻断就停下正在进行的推广 |
| 18:00 | 发 1 个内容平台的长文或案例 | 承接白天没转化的人 |
| 21:00 | 记录当天五个数，写 5 行复盘 | 为第二天提供依据 |
下面是本例限制触达频次的理由，间隔须服从社区规则、用户接受度和自己的承接能力，不是统一三小时规则：同一批受众会在多个渠道看到重复内容，容易判定为刷屏；第一波反馈还没回来，第二次发布无法针对性修改；你需要先确认注册与支付链路在真实流量下没有断，否则第二次发布只是把更多人送进同一个断点。
四、发布后 7 天：每天一个主题
| 天 | 主题 | 具体动作 | 不做什么 |
|---|---|---|---|
| D1 | 回复 | 逐条回完当天收到的评论与私信 | 不改功能 |
| D2 | 修复 | 只修阻断注册与付费的问题 | 不修「体验优化」 |
| D3 | 观察 | 看五个数与漏斗，找最大流失环 | 不看单条差评做决策 |
| D4 | 内容 | 写一篇「怎么用」或「为什么这样设计」 | 不写促销 |
| D5 | 邀请 | 邀请 5 个合适的人做 20 分钟访谈 | 不问「你觉得怎么样」 |
| D6 | 复盘 | 对比目标与实际，写下一周的三个动作 | 不调整定价 |
| D7 | 计划 | 排下一周的渠道与内容 | 不重启已放弃的渠道 |
每天主题仅是排程提醒，不阻止安全/资金/数据问题立即处置。D5、D6若落休息日，内容可提前安排，实时任务挪到下一工作日并计工时；有紧急事件须另记加班并调整总预算。
五、渠道组合表
按「关系的远近」排序，不按流量大小排序。
| 渠道 | 一天内的最小动作 | 预期量级（教学假设） | 不要做的事 |
|---|---|---|---|
| 已有关系 | 一对一发 10 条，附一句为什么找他 | 5–20次访问，转化待测 | 群发同一段话 |
| 垂直社区 | 写一个「我做了个东西解决 X」的帖子，含过程 | 20–80 次访问 | 只放链接不讲背景 |
| 目录站 | 提交 2–3 个产品目录，写清一句话与截图 | 10–40 次访问，长尾 | 一次提交十几个 |
| 内容平台 | 发一篇有具体步骤的实践文 | 30–150 次访问 | 标题夸张、正文空洞 |
| 付费渠道 | 小额测试，设日预算上限 | 50–200 次访问，成本可控性差 | 在没有转化数据前加预算 |
前四行是「用时间换注意力」，最后一行是「用钱换注意力」。付费渠道可作限额实验，但应先验证交易链路，设现金上限、归因窗口与停止条件；没有可靠分母时不扩大预算。
六、事故先防止损害扩大
| 事件 | 立即动作 | 后续与沟通 |
|---|---|---|
| 越权/泄露 | 隔离受影响访问、撤销泄露凭据，保留必要证据 | 查范围、补救并评估适用通报；不等完全恢复 |
| 数据丢失/结果错误 | 暂停危险写入/处理，保护原始材料和恢复点 | 对账与恢复核验，向受影响用户说明结果可信范围 |
| 重复扣费/权益错误 | 暂停相关收费/发权益，按订单核对 | 纠正、退款及受影响通知分别跟踪 |
| 支付不可用 | 关闭购买入口，保留安全浏览与提示 | 查配置和状态；复现遵守通道测试规则 |
| 注册/邮件失败 | 明示故障，保留安全支持入口 | 排查鉴权、邮件与DNS，避免无条件切域破坏信誉 |
| 流量过载 | 限流或安全降级，先保护数据和在途交易 | 恢复后逐步放量，不盲目承诺恢复时间 |
| 负面评论/数据误报 | 核实具体事实，及时回应 | 更正与记录；涉及隐私、恶意内容按平台规则处理 |
是否继续收款取决于能否安全履约。 只保住购买入口而持续丢数据，不是恢复成功。公告及时说明已知事实、影响、用户可做动作及下次更新时间；未知就写未知。个人信息事件按适用规则评估部门与个人通知，不等待技术恢复，也不承诺总能先于用户发现。
七、第一周看板：固定队列与人数
本例选“第71–77天首次注册队列”，每人从注册后观察7天，因此完整转化结果最早第84天汇总；第78天只能先报暂态与尚未成熟人数。每日运营收款另外记，不混进队列。
| 指标 | 定义 | 注意事项 |
|---|---|---|
| 访问规模 | 同一窗口设备级去重访问估计 | 全周重新去重，不把每日UV相加当周UV；跨设备可能同人 |
| 注册 | 队列新增注册人数 | 访问到注册须可匹配身份和同窗来源，否则仅报两个绝对数 |
| 激活 | 队列内7天内完成核心任务人数÷该队列注册人数 | 固定事件，排除自己与测试账号 |
| 付费 | 已激活者在规定窗口内完成首次付款人数÷激活人数 | 同一人买2单仍只算1人；先付后用另报分支 |
| 质量 | 报错会话/总会话；退款订单/同批已付订单 | 单独订单指标，写观察截止日与退款延迟 |
渠道按预先固定的首次可识别触达归因；无法匹配的记未知。为保护隐私不必建立跨站身份画像，数据不足时缩小结论范围，不以“精确转化”强行追踪。
教学算例额外假设300名同窗访问者可准确关联，产生60注册、24激活、3首次付费：60/300=20%、24/60=40%、3/24=12.5%、3/300=1%。这是同一批人的模型，实际只能识别设备时要改标签，不能直接冒称300人。
八、把反馈先登记为待验证解释
| 观察 | 可能解释 | 下一步证据 |
|---|---|---|
| 访问少 | 触达少、渠道不合适、统计漏记、自然周期长 | 核统计、实际发布与访问来源 |
| 注册/激活低 | 信息不清、鉴权失败、价值不匹配、设备/隐私顾虑 | 按版本与设备观察任务，访谈未完成者 |
| 激活后未付 | 价格、预算、购买时机、免费已够用、支付失败 | 查付款状态、决策周期和明确报价后的反应 |
不因一个低比例就宣称渠道、文案或产品是唯一原因。第一周可保留核心版本便于比较，但紧急问题立即处理；不因“先不降价”排除价格确为障碍的证据，也不因尚未凑够5条反馈而推迟止损。
九、用成本选择增长实验
若全部比例保持不变，600×20%×40%×12.5%=6名首次付费，是模型期望。300×30%×40%×12.5%=4.5名也是期望，不向下取整成承诺的4单；实际人数是整数，未知。
| 实验 | 模型期望新增付费 | 需要补的成本输入 |
|---|---|---|
| 访问300增至600，比例不变 | 6−3=3 | 新增广告现金、内容和支持工时 |
| 同样300访问，注册20%增至30%，其他不变 | 4.5−3=1.5 | 文案/交互开发、测试、机会成本 |
仅作比较例：若前者增量成本600元，期望每新增付费200元；后者增量成本600元，期望每新增付费400元。若成本或比例改变，排序会变，不能说提升某环节必然更省力。设预算、同口径观察窗与停止条件，检查是否只是渠道或版本混杂。
十、常见错误表
| 错误 | 后果 | 更好的做法 |
|---|---|---|
| 同一天发 6 个平台 | 第二天全部沉底，无后续动作 | 分三天发，每天留回复时间 |
| 发布前一天合并功能 | 未经测试的故障进入生产 | 提前冻结，只修阻断 |
| 只看总访问，不拆渠道 | 不知道人从哪来、为什么不留 | 每个渠道单独记注册率 |
| 用一条差评改产品 | 被极端样本带偏 | 先判断损害，轻微偏好再累计证据 |
| 发布当天投付费渠道 | 买到更贵的失败 | 先验交易链路，再限额验证渠道 |
| 出故障先解释后修复 | 用户流失扩大 | 止损、通知评估与恢复并行，再复盘 |
十一、行动清单
- 列出 30 个可以直接发消息的人，写下找每个人的理由。
- 写三个版本的一句话介绍，各不超过 40 字。
- 第68天完成冻结、预设休息日内容，只允许修阻断。
- 把发布日动作排到小时，写好自己的回复模板。
- 测试一条错误告警能到达自己的手机。
- 主题按工作日调整，损害事件不等主题日。
- 每天记录五个数，标明分母与渠道。
- 首周末列出待验证原因与未成熟队列，不强行判因果。
使用边界与实操验收
上述触达量、比例、预算与观察窗都是教学输入，不是行业基准。发布工时从01日历的32/64小时阶段预算扣除，预热从上一阶段扣；休息日的必要事故响应须记实际投入并调整计划。
验收：同一人两单不使人数转化超过100%；同设备连续7天不记7个周设备；队列未走满7天标暂态；4.5保持为期望值。增长原因先列多种解释，再安排一个限额实验，不用样本的暂态变化编收入预测。
关键参考与核验范围
以下链接支持对应的规则；渠道量级、漏斗比例与看板口径均为方法演示，不构成增长或投资建议。核验日期：2026-10-23。
- 中华人民共和国个人信息保护法 ：按第4、6、13、17条核必要统计、处理基础和期限；第57条用于评估个人信息事件补救及通知。
- 电子商务法 ：发布公告、促销表述与付费渠道投放涉及经营者信息披露义务，对外文案应先核对适用范围。
系列导航
- 上一篇：第 61–70 天：上线前的十五件事
- 下一篇：第 81–90 天：反馈分诊与第一次收费
- 回到目录：一个人的前 100 天：从想法到第一批付费用户
- 相关阅读：独立开发者的平台寄生
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。