返回部落格

Few-Shot 與 Zero-Shot 提示:何時該用哪一種?

一份實用指南,幫你為任務挑選合適的提示方式,附上可直接複製的範例與簡單的決策框架。

Few-Shot 與 Zero-Shot 提示:何時該用哪一種?
你把一段提示貼進 ChatGPT。輸出結果……還行。但你看過有人在提示中加上「範例」後,得到大幅更好的結果。你也該這麼做嗎?要加幾個範例?這對你手上的任務真的有差嗎?
這些問題不斷出現,而那些術語一點也幫不上忙。「Zero-shot」、「few-shot」、「one-shot」——聽起來像攝影術語,而不是實用建議。這份指南會撇開行話,給你一個清楚的決策框架,告訴你何時該用哪一種,並附上完整的提示讓你自己複製測試。

Zero-shot 提示到底是什麼意思

Zero-shot 提示的意思是:給 AI 一個任務,但不示範任何你想要的結果。你描述自己的需求,讓模型根據訓練所學自行想出做法。
以下是用來摘要會議的 zero-shot 提示:

將以下會議筆記摘要成 3-5 個重點項目,涵蓋會中所做的關鍵決策。

會議筆記:
{{meeting_notes}}
就這樣。沒有「好摘要」的範例,也沒有任何輸入輸出示範。你信任模型自己理解摘要該長什麼樣,以及「關鍵決策」是什麼意思。對許多任務來說,這樣其實效果出乎意料地好。

Few-shot 提示到底是什麼意思

Few-shot 提示的意思是:在提示中加入 2-5 個範例,示範你希望 AI 遵循的模式。等於是在交付實際任務前,先告訴它「我希望你這樣處理」。
同樣的會議摘要任務,加上範例後是這樣:

將會議筆記摘要成 3-5 個重點項目,涵蓋關鍵決策。

範例 1:
輸入:「團隊討論了第三季目標。Sarah 提議將業績目標提高 15%。Mark 不同意,認為以目前的銷售管道,10% 比較實際。團隊投票後決定 12%。同時也決定將網站改版延後到第四季。」
輸出:
- 同意第三季業績目標提高 12%(在 15% 與 10% 之間取折衷)
- 網站改版延後至第四季

範例 2:
輸入:「預算檢討會議。目前支出比預估超出 8%。財務長建議將差旅預算砍半,並凍結新進人員 60 天。執行長批准兩項措施立即生效。」
輸出:
- 差旅預算砍半(立即生效)
- 批准 60 天人事凍結
- 因應 8% 的預算超支

現在請摘要這份:
{{meeting_notes}}
注意差別。範例直接告訴模型你要的格式(帶括號註解的條列項目)、要寫到多細,以及如何處理多個決策。模型在當下脈絡中學會你的偏好——完全不用微調。

兩種做法的關鍵差異一覽

以下是兩種做法在最關鍵的幾個面向上的比較:
  • 速度:Zero-shot 比較快。處理的 token 較少,回應自然較快。
  • 成本:Zero-shot 比較便宜。你是按 token 計費,範例會累積成本。
  • 準備工夫:Zero-shot 幾乎不用準備。Few-shot 則要找或寫出好範例。
  • 簡單任務的準確度:差不多。現代模型對直白的需求兩種方式都應付得來。
  • 複雜或客製任務的準確度:Few-shot 通常勝出。當你需要特定格式或專業術語時,範例會帶來可量測的差距。
取捨很清楚:zero-shot 較簡單也較便宜,few-shot 則讓你對輸出有更多掌控。問題是:額外的掌控何時才值得?

Zero-shot 最適合的情境

當任務本身是模型已從訓練資料中「理解」的內容時,zero-shot 提示最能發揮。這類任務包括:
一般知識問題:詢問解釋、定義或事實資訊。模型知道好的解釋長什麼樣。

創意發想:產生點子、寫初稿,或想各種選項。這時候你希望多樣性,而不是死守某個模式。

標準摘要:濃縮文章、電子郵件或文件,且不需要特定格式。

翻譯:在模型訓練過的語言之間互譯。

簡單分類:把項目分到常見類別(正面/負面、緊急/不緊急),且類別本身意思一目了然。
一個好用的判斷原則:如果你能用白話講清楚自己要什麼,而且不用看範例的人也能聽懂,那 zero-shot 應該就夠用。
決策流程圖:從 zero-shot 開始,評估結果,只有在必要時才加上範例
決策流程圖:從 zero-shot 開始,評估結果,只有在必要時才加上範例

Few-shot 何時值得多花這些 token

