你寫了一段 prompt，叫 Claude 幫你把一批客訴分類。跑出來一看，一半分錯。你回頭改措辭，把「請分類」改成「請仔細分類」，再跑，還是錯。第三次你開始加那種強調詞：「務必」「一定要」「非常重要」，彷彿多喊幾聲它就會認真一點。結果呢？該錯的還是錯。

這個場景我猜你不陌生。大部分人卡在這裡，直覺反應都是「我技巧不夠，得去學 prompt engineering」，然後收藏了一堆「50 個 prompt 咒語」的文章。但你有沒有想過，問題可能不在你會的技巧太少，而在「你在自己硬寫」這件事本身。

先試過的那幾條死路

加強調詞沒用，這件事其實有道理。模型不是聽你「語氣」做事的，你把「務必」講十遍，對它來說跟講一遍差不多。真正決定輸出品質的，是 prompt 的結構。任務講清楚了嗎？輸入輸出的邊界標出來了嗎？有沒有給它一兩個範例，讓它知道「對的長什麼樣」？

我試的第二條路是狂貼範例。這條有效一點，但很快就亂了：範例格式不統一、跟指令混在一起，prompt 變成一大坨，自己回頭看都眼花。手動整理這些結構是苦工，而且是那種「你知道該做、但很不想做」的苦工。

原來這步不用自己做

轉折點是我發現 Anthropic 的 Console 裡，早就內建了兩個專門幹這件苦工的工具。

第一個叫 Prompt 產生器。你不用從空白頁開始，只要用大白話描述你想做什麼（例如「幫我把客訴分成退款、物流、產品問題三類」），它就直接吐一份結構完整的 prompt 給你，該有的角色設定、任務說明、輸出格式都幫你排好。這東西治的是「空白頁恐懼症」：很多人 prompt 寫不好，不是不會寫，是根本不知道從哪個字開始打。

第二個叫 Prompt 改善器，這個更貼近前面那個分類的困境。你把已經寫好、但效果不佳的 prompt 貼進去，它會幫你做四件事：補上 XML 標籤把各區塊框清楚、加入 chain-of-thought（讓模型先想再答）、把你散落的範例標準化重整、還有整體潤飾。

打個比方，它就像你身邊突然多了一位不用錢的文案編輯。你交出去的是一份自己寫的草稿，它退回來的是一份排版工整、邏輯分明、還幫你把該補的例子補好的定稿。你不用懂排版規則，它懂就好。

到底有沒有用，看數字

這種工具最容易讓人懷疑「是不是只是把 prompt 弄得比較漂亮而已」。Anthropic 官方文件給了兩個實測數字：套用改善器之後，一個多標籤分類任務的準確率提升了 30%；另一個摘要任務，原本常常字數超標，改善後字數達標率拉到了 100%。

我得誠實說，這兩個數字是官方文件寫的，我沒在自己的專案上跑過同樣的對照實驗。但方向是合理的。當結構和 chain-of-thought 被正確補上，模型的表現本來就會穩定得多。這也是為什麼準確率能跳這麼多：改的不是措辭，是骨架。

它幫不了你的那部分

工具再好，也有它碰不到的地方，這點得講清楚，不然你會期待落空。

改善器懂 prompt 的通用結構，但它不懂你的業務。你那三個分類「退款、物流、產品問題」之間的模糊地帶該怎麼判、哪些邊緣案例要歸到哪一類，這種只有你和你的資料知道的東西，工具補不出來。它給你的是一副好骨架，血肉還是得你自己填。另外，如果你的 prompt 裡有變數（那種要動態帶入內容的 {{佔位符}}），套改善器前要確認它有被保留下來，不然改完直接壞掉。

所以完整的用法是這樣：先用產生器把起手式生出來，或把手上的爛 prompt 丟進改善器打磨骨架，接著用它附的 Test Case Generator 補幾組測試範例，跑一輪、看哪裡不對、再回饋迭代。把「搭結構」這種機械活外包給工具，你自己專注在「判斷對錯」這種只有你能做的事。

回到開頭那個分類到一半分錯的場景。現在你會怎麼做？不會再是加第四個「務必」。你會把那段 prompt 整個貼進改善器，讓它把結構補齊、把你散落的範例收好，然後你把時間花在真正的重點上——想清楚那些邊緣客訴到底該怎麼分。調 prompt 最有效的第一步，往往就是承認這一步不該由你手動來調。

參考來源（Anthropic 官方）