用 XML 标签构建提示词结构
- 为什么 XML 风格的标签能为 Claude 在提示词各部分之间划出清晰的边界
- 如何用命名标签包裹指令、文档、示例和格式规则
- 如何让 Claude 输出可以可靠解析的带标签内容
- 什么时候该加标签——以及什么时候不要过度加标签
当一条提示词把指令、文档、示例和问题混在一起时,模型可能会把它们搅成一团。XML 风格的标签是一种为每一部分贴标签的清爽办法——而 Claude 对它们的响应尤其好。
核心思路
把每个部分都包裹在一个命名标签里,让什么是什么一目了然:
带标签的提示词结构
<instructions>
Summarize the document for a busy executive. Use only the document; if a fact
isn't there, say so.
</instructions>
<document>
{paste the long document here}
</document>
<format>
3 bullet points, then a one-line "decision needed".
</format>这些标签只是你自己发明的文本——<document>、<example>、<context>、<rules>——但它们为模型提供了清晰的边界。
它为什么有用
- 把数据与指令分开——模型更不容易去服从粘贴进来的文档里夹带的无关文本(对提示词注入的一种温和防御——见 /docs/security/prompt-injection)。
- 减少“它忽略了我提示词的一部分”。每一部分都被清晰地界定。
- 让输出更易于解析——你可以让 Claude 把答案放进 <answer> 标签里,然后可靠地提取出来。
- 与少样本(/docs/prompting/few-shot)组合使用——把每个示例都包进 <example>。
四大收益的细节:
- 把数据与指令分开——模型更不容易去服从粘贴进来的文档里夹带的无关文本(对提示词注入的一种温和防御)。
- 减少"它忽略了我提示词的一部分"。 每一部分都被清晰地界定。
- 让输出更易于解析——你可以让 Claude 把答案放进
<answer>标签里,然后可靠地提取出来。 - 与少样本组合使用——把每个示例都包进
<example>。
要求带标签的输出
Guided walkthrough1 of 3
- 明确告诉模型推理用哪个标签、最终答案用哪个标签。
- 你的代码可以只抓取 <answer> 里的内容,忽略推理部分。
- 当你需要机器可读的结果时,它与结构化输出(/docs/api/structured-output)配合得很好。
要求带标签的输出
Put your reasoning in <thinking> tags and your final answer in <answer> tags.
然后你的代码就能只抓取 <answer> 里的内容。当你需要机器可读的结果时,它与结构化输出配合得很好。
小贴士
- 保持一致——每个标签都要开有合、闭有应;重复使用相同的名称。
- 有意义地命名标签(用 <contract>,而不是 <x>)。
- 不要在琐碎的提示词上过度加标签——当确实存在多个明显不同的部分时再用这种方法。
- 保持一致——每个标签都要开有合、闭有应;重复使用相同的名称。
- 有意义地命名标签(用
<contract>,而不是<x>)。 - 不要在琐碎的提示词上过度加标签——当确实存在多个明显不同的部分时再用这种方法。