Few-Shot Prompting 提升輸出一致性

Few-shot prompting 是 CCA-F 考生被要求能夠實際運用的最高效能 prompt 工程技術。CCA-F 考試任務說明 4.2——「運用 few-shot prompting 提升輸出一致性與品質」——隸屬於 Domain 4（Prompt Engineering 與結構化輸出，佔比 20%），與明確標準設計（4.1）、透過 tool use 實現結構化輸出（4.3）和驗證重試迴圈（4.4）並列。Few-shot prompting 是在不修改程式碼、不調整模型、不新增基礎設施的前提下，最能可靠提升輸出品質的技術——也正因為它的效果如此顯著，考試反覆測試考生是否真正理解「何時」、「怎麼做」以及「放幾個範例」。

這份學習筆記帶你走過 CCA-F 考生必須在架構層級掌握的完整 few-shot 面向：few-shot prompting 作為 in-context learning 的正式定義、zero-shot / one-shot / few-shot 的光譜、2 到 5 個範例的實用甜蜜點與超過後的遞減報酬、範例選取標準（多樣性、邊界覆蓋、正面與負面案例）、格式一致性的紀律、範例錨定風格與格式的機制、負面範例的作用、擺放位置決策（system prompt vs user message）、動態 few-shot 擷取、分類任務的專用模式，以及三大結構性限制（context 成本、範例漂移、範例過時）。最後的考試陷阱章節與 FAQ，將每個概念連回 few-shot prompting 出現最密集的四個考試情境——structured-data-extraction、customer-support-resolution-agent、developer-productivity-with-claude，以及 multi-agent-research-system。

什麼是 Few-Shot Prompting？在 Prompt Context 中提供已解答範例

Few-shot prompting 是在 prompt 中放入兩個以上完整的輸入輸出範例，讓 Claude 能直接從範例推斷任務模式，而非單靠指令。範例就是訓練訊號；任務說明退化為圍繞範例的簡短框架。每個範例都是一對示範——「這是你會見到的輸入類型，這是你應該產生的確切輸出」。Claude 從範例泛化，應用到隨後的真實輸入。

Few-shot prompting 是一種 in-context learning：模型在當次請求的有效期間內短暫習得這個模式，不涉及任何權重更新。沒有任何東西被訓練、儲存或跨請求持久化。每一個需要相同行為的新請求，都必須重新帶入相同的範例。這種短暫性正是 few-shot 無法取代 fine-tuning 的根本原因，同時也使它成為 CCA-F 測試的絕大多數生產模式中，遠比 fine-tuning 更便宜、更快速、更靈活的替代方案。

為什麼 CCA-F 把 Few-Shot 放在 Domain 4

Domain 4 佔考試 20%，六個任務說明平均分配。Few-shot prompting（4.2）是 Domain 中被測頻率第二高的任務，僅次於明確標準（4.1），因為所有下游任務——結構化輸出（4.3）、驗證迴圈（4.4）、批次處理（4.5）、多輪審查（4.6）——都仰賴 Claude 產生一致的輸出形狀。Few-shot 是強制這種一致性最便宜、最普遍適用的機制。社群通過報告反覆指出「指令無效時卻不加範例」是常見的干擾陷阱：考生選了「增加更多指令」，正確答案卻是「加入兩個已解答的範例」。考試獎勵那些在追加說明之前先想到範例的考生。

Few-Shot 不是 Fine-Tuning

Fine-tuning 在精選資料集上更新模型權重，產生一個新的模型 checkpoint。Few-shot prompting 將範例注入單一請求的 context，讓基礎模型維持不變。在 CCA-F 上，任何將 few-shot 框架為「在你的範例上訓練 Claude」或把它當成 fine-tuning 替代品的答案都是錯的。考試明確將 fine-tuning 列為超出範疇，而 few-shot 題目幾乎都有至少一個混淆兩者的干擾選項。正確的心智模型：few-shot 快速、可迭代、短暫；fine-tuning 緩慢、昂貴、永久。

Zero-Shot vs One-Shot vs Few-Shot — 各策略的適用時機

三種 prompting 策略形成一個範例密度的光譜。每個策略都有正確的使用情境，選錯光譜上的位置是 CCA-F 反覆出現的干擾陷阱。

Zero-Shot Prompting

Zero-shot prompting 不含任何已解答範例。Prompt 由任務指令和可能的參考資料組成，接著是真實輸入。適合使用 zero-shot 的時機：

• 任務可以用簡短的自然語言說明清楚（例如：「將這篇文章摘要成三句話」）。
• 輸出格式是自由散文或廣為人知的結構（已知 schema 的合法 JSON 物件）。
• 加入範例的成本（context token、撰寫時間）不值得換來的品質提升。

