AI專案風險管理：用Pre-mortem事前驗屍找出致命假設

10月 23, 2026

原內容日期：2026-08-31。本文為既有教學內容補發；範例依原文標示使用，實際權限與規則請以所屬組織核定資料為準。

為什麼風險會議常常沒有用？

專案啟動時，大家通常對未來充滿期待。有人提出風險，容易被聽成不支持；於是風險表最後只剩下「時程、溝通、技術」三個安全答案。

等專案真的出事，團隊才發現早期其實已經有訊號，只是沒人把它說清楚。

先假設失敗，反而比較容易說真話

Pre-mortem的做法，是先設定一個未來時間點，假設專案已經失敗，再回頭思考原因。

當失敗被設定為共同情境，成員不需要直接反對目前方案，也比較容易說出平常不方便提出的擔心。

AI的角色是擴大視角，不是預測未來

AI可以分別從決策者、使用者、執行、維護、資料法務及反對者角度提出風險候選。

但每項內容都應標示是已知事實、合理推論、團隊擔心，還是AI提出的待驗證假設。沒有資料時，不應生成看似科學的精準失敗機率。

先定義成功，才能討論失敗

「順利上線」不是完整成功標準。還要知道誰會使用、解決什麼問題、用什麼證據判定有效，以及哪些品質、法規或信任條件不能犧牲。

成功定義本身若很模糊，就是第一項重要風險。

將模糊擔心改成可觀察風險

「使用者不買單」很難採取行動。更具體的說法是：試用者不覺得新方法比原流程更快，因此首次體驗後沒有自然回訪，團隊卻持續增加功能。

好的風險敘述包含條件、原因、早期訊號與可能影響。

找到根因，而不是停在失敗結果

延期、超支、沒人使用通常是結果。真正能介入的地方，可能是需求未驗證、授權未確認、責任邊界不清、前置資料品質不足或營運工作被忽略。

建立根因、觸發事件、中間事件與結果的因果鏈，才能知道現在可以改變哪一段。

致命假設要最先驗證

有些假設一旦錯誤，整個專案就不成立。例如使用者根本沒有需求、資料無法合法取得、技術成本超過可接受範圍，或沒有人願意維護。

先問現在有哪些證據，再設計最低成本測試。不要用完整開發去驗證一句「大家應該會喜歡」。

風險需要領先指標

最終結果是「無人使用」，領先指標可能是試用者無法提出真實使用情境、首次使用後沒有回訪，或仍回到原本做法。

領先指標讓團隊在損失擴大前看見變化。警戒門檻則要依現場基準設定，不能讓AI隨意填數字。

預防、應變與停止條件要分開

預防措施降低風險發生機率；應變方案在風險發生後降低損失；觸發條件決定何時啟動備案；停止條件則保護團隊不因沉沒成本無限投入。

這四項分開後，風險表才會真正影響行動。

用小型實驗換取證據

訪談少數目標使用者、製作人工原型、先處理10則素材、測試20個真實問題，通常比直接投入三個月開發更有價值。

實驗不是為了證明自己的想法正確，而是讓錯誤假設可以更早、以更低成本被發現。

結語

好的Pre-mortem不會讓團隊變悲觀，反而讓大家更清楚哪些事情值得放心，哪些需要先驗證。

AI可以幫忙把擔心整理成結構；真正的責任，是由團隊用證據更新判斷，並在早期訊號出現時願意採取行動。

逐步操作

第一步：先寫清楚專案成功的樣子

不要只寫「順利上線」或「大家都喜歡」。至少回答：

誰會使用？
解決什麼問題？
在什麼期限內？
用什麼證據判定有效？
哪些結果不能犧牲？

例如：

90天內完成一個可供20名試用者使用的課程知識助手；回答能追溯至已授權原始素材，重大錯誤由人工審核，試用者能在3分鐘內找到指定概念。

這不是正式承諾，而是本次風險分析使用的成功定義候選。

第二步：設定失敗時間點

選一個具體時間點：

30天後：適合活動、短期流程改善。
90天後：適合MVP、內部工具。
6個月後：適合系統導入、新服務。
1年後：適合長期產品或組織變革。

然後寫：

現在是[日期]。專案被迫停止／無人使用／超支／無法上線。請回顧發生了什麼。

第三步：先讓每個人獨立寫三個原因

如果有團隊，先讓成員獨立思考2～3分鐘，再交給AI整理。這能避免第一個發言者影響所有人。

可用匿名方式收集：

我最擔心的失敗原因
我已經看到的微弱訊號
我覺得團隊不太願意談的問題
哪個假設一旦錯了，整個專案就不成立

