用 XML 标签、分节结构化你的提示词

2026-06-17

提示词结构化，是指把一段提示词按”指令、上下文、示例、输出要求”等功能拆成清晰的区块，用 XML 标签或分节标题把它们区隔开，让模型一眼看清”哪段是任务、哪段是资料、哪段是范例”。一句话:别把所有信息揉成一坨大白话,而是像填表格一样把它们归位。这篇讲清楚结构化为什么有用、怎么搭一个能复用的模板,以及团队怎么落地。

很多人写提示词靠”碰运气”:同一个需求,这次写得顺、模型答得好,下次换个说法就跑偏。问题往往不在模型不够聪明,而在提示词没有结构——指令和资料混在一起,模型分不清你要它”读这段”还是”照这段做”。结构化就是把这份混乱整理成机器和人都能扫读的格式。

为什么需要提示词结构化

模型读提示词,本质是在一长串文字里猜你的意图边界。当任务说明、参考资料、几个示例、输出格式要求全挤在一段里,边界就模糊了,常见后果有三个:

指令被资料”污染”:你贴了一段客户邮件让它总结,结果它把邮件里”请尽快回复”也当成了对它的命令。
示例和正文混淆:你给了个范例想让它模仿格式,它却把范例内容当成了要处理的数据。
输出格式失控:你想要 JSON,它给你一段带寒暄的散文,因为”输出要求”那句话淹没在中间没被重视。

把这些功能块显式区隔开,等于给模型画好了车道。实践中,结构化提示词的稳定性和可控性,通常明显高于同等信息量的”大白话”提示词——这也是为什么进阶的少样本提示(规划中)和系统提示词(规划中)都建立在结构化的基础上。

拿一个真实场景对比一下。同样是让模型总结客户邮件并给处理建议,不加结构的写法通常是:“帮我看看这封邮件,客户说物流慢还威胁要投诉,给我写个回复,别承诺退款,用中文,分段写清楚。邮件如下:XXX”。任务、约束、格式要求、原始邮件全挤一起,模型得自己猜”邮件如下”之后哪句是邮件、哪句是你补充的要求。一旦邮件里出现”请尽快处理”这类祈使句,模型很容易把它当成对自己下的指令,答案就跑偏了。改成结构化后,<task>只放一句话说清目标,<document>把邮件整段包起来,<rules>列约束,<output_format>定格式,模型不用再猜”这段话是谁在说”,批量跑几十条类似邮件时格式跑偏的概率会明显下降。

一段提示词通常拆成哪几块

不是每篇都要全上,但下面这几类功能块是高频组件,按需取用:

功能块	作用	常用标签/标题
角色/身份	设定模型扮演谁、以什么口吻	`<role>`、`# 角色`
任务指令	这次到底要它做什么	`<task>`、`<instructions>`
上下文/资料	供它参考的背景、文档、数据	`<context>`、`<document>`
示例	给一两个范例让它模仿	`<example>`、`<examples>`
约束/规则	必须遵守或禁止的事项	`<rules>`、`<constraints>`
输出要求	格式、长度、语言、字段	`<output_format>`

核心原则只有一条:一块只干一件事,块与块之间用明确的分隔标记隔开。

怎么用 XML 标签把它们区隔

XML 标签是目前最稳的区隔方式——一对成对的尖括号标签,把内容包起来,模型对这种格式的边界识别非常敏感。下面是一个可复制的通用模板:

<role>
你是一名资深电商客服主管,语气专业、克制。
</role>

<task>
阅读 <document> 里的客户投诉,输出一份处理建议。
</task>

<document>
{在这里粘贴客户的原始投诉内容}
</document>

<rules>
- 不承诺任何未经确认的赔偿
- 不暴露内部流程
</rules>

<output_format>
用三段:1) 问题归类 2) 建议话术 3) 是否需要升级
</output_format>

注意几个要点:

标签名见名知意就行,<document>、<task> 这类语义化命名比 <a>、<x> 好,模型也能”读懂”标签含义。
资料用专属标签包起来(如 <document>),并在 <task> 里明确”读 <document> 里的内容”,这样模型就不会把资料当指令。
成对闭合,别漏 </...>,否则边界还是会糊。

不想用标签?分节标题也行

如果你觉得尖括号太”技术”,或者在不支持长提示的场景里,用 Markdown 标题或显眼分隔符分节,效果同样不错:

# 任务
把下面的会议纪要整理成行动项清单。

# 会议纪要
{粘贴纪要}

# 输出要求
每条行动项包含:负责人、事项、截止时间。用 Markdown 表格。

分节和 XML 标签二选一即可,别混用到自相矛盾。判断口诀:

