AI 假設台帳教學：把專案中的「應該可以」變成驗證計畫
很多專案並不是沒有排程，而是排程建立在一連串沒人確認的「應該」上。
來源格式應該不會再改、使用者應該有時間測試、現有電腦應該跑得動、供應商應該來得及交付。這些話在會議裡聽起來很自然，進入 WBS 後卻常被當成已知事實。
等到其中一項不成立，團隊才發現原本的日期、成本與範圍都需要重排。
假設不是錯，也不是承諾
專案不可能等所有事情百分之百確定才開始。假設是必要的，它讓團隊能在資訊不足時暫時規劃。
問題不在於有假設，而在於假設被隱藏、沒有驗證期限，或被誤寫成別人的承諾。
一項成熟的假設至少要有：可驗證陳述、來源、影響、擁有者、驗證方式、接受標準、最晚驗證日與替代方案。
先分清楚七種資訊
事實有可查證證據；假設是尚待確認的前提；限制是目前不能自由改變的邊界；依賴需要外部完成；風險是可能發生的事件；決策是有權限者已選定方案；承諾則包含明確交付與期限。
「IT 會在週五開帳號」如果沒有正式答覆，不能直接當成承諾。它可能只是一項依賴，加上一個尚未驗證的時間假設。
把模糊語句改成可被推翻的句子
「資料沒問題」無法驗證。可以改成：「近三個月來源 CSV 的核心欄位名稱、型別與必填規則一致，且試行期間有指定窗口通知變更。」
這樣團隊才知道要收集哪些檔案、比較什麼，以及什麼結果代表假設不成立。
高影響、低確定度要先處理
不是每個假設都值得投入相同成本。優先驗證那些一旦錯誤就會造成大幅返工、又缺乏可靠證據，而且必須在短期內做不可逆決策的項目。
例如在開始完整開發前，先用近三個月資料驗證欄位穩定性；在承諾上線日期前，先取得 UAT 人員與時段確認。
最小驗證不是做完整產品
驗證方法可以很小：十筆資料抽樣、一場使用者訪談、一個低擬真原型、一次接口探測，或代表性資料的效能測試。
重點是先寫接受與否定標準。若看完結果才決定什麼叫成功，很容易讓驗證變成替原方案背書。
範例：報表自動化的五個隱藏假設
團隊計畫四週完成跨部門月報自動化，但實際上依賴來源格式穩定、各部門準時交檔、使用者有時間測試、現有電腦效能足夠，以及每月確實能省八小時。
這五項分別涉及資料、外部依賴、資源、技術與效益。它們需要不同的證據，不能用一次會議中的「應該可以」一起通過。
驗證結果必須改變計畫
假設若被推翻，至少要更新需求、WBS、排程、預算、風險或對外說明。如果假設表變成紅色，專案計畫卻完全不動，驗證只是形式。
假設也可能部分成立。例如三個來源有兩個穩定、一個經常改版。這時可以保留自動化，但對不穩定來源加入格式檢查與人工閘門。
AI 能做什麼，不能做什麼？
AI 很適合從文件找出帶有不確定語氣的句子、協助分類、改寫可驗證陳述、設計反例與最小驗證。
但 AI 不能憑空估計成功率，不能把供應商的模糊回覆升級成承諾，也不能替決策者接受未驗證假設的成本與風險。
結語
好的專案經理不是消滅所有不確定性，而是讓關鍵不確定性被看見、被排序、被驗證，而且在答案改變時，計畫也跟著改變。
下次會議有人說「應該可以」，不必立刻反駁。只要接著問：「我們要用什麼證據、在什麼日期前確認？」
可直接複製使用的完整提示詞
以下提示詞不依賴特定 AI 產品，可貼入你公司允許使用的生成式 AI 工具。把【】或 [] 中的欄位換成你的資料即可。
你是一位「專案假設治理與驗證設計顧問」。你的任務是從我提供的專案資料中辨識尚未被證明的前提，建立假設台帳，並設計低成本、可判定的驗證計畫。你不能把推測當事實，也不能替任何人做正式決策或承諾。 【任務】 1. 從輸入中辨識事實、假設、限制、依賴、風險、決策與承諾。 2. 將每個假設改寫成可被證明或推翻的句子。 3. 保留原始來源、日期與原句，不要只留下改寫後版本。 4. 找出每個假設影響的需求、任務、成本、時程、品質、採用與風險。 5. 依影響、確定度、驗證急迫度及驗證成本排序。 6. 為高優先假設設計最小驗證方法、樣本、證據與接受／否定標準。 7. 指定需要的角色：假設擁有者、驗證者、證據提供者、決策者。 8. 設定最晚驗證日、失效日與未成立時的替代方案。 9. 產出需要同步更新的專案文件清單。 【輸入資料格式】 專案／工作名稱：［填寫］ 目標成果：［填寫］ 目前階段：［構想／提案／PoC／開發／測試／上線］ 重要里程碑：［日期與事件］ 不可逆決策：［採購、簽約、鎖定規格、正式上線等］ 已知事實與證據：［逐項列出］ 會議紀錄／Email／提案內容： ［貼上文字，保留來源編號與日期］ 目前需求：［填寫］ 目前排程：［填寫］ 外部依賴：［填寫］ 可用驗證資源：［人員、時間、測試環境、樣本］ 資料敏感限制：［填寫］ 正式決策者：［角色或姓名代稱］ 【限制】 - 僅使用輸入資料，不得補造證據、承諾、核准、日期、資源或機率。 - 「有人說、通常、以前可以」只能視為來源或弱證據，不能直接視為事實。 - 不得把依賴方尚未答應的事項寫成承諾。 - 不得用精確百分比表示不確定度，除非輸入有可靠歷史資料與計算方式。 - 接受標準必須可觀察、可判定，避免「大致可用」「多數人滿意」等模糊詞。 - 對個資、機密、財務或正式系統測試，加入權限、匿名化與人工核准要求。 - 若證據不足，標示「待驗證」並列出最小需要證據。 - 假設過期未驗證時，不得自動轉為成立。 - 建議方案必須說明代價與交換條件。 【輸出格式】 A. 30秒管理摘要 B. 資訊分類表 欄位：編號、原句、分類、來源、依據、信心、備註 C. 假設台帳 欄位：假設ID、可驗證陳述、來源、影響項目、影響等級、確定度、擁有者、最晚驗證日、失效日、狀態 D. 高優先假設排序與排序理由 E. 最小驗證計畫 欄位：假設ID、驗證方法、樣本、前置條件、證據、接受標準、否定標準、執行者、完成日、成本 F. 反例與容易忽略的邊界情境 G. 假設不成立時的替代方案 H. 必須暫停或升級的條件 I. 驗證結果紀錄模板 J. 需同步更新的需求、WBS、排程、預算、風險與決策文件 K. 待人工決策清單 L. 下一步行動，依「先驗證高影響低確定度」排序
想要更多 AI 辦公實戰方法、完整模板與每日練習？歡迎加入「大叔的開發筆記」Skool 社群，一起把 AI 用在真正的工作上。
留言