API 開發
提示工程進階:用 XML 標籤劃界線,用角色設定定調
提示工程進階:用 XML 標籤劃界線,用角色設定定調
上一篇講了把話講清楚、講具體、給範例,那是提示工程的入門三招。這篇往前一步,處理提示變長變複雜之後必然遇到的兩個問題:資料和指令攪在一起,以及 Claude 的行為抓不準。
解法分別是 XML 標籤與角色設定。兩招都不難,但用與不用,提示的可靠度差一個檔次。
你將學到什麼
為什麼提示需要結構
指令與資料混在一起時,Claude 會分不清界線在哪。
XML 標籤實戰
用自訂的標籤名稱包住資料、程式碼與文件。
角色設定的力量
system prompt 如何整段改變 Claude 的行為與語氣。
兩招合體的完整提示
角色加結構的可靠提示長什麼樣子。
當提示塞進大量資料,界線就是一切
想像你請 Claude 分析二十頁的銷售紀錄:指令一句、資料一大坨,全部攪在一起送出去。Claude 可能分不清哪句是你的要求、哪段是要分析的資料,甚至把資料裡的句子誤當成指令。
這個問題有個名字,叫內容邊界。人在讀文件時靠排版與標題判斷每段的屬性,模型讀到的卻是一條連續的文字流,你不給記號,它就只能靠猜。
除錯的場景更明顯:你同時貼上自己的程式碼和一段官方文件,請 Claude 找出程式的問題。兩坨文字沒有邊界,Claude 幾乎不可能分清哪段是誰的。解法出奇地簡單:用 XML 標籤把每一塊內容包起來。
<my_code>
...你的程式碼...
</my_code>
<docs>
...官方文件的內容...
</docs>
請依據 docs 裡的說明,找出 my_code 裡的錯誤。
包起來之後,指令可以直接引用標籤名稱,Claude 對「哪段是程式、哪段是文件」再也不會有歧義。你可能會想:Claude 這麼聰明,真的分不出來嗎?多數時候它猜得對,但「猜」正是不穩定的來源。提示工程要的是每次都對,而不是通常都對,所以與其讓它猜,不如把界線畫出來。
標籤名稱自己取,越具體越好
這些不是官方規定的 XML 標籤,你可以取任何名字。訣竅只有一個:取描述性的名稱。sales_records 勝過 data,athlete_information 一看就知道裝的是運動員資料,my_code 與 docs 一眼分開兩種內容。名稱越具體,Claude 越能理解每段的用途。命名時也要保持前後一致:開頭用了什麼名字,結尾與指令裡就用同一個。什麼時候最值得用:
- 提示夾帶大量脈絡或資料時
- 混用多種內容(程式碼、文件、資料)時
- 想把內容邊界講到明明白白時
- 複雜提示需要插入多個變數時
實際用起來長這樣:
<athlete_information>
- Height: 6'2"
- Weight: 180 lbs
- Goal: Build muscle
- Dietary restrictions: Vegetarian
</athlete_information>
Generate a meal plan based on the athlete information above.
簡單提示也許看不出巨大差異,但提示越長、內容越雜,XML 標籤的價值越高。它同時也是寫給未來自己看的:三個月後回來改提示,界線清楚的版本好維護太多了。
角色設定:讓 Claude 用對的身分說話
結構解決「資料歸資料」,角色設定則解決「行為與語氣」。做法是寫一段 system prompt:明確告訴 Claude 它是誰、該怎麼回應,透過 API 的 system 參數傳入,對整段對話持續生效。
經典例子是數學家教。學生問「5x + 2 = 3 怎麼解」,沒有角色設定時,Claude 熱心地直接給出完整解法;套上「有耐心的數學家教」角色後,它改成拋出引導性問題,帶著學生自己想出下一步。
system_prompt = """
You are a patient math tutor.
Do not directly answer a student's questions.
Guide them to a solution step by step.
"""
這段角色描述的寫法值得學:先講身分(有耐心的數學家教),再講行為準則(不直接給答案、要逐步引導)。身分加準則,比單獨一句「你是家教」有效得多。
另一個常見疑問:這些規則寫在 user 訊息裡不行嗎?可以動,但不穩:對話一長,混在內容裡的規則容易被稀釋。system prompt 是行為層級的設定,對整段對話持續生效,角色類的指引放在這裡才站得穩。
兩招合體:一份結構完整的提示
把角色設定與 XML 結構疊起來,就是實務上可靠提示的樣子:
範例也吃這一套結構:把示範輸入與理想輸出分別包進 sample_input 與 ideal_output 標籤,Claude 一眼就看懂哪段是示範、哪段是正式輸入。順帶一提,範例的說明文字也值得放:在理想輸出後面補一句「這個輸出好在哪」,Claude 學到的就不只是格式,還有判斷的理由。
角色定調、標籤劃界,再配上清楚的指令與好範例,這四塊拼起來,你的提示就從「大概可以」進化到「每次都行」。
最後提醒一件事:結構是手段,不是目的。標籤包得再漂亮,指令含糊、範例失準,結果一樣不會好。先用入門三招把內容做對,再用這一篇的結構把邊界畫清楚,兩層都到位,才是完整的提示工程。
延伸學習
HE201|Harness Engineering System Design(6 小時)
六小時的實作課:從 Blueprint 走到可以跑的規格,再用 No-code、n8n 低程式碼與程式碼三條路各做一次同一個 harness,最後處理可靠度——重試、錯誤處理、人工覆核。7 章 54 課,含常見坑與排錯、Capstone 實作,附學員講義 PDF。
NT$ 5,999
ChatGPT 很強,但真正讓你下班的是 Google
六小時完整實錄。從「AI 很厲害,為什麼你還是每天加班」這個問題出發,把 Google Workspace 當成真正的工作平台重新設計一次流程 ── Sheets 的資料結構、Drive 與 Docs 的文件流、Gmail 與 Calendar 的通知系統,再用 Apps Script 讓它自己跑起來,最後收斂成一張屬於你自己的 AI 工作能力地圖。
NT$ 4,599

