以明確準則設計 Prompt 提升精準度

明確標準 prompt 設計是 Claude Certified Architect — Foundations（CCA-F）考試 Domain 4 的機械核心。任務說明 4.1——「設計具有明確標準的 prompt 以提升 precision 並降低 false positive」——錨定了一個佔比 20% 的領域，並貢獻了結構化資料 extraction 情境題中比例最高的考題。考試指南對其期待非常清楚：能夠把模糊的指令（「標記可疑交易」）改寫成可執行的標準區塊（「標記 amount > $10,000 AND merchant_country 不同於 billing_country AND 該帳戶在過去 90 天內沒有在該國家的交易記錄」）的考生，才能通過考試。把 prompt 當成散文而非規格書的考生，往往在這道任務說明上考試當天失分。

這份學習筆記完整涵蓋 CCA-F 考生必須掌握的明確標準設計面向：為何具體性能降低 hallucination、條件-閾值-行動三元組結構、正向與負向標準、數值閾值相對於定性形容詞的優勢、邊界案例列舉、classification 邊界規則、收緊標準所帶來的 precision 與 recall 權衡、針對標記邊界集的標準測試、版本管理紀律，以及欄位層級的 extraction 規則。最後的常見陷阱章節與 FAQ，將每個抽象原則連回考試從中取材最積極的結構化資料 extraction 情境。

為何明確標準重要——具體性降低 Hallucination

大型語言模型是模式補全器。當 prompt 說「標記可疑交易」，Claude 必須從其預訓練分佈中推斷「可疑」的定義——而那個分佈涵蓋了從銀行詐欺教科書、論壇奇聞，到電影情節的一切內容。缺乏明確標準，模型就以一個平均化、不可預測的定義來填補空缺，同一個 prompt 的兩次執行可能產生互不相容的結果。

明確標準收縮了這個推理空間。當 prompt 說「標記 amount > $10,000 AND merchant_country 不同於 billing_country」，Claude 就沒有任何需要自行發明的東西了。Prompt 已成為一份規格書，任何符合標準的實作——無論是人類、規則引擎或模型——都能確定性地執行。Precision 提升，因為標準縮窄了比對範圍；false positive 降低，因為過去因語意重疊而鑽空子的邊界案例，現在都被明確排除了。

CCA-F 考試一貫地獎勵四個選項中最嚴謹、最像規格書的標準。「考量交易背景並運用判斷力標記可疑項目」這樣的干擾選項聽起來很有深度，但幾乎每次都輸給「標記 amount > $10,000 AND merchant_country 不同於 billing_country AND 該帳戶在過去 90 天內沒有在該國家的交易記錄」。明確標準在考試中幾乎每次都勝過模型判斷。

模糊指令創造了「模糊預算」

Prompt 中每一個模糊詞彙——「相關」、「合理」、「顯著」、「高品質」——都會創造一個模糊預算，讓 Claude 朝其訓練先驗漂移來消耗。Prompt 中模糊詞彙越少，漂移幅度就越小。在 CCA-F 結構化資料 extraction 情境中，把「重大發現」定義為「confidence score ≥ 0.85 AND severity 屬於 {high, critical}」的 prompt，無論在 precision 還是逐次執行的穩定性上，都會優於單獨依賴「重大」這個詞彙的 prompt。

標準解剖——條件-閾值-行動三元組

每一個完整的明確標準都分解為三個部分。內化這個三元組結構，是 CCA-F 考生在 Domain 4 能做到的單一最高效益之事。

1. 條件（Condition） — 規則所測試的輸入可觀察特徵。範例：transaction.amount、document.length、message.sender_domain、address.country_code。
2. 閾值（Threshold） — 用於與條件比較的數值界限、列舉集合或模式。範例：> 10000、in {US, CA, GB}、matches /^\d{3}-\d{2}-\d{4}$/。
3. 行動（Action） — 當條件滿足閾值時觸發的決策。範例：set flag = true、加入審核佇列、略過 extraction、return confidence = low。

缺少三個部分中任何一個的標準，都是定義不完整的。「標記可疑交易」有行動（標記）但沒有條件也沒有閾值。「Amount > $10,000」有條件和閾值但沒有行動。「如果可疑就標記」有條件和行動但沒有閾值——而且「可疑」並不可觀察。