Zero-shot 是探索性原型設計，以及 Claude 的預訓練行為已接近目標的任務，最合適的基準起點。

One-Shot Prompting

One-shot prompting 恰好包含一個已解答範例。以下情況適合作為折衷選擇：

• 任務有非常具體的輸出格式，單一示範即可完整說明（例如一行發票明細項目）。
• Context 預算吃緊，只能容納一個範例。
• 在投入完整 few-shot 資源前，先測試範例是否有幫助。

單一範例能強力錨定格式，但幾乎無法說明邊界案例。Claude 往往會過度逐字複製那一個範例的措辭與結構——這個現象有時被稱為「one-shot 過度模仿」。

Few-Shot Prompting（2 個以上範例）

Few-shot prompting 包含兩個以上已解答範例。這是 in-context learning 效果最佳的範疇。多個範例能：

• 呈現任務必須處理的輸入範圍（而不只是單一實例）。
• 傳達變異性——輸出的哪些部分會隨輸入改變，哪些保持不變。
• 建立決策面——如何對落在簡單案例之間的輸入進行分類或路由。
• 大幅降低 one-shot 過度模仿，因為多個範例的共同結構一目瞭然。

決策捷思法

若任務說明沒有歧義，且 Claude 的基準行為已符合需求，從 zero-shot 開始。若一個示範即可完整確定格式，試試 one-shot。若任務有任何決策面、邊界案例或格式微妙之處——而 CCA-F 幾乎每個情境都有——就用 2 到 5 個範例的 few-shot。

範例數量建議 — 2 到 5 個範例作為實用甜蜜點

Anthropic 的 multishot prompting 指引建議多數生產任務以 3 到 5 個範例作為實用甜蜜點。社群通過報告則收斂在稍寬的 2 到 5 個範圍，視任務複雜度而定。理解這個範圍為何有效——以及為何更多範例幾乎不會更好——是 CCA-F 反覆測試的考點。

兩個範例 — 最低限度的 Few-Shot

兩個範例足以示範共同結構。Claude 看到兩份輸出之間什麼是固定的（格式、欄位順序、語調），什麼隨輸入而變化。兩個範例是避免 one-shot 過度模仿的最低門檻。

三到五個範例 — 生產甜蜜點

三到五個範例能涵蓋一般情況、一兩個邊界案例，通常還有至少一個對比案例。這是 in-context learning 展現最強品質提升的區間。第三個範例相對第二個的邊際效益通常很大；第六個範例相對第五個的邊際效益通常很小。

六個以上範例 — 遞減報酬

超過約五個範例後，額外範例通常不會有意義地提升輸出品質。它們確實可靠地增加：

• 每次請求的輸入 token 成本。
• 與 context 長度成比例的輸入處理延遲。
• 若額外範例偏向特定模式，則帶來錨定偏誤風險。
• 隨著範例區塊變長，中間範例被關注的程度下降——即**「迷失在中間」壓力**。

為什麼品質勝過數量

一個精心挑選、涵蓋重要邊界案例的範例，比三個都在示範同一個簡單模式的冗餘範例貢獻更多。社群通過報告指出「輸出仍然不對時不斷加入更多相似範例」是常見的死胡同。當品質仍然不足時，正確的做法通常是加入不同類型的範例——邊界案例、負面範例、對比組——而不是第五個相同的簡單案例重複。

範例選取標準 — 多樣性、邊界覆蓋、正面與負面案例

選擇放哪些範例，往往比決定放幾個更難。三個標準驅動選取。

多樣性

範例應涵蓋任務在生產環境會面對的輸入空間。若你的真實輸入橫跨四種文件類型，few-shot 區塊就不應只放四個同一種類型的範例。多樣性能防止 Claude 的 in-context 模式過度擬合到輸入分佈的某個狹窄切片。

在實作上，多樣性意味著：

• 輸入長度多樣性 — 若生產環境同時見到短、中、長輸入，就都要涵蓋。
• 輸入結構多樣性 — 不同格式、不同欄位順序、不同樣板文字。
• 結果多樣性 — 若任務是分類，要涵蓋多個類別的範例，而不是三個相同類別的範例。
• 領域多樣性 — 若任務橫跨多個領域（醫療、法律、零售），每個領域至少放一個範例。

邊界覆蓋

邊界案例是每單位 context 成本效益最高的範例。一個示範「輸入模糊時怎麼處理」、「輸入為空時怎麼處理」或「輸入自相矛盾時怎麼處理」的範例，能傳授任何數量的簡單範例都無法表達的決策規則。

