AI 決策矩陣教學：先淘汰、再加權，避免漂亮分數替你做錯決定

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

選項很多，真正缺少的往往不是更多意見

團隊選供應商、系統或專案方案時，最常見的畫面是：資訊部重視控制，使用部門重視速度，財務關心成本，主管希望不要延誤。每個人都合理，會議卻很難收斂。

AI 的價值不是替大家宣布答案，而是把不同觀點拆成可檢查的決策結構。

第一道關不是評分，而是硬性門檻

如果資料依法不得離開指定環境，這就是門檻，不是「資安」項目的 20 分。未通過門檻的方案，即使便宜、快速、介面漂亮，也不能靠高總分勝出。

先淘汰不能採用的方案，再比較通過門檻的選項，可以避免決策表最危險的錯誤。

分數之前，先確認證據屬於哪一類

正式報價、實際測試及核准文件是事實；「應該兩週能完成」是待驗證假設；「我們比較重視控制」是價值偏好；「這家公司感覺可靠」可能只是印象。

AI 可以協助分類，但不能把假設改寫成事實。證據不足時應標示待查，而不是補上一個看似合理的分數。

權重是價值選擇，不是數學真理

速度、成本、控制、維護與彈性不可能同時都是第一名。權重的用途，是讓決策者公開說明現在最重視什麼。

權重合計 100 後，還要建立不同情境。成本優先時誰領先？控制優先時排名是否翻轉？如果權重只改一點答案就不同，代表這不是穩定結論，應補證據或先取得價值共識。

不要讓 87.4 分製造虛假的安全感

決策矩陣很容易看起來科學。其實每一個分數背後都可能只是口頭印象。

因此每個分數都應附上證據、來源日期與信心程度。總分最多保留一位小數；比起計算更多小數，更重要的是知道哪些高分建立在低信心假設上。

最有效率的下一步，往往是驗證假設

團隊不需要查清全部未知資訊。先找出同時「影響大、信心低、容易驗證」的假設。

例如，不要立刻介接正式信箱；先用匿名測試郵件驗證核心流程。不要先簽長約；先確認實際使用頻率。讓小型試驗回答真正會改變選擇的問題。

決策也有可逆與不可逆之分

可以在一週後停止的原型，和一簽三年的合約，不能用相同證據門檻。可逆、低成本的決定可以快；不可逆、影響大的決定則需要更完整的查證、審查及退出條件。

最後留下「為什麼」，而不只是「選了什麼」

決策紀錄至少應保存當時的選項、硬性門檻、主要理由、未解假設、附帶條件、反對意見及複查觸發條件。

好的決策紀錄不是保證永遠正確。它讓未來的團隊知道：這個答案在什麼條件下成立，又在什麼條件改變時應重新評估。

AI 可以讓選擇更透明，但最終價值取捨與核准責任仍屬於人。這條界線，正是決策矩陣真正有用的原因。

逐步操作

第一步：把「討論主題」改寫成「決策句」

不要只寫「討論新系統」。改成：

我們要在 9 月 18 日前，決定內部專案追蹤工具的第一階段建置方式，由部門主管核准，範圍只包含 Email 匯入、待辦整理與查詢。

一個合格的決策句至少包含：要決定什麼、為何現在決定、決策期限、範圍、決策者。

第二步：列出所有合理選項

除了熱門方案，也加入：

• 維持現狀
• 延後決定，先做小型試驗
• 混合方案
• 分階段採用不同方案

「不做」不是偷懶，而是比較基準；如果不做的代價最低，它也可能是合理答案。

第三步：先設定硬性門檻

硬性門檻是「沒有通過就不能採用」，例如：

• 法規或合約要求
• 資料不得離開指定環境
• 必須在某日期前可用
• 預算上限
• 必須支援既有身分驗證或必要格式

硬性門檻不要拿來加權。資安要求若是必須符合，就不能讓低價格抵銷不合規。

第四步：把準則寫成可判斷的定義

「好用」太模糊。可以改成：

由三位目標使用者在沒有專人陪同下，完成建立專案、匯入一封郵件及找到待辦三項任務。

每個準則都應寫明：定義、衡量方式、評分範圍、誰提供證據。

第五步：檢查準則是否重疊