以三元組形式撰寫標準

CCA-F 等級標準區塊的建議 prompt 形狀如下：

<criteria>
  <rule id="R1">
    Condition: transaction.amount
    Threshold: > 10000 USD
    Action: add "high-value" flag
  </rule>
  <rule id="R2">
    Condition: merchant_country != billing_country
    Threshold: equality test
    Action: add "cross-border" flag
  </rule>
  <rule id="R3">
    Condition: account.prior_transactions_in(merchant_country, 90 days)
    Threshold: == 0
    Action: add "novel-geography" flag
  </rule>
  <rule id="COMBINED">
    Condition: count(flags) >= 2
    Threshold: >= 2
    Action: route to fraud review; otherwise pass through
  </rule>
</criteria>

這個形狀與三元組結構，以及 Claude 建議使用的 XML 結構化 prompt 一一對應。明確的 <rule id="..."> 鷹架對考試十分友善——把散文改寫為三元組形式的情境題，一貫地將三元組形式標記為正確答案。

正向與負向標準——同時指定該做什麼與不該做什麼

一個微妙但高頻出現的考試模式：明確標準必須涵蓋每個邊界的兩側。只說明要標記什麼，會讓 Claude 從預訓練先驗推斷不標記什麼；只說明要忽略什麼，則在另一側留下相同的空缺。

正向標準——納入規則

正向標準描述何時採取目標行動。它們將比對範圍從「Claude 認為可疑的任何事物」縮窄到「正好是這些列舉的案例」。

負向標準——排除規則

負向標準描述看似比對但必須排除的案例。沒有負向標準，Claude 的模式補全傾向就會拉入近似比對——這種行為在最重要的案例上膨脹了 false positive。

搭配正向與負向標準

生產等級的標準區塊，會針對每個敏感邊界搭配納入規則與排除規則：

<criteria>
  <include>
    Flag transactions where amount > 10000 USD AND merchant_country != billing_country.
  </include>
  <exclude>
    Do NOT flag transactions where the merchant is on the user's allowlist,
    regardless of amount or geography.
  </exclude>
  <exclude>
    Do NOT flag recurring subscription charges (same merchant, same amount,
    monthly cadence, at least 3 prior payments) even if amount > 10000 USD.
  </exclude>
</criteria>

搭配明確的納入與排除規則，是結構化資料 extraction 情境題中使用的標準模式。包含負向標準的情境答案，一貫地優於只列出正向標準的答案，因為負向標準才是真正降低 false positive 的關鍵。

標準量化——數值閾值優於定性形容詞

數值閾值是確定性的；定性形容詞是解釋性的。每一個將形容詞替換為數字的機會，就是從 prompt 中移除一個模糊預算的機會。

應避免的形容詞

以下詞彙在 CCA-F prompt 改寫題中是紅旗：

• 「高」 → 替換為明確的數值閾值（例：> 0.85）。
• 「顯著」 → 替換為可量測的幅度（例：change >= 10%）。
• 「大量」 → 替換為有單位的數值（例：document_length > 50000 characters）。
• 「近期」 → 替換為時間界限（例：within the last 7 days）。
• 「許多」 → 替換為計數（例：>= 3 occurrences）。
• 「重要」 → 替換為列舉類別（例：severity in {high, critical}）。
• 「可疑」 → 分解為條件-閾值-行動規則。

為何數字勝過形容詞

數字迫使 prompt 作者與現實協商。「高 confidence」是一種感覺；「confidence_score >= 0.85」是可測試的邊界，可根據評估指標進行調整。當工程師發現 precision 過低時，可以將數字調整到 0.90 並量測影響。「高」這個字沒有等效的校準機制。

當形容詞不可避免時

有些標準確實難以化約為數字——「文件以正式語域撰寫」、「答案離題」、「語氣不專業」。對於這些情況，正確的備用方案是以範例列舉：提供一組標記過的範例來錨定該形容詞。這正是明確標準與 few-shot prompting（任務 4.2）交會之處。標準提供規則；few-shot 範例為任何不可化約的定性部分提供校準。

