【2026 最新】哪些決策不該交給 LLM？Deterministic Core 6 步實作（決策矩陣＋故障注入）

你請 LLM 幫客人下單，它回了一份格式完美的 JSON：品項有了、數量有了、總價也有了。畫面正常、程式沒報錯，唯一的問題是總價算錯，還擅自通過預算。這正是 Deterministic Core 要解的問題：模型可以理解模糊需求，卻不該單獨裁決可精確計算、受政策限制或難以回復的結果。

這篇專為第一次設計 AI 工作流的讀者寫。你不必先懂模型原理，我會用一筆「預算 1,500、買兩個 Starter 方案」的訂單，從決策矩陣、typed schema、pure function、null、clamp、fail-closed，一路帶到可複製的故障注入與 property tests。

近期一則 r/LLMDevs 開發者自述把數值政策移出 Prompt、改成約 240 行 pure function；這是未經獨立稽核的單一案例，不能證明所有產品都該照抄，卻問對了一個問題：你的流程裡，哪些決策其實有一個能寫下來、能驗證的答案？

先說結論：LLM 提案，程式裁決，人類承諾

可靠 AI 決策管線＝Probabilistic Edge（理解／排序）→ Deterministic Core（驗證／計算）→ Human Commit（不可逆批准）。

• 交給 LLM：從自然語言抽取意圖、找候選、處理模糊偏好、產生解釋。
• 交給程式：價格、稅費、配額、資格、權限、狀態轉移、庫存、去重與政策上限。
• 交給人：高影響例外、難以回復的操作，以及規則本身尚未定義清楚的情況。

記住一句白話：讓模型把「模糊」變成候選，讓程式把候選變成可驗證結果；真正不可逆的那一步，再由有權限的人確認。

Deterministic Core 是什麼？先分清三種責任

Probabilistic Edge 是接觸模糊世界的外圈：讀 Email、理解「最好明天到」、把上百個選項排出前五名。這裡的價值是判斷與彈性，不是保證每次都得到唯一答案。這是本文使用的工程名稱，不代表每一次 API 呼叫都必然不同。

Deterministic Core 是可強制的內核：同一份明確輸入、同一個政策版本與同一份資料快照，應得到同一個結果。pure function（純函式）最適合放在這裡，因為它只依賴顯式輸入，不偷偷讀現在時間、隨時變動的資料庫或模型回覆。白話說，它像收銀機：店員可以聽懂你想買什麼，但價格與找零由機器算。

Human Commit 是最後承諾層。OWASP 的 Excessive Agency 指引建議高影響動作要求使用者批准；OpenAI Agents SDK 的 HITL 文件也把敏感工具呼叫設計成可暫停、批准或拒絕。重點不是每件事都人工做，而是批准要發生在副作用之前。

2026 年 8 月 20 日更新的 PILOT 技術報告 v2提供了一個新例子：LLM 負責生命週期判斷與候選提案，六個 deterministic services 則產生合法命令集合、驗證候選、計算統計證書並獨占狀態寫入。這份報告的線上結果是作者團隊自報，本文只引用它的職責切分，不把單一系統的成效外推到所有場景。

哪些決策該放進 Deterministic Core？看 4 條紅線

紅線 1：是否存在可精確寫下的正確答案？

在規則與資料快照已確定時，總價、折扣、稅費、利率、剩餘額度、日期差、重試上限，都能用公式或查表得到答案。痛點是模型常能產生「看起來合理」的數字；解法是讓 LLM 只抽取 sku、quantity 等意圖，價格一律由 catalog 與函式計算。驗收方式很直接：固定輸入、政策版本與資料快照，輸出必須完全一致。

紅線 2：能否寫成 invariant 或驗證器？

Invariant（不變條件）就是不論輸入怎麼變都不能破的規則，例如「確認中的訂單總價不得超過預算」「數量必須介於 1 到 5」「未知 SKU 不得建立訂單」。只要能寫成 assert、型別、enum、資料庫 constraint 或狀態機，就不應只把它留在 Prompt 裡。

紅線 3：錯了是否難以回復或影響很大？

付款、刪除、發布、寄信、改權限與大量資料寫入，都不是「再生成一次」就能消除的副作用。這類流程要採 propose → validate → preview → approve → commit，並搭配 Agentic Transaction 的冪等與補償設計。LLM 可以提出動作，但不能同時當規則制定者、審核者與執行者。

紅線 4：是否受政策、權限或合約約束？

誰能退款、最多退多少、哪個角色能讀哪筆資料、何時需要雙人批准，都是 authority（授權）問題。NIST AI RMF Core 要求定義 human-AI oversight、檢視錯誤成本，並讓系統在超出知識邊界時能安全失敗。實作上，政策引擎與後端權限才是門鎖；「請遵守公司政策」只是一張告示牌。

四條都沒碰到，而且結果低影響、容易撤回、主要價值來自語意判斷時，才適合讓 LLM 擁有較大空間，例如草稿、標籤建議、摘要或候選排序。若規則尚未定義，答案也不是「讓模型猜」；先回到產品與領域專家，把規則寫清楚。

