Markdown格式在提示词中的应用技巧

Markdown格式在提示词中的应用技巧

上一篇文章我们讲了用分隔符组织提示词。今天我们来深入一个更具体的话题——如何用Markdown格式来写提示词。Markdown不仅是一种排版语法，在提示词工程中，它是一套"信息层级编码系统"——通过标题、列表、代码块、粗体等元素，你可以精确地告诉AI"这段内容是什么级别"、“那段内容是代码还是文本”、“这个信息比那个信息更重要”。掌握Markdown在提示词中的应用，你的提示词信息传递效率能提升一个台阶。

一、Markdown在提示词中的特殊价值

1.1 不只是"排版好看"

很多人以为在提示词中使用Markdown只是为了"让提示词看起来更整洁"。这个理解太表面了。

💡Markdown在提示词中的核心价值不是"美观"，而是"语义信号"。AI的训练数据中包含海量的Markdown格式文档（GitHub上的README、技术博客、文档网站等）。这意味着AI对Markdown的语义有深刻的理解——它知道# 标题是一级主题，知道**粗体**是强调内容，知道代码块中的内容应该被当作"代码"而非"自然语言"处理。

当你使用Markdown格式时，你利用的是AI在训练中建立起来的"格式-语义"映射关系。这比用普通文本+分隔符传达信息要高效得多。

1.2 Markdown的语义信号系统

Markdown的每个语法元素都向AI发送一个特定的"语义信号"：

📝 理解了这个"语义信号系统"，你就能更精确地使用Markdown来"编写"AI对你提示词的理解方式。

二、标题层级的使用策略

2.1 用标题构建信息层级

💡 标题是Markdown中最强的语义信号。一个#和##的差别，在AI的理解中是"主题"和"子主题"的差别。

标题层级的最佳实践：

# 一级标题 → 用于提示词的最顶层板块（如"角色设定"、"任务要求"） ## 二级标题 → 用于板块内的主要分类（如"内容要求"、"格式要求"） ### 三级标题 → 用于分类内的细分项（如"字数要求"、"风格要求"） #### 四级标题 → 尽量少用，层级太深反而让结构复杂

完整示例：

# 任务描述 分析Q2用户增长数据并生成报告。 # 角色设定 你是一位数据分析师，擅长从数据中提取商业洞察。 # 分析要求 ## 内容维度 ### 用户增长 - 新增用户趋势分析 - 渠道来源分析 ### 用户留存 - 次日/7日/30日留存率 - 留存率变化的原因分析 ### 收入分析 - ARPU/ARPPU变化趋势 - 付费转化率分析 ## 格式要求 ### 报告结构 1. 摘要 2. 核心指标概览 3. 详细分析 4. 建议 ### 字数限制 - 总报告：1500字以内 - 摘要：200字以内 # 参考示例 [示例内容] # 数据输入 [数据]

2.2 标题层级的数量控制

⚠️一个提示词中的标题层级不要超过3级。超过3级后，结构变得复杂，AI反而可能"迷失"在层级中。

✅ 最多3级标题： # 大板块 ## 子板块 ### 细项 （到此为止） ❌ 过度嵌套： # 大板块 ## 子板块 ### 细项 #### 更细的项 ##### 太细了 ###### 失去意义了

💡 如果发现需要4级以上的标题，说明你的信息组织结构有问题——应该考虑"展平"层级，或者将一些内容移到列表或段落中。

2.3 标题的命名原则

标题内容应该是"描述性的"而非"结构性的"。

✅ 描述性标题（AI能理解板块的内容性质）： # 角色设定 # 数据分析要求 # 输出格式规范 # 参考示例 ❌ 结构性标题（AI不知道每个板块"是干什么的"）： # 第一部分 # 第二部分 # 第三部分

三、列表的使用技巧

3.1 有序列表 vs 无序列表

💡 这个选择直接影响AI对"这些条目之间的关系"的理解。

使用有序列表（1. 2. 3.）的场景：

• 步骤、流程、先后顺序明确的条目
• 优先级排序（从高到低）
• 时间顺序（从前到后）

分析步骤： 1. 先查看数据整体趋势 2. 再定位异常时间点 3. 然后分析异常维度的交叉影响 4. 最后形成结论和建议