邊界案例規格——在 Prompt 中列舉已知的模糊案例

即使是撰寫良好的標準區塊，也會遺漏有經驗的領域專家能發現的邊界案例。解決方法不是放寬標準——而是直接在 prompt 內列舉已知的模糊案例。

為何邊界案例屬於 Prompt

Claude 無法推斷它從未見過的邊界案例。如果你的領域經常遇到理性的人類也會意見不一的模糊輸入——一筆符合金額閾值但客戶事先已標記的交易；一個存在但為空的 extraction 欄位；一份包含目標實體但出現在引用脈絡中的文件——解決模糊性的正確地方是 prompt，而不是下游清理程式碼。

邊界案例列舉模式

<edge_cases>
  <case id="E1">
    If a transaction matches R1-R3 but the customer has a "travel notice"
    flag active for the merchant_country, DO NOT flag the transaction.
  </case>
  <case id="E2">
    If the extraction field is present in the document but the value is
    empty string, null, or whitespace-only, return { "value": null, "confidence": 0.0 }.
    Do NOT attempt to infer a value from surrounding context.
  </case>
  <case id="E3">
    If the target entity appears inside a quotation (surrounded by quote marks
    or cited as a source), extract it but mark attribution = "quoted".
  </case>
</edge_cases>

列舉的邊界案例是 CCA-F 的最愛，因為它們將隱性的領域知識轉化為明確的指令，這些指令可稽核、可測試、可版本管理。它們也能與 few-shot 範例組合使用——每個邊界案例都可配對一個標記過的範例來強化規則。

Classification 標準設計——邊界案例的決策規則

Classification 是 CCA-F 中受益於明確標準最多的任務。Classification 決策就是邊界決策；每對相鄰類別之間都有一條 prompt 必須解決的邊界。讓邊界保持隱性，就是將它交給預訓練先驗；讓它明確，就是穩定了分類器。

單一類別邊界規則模式

對於二元分類器，你需要一條能明確區分兩個類別的規則。模糊的規則（「若訊息看起來具有時效性就分類為緊急」）會失效；明確的規則（「若以下任一條件成立則分類為緊急：訊息包含『今日下班前』、訊息由 VIP 帳戶傳送、訊息提及正在發生的服務中斷」）則成功。

多類別邊界規則模式

對於 N 類分類器，你需要 N-1 條邊界規則加上優先順序。沒有優先順序，Claude 可能將輸入分配給 prompt 中第一個或最後一個列出的類別。明確的優先順序解決了這個問題：

<classification>
  <rule priority="1">
    If message contains explicit outage language (down, broken, not working)
    OR sender is a VIP account, classify as CRITICAL.
  </rule>
  <rule priority="2">
    If message asks a question that references a specific feature or workflow
    AND no CRITICAL conditions match, classify as TECHNICAL.
  </rule>
  <rule priority="3">
    If message is a thank-you, feedback, or general comment
    AND no higher-priority rule matches, classify as FEEDBACK.
  </rule>
  <rule priority="4">
    Otherwise classify as OTHER.
  </rule>
</classification>

類別定義屬於 Prompt

永遠不要假設 Claude 與你共享完全相同的類別定義。Prompt 必須包含每個類別一到兩句話的定義，以和標準相同的語言撰寫。如果你的分類器有五個類別，你的 prompt 就有五個類別定義。合計成本（幾百個 token）與 precision 的提升相比微不足道。

False Positive 降低——收緊標準以縮窄比對範圍

False positive 是 CCA-F 結構化資料 extraction 情境中被引用最多的 precision 失敗。機械性地降低它們，是收緊標準的工作。四個槓桿佔主導地位。

槓桿一：提高數值閾值

將 confidence_score > 0.70 移動到 confidence_score > 0.85，機械性地降低 false positive 率。代價是較低的 recall（某些 confidence_score 介於 0.70 到 0.85 之間的真正 positive 會被遺漏），但對於 false positive 代價高昂的工作流程——詐欺審核佇列、法律留存、合規標記——這個交換通常是值得的。

槓桿二：新增必要的 AND 條件