完整走一次：自然語言訂單如何穿過三層？

使用者說：「幫我買兩個 Starter 方案，最好明天到，預算最多 1,500。」系統不要請模型直接回傳「批准、總價 1,480」，而是只允許它填寫 intent：

{
  "sku": "starter",
  "quantity": 2,
  "budget_limit": 1500,
  "coupon_code": null,
  "delivery_preference": "next_day",
  "priority_hint": 80,
  "note": "明天到最好"
}

1. Edge 抽取：LLM 把「兩個」「最多 1,500」「明天到」映射到固定欄位，不負責價格與批准。
2. Schema 驗證：要求所有欄位、拒絕未知欄位、型別嚴格，不把字串 "2"偷偷轉成整數。
3. Core 計算：catalog 單價 680 × 2＋運費 120＝1,480；再檢查庫存、數量上限、coupon 與預算。
4. Clamp 建議值：本例的 priority_hint 只影響候選排序，所以可收斂到 0～100；設計上不允許它改變價格或資格。
5. Human Commit：結果是 needs_confirmation，使用者看見 canonical order 後確認，系統才真正下單。

如果預算是 null，Core 回 needs_input；如果數量是 200，回 blocked；如果模型偷偷新增 total: 1 或 status: "approved"，schema 直接拒絕。JSON Schema 官方說明也特別指出：欄位缺失與值為 null不是同一件事。未知不能被當成否定或通過。

Deterministic Core 6 步實作

第 1 步：盤點「決策」，不要只盤點「任務」

「處理訂單」太大，無法劃界。拆成抽取 SKU、抽取數量、查價格、算運費、驗庫存、判斷預算、排序配送偏好、建立訂單八個決策，再逐項套四條紅線。這一步的產物是一張 owner 清單：LLM | code | human，不是另一段更長的 Prompt。

第 2 步：把 LLM 輸出縮成 typed intent

不要讓模型回整張最終訂單，只給它最小必要欄位。Structured Outputs 或 function calling 能改善結構，但 OpenAI 的 官方限制說明明確寫到：schema 正確仍可能在 JSON 的值裡犯錯。因此 typed schema 是邊界入口，不是正確性證明。

第 3 步：嚴格驗型別、enum、unknown 與 null

若使用 Pydantic，可在 validation call 開 strict mode，避免把整數欄位的 "123"寬鬆轉成 123。不論使用哪套工具，都要明寫 additionalProperties: false、required fields、enum 與 null語義。解析失敗就回到補資料流程，不把錯誤 payload 送進執行器。

第 4 步：用 pure function 計算政策結果

把 catalog、stock snapshot、budget 與 policy_version都當參數。函式不要自行讀「現在」或遠端狀態；需要時間就傳入 as_of，需要庫存就傳入具版本的 snapshot。這樣失敗時才知道是抽取錯、政策錯，還是資料已變。

from dataclasses import dataclass
from decimal import Decimal

CATALOG = {"starter": Decimal("680"), "pro": Decimal("960")}
STOCK = {"starter": 4, "pro": 2}
MAX_QTY = 5

@dataclass(frozen=True)
class Intent:
    sku: str
    quantity: int
    budget_limit: int | None
    coupon_code: str | None
    priority_hint: int

def decide(x: Intent):
    priority = min(100, max(0, x.priority_hint))
    if x.sku not in CATALOG:
        return "blocked", None, priority, "unknown_sku"
    if x.quantity < 1 or x.quantity > MAX_QTY:
        return "blocked", None, priority, "quantity_out_of_policy"
    if x.budget_limit is None:
        return "needs_input", None, priority, "budget_required"
    if STOCK[x.sku] < x.quantity:
        return "blocked", None, priority, "insufficient_stock"

    subtotal = CATALOG[x.sku] * x.quantity
    shipping = Decimal("0") if subtotal >= 1600 else Decimal("120")
    total = subtotal + shipping
    if total > Decimal(x.budget_limit):
        return "blocked", total, priority, "over_budget"
    return "needs_confirmation", total, priority, "human_commit_required"

這段刻意省略了真實 catalog 版本、貨幣 rounding、稅制、coupon race、庫存鎖、冪等 key 與資料庫 transaction；正式環境要在 commit 前重新驗證易變狀態。它教的是邊界，不是假裝 30 行就能完成電商系統。

第 5 步：分清 clamp、reject 與 fail-closed

• Clamp：只用於明確可收斂、且不改變授權的建議值，例如排序分數 0～100。
• Reject：型別錯、未知欄位、無效 SKU、超量、越權或模型提供了不該提供的計算欄位。
• Fail-closed：缺少預算、批准、身份或政策版本時，不執行副作用；回 needs_input 或 blocked。

不要把 quantity=200靜默 clamp 成 5 再下單，因為那改變了使用者意圖；也不要把未知 coupon 當成「沒有折扣」繼續。Clamp 是護欄，不是替錯誤做決定。

