跳到主要内容

用 XML 标签构建提示词结构

进阶
What you'll learn
  • 为什么 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>——但它们为模型提供了清晰的边界。

它为什么有用

Pro tip
  • 把数据与指令分开——模型更不容易去服从粘贴进来的文档里夹带的无关文本(对提示词注入的一种温和防御——见 /docs/security/prompt-injection)。
  • 减少“它忽略了我提示词的一部分”。每一部分都被清晰地界定。
  • 让输出更易于解析——你可以让 Claude 把答案放进 <answer> 标签里,然后可靠地提取出来。
  • 与少样本(/docs/prompting/few-shot)组合使用——把每个示例都包进 <example>。

四大收益的细节:

  • 把数据与指令分开——模型更不容易去服从粘贴进来的文档里夹带的无关文本(对提示词注入的一种温和防御)。
  • 减少"它忽略了我提示词的一部分"。 每一部分都被清晰地界定。
  • 让输出更易于解析——你可以让 Claude 把答案放进 <answer> 标签里,然后可靠地提取出来。
  • 少样本组合使用——把每个示例都包进 <example>

要求带标签的输出

Guided walkthrough1 of 3
  1. 明确告诉模型推理用哪个标签、最终答案用哪个标签。

要求带标签的输出

Put your reasoning in <thinking> tags and your final answer in <answer> tags.

然后你的代码就能只抓取 <answer> 里的内容。当你需要机器可读的结果时,它与结构化输出配合得很好。

小贴士

Key takeaways
  • 保持一致——每个标签都要开有合、闭有应;重复使用相同的名称。
  • 有意义地命名标签(用 <contract>,而不是 <x>)。
  • 不要在琐碎的提示词上过度加标签——当确实存在多个明显不同的部分时再用这种方法。
  • 保持一致——每个标签都要开有合、闭有应;重复使用相同的名称。
  • 有意义地命名标签(用 <contract>,而不是 <x>)。
  • 不要在琐碎的提示词上过度加标签——当确实存在多个明显不同的部分时再用这种方法。

自测一下

自测一下

0/5
  1. 当一条提示词把指令、文档和问题混在一起时,XML 风格的标签之所以有用,主要原因是什么?
  2. 为什么标签能充当对提示词注入的一种温和防御?
  3. 如何从带标签的回复中可靠地只提取出 Claude 的最终答案?
  4. 命名标签的最佳实践是哪一项?
  5. 什么时候你不应该使用 XML 标签?

下一步