Premortem 完整流程

2026-08-18

來源：改編自外部 Anthropic premortem skill（西班牙文原文，Gary Klein 方法的完整落地版）。 理論依據：references/principles/premortem-klein.md（單一問句「假設已失敗，是什麼殺了它」的心理學根據）。本檔是該問句的操作展開版——把一句話問句擴展為「列舉 -> 並行深挖 -> 綜合」三段式流程。 與 WRAP P 階段的關係：P 階段預設用簡化三問（見 SKILL.md「P — 準備好犯錯」：假設 12 小時後失敗，列 3 個最可能原因）。本檔是同一方法論在高成本決策下的完整展開——原因數量不設上限（3-9 不等）、每個原因獨立派 subagent 深挖、最後產出結構化綜合報告。

適用邊界

何時用完整 premortem（本檔），何時用 P 階段簡化三問

情境	適用流程	理由
一般 ticket 執行前 WRAP 檢查	P 階段簡化三問（SKILL.md）	決策成本低，1-2 分鐘完成即可
版本規劃、重大提案評估、發版前檢查	完整 premortem（本檔）	決策成本高，錯誤代價需要並行深挖攤開
架構決策、規則系統重大變更	完整 premortem（本檔）	影響範圍跨多個後續 ticket，值得投入並行分析成本

判斷依據：不是「時間夠不夠」，而是「錯誤的修復成本是否遠高於分析成本」（見 .claude/rules/core/ai-communication-rules.md 規則 6，決策依價值/容量非估時）。

好的 premortem 對象

即將建置的產品或功能
有金錢或聲譽風險的發版計畫
定價或商業模式變更
策略或定位轉向
任何「答錯代價很高」的承諾

不適合 premortem 的對象

情境	原因	建議改用
沒有具體計畫的模糊想法	缺乏可分解的失敗原因錨點	先協助定案計畫，再回頭做 premortem
只有單一正確答案的問題	不是決策，是事實查核	直接查證回答
對草稿的創意回饋	屬編輯範疇，非風險推演	一般 review 流程
已定案且不可逆的決策	premortem 只在還能改路線時有用	不執行；如需記錄教訓見 quality-baseline 規則 6

五步流程

步驟 0：Context 充足度閘門

核心問句：「我對這個計畫的理解，夠不夠讓失敗原因錨定在真實細節上？」資訊不足時產出的失敗原因會流於空泛通用建議，對決策者沒有幫助。

先查現有 context，再問用戶：掃描當前對話、CLAUDE.md、memory/ 目錄、ticket 描述，提取已有資訊，避免重複詢問已知內容。

三問門檻（三項都有答案才進入步驟 1）：

問題	目的
這是什麼？	一句話描述被分析的計畫/決策/產品
影響誰？	受影響的對象（用戶群、團隊、利害關係人）
成功長什麼樣？	失敗是成功的反面，不知道成功定義就無法定義失敗

補齊方式：三項有缺，一次只問最關鍵的一項，每次回答後重新評估是否已達門檻，不逐項機械提問。三項齊備立即進入步驟 1，不做多餘提問。

步驟 1：Raw 失敗原因列舉

單次完整分析，不預設分類、不套用固定視角（lens）。

每個失敗原因必須：

具體對應此計畫（不是套用任何計畫都成立的通用建議）
錨定計畫的真實細節（用戶提供的具體數字、時程、對象）
是真實威脅（非可忽略的小瑕疵或極端邊緣案例）

數量原則：依計畫真實情況而定，不預設固定數字。原文經驗值落在 3-9 個之間；找不到更多真實原因時停止，不為湊數硬套牽強理由；有更多真實原因時不因「差不多了」提前收尾。

步驟 2：並行深挖（每個原因一個 subagent）

取步驟 1 的每個失敗原因，各自派一個 subagent 獨立深挖，全數同時派發（同一訊息內平行 Agent 呼叫）。序列派發會讓後派發的分析被先前分析污染，且浪費等待時間。

派發規範（本框架落地約束，見下方「框架落地約束」章節）：

prompt 遵循三段式骨架（.claude/references/agent-dispatch-template.md），總行數 <= 30 行
輸出目標為 markdown 檔案，禁 HTML、禁 emoji（.claude/rules/core/document-format-rules.md 規則 1）
並行派發數量與 .claude/error-patterns/process-compliance/PC-137-*.md 上限對照，.claude/ 內檔案編輯場景才受限；本步驟 subagent 產出為 worktree 外的 markdown 分析檔，不受 PC-137 .claude/ 並行編輯上限拘束，但仍建議單批次 <= 6 個以控制 review 負擔

深挖 subagent 產出必含三要素：

失敗故事：2-3 段敘事，具體到「什麼時候、什麼決定、什麼後果」，讀起來像真實案例研究，不是抽象分析
底層假設：一句話——計畫默許為真、但從未被驗證的那個前提
早期警訊：1-2 個可觀測、可量測的訊號（不是模糊感覺，是能實際看到或量到的東西）

單一 subagent 回應總長 < 300 字（中文以字計）。直白陳述，不迴避壞消息，不用「或許」「可能稍嫌」等淡化語氣包裝明確風險。

subagent prompt 範本：

 1Ticket: {ticket_id}
 2
 3## 職責邊界聲明
 4premortem 深挖分析代理人，僅分析下方指定的單一失敗原因，禁止分析其他原因、禁止修改任何程式碼或設定檔。
 5
 6## 背景
 7計畫：{一句話描述 what / for whom / 成功定義}
 8框架前提：假設此計畫已執行完成且已失敗（非「可能失敗」，是「已經失敗」）。
 9