每一個以 AND 串接的正向標準都縮窄了比對範圍。「Amount > $10,000」捕捉到太多合法交易；「Amount > $10,000 AND merchant_country != billing_country AND 在 merchant_country 沒有先前交易」則捕捉到一個小得多、precision 高得多的集合。

槓桿三：新增負向（排除）標準

排除規則從比對範圍中剔除合法的近似案例，而不進一步限制正向側。「不標記定期訂閱費用」排除了一整類 false positive，同時不影響真正的詐欺訊號。

槓桿四：要求證據欄位

要求 Claude 回傳觸發比對的具體證據——「包含能證明比對的確切文字摘錄」、「包含滿足規則的欄位名稱」。要求提供證據能降低 hallucination 的比對，因為 Claude 無法像捏造標記那樣輕易地捏造證據。

False Negative 權衡——標準收緊時的 Precision 與 Recall

你新增的每一個標準，都同時降低了 false positive 和 true positive。這就是 precision 與 recall 的權衡，CCA-F 考試測試考生是否能認識到這一點。

Precision 與 Recall——Prompt 設計的定義

• Precision = 在 prompt 標記的項目中，有多少比例是真正正確的比對。高 precision 意味著 false positive 很少。
• Recall = 在所有真正正確的比對中，有多少比例被 prompt 標記出來。高 recall 意味著 false negative 很少。

標準鬆散到標記一切的 prompt，recall 為 100% 但 precision 很低。標準嚴格到什麼都不標記的 prompt，recall 未定義且 false positive 為零。這兩個極端之間的工作點，是商業決策，而不是模型決策。

領域成本決定工作點

嚴格標準（高 precision、低 recall）適用於 false positive 代價高昂的情況——法律審核、詐欺佇列、安全事件。寬鬆標準（高 recall、低 precision）適用於 false negative 代價高昂的情況——醫療篩查、安全關鍵警報、法規遵循。CCA-F 考試期望考生在情境答案中明確闡述這個權衡。

透過評估進行校準

沒有標記好的評估集，就無法校準 precision-recall 的權衡。正確的工作流程：

1. 在標記好的集合上執行 prompt。
2. 在當前標準下量測 precision 和 recall。
3. 調整標準（收緊或放寬）。
4. 重新執行並重新量測。
5. 反覆迭代，直到工作點符合商業需求。

這是從 prompt 設計（任務 4.1）通往驗證與重試迴圈（任務 4.4）的橋樑。明確標準給你旋鈕可以轉動；標記好的評估集告訴你要轉多遠。

標準測試——針對標記邊界案例集評估 Prompt

明確的標準區塊，只有在校準它的評估達到一定品質時才有意義。CCA-F 期望考生像對待程式碼變更一樣對待 prompt 變更：針對固定的測試集量測，並設置明確的通過/失敗閾值。

最小標記集

標準區塊可用的評估集包含：

• 30-100 個正向案例 — 應該符合標準的輸入，涵蓋典型分佈。
• 30-100 個負向案例 — 不應符合的輸入，包括過去產生 false positive 的近似案例。
• 10-30 個邊界案例 — prompt 明確處理的已列舉模糊案例，每個都標記了預期輸出。

這不是研究等級的評估；而是捕捉收緊或放寬標準時發生回歸的最小可行測試框架。

執行評估

在完整的標記集上執行 prompt。在正向/負向拆分上計算 precision 和 recall。對於邊界案例，計算精確比對準確率——prompt 是否針對每個已知模糊案例產生了預期輸出。

解讀結果

• 若 precision 過低，使用上述四個槓桿收緊標準。
• 若 recall 過低，放寬標準或鬆弛閾值。
• 若邊界案例準確率過低，表示列舉的邊界案例規則沒有被套用——精煉其措辭或新增強化用的 few-shot 範例。

評估迴圈就是設計迴圈

沒有評估迴圈的明確標準只是猜測。迴圈是：修改標準 → 執行評估 → 量測 precision/recall/邊界案例準確率 → 決定是否提交、精煉或還原。這與軟體工程單元測試的紀律相同，應用於 prompt 上。

標準版本管理——追蹤 Prompt 變更及其 Precision 影響

標準區塊是原始碼。它們屬於版本控制，需要變更歷史、程式碼審查和回滾路徑。

要版本管理的內容

