夜雨聆风发布复盘别让 AI 直接总结：先收 6 类证据｜第 17 件事
摘要：这是“AI 帮你完成 100 件事”的第 17 篇。产品、版本、活动或内容发布后，最容易做错的不是没写复盘，而是把群聊、数据和反馈一起丢给 AI，让它写一篇看起来完整的总结。更稳的做法，是先收齐 6 类证据，强制区分事实、推断和未知，再把行动项交给人确认。
封面文案：
主标题：发布复盘别直接总结
副标题：先收 6 类证据｜第 17 件事
产品上线第二天，老板问：
昨天发布得怎么样？整理一份复盘。
你打开群聊，看到的是这样的：
运营说首小时数据“还不错”； 客服转来 12 条用户反馈； 开发提到上线时临时改过一个配置； 数据同学说看板口径还要再确认； 产品记得目标，但找不到发布前那版成功标准； 大家都说“有些地方下次可以优化”。
这时最顺手的动作，是把材料一起丢给 AI：
请根据这些内容，写一份专业的发布复盘。十几秒后，你会得到一篇结构完整的文档。
有背景、有结果、有问题、有经验，还有“加强协作”“持续优化”“提升监控”。
它看起来像复盘。
但团队下次发布，可能什么都不会改变。
原因很简单：AI 把材料写顺了，却没有替你补齐证据。目标口径不清、时间线断了、用户反馈没有样本范围、根因没人确认、行动项没有负责人，这些问题会被流畅的文字盖住。
所以这篇先给判断：
AI 写发布复盘，第一步不是总结，而是先收齐目标、结果、时间线、反馈、问题和行动 6 类证据，并把每个结论标成“事实、推断或未知”。
图 1：AI 可以整理 6 类证据，但不能替团队补造缺失证据。
这套方法适合谁
适合这些场景：
产品功能、App 版本、网站改版上线； 营销活动、直播、课程或新品发布； 公众号、视频、报告或专题内容发布； 内部系统切换、流程调整或团队工具启用； 程序员、产品经理、运营和项目负责人做阶段复盘； 小团队材料散在群聊、表格、工单和看板里，想先用 AI 整理。
不适合把 AI 当最终判断者的场景：
生产事故、安全漏洞、合规事件； 涉及客户赔偿、员工责任或法律判断； 财务数据、医疗结论或高风险决策； 指标口径尚未确认，却要求 AI 直接给成功结论； 材料含客户隐私、密钥、合同、未公开路线图或个人绩效。
AI 可以帮你把讨论变成一份可审的草稿。
最终事实、因果和责任，必须由掌握证据的人确认。
准备材料：先收 6 类证据
别一上来写正文。
先建一个文件夹，或者一张表，收这 6 类材料。
1. 原始目标与成功标准
包括：
为什么要发布； 目标用户是谁； 原计划解决什么问题； 预期指标和基线是什么； 发布范围、时间窗口和不做什么； 谁批准了成功标准。
如果发布前没有成功标准，复盘里就要直接写“发布前未定义”，不要让 AI 反推一个漂亮目标。
2. 实际结果与数据口径
每个数字至少带上：
指标名称 + 数值 + 时间范围 + 分母 + 对比基线 + 数据来源“转化率提升 20%”不够。
要写成：
发布后 24 小时，落地页访问到注册的转化率为 12.0%，发布前连续 7 天同口径均值为 10.0%，相对提升 20%。数据来源：内部分析看板，查询时间 7 月 1 日 10:00。口径没确认，就标“待确认”。
3. 时间线与关键决策
收集：
计划发布时间； 实际发布时间； 关键检查点； 临时变更； 问题首次出现时间； 谁在什么信息下做了什么决定； 恢复、下线、回滚或补救时间。
时间线不是为了找谁“搞砸了”。
它是为了看清信息何时出现、团队何时知道、系统为什么没有更早发现。
4. 用户与团队反馈
把原始反馈保留来源和样本范围：
客服工单； 用户访谈； 评论区； 销售反馈； 社群记录； 团队成员观察。
“用户普遍觉得难用”通常不合格。
更可信的写法是：
发布后 24 小时共收到 18 条相关客服工单，其中 11 条提到找不到导出入口。这是客服样本，不代表全部用户。5. 问题、失败和异常证据
包括：
错误日志与告警； 未通过的检查项； 延迟、返工和临时补丁； 错误配置； 用户流失点； 没有发生但风险很高的 near miss； 发布清单里被跳过的步骤。
这里先记录“发生了什么”，不要急着写“为什么发生”。
6. 后续行动与约束
把已讨论的动作先收进来：
要修什么； 谁负责； 什么时候完成； 完成后怎么验收； 在哪个工单或项目里跟踪； 如果不做，接受什么风险。
“加强沟通”“持续优化”“提升意识”都不算行动项。
一个行动项至少要能被关闭。
工具怎么选：先看材料敏感度
你不需要为了写复盘换一套昂贵工具。
按材料敏感度选路线即可。
路线 A：公司批准的 AI 工作区
适合内部产品、业务数据和跨部门材料。
优先使用公司已经批准的数据策略、权限和保留规则。可以把目标文档、数据摘要、会议纪要和工单导出放在同一项目里。
路线 B：本地或企业内 Agent
适合代码版本、日志、配置和仓库变更较多的发布。
它可以读取 commit、issue、CI 和测试记录，先生成时间线和变更摘要。能访问不等于有权外发，仍然要按公司制度处理。
路线 C：通用聊天工具 + 脱敏材料
适合个人项目、公开内容或已经去标识化的业务摘要。
只提供复盘必要信息。客户姓名、订单、联系方式、token、内部漏洞、合同和未公开计划不要上传。
路线 D：只让 AI 生成空模板
材料不能上传时，让 AI 根据你的场景生成表格、提问清单和验收标准，再由团队在内部填写。
这是最保守，也很实用的路线。
费用和文件上传能力会随产品、账号和组织策略变化。正式使用前，看当前账号页面和公司规定，不要把某个工具今天的入口当成长期承诺。
第 0 步：先定复盘范围
先回答 4 个问题：
1. 复盘对象：哪次发布、哪个版本、哪个活动？2. 时间窗口：从什么时候到什么时候？3. 复盘目的：验证结果、找流程问题，还是处理事故？4. 参与确认的人：谁负责确认数据、技术、用户反馈和行动？如果范围不清，AI 会把不同版本、不同活动和不同时间的数据混在一起。
你可以先发这段：
你是发布复盘助手。复盘对象：[产品 / 版本 / 活动 / 内容名称]时间窗口：[开始时间] 到 [结束时间]复盘目的：[验证目标 / 找流程问题 / 形成后续行动]确认角色：[产品、技术、运营、数据、客服等]请先复述复盘范围，并列出可能混入但不属于本次复盘的材料。不要开始写结论。第 1 步：让 AI 只做材料盘点
把 6 类材料交给 AI 后，先让它查缺口。
请把我提供的材料整理成 6 类证据表：1. 原始目标与成功标准；2. 实际结果与数据口径；3. 时间线与关键决策；4. 用户与团队反馈；5. 问题、失败和异常证据；6. 后续行动与约束。每一条都输出：- 内容摘要；- 原始来源；- 时间；- 是否可核验；- 缺失信息；- 标签：事实 / 推断 / 未知。这一轮不要写复盘正文，不要补全我没有提供的信息。验收这一步，只看两件事：
AI 有没有指出缺什么； 它有没有把推断写成事实。
如果它已经开始“综合来看，本次发布总体成功”，先停下来。
证据表还没齐，不需要总体评价。
第 2 步：对齐计划与实际
发布复盘最有价值的部分，不是重述做了什么。
是把计划和实际并排。
提示词：
请基于已确认材料，生成“计划 vs 实际”对照表。列：1. 目标或检查项；2. 原计划；3. 实际结果；4. 偏差；5. 偏差证据；6. 当前解释；7. 仍待确认的问题。规则：- 数字必须保留时间范围、分母、基线和来源；- 没有原计划就写“发布前未定义”；- 没有实际数据就写“未采集”；- 当前解释如果没有直接证据，标为“推断”；- 不要把相关性写成因果。这张表会暴露很多真问题：
目标写了，但没有数据； 数据有了，但口径和发布前不同； 结果没达标，但团队不知道偏差从哪一天开始； 发布成功了，但靠临时补丁和加班撑住； 指标达标了，但用户反馈集中在关键体验问题上。
第 3 步：排时间线，找“系统在哪里失去控制”
把群聊、工单、监控和版本记录按时间排序。
图 2：先定范围和查缺口，再分析偏差。顺序反了，AI 很容易把猜测写成结论。
可以复制：
请把材料整理成时间线。每个节点包含：- 时间；- 发生的事实；- 当时团队已知的信息；- 当时采取的动作；- 动作依据；- 结果；- 证据来源；- 仍未知的点。然后只回答 4 个问题：1. 哪个最早信号没有被看到？2. 哪个检查本来应该发现问题？3. 哪个决定是在信息不足时做出的？4. 哪个补救动作最有效？不要评价个人，不要把“谁做了什么”直接等同于根因。这里的工程判断是：
一次发布问题很少只由一个人造成。
更常见的是目标没写清、门禁缺失、监控太晚、权限不明、信息没有进入决策流程。
好的复盘要让系统变得更难犯同类错误。
第 4 步：强制区分事实、推断和未知
这是整套方法里最重要的一步。
要求 AI 给每个重要结论加标签：
[事实] 有直接数据、记录、截图、日志或确认人；[推断] 根据多个事实提出的解释，仍需验证；[未知] 当前材料无法回答，必须补证据或保留为空。例如：
[事实] 10:12 监控出现错误率上升，来源为告警记录。[事实] 10:20 团队回滚配置，10:28 错误率恢复。[推断] 新配置可能是错误率上升的主要原因。[未知] 为什么发布前检查没有覆盖该配置组合。这比写“本次问题根因是配置错误”更可信。
前者允许团队继续验证。
后者可能只是 AI 把时间上的先后关系写成了因果。
第 5 步：把反馈聚类，但保留样本边界
AI 很适合处理大量反馈。
但聚类之后，要保留原始数量和来源。
请把用户和团队反馈聚类。每一类输出：1. 主题；2. 反馈数量；3. 典型原句的简短摘要；4. 来源渠道；5. 涉及的用户或角色；6. 是体验问题、功能缺陷、认知偏差还是个别偏好；7. 还需要什么数据验证。不要使用“用户普遍认为”“大家都觉得”等没有样本依据的表达。同一条反馈只能计入一次，保留原始编号方便回查。AI 的分类结果要由一位了解业务的人抽样复核。
尤其注意：
抱怨最多的不一定影响最大； 没有人反馈，不代表没有问题； 内部团队的“操作麻烦”和客户的“无法完成任务”不是同一优先级； 评论区高频词不等于全体用户结论。
第 6 步：只保留 3 个可追踪行动
复盘最后最容易变成愿望清单。
十几个行动项，通常一个都落不下去。
先让 AI 草拟，再由团队选 2—3 个最关键动作。
根据已确认事实和偏差，提出最多 5 个候选行动。每个行动必须包含：- 要改变的系统、流程或检查；- 对应哪条证据；- 负责人角色；- 完成期限；- 验收标准；- 跟踪入口；- 不做的风险；- 优先级。删除“加强沟通、持续优化、提高意识、密切关注”这类不可验收表达。不要指定具体个人，由团队确认负责人。最终行动可以这样写：
行动：在发布门禁中增加配置组合检查。证据：本次问题只在 A+B 配置同时启用时出现。负责人：发布工程负责人。期限：7 月 8 日。验收：测试环境可自动阻止该冲突组合，CI 有对应测试记录。跟踪：项目工单 REL-128。这才是复盘和普通工作总结的分界线。
总结解释过去。
复盘要改变下一次发布。
完整提示词：从证据到复盘草稿
前面每一步通过后，再让 AI 写正文。
你是发布复盘助手，不是事实和责任的最终判断者。请仅基于我提供并确认的材料，生成发布复盘草稿。结构：1. 发布范围与目标；2. 结果概览；3. 计划 vs 实际；4. 关键时间线；5. 做得好的地方；6. 主要偏差与影响；7. 原因分析；8. 用户与团队反馈；9. 后续行动；10. 待确认问题。写作规则：- 每个重要结论标注“事实 / 推断 / 未知”；- 数据保留时间范围、分母、基线和来源；- 不伪造缺失信息；- 不把相关性写成因果；- 不评价或归责个人；- 行动必须有负责人角色、期限、验收标准和跟踪入口；- 没有证据支撑的句子放入“待确认问题”；- 语言具体，不写“持续赋能、全面提升、形成闭环”等空话。最后再输出一份“人工终审清单”，列出必须由产品、技术、数据、运营或负责人确认的点。8 个常见失败
1. AI 一上来就写“总体成功”
处理：退回证据表。目标、基线和结果没有对齐前，不做总体评价。
2. 数据看起来完整，口径却不一样
处理：每个指标补时间范围、分母、基线和来源。同名不同口径，分开写。
3. 时间线只有结果，没有当时已知信息
处理：每个节点补“当时知道什么”和“依据什么做决定”，否则无法改进决策流程。
4. AI 把最后一次变更写成根因
处理：标记为推断，要求补复现、日志、实验或负责人确认。
5. 用户反馈被写成普遍结论
处理：保留反馈数量、来源渠道和样本限制。
6. 行动项都是口号
处理：没有负责人、期限、验收和跟踪入口的动作全部退回。
7. 复盘变成追责会
处理：讨论系统、流程和信息条件。涉及个人责任时，由管理流程单独处理，不交给 AI 下结论。
8. 为了上下文完整，上传了敏感材料
处理：先脱敏。无法脱敏时，只让 AI 生成模板和问题清单，在内部环境填写。
发布复盘验收：这 8 个问题都要有人回答
图 3：一篇可执行的复盘，最后要落到事实、口径、因果、行动、跟踪和隐私。
发布复盘前，逐项检查：
1. 复盘对象和时间窗口是否唯一、清楚？2. 原始目标和成功标准是否可回查？3. 每个关键数字是否有口径、基线、时间和来源？4. 时间线是否区分“当时已知”和“事后知道”？5. 原因结论是否有证据，还是仍属于推断？6. 用户反馈是否保留样本数量、来源和限制？7. 每个行动是否有负责人、期限、验收和跟踪入口？8. 客户、员工、合同、漏洞和路线图信息是否已脱敏？有一项答不上来，就在复盘里保留“未知”或“待确认”。
一份承认未知的复盘，比一份因果完整但证据不足的复盘更有用。
Takeaway
记住这 6 句：
1. 不让 AI 直接总结，先定复盘范围。2. 先收目标、结果、时间线、反馈、问题、行动 6 类证据。3. 每个结论都标事实、推断或未知。4. 数据必须带口径、基线、时间和来源。5. 根因由证据和负责人确认，不让 AI 自己编。6. 行动必须有负责人、期限、验收和跟踪入口。如果这篇内容对你有帮助，欢迎关注 Glasswing AI。下一篇继续拆解具体工作流。
参考来源
Google SRE：《Postmortem Culture: Learning from Failure》 Atlassian：《Postmortem Templates》《Postmortem Reports》 AWS：《Performing a post-incident analysis》 GitLab Handbook：《Group Retrospectives》及官方复盘提示词
完整链接、功能边界、费用门槛和隐私核验记录见文章包内《参考来源与核验》。
DBS 诊断记录
/dbs-content 第 1 轮
文字洁癖：发现“AI 总结很快”容易落入泛效率叙事，已改为“证据链缺口”这个具体冲突。 封面/标题：通过。标题前 16 字出现发布复盘、AI 冲突和行动，“6 类证据”在正文完整兑现。 表达效率：通过。结构按材料、工具、步骤、提示词、失败处理、验收推进。 认知落差：通过。把“写得完整”与“证据可信”分开，强调复盘要改变下一次发布。 AI 辅助工作流：通过。包含可复制提示词、工具筛选、失败处理、验收标准和隐私边界。
/dbs-ai-check 第 1 轮
命中 2 处弱信号：部分段落使用对称句和“不是 X，是 Y”结构；已压缩为具体动作和证据例子。 强 AI 指纹：0 处。 修改动作：补入第二天翻群聊、数据口径、工单编号和 unknown 标签，删除空泛升维句。
标题公式记录
最终标题：发布复盘别让 AI 直接总结：先收 6 类证据｜第 17 件事
公式编号：#61 为什么你应该停止 [行动] 组合公式：账号母公式“对象/场景 + AI 变化/冲突 + 数字/行动/判断” 触发器：行动号召 + 数字锚定 兑现方式：正文提供 6 类证据、6 步工作流、完整提示词、8 个失败处理和 8 项验收标准。