10## 你的任務
11被分派的失敗原因：{failure_reason}
12
13深入還原這個失敗如何發生，寫入 `{scratchpad_path}/premortem-reason-{n}.md`（純 markdown，禁 HTML、禁 emoji），依序含三段：
141. 失敗故事（2-3 段敘事，具體錨定計畫細節，像真實案例研究）
152. 底層假設（一句話：計畫預設為真但未經驗證的前提）
163. 早期警訊（1-2 個可觀測、可量測的訊號）
17
18總長 < 300 字。直白陳述不迴避壞消息，不軟化用詞。
19完成後回報檔案路徑即可，不需在回應中重複全文。

輸出隔離理由：各 subagent 寫入獨立檔案（而非同一份 ticket 或同一份回應），避免並行寫入同一檔案的衝突，也避免綜合者只讀到被 Hook 提示覆蓋的最終回應（相關案例：feedback_review_agent_final_message_hijack.md）。

步驟 3：三分綜合報告

所有深挖 subagent 完成後，讀取全部產出檔案，撰寫綜合報告。綜合報告是整個 premortem 流程的核心產出——多數讀者只會讀綜合報告，深挖細節僅在需要時查閱。

綜合報告固定含五節：

節次	內容	具體性要求
最可能的失敗	依計畫現況判斷最可能發生的失敗場景，附理由	決策者應優先處理的項目
最危險的失敗	發生機率較低但一旦發生傷害最大的場景	值得投保（提前防範）的項目
隱藏假設	所有深挖分析中最重要、決策者最可能未曾質疑過的那個假設	一句話講清楚假設內容
修訂計畫	每項對應一個具體失敗場景的具體改動	禁止空泛建議（如「考慮調整定價」），須寫可執行動作（如「先用 20 人小規模試跑 X 定價一週」）
發版前檢查清單	3-5 項可驗證的具體檢查動作	每項須能防止或偵測某個已識別的失敗模式

步驟 4：落檔

報告落 markdown 至 ticket Solution 章節或對應 worklog，不產出 HTML 檔案、不使用 emoji（原文 paso 5-6 的 HTML 視覺化報告與 emoji 裝飾在本框架一律移除，依 .claude/rules/core/document-format-rules.md 規則 1 與 .claude/rules/core/language-constraints.md 規則 3）。

保留內容：綜合報告五節 + 各深挖分析原始檔案路徑（供需要時查閱），不需另外產生獨立的「逐字稿」檔案。

強制注意事項

原則	說明
全部深挖 agent 必須同批並行派發	序列派發浪費時間，且讓後續分析被先前分析污染
明確設定「已失敗」的框架前提	「已經失敗，解釋怎麼死的」比「可能會失敗嗎」更能繞過過度自信偏誤（見 premortem-klein.md），框架前提不可弱化為疑問句
詳盡但不湊數	找到多少真實原因就列多少，不為對齊某個數字硬湊或提前收斂
綜合報告是產出核心	深挖分析是綜合報告的原料，不是平行地位的最終產出
不軟化風險陳述	premortem 的價值在於說出決策者不想聽但真實存在的問題；發現嚴重問題直接陳述
修訂計畫必須具體可執行	每項改動應是決策者本週就能做的動作，而非方向性提醒
尊重 context 門檻	資訊不足時寧可多問一題，也不要用空泛失敗原因浪費決策者時間

框架落地約束

本節記錄本框架（book-overview）對原文流程的落地調整，其他專案沿用本 skill 時可依自身派發規範調整此節，不影響上方五步流程主體。

面向	原文做法	本框架做法	依據
報告格式	自包含 HTML 視覺化報告 + emoji 裝飾	markdown 落 ticket/worklog，禁 HTML、禁 emoji	`document-format-rules.md` 規則 1、`language-constraints.md` 規則 3
Subagent 派發	未限定框架	prompt <= 30 行、三段式骨架、首行 `Ticket: {id}` 格式	`.claude/references/agent-dispatch-template.md`（PCB pattern）
並行上限	未限定	對 `.claude/` 內檔案編輯場景適用 PC-137 上限；本流程產出為分析檔案不受此限，仍建議單批 <= 6 個	`.claude/error-patterns/process-compliance/PC-137-*.md`
產出路徑	使用者工作區任意位置	ticket Solution 章節或對應 worklog，遵循本專案文件系統	`.claude/rules/core/document-format-rules.md`

與其他決策/審查機制的邊界

機制	分解軸	適用時機	與 premortem 的關係
完整 premortem（本檔）	沿「失敗原因」並行——每個 subagent 深挖同一計畫的不同死因	高成本決策的事前風險推演	—
parallel-evaluation	沿「審查視角」並行——每個 agent 用不同準則審查同一份既定產出（品質/架構/效率等）	程式碼審查、方案審查、Phase 4 重構評估	分解軸不同，不可互相替代：premortem 問「這計畫會怎麼死」，parallel-evaluation 問「這個已完成的東西從各角度看品質如何」
WRAP P 階段簡化三問	單一問句，行前預想 3 個最可能原因	一般 ticket 執行前的快速檢查	完整 premortem 是同一方法論在高成本決策下的完整展開版，兩者共用同一理論依據（premortem-klein.md）
LLM Council / 多方案比較	針對「尚未執行的決策」給出當下多個角度的意見	決策前徵詢多方觀點	premortem 不是徵詢意見，是把 Claude 送到「決策已失敗的未來」倒推原因，心理機制與產出皆不同；使用者若要的是「現在的多角度意見」而非「失敗推演」，應改用方案比較機制

誤用防護：若對已完成的既定產出提出「這個做得好不好」的問題，屬 parallel-evaluation 範疇，不應套用 premortem 流程（無「死亡」可供倒推）。

Tarragon