當輸出需要遵循某種模型無法只靠指令推斷出來的模式時,few-shot 提示就值回票價:
自訂格式:當你需要輸出符合特定結構——具備特定欄位的 JSON、欄位明確的表格、特定樣式的條列項目時。範例呈現格式比文字描述清楚得多。

你自己的分類類別:如果你要把客服信分成「帳務問題」、「功能需求」、「Bug 回報」、「一般詢問」這幾類,各給幾個範例能讓模型理解你的定義。

品牌語氣或調性對齊:想讓 AI 寫得像你公司現有的內容嗎?給它 2-3 個那種語氣的範例。「請以專業但友善的語氣寫」這類指令很模糊;範例則具體許多。

特定領域的術語:如果你的產業使用一些行話或縮寫,且這些詞在別處有不同意思,範例能讓模型理解你的脈絡。

邊緣案例與微妙語感:諷刺、反諷,或那些容易讓 zero-shot 翻車的細微差別。研究顯示,few-shot 提示能顯著提升處理情感邊緣案例的能力,例如否定句和諷刺。
一項研究發現,在 Twitter 情感分類上,僅 20-50 個範例的 few-shot 提示,就能逼近用超過 10,000 筆資料微調過的模型的表現。這就是精挑範例的威力。
如果你發現自己正在累積一整批不同任務的 few-shot 提示,像 PromptNest 這種工具能幫你把它們存起來,並內建 {{meeting_notes}} 這類變數——複製時填入空格,完整提示就能直接貼上。

「先 Zero,需要再升級」的工作流程

以下是同時省時間又省 token 的實務做法:
步驟 1:先試 zero-shot。寫一段清楚的提示,描述你要什麼。對任務具體一點,但暫時別放範例。

步驟 2:評估輸出。它有沒有給你需要的東西?有的話,就到此為止。沒有的話,找出哪裡出了問題——是格式?語氣?細節缺漏?還是根本誤解了任務?

步驟 3:加上有針對性的範例。做 2-3 個專門示範模型出錯之處的範例。如果格式不對,就示範正確格式;如果語氣偏了,就示範對的語氣。
這個流程之所以重要,是因為你不是在猜要不要用範例——你是針對實際的落差去補。有時在 zero-shot 提示中加一句「Let's think step by step」就能解決推理問題,完全用不到範例。研究證實,在推理任務上,zero-shot 思維鏈往往勝過 few-shot。

你到底需要幾個範例?

研究結果一致指向一個甜蜜點:對多數任務而言,2-5 個範例是最佳值。資料告訴我們:
- 前 2-3 個範例帶來最大的準確度提升 - 從第 4-5 個範例開始,效益遞減非常明顯 - 範例放太多反而可能降低表現,因為會引入相互衝突的模式 - 範例品質比數量更重要——三個出色的範例勝過十個普通的
還有一個關於範例順序的重要發現:研究顯示範例的排列順序會影響結果,有時最佳順序就足以決定表現是好是壞。如果你的 few-shot 提示效果不理想,先試著重新排序,再考慮加更多範例。
示意圖呈現提示中陸續加入範例卡片,前幾個之後效益遞減
示意圖呈現提示中陸續加入範例卡片,前幾個之後效益遞減
對多數情境來說,先從 2 個範例開始。如果準確度還不到位,就再加一個涵蓋不同變化的範例。你很少需要超過 4 個。

思維鏈:推理任務的折衷選項

還有第三種做法,特別適合數學、邏輯與多步驟問題:思維鏈提示(chain-of-thought)。你不是丟出輸入輸出範例,而是請模型「一步一步思考」。
Zero-shot 思維鏈長這樣:

一家店有 45 顆蘋果。早上賣出 12 顆,接著進了一批 30 顆。下午又賣出 18 顆。打烊時店裡剩幾顆蘋果?

Let's work through this step by step.
就這麼一句——「Let's work through this step by step」——就能讓模型把推理過程攤出來,而不是直接跳到答案。處理複雜推理時,這常常勝過 zero-shot 和 few-shot 兩種做法。
arXiv 上一份近期研究發現,對 GPT-4 和 Claude 這種能力較強的模型,zero-shot 思維鏈在推理任務上經常勝過 few-shot。範例反而可能限制模型的思考方向,而非幫助它思考。
在以下情況使用思維鏈:
  • 任務需要多個邏輯步驟
  • 你需要模型解釋自己的推理過程(便於抓錯)
  • 涉及數學、程式邏輯或分析型問題
  • 你想驗證模型的推理路徑,而不只是看答案

可以直接複製使用的完整提示範例

我們把三種做法在實際任務上並排展示。所有提示都已用 GPT-4 與 Claude 測試過,可以直接拿來用。

任務 1:電子郵件語氣分類

Zero-shot 版本:

