使用 XML 标签组织复杂输入
XML 标签是什么？
XML 使用尖括号标记数据的边界。一个包含内容的元素通常有开始标签和结束标签：
<book>
<title>示例书名</title>
<author>示例作者</author>
</book><book>是开始标签；</book>是结束标签；/叫斜线或正斜线，不是反斜线；- 标签可以嵌套，用来表达层级关系。
完整 XML 语法还包含属性、转义、自闭合元素等规则。本章不是教授 XML 解析，而是借用这种清楚的边界来组织 Prompt。
为什么标签有帮助？
当一个 Prompt 同时包含任务说明、待处理材料、参考示例和输出格式时，只用空行分隔容易混淆。语义明确的标签可以告诉读者和模型每一部分是什么。
<task>这里是任务</task>
<input>这里是待处理材料</input>
<rules>这里是规则</rules>
<output_example>这里是输出示例</output_example>标签名没有唯一答案。<input>、<meeting_notes> 或中文的 <会议记录> 都可以。选择能够准确描述内容、前后一致的名称即可。
XML 标签只是分隔符，不是“效果最好的终极格式”。Markdown 标题、代码块、JSON 或其他清晰结构也可以。应根据输入内容和下游用途选择。
案例：从会议记录提取待办事项
下面的会议记录完全虚构：
陈晨：登录页的错误提示需要改得更清楚，我负责周三前提交新文案。
林溪：我会更新帮助中心，但会议没有确定完成日期。
王宁：新版上线前要补一次无障碍测试，负责人还没有确定。我们希望模型只提取明确提供的信息，不编造负责人和日期。
请从 <meeting_notes></meeting_notes> 中提取待办事项。
<rules>
1. 只使用会议记录明确提供的信息；
2. 没有负责人或截止时间时写“未提供”；
3. 不要根据职位、语气或常识推断；
4. 使用 Markdown 表格输出。
</rules>
<meeting_notes>
陈晨：登录页的错误提示需要改得更清楚，我负责周三前提交新文案。
林溪：我会更新帮助中心，但会议没有确定完成日期。
王宁：新版上线前要补一次无障碍测试，负责人还没有确定。
</meeting_notes>
<output_columns>
事项 | 负责人 | 截止时间 | 原文依据
</output_columns>期望结果：
| 事项 | 负责人 | 截止时间 | 原文依据 |
|---|---|---|---|
| 提交登录页错误提示的新文案 | 陈晨 | 周三前 | “我负责周三前提交新文案” |
| 更新帮助中心 | 林溪 | 未提供 | “我会更新帮助中心，但会议没有确定完成日期” |
| 补一次无障碍测试 | 未提供 | 新版上线前 | “负责人还没有确定” |
这里保留“原文依据”，可以更快发现模型是否把不存在的信息补进了结果。
使用标签时的注意事项
包裹内容时保持成对和一致
如果使用 <meeting_notes> 开始，就使用 </meeting_notes> 结束。标签拼写、大小写和层级应前后一致。
在自然语言中引用标签名时，可以写“读取 meeting_notes 部分”，并不是每一次提到名称都必须展示完整标签。真正包裹输入内容时，再使用完整边界。
处理输入中的特殊字符
如果输入本身包含与分隔标签相同的文本，边界可能变得含糊。可以更换一个不冲突的标签名，或在程序中按照完整 XML 规则转义和解析。
标签不会自动防止 Prompt 注入
外部网页、邮件或文档中可能包含“忽略之前规则”等恶意或无关指令。把它放进 <input> 并不会让它自动安全。
涉及外部内容或工具调用时，还需要：
- 把外部材料当作数据，而不是高优先级指令；
- 限制模型可以访问的工具和数据；
- 对修改、付款、发送等操作设置确认；
- 校验工具参数与输出；
- 记录调用并为异常准备人工接管。
标签不会阻止模型编造事实
原会议没有截止时间，就必须明确要求输出“未提供”。如果示例反而补出一个日期，它展示的是错误行为，不是优秀结果。
本章检查清单
- 每个标签名是否能准确描述内容；
- 包裹内容的开始和结束标签是否对应；
- 输入、规则和输出示例是否分开；
- 是否说明未知信息不能推断；
- 是否保留了必要的原文依据；
- 外部输入是否按不可信数据处理；
- 高风险工具是否有权限、确认和审计。
标签可以提高可读性，但它只是组织输入的方法。结果是否可靠，仍取决于任务定义、事实依据、输出校验和系统边界。