• 完整的 prompt 文字，包括 system prompt、標準區塊、邊界案例和 few-shot 範例。
• 評估集（正向、負向、邊界案例，含標記）。
• 每個已提交版本的量測指標（precision、recall、邊界案例準確率）。

變更日誌紀律

每次標準變更都應有一筆記錄，記載：

• 變更了什麼（哪條規則、哪個閾值、哪個邊界案例）。
• 為何變更（哪個失敗範例、哪個利害關係人的請求、哪個商業規則更新）。
• 在評估集上變更前後量測到的 precision/recall。
• 提交雜湊值或等效的版本識別碼。

回滾是設計特性

為了回應 false positive 投訴而收緊標準，可能會無意間壓垮合法案例的 recall。沒有版本管理，就無法回滾；有了版本管理，回滾只需一個指令。提到 prompt 版本管理的 CCA-F 情境答案，一貫地優於將 prompt 視為一次性產物的答案。

Extraction 任務的標準——結構化資料的欄位層級規則

結構化資料 extraction 情境是明確標準在 CCA-F 考試上最重度發揮作用之處。結構化 extraction 意指從非結構化或半結構化輸入中提取具名欄位，並輸出符合 schema 的物件。每個欄位都值得有自己的標準區塊。

欄位層級標準

對於 extraction schema 中的每個欄位，prompt 應指定：

• 來源規則（Source rule） — 在輸入的哪裡尋找（例：「customer_name 是 header 區塊中『Customer:』後面的值」）。
• 格式規則（Format rule） — 值的預期形狀（例：「ISO 8601 日期字串」、「E.164 電話號碼」、「全大寫國家碼」）。
• 存在規則（Presence rule） — 欄位缺失時該如何處理（例：「回傳 null；不要從周圍脈絡推斷」）。
• 模糊性規則（Ambiguity rule） — 存在多個候選值時該如何處理（例：「若出現多個客戶名稱，選擇 header 中的那個；若沒有 header，回傳 null」）。

Strict Tool Use 作為強制層

明確標準產生正確的值；strict tool use 產生正確的形狀。將 extraction 定義為帶有 strict: true 的 tool call，保證 Claude 的輸出符合 JSON Schema——缺少欄位、錯誤類型和多餘的鍵都不可能出現。標準區塊管理內容；strict schema 管理結構。這兩層是組合關係——它們不是替代品。

證據連結欄位

對於需要稽核的 extraction，要求每個欄位包含支持該值的來源文字摘錄。這在標準中很便宜（「對於每個提取的欄位，包含一個 source_excerpt，其中包含輸入中支持該值的逐字文字」），且能大幅降低 hallucination 的 extraction。考試將此模式視為結構化資料 extraction 的最佳實踐。

標準如何與 Few-Shot 範例組合

明確標準與 few-shot 範例是互補的，而非競爭關係。考試一貫地測試考生是否了解這一點。

標準定義規則；範例校準規則

標準以散文或結構化形式表達決策規則。範例在具體實例中錨定規則，消除微妙邊界案例的歧義。有標準但零範例的 prompt，傾向於執行規則的字面意思但錯過精神；有範例但無標準的 prompt，傾向於過度擬合範例，並在與範例集不同的輸入上行為失常。

何時對標準新增範例

在以下情況新增 few-shot 範例：

• 標準包含不可化約的定性元素（語氣、語域、專業度）。
• 邊界案例規則有非直觀的正確輸出，受益於視覺強化。
• 輸出格式足夠複雜，以至於具體實例比散文描述更能說明。

建議的組合形狀

<instructions>
  [task description]
</instructions>
<criteria>
  [explicit rules as triplets]
</criteria>
<edge_cases>
  [enumerated ambiguous cases with rules]
</edge_cases>
<examples>
  [3-5 input/output pairs that exercise criteria and edge cases]
</examples>
<input>
  [the actual input to process]
</input>

這個順序符合 Anthropic 的公開建議：標準和邊界案例建立邏輯；範例錨定邏輯；輸入排在最後，讓最新的脈絡在注意力中最清晰。

XML 標籤不是可選的

