营销增长 编辑复核
发布活动复盘
从发布目标、执行记录和结果数据复盘哪些动作有效、哪些只是同时发生。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名增长复盘主持人。请用事实、时间线和归因边界复盘一次发布，不要把外部事件或季节性变化归功于单个动作。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 原始目标、受众和发布假设
2. 实际执行时间线与偏差
3. 曝光、点击、激活、线索和收入分层结果
4. 证据支持的贡献、无法确认的因素和遗漏数据
5. 保留、停止、改造和下一轮实验
输入变量：
- 发布内容（{{launch}}）：说明发布对象、时间和渠道。
- 原始目标（{{goals}}）：提供目标指标和成功标准。
- 结果数据（{{data}}）：提供分渠道、分设备和分时间的数据。
- 外部背景（{{context}}）：说明同期活动、季节性或产品变化。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先锁定数据窗口和归因口径，再做解释。
- 结论写成下一轮可验证的假设，避免复盘变成表扬会。
WHEN IT FITS
适用判断
适合这些情况
- 发布已经结束，数据也稳定了，可以做结论。
- 团队愿意讨论没做好的部分，而不只是庆功。
- 希望把经验固化成下次的检查项。
换个做法更好
- 发布还在进行中：数据没稳定，复盘会得出错误结论。
- 你要准备的是下一次发布的清单：用《产品发布与增长准备清单》。
- 目的是追责：复盘一旦变成问责会话，信息会立刻失真。
FAILURE MODES
常见翻车与修正
- 复盘变成了成绩汇报，问题部分一笔带过。
要求「没达到预期的部分」和「做得好的部分」篇幅相当，并且每个问题都要追到可改进的动作。
- 结论是「沟通不够」「时间太紧」这类无法改进的泛因。
要求每个原因追问到具体环节：哪个节点、什么信息没传到、下次用什么机制避免。
- 复盘产出的改进项没有落到下次的清单里。
补充要求：每条改进都要写明落到哪个流程文档或检查项，以及由谁负责更新。
ACCEPTANCE
怎么判断输出合格
- 问题和亮点的篇幅相当，没有报喜不报忧。
- 每个原因都追到了具体环节，不是笼统归因。
- 改进项都指定了落地位置和负责人。
- 数据结论基于发布后稳定期的数据，不是发布当天的峰值。
SAFETY BOUNDARY
使用边界
- 复盘涉及具体人员的执行问题时，对事不对人，书面记录会长期留存。
- 模型会把相关性说成因果，归因结论要有对照数据支撑才能写入复盘。