资料里本身含大量 Markdown(标题、列表) → 用 XML 标签包资料,避免标题打架。
提示短、字段少、给人看也要清爽 → 用分节标题更轻便。
要让模型严格区分”指令 vs 待处理文本” → 优先 XML 标签,边界最硬。

标签怎么嵌套:多示例、多轮资料怎么写

单个功能块好搭,难点在”资料不止一份”或”示例不止一个”的时候。这里给两个直接能抄的写法:

多个示例,用一个外层标签包住若干个编号子标签,别把示例平铺成一大段:

<examples>
  <example id="1">
    输入:发货延迟,客户情绪激动
    输出:先致歉,说明物流原因,不承诺具体到货时间
  </example>
  <example id="2">
    输入:客户要求全额退款且无理由
    输出:说明退款政策,引导走正规售后流程
  </example>
</examples>

多份资料,比如既要参考产品手册又要参考历史工单,分别用不同标签名而不是都叫<document>,避免模型分不清”这段话该对照哪份资料”:

<product_manual>
{产品说明书内容}
</product_manual>

<past_tickets>
{相似历史工单摘要}
</past_tickets>

<task>
结合上面两份资料,判断这次投诉是否属于已知问题,给出处理建议。
</task>

标签一多,记得在<task>里点名”结合 A 和 B”,别指望模型自己猜该看哪份——嵌套结构解决的是”资料分类”,替代不了”指明关系”这一步。

常见坑:结构化也会翻车的几种情况

结构化不是万能药,踩坑的地方通常不在”要不要用标签”,而在细节:

标签起名太随意,把资料块叫<a>、规则块叫<b>,模型能处理,但你半年后回来改会完全看不懂,新人接手更一头雾水。
只包资料、不点名任务,以为塞进<document>模型就”知道”该拿它做什么,结果<task>写得太笼统,模型对着资料自由发挥。一定要显式写清”处理<document>里的内容”。
规则堆太长又不分优先级,十几条<rules>一股脑列下去,模型很可能只重点响应前几条。约束多时,把最不能违反的放最前,或单独加一条”冲突时优先遵守第一条”。
XML 和 Markdown 标题混用不一致,一会儿<task>一会儿# 任务,模型注意力会被轻微打乱,选定一种就坚持到底。
忘了检查闭合标签,手动拼接长提示词时,资料本身若含尖括号字符,可能意外”闭合”了你的标签导致边界错乱,建议改用不易和内容冲突的标签名,或拼接前先转义。

结构化能用在哪些场景

批量内容生产:把”风格规则”和”本次素材”分块,换素材时只改一个块,模板复用。
数据抽取:<document> 放原文,<output_format> 规定 JSON 字段,抽取结果稳定可解析。
团队共享提示词:结构化的提示词像一份填空表,新人填资料块就能用,不必看懂全部逻辑。
沉淀为内部资产:把跑通的结构化提示词存成模板库,等于把”会写提示词的人”的经验固化下来,这正是管理者用 AI 的关键一步——让能力沉淀在组织里,而非个人脑子里。

落地三步:从一次性提示到团队模板

先拆块:拿你现在最常用的一个提示词,按上面的功能块分一遍,看哪些信息混在了一起。
定标准:团队内统一一套标签或分节约定(比如都用 <task>/<context>/<output_format>),避免各写各的。
建模板库:把高频任务的结构化模板存进文档或工具,留好”资料块”的空位,日常只填空,不重写。

结构不是越复杂越好——够用就停。简单任务一句话能说清,就别硬套六个标签;复杂、要复用、要交给别人用的任务,才值得把结构搭扎实。

常见问题

提示词结构化和提示词工程是一回事吗? 不完全是。结构化是提示词工程里的一项基础技巧,专指”把信息分块区隔”。提示词工程还包括给示例、设定角色、调推理步骤等更多手段,结构化是它们的承载骨架。

一定要用 XML 标签吗,用 Markdown 标题不行? 都行。XML 标签边界更硬,适合严格区分指令和待处理文本;Markdown 分节更轻便,适合短提示。二选一别混用即可,具体哪种更好以你所用模型的官方文档建议为准。

标签名有规定吗,必须用 <context> 这种吗? 没有强制规定,语义化、见名知意即可,成对闭合不要漏标签。模型靠标签结构识别边界,标签名本身只要清楚就行。

结构化会让提示词变长,消耗更多 token 吗? 会稍微变长,但换来的是输出更稳定、返工更少,总体通常更划算。简单任务不必硬套,复杂和要复用的任务才值得加结构。

👉 看看 AI 时代的组织与管理专栏,或了解 AI 时代管理者认知课。需要定制落地与陪跑,欢迎聊企业服务。