如何用 AI 编写经验教训报告：区分根因与假设，追踪行动效果

要用 AI 编写经验教训报告，先冻结事件或项目范围，收集带日期的证据集，区分预期与实际结果。让 AI 整理观察、起草可能的教训，但要求附引文或来源 ID。由直接了解情况的人核实影响因素和根因说法，再把获批教训转成有负责人、期限和明确效果检验的行动。

经验教训报告不是会议纪要、完整根因分析、事故报告或绩效评估。它应说明哪些条件促成或阻碍了结果，以及未来团队应重复、改变或调查什么。按照 AI 使用总指南设定边界。项目计划仍是计划工作的记录；用行动项流程记下决定，但不要把它们当作已核实的教训。

关键要点：

• 收集材料前，先定义范围、时段、受众和决策。
• 保存证据，区分预期结果与实际结果。
• 既检查成功也检查不足，不让报告变成问责。
• 区分观察、影响因素、假设和已验证原因。
• 按“条件、影响、未来建议”写教训。
• 每项行动都有负责人、期限和效果衡量方式。

步骤 1：确定范围、时段和受众

写一份简短的复盘章程：项目、事件、版本、演练或阶段，起止日期，涉及的团队和地点，目标读者，以及报告要改善的未来决策。写明排除项，免得复盘变成无边的审计。

理清相关流程。安全事故可能需要受保护的调查；雇佣问题可能要交人力资源处理；信息安全事件可能有访问和披露限制。经验教训报告可以采用这些流程已批准的结论，但不应取代或干扰它们。

指定报告负责人和批准小组，他们应有足够的专业知识和独立性来质疑草稿。规定参与者如何更正引述、敏感信息如何脱敏，以及最终报告和行动跟踪表存放在哪里。

NASA 把经验教训描述为从经验中获得、可惠及未来项目的知识，并设有收集和分享这类知识的流程。［1］ 价值来自复用，而不只是记录“开过复盘会”。

步骤 2：建立受控证据集

收集既能反映意图、也能反映执行的材料：

• 已批准的计划、需求、进度和成功标准；
• 决策日志、变更记录、风险和问题日志；
• 运营日志、测试结果、质量记录和指标；
• 会议记录和当时的笔记；
• 客户、合作伙伴和团队的反馈；
• 与本项工作相关的以往教训和行动。

每项材料分配证据 ID、负责人、日期、版本、出处位置、敏感程度和可靠性说明。保存原件；文件有变更时，保留分析所用的版本。

不要把受限日志、个人信息、法律材料、安全细节或机密反馈上传到未经批准的 AI 服务。尽量减少输入，并遵守访问、保留和脱敏规则。NIST 的生成式 AI 风险概况强调了在整个使用过程中应管理的隐私、虚构、信息完整性和人工监督风险。［4］

对从外部来源引入的说法，使用事实核查流程。如果大家都是从同一个人那里听来的，重复出现的回忆并不自动算作独立证据。

步骤 3：分开预期与实际结果

讨论原因之前，先建立结果表：

结果 ID	预期结果与来源	实际结果与证据	差异	可信度与缺口
O-01	PLAN-04 的获批目标	MET-09 的测量结果	明确差异	两条迟到记录待补

有已批准的成功标准就用它们；当初没有明确目标，就如实说明，不要事后补造。定性与定量结果并列记录，但写明代表谁的观点、反馈如何收集。

核对单位、人群、时间边界、缺失数据和修订。靠缩减范围赶上日期的项目，未必达到了原本的预期结果；反过来，一项延误的活动也可能避免了更大的失败。保留背景。

结果表复核之后，才让 AI 总结差异。要求它附上来源 ID，并在证据不足时返回 INSUFFICIENT EVIDENCE，而不是推断结果。

步骤 4：同时分析有效做法和不足

成功和不成功的结果都要复盘，问哪些条件、决策、控制、技能、资源或沟通起了作用。只记录问题的报告让团队学得更少；促成成功的条件不被看见，成功也难以重复。

条件允许时，用多种收集方法：文件审阅、结构化访谈、匿名反馈、引导式讨论和指标分析。记录不同看法，不过早强求共识。参与者可能准确描述了自己的经历，却没有证据支撑更宏观的因果结论。

避免指责性语言和对个人性格的评判。描述可观察的工作条件和决策。“审批负责人有三天没有明确”可以复核；“团队不重视治理”则是在揣测动机。如果个人行为需要调查，就走相应的正式流程。

NASA 的经验教训信息系统保存各项目的教训，让未来团队能够检索和复用相关经验。［2］ 在里程碑时就收集教训，不要完全依赖项目结束时的记忆。

步骤 5：区分观察、因素、假设与根因

使用明确的证据状态：

• 观察： 某个来源或测量直接显示的内容。
• 影响因素： 经复核、被认为影响了结果的条件。
• 假设： 看似合理、但仍需检验的解释。
• 已验证根因： 通过已批准的分析流程确立的因果结论。
• 未知： 证据不足的重要问题。

AI 可以归类相似观察或生成调查问题，但不得把相关性或频繁出现的意见提升为根因。润色过的因果故事即使每句都合理，也可能是错的。

一条有用的提示词是：