將「好維護、容易交接、技術門檻低」檢查一次。如果它們都在衡量維運負擔，可合併或清楚切分，避免同一優點得到三次加分。

第六步：分開事實、假設、偏好與未知

類型	範例	處理方式
已知事實	現有主機已支援 PHP 與 MySQL	附來源或確認人
待驗證假設	兩週內能完成可用原型	安排小型試作
價值偏好	團隊較重視完全控制	反映在權重，不冒充事實
未知資訊	郵件介接所需權限	指派查證，不先打分

第七步：先做門檻篩選

依序將各方案標示為：

• 通過
• 不通過
• 尚待確認
• 可在附帶條件下通過

有重大未知的方案，不要直接視為通過，也不要因缺資料就打零分。

第八步：分配權重，合計必須為 100

建議先由決策者說明優先順序，再設定權重。常用準則包括：

• 導入速度
• 資料與資安符合度
• 維護負擔
• 客製彈性
• 一次性與持續成本
• 整合難度
• 使用者採用難度
• 未來擴充性

權重不是客觀真理，而是把組織當下的價值選擇公開化。

第九步：建立有錨點的 1～5 分量尺

不要憑感覺給 4 分。每項準則都先定義分數：

• 1 分：明顯無法滿足，且需重大補救
• 3 分：可滿足基本需求，但有明確限制
• 5 分：已有證據顯示可完整滿足

2 分與 4 分代表介於相鄰描述之間。若證據不足，填「待查」，不要假裝精準。

第十步：每個分數都附證據與信心

證據可以是合約、正式報價、試作結果、政策文件、使用者測試或技術確認。信心可標示高、中、低：

• 高：有正式文件或實測
• 中：有可信來源，但尚未在本情境驗證
• 低：主要來自推測、口頭印象或過期資訊

低信心的高分，通常比低分更值得先查證。

第十一步：做三種敏感度情境

至少比較：

• 速度優先
• 成本優先
• 控制與風險優先

觀察排名是否改變。如果只要把某項權重調整 5～10 分就翻盤，表示決策尚不穩定，應先補證據或取得價值取捨的共識。

第十二步：檢查可逆性與延後成本

詢問：

• 做錯後能否回頭？回頭成本多高？
• 可以先小規模試行嗎？
• 延後一週、一個月會失去什麼？
• 哪些承諾會讓未來被鎖定？

可逆、低成本的決策適合快速試驗；不可逆、高影響的決策需要更多證據與核准。

第十三步：先驗證最會改變答案的假設

不要把所有未知都查完。優先驗證同時符合以下條件的項目：

• 信心低
• 對總排名影響大
• 能以低成本快速驗證

例如先用匿名測試郵件做三天原型，而不是一開始就搬移正式資料。

第十四步：留下決策紀錄

至少記錄：

• 最終選擇及決策者
• 決策日期與適用範圍
• 主要理由與未採用方案
• 仍成立的關鍵假設
• 附帶條件與停止條件
• 不同意見及其理由
• 何時、因何種事件重新檢視

決策紀錄不是證明當時「一定正確」，而是讓未來知道當時依據。

可直接複製的完整提示詞

你是一位資深決策分析顧問、專案經理與風險溝通教練，擅長協助非技術團隊建立透明、可追溯的選項比較與決策紀錄。

【任務】
請根據我提供的資料，建立一份「先檢查硬性門檻、再進行加權比較、最後做敏感度與假設驗證」的決策分析。

你可以整理、追問、指出矛盾及計算我已確認的分數，但不得替我決定價值觀，不得捏造價格、功能、法規、時程、測試結果或供應商承諾。

【決策基本資料】
決策題目：[要決定什麼]
決策原因：[為何現在要決定]
決策期限：[YYYY-MM-DD]
決策者：[角色]
參與角色：[填寫]
適用範圍：[包含與不包含]
決策有效期間：[填寫]
預算或資源限制：[填寫]
若延後決定的影響：[填寫]
敏感資訊限制：[填寫]

【候選方案】
方案編號｜方案名稱｜一句話說明｜是否包含維持現狀／延後／混合方案
[貼上資料]

【硬性門檻】
門檻編號｜門檻內容｜通過標準｜證據來源｜由誰確認
[貼上資料]