值得考慮的邊界案例：

• 缺少欄位 — 少了必要資訊的輸入。
• 訊號衝突 — 同時指向兩個方向的輸入。
• 近似輸入 — 看起來符合任務但其實不應匹配的輸入。
• 退化輸入 — 空字串、只有空白、重複 token。

單一邊界範例往往能修復比三個額外的典型範例更多的生產問題。

正面與負面案例

正面範例示範目標行為。負面範例示範不應做的模式，通常搭配一個修正。負面範例在分類、內容審核，以及結構化擷取——任何「納入」與「排除」之間的界線很重要的任務——都特別有力。

負面範例不只是一個錯誤答案；它是一個明確標記的範例，讓 Claude 直接看到不想要的輸出，從而磨利對這條界線的感知。第七節對負面範例有更深入的說明。

範例格式一致性 — 讓範例與期望輸出格式完全對齊

Claude 會複製你的範例的確切格式。這正是 few-shot 強制輸出一致性的主要機制——這也意味著範例的每個表面細節都很重要。

確切格式匹配的意涵

若你的範例用 JSON 且欄位順序為 id、name、amount，Claude 會強烈偏好輸出中的同一欄位順序。若你的範例用 snake_case 鍵，Claude 不會切換成 camelCase。若你的範例用 <result>...</result> XML 標籤包裹輸出，Claude 會產生相同的標籤。若你的範例用小寫 enum 值，Claude 不會改用大寫。

為什麼這是優點

強制匹配正是讓 few-shot 在一致性上如此有用的原因。用說明文字寫「請用 snake_case 鍵、小寫 enum 值，並按照這個確切的欄位順序」既冗長又脆弱，往往還不完整。用兩個範例展示目標格式，則緊湊、精準，且不留任何解釋空間。

為什麼這也是陷阱

你自己的範例若不一致，這個不一致就會滲入 Claude 的輸出。若範例一用 customer_id，範例二用 customerId，生產輸出就會在兩者之間隨機交替。若範例一有結尾換行而範例二沒有，生產輸出就會混雜兩種。範例中的一個拼寫錯誤，就可能成為 Claude 複製的模式。

上線前的紀律清單

在發布 few-shot prompt 前，逐一核對每個範例：

• 欄位名稱完全一致 — 相同大小寫、相同拼寫、相同順序。
• 空白慣例完全一致 — 相同縮排、相同結尾換行策略。
• 包裹標記完全一致 — 相同 XML 標籤、相同 Markdown fence、相同分隔符。
• 語調完全一致 — 正式程度、詳細程度、是否有問候語，全部一致。
• 空值處理完全一致 — 缺少資料的慣例在所有範例中必須相同。

輸出一致性機制 — 範例如何錨定格式與風格

Few-shot prompting 帶來的一致性提升不是魔法；它是 transformer 模型如何對前置 context 做條件化的直接結果。理解這個機制，能讓你清楚 few-shot 能解決哪些問題、不能解決哪些問題。

大規模的模式補全

Transformer 語言模型被訓練成根據前置 context 預測下一個 token。當你提供一連串的輸入輸出範例組合，後面跟著一個新的輸入，最可能的續接就是另一個相同形狀的輸出——因為那正是 context 中的模式所預測的結果。Claude 實際上是在補全 [輸入1 → 輸出1, 輸入2 → 輸出2, ..., 輸入N → ?] 這個模式，而 ? 受前幾個輸出的結構性規律強烈偏置。

範例能可靠錨定的事物

• 結構格式 — JSON vs XML vs 散文、欄位名稱、欄位順序、包裹標籤。
• 長度分佈 — 短輸出維持短；長輸出維持長。
• 語調與語域 — 正式、非正式、專業、親切。
• 詞彙偏好 — 術語、縮寫、品牌語調。
• 空值處理慣例 — 空字串、null 字面值、缺少的鍵、佔位符。
• 分類邊界 — 哪些輸入特徵對應哪個輸出標籤。

範例單獨無法修復的事物

• 領域知識的事實錯誤 — 若 Claude 不知道某個事實，範例不會提供那個事實。
• 嚴格的 schema 驗證 — few-shot 強烈偏置輸出趨向某個 schema，但無法保證完全符合。搭配嚴格的 tool use（任務 4.3）才能保證 schema 遵從性。
• 長文件理解 — 若輸入太長導致處理不準確，加入輸出範例不能修復輸入端的問題。
• 未見輸入分佈上的推理錯誤 — 範例只引導 Claude 處理它們所代表的分佈。