將這封客戶郵件的語氣分類為:不滿、滿意、中性或緊急。

郵件:
{{email_text}}

語氣:
Few-shot 版本(較適合處理邊緣案例):

將客戶郵件語氣分類為:不滿、滿意、中性或緊急。

郵件:「我等訂單已經三週了。這太誇張了。我現在就要退款。」
語氣:不滿

郵件:「想跟你們說聲謝謝——商品提早到貨,而且很好用!」
語氣:滿意

郵件:「您好,可以幫我確認訂單是否已出貨嗎?訂單編號 #12345。」
語氣:中性

郵件:「我們系統當機,今天就需要那個替換零件,不然合約會丟。」
語氣:緊急

郵件:{{email_text}}
語氣:
Few-shot 版本能幫模型理解你的具體定義。「緊急」和「不滿」可能模糊難分——範例能把界線劃清楚。

任務 2:商品描述改寫

Zero-shot 版本:

將這段商品描述改寫得更吸引人、更聚焦於使用者益處。控制在 100 字以內。

原文:{{product_description}}

改寫版本:
Few-shot 版本(較適合維持品牌語氣一致):

將商品描述改寫得吸引人並聚焦於使用者益處。請對齊以下風格:

原文:「不鏽鋼水瓶。容量 24 oz。可冷藏飲品 24 小時。」
改寫:「24 oz 質感不鏽鋼水瓶,陪你一整天好好喝水。早晨咖啡通勤路上熱呼呼,午後冰水在健身房依然冰涼。一只水瓶,無限可能。」

原文:「無線耳機。8 小時續航。主動降噪。」
改寫:「8 小時連續播放你最愛的 podcast。我們的無線耳機隔絕雜音,讓你專注於真正重要的事——無論是深度工作、健身歌單,還是終於把那本聽不完的有聲書聽完。」

原文:{{product_description}}
改寫:
Few-shot 版本教會模型一種具體的文案風格——以益處為主、口語化、帶具體使用情境。Zero-shot 會給你一份改寫,但不一定是你的語氣。

任務 3:Bug 回報結構化

Zero-shot 版本:

將這份 bug 回報轉成結構化格式,包含:摘要、重現步驟、預期行為、實際行為。

Bug 回報:{{bug_report}}
Few-shot 版本(較適合維持格式一致):

將 bug 回報轉換成結構化格式。

輸入:「我嘗試上傳 PDF 時 app 整個閃退。我在儀表板上,按了上傳,選了一份 5MB 的 PDF,結果它直接關閉了。本來應該在我的上傳列表裡看到那份檔案,但結果整個 app 就掛了。」

輸出:
**摘要:**上傳 PDF 檔案時 app 閃退
**重現步驟:**
1. 進入儀表板
2. 點選上傳按鈕
3. 選取 PDF 檔案(已用 5MB 檔案測試)
**預期行為:**檔案出現在上傳區段
**實際行為:**應用程式異常閃退/關閉

---

輸入:{{bug_report}}

輸出:
技術文件的一致性很重要。Few-shot 版本能確保每份 bug 回報都遵循同樣的結構與相同的詳細程度。

快速決策框架

面對新任務時,跑過下面這幾個問題:
1. 任務直白且定義清楚嗎?→ 從 zero-shot 開始 2. 需要某種模型可能猜不到的特定格式嗎?→ 用 few-shot 3. 任務涉及多步驟推理嗎?→ 先試 zero-shot 思維鏈 4. 需要一致的品牌語氣或專業術語嗎?→ 用該語氣的範例做 few-shot 5. Zero-shot 已經給了你 80% 想要的內容嗎?→ 留著用。為了 100% 多花 3 倍 token 不划算。
目標不是用最炫的技術——而是有效率地拿到好結果。Zero-shot 是預設選項,只有在簡單做法不夠用時才加上更多複雜度。

把它放進你的日常工作

要把這些觀念內化,最好的方式就是動手實驗。挑一個你常做的任務——摘要報告、寫信、分類使用者回饋——兩種做法都試一遍。看看 zero-shot 在哪些地方不夠用,看看 few-shot 在哪些地方真的帶來差別。
一旦找到好用的提示,把它存到你之後真的找得回來的地方。如果你正在累積一批帶範例和變數的提示,PromptNest 是一款 macOS 原生 app($19.99 一次買斷,Mac App Store 上架,沒有訂閱、不用註冊、完全在本機執行),能把它們整理得井然有序、可搜尋,並讓你在任何 app 裡用快捷鍵叫出來。再也不必在散亂的筆記裡翻找你三週前寫的那段完美 few-shot 提示。
從簡單開始。需要時再加複雜度。把有效的留下來。整套策略就這樣。