使用无序列表（- * +）的场景：

• 并列的要求、规则、特征
• 无先后顺序的选项或要素
• 清单式的检查要点

分析中需关注的因素： - 季节性波动 - 竞品动态影响 - 产品功能变更 - 市场环境变化

3.2 嵌套列表的深度控制

⚠️嵌套列表不要超过3层。超过3层的嵌套在AI的理解中可能产生混淆。

✅ 最多3层嵌套： - 数据分析 - 用户维度 1. 新增用户 2. 活跃用户 3. 流失用户 - 收入维度 1. 总收入 2. 人均收入 ❌ 过度嵌套： - 第一层 - 第二层 - 第三层 - 第四层（开始失去结构意义） - 第五层（AI可能无法准确理解层级关系）

3.3 列表项的一致性

💡 同一层级的列表项应该是"同类内容"。不要在同一个列表中混合不同类型的条目。

❌ 混合类型： 分析要求： - 查看用户增长趋势（行为） - 收入变化（数据项） - 建议优化产品功能（结论/建议） ✅ 同类一致： 分析内容： - 用户增长趋势 - 收入变化分析 - 留存率变化分析 - 渠道效果对比 分析步骤： - 第一步：数据概览 - 第二步：异常定位 - 第三步：原因分析 - 第四步：形成建议

四、代码块的正确使用

4.1 什么时候用代码块

💡 代码块告诉AI：“这部分内容请按照代码/数据/结构化文本的方式理解，不要当作自然语言指令。”

应该放在代码块中的内容：

• 实际的代码片段
• JSON/XML/YAML等结构化数据
• 示例输出格式
• 提示词中的"示例部分"（特别是格式示范）
• 不应该被AI当作"指令"解读的纯展示性内容

✅ 用代码块包裹示例输出格式： 请按照以下格式输出： ```json { "analysis": "分析内容", "score": 85, "recommendations": ["建议1", "建议2"] }

❌ 不用代码块（AI可能混淆）：
请按照以下格式输出：
{
“analysis”: “分析内容”,
“score”: 85,
“recommendations”: [“建议1”, “建议2”]
}

### 4.2 代码块的语言标注 💡 在代码块的开头标注语言类型，能进一步帮助AI理解内容的性质。

```json → AI知道这是JSON数据，会以数据格式理解 ```sql → AI知道这是SQL查询，会以数据库查询语义理解 ``` → 不加标注，AI需要自行判断

标注语言类型是一个"零成本但有效"的习惯，建议养成。

4.3 行内代码的妙用

💡 行内代码（用反引号包裹）用于标记"这不是普通文字，而是技术术语、变量名、命令或特定值"。

✅ 使用行内代码的场景： 请用 `pandas.DataFrame.groupby()` 进行分组聚合。 将 `status` 字段的值设置为 `active` 或 `inactive`。 运行 `npm install` 安装依赖。 不需要用行内代码的场景： 今天天气很好，适合出去散步。 请仔细分析用户反馈中的情感倾向。

五、强调与引用

5.1 粗体和斜体的信号强度

💡 在提示词中，粗体和斜体不仅是"排版"，更是"重要性信号"。

• **粗体**= 高优先级信号：“这个信息特别重要，请特别注意”
• *斜体*= 低优先级信号：“这是一个术语或特殊表达，请注意区分”
• ***粗斜体***= 最高优先级信号（慎用，用多了就没效果了）

⚠️使用原则：一篇提示词中，粗体的使用应该控制在5处以内。如果到处都是粗体，那就没有"重点"了——AI会对所有粗体内容"一视同仁"地重视，等于没有突出任何东西。

✅ 适度使用粗体（突出最关键的要求）： 请分析以下数据。**最重要的要求：所有结论必须有数据支撑，不能凭感觉推测。** 另外请注意输出格式要求。 ❌ 过度使用粗体（失去了突出重点的作用）： 请**分析**以下**数据**。**最重要**的要求：**所有结论**必须有**数据支撑**， 不能**凭感觉推测**。另外请**注意**输出**格式**要求。 → AI不知道哪句是"重中之重"

5.2 引用块的妙用

💡 引用块（>）在提示词中有独特的信号含义：“这是引用的外部内容/示例/背景材料，不是给你的指令”。

