这里讨论的提示词工程，都是AI应用开发过程中，给大模型的【系统提示词】，而非用户在输入框直接发送的【用户提示词】。

用【不同的写作结构，来写同样的提示词】，模型的理解程度和指令遵循程度，会有差异吗？会的，兄弟，会的。因为不同模型的训练数据结构偏好不同，而且不同写作结构的优劣不同。

一、Markdown

Markdown 是我们日常交流中最常用的格式，比如写 README 文件或者聊天。使用 ## 作为标题，* 或 1.作为列表，非常自然，易于编写和阅读。

# 角色和目标
你将扮演一位专业的文案撰写助手，为一名律师用户服务。你的目标是帮助这位律师通过微信朋友圈文案来吸引潜在客户。

# 核心能力
- **概念转化**: 将复杂的法律概念转化为普通人易懂的语言。
- **场景联想**: 将法律知识与日常生活场景紧密联系起来。
- **语言风格**: 保持专业性的同时，使用亲和、真诚的语气，并巧妙使用表情符号增强可读性。

# 文案结构
你的输出必须遵循以下结构：
1.  **引言**: 用一个日常场景或问题引起读者兴趣（1-2句）。
2.  **核心内容**: 解释法律概念，提供2-3个关键点（2-3段，每段2-3句）。
3.  **实用建议**: 给出1-2条实际可操作的建议（1段）。
4.  **结语**: 简短的总结或呼吁（1句）。

# 限制条件
- **直接输出**: 严格按照用户的输入生成文案，不要添加任何额外的对话或引导性文字，比如“好的，这是为您撰写的文案：”或“您看这个可以吗？”。
- **严格遵循示例**: 请参考以下示例的风格和格式进行输出。

# 示例
---
## 示例一：劳动合同中的试用期
🤔 刚入职就被告知要试用6个月，这合理吗？让我们一起来了解下劳动合同中的试用期那些事儿！
...（此处省略示例内容）
## 示例二：房屋买卖中的 "阳光房" 问题
🏠 买房遇到 "阳光房"？别让美好的阳光变成法律阴影！

大模型训练数据中包含了海量的 Markdown 格式的文本（如 GitHub、博客），所以理解很容易。

但缺点是结构界定不够强，虽然可以用标题来分隔，但它不像 XML 的闭合标签那样具有强制的“结束”信号。对于非常复杂的嵌套指令，其约束力可能弱于 XML。（后面会讲到）

对于中等或简单的提示词，比如一个只包含角色和几个主要任务的提示词，没有复杂的条件判断和逻辑判断，用 Markdown 就完全足够了。

（一）Gemini更适合markdown等说人话的结构

Gemini 系列模型的训练使其非常擅长理解自然语言的结构，如标题、列表、粗体等，因此最适合它的结构是清晰的 Markdown 格式，其次是纯自然语言。相比 XML，Markdown没有繁琐的标签，让提示词更专注于核心内容，减少了模型解析的“噪音”。

（二）Gemini也可用XML，但非最优

Gemini 作为一个顶尖的大模型，完全有能力解析 XML。当你的提示词极其复杂，有非常多层的嵌套逻辑时，XML 的强制闭合标签可以提供最强的结构保证。

当你希望一个提示词能在 Claude 和 Gemini 等多个模型间通用时，可以考虑用 XML。至于我为什么能得出如此结论，请参考谷歌自己的提示词文档示例，还有去试试【同一套提示词放在不同结构中】，就知道差异了。

那什么是XML？

二、XML

XML就是把提示词写复杂，那为什么要写复杂？有什么逻辑或者嵌套关系，自然语言表述不清楚，而XML能够表述清楚的？为什么要用“像给机器编程”的语言，而不是“像和人聊天”的语言来与AI沟通。

核心区别在于：XML强制性地、毫不含糊地定义了结构和关系，而自然语言依赖于上下文、常识和约定俗成的模糊理解。

（一）场景一：精确的逻辑分组

想象一个复杂的搜索指令，你希望AI帮你筛选简历。

自然语言的模糊表述：

“帮我找一些候选人，他们必须会 Java 和 Python，或者有5年以上工作经验和硕士学位。”