Claude 被訓練為能解析 prompt 中的 XML 標籤。使用 <criteria>、<edge_cases>、<examples> 和 <input> 作為明確章節，相較於非結構化散文，能大幅改善標準遵守程度。考試一貫地將 XML 標籤化的 prompt 標記為正確，優於內容相同的散文 prompt。

白話說明

抽象的標準機制，一旦錨定在大多數考生已經熟悉的具體情境上，就會變得直觀。三個截然不同的類比涵蓋了明確標準設計的完整面貌。

類比一：衛生稽查員的查核表——標準作為三元組

想像一位衛生稽查員走進一間餐廳廚房。一個模糊的稽查員四處走動說「標記任何不衛生的地方」。兩個稽查員對「不衛生」的認定會持續不一致，同一個稽查員在不同天也可能做出不同的結論。一個專業稽查員帶著查核表：「若熟肉的表面溫度低於 60°C 則標記」（條件 + 閾值 + 行動）；「若生雞肉存放在即食食品上方則標記」（條件 + 閾值 + 行動）；「不標記不鏽鋼上能擦掉的輕微水漬」（負向標準）。查核表將稽查從解釋性的藝術轉化為可重現的程序。兩個使用相同查核表的稽查員產生相同的報告。明確標準對 Claude 做的事，正是查核表對稽查員做的事：它們以可觀察的規則取代解釋性判斷，這就是 precision 改善、逐次執行的差異縮小的原因。CCA-F 考試獎勵能為模糊指令撰寫出查核表版本的考生。

類比二：機場安全檢查線——Precision、Recall 與權衡

機場安保是一個活生生的 precision 與 recall 實驗。寬鬆的檢查政策讓所有人快速通過（非威脅的 recall 高、false positive 為零，但真正的威脅溜走——威脅偵測的 precision 低）。嚴格的政策仔細審查每位旅客（威脅的 precision 高，但許多無辜旅客被標記——非威脅快速通過的 recall 低）。安保主管必須根據每種錯誤類型的成本選擇工作點：錯失威脅的成本相對於誤報的成本。政策將工作點表達為明確標準：「若以下任一條件成立，旅客進入二次篩查——液體超過 100ml、金屬超過 X 克、隨機抽查，或列於觀察名單」。這些就是條件-閾值-行動三元組。當新威脅出現，標準收緊（降低閾值、新增條件）；當排隊過長的投訴增加，標準放寬。Claude 的 prompt 工程師面對著相同的經濟體：收緊標準以犧牲 recall 為代價降低 false positive；放寬標準以犧牲 false positive 為代價提高 recall。CCA-F 考試希望考生闡明這個權衡，而非將收緊視為免費的勝利。

類比三：藥師的處方核查——邊界案例與排除規則

藥師收到一張處方並必須決定是否配藥。正向標準：「處方有有效簽名、患者 ID 相符、藥物有庫存、劑量在指引範圍內」。負向標準：「若患者正在使用禁忌藥物則不配藥；若劑量超過依體重調整的最大值則不配藥；若保險拒絕申請則不配藥」。藥師曾見過的邊界案例：「若處方劑量看起來不尋常，但開立處方的醫師是這個病症的已知專科醫師，配藥前先致電確認——不要直接拒絕」。這每一項都對應到一個 prompt 模式。正向標準是納入規則。負向標準是排除規則。邊界案例是帶有明確解決方案的列舉規則。持續遵循這些書面規則的藥師，比只依賴經驗的藥師犯更少錯誤，因為書面規則可稽核、可傳授給新員工，且在新的安全資訊出現時可更新。帶有明確標準的 prompt 行為方式完全相同——它們產生可稽核、precision 最佳化的輸出，審閱者可追溯到具體規則。

考試當天選用哪個類比

• 關於標準結構的題目 → 衛生稽查員查核表類比。
• 關於收緊標準與權衡的題目 → 機場安保類比。
• 關於邊界案例與排除規則的題目 → 藥師類比。

常見考試陷阱

CCA-F Domain 4 持續利用五種圍繞明確標準設計的反覆出現陷阱模式。所有五種都以合理的干擾選項形式偽裝出現在結構化資料 extraction 情境中。

陷阱一：「更多標準永遠更好」