對 CCA-F 的含義

當情境描述的是輸出格式問題（JSON 形狀不一致、語調不一致、欄位順序漂移），few-shot 通常是正確答案。當情境描述的是輸出正確性問題（事實錯誤、必須保證的無效 schema、幻覺內容），few-shot 是部分解法，必須搭配明確標準（4.1）、嚴格 tool use（4.3），或驗證迴圈（4.4）。

負面範例 — 展示不想要的輸出以銳化對比

負面範例是一個明確標記的示範，說明 Claude 不應該做什麼。它不是一個未標記的錯誤答案；它是一個明確標示的反模式，搭配修正或清晰的「不是這樣」框架。對於可接受與不可接受之間的界線至關重要的任務，負面範例是 few-shot prompting 中效益最高的技術之一。

負面範例值得投入的時機

• 內容審核 — 區分細微的政策違規與無害內容。
• 標籤模糊的分類 — 區分「垃圾郵件」與「有意義的促銷郵件」，或「緊急」與「高優先度」。
• 有歧義的結構化擷取 — 教 Claude 在輸入不支援時不要擷取值（「不要憑空捏造」的邊界）。
• 語調控制 — 當目標是特定語域時，將過於正式或過於隨意的輸出標記為不想要。
• 格式紀律 — 標記「幾乎正確」但違反細微規則的輸出（多餘的尾隨逗號、鍵的大小寫錯誤）。

負面範例的結構模式

兩種常見格式：

1. 對比組 — 每個範例同時包含一個錯誤輸出和一個正確輸出，並明確標記：

<example>
<input>Customer: "I want to speak to a human."</input>
<wrong_output>Have a nice day!</wrong_output>
<correct_output>I understand — connecting you to a human agent now.</correct_output>
</example>

2. 獨立負面區塊 — 幾個正面範例之後，跟著一小塊明確標示的負面範例：

<negative_examples>
<example>
<input>...</input>
<output>This output is wrong because it misses the escalation signal.</output>
</example>
</negative_examples>

比例建議

負面範例應佔 few-shot 區塊的少數——每兩到三個正面範例對應一個負面範例是合理的比例。負面範例過多，會讓 Claude 偏向過度拒絕輸入。目標是銳化對比，而不是將任務重新框架成「避免壞輸出」。

範例擺放位置 — System Prompt vs User Message

你在請求中把範例放在哪裡，會影響 Claude 如何對待它們。CCA-F 反覆測試這個區別，通常以 system prompt 擺放與 user message 擺放之間的選擇呈現。

範例放在 System Prompt

以下情況將範例放在 system prompt：

• 範例定義了 agent 在對話每一輪都應保持的持久的 persona 或風格。
• 範例描述了整個 session 都適用的工具呼叫模式。
• 你希望透過 prompt caching 讓範例成本只付一次，並在多輪使用者對話中重複使用。
• 範例是可重複使用的模板的一部分，應獨立於任何特定的使用者輸入。

範例放在 User Message

以下情況將範例放在 user message：

• 範例是任務特定的，附屬於特定請求。
• 範例是根據當前輸入動態選取的（見第九節）。
• 你正在使用 Messages API 進行單輪呼叫，沒有對話狀態可以分攤。
• 範例帶有「這是任務的已解答範例，現在做這個真實的」框架——這是典型的單輪 few-shot 模式。

兩種擺放位置都應使用 XML 標籤

Anthropic 的 prompt 工程指引建議，無論擺放位置如何，都用明確的 XML 標籤包裹範例區塊（<examples>、<example>、<input>、<output>）。XML 標籤讓 Claude 能明確辨認範例的邊界，更容易區分範例、指令與真實輸入。省略 XML 標籤是「Claude 開始產生更多範例而不是回答問題」這類問題的常見根源。

範例排序中的錨定偏誤

範例的順序很重要。Claude 對最靠近真實輸入的（最新的）範例加權較重。實際含義：

• 把最具代表性的範例放在最後，而不是最前面。
• 避免在末尾集中相同類別的範例——那會讓分類器偏向那個類別。
• 對於分類任務，交錯排列各類別，而不是分組排列。
• 對於擷取任務，以結構最接近預期真實輸入結構的範例結尾。

動態 Few-Shot — 根據輸入相似度以程式化方式選取範例

靜態 few-shot 區塊對每個請求使用相同的 3 到 5 個範例。動態 few-shot 則根據與當前輸入的相似度，為每個請求挑選不同的範例。動態 few-shot 是最高品質的生產系統在不為每次呼叫付出 20 個範例的 context 成本下，從 few-shot 榨出更多效益的方式。