你的任务是分析以下用户反馈： > 这个App太卡了！点一个按钮要等3秒钟，我用了两天就卸载了。 请基于以上用户反馈，分析可能的原因和优化建议。

引用块让AI清楚地区分"要分析的内容"和"给你的指令"——这对于包含大量外部文本的提示词尤其重要。

六、Markdown在提示词中的综合应用

6.1 提示词整体结构设计

💡 一个结构良好的Markdown提示词应该有清晰的"视觉层次"——读者（包括AI和人类）扫一眼就能理解信息的组织方式。

推荐的整体结构：

# 主板块A（一级标题） ## 子板块A1（二级标题） - 内容项（列表） - 内容项 ## 子板块A2（二级标题） 1. 有序步骤 2. 有序步骤 # 主板块B（一级标题） > 引用或备注（引用块） 内容正文（正文段落） # 主板块C（一级标题） ```json { "示例数据": "value" }

实际提示：

角色设定

你是一位经验丰富的数据分析师。

任务描述

分析以下用户反馈数据，找出核心问题并给出建议。

分析要求

必须涵盖

• 问题识别：用户的核心痛点是什么？（需引用具体反馈作为证据）
• 影响评估：这个问题影响面多大？严重程度如何？
• 建议方案：给出2-3个具体的改进建议

格式要求

报告按以下结构组织：

1. 摘要（100字以内）
2. 问题分析
3. 改进建议
4. 优先级建议

约束条件

• 字数：总计不超过800字
• 风格：客观、具体、可操作
• 引用：每个结论必须引用至少一条用户反馈作为支撑

数据输入

用户反馈汇总：

“页面加载太慢了，我试了3次都在转圈。”
“功能很全，但操作太复杂，需要点很多次。”
“客服响应很快，好评。”
“数据导出的格式有问题，Excel打开乱码。”

输出格式参考

## 摘要 [简明扼要的概述] ## 问题分析 ### 问题1：[问题名称] - 严重程度：高/中/低 - 影响用户数：X人 - 用户原声：> "[引用]" - 根因分析：[分析] ## 改进建议 1. [建议1] 2. [建议2]

开始分析

### 6.2 Markdown与分隔符的混用 Markdown和上一篇文章讲的"分隔符"可以互补使用：

用 === 隔离最大的"域"（如示例域 vs 任务域）
用 # 组织域内的"板块"
用 ## 组织板块内的"子板块"
用列表组织"条目"

===== 示例域 =====

示例1

输入：…
输出：…

示例2

输入：…
输出：…

===== 任务域 =====

任务描述

…

实际输入

…

这种混用策略利用了分隔符的"强硬隔离"能力和Markdown的"层级组织"能力。 --- ## 七、Markdown提示词的常见陷阱 ### 7.1 陷阱一：代码块中的指令被"忽略" ⚠️ 代码块中的内容可能被AI理解为"要处理的文本/数据"而非"指令"。

❌ 错误：把重要指令放在代码块中

请务必以JSON格式输出，且所有字段不能为空。

→ AI可能认为这只是"展示的格式示例"，而非必须遵守的指令

✅ 正确：指令放在代码块外的正文中
请务必以JSON格式输出，且所有字段不能为空。
以下是JSON格式示例：

{"field":"value"}

### 7.2 陷阱二：标题被误解为"任务的主题"

⚠️ 如果提示词中说"# 请帮我分析数据"，AI可能将"请帮我分析数据"
理解为"这是标题文本"，而非"这是对我的指令"。

✅ 标题应该是板块名称，指令放在正文中：

任务描述

请帮我分析以下数据。

### 7.3 陷阱三：水平线在某些平台被"截断" ⚠️ `---`（三个减号）在Markdown中是水平线，但在某些AI平台中可能被当作"对话分隔符"或"提示词结束标记"。

✅ 用 === 代替 — 作为板块分隔
不建议在提示词中使用 — 作为分隔符

--- ## 八、完整实战案例 ### 8.1 案例：构建一个"技术方案评审"的Markdown提示词 📝 **场景**：需要一个标准化的提示词模板，用于评审技术方案文档。

角色设定

