API 開發

提示工程進階:用 XML 標籤劃界線,用角色設定定調

當提示夾帶大量資料時,用 XML 標籤(例如 sales_records、my_code、docs 這類自訂名稱)把不同內容包起來,Claude 才分得清哪段是指令、哪段是資料;再用 system prompt 給 Claude 一個明確角色(例如有耐心的數學家教),行為與語氣就會跟著角色走。兩招合用,是把提示從堪用推向可靠的關鍵。
提示工程進階:用 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 結構疊起來,就是實務上可靠提示的樣子:

system prompt:角色與行為準則資料區:用 athlete_information 這類標籤包住範例區:sample_input 與 ideal_output指令:動詞開頭,清楚直接
角色定調、標籤劃界、範例示範、指令收尾:可靠提示的四層結構。

範例也吃這一套結構:把示範輸入與理想輸出分別包進 sample_input 與 ideal_output 標籤,Claude 一眼就看懂哪段是示範、哪段是正式輸入。順帶一提,範例的說明文字也值得放:在理想輸出後面補一句「這個輸出好在哪」,Claude 學到的就不只是格式,還有判斷的理由。

角色定調、標籤劃界,再配上清楚的指令與好範例,這四塊拼起來,你的提示就從「大概可以」進化到「每次都行」。

最後提醒一件事:結構是手段,不是目的。標籤包得再漂亮,指令含糊、範例失準,結果一樣不會好。先用入門三招把內容做對,再用這一篇的結構把邊界畫清楚,兩層都到位,才是完整的提示工程。

一個簡單的自我檢查把你的提示唸給一個沒有背景知識的人聽:他若分不清哪段是指令、哪段是資料,Claude 多半也分不清。反過來也成立:能一眼指出每一段的身分,這份提示的結構就及格了。
參考出處本文取材自 Anthropic 官方 Claude Academy 免費課程「Building with the Claude API」,由酒Ann 消化後以自己的視角重新編寫。想看英文原版課程,可到 Claude Academy 修習。

延伸學習

把這篇文章分享給需要的人FacebookLINEThreadsX

常見問答

XML 標籤要用官方規定的名稱嗎?
不用。自己取描述性的名稱就好:sales_records 比 data 好,athlete_information 一看就懂。名稱越具體,Claude 越能理解每段內容的用途。
短提示也需要 XML 標籤嗎?
簡單提示用不用差異不大,但標籤仍能當清楚的分隔線。提示越長、夾帶的資料越多、內容種類越雜,標籤的價值就越明顯。
角色設定要寫在哪裡?
寫成 system prompt,透過 API 的 system 參數傳入,而不是塞在 user 訊息裡。它對整段對話持續生效,是行為層級的設定。
角色設定可以寫到多具體?
越具體越好。除了「你是誰」,還要寫明該做什麼、不該做什麼,例如家教角色就明確規定不直接給答案、要一步一步引導。