提示工程基礎：把話講清楚，再給幾個好範例

很多人以為提示工程（prompt engineering）是「會下神奇咒語」，其實它更像工程：把你已經寫出來的提示，一輪一輪改到能穩定產出高品質結果。每一輪改動都要能被量測，而不是憑感覺。

這篇用同一個例子（替運動員產生一日餐單）帶你走完整個迭代流程，每套用一招，分數就跳一次，效果看得到。這篇把入門最有效的三招整理給你。

提示工程是一個循環，不是一次定稿

整個流程拆成五步，你可以一直重複到滿意為止：

1. 設定目標：定義這個提示要完成什麼
2. 寫初版提示：先求有，不求好
3. 評測：用一致的標準測它的表現
4. 套用提示工程技巧：一次改一件事
5. 再評測：確認改動真的有效

示範任務是「替運動員產生一日餐單」：提示要吃進身高、體重、目標與飲食限制，產出完整的餐飲計畫。初版故意寫得很隨便，只問「這個人該吃什麼」，評測拿了 2.32 分（滿分 10 分）。別灰心，低分的初版正是基準線的用途：之後每一招值多少分，都量得出來。

評測的做法有個現成雛形：先描述任務與輸入欄位，自動生成少量測試案例（開發期兩三筆就好，迭代才快），再讓評分模型依你補充的標準打分數，產出總分與逐案的詳細報告。報告會寫出每個案例為什麼扣分，那正是下一輪改進的線索。

第一招：把話講清楚、講直接

提示的第一句是整份提示最重要的部分。「清楚」是指用誰都看得懂的簡單語言，直說你要什麼；「直接」是指用指令，不用問句，開頭放動作動詞：寫、產生、列出。

對比一下就有感：與其寫「我最近在看再生能源的東西，地熱好像不錯，哪些國家在用啊」，不如寫「列出三個使用地熱能源的國家，並附上各國的發電數據」。前者讓 Claude 猜你要什麼，後者直接告訴它。

回到餐單例子：初版的「這個人該吃什麼」改成「替運動員產生符合其飲食限制的一日餐單」，一句話就講明了動作（產生）、產物（餐單）與限制（一日、運動員、飲食限制）。光這一改，評測分數就從 2.32 跳到 3.92。

第二招：講得具體

「寫一篇角色發現隱藏天賦的短篇故事」這種提示，Claude 有一百種寫法：兩百字或兩千字、一個角色或五個角色，全看它當下怎麼發揮。加上明確的準則，輸出的穩定度與品質會立刻不同。具體化有兩種做法，實務上常一起用：

• 輸出品質準則：列出成品該有的樣子，包含長度、結構、必含元素、語氣風格
• 流程步驟：要 Claude 先腦力激盪、再挑選、再產出，適合需要多角度思考的複雜問題

餐單提示加上六條準則（標明每日總熱量、寫出蛋白質脂肪碳水的份量、標示用餐時間、只用符合限制的食材、份量以公克計、提到預算就控制預算）之後，評測分數從 3.92 跳到 7.86，直接翻倍。

建議是：品質準則幾乎每個提示都該有；流程步驟則留給疑難排解、決策分析這類需要面面俱到的任務，例如分析業績下滑時，引導 Claude 逐一檢視市場、產業、個人表現、組織與客戶回饋，而不是抓著單一原因猛打。

第三招：給範例，讓 Claude 看著學

在提示裡放入「輸入與理想輸出」的配對，就是所謂 one-shot（一個範例）與 multi-shot（多個範例）提示。它最能發揮的地方是邊角案例。舉個推文情緒分類的例子：「是喔，這真是我看過最棒的電影呢」表面看是正面，實際上是反諷的負評。

這種微妙的判斷很難用指令描述清楚，但給一個反諷範例並標注正確答案，Claude 就懂了。

• 捕捉邊角案例與例外情境
• 定義複雜的輸出格式（例如特定的 JSON 結構）
• 示範你要的語氣與風格
• 展示模稜兩可的輸入該怎麼處理

兩個實務訣竅：一，範例用 XML 標籤包起來（例如 sample_input 與 ideal_output），界線清楚；二，別只丟範例，補一句「這個輸出好在哪」，Claude 學到的就不只是格式，還有背後的理由。

範例哪裡找？你的評測報告就是寶庫：把得分最高的輸出挑出來，配上原本的輸入放進提示，等於直接告訴 Claude 什麼叫做滿分。