第四步：讓 AI 扮演六種角色

至少從以下視角檢查：

贊助／決策者： 投資價值、優先序、成果證據。
最終使用者： 是否真的願意用、是否解決問題。
執行團隊： 能力、工作量、依賴、時程。
營運維護者： 上線後誰更新、處理錯誤、回覆問題。
資料／資安／法務： 授權、個資、資料來源、責任。
反對者或替代方案支持者： 為什麼不該做、是否有更便宜做法。

角色不是用來扮演壞人，而是補足團隊容易忽略的角度。

第五步：把失敗原因改寫成可檢查的句子

不要寫：

使用者接受度不足。

改成：

試用者覺得回答不比搜尋原始教材快，前兩週只有少數人重複使用，因此團隊在沒有穩定使用需求前就持續增加功能。

一個可用的風險敘述包含：

事件或條件
為什麼會發生
可觀察的早期訊號
對專案造成的影響

第六步：區分根因、觸發事件與結果

例如：

根因：沒有取得素材使用與改寫授權。
觸發事件：準備公開試用時，內容擁有者要求停止。
結果：已建內容無法發布，時程與信任受損。

「專案延誤」通常是結果，需要繼續追問延誤是如何形成的。

第七步：找出致命假設

致命假設是：一旦錯了，專案價值或可行性就大幅下降。

常見類型：

使用者真的有這個問題。
解法比現有做法更省時間或更可靠。
關鍵資料能合法取得與持續更新。
技術能在可接受成本內達到品質。
有人願意負責長期營運。
決策者願意投入資源。

每個假設都要問：「現在有什麼證據？最便宜的驗證方式是什麼？」

第八步：排序，但不要假裝是精準機率

可以用1～5分評估：

發生可能性
影響程度
被發現前的隱蔽程度
目前證據強度（反向參考）

分數只是討論工具，不是統計模型。AI不得宣稱「有80%機率失敗」，除非有可靠資料與計算依據。

第九步：為高風險建立領先指標

領先指標要比最終結果更早出現。

例如「使用者不採用」的早期訊號可以是：

邀請20人，實際完成首次使用不到[門檻待確認]人。
首次使用後，第二週回訪人數持續偏低。
使用者仍回到原本搜尋或詢問人的方式。
訪談時無法說出明確使用情境。

門檻需由團隊依專案規模確認，不要讓AI自行設定。

第十步：設計預防、應變與停止條件

每項高風險至少包含：

預防措施： 現在做什麼降低發生可能。
應變方案： 風險發生時怎麼降低損失。
觸發條件： 看到什麼訊號就啟動備案。
停止條件： 什麼情況下不應繼續投入。

停止不一定代表失敗，也可能是及早保護資源。

第十一步：把最大風險變成最小實驗

不要用三個月開發來驗證「有人想用」。可以先：

訪談5～10位目標使用者。
用20個真實問題做人工原型。
只整理一個主題、10則故事或一個流程。
由人工提供回答，測試需求與信任。
先取得素材授權與引用規則。
比較新方法與原做法所需時間。

實驗應寫清楚：假設、方法、樣本、成功門檻、失敗後的決定。

第十二步：建立不責怪人的風險回顧

每週或每個里程碑確認：

哪些早期警訊已出現？
哪些風險下降或升高？
新證據改變了哪些假設？
是否需要啟動備案？
是否已達停止或縮小範圍條件？

檢查制度、資訊與條件，不把風險表變成人員評分表。

可直接複製的完整提示詞

你是一位資深專案風險顧問、產品策略師、營運主管與Pre-mortem主持人。你擅長在不責怪個人的前提下，從不同利害關係人視角找出專案可能失敗的原因，並將模糊擔心轉換成可驗證假設、領先指標、預防措施、應變方案與最低成本實驗。

【任務】
請針對我提供的專案進行事前驗屍（Pre-mortem）：假設在指定時間點，專案已經失敗或被迫停止，倒推可能原因與被忽略的早期訊號。

你的輸出是風險假設與驗證計畫，不是預言。不得虛構事實、精準機率、客戶反應、成本、日期、授權狀態或責任人。

【專案基本資料】
專案名稱：[填寫]
專案類型：[系統導入／流程改善／活動／新產品／AI應用／其他]
目前階段：[構想／規劃／開發／試行／上線前／其他]
預計期間：[填寫]
預算或資源限制：[填寫]
專案贊助角色：[填寫]
專案負責角色：[填寫]
主要使用者：[填寫]
主要合作角色：[填寫]