这段话的歧义在于分组不清：【和】与【或者】的优先级是什么？

解读A: 【会Java和Python】或者同时【有5年经验和硕士学位】都行

解读B: 必须【会Java和Python】，同时有硕士学位或者5年以上工作经验

这两种解读会筛选出完全不同的人。XML的清晰表述：

   <search_query>
    <criteria_logic operator="OR">  <!-- 最外层是“或者”关系 -->
        <group operator="AND">      <!-- 第一个条件组，内部是“和”关系 -->
            <skill>Java</skill>
            <skill>Python</skill>
        </group>
        <group operator="AND">      <!-- 第二个条件组，内部是“和”关系 -->
            <experience years="5+"></experience>
            <degree>硕士</degree>
        </group>
    </criteria_logic>
</search_query>

1. 强制分组：
2. 明确逻辑：operator="OR" 和 operator="AND" 属性清楚地定义了组与组之间、组内元素之间的逻辑关系。

（二）场景二：区分内容和指令参数

假设你要让AI处理一篇需要翻译的文章，并有一些附加要求。

自然语言的模糊表述：

“请把这篇关于人工智能的文章翻译成德语，它的安全级别是机密，作者是李博士。”

这段话容易导致内容与指令混合：“安全级别是机密”、“作者是李博士”、“要快点”这些是关于文章的指令参数，还是需要被翻译的内容本身？

AI可能会错误地把“安全级别是机密”这句话也翻译到德语正文中去。

XML的清晰表述：

    <source_language>Chinese</source_language>
    <target_language>German</target_language>
    <metadata>
        <security_level>机密</security_level>
        <author>李博士</author>
    </metadata>
    <content>
        <![CDATA[
        这里是关于人工智能的正文内容...
        ...文章很长...
        ]]>
    </content>
</translation_task>

1. 职责分离：
2. 属性化指令：像priority="high"这样的属性，将模糊的“快点”变成了机器可以理解的、结构化的指令参数。
3. 内容封装：确保了无论正文内容是什么（哪怕内容里也包含XML标签），都会被当作纯文本处理，不会与指令结构冲突。

（三）场景三：复杂的条件嵌套与分支

想象一个自动客服机器人的对话逻辑。自然语言的模糊表述：

“如果用户提到‘退款’，检查他是不是VIP。 如果是VIP，就告诉他可以享受加急处理，并转接到高级客服。 如果不是VIP，就问他订单号。 如果用户提到‘查询物流’，就直接问他订单号。”

随着条件增多，句子会变得越来越长、越来越绕，很容易遗漏某个分支或搞错嵌套关系。

“如果不是VIP，就问他订单号”，这个流程和“查询物流”的流程一样都是问订单号，但它们触发的原因和后续步骤完全不同。自然语言很难清晰地表达这种“同源异流”或“异源同流”的逻辑。

XML的清晰表述：

   <dialogue_flow>
    <trigger keyword="退款">
        <condition check="user.is_vip" value="true">
            <action>respond_with_text: "作为VIP客户，您将享受加急退款服务。"</action>
            <action>transfer_to_Agent_group: "高级客服"</action>
        </condition>
        <condition_else>
            <action>ask_for_info: "订单号"</action>
        </condition_else>
    </trigger>
    
    <trigger keyword="查询物流">
        <action>ask_for_info: "订单号"</action>
    </trigger>
</dialogue_flow>

1. 模块化：每个
2. 显式条件：
3. 可维护性：如果想增加一个“投诉”的触发词，只需在下面加一个新的

最终，对于大模型而言，解析一个结构清晰的XML就像看一张地图，路径明确；而解析一段复杂的自然语言则像听一段绕口令，需要消耗大量认知资源去猜测真正的意图，而且还很容易猜错。

像 Anthropic 的 Claude 系列模型，其官方文档明确指出模型经过了专门训练，能够很好地理解和遵循 XML 标签。将指令放在

缺点是可读性稍差，对于人类来说，满眼的尖括号和闭合标签会显得有些冗长和杂乱。

三、YAML

YAML 常用于配置文件，因为它在表达键值对数据时非常简洁。“键值对”（Key-Value Pair）是计算机里一个很基础的概念，可以理解为“项目名称：项目内容”。

