工具-提示工程

🎯 什麼情境該想到我

當你用 LLM 但輸出不穩、不照指示、格式亂時——這是第一個、最便宜的調整手段。

⚙️ 怎麼用

1. 清楚具體的指示：說明角色、任務、限制、輸出格式；把「要什麼」講到不需要猜。
2. 給範例（few-shot）：示範幾組輸入→輸出，比純描述更有效。
3. 要求結構化輸出：指定 JSON/schema，方便下游程式解析、也減少亂答。
4. 引導推理：複雜任務讓它「先想再答」（分步/思考），別逼它一步跳到結論。
5. 迭代：用固定測試集比較不同版本（配 工具-AI系統評估），別憑感覺調。

★ 書中的五條最佳實踐（《AI 工程》第 5 章）

書說這些是從 OpenAI、Anthropic、Meta、Google 的提示指南以及成功上線的團隊經驗中提煉出來、對大多數模型都有效的通用技巧；早期那些「寫 Q: 而不是 Questions:」「承諾給 300 美元小費」的招數，會隨著模型變強而失效。

實踐	具體做法
寫清楚明確的指令	無歧義地說明要做什麼（例：評分標準是 1–5 還是 1–10？遇到不確定時怎麼辦？）；請模型扮演角色；給範例；指定輸出格式
提供足夠的脈絡	把需要的資料放進提示；需要時限制模型只能用提供的資訊回答
把複雜任務拆成簡單的子任務	例：先分類客服問題的類型，再依類型用不同的提示處理
給模型時間思考	要求逐步推理（chain-of-thought）或自我批判
迭代提示	每次修改都用同一組測試比較

書也提醒拆解與 CoT 的代價：更多次模型呼叫、更多 token → 延遲與成本上升。

★ 拆解的好處不只是準確度

書列出拆解提示的其他好處，工程上特別重要的是：

• 監控：可以分別看每個子任務的表現，知道是哪一步出錯。
• 除錯：失敗時可以定位到具體的子提示。
• 平行化：互不依賴的子任務可以同時送出。
• 省力：寫簡單的提示比寫複雜的提示容易。

缺點是使用者感受到的延遲可能增加，尤其是使用者看不到中間輸出的任務。

★ 把提示當成程式碼管理

書建議把提示和程式碼分開：放在獨立的檔案（或提示目錄），程式碼用名稱引用。好處包括：

• 多個應用可以重用同一個提示。
• 提示可以獨立測試。
• 非工程人員（領域專家）可以參與修改提示，而不用碰程式碼。

更進一步，書建議為每個提示附上中繼資料：適用的模型、建立日期、用在哪個應用、建立者；提示模板也可以記錄理想的取樣參數（temperature、top-p）與輸入／輸出的 schema。記錄模型特別重要——同一個提示換了模型，行為可能完全不同。在 Go 裡可以用 embed 把提示檔在編譯時嵌入二進位檔，版本跟著程式碼一起走：

//go:embed prompts/classify_ticket.v3.md
var classifyTicketPrompt string

★ 提示修改的評估流程

1. 建一組固定的測試案例（包含典型案例與過去出錯的案例）。
2. 修改前跑一次，記錄結果。
3. 修改提示。
4. 再跑一次，比較整體分數，也看個別案例的變化——改善了 5 個案例、弄壞了 2 個，要知道是哪 2 個。

沒有評估集就改提示，就像沒有測試就重構（見 工具-AI系統評估、工具-AI改動的AB對照評測）。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 提示改一點行為可能大變 → 一定要有評估集把關，否則是在瞎調。

• 提示是攻擊面：使用者輸入和檢索進來的文件都可能包含「忽略前面的指令」這類注入。系統提示不是安全邊界，權限控制要在程式碼層做（見 提示注入與分層防禦）。

• 長而固定的系統提示可以利用前綴快取降低成本與延遲：把不變的部分放在最前面，變動的部分放在後面（見 前綴快取 Prompt Caching）。

🔗 相關工具

• 工具-AI系統評估 —— 提示改一點行為就大變；沒有固定評估集比較版本，你只是在瞎調
• 工具-RAG檢索增強生成 —— 提示調到頂還是答錯事實時的下一步：把知識餵進上下文，而不是繼續改字
• 工具-上下文學習的示例怎麼挑怎麼排、工具-思維鏈的變體怎麼選 —— 範例怎麼挑、什麼時候該或不該叫模型一步一步想（含「對話模型加了反而變差」的反向條件）