【成功定義候選】
在[時間點]前，希望達成：[填寫]
可接受的成功證據：[填寫]
不能犧牲的條件：[品質／法規／資安／信任／成本上限／其他]
本次不在範圍內：[填寫]

【失敗情境】
假設現在是[未來日期或期間]，專案發生：[被迫停止／無人採用／嚴重延期／超支／未通過驗收／其他]
已知最終結果：[填寫；沒有則只使用上方情境]

【已知事實】
請逐項提供來源或證據：
[貼上]

【尚未驗證的假設】
[貼上；不知道可填無，請協助辨識候選]

【團隊個別擔心】
角色代碼｜擔心的事情｜已看到的微弱訊號｜不確定處
[貼上匿名內容]

【已知限制與依賴】
項目｜類型｜依賴對象｜目前狀態｜若未取得的影響
[貼上]

【分析角色】
請分別從以下角度分析：
1. 贊助／決策者
2. 最終使用者
3. 執行團隊
4. 營運維護者
5. 資料／資安／法務／品質
6. 合理反對者或替代方案支持者

【限制與判定規則】
1. 所有風險必須標示為已知事實、合理推論、團隊擔心或AI提出的待驗證假設。
2. 不得把AI提出的情境寫成已經發生或一定會發生。
3. 不得捏造精準發生機率、損失金額、日期、使用率、成本或市場反應。
4. 沒有可靠歷史資料時，機率只能使用高、中、低或1～5討論分數，並標示主觀評估。
5. 區分根因、觸發事件、早期訊號與最終結果。
6. 「專案延期、超支、失敗」通常是結果，必須繼續追問形成原因。
7. 風險敘述需包含條件、原因、早期訊號及可能影響。
8. 不得將個人性格、年齡、背景或未證實動機當作風險根因。
9. 問題聚焦流程、資源、資訊、假設、制度與外部條件，不進行人身歸責。
10. 找出風險間的因果關係，避免把同一原因拆成大量重複項目。
11. 區分可控制、可影響與只能監測的風險。
12. 找出一旦錯誤就會大幅降低專案價值或可行性的致命假設。
13. 每項致命假設都要列出現有證據、反證與最低成本驗證方式。
14. 領先指標必須能在最終失敗前被觀察。
15. 警戒門檻若無資料支持，保留[待團隊設定]，不得自行創造。
16. 預防措施、應變方案、觸發條件與停止條件必須分開。
17. 建議行動需考量現有資源與時間，不提供無限資源下的理想方案。
18. 優先建議可在7、14或30天內取得證據的小型實驗。
19. 實驗需包含假設、方法、樣本、觀察指標、門檻、結果對應決策。
20. 不能將訪談者口頭興趣直接視為付費、採用或正式承諾。
21. 涉及著作權、授權、個資、資安、法規、醫療、財務、合約或人事時，標示需由專業角色確認。
22. 未取得授權的素材不得建議直接公開、訓練模型或商業使用。
23. 不得從匿名資料推測真實人物、組織或專案。
24. 使用繁體中文，語氣直接、專業、尊重。

【輸出格式】

一、事前驗屍摘要
以150字內描述假設的失敗情境、最大三項風險、最早應驗證的致命假設。

二、成功定義健檢
| 項目 | 已提供內容 | 是否可驗證 | 尚缺什麼 | 建議確認人 |

三、六角色失敗原因
| 角色 | 可能失敗原因 | 類型 | 判斷依據 | 早期訊號 | 可能影響 |
類型限定：已知事實、合理推論、團隊擔心、AI待驗證假設。

四、因果鏈整理
| 根因 | 中間事件 | 觸發事件 | 最終結果 | 現在哪一段可介入 |

五、致命假設清單
| 假設ID | 假設 | 為何致命 | 現有證據 | 反證 | 證據強度 | 最低成本驗證 |

六、風險優先表
| 風險ID | 風險敘述 | 可能性1～5 | 影響1～5 | 隱蔽1～5 | 評分依據 | 優先序 |
分數標示為討論用主觀評估，不得轉換成精準機率。

七、領先指標與觸發條件
| 風險ID | 領先指標 | 目前基準 | 警戒門檻 | 觀察頻率 | 資料來源 |
缺少門檻時填[待團隊設定]。

八、風險處理卡
| 風險ID | 可控制程度 | 預防措施 | 應變方案 | 啟動備案條件 | 停止／縮小條件 | 負責角色 |

九、7／14／30天驗證計畫
| 時間 | 假設ID | 實驗 | 樣本 | 觀察指標 | 成功門檻 | 失敗後決定 | 成本或工時 |
沒有資料時使用[待填]，不得自行承諾。

十、最便宜的三個下一步
每項說明：今天能做什麼、能降低哪項不確定性、完成證據。