比如，一个用户信息可以这样表示：

• 姓名（键）：张三（值）
• 年龄（键）：30（值）
• 职业（键）：律师（值）

在不同格式里，这个信息的写法是：

XML的写法 (像文件夹):

      <user>
  <name>张三</name>
  <age>30</age>
  <profession>律师</profession>
</user>

YAML的写法 (像清单/大纲):

      user:
  name: 张三
  age: 30
  profession: 律师 

对比之下YAML非常简洁，它省略了所有尖括号，只用键: 值和缩进来表示层级关系。name、age、profession都向内缩进了，说明它们都属于user这个大项。

（一）YAML的缺陷是对缩进敏感

YAML 使用缩进来表示层级。一个多余的空格或 Tab 键的错用就可能导致整个结构解析错误，这在手写复杂提示词时很容易发生。

因为YAML没有XML的这种“结束标签”来告诉程序“这个部分到此为止”，它完全依赖缩进来判断内容的层级关系。

正确的YAML:

# “联系方式”是“用户”的一部分
user:
  name: 李四
  contact:
    email: lisi@example.com
    phone: 123456

这里的contact比user多缩进了2个空格，所以程序知道contact是user的子项目。email和phone又比contact多缩进了2个空格，所以它们是contact的子项目。逻辑清晰。

错误的YAML (仅仅是手滑，少打或多打了空格):

# “联系方式”和“用户”变成平级了
user:
  name: 李四
contact: # <-- 错误！这里的缩进和user一样了！
    email: lisi@example.com
  phone: 123456 # <缩进又和name平级了！

在这个错误的例子里：

1. contact因为没有缩进，它不再属于user，而是和user平起平坐的另一个独立项目。
2. phone的缩进又和name一样，程序会彻底混乱，不知道phone到底属于谁。

一个程序在读取这个错误的YAML文件时，会直接报错并停止工作。对于一个长达几十上百行的复杂提示词，可能仅仅因为一个地方手滑多按了一下空格，整个提示词就完全失效了，而且还很难找到错误在哪。

所以YAML 不常被直接用作手写的复杂系统提示词。它更适合的场景是：你在一个程序中定义提示词模板，然后用代码读取 YAML 配置文件，动态地填充内容并生成最终的提示词字符串。

（二）用程序读取YAML，动态生成提示词

这是YAML最强大、最正确的用法。把它当成一个【配置文件】，让一段代码去读取它，然后自动组装成最终的提示词。

场景： 你的律师朋友今天想写劳动法，明天想写婚姻法。

第一步：创建YAML配置文件 (config.yaml)

这个文件只存放会变化的数据。

      topic: "劳动合同中的试用期"
target_audience: "职场新人"
writing_style: "亲切、幽默"

第二步：创建提示词模板 (prompt_template.txt)

这是一个带有“占位符”的文本文件。

      你是一位专业的文案助手。
请你为【{audience}】写一篇关于【{topic}】的朋友圈文案。
文案风格要求【{style}】。

第三步：用程序来执行

1. 程序读取 config.yaml 文件，得到 topic 是【劳动合同中的试用期】等信息。

2. 程序读取 prompt_template.txt 文件。

3. 程序将从YAML里读到的信息，填入模板的 {} 占位符中。

4. 程序最终生成完整的提示词：

   "你是一位专业的文案助手。请你为【职场新人】写一篇关于【劳动合同中的试用期】的朋友圈文案。文案风格要求【亲切、幽默】。"

这样做的好处是，律师朋友下次想写“婚姻法”时，他只需要修改简单明了的 config.yaml 文件，把topic改成“婚姻法中的财产分割”就行了。他完全不需要去碰那个复杂、容易出错的提示词模板。

核心思想始终是：将不变的“逻辑和指令”（How）与多变的“数据和内容”（What）分离开来。

不变的逻辑 (提示词模板): 由提示词工程师精心设计，定义了AI的角色、任务结构、语气、输出格式等。

多变的数据 (YAML配置文件): 由普通用户（或其他程序）填写，提供了每次任务需要处理的具体信息。

（三）其他具体场景

场景：电商产品描述批量生成器

目标：为一个拥有成千上万种商品的电商网站，快速生成风格统一、吸引人的产品描述。

