本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

自動化推理政策最佳實務

此頁面會合併建立和維護自動化理由政策的最佳實務。在建立第一個政策之前，請先閱讀此內容，並在偵錯問題時回頭參考。如需這些實務背後的概念基礎，請參閱 自動化理由檢查概念。如需step-by-step建立說明，請參閱 建立自動推理政策。

開始簡單並反覆執行

建立自動推理政策時最常見的錯誤是嘗試以單一傳遞擷取整個複雜的文件。反之，請從規則的重點子集開始，並逐步建置。

這種方法有兩個優點：它可以更輕鬆地隔離問題 （您知道哪個區段引入了問題），並在開發期間保持可管理政策。具有 10 個經過良好測試規則的政策比具有 100 個未經測試規則的政策更有用。

使用 LLM 預先處理文件

對於冗長、包含敘述性內容的文件，或將規則與非規則內容 （例如法律免責聲明或組織背景） 混合，請在將文件上傳至自動化理由檢查之前，透過 LLM 執行文件。要求 LLM 依明確的 if-then 規則擷取內容。此預先處理步驟可大幅改善擷取政策的品質，因為自動化原因檢查最適合使用清晰的宣告式陳述式，而非非結構化文字。

撰寫您的預先處理提示時，請包含 LLM 的下列指示：

如需詳細的提示範本和step-by-step預先處理工作流程，請參閱 （選用） 使用 LLM 將文件重寫為邏輯規則。

使用影響 (=>) 來建構規則

if-then 格式 => （使用隱含運算子） 是最重要的單一規則撰寫模式。每個表達條件關係的規則都應使用此格式。

裸露聲明 （沒有 if-then 結構的規則） 會建立軸線 — 一律為 true 的陳述式。宣告eligibleForParentalLeave會告知自動理由檢查，無論任何條件為何，父系休假資格一律為 true。任何指出使用者不符合條件的輸入都會傳回，IMPOSSIBLE因為它會與此軸矛盾。

裸露聲明僅適用於應一律保留的邊界條件，例如：

;; Account balance can never be negative
(>= accountBalance 0)

;; Interest rate is always between 0 and 1
(and (>= interestRate 0) (<= interestRate 1))

如果您在擷取的政策中發現裸露聲明，請將它們重寫為條件式或刪除。如需檢閱解壓縮政策的詳細資訊，請參閱 檢閱解壓縮的政策。

撰寫完整的變數描述

變數描述是轉譯準確度的主要因素。自動化推理檢查將自然語言轉換為正式邏輯時，會使用變數描述來判斷哪些變數對應至文字中提到的概念。模糊或不完整的描述是TRANSLATION_AMBIGUOUS結果的頭號原因。

良好的變數描述應回答四個問題：

範例：前後

針對非專屬狀態使用布林值

建立可共存的狀態模型時，請使用不同的布林值變數，而非單一列舉。一個人可以是資深人員和老師。使用列舉會在兩者之間customerType = {VETERAN, TEACHER}強制選擇，並在兩者套用時建立邏輯衝突。

預留列舉給真正互斥的類別，其中一次只能套用一個值，例如 leaveType = {PARENTAL, MEDICAL, BEREAVEMENT}（員工一次只能請求一種休假）。如需自訂類型的詳細資訊，請參閱 自訂類型 （列舉）。

在變數描述中指定單位和格式

單位的模棱兩可性是翻譯錯誤的常見來源。如果使用者說「我在這裡工作了 2 年」且您的變數是 tenureMonths，則翻譯需要知道 才能將年轉換為月。如果您的變數描述未指定單位，則翻譯可能會指派 tenureMonths = 2而非 tenureMonths = 24。

一律指定：

範例：

驗證數值的範圍

對於數值變數，新增限制有效範圍的邊界規則。這可防止邏輯上不可能的情況，並協助自動化合理性檢查產生更有意義的結果。

;; Account balance cannot be negative
(>= accountBalance 0)

;; Interest rate must be between 0 and 1 (0% to 100%)
(and (>= interestRate 0) (<= interestRate 1))

;; Credit score ranges from 300 to 850
(and (>= creditScore 300) (<= creditScore 850))

;; Tenure in months cannot be negative
(>= tenureMonths 0)

如果沒有這些界限規則，自動推理檢查可能會考慮帳戶餘額或點數超過 1000 的負面案例，這在您的網域中沒有意義。邊界規則是裸露聲明 （規則不是 if-then 格式） 適用的少數案例之一。

使用中繼變數進行抽象化

當多個規則共用共同條件時，請將該條件擷取至中繼布林值變數。這可簡化您的規則，並使政策更容易維護。

範例：成員資格方案

而不是在每個利益規則中重複成員資格條件：

;; Without intermediate variable (repetitive)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForFreeShipping)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForPrioritySupport)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForEarlyAccess)

