Prompt engineering 是什麼:不是咒語,是把需求寫成規格

很多人第一次聽到 prompt engineering，會以為它是一套 AI 咒語：「只要在句尾加上 step by step，模型就會變聰明」、「只要叫它扮演專家，答案就會專業」。

這個理解有一半對，也有一半危險。

對的是，你怎麼問，確實會影響模型怎麼答。危險的是，如果把 prompt engineering 當成神祕咒語，很快就會掉進複製模板、堆疊形容詞、把責任丟給模型的坑。

Prompt engineering 是設計自然語言指令、上下文、範例與輸出格式，讓 AI 模型更穩定完成任務的實務方法。

簡短版：prompt engineering 不是把話講得更華麗，而是把需求寫成模型能執行、團隊能測試、系統能維護的規格。

Prompt 是模型看到的工作單

LLM 不像傳統軟體那樣吃固定欄位、跑固定邏輯。它讀的是文字、圖片、檔案、工具結果，再根據這些輸入生成下一步輸出。

這些輸入統稱為 prompt。

一個 prompt 可以很短：

用三句話解釋什麼是 RAG。

也可以像一張完整工單：

你是 B2B SaaS 客服主管。

任務:
根據下方客戶來信,判斷問題類型、緊急程度,並草擬一封繁體中文回覆。

限制:
- 不承諾退款。
- 如果資料不足,列出需要客服確認的問題。
- 語氣要清楚、專業,不要過度熱情。

輸出格式:
1. 問題類型
2. 緊急程度
3. 建議回覆
4. 需要補問的資訊

客戶來信:
...

兩者都叫 prompt。差別在於第二種把任務、限制、角色、輸出格式與上下文拆清楚，模型比較不需要猜。

好 prompt 通常有五個零件

不同平台的文件用詞不完全一樣，但實務上可以先看五個零件。

零件	它解決什麼問題	例子
任務	告訴模型要做什麼	「摘要這份合約的付款條款」
上下文	告訴模型應該依據什麼資料	客戶來信、公司政策、產品文件
限制	告訴模型不能做什麼或必須遵守什麼	不要猜測、不要引用來源外資料、限 300 字
範例	告訴模型「做對」長什麼樣	兩組輸入與理想輸出
輸出格式	讓結果可讀、可接系統、可檢查	JSON、表格、條列、固定欄位

新手常犯的錯，是只寫任務。

「幫我寫一封信」太鬆。「根據這封客訴信，用客服主管語氣寫 120 字內回覆，先道歉、再說明下一步，不要承諾賠償」就比較像可執行規格。

這不是因為模型需要被哄。是因為真實工作本來就需要規格。人類同事如果只收到「幫我處理一下」也會做歪。

Prompt engineering 不是越長越好

很多人以為 prompt 寫越長，模型越聽話。實務上不是。

長 prompt 有三個風險。

第一，指令互相打架。前面說「精簡」，後面又說「詳盡展開」，模型只能猜哪個比較重要。

第二，重點被淹沒。資料、範例、限制、輸出格式混在一起，模型可能漏掉關鍵限制。

第三，維護成本上升。團隊沒有人敢改一段三千字 prompt，最後它就變成誰也不懂的黑盒。

比較好的方向是：清楚、分段、可測試。

把 prompt 寫成幾個穩定區塊：

角色 / 背景
任務
資料
限制
輸出格式
最後再次提醒最重要的限制

這樣不是為了美觀，而是讓人和模型都知道哪一段在負責什麼。

Few-shot:用範例教模型格式與品味

Few-shot prompting 是在 prompt 裡放幾個「輸入 → 理想輸出」範例，讓模型模仿模式。

它特別適合三種場景。

第一，分類。 例如把客服訊息分成「付款」、「功能」、「帳號」、「其他」。

第二，格式。 例如每次都輸出同一種 JSON schema。

第三，品味。 例如品牌語氣、編輯標題、客服回覆的分寸。

例如：

請把使用者問題分類成 billing / bug / account / other。

範例:
輸入: 我信用卡被刷了兩次
輸出: billing

輸入: 登入後一直跳回首頁
輸出: bug

現在分類:
輸入: 我想改公司信箱
輸出:

這比單純說「請正確分類」有效，因為模型看到的是你定義的邊界。

但 few-shot 也不是萬靈丹。範例如果品質差、彼此不一致，模型會學到壞規則。範例如果太多，又會擠掉真正任務資料的 context。

System prompt:不是萬能最高權限，但很重要

很多產品把 prompt 分成不同層級。常見做法是用 system 或 developer instruction 放長期規則，再用 user prompt 放當次任務。