把所提供的证据整理为观察、支持的来源 ID、矛盾之处和未解决问题。只有在引用了支持证据时，才提出候选影响因素。把所有未经验证的解释标为假设。不要补造事件、意图、责任归属或根因。保留少数意见；证据不足时返回 UNKNOWN。

已有经验证的根因分析时，把它作为输入引用，并保留其范围和批准信息。不要借 AI 非正式地重做，再用新结论取代。

步骤 6：用 AI 编写经验教训报告时按条件、影响和建议写教训

可复用的教训应具体到能指导未来的决策，又不至于窄到只是复述一次事件。使用如下结构：

条件： 当 [scope] 中出现 [reviewed condition] 时， 影响： 它促成了 [observed effect]，依据为 [evidence IDs]。 建议： 未来团队在 [trigger] 时，应当 [bounded action or decision rule]。 限制： [uncertainty, exception, or transfer condition]。

避免“多沟通”“早测试”这类口号。写明谁在何时需要什么信息、通过哪项控制，以及如何识别成功。同样，不经可迁移性检验，不要把一个团队的经验推广到所有情境。

向复核人提三个问题：证据是否充分？教训是否与行动区分开了？另一个团队能否看懂它何时适用？通不过这些检查的陈述，就否决或修改。

步骤 7：把获批教训转成行动

报告需要一份行动跟踪表，而不只是建议：

证据	观察	教训	行动	负责人	期限	验证方式	状态
EV-03、LOG-07	审批没有负责人	上线前指定权限	在上线清单加入负责人和升级计时	项目负责人	9 月 30 日	抽查三次上线的延误	已批准

请用真实证据和获批行动代替示例。每项行动应有一位负责人、期限、所需资源、优先级和效果衡量方式。“更新流程”不完整，除非知道由哪份文件承载、谁批准、如何验证。

FEMA 的 HSEEP 政策和指南把演练中的观察与纠正行动、负责组织和完成跟踪联系在一起。［3］ 同样的纪律能防止教训在发布后就被遗忘。

区分“完成”与“有效”。发布一份清单，只算完成了交付物；证明团队确实在用、目标问题确实减少，才是在检验结果。安排后续复核日期，并定义什么证据会让这项行动关闭、修订或重新打开。

步骤 8：复核、脱敏、归档和跟进

把依赖某位负责人证据的具体观察和教训陈述交给他复核，邀请他附上来源进行更正。公开解决矛盾；证据仍然不一致时，保留这一局限。

分发之前，复核隐私、保密、法律特权、安全、信息安全、合同和监管方面的限制。只做必要的删节；如果政策要求，保留一份授权记录。对小团队或特征明显的事件，仅删除姓名往往不足以去标识化。

把带日期的报告版本和行动登记表一起批准。记录谁批准了对证据的解读、谁接受了每项行动、谁负责后续跟进。配置好人类审批步骤，确保 AI 草稿不会被误认为已批准的报告。

把教训放在未来团队规划时能找到的地方，而不只是结项档案。按领域、触发条件、生命周期阶段和适用范围打标签。到预定跟进时间，复核完成情况和效果证据，更新状态，并记录行动为何关闭、修订、移交或被否决。

后来的证据表明某条教训的条件已不再适用时，就废止或修订它。如果旧建议在没有背景说明的情况下一直显示，知识库就会变得不那么可信。

最终质量检查清单

批准前确认：

• 范围、时段、受众和排除项明确；
• 预期和实际结果都引用了受控证据；
• 成功和不足都有呈现；
• 观察、假设、影响因素和已验证原因彼此区分；
• 没有 AI 编造的事件、引述、结果、根因或责任归属；
• 每条获批教训都写明何时适用、改变什么；
• 每项行动都有负责人、日期、验证方式和状态；
• 参与者和专家已复核相关陈述；
• 隐私和访问控制与材料相称；
• 报告和行动登记表属于同一个已批准版本。

常见问题

复盘会与经验教训报告有何不同？

复盘会是一项讨论或复核活动；报告则是一份受控文件，把证据与获批的教训、行动、负责人和后续跟进联系起来。

AI 能确定根因吗？

AI 可以整理证据并提出假设。根因只能来自已批准的分析方法和合资格的人工复核。

是否记录成功经验？

要记录。写下促成良好结果的条件，让未来团队能有意识地重复。

怎样避免报告变成问责？

描述可观察的条件、决策、控制和证据，而不是动机或性格。个人行为或绩效问题走相应的正式流程。

参与者意见不一致怎么办？

保留不同的说法，找出支持证据，并说明哪些仍未解决。共识不能代替证据。

何时收集教训？

在重要里程碑和重大事件之后收集，再在阶段或项目结束时汇总。不要只靠项目结束时的记忆。

行动何时可以关闭？

“完成”意味着交付物已落实；关闭还应考虑事先定义的效果证据。

可以用 AI 处理机密证据吗？

只能在获准处理该类数据的环境和流程中进行。尽量减少输入，控制访问，遵守保留规则，并在需要时让隐私、法务、信息安全或其他专家参与。

来源

1. NASA, NASA Lessons Learned — https://www.nasa.gov/nasa-lessons-learned/
2. NASA, Lessons Learned Information System — https://llis.nasa.gov/
3. FEMA, HSEEP Policy and Guidance — https://preptoolkit.fema.gov/web/hseep-resources/policy-and-guidance
4. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 8 月 29 日。