定義中繼變數並參考它：

;; With intermediate variable (cleaner)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) isPremiumMember)
(=> isPremiumMember eligibleForFreeShipping)
(=> isPremiumMember eligibleForPrioritySupport)
(=> isPremiumMember eligibleForEarlyAccess)

此模式可讓您稍後更輕鬆地更新成員資格條件，您只需變更一個規則，而不需要變更三個規則。

使用列舉進行分類

當變數代表具有一組固定互斥值的類別時，請使用自訂類型 （列舉），而不是多個布林值或字串。列舉會限制可能的值，並讓規則更清楚。

保持邏輯宣告，而非程序性

自動化推理政策說明什麼是 true，而不是如何運算它。避免編寫類似具有循序步驟或優先順序邏輯之程式碼的規則。

同樣地，請避免規則之間的編碼優先順序或優先順序。在正式邏輯中，所有規則會同時套用。如果您需要表達某個條件覆寫另一個條件，請在規則條件中明確編碼：

;; GOOD: Explicit exception handling
;; General rule: full-time employees with 12+ months get parental leave
(=> (and isFullTime (> tenureMonths 12) (not isOnProbation))
    eligibleForParentalLeave)

;; BAD: Trying to encode precedence
;; "Rule 1 takes priority over Rule 2" — this concept doesn't exist
;; in formal logic. Instead, combine the conditions into a single rule.

命名慣例

一致的命名可讓政策更易於讀取、維護和偵錯。請遵循下列慣例：

避免可能模棱兩可的縮寫。使用 tenureMonths而非 tenMo，以及 isFullTime 而非 ft。清除名稱有助於人工檢閱者和翻譯程序。

常見的反模式

下列模式經常導致自動化合理化政策中的問題。如果您遇到非預期的測試結果，請檢查您的政策是否包含任何這些反模式。

軸線而非含意

如 中所述使用影響 (=>) 來建構規則，裸露聲明會建立一律為 true 的軸線。這是最常見的反模式和最具破壞性 — 它讓整個類別的輸入傳回 IMPOSSIBLE。

徵狀：應IMPOSSIBLE改為傳回VALID或INVALID傳回的測試。

修正：在您的規則中尋找裸露聲明，並將其重寫為含意，如果它們不代表界限條件，則將其刪除。

重疊變數

有兩個代表相同或類似概念的變數 （例如 tenureMonths和 monthsOfService) 會混淆轉譯程序。自動化理由檢查無法判斷用於指定概念的變數，導致不一致的轉譯和TRANSLATION_AMBIGUOUS結果。

徵狀：TRANSLATION_AMBIGUOUS即使輸入文字清晰不明確，測試也會傳回。

修正：將重疊變數合併為具有完整描述的單一變數。更新參考已刪除變數的所有規則。

過於複雜的政策

具有太多變數、深度巢狀條件或非線性算術的政策可能會超過處理限制並傳回TOO_COMPLEX結果。

徵狀：測試傳回TOO_COMPLEX或逾時。

修正：簡化政策。移除未使用的變數，使用中繼變數將複雜的規則分解為較簡單的變數，並避免非線性算術 （指數、不合理數字）。如果您的網域真的複雜，請考慮將其分割成多個聚焦政策。

矛盾的規則

相互矛盾的規則使得自動推理檢查無法得出結論。例如，一個規則表示全職員工符合休假資格，另一個規則則表示第一年的員工不符合資格，而不指定第一年全職員工會發生什麼情況。

徵狀：測試IMPOSSIBLE傳回涉及衝突規則的輸入。

修正：檢查品質報告是否有衝突的規則。將規則合併為具有明確條件的單一規則，或刪除其中一個衝突規則，以解決衝突。如需詳細資訊，請參閱檢閱解壓縮的政策。

未使用的變數

任何規則未參考的變數都會將雜訊新增至轉譯程序。轉換可能會將值指派給未使用的變數，浪費處理容量，並可能在未使用的變數與類似的作用中變數競爭時產生TRANSLATION_AMBIGUOUS結果。

徵狀：非預期TRANSLATION_AMBIGUOUS的結果，或將值指派給不影響任何規則之變數的轉譯。

修正：刪除未使用的變數。在 主控台中，尋找變數旁的警告指標。透過 API，GetAutomatedReasoningPolicyBuildWorkflowResultAssets使用 從 檢查品質報告--asset-type QUALITY_REPORT。

缺少列舉值

如果您的列舉未包含使用者可能提及的每個可能類別的值，則當輸入不符合任何定義的值時，轉譯可能會失敗或產生非預期的結果。

徵狀：測試傳回TRANSLATION_AMBIGUOUS或輸入提及不在列舉中的類別NO_TRANSLATIONS時。

修正：將 OTHER或 NONE值新增至列舉，以處理不符合已定義類別的輸入。更新列舉值描述，以釐清何時套用每個值。