提示詞工程入門：怎麼寫好 AI 提示詞

為什麼提示詞的寫法很重要

語言模型不知道你的處境，它只看得到你送出的文字。提示詞含糊時，模型會用最典型的答案填補空白，通常就是千篇一律、太長，或是對錯了讀者。提示詞工程的工作，大部分就是消除猜測。

有個好用的檢驗方法：一位從沒見過你的聰明新同事，只看你這則訊息，能把事情做好嗎？如果他得先問你三個問題，模型也需要這三個問題的答案。OpenAI、Anthropic 和 Google 的官方指南，用不同的說法給了相同的核心建議：清楚、具體，提供背景，給範例，說明你要的格式。

好提示詞的六個要素

不是每個提示詞都需要這六項，但對照這份清單，就能修好大多數寫得不好的提示詞。

較長的輸入素材，請放在清楚的標記之間，例如 XML 風格的標籤或三個引號，讓模型分得出哪些是你的指令，哪些是要處理的文字。這也能降低一種風險：輸入內容（例如貼上的網頁）裡藏著的指令，被誤當成命令執行。

改寫前後的對照

這是一個典型寫得不好的提示詞：

Summarize this article.

模型會寫出摘要，但長度是多少、給誰看、什麼形式？下面是補上這些空白之後的同一個請求：

You are helping a busy product manager decide whether to read a research article.

Summarize the article below for that reader.
- Start with one sentence: the main finding.
- Then 3 bullet points: method, key number, main limitation.
- Use plain English. Explain any technical term in a few words.
- Under 100 words in total.
- If the article does not state a limitation, write "No limitation stated".

<article>
{paste the article here}
</article>

各個部分的作用：

• 第一行設定了讀者與目的。模型現在知道摘要為何而寫，所以懂得取捨。
• 項目符號的結構固定了格式，每份摘要看起來都一樣，也方便比較。
• 字數限制避免模型灌水。
• 針對「沒有提到限制」的規則，告訴模型在邊緣情況該怎麼辦，而不是讓它編造一個。
• 標籤把文章與指令隔開。

文字說不清楚時，就給範例

有些要求很難用文字描述，卻很容易示範：說話的語氣、標記的分類方式、特定的輸出風格。加入幾個示範範例，稱為少樣本提示（few-shot prompting）。一個範例（one-shot）往往就有很大的幫助，兩到五個各不相同的範例，通常就能涵蓋主要情況。

Classify each support message as BILLING, SHIPPING, PRODUCT or OTHER.
Reply with the label only.

Message: I was charged twice for order 5521.
Label: BILLING

Message: The handle on my mug cracked after one week.
Label: PRODUCT

Message: Do you have a shop in Osaka?
Label: OTHER

Message: {new message}
Label:

讓範例彼此之間有差異。如果每個範例都又短又有禮貌，模型碰到又長又憤怒的訊息，可能就處理不好。也要確認範例與規則一致：模型對範例的模仿，比對文字指令的遵循更強烈。

針對特定情況的技巧

• 先要步驟，再要答案。數學、邏輯或多部分的決策，請模型先逐步推演，再給最終答案，可以提高準確度，這稱為思維鏈提示（chain-of-thought prompting）。許多現行的模型會在內部這樣做（常稱為推理或思考模式），所以只要求「仔細作答」可能就夠了。
• 拆分大任務。與其用一個提示詞要求「研究、列大綱再寫報告」，不如分成三個提示詞，逐一檢查每個輸出，這稱為提示詞串接（prompt chaining）。
• 角色設定要有資訊量才加。「你是越南的稅務會計師」會改變用詞與預設假設，「你是世界級天才」則什麼都沒增加。
• 說明要做什麼，而不只是要避免什麼。「用短句寫」比「不要囉嗦」有效。
• 允許說「我不知道」。告訴模型可以回答資料不足，能減少捏造的事實，雖然無法完全消除。
• 若輸出要交給程式讀取，就要求機器可讀的格式，例如帶有具名欄位的 JSON。多數 API 也能直接強制套用 JSON schema。

像測試程式碼一樣測試提示詞

在一個範例上有效的提示詞，可能在下一個就失敗。如果這個提示詞會重複使用，或要給別人用，就要測試：

1. 寫下好的輸出應有的樣子：長度、格式、必須正確的事實。
2. 收集 10 到 20 筆真實輸入，包含困難的：極短、極長、離題、另一種語言。
3. 對全部輸入執行提示詞，並閱讀每一份輸出。
4. 一次只改一個地方，然後整組重跑，才知道是哪項修改有幫助。
5. 把最終的提示詞和測試集放在一起。當你換模型，或模型更新時，重新跑一遍測試集。

最後一步很重要，因為同一個提示詞在不同模型、甚至同一模型的新版本上，表現可能不一樣。模型開發商的提示詞工程指南會隨時間改變，也是這個原因。

常見的錯誤

• 一個提示詞塞了太多目標。十條同等重要的規則，會有一部分被忽略。把最重要的規則放前面，清單保持簡短。
• 自相矛盾，例如「要詳細」又要「50 字以內」。模型會滿足其中一項，違反另一項。
• 靠大寫字母或威脅語氣（「你必須」）而不是清楚的理由。簡短說明規則為何存在，通常效果更好。
• 沒有把輸入與指令分開，結果模型把你文件的一部分當成命令。
• 盲目相信輸出中的事實。寫得再好的提示詞，仍會產生信心十足的錯誤。人名、數字、引述和連結都要查證。