**提示词模板 (由提示词工程师锁定，不可修改):**

      `# 角色
你是一位顶级的营销文案专家，为我们的品牌撰写产品描述。

# 任务
根据下方提供的产品数据，生成一篇引人入胜的产品描述。

# 品牌声音
请严格遵循指定的品牌声音：**{{brand_voice}}**

# 输出结构
1.  **吸引人的标题**: 结合产品名和核心卖点。
2.  **开场段落 (2句话)**: 描绘一个用户使用场景，激发情感共鸣。
3.  **核心特性 (列表)**: 将`key_features`中的每一点，用更具吸引力的语言重新包装。
4.  **目标用户 (1句话)**: 点明这款产品是为谁设计的。
5.  **结尾号召**: 鼓励用户立即体验。

# 产品数据
产品名: {{product_name}}
品类: {{category}}
核心特性: {{key_features}}
目标受众: {{target_audience}}`

YAML配置文件 (由商品上架员填写):

`product_id: "SKU-0981"
product_name:"星尘降噪耳机 Pro"
category:"电子产品"
key_features:
-"主动式混合降噪，深达45dB"
-"30小时超长续航"
-"空间音频，影院级听感"
-"钛合金材质，轻巧耐用"
target_audience:"追求高品质生活的商务人士和音乐发烧友"
brand_voice:"科技感、专业、高端"`

商品上架员只需要填写一个简单的表单，系统就会自动将这些数据填入复杂的提示词模板，然后发送给AI模型，生成一篇高质量文案。他完全不需要懂提示词工程，就可以为1000个不同耳机、水杯、背包生成风格完全一致的专业文案。

场景：企业内部报告/周报小助手

目标： 帮助公司员工快速将零散的工作要点，整理成格式规范、语言专业的周报。

**提示词模板 (集成在公司OA系统中的AI功能):**

      `# 角色
你是一位专业的商业助理（BA），擅长撰写清晰、专业的商业报告。

# 任务
根据 **{{employee_name}}** 提供的本周工作要点，生成一份完整的、格式规范的部门周报。

# 输出格式
请严格按照以下Markdown格式输出：

## **{{department}} 周报**
- **汇报人**: {{employee_name}}
- **汇报周期**: {{reporting_period}}

### **一、本周工作完成情况**
（将`this_week_completed`中的要点，用更完整、更专业的商业语言进行描述和总结。）

### **二、下周工作计划**
（将`next_week_plan`中的要点，以清晰的列表形式呈现。）

### **三、遇到的挑战与所需支持**
（将`challenges_and_support_needed`中的问题，以客观、清晰的方式进行陈述，并明确指出需要哪个部门的协助。）`

YAML配置文件 (员工每周填写):

`employee_name: "王经理"
department:"市场部"
reporting_period:"2023年10月23日 - 2023年10月27日"
this_week_completed:
-"完成了双十一活动策划案V2版"
-"与设计部沟通，敲定了宣传海报主视觉"
-"数据分析：上周短视频渠道用户增长了15%"
next_week_plan:
-"启动广告投放流程"
-"撰写3篇公众号推文"
challenges_and_support_needed:"设计资源紧张，海报出图可能延期，需要项目管理部协调。"`

员工不再需要花费大量时间思考措辞和排版。他们只需在一个简单的表单里（背后就是YAML）填写几个要点，AI就能“一键生成”一份非常专业的周报。这统一了全公司的报告格式，并为管理者节省了大量阅读和理解的时间。

配置文件的提示词工程，本质上是创建了一个“AI应用框架”。

框架 (模板) 决定了AI的能力边界和产出质量。数据 (YAML) 决定了AI每次具体执行任务的内容。

这种模式让AI应用变得可扩展、可维护、易于使用，使得非技术人员也能学会。

新手如何开始快速体验XML和YAML的魅力？只需要让大模型帮你处理即可，发送消息【请把以下纯文本变成md/xml/yaml格式：xxx】

正确的使用方法是，先优化表达，优化还是达不到自己的预期效果时，再考虑用新的结构。一般情况下越简单越好。别折磨自己，不要为了炫技，写一个自己都不熟悉的结构。