十一、反方意見
提出最有力的三項「不應繼續／應改用其他方案」理由，並說明需要什麼證據才能回應。

十二、啟動會議風險摘要
提供一段可直接貼入專案章程或啟動簡報的版本。

十三、人工確認清單
列出設定門檻、指派責任、啟動備案、停止專案及使用敏感素材前必須確認的事項。

實際教學範例

專案情境

將一位講師多年課程中的故事、觀念與練習整理成AI知識助手，先供小範圍學員查詢與學習。

初步成功定義

90天內完成可供20名試用者使用的原型；回答能回到已授權的原始故事或教材，並由內容負責人確認重要觀念沒有失真。

這仍是規劃候選，需要與內容擁有者確認。

假設失敗情境

六個月後，專案停止公開測試。團隊做了很多內容，但使用者很少重複使用；部分故事的公開與改寫授權不清楚，回答也偶爾把不同課程觀念混在一起。

六角色可能看到的問題

角色	失敗原因候選	早期訊號
內容擁有者	助手的語氣或解釋偏離原意	多次要求修正核心觀念，無明確審核準則
學員	不知道什麼時候要用，比搜尋筆記沒有更快	首次試用後很少再次提問
執行團隊	一開始就整理全部課程，範圍太大	素材持續增加，第一個可測版本遲遲不出現
維護者	沒有人長期更新與處理錯誤	新故事加入後沒有固定審核與版本流程
授權／法務	未先確認故事、姓名、影像與引用權限	準備公開時才開始詢問授權範圍
合理反對者	簡單的主題索引加人工回覆可能更便宜	使用量低，AI成本與維護工作卻持續增加

致命假設

假設	為何致命	最低成本驗證
內容擁有者願意授權指定素材用於此用途	無授權就不能可靠公開或持續擴充	先用一頁用途、範圍、引用與審核說明取得書面確認
學員有重複查詢故事與觀念的需求	沒有使用情境，功能再多也不會被採用	訪談8名學員，收集最近真正找不到答案的20個問題
10則故事足以測試核心價值	若必須整理全部內容才能有用，MVP成本過高	只製作10則經確認故事，進行兩週人工輔助測試
回答能追溯來源並維持原意	無法追溯會傷害信任	由內容負責人評閱20題，記錄錯誤類型而非只看總分

領先指標候選

試用者提出的問題是否落在已整理內容範圍。
首次使用後是否出現自然回訪，而非被提醒才使用。
每20個回答中，需要重大內容修正的數量。
新增一則故事從整理到核准所需工時。
回答無法提供來源的比例。
授權與審核規則是否在公開測試前完成確認。

具體門檻需由專案成員與內容擁有者決定，不能由AI憑空設定。

7天最低成本行動

整理一頁式用途、對象、素材範圍與授權問題。
訪談5～8名可能使用者，收集真實問題，不先介紹完整功能。
挑選10則已確認可使用的故事，建立人工原型。
設計20題測試，記錄答對、失真、無來源及超出範圍。

AI不能做的事

不能把講師表示「有興趣」解讀為已正式授權全部素材。
不能自行決定哪些故事可公開或商業使用。
不能預測學員一定願意使用或付費。
不能用虛構的使用率證明市場需求。
不能把課程觀念重新解釋後，假裝仍是講師原話。

常見錯誤、隱私與使用注意事項

把Pre-mortem當唱衰大會： 目的是提早降低不確定性，不是證明專案不該做。 - 問題全部歸因於個人： 應檢查制度、資訊、資源、依賴與流程。 - 只列最壞情境： 還要有早期訊號與可執行行動。 - 把AI假設當現況： 每項風險要標示來源與證據身分。 - 捏造精準機率： 沒有歷史資料時，分數只是排序工具。 - 每項風險都評最高： 會失去優先順序。 - 把結果當根因： 延期、超支、無人使用都需要繼續追問。 - 只有風險負責人： 還要有領先指標、觸發條件與應變方案。 - 門檻由AI亂設： 數值需依基準、規模與可接受風險決定。 - 只做訪談就宣稱需求成立： 口頭興趣不等於實際採用。 - 實驗規模太大： 應用最小樣本先測最致命假設。 - 沒有停止條件： 團隊可能因沉沒成本持續投入。 - 用匿名風險猜測發言者： 不應追查或推測是誰提出擔心。 - 貼入客戶、員工或未公開資料： 先去識別化並遵守公司政策。 - 忽略授權與著作權： 有內容不等於有權改寫、公開或商業使用。 - 把風險表當績效表： 會讓團隊不敢回報早期警訊。