適用於誰
- 搜「提示詞 xml標籤」「提示詞 分隔符」的人；
- 看到別人的提示詞裏寫滿了
<context>、<instructions>這樣的尖括號，想知道這是不是必須、該怎麼寫的人； - 提示詞越寫越長，模型開始把資料裏的話當成指令、或者把例子當成正文的人。
本文根據 Anthropic、OpenAI、Google 的官方提示詞文檔整理，資料核對於 2026-10-11。
結論先說
- 標籤的作用是「分區」：告訴模型哪一段是指令、哪一段是資料、哪一段是例子，避免混淆。
- 不是隻有 Claude 才用。三家官方文檔都推薦用 XML 風格的標籤或 Markdown 來組織提示詞。
- 沒有「官方規定的標籤名」。標籤名自己取，要求是有描述性、前後一致。
- Markdown 標題適合劃分大的章節，XML 標籤適合包住一整塊內容，兩者可以配合使用；Google 則建議在一個提示詞裏選定一種並保持一致。
- 短提示詞不需要標籤。一句話能說清的事，加標籤只是添亂。
三家官方怎麼說
| 說法 | |
|---|---|
| Anthropic | XML 標籤幫助模型無歧義地解析複雜的提示詞，尤其是當提示詞裏混合了指令、上下文、示例和可變輸入時。把每種內容包在各自的標籤裏，可以減少誤解 |
| OpenAI | 用 Markdown 和 XML 標籤的組合幫助模型理解提示詞和上下文數據的邏輯邊界。Markdown 的標題和列表用來標出不同部分並表達層級；XML 標籤用來界定一段內容（比如參考文檔）從哪裏開始、到哪裏結束，標籤的屬性還可以用來放關於內容的元數據 |
用清晰的分隔符把提示詞的不同部分分開，XML 風格的標籤（如 <context>、<task>）或 Markdown 標題都有效；選一種格式，在同一個提示詞裏保持一致 |
OpenAI 在給推理模型的建議裏也專門有一條：用 Markdown、XML 標籤和小標題這樣的分隔符，清楚地標明輸入的不同部分。
步驟
1. 判斷要不要分區
需要分區的信號：
- 提示詞裏有大段粘貼的資料（文檔、電郵、代碼、聊天記錄）；
- 同時有指令 + 例子 + 待處理的內容三樣東西；
- 資料裏本身含有祈使句（比如一封電郵裏寫着「請盡快回覆」），你擔心模型把它當成給自己的指令；
- 你需要程序化地從輸出裏提取某一部分。
反之，「把這句話翻譯成英文」這種一句話的任務，不需要任何標籤。
2. 給每種內容一個標籤
Anthropic 舉的例子是 <instructions>、<context>、<input>。常用的一組：
| 標籤 | 放什麼 |
|---|---|
<role> 或 # 身份 | 角色和定位 |
<instructions> | 要做什麼、規則、步驟 |
<context> | 背景資訊 |
<document> / <documents> | 參考資料 |
<example> / <examples> | 少樣本示例 |
<input> 或具體名稱如 <email> | 這一次要處理的內容 |
<output_format> | 期望的輸出格式 |
Anthropic 的兩條最佳實踐：
- 標籤名要一致、有描述性。整個提示詞乃至你所有的提示詞裏，同一種內容用同一個名字；
- 內容有天然層級時就嵌套。例如多份文檔放在
<documents>裏，每份再用帶編號的<document index="1">包起來。
標籤名用中文還是英文，官方文檔沒有規定，示例都是英文。重要的是前後一致、成對閉合。
3. 在指令裏按名字引用
標籤的好處是可以指名道姓。與其寫「根據上面的內容」，不如寫：
請根據 <contract> 中的條款，逐條檢查 <checklist> 裏的每一項是否滿足。資料很多時，這種引用方式能明顯減少模型「看錯對象」的情況。
4. Markdown 和 XML 怎麼配合
OpenAI 官方示例的排法是：大章節用 Markdown 標題，具體內容塊用 XML 標籤。
# 身份
你是幫助團隊統一代碼風格的編程助手。
# 指令
* 變量名一律用 snake_case。
* 只返回代碼，不要解釋。
# 示例
<user_query>
怎麼聲明一個存名字的字符串變量？
</user_query>
<assistant_response>
var first_name = "Anna";
</assistant_response>Google 的模板則是全程用 XML 風格的標籤（<role>、<constraints>、<context>、<task>），並說明把用戶輸入放進 <context> 之後，模型會知道這是數據而不是指令。兩種都可以，關鍵是一個提示詞內部風格統一。
Anthropic 還有一條相關的提醒：提示詞本身的格式風格會影響回答的風格。提示詞裏滿是 Markdown，回答也更容易滿是 Markdown；想要成段的文字，就少用列表和加粗來寫提示詞。
5. 讓輸出也進標籤
標籤不只用於輸入。讓模型把不同部分的輸出放進指定的標籤裏，後續提取和核對都更方便：
先在 <quotes> 標籤裏摘錄相關原文，再在 <answer> 標籤裏給出結論。Anthropic 文檔裏把這種做法用在好幾個地方：用 <quotes> 和 <info> 分開摘錄與分析；思考關閉時把最終答案放進 <answer> 標籤以便提取；想控制寫作風格時，讓模型把正文寫在一個以風格命名的標籤裏。
程序裏用簡單的字符串匹配就能取出標籤內的內容。但如果你需要的是嚴格合法的 JSON，應該用結構化輸出功能而不是靠標籤，見《如何讓大模型穩定輸出 JSON》。
通用模板
<role>
［一兩句話：它是誰、為誰服務、什麼口吻］
</role>
<instructions>
1. ［第一步］
2. ［第二步］
3. ［規則與限制；重要的規則寫上原因］
</instructions>
<examples>
<example>
<input>［示例輸入］</input>
<output>［示例輸出］</output>
</example>
</examples>
<documents>
<document index="1">
<source>［來源］</source>
<document_content>
［資料正文］
</document_content>
</document>
</documents>
<task>
［這一次的具體請求。資料很長時，把這一段放在最後］
</task>按需刪減：沒有例子就刪掉 <examples>，沒有資料就刪掉 <documents>。
常見問題
Q：必須是合法的 XML 嗎？要不要寫聲明、轉義特殊字符？
不需要。這裏只是借用尖括號的形式做分隔，不會被當作 XML 解析。成對閉合、不要交叉嵌套就可以。
Q：用三個引號、三個反引號或者 ### 做分隔行不行？
可以，它們同樣是分隔符。標籤的優勢在於有名字，能在指令裏引用，也能嵌套。資料本身包含代碼塊或 Markdown 時，用標籤包住更不容易混淆。
Q：資料裏的內容會不會被當成指令執行？
分區能降低這種風險，Google 的模板也是這樣說明的。但它不是安全機制：處理不可信的外部內容（網頁、陌生電郵）時，仍然要假設其中可能有人為設計的指令，重要操作要有人工確認。
Q：聊天介面裏也能這麼寫嗎？
能，直接把帶標籤的文本粘進輸入框即可。上載文件時文件本身就是一個獨立的塊，不用再包標籤，在問題裏用文件名指代就行。
Q：標籤用得越多越好嗎？
不是。每加一個標籤都要問：它區分開了兩種不同的內容嗎？只包住一句話的標籤通常是多餘的。
參考資料
- Anthropic 文檔：Prompting best practices（Structure prompts with XML tags、Control the format of responses）— https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
- OpenAI 文檔：Prompt engineering（Message formatting with Markdown and XML）— https://developers.openai.com/api/docs/guides/prompt-engineering
- OpenAI 文檔：Reasoning best practices — https://developers.openai.com/api/docs/guides/reasoning-best-practices
- Google 文檔：Prompt design strategies（Structured prompting examples）— https://ai.google.dev/gemini-api/docs/prompting-strategies
0 條評論
還沒有評論，來搶沙發～