提示詞工程基礎：實用辭彙表條目

提示詞工程是撰寫輸入文字的實踐，目的是讓語言模型產生你實際需要的輸出。它介於寫作和除錯之間：你不是以傳統意義上編寫程式碼，但你確實在測試模型如何解釋指令的假設，並在出現錯誤時反覆調整。

提示詞實際上是什麼

提示詞是你在模型生成回應前傳送給它的所有內容——指令、上下文、範例，以及實際的問題或任務。大多數現代聊天模型將這些分成角色：系統訊息（設定行為和約束條件）、使用者訊息（實際請求），有時還有助理訊息（先前的對話或範例）。如果你使用 OpenAI 或 Anthropic 這樣的 API，你會在程式碼中明確設定這些。如果你使用聊天介面，系統提示詞通常是隱藏的，或在對話開始時設定一次。

為什麼同樣的問題會得到不同的答案

語言模型根據在它之前的所有內容（包括你的措辭、字序，甚至標點符號）來預測下一個詞彙。問「解釋遞迴」會得到一般的教科書答案。問「向一位理解迴圈但不理解遞迴的初級開發人員解釋遞迴，用一個包含基本情況和遞迴情況的 Python 範例」，你會得到更有用的東西。你的輸入的具體性直接形塑了輸出的具體性。這是初學者需要掌握的核心洞察：模型不是在讀心術，而是在與你的措辭進行模式匹配。

值得首先學習的核心技巧

零樣本提示詞是指直接提問，沒有範例：「寫一個符合美國電話號碼的正規表示式。」這對常見的、定義明確的任務能運作得很好。

少樣本提示詞是指在要求模型繼續該模式之前，給模型一個或多個你想要的輸入/輸出模式的範例。如果你想讓模型將支援工單分類到各個類別，先給它看三個標記過的範例會產生比僅用文字描述類別更一致的結果。

思維鏈提示詞要求模型在給出最終答案前逐步推理，通常是透過直接新增「逐步思考」或要求它展示其工作。這有助於解決數學、邏輯和多步驟任務，但也增加了詞彙用量和回應長度。

角色提示詞為模型指派一個角色——「你是一位高級資安工程師，正在檢查這段程式碼是否有漏洞」——這能轉變語調、詞彙，以及它優先考慮的細節類型。它不會賦予模型新的能力，但會固定其輸出風格。

結構比聰明才智更重要

初學者常常假設提示詞工程是找到魔法短語的問題。實際上，結構幾乎每次都會勝過聰明才智。將你的提示詞分解成清晰的部分：上下文、任務、約束條件和格式。例如：

Context: You're reviewing a Python Flask app for a security audit.
Task: Identify SQL injection risks in the code below.
Constraints: Only flag issues in the /login and /search routes.
Format: Return a numbered list with the line number and a one-sentence explanation.

這類明確的格式化減少了歧義，如果你在指令碼中將提示詞串在一起，還能讓輸出更容易以程式設計方式解析。

早期常見的錯誤

一個常見的錯誤是含糊其辭偽裝成簡潔——問「讓這個更好」而不定義「更好」是什麼意思（更快？更易讀？更安全？）。另一個是在單一提示詞中塞進五個無關的任務，這往往會對全部五項產生膚淺的答案，而不是對一項的紮實答案。初學者也經常忘記模型在各個 API 呼叫之間沒有記憶，除非你明確地將先前的對話歷史傳回，這在建立任何有狀態的東西時會使人困惑。

像工程師一樣測試和反覆

把提示詞當作你要版本管理和測試的程式碼，而不是一次性丟掉的文字。對提示詞變化及其輸出保持記錄，尤其是對你會在生產環境中重複使用的任何東西，比如客戶支援機器人或程式碼檢查助手。小的措辭改變——「摘要」對比「摘要成確切的三個項目符號」——可以產生意義上不同的結果，而找出什麼適合你的用例的唯一方法是自己執行比較，而不是假設。

這如何融入建立真實的東西

一旦提示詞變得可靠，下一步通常是以程式設計方式使用：用為你的任務調整的溫度和 max_tokens 設定呼叫 API，為格式不良的輸出新增重試邏輯，以及在回應觸及使用者前驗證它們。那是提示詞工程開始與常規軟體工程紀律重疊的地方，也是從在聊天視窗中實驗轉移到撰寫實際指令碼的好時機。

如果你想進一步了解，請查看 Korra Studio 關於在 Python 中使用 LLM API 以及從頭開始建立小型 AI 驅動工具的章節。