過度規格化導致脆弱性。有 40 條標準的 prompt 在訓練範例上的標記率會高於有 4 條標準的 prompt，但它也會在任何不符合 40 個預期形狀之一的輸入上出現災難性的行為失常。CCA-F 考試一貫地將「新增更多規則」標記為錯誤答案，當情境涉及偏離訓練分佈的輸入時。正確答案通常是將標準保持嚴格但精簡，讓 few-shot 範例涵蓋長尾。

陷阱二：明確標準取代 Few-Shot 範例

它們不能。標準與範例是互補的，兩者都應出現在 CCA-F 等級的 prompt 中。用更多標準取代 few-shot 範例的 prompt，失去了錨定定性術語的範例校準；用更多 few-shot 範例取代標準的 prompt，失去了讓新輸入可預測的規則式確定性。明確保留標準和範例兩者的 CCA-F 情境答案，一貫地優於偏向其中之一的答案。

陷阱三：偽裝成標準的模糊形容詞

「高 confidence」不是標準。「顯著影響」不是標準。「可疑行為」不是標準。情境干擾選項頻繁地將模糊形容詞包裝在類似標準的語法中——<rule>標記任何顯著的東西</rule>——並將其作為「明確標準」選項提供。它不是。正確答案將形容詞替換為數值閾值或列舉類別。

陷阱四：只有正向標準而無排除規則

以「降低 false positive」為目標的情境題，通常會提供一個收緊正向標準但不新增排除規則的選項。這個選項在邊際上改善 precision，但輸給將相同正向標準與已知近似案例的明確排除規則搭配的選項。在 CCA-F 上，當明確目標是降低 false positive 時，帶有排除規則的答案幾乎每次都勝出。

陷阱五：標準變更未經評估或版本管理

詢問「收緊標準後下一步該做什麼」的情境題，通常會將「立即部署」作為干擾選項提供。正確答案是針對標記的評估集執行已收緊的標準、量測 precision 和 recall，並在部署前將 prompt 版本化。將 prompt 視為一次性產物的行為會被扣分；將其視為版本化程式碼的行為會得到獎勵。

練習錨點

明確標準設計在六個 CCA-F 情境中的一個出現最密集。將以下內容視為情境叢集題的架構骨幹。

結構化資料 Extraction 情境

在這個情境中，一條 pipeline 吸收文件（發票、醫療記錄、合約、支援票）並將具名欄位 extract 到結構化 schema 中。預期會有題目測試你是否能：

• 將模糊的 extraction 指令（「提取關鍵欄位」）改寫為帶有來源、格式、存在和模糊性規則的欄位層級標準。
• 將正向納入標準與近似欄位的明確排除規則搭配。
• 將「重要」或「顯著」等形容詞替換為數值閾值或列舉類別。
• 在 prompt 內列舉已知的邊界案例（空欄位、引用實體、多比對輸入）。
• 將明確標準與 strict: true tool use 組合以保證 schema 符合。
• 在部署標準變更前，將 prompt 版本化並執行標記的評估集。

Customer-Support-Resolution-Agent 情境

Customer-Support 情境在 agent 必須對票務分類、偵測緊急程度或決定何時升級時，使用明確標準。預期會有題目測試帶優先順序排序的 classification 規則設計、明確的緊急閾值（而非主觀的「看起來緊急」啟發式方法），以及列舉的升級觸發條件（而非 Claude 判斷式的升級）。相同的條件-閾值-行動三元組結構同樣適用。

Multi-Agent-Research-System 情境

Multi-Agent-Research 情境在 subagent 決定什麼構成「充分的答案」或「高品質的來源」時使用明確標準。預期會有題目測試答案品質標準是否作為明確規則拼寫出來（最少引用來源數量、最低 confidence score、必要的證據欄位），而非留給 subagent 判斷。在 subagent prompt 層級的明確標準，是防止研究 pipeline 中品質漂移的手段。

FAQ——明確標準設計前五大問題

為何明確標準在 CCA-F 情境答案上優於自然語言指令？

