项目复盘PPT可以分4步做：还原当初的目标与约束，对比实际交付，沿关键事件解释差异，再选少量能验证的改进动作。AI适合将这些记录整理成大纲，但不能把“项目延期”自动归因为执行力，也不能把一次顺利交付当成方法已经被证明有效。
把项目计划、变更记录和团队复盘笔记合在一份材料中，可用文档生成PPT起草。与故障复盘不同，这里既看需要改进的地方，也保留应该继续使用的做法。
第1步：恢复最初的约定，别用最终版本倒推目标
以下使用虚构的“客户帮助中心改版”项目。最初计划在6月30日发布12篇核心帮助文档，验收要求是每篇有操作步骤和一张有效配图。6月18日增加了双语需求；团队没有同步确定范围与发布日期如何调整。实际6月30日发布10篇，其余2篇在7月3日发布。双语内容仍在后续制作，不能写成已经全部交付。
材料至少保留三个版本：最初承诺、已确认的变更、实际结果。有人在会议中提出的想法不能自动算批准变更；项目结束时更新过的总计划，也不能覆盖原来的比较基线。
这个项目的“按期完成”有两种容易混淆的说法：网站模块按时上线，不等于12篇文档按时齐备。首页可以概括为“模块如期上线，2篇文档延后3天补齐”，把进展与缺口放在同一句中，不用单一红绿灯压平结果。
第2步：用交付物比较，保留做得好的部分
| 事项 | 原计划 | 实际记录 | 复盘要追问什么 |
|---|---|---|---|
| 核心文档 | 6月30日发布12篇 | 当天10篇，7月3日补齐2篇 | 两篇共同卡在哪里，而不是平均给所有环节扣分 |
| 配图要求 | 每篇至少一张与步骤对应的图 | 12篇均在发布前经过图文对应检查 | 哪些检查方式值得继续保留 |
| 双语内容 | 最初不在范围内 | 6月18日提出，尚未全部完成 | 新增需求如何进入排期和范围决策 |
不要把“完成10/12篇”直接写成项目完成度83.3%。这只能表示原计划文档数量的发布比例，不能代表质量、工作量或总体进度。两篇未完成的文档可能比其他篇复杂，也可能只是等待某项确认；要回到实际记录解释。
成功做法同样需要证据。本例的图文对应检查确实在每篇发布前执行，可以保留“由另一位成员按步骤核对配图”的做法；没有返工统计时，不把它写成“返工率下降50%”。复盘要留下可复用动作，而不是追加漂亮百分比。
第3步：把事件、解释与证据分开
两篇晚发文档的记录显示：6月21日内容初稿已完成；6月24日发现所用产品截图需要更新；6月27日得到新的界面说明；7月2日完成图文核对。记录能说明等待和修订发生在哪些时点，不能仅凭顺序就确定双语需求是唯一原因。
复盘会可以提出两个假设：一是截图依赖确认得太晚，二是新增需求分散了同一位审核者的时间。第一个需要查截图准备清单，第二个需要看排程与实际审核记录。材料不足时，把假设连同需要补的证据留在页面中，而不是让AI把它们改写成确定结论。
给PPTGO的要求可以这样写：
根据帮助中心改版记录制作复盘大纲。6月30日计划发布12篇，实际发布10篇，7月3日补齐2篇；双语需求6月18日新增但未确认范围和期限。保留配图逐篇检查这个有效做法。晚发两篇涉及截图更新和审核，原因尚需查准备清单与审核排程。区分结果、事件、原因假设，不生成责任人评价，不把10/12称为整个项目完成度。
生成大纲时，顺序可采用“本次结论—计划与实际—关键变更—值得保留的做法—待验证原因—下一次项目动作”。如果大纲只有问题与责任，补回有效做法；如果标题是“新增需求导致延期”，改成“新增需求与审核依赖需要进一步核对”。
页面上用两行对照计划与实际，并把双语需求放在独立的“范围变更”栏。不要把它混入原计划分母，也不要为让时间轴整齐而省略关键日期。PPTGO的页面编辑用于调整这些表达，事实判定仍来自项目记录。
第4步：把复盘结论变成下一次项目的动作
“加强沟通”不能直接指导下一次项目。本例可优先考虑两项改进：在起稿前列出每篇截图的来源及确认人；新增语言或交付项时，同时确认范围、审核资源与期限。它们分别回应截图依赖和需求变更，不需要给每个问题都安排一次培训。
动作页写明触发点、负责人角色、产物和检查时点。例如“下一次内容项目启动时，由内容负责人完成截图依赖表；起稿前检查每项是否有可用来源”，而不是只写“负责人：内容组，截止：下周”。如果团队还没有同意动作，应标成拟议安排。
复盘会后，把动作落实到实际项目工具中；PPT只是讨论与说明载体，不等于任务已经创建或完成。需要长期跟踪目标与结果时，可参考OKR复盘的目标与证据写法；不要把一次项目复盘扩成全团队绩效评价。
用同一份材料在PPTGO起草项目复盘后，最后检查听众能否回答：原来约定什么、实际差在哪、哪种解释有证据、下一个项目要提前做什么。能回答这四个问题，比把过程写成十几页流水账更有价值。