【評估準則】
準則｜定義｜衡量方式｜目前建議權重｜1分標準｜3分標準｜5分標準
[貼上資料；尚未決定權重可留白]

【現有證據】
資料編號｜方案｜相關門檻或準則｜內容｜來源｜日期｜確認人
[貼上匿名化資料]

【利害關係人觀點】
角色｜最重視的事項｜擔心的風險｜不可接受結果
[貼上資料]

【已知分數】
方案｜準則｜分數1～5或待查｜理由｜證據編號｜信心高／中／低
[貼上資料；沒有則填無]

【分析規則】
1. 先用一句話重述決策，確認範圍、期限與決策者。
2. 若沒有「維持現狀、延後決定或混合方案」，提醒我考慮加入，但不得自行假定它們可行。
3. 硬性門檻與偏好型準則必須分開；未通過必要門檻的方案不得靠加權總分勝出。
4. 門檻未知時標示「尚待確認」，不得視為通過。
5. 檢查準則是否重疊、含糊、不可衡量或偏向特定方案。
6. 把事實、假設、價值偏好、意見及未知資訊分開。
7. 所有現行價格、產品功能、法規、政策與供應商承諾若未附可靠來源，一律標示待查證。
8. 不得以常識補齊缺少的成本、時程、功能、法規或資安結論。
9. 權重合計必須為100；若我未提供權重，只能提出「建議草案」，並說明理由，等待決策者確認。
10. 分數必須對應1、3、5分錨點；證據不足時填「待查」，不得填0分或自行猜分。
11. 每個分數列出理由、證據編號及信心程度。
12. 計算方式為：加權分數＝分數÷5×權重。只有已確認分數才能納入計算。
13. 不可用小數點製造不存在的精準度；總分最多保留一位小數。
14. 不得把「低信心」直接乘上一個任意折扣；需與原始分數分欄呈現。
15. 至少建立速度優先、成本優先、控制與風險優先三種情境；每種權重仍須合計100。
16. 找出權重或單一分數稍微改變就會造成排名翻轉的項目。
17. 分析各方案的可逆性、轉換成本、延後成本與被鎖定風險。
18. 將假設依「影響程度×不確定性×驗證便利性」排序，但不要捏造精準機率。
19. 為前三個關鍵假設設計低成本、有限範圍且不使用正式敏感資料的驗證。
20. 不得將最高分直接寫成最終決定；最終核准仍屬於指定決策者。
21. 保留反對意見、未解風險、附帶條件與重新檢視觸發條件。
22. 涉及法務、資安、個資、財務、採購或合約時，標示需由相應專業角色確認。
23. 請隱去姓名、Email、帳號、客戶名稱、未公開報價、憑證與機密架構細節。
24. 使用繁體中文，語氣專業、清楚、中立。

【輸出格式】

一、決策摘要
在150字內說明：要決定什麼、何時決定、目前領先方案、最大未知與下一步。若資料不足，不得宣布領先方案。

二、決策問題健檢
| 項目 | 現有內容 | 是否清楚 | 待補資料 |

三、方案完整性
| 方案 | 類型 | 核心做法 | 是否值得保留 | 理由 |

四、硬性門檻檢查
| 方案 | 門檻 | 通過／不通過／待確認／附條件通過 | 證據 | 確認人 |

五、準則品質檢查
| 準則 | 是否重疊 | 是否可衡量 | 可能偏誤 | 修正建議 |

六、事實與未知資訊
| 項目 | 事實／假設／偏好／意見／未知 | 來源 | 信心 | 待辦 |

七、基準情境決策矩陣
| 準則 | 權重 | 方案A分數 | 證據與信心 | 方案B分數 | 證據與信心 | 方案C分數 | 證據與信心 |
表後列出各方案加權總分、未計分項目及計算說明。

八、敏感度分析
| 情境 | 權重變化 | 排名 | 是否翻轉 | 主要原因 |

九、最敏感的三項變數
說明哪一項權重、分數或未知資訊最可能改變結論。

十、可逆性與延後成本
| 方案 | 可逆性 | 退出成本 | 延後成本 | 鎖定風險 | 建議承諾範圍 |