動態 Few-Shot 的模式

1. 維護一個精選的範例庫——一組 50 到 500 個已解答的輸入輸出對，涵蓋完整的生產輸入分佈。
2. 在請求時，計算當前輸入與庫中每個範例的相似度分數（向量相似度、BM25 關鍵字評分、基於後設資料的路由）。
3. 選取相似度最高的前 K 個（通常為 3 到 5 個）範例。
4. 如常將這些範例注入 prompt。
5. 送出請求。

動態 Few-Shot 勝過靜態的原因

• 更高的相關性 — Claude 看到的範例是最接近當前輸入的，而不是輸入分佈的固定樣本。
• 更好的邊界案例覆蓋 — 範例庫可涵蓋 500 個邊界案例，只將匹配當前輸入的那一個浮現出來。
• 更小的活躍 context — 你可以維護一個龐大的範例庫，每次請求卻只付 3 到 5 個範例的成本。
• 更易維護 — 加入新範例只需附加到庫中，不需重新調整靜態區塊。

動態 Few-Shot 值得工程投入的時機

動態 few-shot 需要一個範例儲存庫、一個相似度引擎，以及每次請求的擷取步驟——是真實的工程投入。以下情況值得這樣做：

• 高流量的生產工作負載，每次請求的品質提升會複利累積。
• 輸入分佈高度可變的任務，沒有任何 5 個靜態範例能代表整個分佈。
• 長期產品，範例庫可以隨使用者回饋成長。

對於原型、短期工具或低流量批次工作，靜態 few-shot 是正確的取捨。

超出範疇的說明

CCA-F 將 embedding 模型內部原理和向量資料庫實作細節列為超出範疇。考試測試的是你能否識別動態 few-shot 模式以及何時適用，而不是你能否實作一個向量搜尋引擎。需要深入擷取工程知識的答案是干擾選項；識別「根據輸入相似度選取範例」為正確架構模式的答案通常才是對的。

Few-Shot 用於分類 — 範例作為隱式決策邊界定義

分類是 few-shot prompting 表現最亮眼的任務。範例字面上就是決策邊界：Claude 單從範例推斷標籤映射，不需要明確規則。

分類任務的 Few-Shot 模式

對於有 K 個標籤的分類器，每個標籤放約 1 到 2 個範例（小型分類器共 3 到 8 個範例）。每個範例是一個 (輸入, 標籤) 組合。可選的補充：

• 簡短的 rationale 欄位，說明標籤背後的推理——對細微的類別有幫助。
• 若標籤有自然的序數（低/中/高），可加入信心提示。
• 相鄰標籤之間的近似案例，可加入負面範例。

為什麼範例勝過規則用於分類

分類規則很難窮舉。「若工單提到中斷或客戶是企業等級或訊息語調憤怒，則視為緊急」是一條可以編碼的規則。但真實生產分類系統的「若...則緊急」通常有幾十個沒人想逐一列舉的模糊條件。少數幾個有代表性的範例，能捕捉到一頁規則無法描述的決策面。

交錯排列類別以避免順序偏誤

始終在範例區塊中交錯排列類別：

• 好的做法： 緊急、一般、緊急、低、一般、低。
• 不好的做法： 緊急、緊急、緊急、一般、一般、低。

在末尾集中相同類別，會讓 Claude 偏向最後那個類別。交錯排列能讓所有標籤的順序效應取得平衡。

搭配結構化輸出

對於分類任務，將 few-shot 與 tool use schema（任務 4.3）搭配使用，讓 Claude 必須從允許的集合中回傳一個標籤。Few-shot 教 Claude 映射關係；嚴格的 tool use 強制確保答案是其中一個合法標籤。這個組合是 CCA-F 考試對「讓分類既準確又保證符合 schema」的標準答案。

Few-Shot 的限制 — Context Window 成本、範例漂移、範例過時

Few-shot prompting 不是免費的，也不是萬靈丹。CCA-F 要求考生認識三大結構性限制。

Context Window 成本

每個範例在每次請求上都要付輸入 token。5 個範例、每個範例 300 個 token，在真實輸入到達之前就花掉了 1,500 個輸入 token。對於低延遲高流量的工作負載，這個成本是真實的。緩解方式：

• Prompt caching — Anthropic 的 prompt caching 功能將範例區塊的成本分攤到重複請求上。靜態 few-shot 區塊放在 system prompt 中時，範例在每次快取命中只付一次費用，而不是每次呼叫都付。
• 動態 few-shot — 擷取更少、更相關的範例，而不是每次都送出所有範例。
• 範例壓縮 — 將每個範例修剪到傳達模式所需的最低限度（移除樣板、縮短散文）。