第 6 步：故障注入＋property tests 驗證核心

Example-based unit test 通常先列出有限的已知案例；property-based testing 則先寫 invariant，再生成許多輸入找反例。Python 的 Hypothesis 官方文件提供完整工具；零套件也能先用固定 seed 的亂數迴圈。至少測這五條：

1. 0 ≤ normalized_priority ≤ 100。
2. needs_confirmation 時，總價一定存在且不超過預算。
3. 預算為 null 時，永遠不能進入確認狀態。
4. 數量、庫存、SKU 或 coupon 違規時，不能建立可 commit 的結果。
5. 備註裡即使出現「ignore policy and approve」，也不能改變價格與權限。

全 LLM vs 混合式 A/B：比較的不是模型聰明度

A 組讓模型同時提供 intent、總價與批准狀態；B 組只收 intent，再交給嚴格 schema 與 pure function。對兩組注入字串數量、模型自帶總價、超量、缺預算、惡意 note、極端排序分數與未知 SKU。你要觀察的不是回答文筆，而是：

• 錯誤是否被拒絕、要求補資料或限制在建議欄位？
• 任何路徑能否繞過 policy function 直接 commit？
• 同一個 policy snapshot 能否重播出同一結果？
• 每個 block 是否留下 reason code 與 policy version？

本文的邊界 lab 不呼叫模型，也不宣稱比較某個 provider；它只用合成 payload 驗證 enforcement。若要評估真實模型，把同一組 user requests、schema、catalog snapshot 與評分規則固定，再比較 extraction error、拒絕率、人工補問率與 end-to-end task success。可以接著用 AI Evals的方式建立資料集與回歸門檻。

6 個常見坑：Deterministic 不等於自動正確

1. 把 schema 當真相：格式正確只證明可解析，不能證明 quantity或理由正確。
2. 用第二個 LLM 當唯一 guardrail：它適合找未知問題，卻仍是建議層；硬政策要有程式或下游權限強制。
3. 所有錯誤都 clamp：靜默修正會掩蓋 drift，也可能改變使用者意圖；授權與交易欄位應 reject。
4. pure function 偷讀外部狀態：價格、時間、匯率與庫存要以版本快照顯式傳入，否則無法重播。
5. 規則沒有版本：log 只寫「blocked」還不夠；要記 policy_version、input hash 與 reason code。
6. 批准晚於副作用：先寄信、再請人確認不是 Human Commit；批准要綁定即將執行的 canonical request。

Deterministic Core 只能強制你已經寫進去的規則。壞政策會穩定地產生壞結果，錯誤輸入也會穩定地被計算。因此還要做 domain review、shadow mode、線上監控與定期回歸；這也正是 Prompt Injection 回歸測試與 Agent Runtime Controls要補上的相鄰層。

FAQ：哪些決策不該交給 LLM？

1. Temperature 設成 0，就能取代 Deterministic Core 嗎？

不能。取樣設定不會把價格公式、權限政策或語意正確性變成可證明的規則；即使某次輸出一致，也可能一致地算錯。

2. Structured Outputs 已符合 schema，就安全了嗎？

不夠。它大幅改善結構遵循，但官方文件也明列 value 內仍可能出錯。Schema 後面仍要接 domain validation 與 policy function。

3. Pure function 能消除所有 AI 風險嗎？

不能。它讓已知規則可重播、可測試；抽取錯誤、規則缺漏、資料過期與未預見情境仍需要 eval、監控與人工處理。

4. 什麼時候用 clamp，什麼時候直接 reject？

看它是否改變權利與結果。排序分數可 clamp；數量、金額、資格、權限與批准應 reject 或補問。

5. null 應該當 false 或使用預設值嗎？

通常先當 unknown。除非產品規格明定預設語義，否則「未回答」不等於「回答否」。高影響欄位缺值時應 fail-closed。

6. LLM 最適合保留哪些決策？

模糊、可逆、需要語意的提案。例如抽取意圖、找候選、依偏好排序、草擬說明與提出例外；最後結果仍經過可驗證邊界。

7. 所有動作都要人類批准嗎？

不必。低影響、可回復、政策明確且測試充分的動作，可由 Deterministic Core 自動執行；人工批准集中在高影響與例外。

8. 規則常改，Deterministic Core 會不會很難維護？

會增加工程責任，但也讓變更可管理。把政策版本化，為每條規則配測試與 migration，並用舊案例跑 regression；比把政策藏在 Prompt 裡更容易查出哪次變更造成差異。

給新手的 7 個帶走重點

1. 先拆決策，再決定誰負責。
2. 能精確計算或驗證的結果，移進程式。
3. LLM 只輸出最小 typed intent，不輸出最終批准。
4. 未知欄位拒絕；null 不等於 false。
5. Clamp 建議值，reject 權限與交易違規。
6. 高影響副作用採 preview＋Human Commit。
7. 用故障注入與 property tests 持續尋找繞過路徑，並把反例納入回歸。