明確標準收縮了 Claude 否則會用預訓練先驗填補的模糊空間。像「標記可疑交易」這樣的自然語言指令，需要 Claude 推斷「可疑」的定義；兩次執行可能產生不同的定義，因為推斷是欠定的。明確標準——amount > 10000 AND merchant_country != billing_country AND 在該國家 90 天內沒有先前交易——沒有任何需要推斷的東西。Precision 提升，因為比對範圍更窄；一致性提升，因為規則是確定性的；可稽核性提升，因為審閱者可以對照每條規則核查每個輸入。以條件-閾值-行動三元組形式呈現明確標準的 CCA-F 情境答案，一貫地優於依賴模型判斷的答案。

如何在收緊標準與失去 recall 之間取得平衡？

收緊標準從來不是免費的改善——你新增的每條規則都同時降低了 false positive 和某些 true positive。平衡是商業決策，由每種錯誤類型的成本驅動。對於 false positive 代價高昂的佇列（法律審核、詐欺調查、安全事件），積極收緊。對於 false negative 代價高昂的工作流程（醫療篩查、法規遵循），保持標準較寬鬆，並依賴下游人工審核來捕捉 false positive。校準需要標記的評估集：在當前標準下量測 precision 和 recall、調整、重新量測。明確命名這個權衡的 CCA-F 情境答案（例如「收緊這些標準將改善 precision，但可能降低 recall；在標記的評估集上監控」）一貫地優於將收緊視為無條件勝利的答案。

明確標準應該取代我的 few-shot 範例嗎？

不。標準和範例是互補的，兩者都應出現在 CCA-F 等級的 prompt 中。標準以結構化形式定義決策規則；範例校準規則中任何殘留的定性元素，並以具體形式展示輸出格式。有標準但無範例的 prompt，傾向於執行規則的字面意思但錯過微妙的格式慣例；有範例但無標準的 prompt，傾向於過度擬合範例並在不同的輸入上行為失常。建議的形狀是兩者交織：標準加邊界案例規則加 3-5 個 few-shot 範例，全部以 XML 標籤包裝。CCA-F 考試一貫地將同時保留標準和範例的答案標記為正確，優於偏向其中之一的答案。

如何處理我的標準無法解決的已知模糊案例？

直接在 prompt 中將模糊案例列舉為明確的 <edge_cases> 條目。對於每個案例，指定識別該案例的條件（「若一筆交易符合金額閾值，但客戶對 merchant_country 有有效的旅遊通知」），以及明確的解決方案（「不標記該交易；改而在輸出中設置 travel_notice_overrode_flag = true」）。列舉的邊界案例將隱性的領域知識轉化為可稽核的 prompt 指令。CCA-F 考試一貫地偏好此模式，優於擴展主要標準區塊或在下游程式碼中處理案例的方案。邊界案例屬於 prompt，因為那是 Claude 能套用它們的地方；隱藏在後處理中的邊界案例，仍然讓 Claude 產生不正確的中間輸出。

生產標準區塊的最低評估紀律是什麼？

標準區塊的最小可行評估框架包含 30-100 個標記好的正向案例、30-100 個標記好的負向案例（包含過去造成 false positive 的已知近似案例），以及 10-30 個對應到列舉的 <edge_cases> 規則的標記好邊界案例。在完整集合上執行 prompt，在正向/負向拆分上計算 precision 和 recall，並在邊界案例上計算精確比對準確率。每次標準變更都伴隨一次評估重跑，以及記錄變更前後指標的提交。將 prompt、評估集和量測結果一起版本化。提議在未重跑評估的情況下部署標準變更的 CCA-F 情境答案，一貫地被標記為錯誤；包含評估迴圈和版本提交的答案，被標記為考試獎勵的成熟工程回應。

延伸閱讀

• Prompt engineering overview: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
• Use examples (multishot prompting) to guide Claude's behavior: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/multishot-prompting
• Increase output consistency — structured outputs: https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/increase-consistency
• Use XML tags to structure your prompts: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/use-xml-tags
• Strict tool use — schema-guaranteed output: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/strict-tool-use
• Claude 4 prompting best practices: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/claude-4-best-practices

Related ExamHub topics: Few-Shot Prompting for Output Consistency and Quality, Structured Output with Tool Use and JSON Schemas, Validation, Retry, and Feedback Loops for Extraction Quality, Multi-Instance and Multi-Pass Review Architectures.