十一、關鍵假設驗證
| 優先序 | 假設 | 為何會改變決策 | 最小驗證方式 | 所需時間／資源 | 通過標準 | 負責角色 |
沒有資料時，時間與資源只能標示待估。

十二、決策建議草案
提供「建議採用」「附條件採用」「先試驗再決定」「暫緩」等可能表述，清楚說明這只是分析草案，等待決策者核准。

十三、決策紀錄草案
包含決策、理由、未採用方案、關鍵假設、附帶條件、停止條件、不同意見、複查日期與觸發事件。

十四、會議用確認問題
列出最多8題真正需要決策者回答的問題，避免重複討論已有證據的事項。

十五、人工確認清單
列出正式決定、簽約、付款、上線或處理敏感資料前必須確認的事項。

實際教學範例

情境

某團隊要決定內部「Email 轉專案待辦」工具的第一階段做法：

• 方案 A：快速原型平台
• 方案 B：現有虛擬主機自行開發
• 方案 C：公司內部伺服器自行開發
• 方案 D：維持人工整理一個月，同時完成需求驗證

目前已知：團隊擁有可用的虛擬主機與內部伺服器；但各方案的實際介接權限、導入時程、維護量及供應商條件尚未完整查證。

硬性門檻

門檻	通過標準
敏感郵件處理	未經核准不得將正式郵件內容送往外部環境
權限	可限制不同使用者能看到的專案與郵件
可追溯性	每筆匯入與修改能保留來源與時間
試行期限	能在主管確認的試行期限內完成最小可用流程

AI 整理後的關鍵發現

1. 方案 A 的「原型速度」可能較快，但目前只是待驗證假設；若使用正式郵件，還有資料處理與資安審查門檻。
2. 方案 B 與 C 都需要估算實際開發及維護量，不能因「已有主機」就把成本視為零。
3. 方案 D 能降低過早承諾的風險，但會持續產生人工整理時間與延後效益。
4. 現階段最可能改變決策的未知資訊，不是介面美觀，而是郵件權限、敏感資料邊界及最小流程的實作時間。

建議的分階段決策

先使用匿名化測試郵件，在有限範圍內驗證「郵件匯入、待辦辨識、人工確認、專案查詢」四個核心流程；同時由資訊與資安角色確認正式資料可使用的環境。完成測試結果與權限確認後，再決定正式建置方案。

這不是宣布某個平台勝出，而是先消除最會改變答案的未知資訊。

決策紀錄草案

決策：先進行 5 個工作天的匿名資料原型驗證，尚未決定正式上線平台。
範圍：僅驗證四個核心流程，不介接正式信箱。
通過條件：目標使用者能完成指定任務，且資訊與資安確認正式資料處理邊界。
停止條件：需要使用正式敏感資料才能完成原型，或必要權限無法在試行範圍取得。
複查觸發：原型結果、權限審查、維護工時估算三項資料齊備後重新比較。

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

讓 AI 直接選答案： AI 不知道組織真正願意承擔的風險。 - 硬性門檻也拿來加權： 必須符合的要求不能被其他優點抵銷。 - 先打分再定義標準： 容易讓分數服務既有偏好。 - 重複準則： 同一優點被換句話說後多次計分。 - 權重平均分配： 看似中立，實際上逃避價值排序。 - 缺資料就給零分：「未知」與「表現差」是兩件事。 - 使用過多小數： 精細算式不能彌補薄弱證據。 - 只做一種權重： 看不到結論對價值取捨有多敏感。 - 把最高分當成自動核准： 分數是討論工具，不是決策權限。 - 忽略不做與延後： 可能高估新方案帶來的淨價值。 - 沒有可逆性分析： 小型試驗與長期合約不應用同一決策節奏。 - 引用過期價格或功能： 供應商資料要標明查證日期與官方來源。 - 直接上傳正式報價： 應遮罩供應商名稱、折扣、付款條件與聯絡資料。 - 貼入客戶或員工個資： 用角色、代碼與匿名測試資料代替。 - 上傳系統架構與憑證： 不要輸入帳密、API 金鑰、內網位址或弱點資訊。 - 忽略專業審查： 法務、資安、財務與採購結論仍需權責人確認。 - 刪除不同意見： 反對意見可能指出結論最脆弱的地方，應保留在紀錄中。