主題: 學習筆記

Core Prompting Techniques：指令寫了，還要給範例嗎？

一句指令不夠，要補規則還是給範例？用 GitHub Issue 分類，整理 Standard、Zero-shot、One-shot 與 Few-shot 的差別。

「幫我整理一下這些 Issue。」

這句話寫起來很快。不過「整理」是要摘要、貼標籤，還是連修正計畫都一起寫？工作還沒開始，AI 就先收到一份猜題作業。

這篇拿 GitHub Issue 分類當例子，整理 Sabrina Goldfarb《Practical Prompt Engineering》的 Core Prompting Techniques 章節。我比較想弄清楚的是：一句話交代不完時，到底該把規則寫清楚，還是拿個範例給它看？

下面的 Issue 與提示都是自編示例。預期標籤依文章中的規則判定，還沒拿模型實測；課程與研究來源附在相關段落。

名字先放一邊，看看各自在處理什麼

Standard Prompt 描述直接提出請求的方式；shot 數量描述提供多少個任務示範。背景資料不等於示範答案：附上程式碼請模型找問題，如果沒有展示「另一段輸入及其預期輸出」，依然可以是 zero-shot。這個區分延伸自課程的 Standard Prompt 與 Zero Shot 定義。

Standard Prompt：先說好要它交什麼

回到開頭那句「幫我整理 Issue」。如果我只需要分類，就把這件事直接寫出來，順便交代回覆格式：

請協助分流 GitHub Issue。
每則只輸出一個標籤，供維護者決定後續處理順序。
標籤限用 bug、feature、question。
若輸入沒有足夠資訊判定，輸出 needs-info。
不要補寫修正程式或新增需求。

寫到這裡，工作範圍就清楚多了：要貼標籤，資訊不夠時也有處理方式。不過，一則 Issue 同時回報錯誤又要求新功能，該貼哪個？這就得補上團隊的分類規則。

本站的 Standard Prompt 單篇筆記另用訂閱表單說明必要背景與釐清時機；這裡接著看示範如何補足指令。

Zero-shot：不給範例，先把規則講清楚

Zero-shot 不提供任務示範，但仍能包含詳細規則。以下是可獨立使用的分類提示：

將下列 Issue 分類，只輸出一個標籤。
bug：明確回報既有功能與預期不符。
feature：要求尚未提供的能力。
question：詢問既有功能如何使用。
needs-info：資訊不足，無法依上述規則判定。
同時符合多類時，依 bug > feature > question 的順序選擇。

待分類 Issue：
按下刪除後卡片消失，但重新整理頁面時又出現。

照這套規則，預期答案是 bug：明明刪掉了，重新整理卻又回來，這是在回報既有功能的異常。

我會先從這個版本開始。答錯時，才有辦法回頭找是規則漏寫、模型誤解，還是 Issue 根本沒交代清楚。如果已經能穩定完成，就先用著，不用急著替 prompt 加料。

One-shot：拿一份給它看，照這個格式

One-shot 提供一組示範。課程建議先選常見且完整的案例，讓模型看見要沿用的模式。

保留上一節的分類規則，再加入：

示範輸入：請問如何修改已儲存提示的標題？
示範輸出：question

待分類 Issue：
希望新增匯出 JSON 的功能，目前只能在頁面上查看資料。

這次預期是 feature。那份示範讓模型看到：使用者寫一段話，你回一個標籤就好。不過，bug 怎麼判、混合需求怎麼選，這一題都還沒示範到。

範例也要自己先看過。如果上面寫「只回標籤」，下面卻示範一整段分析，那到底要它學哪個？先把這種矛盾修掉。

Few-shot：把容易分錯的情況也拿出來

依本課程的用法，Few-shot 是提供兩個以上的示範。我會優先補那些容易分錯的情況。如果五題都是差不多的 bug，混合需求該怎麼處理，還是一題都沒示範到。

保留相同規則，以以下示範取代上一節的一組示範：

輸入：按下儲存後顯示成功，但重新整理後資料不見了。
輸出：bug

輸入：希望新增目前沒有的標籤篩選功能。
輸出：feature

輸入：請問如何刪除已儲存的提示？
輸出：question

輸入：不能用。
輸出：needs-info

輸入：刪除後資料會復原，也希望新增批次刪除。
輸出：bug

待分類 Issue：
希望新增深色模式，也想知道目前如何修改標題。

這題同時有新功能和使用問題，照 feature > question 的順序，預期輸出就是 feature。前面的示範也補了「不能用」這種資訊不足的回報，以及一次塞兩個需求的情況。哪天團隊改成可以貼多個標籤，規則和範例就要一起改，不能只改一邊。

課程引用的 Language Models are Few-Shot Learners 研究 GPT-3 在上下文中使用示範的能力，沒有為每個任務更新模型權重。這與 fine-tuning 不同；論文的任務結果也不能保證任何現代模型都會因增加範例而進步。

順帶一提，課程用提示詞收藏庫串起練習：Standard／Zero-shot 建立儲存與刪除功能，One-shot 產出星等功能的規劃，Few-shot 則產出筆記功能的實作提示。這裡很容易漏看：拿到一份規劃，離功能真的做好，還有一段路。 請它規劃、請它寫提示、請它實作，最後要檢查的東西也不同。

資訊位置與長對話整理，我另外放在 Context Placement：重要資料放哪裡，AI 才找得到？。這裡先把注意力留給規則與示範。

換幾題沒示範過的，再看看結果

改完 prompt，先別只看示範題答得多漂亮。留幾題沒放進去的，用同一套規則檢查。下面是之後可拿來測的題目，標籤先由人工依規則訂好：

先測 zero-shot，再分別加上一組與多組示範；保持模型版本、設定及測試輸入一致，保留完整上下文並重複測試。檢查分類是否符合政策、是否只輸出一個合法標籤，以及哪些案例持續出錯。示範更多也會佔用輸入 token，需要一起記錄成本與延遲。

比較 shot 數量時，先保留同一套分類規則，只調整示範。如果連規則和測試題目都一起改，最後就算答對了，也很難知道是哪個改動有用。

參考資料與整理範圍

• Sabrina Goldfarb，Practical Prompt Engineering for Developers：本篇整理 Core Prompting Techniques 的 Standard Prompt 與三種 shot 用法；Context Placement 另見獨立文章。原站標示文字內容為 CC BY-NC 4.0，程式範例與練習為 Apache 2.0。
• Brown 等人，Language Models are Few-Shot Learners：上下文示範與 GPT-3 的研究背景。

來源於 2026-10-16 查閱。本篇為概念摘要與自編案例，非逐字翻譯；未涵蓋 Advanced Prompting Techniques。本文未執行 Issue 分類的模型測試，預期標籤不構成品質提升的證據。