偉龍blog

從提示詞工程開始:用系統化 Prompt 讓大模型輸出更穩定的實戰指南

—

由

Edwin
于

如果你已經跟著前面幾篇把 LLM API、RAG、AI Agent 都跑通了,大概率遇過這種尷尬:同一個模型、同一個問題,昨天回答得頭頭是道,今天就開始胡言亂語。換模型?調溫度?都不是根本解法。真正的原因,通常藏在你的 Prompt 裡。這篇我們來補上大模型應用的「第零積木」——提示詞工程(Prompt Engineering),讓模型的輸出從「憑手感」變成「可預期」。

一、為什麼你的 Prompt 時靈時不靈

先建立一個心態:大模型本質上是一台「高級補全機」,它不是在「理解」你,而是在根據上下文機率性地補全最合理的續寫。所以當你只寫「幫我總結這段文字」,模型只能靠猜:總結成一句話還是十點清單?正式還是口語?給老闆看還是給自己看?含糊的指令,就是把答案交給運氣。一個穩定的 Prompt 通常包含三個要素:

  • 角色(Role):告訴模型「你是誰」,例如「你是一位資深客服品管主管」,讓它對齊語氣與專業度。
  • 任務(Task):明確要做什麼,輸入是什麼、輸出長什麼樣。
  • 約束(Constraints):邊界條件,例如輸出格式、選項枚舉、「資料不足就回答無法判斷」。

二、五個立刻能用的技巧

  • 給範例(Few-shot):與其描述規則,不如直接給一兩組「輸入→期望輸出」的範例。模型的模仿能力,遠強於它的閱讀理解能力。
  • 要求結構化輸出:明確要求 JSON 並給出欄位定義,下游程式碼才好解析,別讓程式去猜自由文字。
  • 先分析再回答:加一句「請先逐步分析,最後再給結論」,能明顯降低推理題的錯誤率。
  • 允許說不知道:加入「如果資料不足以回答,請回答無法判斷」,這是抑制幻覺最便宜的手段。
  • 用分隔符隔開指令與資料:把使用者輸入包在明確標記裡,避免使用者的話被當成你的指令執行(順手防一層提示注入)。

三、實戰:把含糊 Prompt 改造成穩定 Prompt

以一個常見需求為例:把客戶留言自動分類並標記緊急程度。先看最低可用版本:

const badPrompt = `請幫我分析這筆客戶留言:\n${message}`;

這種寫法的輸出每次都不一樣,後端根本沒法接。我們按步驟改造它。

步驟 1:加角色、任務與約束。

const systemPrompt = `你是一位電商客服品管專家。
任務:分析客戶留言,判斷意圖分類與緊急程度。
約束:
1. category 只能是:退換貨/物流/商品諮詢/其他
2. urgency 只能是:high/medium/low
3. 若留言資訊不足,urgency 填 low,reason 寫「資訊不足」
4. 只輸出 JSON,不要任何多餘文字`;

步驟 2:要求結構化輸出並給範例。

const userPrompt = `
留言內容:
"""${message}"""

請嚴格依以下 JSON 格式輸出:
{"category": "...", "urgency": "...", "reason": "..."}

範例:
輸入:「我三天前買的東西到現在還沒出貨,再不處理就投訴!」
輸出:{"category": "物流", "urgency": "high", "reason": "表達明確不滿並揚言投訴"}`;

步驟 3:呼叫時鎖定參數。分類這種追求確定性的任務,把 temperature 調低(0~0.3),減少隨機性:

const res = await fetch('https://api.example.com/v1/chat/completions', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    Authorization: `Bearer ${apiKey}`,
  },
  body: JSON.stringify({
    model: 'gpt-4o-mini',
    temperature: 0.2,
    messages: [
      { role: 'system', content: systemPrompt },
      { role: 'user', content: userPrompt },
    ],
  }),
});
const { choices } = await res.json();
const result = JSON.parse(choices[0].message.content);

步驟 4:建立壞案例回歸測試。把曾經翻車的留言存成測試集,每次改 Prompt 就重跑一遍,確認沒有「改好一個、弄壞三個」。重點:Prompt 是程式碼,不是聊天紀錄——要有版本、要有測試。

四、把 Prompt 當程式碼管理

  • 抽成獨立檔案:不要讓長字串散落在業務程式碼裡,集中放到 prompts/ 目錄統一維護,改起來一目瞭然。
  • 記錄版本與效果:每次修改都註明改了什麼、為什麼改、測試集通過率多少,出問題才回滾得動。
  • 重要規則放頭尾:模型對開頭與結尾的注意力最強,核心約束放在系統提示開頭,並在結尾重申一次。

特別注意:不要迷信「萬能咒語」。網路流傳的神奇 Prompt,大多是特定模型、特定任務上的過擬合結果。對工程師來說,可測試、可回滾的系統化 Prompt,遠比一句玄學咒語可靠。

互動話題:你有遇過模型輸出「時靈時不靈」的坑嗎?你都是怎麼調 Prompt 的?歡迎在留言區分享你的踩坑與調教經驗!