XML标签提示法用标签结构化复杂指令前面我们讲了用分隔符和Markdown来组织提示词。今天我们来聊一种在复杂场景下特别强大的结构化方法——XML标签提示法。很多人在用Claude的时候会发现官方文档和大量高级案例中大量使用tag内容/tag这种XML风格的标签来组织提示词。这不仅仅是一种排版偏好——XML标签在AI的理解中是一种极其精确的信息分类信号。掌握XML标签提示法你的复杂提示词设计能力将进入一个全新的层次。一、XML标签提示法的原理与优势1.1 为什么是XML标签 XML标签在提示词中有三个独特的优势优势一语义精确性XML标签有明确的开标签和闭标签tag和/tag清楚地定义了这个区域从哪里开始到哪里结束。相比Markdown的标题和组织符号XML标签的边界是绝对清晰的——不会存在这个内容属于哪个板块的歧义。requirements 所有放在这里的内容都是要求不会与背景或示例混淆 /requirements context 所有放在这里的内容都是背景信息 /context优势二可以嵌套XML标签支持嵌套结构可以表达复杂的层级关系。这对于结构复杂的提示词尤其重要。task step name分析数据 input原始数据/input output分析结果/output /step step name生成报告 input分析结果/input output报告文档/output /step /task优势三AI训练数据中的大量存在互联网上有海量的HTML、XML文档。AI在处理XML标签时能够非常自然地理解被标签包裹的内容具有特定的语义角色。这是一种根深蒂固的格式-语义关联训练数据中极其常见。1.2 XML标签 vs Markdown vs 分隔符特性XML标签Markdown分隔符边界清晰度极高开闭标签中标题下一段开始即结束中需约定支持嵌套天然支持有限支持标题层级不支持语义表达能力高标签名可自定义中H1-H6, code等低纯分隔编写复杂度较高低最低适用场景复杂多模块提示词一般提示词简单分隔Token消耗较高多写标签中等低选择建议简单任务3-5行提示词分隔符或纯文本就够了中等复杂度5-20行提示词Markdown是最佳选择高复杂度20行以上有多个不同性质的信息模块XML标签是最佳选择二、XML标签提示法的基本用法2.1 基本语法 XML标签提示法的核心语法极其简单标签名内容/标签名标签名是自定义的用于描述该区域内容的性质或角色。常用标签名包括标签名用途instructions或task任务指令context或background背景信息examples示例区域example单个示例input输入内容output期望输出/输出格式constraints约束条件format格式要求role角色定义thinking要求AI展示思考过程answer要求AI的输出回答部分data数据输入2.2 一个完整的XML标签提示词role 你是一位资深的产品经理有8年的B2B SaaS产品经验。 你的分析风格是数据驱动、用户导向、务实可行。 /role context 我们的产品是一个面向中小企业的项目管理工具。 近期用户留存率从45%下降到了38%过去3个月。 竞品在过去两个月内连续发布了两个重要功能更新。 /context task 分析用户留存率下降的原因并给出改进建议。 /task constraints - 分析必须基于数据我会提供数据不能猜测 - 建议必须是可执行的给出具体步骤和优先级 - 总输出控制在1000字以内 /constraints data 2024年Q1用户行为数据 - 新用户次日留存42%去年同期48% - 核心功能使用率任务管理78%、文件共享35%、时间线22% - 主要流失节点注册后第3天40%的用户在这一天之后不再活跃 - 用户反馈高频词界面复杂、上手慢、功能太多 /data format 请按以下结构输出 1. 核心发现2-3句话 2. 原因分析按可能性排序 3. 改进建议按优先级排序每个建议包括具体行动、预期效果、实施难度 /format2.3 标签命名的原则 标签名的选择直接影响AI对内容的理解。好的标签名应该① 语义明确✅ role、task、example、constraints ❌ part1、section-a、block1② 与内容性质匹配✅ 如果内容是输出格式要求 → output_format ❌ 用 requirements 来包裹格式要求——太笼统了③ 保持一致风格✅ 全小写下划线user_data、output_format ✅ 全小写连字符user-data、output-format ✅ 驼峰式userData、outputFormat ❌ 混用user_data和outputFormat同时出现三、XML标签的嵌套结构3.1 单层嵌套最基本的嵌套是一个外层标签包裹多个内层标签。task description分析用户流失原因/description input_data用户行为数据/input_data expected_output分析报告/expected_output deadline本周五/deadline /task3.2 多层嵌套对于复杂任务可以使用多层嵌套表达精细的层级关系。project phase number1 name数据收集 task description收集过去6个月的用户行为数据/description owner数据团队/owner outputCSV格式的原始数据文件/output /task /phase phase number2 name数据分析 task description使用以下框架分析数据/description framework step数据清洗去除异常值和空值/step step趋势分析计算各指标的同比和环比变化/step step分段分析按用户类型、渠道、行为分段分析/step step根因分析使用5 Whys方法挖掘根本原因/step /framework output包含图表和分析结论的分析报告/output /task /phase phase number3 name建议生成 task description基于分析结论生成改进建议/description criteria criterion每个建议有明确的可衡量指标/criterion criterion按投入产出比排序/criterion criterion包含实施路线图时间线里程碑/criterion /criteria output改进建议文档/output /task /phase /project 这种多层嵌套结构让AI能精确理解每个任务属于哪个阶段、“每个要求属于哪个维度”——信息不会串位。3.3 嵌套深度控制⚠️XML标签嵌套深度建议不超过4层。超过4层时Token消耗显著增加每层多两个标签AI理解层级关系的准确性下降人类编写和维护的难度急剧增加✅ 推荐最大深度4层 project phase task step.../step /task /phase /project ❌ 过度嵌套6层 a b c d e f.../f /e /d /c /b /a四、XML标签的高级用法4.1 用标签引导输出结构 XML标签不仅用于组织输入提示词还可以用于指定输出格式——让AI用标签化的结构来组织输出。请按以下XML结构组织你的输出 analysis summary分析摘要100字以内/summary key_findings finding priorityhigh关键发现1/finding finding prioritymedium关键发现2/finding /key_findings root_causes cause confidencehigh根本原因1/cause cause confidencemedium根本原因2/cause /root_causes recommendations recommendation impacthigh effortmedium action具体建议/action rationale理由/rationale timeline时间线/timeline /recommendation /recommendations /analysis让AI以XML格式输出有几个好处输出结构极其精确每个字段都有明确的标签名方便程序解析特别是对接下游系统时对AI生成的内容有格式约束作用AI会自动对齐标签结构4.2 用标签属性传递元信息 标签属性如finding priorityhigh可以在不增加嵌套层级的情况下传递额外的元信息。finding priorityhigh confidence85% categoryretention 用户的流失主要集中在注册后的前3天 /finding属性应该用于传递关于这个内容的元信息而不是内容本身。好的属性包括priority优先级confidence置信度category分类status状态source来源4.3 用thinking和answer分离思考与回答 这是XML标签提示法中一个非常实用的模式——将AI的输出分为思考过程和最终答案两部分。请按以下格式回答 thinking 在这里写下你的思考过程 - 问题要求什么 - 已知条件是什么 - 你的推理步骤是什么 - 有没有需要考虑的边界情况 /thinking answer 在这里给出你的最终答案。答案应该直接、清晰 不需要在答案中重复思考过程。 /answer这种模式的优势思考与回答分离用户可以选择只看答案部分不用阅读整段推理方便程序解析下游程序可以直接提取answer标签中的内容减少幻觉AI在thinking中梳理逻辑后再在answer中输出减少了边想边说导致的错误4.4 用if标签注入条件逻辑 你可以在提示词中使用伪XML条件标签来表达条件逻辑。task 分析用户的反馈并根据反馈类型采取不同的处理方式。 if condition反馈包含明确的bug描述 action分类为bug报告提取复现步骤评估严重程度/action /if if condition反馈是功能建议 action分类为功能请求评估与产品路线图的一致性 估算开发工作量/action /if if condition反馈是一般性抱怨 action分类为用户体验问题提取用户情绪和核心痛点 不做技术分析/action /if if condition反馈不明确或信息不足 action标注为需补充信息列出需要向用户追问的问题/action /if /task⚠️ 注意这不是真正的程序逻辑AI不会像程序一样执行if标签。它更多是一种结构化的说明方式——用标签的形式让条件判断逻辑更清晰AI能更好地按照这个逻辑来分类处理。五、XML标签提示法的最佳实践5.1 标签体系设计原则 设计一套好的XML标签体系需要遵循以下原则原则一正交性不同标签的功能不重叠。每个标签有其独特且明确的职责。✅ 正交的标签设计 role → 只定义角色身份 task → 只定义任务目标 context → 只提供背景信息 data → 只提供数据输入 format → 只定义输出格式 constraints → 只定义约束条件 ❌ 功能重叠 info → 太笼统什么都可以放 details → 也太笼统与info功能重叠原则二最小完备性标签数量不多不少——刚好覆盖所有需要区分的信息类型但不多加不需要的标签。经验法则一个提示词中自定义XML标签的种类通常应该控制在5-10个之间。太少不足以区分信息类型太多增加认知负担。原则三可读性优先标签名应该让人类读者包括未来的你自己一眼就能理解。不追求极简而损失可读性。✅ 可读的标签名 user_feedback、output_format、quality_criteria ❌ 过于简化的标签名 uf、of、qc5.2 标签与内容的布局 标签内部的文本建议另起一行开始增加可读性。✅ 推荐布局内容另起一行 role 你是一位资深的产品经理。 /role ✅ 也可以短内容同行 role你是一位资深的产品经理。/role ❌ 不推荐标签和内容混在同一行但内容很长 role你是一位资深的产品经理有8年的B2B SaaS产品经验。 你的分析风格是数据驱动、用户导向、务实可行。在分析问题时 你会先从用户的角度出发理解他们的真实需求……/role → 开标签和闭标签不容易一眼看到降低了可读性5.3 兼容性考量⚠️ 不是所有AI模型都对XML标签同样敏感。Claude系列对XML标签的理解特别好这是它的设计特点但其他模型可能有差异。对于跨模型使用的提示词优先使用简单标签名如task、format避免过深的嵌套不超过3层保持标签体系的一致性在非Claude模型上先测试XML标签是否被正确理解六、XML标签与其他结构化方法的混合使用6.1 XML Markdown# 角色设定 role 你是一位资深的技术写作专家。 /role # 任务要求 task step number1 ### 分析阶段 阅读以下技术文档草稿找出表达不清晰的地方。 /step step number2 ### 重写阶段 对不清晰的部分进行重写保持技术准确性的前提下提升可读性。 /step /task # 输出格式 请按以下格式输出 markdown ## 问题清单 1. [问题描述]位置第X段 2. ... ## 修改建议 [修改后的完整文本] XML定义信息分类Markdown处理格式呈现——两者各司其职。 ### 6.2 XML 分隔符 系统设定 … 示例 …… 任务执行 … 分隔符提供最强的视觉隔离XML提供语义分类。 --- ## 七、完整实战案例 ### 7.1 案例多阶段文档生成任务 **场景**一个复杂的文档生成任务包含需求分析、大纲规划、内容撰写、质量审查四个阶段。你是一位资深的技术文档工程师有5年为开发者撰写API文档的经验。 你撰写的文档以清晰、准确、示例丰富而著称。overall_task为一套REST API生成完整的开发者文档。/overall_task在开始撰写文档前先分析提供的API信息列出所有需要补充的信息点。 如果某些关键信息缺失如认证方式、错误码定义等请明确指出。 [API的端点列表、请求/响应示例等原始信息] 缺少OAuth2.0的token获取流程说明 缺少429限流错误码的定义 基于收集到的信息规划文档的整体结构。 按照概述→快速开始→认证→API端点→错误处理→SDK指南→最佳实践的结构组织。......按照大纲逐个章节撰写文档内容。每章完成后用以下标准自检 - 是否有清晰的代码示例 - 示例代码是否可以直接运行 - 是否说明了请求参数的必填/可选/默认值 - 使用第二人称你来称呼开发者 - 代码块使用语言标注 - 请求和响应示例成对出现 - 重要注意事项用 **粗体** 标注 从以下维度审查已撰写的文档 1. 完整性所有API端点是否都有文档 2. 准确性示例代码是否能正常运行 3. 一致性术语使用是否统一 4. 可读性新加入团队的开发者能否独立阅读并理解 X/10 ... ... ...final_constraints- 总文档长度5000-8000字- 至少包含10个代码示例- 所有示例代码必须经过思维验证在标注语言环境中是否合理- 禁止使用简单地“仅仅”基本上等降低专业感的词汇/final_constraints7.2 案例效果解析这个XML标签提示词的优势阶段隔离4个phase标签将整个任务分成4个清晰的阶段每个阶段有自己的指令、输入和输出格式。AI在处理一个阶段时不会被其他阶段的信息干扰。层级关系用phase嵌套instructions、input、output_format等子标签让AI清楚每个阶段的指令-输入-输出三要素。属性传递元信息number1和name信息收集让每个阶段的标识和功能一目了然。质量控制内置每个阶段都有自己的质量检查标准不需要额外写审查提示词。核心要点总结✅XML标签的三大优势①边界绝对清晰开闭标签定义精确区域②天然支持嵌套表达复杂层级关系③AI训练数据中大量存在HTML/XML让AI对标签语义有深层理解。适用于20行以上的复杂提示词。✅标签命名三原则①语义明确task而非part1②与内容性质匹配一个标签一个职责③风格一致全篇用同一种命名风格。嵌套深度控制建议不超过4层。每多一层嵌套token消耗增加且AI理解层级关系的准确性下降。如果发现需要超4层嵌套考虑展平一部分结构。四种高级用法①用标签引导输出结构让AI以XML格式输出精确控制输出层级②用标签属性传递元信息priorityhigh在不增加嵌套时传递额外信息③用thinking和answer分离思考与答案④用if伪标签注入条件逻辑辅助说明性的条件判断非真正的程序逻辑。混用策略XML MarkdownXML定义信息分类Markdown处理格式呈现 分隔符最强的视觉隔离。三种方法各取所长构建最精确的提示词结构。⚠️兼容性注意Claude系列对XML标签理解最好其他模型可能有差异。跨模型使用时用简单标签名、控制嵌套深度、先测试再正式使用。
XML标签提示法：用标签结构化复杂指令
XML标签提示法用标签结构化复杂指令前面我们讲了用分隔符和Markdown来组织提示词。今天我们来聊一种在复杂场景下特别强大的结构化方法——XML标签提示法。很多人在用Claude的时候会发现官方文档和大量高级案例中大量使用tag内容/tag这种XML风格的标签来组织提示词。这不仅仅是一种排版偏好——XML标签在AI的理解中是一种极其精确的信息分类信号。掌握XML标签提示法你的复杂提示词设计能力将进入一个全新的层次。一、XML标签提示法的原理与优势1.1 为什么是XML标签 XML标签在提示词中有三个独特的优势优势一语义精确性XML标签有明确的开标签和闭标签tag和/tag清楚地定义了这个区域从哪里开始到哪里结束。相比Markdown的标题和组织符号XML标签的边界是绝对清晰的——不会存在这个内容属于哪个板块的歧义。requirements 所有放在这里的内容都是要求不会与背景或示例混淆 /requirements context 所有放在这里的内容都是背景信息 /context优势二可以嵌套XML标签支持嵌套结构可以表达复杂的层级关系。这对于结构复杂的提示词尤其重要。task step name分析数据 input原始数据/input output分析结果/output /step step name生成报告 input分析结果/input output报告文档/output /step /task优势三AI训练数据中的大量存在互联网上有海量的HTML、XML文档。AI在处理XML标签时能够非常自然地理解被标签包裹的内容具有特定的语义角色。这是一种根深蒂固的格式-语义关联训练数据中极其常见。1.2 XML标签 vs Markdown vs 分隔符特性XML标签Markdown分隔符边界清晰度极高开闭标签中标题下一段开始即结束中需约定支持嵌套天然支持有限支持标题层级不支持语义表达能力高标签名可自定义中H1-H6, code等低纯分隔编写复杂度较高低最低适用场景复杂多模块提示词一般提示词简单分隔Token消耗较高多写标签中等低选择建议简单任务3-5行提示词分隔符或纯文本就够了中等复杂度5-20行提示词Markdown是最佳选择高复杂度20行以上有多个不同性质的信息模块XML标签是最佳选择二、XML标签提示法的基本用法2.1 基本语法 XML标签提示法的核心语法极其简单标签名内容/标签名标签名是自定义的用于描述该区域内容的性质或角色。常用标签名包括标签名用途instructions或task任务指令context或background背景信息examples示例区域example单个示例input输入内容output期望输出/输出格式constraints约束条件format格式要求role角色定义thinking要求AI展示思考过程answer要求AI的输出回答部分data数据输入2.2 一个完整的XML标签提示词role 你是一位资深的产品经理有8年的B2B SaaS产品经验。 你的分析风格是数据驱动、用户导向、务实可行。 /role context 我们的产品是一个面向中小企业的项目管理工具。 近期用户留存率从45%下降到了38%过去3个月。 竞品在过去两个月内连续发布了两个重要功能更新。 /context task 分析用户留存率下降的原因并给出改进建议。 /task constraints - 分析必须基于数据我会提供数据不能猜测 - 建议必须是可执行的给出具体步骤和优先级 - 总输出控制在1000字以内 /constraints data 2024年Q1用户行为数据 - 新用户次日留存42%去年同期48% - 核心功能使用率任务管理78%、文件共享35%、时间线22% - 主要流失节点注册后第3天40%的用户在这一天之后不再活跃 - 用户反馈高频词界面复杂、上手慢、功能太多 /data format 请按以下结构输出 1. 核心发现2-3句话 2. 原因分析按可能性排序 3. 改进建议按优先级排序每个建议包括具体行动、预期效果、实施难度 /format2.3 标签命名的原则 标签名的选择直接影响AI对内容的理解。好的标签名应该① 语义明确✅ role、task、example、constraints ❌ part1、section-a、block1② 与内容性质匹配✅ 如果内容是输出格式要求 → output_format ❌ 用 requirements 来包裹格式要求——太笼统了③ 保持一致风格✅ 全小写下划线user_data、output_format ✅ 全小写连字符user-data、output-format ✅ 驼峰式userData、outputFormat ❌ 混用user_data和outputFormat同时出现三、XML标签的嵌套结构3.1 单层嵌套最基本的嵌套是一个外层标签包裹多个内层标签。task description分析用户流失原因/description input_data用户行为数据/input_data expected_output分析报告/expected_output deadline本周五/deadline /task3.2 多层嵌套对于复杂任务可以使用多层嵌套表达精细的层级关系。project phase number1 name数据收集 task description收集过去6个月的用户行为数据/description owner数据团队/owner outputCSV格式的原始数据文件/output /task /phase phase number2 name数据分析 task description使用以下框架分析数据/description framework step数据清洗去除异常值和空值/step step趋势分析计算各指标的同比和环比变化/step step分段分析按用户类型、渠道、行为分段分析/step step根因分析使用5 Whys方法挖掘根本原因/step /framework output包含图表和分析结论的分析报告/output /task /phase phase number3 name建议生成 task description基于分析结论生成改进建议/description criteria criterion每个建议有明确的可衡量指标/criterion criterion按投入产出比排序/criterion criterion包含实施路线图时间线里程碑/criterion /criteria output改进建议文档/output /task /phase /project 这种多层嵌套结构让AI能精确理解每个任务属于哪个阶段、“每个要求属于哪个维度”——信息不会串位。3.3 嵌套深度控制⚠️XML标签嵌套深度建议不超过4层。超过4层时Token消耗显著增加每层多两个标签AI理解层级关系的准确性下降人类编写和维护的难度急剧增加✅ 推荐最大深度4层 project phase task step.../step /task /phase /project ❌ 过度嵌套6层 a b c d e f.../f /e /d /c /b /a四、XML标签的高级用法4.1 用标签引导输出结构 XML标签不仅用于组织输入提示词还可以用于指定输出格式——让AI用标签化的结构来组织输出。请按以下XML结构组织你的输出 analysis summary分析摘要100字以内/summary key_findings finding priorityhigh关键发现1/finding finding prioritymedium关键发现2/finding /key_findings root_causes cause confidencehigh根本原因1/cause cause confidencemedium根本原因2/cause /root_causes recommendations recommendation impacthigh effortmedium action具体建议/action rationale理由/rationale timeline时间线/timeline /recommendation /recommendations /analysis让AI以XML格式输出有几个好处输出结构极其精确每个字段都有明确的标签名方便程序解析特别是对接下游系统时对AI生成的内容有格式约束作用AI会自动对齐标签结构4.2 用标签属性传递元信息 标签属性如finding priorityhigh可以在不增加嵌套层级的情况下传递额外的元信息。finding priorityhigh confidence85% categoryretention 用户的流失主要集中在注册后的前3天 /finding属性应该用于传递关于这个内容的元信息而不是内容本身。好的属性包括priority优先级confidence置信度category分类status状态source来源4.3 用thinking和answer分离思考与回答 这是XML标签提示法中一个非常实用的模式——将AI的输出分为思考过程和最终答案两部分。请按以下格式回答 thinking 在这里写下你的思考过程 - 问题要求什么 - 已知条件是什么 - 你的推理步骤是什么 - 有没有需要考虑的边界情况 /thinking answer 在这里给出你的最终答案。答案应该直接、清晰 不需要在答案中重复思考过程。 /answer这种模式的优势思考与回答分离用户可以选择只看答案部分不用阅读整段推理方便程序解析下游程序可以直接提取answer标签中的内容减少幻觉AI在thinking中梳理逻辑后再在answer中输出减少了边想边说导致的错误4.4 用if标签注入条件逻辑 你可以在提示词中使用伪XML条件标签来表达条件逻辑。task 分析用户的反馈并根据反馈类型采取不同的处理方式。 if condition反馈包含明确的bug描述 action分类为bug报告提取复现步骤评估严重程度/action /if if condition反馈是功能建议 action分类为功能请求评估与产品路线图的一致性 估算开发工作量/action /if if condition反馈是一般性抱怨 action分类为用户体验问题提取用户情绪和核心痛点 不做技术分析/action /if if condition反馈不明确或信息不足 action标注为需补充信息列出需要向用户追问的问题/action /if /task⚠️ 注意这不是真正的程序逻辑AI不会像程序一样执行if标签。它更多是一种结构化的说明方式——用标签的形式让条件判断逻辑更清晰AI能更好地按照这个逻辑来分类处理。五、XML标签提示法的最佳实践5.1 标签体系设计原则 设计一套好的XML标签体系需要遵循以下原则原则一正交性不同标签的功能不重叠。每个标签有其独特且明确的职责。✅ 正交的标签设计 role → 只定义角色身份 task → 只定义任务目标 context → 只提供背景信息 data → 只提供数据输入 format → 只定义输出格式 constraints → 只定义约束条件 ❌ 功能重叠 info → 太笼统什么都可以放 details → 也太笼统与info功能重叠原则二最小完备性标签数量不多不少——刚好覆盖所有需要区分的信息类型但不多加不需要的标签。经验法则一个提示词中自定义XML标签的种类通常应该控制在5-10个之间。太少不足以区分信息类型太多增加认知负担。原则三可读性优先标签名应该让人类读者包括未来的你自己一眼就能理解。不追求极简而损失可读性。✅ 可读的标签名 user_feedback、output_format、quality_criteria ❌ 过于简化的标签名 uf、of、qc5.2 标签与内容的布局 标签内部的文本建议另起一行开始增加可读性。✅ 推荐布局内容另起一行 role 你是一位资深的产品经理。 /role ✅ 也可以短内容同行 role你是一位资深的产品经理。/role ❌ 不推荐标签和内容混在同一行但内容很长 role你是一位资深的产品经理有8年的B2B SaaS产品经验。 你的分析风格是数据驱动、用户导向、务实可行。在分析问题时 你会先从用户的角度出发理解他们的真实需求……/role → 开标签和闭标签不容易一眼看到降低了可读性5.3 兼容性考量⚠️ 不是所有AI模型都对XML标签同样敏感。Claude系列对XML标签的理解特别好这是它的设计特点但其他模型可能有差异。对于跨模型使用的提示词优先使用简单标签名如task、format避免过深的嵌套不超过3层保持标签体系的一致性在非Claude模型上先测试XML标签是否被正确理解六、XML标签与其他结构化方法的混合使用6.1 XML Markdown# 角色设定 role 你是一位资深的技术写作专家。 /role # 任务要求 task step number1 ### 分析阶段 阅读以下技术文档草稿找出表达不清晰的地方。 /step step number2 ### 重写阶段 对不清晰的部分进行重写保持技术准确性的前提下提升可读性。 /step /task # 输出格式 请按以下格式输出 markdown ## 问题清单 1. [问题描述]位置第X段 2. ... ## 修改建议 [修改后的完整文本] XML定义信息分类Markdown处理格式呈现——两者各司其职。 ### 6.2 XML 分隔符 系统设定 … 示例 …… 任务执行 … 分隔符提供最强的视觉隔离XML提供语义分类。 --- ## 七、完整实战案例 ### 7.1 案例多阶段文档生成任务 **场景**一个复杂的文档生成任务包含需求分析、大纲规划、内容撰写、质量审查四个阶段。你是一位资深的技术文档工程师有5年为开发者撰写API文档的经验。 你撰写的文档以清晰、准确、示例丰富而著称。overall_task为一套REST API生成完整的开发者文档。/overall_task在开始撰写文档前先分析提供的API信息列出所有需要补充的信息点。 如果某些关键信息缺失如认证方式、错误码定义等请明确指出。 [API的端点列表、请求/响应示例等原始信息] 缺少OAuth2.0的token获取流程说明 缺少429限流错误码的定义 基于收集到的信息规划文档的整体结构。 按照概述→快速开始→认证→API端点→错误处理→SDK指南→最佳实践的结构组织。......按照大纲逐个章节撰写文档内容。每章完成后用以下标准自检 - 是否有清晰的代码示例 - 示例代码是否可以直接运行 - 是否说明了请求参数的必填/可选/默认值 - 使用第二人称你来称呼开发者 - 代码块使用语言标注 - 请求和响应示例成对出现 - 重要注意事项用 **粗体** 标注 从以下维度审查已撰写的文档 1. 完整性所有API端点是否都有文档 2. 准确性示例代码是否能正常运行 3. 一致性术语使用是否统一 4. 可读性新加入团队的开发者能否独立阅读并理解 X/10 ... ... ...final_constraints- 总文档长度5000-8000字- 至少包含10个代码示例- 所有示例代码必须经过思维验证在标注语言环境中是否合理- 禁止使用简单地“仅仅”基本上等降低专业感的词汇/final_constraints7.2 案例效果解析这个XML标签提示词的优势阶段隔离4个phase标签将整个任务分成4个清晰的阶段每个阶段有自己的指令、输入和输出格式。AI在处理一个阶段时不会被其他阶段的信息干扰。层级关系用phase嵌套instructions、input、output_format等子标签让AI清楚每个阶段的指令-输入-输出三要素。属性传递元信息number1和name信息收集让每个阶段的标识和功能一目了然。质量控制内置每个阶段都有自己的质量检查标准不需要额外写审查提示词。核心要点总结✅XML标签的三大优势①边界绝对清晰开闭标签定义精确区域②天然支持嵌套表达复杂层级关系③AI训练数据中大量存在HTML/XML让AI对标签语义有深层理解。适用于20行以上的复杂提示词。✅标签命名三原则①语义明确task而非part1②与内容性质匹配一个标签一个职责③风格一致全篇用同一种命名风格。嵌套深度控制建议不超过4层。每多一层嵌套token消耗增加且AI理解层级关系的准确性下降。如果发现需要超4层嵌套考虑展平一部分结构。四种高级用法①用标签引导输出结构让AI以XML格式输出精确控制输出层级②用标签属性传递元信息priorityhigh在不增加嵌套时传递额外信息③用thinking和answer分离思考与答案④用if伪标签注入条件逻辑辅助说明性的条件判断非真正的程序逻辑。混用策略XML MarkdownXML定义信息分类Markdown处理格式呈现 分隔符最强的视觉隔离。三种方法各取所长构建最精确的提示词结构。⚠️兼容性注意Claude系列对XML标签理解最好其他模型可能有差异。跨模型使用时用简单标签名、控制嵌套深度、先测试再正式使用。
