Few-Shot Prompting

少樣本提示是什麼，跟純文字描述你要的輸出有什麼不同？

少樣本提示指的是在提示裡放入幾組「輸入內容對應到期望輸出」的具體範例，讓 Claude 直接從這些範例裡歸納出你要的風格、格式、細節拿捏，而不是靠一段抽象的文字說明去傳達。例如你想要 Claude 幫忙寫 commit message，與其寫「請用簡潔專業的語氣描述變更」，不如直接給兩三組「這是什麼樣的程式碼變更」對應「這是應該產出的 commit message」的實際案例。

跟純文字描述最大的不同在於「傳達精確度」。文字描述本身容易產生模糊地帶——「簡潔」「專業」這類形容詞每個人的認知標準不完全一樣；範例則是把你腦中那個「精確的樣子」直接攤開來給 Claude 看，省去了「用語言去描述一個風格」這個中間會失真的轉譯過程。

少樣本提示為什麼被需要，解決了什麼問題？

用純文字描述輸出要求時，會遇到一個具體限制:語言本身對「風格」「語氣」「精細的格式規則」這類東西的表達能力有限。你可以寫「用友善但專業的語氣」,但「友善但專業」實際落實到句子裡該長什麼樣子,不同人心裡的畫面可能差異很大——這種落差不是因為指令寫得不夠認真,而是文字本身在傳達這類細膩差異時,天生就有極限。

少樣本提示解決的正是這個「語言表達力不足」的問題:比起持續堆疊更多形容詞去逼近你要的風格,直接給範例是一種更直接的溝通方式——如同教一個新同事怎麼寫報告,與其口頭描述「大概是這種感覺」,不如直接給他看兩三份過去寫得好的報告,讓他自己抓住那個「感覺」是什麼。範例傳遞的資訊密度,往往比同樣篇幅的文字描述更高。

少樣本提示實際上怎麼運作，範例該給幾組、該怎麼挑選才有效?

運作原理是 Claude 會從提供的範例裡歸納出共通的模式（格式結構、語氣、判斷邏輯),再把這個模式套用到新的輸入上。範例數量沒有絕對規定,但實務上通常給二到三組就有明顯效果,重點不在數量多寡,而在於範例本身有沒有涵蓋到你在意的關鍵變化——例如如果你要 Claude 產出的內容有兩種常見情境(像是新增功能跟修正錯誤這兩類 commit),範例裡最好各給至少一組,而不是只給同一種情境的範例,不然 Claude 遇到另一種情境時,可能沒有足夠的參考依據做類比。

挑選範例時,品質比數量重要——與其塞五個普通範例,不如精選兩三個能清楚示範「好」跟「不夠好」差異的範例。如果任務本身有明確的輸出格式規則(例如固定的欄位順序),搭配範例使用時可以額外加上格式模板,讓 Claude 同時掌握「規則本身」跟「規則實際套用起來的樣子」,這兩者合起來通常比只給其中一種更穩定。

少樣本提示對我有什麼實際影響，什麼時候該用範例、什麼時候文字描述就夠了？

判斷準則可以回到「這個輸出要求,能不能用清楚的文字講完」這個問題。如果你要的是一個明確的邏輯規則(例如「檢查有沒有負責人欄位」這種是非題式的判斷),文字描述通常就足夠精確,不需要額外的範例;但如果你要的是一種「風格」「語氣」「精細的格式拿捏」這類難以用三言兩語窮盡的東西,範例通常比堆砌形容詞更快讓 Claude 抓到重點。

實務上一個好用的習慣是:當你發現自己為了描述一個要求,寫了好幾句形容詞卻還是覺得「這樣講不夠精確」,這就是該考慮改用範例的訊號。另外,少樣本提示不需要每次從零想範例——如果你手上已經有過去做得不錯的實際成品(例如以前寫過的一份好的報告、一則好的 commit message),直接拿那份成品當範例,通常比自己重新編一個假想範例更貼近你真正想要的標準。