你是一位资深技术架构师，拥有12年的系统设计经验。
你的评审风格：犀利但建设性——批评要到位，但必须给出更好的方案。

任务描述

评审以下技术方案文档，从以下维度进行评估并生成评审报告。

评审维度

架构设计

• 系统架构的合理性和扩展性
• 组件之间的耦合度和内聚性
• 技术选型与场景的匹配度

数据设计

• 数据模型是否合理
• 查询性能是否满足预期
• 数据一致性保证机制

可靠性

• 故障处理机制是否完善
• 是否有单点故障
• 数据备份和恢复方案

安全性

• 认证和授权机制
• 数据传输和存储的加密
• 常见攻击向量的防护

可维护性

• 代码组织和模块划分
• 日志和监控的设计
• 部署和运维的复杂度

评分标准

每个维度按照以下标准评分：

输出格式

请严格按照以下格式输出评审报告：

# 技术方案评审报告 ## 总体评分 | 维度 | 评分 | 说明 | |------|------|------| | 架构设计 | X/5 | 一句话说明 | | 数据设计 | X/5 | 一句话说明 | | 可靠性 | X/5 | 一句话说明 | | 安全性 | X/5 | 一句话说明 | | 可维护性 | X/5 | 一句话说明 | **综合评分**：X/25 ## 主要问题 ### 🔴 严重问题 [每个问题单独列出，包含：问题描述、影响分析、修复建议] ### 🟡 需关注的问题 [同上格式] ### 🟢 优化建议 [同上格式] ## 亮点 [方案中做得好的地方，至少2点] ## 总结 [2-3句话的总结，包含评审结论和改进方向]

待评审方案

[在此处粘贴技术方案文档]

开始评审

请基于以上所有要求，对技术方案进行评审。

### 8.2 案例要点解析 这个Markdown提示词的设计有几个值得注意的细节： 1. **用`# 标题`组织顶层结构**：角色、任务、评审维度、评分标准、输出格式——每个都是独立的顶层板块。 2. **用`## 标题`细分维度**：架构设计、数据设计等是评审维度下的子维度。 3. **用表格展示评分标准**：表格让分数和含义的对应关系一目了然。 4. **用代码块包裹输出格式**：告诉AI"这个格式模板不要当作自然语言来理解，而是当作输出格式的参考"。 5. **关键要求用粗体突出**："犀利但建设性"被粗体标记，这是整个角色的核心特征。 6. **有序编号留给步骤列表**：评审报告结构用数字编号，暗示了"输出时按这个顺序组织"。 --- ## 核心要点总结 ✅ **Markdown在提示词中的核心价值**：不是让提示词"更好看"，而是利用AI训练数据中建立起来的"Markdown格式-语义"映射关系，精确传递信息的层级、类型和重要性。每个Markdown元素都是一个"语义信号"。 ✅ **标题层级三原则**：①不超过3级（#/##/###）；②标题用描述性名称（"角色设定"而非"第一部分"）；③层级关系反映信息的逻辑关系（一级是板块，二级是子板块，三级是细项）。 💡 **列表使用的关键区分**：有序列表用于步骤和优先级排序（暗示"先后顺序"），无序列表用于并列条目（暗示"无先后之分"）。嵌套不超过3层，同层列表项必须是"同类内容"。 📝 **代码块的三大用途**：①包裹示例输出格式（防止AI将其当作指令）；②包裹结构化数据（JSON/XML/YAML）；③标注语言类型提供额外语义信号（\`\`\`json让AI知道这是JSON数据）。行内代码用来标记技术术语和命令。 ⚠️ **粗体使用原则**：整篇提示词中粗体控制在5处以内。粗体是"高优先级信号"，用多了等于没有重点。关键约束用粗体，一般内容不用。 🔧 **最佳组合策略**：Markdown（组织层级和语义）+ 分隔符（隔离大的"域"）+ 引用块（区分"要处理的内容"和"给你的指令"），三者混用可以构建信息传递效率最高的提示词。 ⚠️ **三大陷阱**：①代码块中的文本可能被AI当作"展示内容"而非"指令"；②标题不应该包含指令性内容（"# 请帮我分析"不如"# 任务描述"加正文"请帮我分析"）；③`---`在某些平台可能被当作对话截断符号，推荐用`===`替代。