範例漂移

範例漂移發生在任務隨時間微妙改變，但原始範例不再匹配當前目標時。症狀：

• 生產輸出開始看起來稍微過時——舊欄位名稱、舊語調、舊格式慣例。
• Claude 偶爾產生完全匹配舊範例但違反新規格的輸出。
• 範例說一件事；文件說另一件事。

漂移是維護問題。解法是將範例區塊視為一級工件：對它進行版本控制、在每次影響輸出形狀的產品變更時審查它，並將它納入評估執行，以便及早發現退化。

範例過時

過時的範例是內容不再符合現實的範例——引用舊費率方案的定價範例、地址已更改的地點範例、已停產 SKU 的產品範例。過時的範例不只是維護問題；Claude 會複製過時的內容。

• 優先使用抽象而非具體 — 在可能的情況下，讓範例的結構不依賴於易變的事實。「X 客戶在 Y 方案」優於「某公司在 2024 金級方案」。
• 每次發布時稽核 — 對於任何包含範例的 system prompt 或 skill，過時偵測應列入發布核查清單。

Few-Shot 不是 Fine-Tuning（再次強調）

Few-shot 的每個限制，最終都可以追溯到同一個根源：範例活在 context 中，而非權重中。它們每次請求都要付費，必須在每次呼叫時重新傳入，且沒有持久性。當範例的每次請求成本對特定工作負載而言根本性地過高時，在更廣泛的 Claude 生態系中正確的升級路徑，通常不是 fine-tuning（CCA-F 明確超出範疇），而是 prompt caching、動態 few-shot 與更精簡範例的組合。CCA-F 建議以 fine-tuning 解決 few-shot 成本問題的答案，定義上就是錯的。

白話說明

抽象的 few-shot 原理，一旦錨定在考生熟悉的具體情境上，就會變得直觀。三個不同的類比涵蓋了這個技術的完整面貌。

類比一：師父帶學徒做台菜 — 看著做好的菜來學習

想像一位剛入行的師承學徒，第一天跟著台菜師傅學藝。師傅不遞給學徒一本二十頁的食譜規則書；師傅在學徒面前做了兩三道菜，說「照這樣擺盤」。學徒看著師傅做第一道（範例一），看著做第二道（範例二），然後開始自己出菜。師傅做的每一道菜都是一個已解答範例——相同的配色擺設、相同的淋醬弧度、相同的份量。做到第三道，學徒的出菜跟師傅幾乎一模一樣。如果師傅只說「弄好看一點」就叫學徒自己來，每道菜看起來都會不一樣。師傅親做的那幾盤，就是 few-shot 範例；學徒就是 Claude；一致的出菜就是 few-shot 帶來的輸出一致性。注意，一道菜不夠——學徒會過度模仿。二十道菜很浪費——學徒三道就學會了。如果師傅的兩道菜對醬汁放哪裡看法不一，學徒就會永遠交替用兩種方式。這正是範例間格式漂移對 Claude 造成的影響。

類比二：圖書館的分類員 — 用展示的範本學分類

想像在圖書館訓練一位新分類員。任務是將每本進館的新書分到五個類別之一。比起解釋完整的分類規則，資深館員直接拿出五本已分好類的書——每個類別各一本——說「照這些書的方式分類進來的書」。新分類員不背分類規則；他從五個範例泛化。當一本書落在兩個類別之間時，他把它和範例比較，選最接近的那個。圖書館的庫房裡已有五百本分好類的書，對於難以判斷的書，資深館員會從中抽出三本最相似的讓新分類員參考。這就是動態 few-shot。五個交錯排列的範例，優於五個都來自同一個類別的範例。一個分錯類的舊書，會訓練新分類員犯相同的錯誤。Few-shot 分類，就是這個靠展示範本而非背誦規則受訓的圖書館分類員。

類比三：家傳食譜卡 — 不靠指令的格式一致性

家傳的食譜卡是偽裝成範例的規格書。它寫著「奶油和糖打發，蛋一顆一顆加入，再折入麵粉」。新廚師照著那張卡做，每次都烤出跟那張卡上一模一樣的蛋糕——相同口感、相同形狀、相同鬆軟度。卡片不需要寫「用九吋圓模」。放在架上、緊鄰那張卡的示範成品，默默規定了模具的尺寸。若食譜只寫「烤個蛋糕」，成果就會天差地遠。這張食譜卡是一個 one-shot 範例加指令；一本有三種變化的蛋糕食譜（原味、檸檬、巧克力），就是一個 few-shot 區塊。食譜書教導哪些部分是固定的（作法），哪些部分可以變化（口味）。當廚師從那本食譜書學到如何即興發揮第四種變化時，few-shot 就成功了。當廚師只用單一食譜卡，只能永遠做那一道蛋糕時，one-shot 過度模仿就發生了。CCA-F 中抱怨「每次呼叫的輸出形狀差異懸殊」的情境，描述的是缺少一本食譜書——而不是缺少一本規則手冊。