例如：

System:
你是公司內部客服助理。只能根據提供的政策文件回答。資料不足時說明需要人工確認。

User:
這位客戶問能不能退款,請根據下方政策草擬回覆。

System prompt 適合放：

• 長期角色與責任
• 安全與合規限制
• 語氣與輸出原則
• 工具使用規則
• 不能被一般使用者任意改掉的產品邏輯

但不要誤會：system prompt 不是保險箱。它可以提高遵循度，不能取代權限控管、資料隔離、工具審核與輸出檢查。

如果 AI 助手能退款，真正的安全邊界應該在後端權限與審批流程，不是只寫一句「請不要亂退款」。

Chain-of-thought:它改變了 prompting，但不要迷信口號

2022 年的 chain-of-thought prompting 論文讓很多人注意到：對某些算術、常識與符號推理任務，在範例中展示中間推理步驟，可以改善大型模型表現。

這是 prompt engineering 歷史上重要的一步，因為它說明 prompt 不只是在問問題，也可以示範「怎麼想」。

但今天使用時要更克制。

第一，不同模型對推理指令的反應不同。一般文字模型、reasoning model、多模態模型，最佳提示方式不一定一樣。

第二，「請一步一步想」不是萬用修復。資料不足、工具沒接、問題定義錯，再怎麼要求思考也不會變成可靠答案。

第三，在產品裡，你通常更需要可驗證的輸出，而不是模型公開一長串看似合理的內心獨白。更穩的做法是要求模型列出假設、引用依據、檢查清單或計算結果，讓人能驗證。

真正的 prompt engineering 應該有 eval

如果一段 prompt 只在你當下測過一次，它還不是工程，比較像手感。

Prompt engineering 之所以有 engineering，關鍵在 eval。

你需要一組代表真實工作的測試題：

• 常見問題
• 邊界案例
• 惡意或模糊輸入
• 資料不足的情境
• 不同語氣、不同格式、不同長度的輸入

然後看 prompt 改版後，模型在這些題目上有沒有更好。

對內容團隊，eval 可以是「摘要是否保留關鍵事實」、「標題是否避免誇大」、「是否使用繁體中文」。對客服團隊，eval 可以是「是否承諾了不該承諾的事」、「是否列出需要補問資訊」。對工程團隊，eval 可以是 JSON 是否 valid、欄位是否齊全、工具參數是否正確。

沒有 eval,prompt 會變成玄學。今天覺得好，明天換模型、換資料、換使用者說法，就不知道哪裡壞掉。

它跟 fine-tuning 差在哪

Prompt engineering 不改模型參數。它改的是模型當下看到的指令與上下文。

Fine-tuning 則是用訓練資料調整模型行為，讓模型更常產生你要的模式。

粗略分：

問題	優先考慮
任務還沒定義清楚	Prompt engineering
需要放公司政策、文件、當次資料	Prompt + RAG
需要固定輸出格式	Prompt + structured output / schema
模型反覆學不會某種穩定風格或任務	Fine-tuning
需要接外部系統做動作	Tool calling

多數團隊一開始不需要 fine-tuning。先把 prompt、資料、工具、eval 做好，通常就能解掉 80% 的問題。

對台灣團隊的判斷

台灣企業導入 AI 時，常把 prompt engineering 當成「找一個很會問 ChatGPT 的人」。

這會低估它。

真正有價值的人，不是背了最多 prompt 模板，而是能把一個模糊流程拆成：

1. 模型要負責哪一步？
2. 哪些資料可以給模型？
3. 哪些答案必須引用來源？
4. 哪些情況要說不知道？
5. 哪些動作需要人工審核？
6. 怎麼測試它有沒有變好？

這比較像產品經理、編輯、客服主管、法務與工程師一起做流程設計。

例如一間 B2B 公司想做 AI 客服，不要先問「客服 prompt 怎麼寫」。先把退費政策、升級規則、例外條款、人工轉接條件整理清楚。prompt 只是最後把這些規則交給模型的介面。

如果公司流程本身混亂，prompt 再漂亮也只是把混亂包成流暢文字。

一句話收尾

Prompt engineering 是 AI 產品的介面設計。

它把人的需求、公司的規則、任務的上下文，翻成模型能處理的工作單。

好的 prompt 不會讓模型變成全知，但會讓它少猜一點、穩一點、比較容易被測試。這就是它真正的價值。

周詠晴（編輯：廖玄同），《Prompt engineering 是什麼:不是咒語,是把需求寫成規格》，矽基前沿 [Si]gnals，2026-04-26。https://signals.tw/articles/what-is-prompt-engineering/