這篇文章整理我在使用大型語言模型（LLM）時常用的提示工程策略。當你發現模型的回答不夠精準、常常出錯或答非所問，問題往往不在模型本身，而在提示詞的設計方式。我依照 OpenAI 官方指引，把獲得更好結果的方法歸納成六大策略，並附上每個策略底下的具體做法。
為什麼提示詞寫法會直接影響 LLM 的輸出品質？
語言模型是根據輸入的文字來預測最可能的輸出，所以提示詞裡給了多少細節、有沒有明確的步驟和格式要求，會直接決定答案的相關性與正確性。同一個問題，模糊的問法和清楚的問法可能得到完全不同品質的結果。底下六個策略就是圍繞「把話說清楚、給足素材、拆小任務、留思考時間、善用工具、量化驗證」這條主線展開的。
六大策略有哪些？
| # | 策略 | 一句話重點 |
|---|---|---|
| 1 | 寫清楚的說明 | 給足細節、指定角色、步驟、範例與輸出長度 |
| 2 | 提供參考文本 | 讓模型依據你給的資料回答並附引用 |
| 3 | 拆分複雜任務 | 把大任務重構成一串簡單子任務的工作流 |
| 4 | 給模型時間「思考」 | 要求思維鏈，先推理再下結論 |
| 5 | 使用外部工具 | 用檢索（RAG）、程式執行補足模型弱點 |
| 6 | 系統地測試更改 | 用 eval 測試套件量化每次提示詞修改的效果 |
策略一：寫清楚的說明
模型無法讀心，指令越具體，答案越相關。我常用的做法包括：
- 在查詢中包含詳細資訊，以獲得更相關的答案
- 要求模型採用角色（例如「你是一位資深保單審核員」）
- 使用分隔符（如 ` ``` ` 或 XML 標籤）清楚地指示輸入的不同部分
- 指定完成任務所需的步驟
- 舉例說明（few-shot），給一兩個輸入輸出範例
- 指定所需的輸出長度（例如「用三句話、不超過 200 字回答」）
- 提供參考文本作為回答依據
策略二：提供參考文本
語言模型可能會捏造（幻覺）不存在的答案，特別是在被問到冷門主題或需要引用具體來源時。對抗方式是餵給模型參考文字：
- 指示模型使用參考文本回答問題
- 指示模型使用參考文本的引用（citations）來回答，方便驗證答案出處
這個做法也是 RAG（檢索增強生成）的核心思路。
策略三：將複雜的任務拆分為更簡單的子任務
正如軟體工程中的良好做法是將複雜系統分解為一組模組化元件一樣，提交給語言模型的任務也是如此。複雜任務往往比簡單任務具有更高的錯誤率。此外，複雜任務通常可以重新定義為更簡單任務的工作流，其中早期任務的輸出用於構造後續任務的輸入。我常見的三種拆法：
- 使用意圖分類來標識與用戶查詢最相關的指令
- 對於需要很長對話的對話應用程式，總結或過濾以前的對話
- 分段總結長文檔，並以遞迴方式構建完整的摘要
策略四：給模型時間「思考」
如果要求你把 17 乘以 28，你可能不會立即知道答案，但仍然可以隨著時間的推移計算出來。同樣地，模型在試圖立即回答時會犯更多的推理錯誤，而不是花時間找出答案。在回答之前要求一個「思維鏈」（chain of thought），可以幫助模型更可靠地推理出正確的答案：
- 在匆忙得出結論之前，指示模型先制定自己的解決方案
- 使用內心獨白或一系列查詢來隱藏模型的推理過程（只對使用者呈現最終答案）
- 詢問模型在之前的過程中是否遺漏了任何內容
策略五：使用外部工具
透過向模型提供其他工具的輸出，可以補償模型本身的弱點：
- 文本檢索系統（有時稱為 RAG 或檢索增強生成）可以告訴模型相關文檔的資訊
- 像 OpenAI 的 Code Interpreter 這樣的程式碼執行引擎，可以幫助模型進行數學運算和執行程式碼
- 透過 function calling 授予模型對特定函數的存取權限
如果一項任務可以透過工具而不是語言模型更可靠或更高效地完成，就把它卸載給工具，充分利用兩者的長處。
策略六：系統地測試更改
如果可以衡量性能，就更容易提高性能。在某些情況下，對提示的修改會在幾個孤立的示例上獲得更好的性能，但在更具代表性的示例集上反而導致整體性能較差。因此，為了確保更改對性能有淨正面影響，需要定義一個全面的測試套件（也稱為「eval」）：
- 參考黃金標準答案（golden answers）來評估模型輸出
把提示詞的調整當成程式碼修改一樣對待：有測試、有基準、有量化指標，才敢說這次改動是進步。
延伸閱讀
- Prompt engineering 提示工程：獲得更好結果的六種策略：同樣聚焦 Prompt Engineering、LLM，可接著比較不同情境的做法。
- 提示工程框架的概念：明確提問、In-Context Learning、CoT 與 ToT：同樣聚焦 Prompt Engineering、LLM，可接著比較不同情境的做法。
- ReAct Prompting 是什麼？Reasoning/Acting 如何讓 LLM 邊推理邊行動：同樣聚焦 LLM、Prompt Engineering，可接著比較不同情境的做法。
常見問題
什麼是提示工程（Prompt Engineering）？
提示工程是設計與優化輸入給語言模型的提示詞，以獲得更準確、更相關輸出的方法論。它包含寫清楚指令、提供範例、拆分任務、結合外部工具等系統性技巧，而不是碰運氣的試錯。
提示詞寫越長越好嗎？
不是。重點是資訊密度與結構，而不是長度。冗長但含糊的提示詞不如簡短但具體（含角色、步驟、格式、範例）的提示詞有效，過長的上下文甚至可能稀釋關鍵指令。
什麼是思維鏈（Chain of Thought）？
思維鏈是要求模型在給出最終答案前，先逐步寫出推理過程的技巧。因為模型「邊想邊寫」比「直接搶答」更不容易出推理錯誤，這對數學、邏輯和多步驟任務特別有效。
RAG 和提示工程有什麼關係？
RAG（檢索增強生成）是提示工程策略「提供參考文本」的工程化實現：先從外部知識庫檢索相關文件，再放進提示詞讓模型據此回答，能有效減少幻覺並提供可驗證的引用。
如何知道改提示詞真的有幫助？
建立一組代表性測試範例（eval suite）與黃金標準答案，每次修改提示詞後在同一組範例上量化比較。只看單一案例的好壞容易誤判，整體指標變好才是真的進步。
參考資料
最後更新
2026-08-28（原文發布於 2024-06-07，本文保留原始筆記內容並補上 GEO 結構。）
關於作者 {#author}
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2024-06-07