考試當天選用哪個類比

• 關於為什麼範例勝過指令的題目 → 師父帶學徒類比。
• 關於用 few-shot 做分類的題目 → 圖書館分類員類比。
• 關於範例帶來格式一致性提升的題目 → 家傳食譜卡類比。

常見考試陷阱

CCA-F Domain 4 持續利用六種與 few-shot prompting 相關的反覆出現陷阱模式。六種全部都有社群通過報告記錄在案，並以合理的干擾選項形式出現。

陷阱一：混淆 Few-Shot 與 Fine-Tuning

Few-shot prompting 是 in-context learning——範例在 prompt 中，沒有權重更新，沒有持久性。Fine-tuning 在精選資料集上更新模型權重，產生新的 checkpoint。CCA-F 考試明確將 fine-tuning 列為超出範疇。任何將 few-shot 框架為「在你的資料上訓練 Claude」或「永久教 Claude 新行為」的答案都是錯的。Few-shot 快速、可迭代、短暫；fine-tuning 緩慢、昂貴、永久。

陷阱二：更多範例永遠勝過更少

Anthropic 的指引認定 3 到 5 個範例是實用甜蜜點。超過約 5 個範例後，邊際品質增益很小，但 context 成本、延遲和「迷失在中間」風險都會增加。建議「盡可能多的範例」或「至少 10 個範例」的答案是錯的。範例品質勝過數量——單一邊界案例範例能修復的問題，往往多於三個冗餘的正面範例。

陷阱三：忽視範例格式一致性

Claude 複製範例的確切表面格式。若你的範例在欄位大小寫、欄位順序、空值處理或包裹標記上不一致，生產輸出就會在衝突的慣例之間交替。當考試情境描述「每次執行的輸出格式不一致」時，正確答案通常是「稽核並修復 few-shot 範例中的不一致性」——而不是「增加更多指令」。

陷阱四：範例區塊沒有 XML 標籤

Anthropic 的 prompt 工程指引建議用明確的 <examples> 和 <example> 標籤包裹範例。沒有 XML 標籤，Claude 可能混淆指令、範例與輸入，有時繼續產生更多範例而不是回答問題。描述注入範例但沒有結構性標籤的答案是不完整的。XML 標籤是 Domain 4 的橫切期待，在任務 4.1 和 4.2 都有測試。

陷阱五：容易產生幻覺的任務卻跳過負面範例

對於 structured-data-extraction 情境中 Claude 有時會憑空捏造輸入中不存在的欄位值，一個明確標記的負面範例（「當欄位不在輸入中時，回傳 null；不要猜測」）通常是正確的修復方式。一直加入正面範例而幻覺問題持續的考生，錯過了這個關鍵。負面範例是銳化「擷取」與「不擷取」之間邊界的高效益工具。

陷阱六：明顯需要動態 Few-Shot 時卻用靜態

當情境描述的輸入分佈極廣，沒有任何 5 個靜態範例能代表——例如跨 30 個類別的分類器或跨 20 種文件類型的擷取器——正確答案是動態 few-shot（按相似度為每次請求擷取範例），而不是「加入更多靜態範例」。堅持對高度可變的輸入空間用單一靜態區塊的答案是錯的。

練習錨點

Few-shot prompting 出現在所有觸及 Domain 4 的四個情境中，但兩個情境最集中練習它。

Structured-Data-Extraction 情境

這是任務 4.2 的旗艦 CCA-F 情境。Agent 從非結構化輸入——發票、合約、支援工單、醫療記錄——擷取結構化欄位。預期會有題目測試：(a) 選擇 3 到 5 個多樣化範例，而不是單一範例或 20 個範例；(b) 當 Claude 對缺少的欄位產生幻覺時加入負面範例；(c) 透過範例格式一致性強制嚴格的 JSON 欄位順序；(d) 將 few-shot 與嚴格 tool use（任務 4.3）搭配以保證 schema 符合規範；(e) 診斷當範例在大小寫或空值處理上不一致時的格式漂移；以及 (f) 在持久擷取 persona 選 system prompt 擺放、動態的每次請求範例選 user message 擺放之間做選擇。這個情境是考試中 few-shot 密度最高的單一情境。

