提供例子（few-shot）

TL;DR

• Few-shot 比寫規則快。「給 3 個對話例」比「我希望回答要 X、Y、Z」直接
• 範例放 system 或 user 都可以，但用 <example> 包起來讓 Claude 看清楚邊界
• 範例品質 > 數量，1 個高品質範例屌打 5 個 noisy 的

一個情境：諷刺語氣分類

你寫了一個 sentiment 分類器——丟一則 tweet，回 Positive 或 Negative：

Classify the sentiment of this tweet as Positive or Negative.

Tweet: Yeah, sure, that was the best movie I've seen since
'Plan 9 from Outer Space'.

Claude 回 Positive——但這是諷刺（Plan 9 是 cult 級爛片）。User 寫的是反話。光看字面是正面，靠 guidelines 寫「請小心諷刺語氣」也常常擋不住。

這時候 best move 是直接給範例，說再多不如示範一次。

Classify the sentiment of each tweet as Positive or Negative.
Be especially careful with sarcasm.

<example>
  <sample_input>Great game tonight!</sample_input>
  <ideal_output>Positive</ideal_output>
</example>

<example>
  <sample_input>Oh yeah, I really needed a flight delay tonight! Excellent!</sample_input>
  <ideal_output>Negative</ideal_output>
</example>

Now classify:
Tweet: Yeah, sure, that was the best movie I've seen since
'Plan 9 from Outer Space'.

第二個範例就是諷刺的 demo。Claude 抓到 pattern，新 tweet 就會回 Negative。

One-shot vs multi-shot

名稱	範例數	用在
Zero-shot	0	簡單任務、Claude 本來就會的事
One-shot	1	確立基本 pattern、複雜輸出格式
Multi-shot	2–5	邊角案例、不同類型的合理回答

為什麼不寫 10 個範例：

1. Token 變貴（每個範例都進 input）
2. Latency 變慢
3. 邊際效益遞減——3 個之後通常 plateau
4. 範例越多越容易 noisy，反而拖累

新手起手用 3 個 是黃金值：一個典型 case、兩個邊角 case。

用 XML 包範例（為什麼這個結構穩）

範例的 markup 通常長這樣：

<example>
  <sample_input>...</sample_input>
  <ideal_output>...</ideal_output>
</example>

Tag 名稱可以自訂，但建議：

• <example> 包整組 input/output 對
• 內層用 <sample_input> / <ideal_output> 或 <input> / <output>
• 多個範例就重複多個 <example> block

為什麼有效見上一篇的 XML tag 段——Claude 對 XML 邊界特別敏感，能精準分清楚「這是示範資料」vs「這是真的要處理的 input」。

加上「為什麼這是好答案」

進階一點的做法：在 ideal output 後面補一段這個 output 為什麼算好：

<example>
  <sample_input>
    Height: 180 cm, Weight: 75 kg, Goal: Build muscle, Restrictions: Vegetarian
  </sample_input>

  <ideal_output>
    [完整 meal plan 內容]
  </ideal_output>

  This example is well-structured, provides detailed information on
  food choices and quantities in grams, fits the vegetarian restriction,
  and matches the muscle-building calorie surplus.
</example>

差別在哪：Claude 不只看到「應該長這樣」，還看到「為什麼這樣才對」。後者轉化成更穩的 generalization——下次新 input 來，它能照同一套標準產出，而不是只會抄表面格式。

範例怎麼挑——從 eval 報告抓

最省事的做法：跑 eval pipeline，從得 10 分（或最高分）的 case 直接挪過來當範例。

工作流：

1. 寫 v1 prompt（套上 direct + specific + XML）
2. 跑 eval，產出 HTML 報告
3. 找分數最高的 1–3 個 case
4. 把 input + output 整組塞進 prompt 變成 <example>
5. 再跑一次 eval 看是否進步

這個技巧為什麼強：你不是憑空寫範例（容易跟真實分布不一樣），而是用 model 自己已經寫得最好的版本當錨點。Claude 看到自己的高分輸出，會更穩地朝那個方向走。

最大的雷：範例跟真實 case 太像 → overfit

Few-shot 也有副作用：範例如果跟真實 input 太像，Claude 會「抄」而不是「想」。

症狀	原因
不同 input 都產出近乎一樣的 output	範例太具體，被當 template 直接複製
範例某句話原封不動出現在新 output	Claude 在背答案
改一個 input 欄位 output 沒變	model 沒在看真實 input

解法：

1. 範例選形式相似、內容差異大的 case
2. 範例 input 用跟 production 不同的具體數字 / 名字
3. 多 shot 時讓範例彼此 output 風格一致、但細節差很遠
4. 跑 eval 時故意丟跟範例很像的 input，看 output 會不會抄

Few-shot vs guidelines：什麼時候用哪個

場景	首選
簡單分類、固定欄位抽取	Guidelines（specific）
複雜輸出格式（特定 JSON 結構）	Few-shot
邊角案例（諷刺、雙關、反例）	Few-shot
特殊語氣 / 風格	Few-shot
一般任務的品質提升	Guidelines + 1 個範例

實務上兩個會混用——guidelines 寫底線、few-shot 補特殊狀況。不要把 few-shot 當萬靈丹（每個 prompt 都塞 5 個範例會很貴）。

接下來

Section 3 的三篇把「迴圈 + 主力技巧 + few-shot」串起來了，到這裡你應該能把任意 prompt 從 baseline 推到 production-ready 的分數。

下一個 Section 完全換主題：Tool use。當 prompt 再怎麼寫都解不掉「Claude 沒辦法答 SF 現在天氣」這種需要外部資料的問題時，就是時候讓 Claude 可以呼叫你的 function 了。從 Tool use 是什麼 開始——一個全新的、跟 prompt 平行的能力軸線。