用 AI 做产品复盘

用 AI 做产品复盘，适合把发布记录、用户反馈、指标说明、项目决策和故障信息整理成时间线与问题清单。AI 可以帮助比较“原计划”和“实际发生”，但不能凭有限材料认定根因、归责个人或生成不存在的效果数字。

页面摘要

项目	说明
阅读时间	约 8 分钟
适合人群	产品、设计、研发、数据、运营、项目负责人和创业团队
核心产出	目标回顾、事实时间线、结果证据、原因假设、反例、行动项与复查条件
使用前提	有版本明确的计划、发布记录、数据口径和相关角色输入
不适合	用 AI 追责、伪造改进效果，或把事后叙述包装成已验证因果

适用边界

复盘的目标是改善系统和决策，不是证明当初选择正确。指标变化可能同时受到渠道、季节、数据口径和其他发布影响；用户反馈也有样本限制。事实、解释和行动建议必须分开。

信息类型	示例	写作要求
事实	某版本在确认日期进入某环境	有来源和时间
结果	某指标按指定口径发生变化	说明范围，不自动归因
原因假设	流程步骤可能造成阻碍	写支持与反对证据
决策	团队决定继续、调整或停止	记录责任人与依据

七步复盘流程

1. 定义复盘问题：限定项目、周期、受众和要改进的决策或流程。
2. 恢复原始目标：使用当时版本的目标、范围和假设，不用事后结果重写成功标准。
3. 建立事实时间线：汇总研究、决策、开发、发布、异常和支持记录，保留来源编号。
4. 核对结果口径：由数据与业务责任人确认时间窗、分群和数据质量；无数据时明确缺口。
5. 生成多种解释：让 AI 分列支持证据、反例、替代解释和仍需验证的信息。
6. 设计可执行行动：每项对应具体流程缺口，写负责人、检查时点和完成证据。
7. 安排回看：在下一轮计划或发布后检查行动是否执行，而不是只保存复盘文档。

假设示例：状态提示改版复盘

以下材料为教学假设，不包含真实项目结果或用户数据。

示例输入

目标：让用户在导出等待期间理解任务状态。
原假设：明确展示排队、处理、成功和失败，可减少状态不确定。
事实：版本 R1 已按发布记录上线网页端；帮助中心同步了失败处理步骤。
可用证据：三条上线后工单摘录；事件口径尚未通过数据负责人确认。
要求：不生成趋势、比例或因果结论。

示例输出

部分	复盘草案
已确认事实	R1 在网页端上线；帮助材料已同步，来源需附发布记录与文档版本
当前线索	三条工单可用于理解具体困惑，不能代表总体变化
未知	状态查看、重试和完成行为的数据口径未确认
原因假设	文案、刷新机制、错误分类或任务本身耗时都可能影响体验
反例检查	寻找理解状态但仍无法完成任务的记录，以及没有看到提示的路径
下一步	确认事件口径；按错误类型回看工单；检查移动端是否在范围外

行动项草案

行动：由数据负责人确认导出事件定义与可用时间范围。
完成证据：口径卡经过产品和数据共同确认，不以“已埋点”代替。
行动：由支持负责人对工单做来源编码并保留原始语境。
完成证据：每个主题能回到工单编号，且报告包含反例与样本边界。

决策与复核表

检查项	复核问题	合格信号
目标	使用的是当时目标还是事后改写？	可回到原始计划版本
事实	时间线每项是否有来源？	观察与解释分开
结果	口径和范围由谁确认？	不用零散反馈冒充总体数据
原因	是否列替代解释和反例？	不把同时发生写成因果
行动	能否改变具体流程？	有负责人、检查点和完成证据

常见错误

• 只复述做了什么，没有回看目标和未实现部分。
• 用上线后的任何正向变化证明方案有效。
• 让 AI 生成“根因”并归责个人，没有证据链。
• 行动项写成“加强沟通”“提高重视”，无法验证是否完成。
• 复盘结束后无人跟进，下一项目重复同类问题。

复盘证据结构稳定后再辅助整理

当来源编码、指标口径和人工决策机制已经明确，需要汇总项目材料与行动项时，可以查看 OfApp.cn 当前公开能力。具体支持范围请以官方文档为准。

查看 OfApp.cn 官方文档

常见问题

复盘一定要等数据完整吗？

不必，但要区分当前事实与待补证据。可以先复盘决策过程和执行质量，再安排数据回看。

AI 能做根因分析吗？

可以生成候选解释和追问，不能独立确认根因。根因需要系统证据、相关角色核对和必要验证。

复盘应该公开到什么范围？

依据组织规则和内容敏感度决定。对外版本不应包含客户身份、内部责任判断、安全细节或未公开计划。

如何避免复盘变成追责会？

聚焦当时信息、系统条件和决策机制，明确事实与判断，行动项指向可改流程而非模糊人格评价。

相关文章

• 用 AI 搭指标树
• 用 AI 写发布说明
• 用 AI 规划产品路线图
• 用 AI 写周报
• AI 产品工作指南

带走什么

产品复盘要忠于当时目标和现有证据，把事实、解释与行动分开。AI 负责整理和提出反例，人负责数据口径、因果判断与改进承诺。