Customer-Support-Resolution-Agent 情境

在這個情境中，支援 agent 對進件工單分類、起草回覆，並路由升級。Few-shot 出現在：(a) 每個標籤 1 到 2 個範例、各類別交錯排列的分類 prompt；(b) 少數已解答範例建立語調和品牌聲音的起草模板；(c) 教 agent 不處理超出範疇查詢的負面範例；(d) 將相似的歷史工單擷取為當前工單範例的動態 few-shot；以及 (e) multi-agent-research-system 和 developer-productivity-with-claude 情境，也練習 few-shot，但主要重心分別轉移到 orchestration 和程式碼生成模式。

FAQ — Few-Shot Prompting 前六大問題

few-shot prompting 究竟是什麼，和 zero-shot 有什麼不同？

Few-shot prompting 是在 prompt 中放入兩個以上的已解答輸入輸出範例，讓 Claude 從示範中推斷任務模式，而非只靠指令。Zero-shot prompting 不含任何範例；prompt 由指令加上輸入組成。Few-shot 對有特定格式要求、邊界案例或模糊決策邊界的任務，能大幅提升輸出一致性。它是一種 in-context learning——模式在單一請求的有效期間內短暫習得，沒有權重更新，請求之間也不會持久化。

few-shot prompt 中應該放幾個範例？

Anthropic 的 multishot prompting 指引認定 3 到 5 個多樣且相關的範例，為多數任務的實用甜蜜點。兩個範例是最低限度的 few-shot；超過約 5 個範例後，邊際品質提升變小，但你要為額外範例付出輸入 token、延遲和「迷失在中間」風險的代價。品質勝過數量——一個精心挑選的邊界案例範例，比三個相同簡單模式的冗餘範例貢獻更多。建議「盡可能多」或「至少 10 個」的答案，在 CCA-F 上是錯的。

few-shot prompting 和 fine-tuning 一樣嗎？

不一樣。Few-shot prompting 是 in-context learning——範例活在 prompt 中，每次請求都要付費。Fine-tuning 在精選資料集上更新模型權重，產生新的模型 checkpoint。Few-shot 快速、可迭代、短暫；fine-tuning 緩慢、昂貴、永久。CCA-F 考試明確將 fine-tuning 列為超出範疇，題目中常有混淆兩者的干擾選項。當 zero-shot 品質不足時，CCA-F 上幾乎總是應該加入已解答範例，而不是做 fine-tuning。

few-shot 範例應該放在 system prompt 還是 user message？

當範例定義了一個在 session 每輪都應使用的持久 persona、風格或工具呼叫模式時，放在 system prompt——這也讓 prompt caching 能將成本分攤到多輪使用者對話。當範例是任務特定的，或根據輸入相似度動態選取的，放在 user message。無論擺放位置，都用明確的 XML 標籤包裹範例區塊（<examples><example><input>...</input><output>...</output></example></examples>），以區分範例、指令與真實輸入。

什麼時候應該加入負面範例？

對於可接受與不可接受輸出之間的界線很重要的任務，加入負面範例——內容審核、標籤模糊的分類、容易對缺少欄位產生幻覺的結構化擷取，以及語調控制。單一明確標記的負面範例，往往比三個額外的正面範例修復更多的生產問題。保持負面範例為少數（約每兩到三個正面範例對應一個負面範例）。結構模式包括對比組（同一區塊中錯誤輸出加正確輸出）和專屬的 <negative_examples> 區塊。過度使用負面範例，會讓 Claude 偏向過度拒絕。

如果任務有幾百個邊界案例，我需要在每個 prompt 中放幾百個範例嗎？

不需要——這正是動態 few-shot 的正確使用情境。維護一個精選的範例庫，存放 50 到 500 個涵蓋生產輸入分佈的已解答組合。在請求時，擷取與當前輸入最相似的前 3 到 5 個範例（向量相似度、關鍵字評分或後設資料路由），只將這些注入 prompt。這讓每次請求的 context 成本維持在 3 到 5 個範例，同時讓你在庫中涵蓋幾百個案例。動態 few-shot 是 CCA-F 對「情境描述靜態 5 個範例無法代表的廣泛輸入分佈」的標準正確答案。

延伸閱讀

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

Related ExamHub topics: Explicit Criteria Prompt Design, Structured Output with Tool Use and JSON Schemas, Validation, Retry, and Feedback Loops for Extraction, Multi-Instance and Multi-Pass Review Architectures.