如何用 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 日。