大模型提示词工程进阶指南：从基础框架到实战优化，打造高精准Prompt

在大模型应用日益广泛的今天，“如何让模型精准理解需求、输出符合预期的结果”成为许多使用者的核心痛点——明明在提示词中明确了要求，模型却依然答非所问；有时前半段推理逻辑清晰，后半段却突然偏离方向；甚至反复强调“不要这样思考”，模型仍会陷入固定误区。

这些问题的核心，并非大模型能力不足，而是缺乏一套科学、系统的提示词（Prompt）设计方法。市面上常见的CRISE、BROKE等框架，虽能应对文本解析、翻译等非精准类任务，但在数据分析、SQL生成等对准确性要求极高的复杂场景中，往往难以满足需求。

本文基于腾讯CSIG磐石数据中心在大模型数据分析场景中的实战经验，提炼出一套覆盖“初始化-优化-落地”全流程的提示词工程方法论，从框架搭建、模块设计到工具运用，手把手教你打造出“让模型听话”的高精准Prompt，解决实际应用中的各类痛点。

一、提示词工程的核心认知：没有“终极Prompt”，只有“迭代Prompt”

许多人在设计提示词时，总希望能一步到位，写出一个“万能终极Prompt”，但实战经验告诉我们：成功的长提示词，必然是“初始版本→测试验证→问题分析→优化迭代”的循环产物。

以数据分析场景中的“SQL生成Prompt”为例，初始版本可能仅包含“角色（数据分析师）+任务（生成SQL）+表结构”三个基础要素，但测试后会发现：模型可能忽略时间筛选条件、误用字段名，或未结合用户Query中的维度要求。此时就需要补充“核心原则（必须基于表结构生成）”“CoT思考步骤（先解析维度再确定筛选条件）”等模块，逐步完善。

不过，这种迭代并非盲目试错，而是有规律、有方法可循。在迭代过程中，我们可以借助大模型自身的能力加速优化，同时遵循固定的框架结构，确保每一次调整都能解决具体问题，最终形成符合场景需求的高精准Prompt。

二、提示词的基础框架：6大核心模块，覆盖复杂场景需求

经过大量实战验证，在数据分析、精准查询等复杂场景中，一套高效的提示词需包含“角色&任务、核心原则、上下文处理、CoT思考链、输出规范、Few-Shot示例”6大核心模块，再根据需求补充“要求和限制”，形成完整的逻辑闭环。

这套框架的优势在于：既明确了模型的“身份定位”和“任务目标”，又通过“核心原则”划定执行边界，借助“上下文处理”提供必要信息，用“CoT”规范思考路径，靠“输出规范”约束结果格式，最后以“Few-Shot”降低模型理解成本——各模块环环相扣，共同提升Prompt的精准性。

（一）模块1：角色&任务——给模型“明确身份”和“具体目标”

角色&任务是提示词的“顶层指令”，位于Prompt最前端，核心作用是让模型从“通用知识库”切换到“专业领域模式”，明确“我是谁”和“我要做什么”。

1. 角色定位：调用模型的专业能力

大模型本身具备跨领域知识，但在具体任务中，需要通过“角色定位”激活特定领域的能力。例如：

• 若任务是“分析用户消费数据，生成可视化图表”，角色应设定为“资深数据分析师，擅长用户行为分析和Python可视化（Matplotlib/Seaborn）”；
• 若任务是“提取医疗文献中的疾病诊断标准”，角色应设定为“医学信息分析师，熟悉临床医学术语和文献结构化提取方法”；
• 若任务是“生成符合川菜口味的菜谱”，角色应设定为“川菜主厨，精通川菜‘一菜一格、百菜百味’的烹饪特点，擅长运用麻辣、辛香调料”。

注意：角色定位需“精准且具体”，避免模糊表述。例如“你是一名医生”不如“你是一名牙科医生，擅长儿童龋齿预防和治疗方案设计”——越具体的角色，模型越能聚焦相关知识，减少无关信息干扰。

2. 任务描述：一句话讲清“具体要做什么”

任务描述需简洁明了，明确模型的输出目标，避免歧义。例如：

• 错误表述：“你是数据分析师，帮我处理一下销售数据”（未说明“处理方式”和“输出结果”）；
• 正确表述：“你是数据分析师，基于提供的销售表结构（包含字段：日期、区域、产品类别、销售额），生成SQL查询语句，统计2025年Q1各区域的月度销售额同比增长率”（明确“输入信息”“操作方式”和“输出结果”）。

角色与任务结合后，模型的“行动边界”会变得清晰：既知道要调用哪方面的专业能力，也清楚最终要达成的目标，从源头减少“答非所问”的概率。

（二）模块2：核心原则——设定模型执行的“最高纲领”

核心原则是模型执行任务时必须遵守的“底线规则”，具有“高权重性”（优先级仅次于角色&任务），作用是解决“反复出现的共性问题”。

1. 核心原则的设计要点

• 数量控制在3条以内：原则越多，模型越容易混淆优先级，导致部分规则被忽略。实战中，2-3条核心原则足以覆盖大部分场景需求；
• 聚焦“关键约束”：原则需针对任务中的“核心风险点”，例如SQL生成任务中，“字段名必须与表结构一致”是关键约束，需写入核心原则；
• 表述简洁明确：避免模糊的“建议性语言”，使用“必须”“严禁”等确定性词汇，让模型明确“不可逾越的边界”。

2. 不同场景的核心原则示例

任务类型	核心原则设计示例
SQL生成	1. 必须基于提供的表结构生成SQL，表名、字段名需与表结构完全一致； 2. 非时间筛选条件必须来自用户Query的维度解析结果，不可额外添加条件。
文本分词提取	1. 宁可多输出，不要漏输出：不确定是否为有效维度词时，优先保留； 2. 复合词完整性优先：避免将“人工智能”拆分为“人工”“智能”单独输出。
医疗文献摘要	1. 必须保留文献中的核心数据（如样本量、统计P值），不可遗漏； 2. 专业术语需与原文一致，不可随意替换（如“高血压”不可改为“血压高”）。

3. 核心原则的迭代时机

初始版本的Prompt可能没有核心原则，但在测试过程中，若发现模型反复出现同一类错误（如SQL中频繁误用字段名），就需要将“避免该错误的规则”提炼为核心原则。例如：测试中发现模型多次忽略“表结构中的日期字段格式为‘YYYY-MM-DD’”，则可补充核心原则：“SQL中的日期筛选条件，格式必须与表结构中的日期字段一致（YYYY-MM-DD）”。

（三）模块3：上下文处理——让模型“拿到足够的信息”

Context Engineering（上下文工程）是当前提示词领域的热点，核心是“以恰当的格式，将必要信息放在恰当的位置”，确保模型能获取执行任务所需的全部上下文（如知识库、历史对话、上游输出等）。

1. 上下文处理的3个关键原则

• 位置后置：上下文内容通常较长（如完整的表结构、多轮对话记录），若放在Prompt前端，会打断“角色&任务-核心原则”的逻辑链，建议放在Prompt末尾，避免干扰模型对核心指令的理解；
• 结构清晰：用明确的标签（如<context></context>）或标题（如“## 表结构信息”）划分不同类型的上下文，例如将“表结构”放在<context1>，“用户Query”放在<context2>，让模型快速定位所需信息；
• 说明“作用”：明确每种上下文的用途，例如“中的表结构是生成SQL的唯一依据，不可使用外部表信息”，避免模型误解上下文的角色。

2. 数据分析场景的上下文组织示例

在“基于用户Query生成SQL”的任务中，上下文通常包含“表结构、维度解析结果、用户Query、表周期（月表/日表）”，其组织形式如下：

## 上下文信息
1. **表结构**：生成SQL必须基于此表结构，详细信息在<context1></context1>标签内（XML格式，包含表名、字段名、字段类型、表周期）；
2. **维度解析结果**：用户Query中的维度要求（如“区域=华北”“产品类别=电子产品”），在<context2></context2>标签内（格式：维度名称=维度值）；
3. **用户原始Query**：用户的需求原文，在<context3></context3>标签内，用于验证SQL是否匹配用户意图；
4. **表当前日期**：月表的当前月为{{table_month}}（格式：YYYYMM），日表的当前日为{{table_day}}（格式：YYYYMMDD），用于时间筛选条件设计。

<context1>
<表结构>
  <表名>sales_info</表名>
  <字段列表>
    <字段>date（日期，格式YYYY-MM-DD，表周期：日表）</字段>
    <字段>region（区域，如华北、华东）</字段>
    <字段>product_type（产品类别，如电子产品、日用品）</字段>
    <字段>sales_amount（销售额，单位：元）</字段>
  </字段列表>
</表结构>
</context1>

<context2>
region=华北，product_type=电子产品
</context2>

<context3>
统计2025年5月华北区域电子产品的日销售额
</context3>

通过这种方式，模型能清晰区分不同类型的上下文，明确“哪些信息用于确定表名、哪些用于设计筛选条件”，避免因信息混乱导致的错误。

（四）模块4：CoT思考链——规范模型的“推理路径”

CoT（Chain of Thoughts，思维链）是针对“逻辑复杂任务”设计的模块，核心是“将复杂任务拆解为步骤化的思考流程”，让模型“一步一步推理”，而非直接输出结果，从而提升准确率。

1. CoT的核心价值：解决“跳跃式推理”问题

以经典的“物品数量计算”问题为例：

• 问题：小明有5个苹果、3个梨；妈妈拿走2个苹果，爸爸给1个梨；小明用1个梨换姐姐1个苹果，最终小明有几个苹果、几个梨？
• 无CoT提示词：“请回答最终小明有几个苹果、几个梨”——模型可能因跳跃推理出错（如忘记“用梨换苹果”的步骤）；
• 有CoT提示词：“请按以下步骤计算：
  步骤1：记录初始苹果、梨的数量；
  步骤2：依次计算‘妈妈拿走苹果’‘爸爸给梨’‘用梨换苹果’后，每种水果的数量变化；
  步骤3：汇总最终数量，并验证是否遗漏步骤”——模型会按步骤推理，错误率显著降低。

在数据分析、逻辑推理等场景中，CoT能将“模糊的思考过程”转化为“明确的步骤”，让模型的推理路径可追溯、可控制。

2. 复杂场景的CoT设计示例：维度解析任务

维度解析是“从用户Query中提取维度词（如‘区域’‘产品类别’）并匹配知识库”的任务，逻辑复杂（需区分精确匹配、模糊匹配，按层级遍历），其CoT设计如下：

## 维度解析执行步骤（必须严格遵循）
### 步骤1：精确匹配流程
1. 若用户Query中的词组带有属性（如“电子产品类别”中的“电子产品”是属性），仅在“产品类别”维度内搜索；无属性则全维度搜索；
2. 精确匹配规则：词组与维度值完全一致（含字母、数字，不区分大小写和空格），“包含”或“被包含”均不视为匹配（如“华北区”≠“华北”）；
3. 层级匹配规则：必须按“层级0→层级1→层级2”的顺序匹配（层级0：一级节点，如“区域”；层级1：二级节点，如“华北”；层级2：三级节点，如“北京”），完成一个层级后再进入下一层级；
4. 同级遍历要求：在每个层级内，必须遍历所有同级节点（如层级1的“华北”“华东”“华南”），不可跳过；
5. 终止条件：若在某一层级匹配成功，立即停止该维度的后续匹配，输出“层级名称=维度值”；若精确匹配失败，进入步骤2。

### 步骤2：模糊匹配流程
1. 匹配范围与步骤1一致（带属性则指定维度，无属性则全维度）；
2. 模糊匹配规则：词组包含于维度值（如“华北”包含于“华北区域”，视为匹配）；
3. 层级顺序、同级遍历要求与步骤1一致；
4. 终止条件：匹配成功则输出结果，失败则进入步骤3。

### 步骤3：结果验证
1. 检查匹配到的维度值在树状知识库中的层级位置，确保“层级名称”正确（如“北京”属于层级2，不可标注为层级1）；
2. 严禁将同层级节点误判为上下级（如“华北”和“华东”均为层级1，不可标注为“华北→华东”）；
3. 若验证通过，输出最终结果；若验证失败，输出“无匹配维度”。

通过这种“步骤化、规则化”的CoT设计，模型会严格按照“精确匹配→模糊匹配→结果验证”的路径执行，避免因“跳过步骤”或“误判层级”导致的错误。实战数据显示，引入CoT后，维度解析任务的准确率可提升20%以上。

（五）模块5：输出规范——约束模型的“结果格式”

大模型常存在“过度表达”问题：不仅输出结果，还会附加大量推理过程、补充说明；或不按要求格式输出（如要求“逗号分隔”，却用“换行分隔”）。输出规范的作用，就是“明确结果的格式和内容边界”，让模型输出“干净、可用”的结果。

1. 输出规范的2大核心内容

输出规范需同时明确“应该输出什么”和“不应该输出什么”，即“正向要求”和“反向禁止”：

类别	设计要点	示例（维度解析任务）
正向要求	1. 明确结果结构（如“词组–层级名称=维度值”）； 2. 明确内容范围（如“仅输出匹配到的维度词”）； 3. 明确特殊情况处理（如“无匹配时输出‘无’”）。	1. 结果格式：“词组–层级名称=维度值”（如“华北–层级1=华北”）； 2. 一次词组仅输出一个结果，不可多个结果合并； 3. 无匹配维度时，输出“无”。
反向禁止	1. 禁止输出推理过程（如“我先检查了层级0，发现无匹配…”）； 2. 禁止输出无关内容（如“以下是额外补充的维度知识…”）； 3. 禁止修改结果格式（如不可用“冒号”代替“–”）。	1. 严禁输出维度解析的思考过程，直接输出最终结果； 2. 不可额外添加“维度解释”（如“华北是中国的北方区域…”）； 3. 不可改变结果分隔符，必须用“–”连接词组和维度值。

2. 不同场景的输出规范示例

• SQL生成任务：

  ## 输出规范
  1. 仅输出SQL语句，无任何前缀、后缀（如“以下是生成的SQL：”“SQL说明：”均需省略）；
  2. SQL语句需格式化（关键字大写，如SELECT、FROM；字段名小写，如sales_amount）；
  3. 若无法生成符合要求的SQL（如缺少必要字段），输出“无法生成SQL：原因+缺少的信息”（如“无法生成SQL：缺少‘销售额’字段的表结构信息”）；
  4. 禁止输出SQL的执行步骤、优化建议等无关内容。
  

• 文本摘要任务：

  ## 输出规范
  1. 摘要长度控制在原文的1/3以内，不超过300字；
  2. 必须包含原文的核心要素：研究对象、方法、结果、结论（如为新闻，需包含时间、地点、事件、影响）；
  3. 用“段落式”输出，不可分点；
  4. 禁止添加个人观点（如“我认为该研究的价值在于…”），仅客观总结原文内容。
  

通过输出规范，模型的结果会变得“标准化、可用化”——无需人工筛选、修改格式，可直接用于下游任务（如SQL可直接复制执行，摘要可直接插入报告）。

（六）模块6：Few-Shot示例——降低模型的“理解成本”

Few-Shot（少量示例）是提升模型准确率的“高效工具”，核心逻辑是“用示例演示‘正确的做法’”——就像教应届生做事时，“说十遍规则，不如给一个示例”。模型通过学习示例中的“任务逻辑、格式要求”，能更快掌握Prompt的核心意图。

1. Few-Shot示例的设计要点

• 示例与CoT保持一致：示例中的思考过程、执行步骤，必须与Prompt中的CoT完全匹配，避免模型混淆逻辑；
• 覆盖典型场景：示例需包含“正常情况”和“特殊情况”，例如维度解析任务中，需包含“精确匹配成功”“模糊匹配成功”“无匹配”三种示例；
• 格式清晰：用“用户Query→执行过程→输出结果”的结构呈现示例，让模型明确“输入→处理→输出”的对应关系。

2. 维度解析任务的Few-Shot示例

## Few-Shot示例（必须参考示例逻辑执行）
### 示例1：精确匹配成功
- 用户Query：“统计华北区域的销售额”
- 执行过程（遵循CoT步骤）：
  1. 提取词组“华北区域”，无属性→全维度搜索；
  2. 精确匹配：检查层级0（维度名称：区域）→无匹配；进入层级1（维度值：华北、华东、华南）→“华北”与“华北区域”中的“华北”不完全一致？不，用户Query中的词组是“华北区域”，维度值是“华北”→精确匹配失败？重新检查：精确匹配规则为“词组与维度值完全一致”，“华北区域”≠“华北”→精确匹配失败，进入模糊匹配；
  3. 模糊匹配：“华北”包含于“华北区域”→匹配成功，层级1=华北；
  4. 结果验证：“华北”属于层级1，无层级错误→验证通过。
- 输出结果：“华北区域--层级1=华北”

### 示例2：模糊匹配成功
- 用户Query：“分析电子产品类别的销售趋势”
- 执行过程：
  1. 提取词组“电子产品类别”，属性为“电子产品”→指定“产品类别”维度搜索；
  2. 精确匹配：层级0（产品类别）→无匹配；层级1（维度值：电子产品、日用品、服装）→“电子产品类别”≠“电子产品”→精确匹配失败；
  3. 模糊匹配：“电子产品”包含于“电子产品类别”→匹配成功，层级1=电子产品；
  4. 结果验证：“电子产品”属于层级1→验证通过。
- 输出结果：“电子产品类别--层级1=电子产品”

### 示例3：无匹配
- 用户Query：“计算2025年的总销售额”
- 执行过程：
  1. 提取词组“2025年”，属于“时间词”（根据“要求和限制”，时间词不参与维度匹配）；
  2. 无其他有效词组→精确匹配、模糊匹配均失败；
  3. 结果验证：无匹配维度→验证通过。
- 输出结果：“无”

通过这三个示例，模型能清晰理解“如何判断匹配类型”“如何处理属性词组”“如何应对无匹配场景”，大幅降低因“理解偏差”导致的错误。实战中，添加2-3个典型示例，可使模型的任务准确率提升15%-25%。

（七）补充模块：要求和限制——处理“特殊逻辑”

要求和限制是对核心原则、CoT的“补充说明”，用于处理任务中的“特殊情况”或“细节逻辑”，可根据需求选择是否添加，位置可在CoT模块内（步骤中的特殊规则）或单独成模块。

1. 要求和限制的常见类型

• 内容筛选：明确“哪些内容需要处理，哪些不需要”，例如维度解析任务中，“不提取具体数值（如订单号、金额）、时间词（如今年、Q1）”；
• 特殊规则：任务中的个性化逻辑，例如“当用户Query中出现‘环比’时，时间筛选条件需取‘上月同期’”；
• 格式细节：输出规范中未覆盖的格式要求，例如“SQL中的注释需用‘–’开头，不可用‘#’”。

2. 要求和限制的示例（维度解析任务）

## 要求和限制
1. 明确不提取的内容：
   - 具体数值：uin号、订单号、金额（如100元）、年份月份（如2025年、5月）；
   - 时间词：今年、本月、上月、去年、Q1、24年；
   - 业务动词：收入、增长、下降、对比、趋势、成本；
   - 疑问词：什么、哪些、如何、多少；
   - 通用词：客户（单独出现时）、官网客户（需提取为“官网”）；
   - 特定词：订单、地区、大盘、整体、产业树聚合。
2. 明确需提取的维度词：
   - 固定维度：服务、零售、i0A、国内区域；
   - 动态维度：用户Query中包含的“产品类别”“品牌”“渠道”相关词汇（如“手机品牌”中的“手机”）。

通过要求和限制，模型能处理任务中的“边缘场景”，避免因“未覆盖特殊规则”导致的错误。

三、提示词的迭代优化：从“初始版本”到“高精准版本”

一套优秀的Prompt，并非一次性设计完成，而是通过“测试-分析-优化”的循环不断完善。这个过程中，我们可以借助大模型自身的能力加速初始化，再通过人工分析解决核心问题，最终形成稳定可用的版本。

（一）第一步：借助大模型生成“初始版本Prompt”

手动写第一版Prompt效率低、易遗漏模块，可通过“给大模型提供素材+明确框架要求”，让其生成初始版本，再基于此修改。

1. 准备生成初始版本的素材

• 任务相关数据：30条左右的“用户Query+期望输出结果”（如维度解析任务中，“Query：华北区域销售额”+“期望输出：华北–层级1=华北”）；
• 上下文信息：任务所需的知识库（如维度树状结构、表结构）；
• 框架要求：明确初始Prompt需包含的模块（如“角色&任务+核心原则+上下文处理+CoT+输出规范+Few-Shot”）。
  

2. 生成初始版本的Prompt示例

# 任务：帮我生成“维度解析任务”的初始Prompt
## 角色：你是高级Prompt Engineer，擅长设计数据分析场景的提示词
## 核心要求：
1. 初始Prompt需包含“角色&任务、核心原则、上下文处理、CoT、输出规范、Few-Shot”6个模块；
2. 基于提供的素材设计，确保每个模块符合维度解析任务的需求；
3. 格式用Markdown，结构清晰，便于后续修改。

## 提供的素材：
1. Query-期望输出示例（30条中的3条）：
   - Query1：“统计华北区域的销售额”→期望输出：“华北区域--层级1=华北”
   - Query2：“分析电子产品类别的销售趋势”→期望输出：“电子产品类别--层级1=电子产品”
   - Query3：“计算2025年5月的总销量”→期望输出：“无”
2. 维度知识库（树状结构）：
   - 层级0：区域、产品类别、渠道
   - 层级1（区域）：华北、华东、华南；层级1（产品类别）：电子产品、日用品、服装；层级1（渠道）：线上、线下
   - 层级2（华北）：北京、天津、河北；层级2（电子产品）：手机、电脑、平板
3. 任务说明：从用户Query中提取维度词，匹配维度知识库，输出“词组--层级名称=维度值”，时间词、数值不提取。

将上述内容提交给大模型后，可快速得到包含6大模块的初始Prompt，省去“从零搭建框架”的时间。

（二）第二步：设计测试集，验证初始版本的问题

初始版本生成后，需通过“测试集”验证其效果，定位问题所在。

1. 测试集的设计要求

• 覆盖多场景：测试集需包含“正常场景”（如精确匹配成功）、“特殊场景”（如模糊匹配、无匹配）、“复杂场景”（如多维度词组、带属性的词组）；
• 数量足够：建议测试集包含20-30条Query，确保能覆盖大部分潜在问题；
• 标注清晰：每条测试用例需包含“用户Query、初始Prompt的输出结果、正确结果、错误原因描述、得分（如0-10分）”，便于后续分析。

2. 测试集示例（维度解析任务）

用户Query	初始Prompt输出结果	正确结果	错误原因描述	得分
统计北京区域的手机销售额	北京区域–层级1=北京	北京区域–层级2=北京	误将层级2的“北京”标注为层级1，违反层级匹配规则	4
分析线下渠道的日用品销量	线下渠道–层级1=线下	线下渠道–层级1=线下	匹配正确，格式符合要求	10
计算2025年Q1的总利润	2025年Q1–无匹配	无	输出格式错误，应直接输出“无”，而非“2025年Q1–无匹配”	6
查看官网客户的服装销售数据	官网客户–无匹配	官网客户–层级1=服装	未提取“官网客户”中的“官网”，违反“通用词处理规则”	3

（三）第三步：分析错误原因，优化Prompt

根据测试集的结果，按“模块”定位错误原因，针对性优化Prompt。常见的错误类型及优化方法如下：

错误类型	可能原因	优化方法
层级标注错误（如北京标为层级1）	CoT中的层级规则不明确，未明确“层级0-层级1-层级2”的定义	在CoT的“层级匹配规则”中，补充各层级的具体定义（如“层级1：区域的二级节点，如华北、华东；层级2：区域的三级节点，如北京、天津”）
输出格式错误（如多添加前缀）	输出规范中的“反向禁止”不明确	在输出规范中补充“禁止在结果前添加任何前缀（如‘匹配结果：’‘输出：’）”
未提取有效维度词（如官网客户）	要求和限制中“需提取的维度词”未包含“官网”	在“要求和限制”的“明确需提取的维度词”中，添加“官网（来自‘官网客户’）”
SQL字段名错误	核心原则未强调“字段名必须与表结构一致”	将“生成SQL时，字段名需与表结构中的字段名完全一致，不可简写或修改”添加到核心原则

优化示例：针对“层级标注错误”的优化

• 原CoT层级规则：“必须按层级0→层级1→层级2的顺序匹配”；
• 优化后CoT层级规则：“必须按层级0→层级1→层级2的顺序匹配，各层级定义如下：
  层级0：维度大类（如‘区域’‘产品类别’，无具体维度值）；
  层级1：维度大类下的一级节点（如‘区域’下的‘华北’‘华东’）；
  层级2：层级1下的二级节点（如‘华北’下的‘北京’‘天津’）”。

优化后，模型能明确各层级的定义，避免“层级标注错误”的问题。

（四）第四步：循环测试与优化，直至稳定

优化后的Prompt需再次用测试集验证，若仍有错误，重复“分析原因→优化模块”的步骤，直至测试集中80%以上的用例达到预期效果（得分≥8分）。此时，Prompt基本可满足实际场景需求，后续可根据新的任务场景（如新增维度、变更表结构）进行小范围调整。

四、提示词的格式选择：Markdown vs JSON

在设计Prompt时，格式选择会影响“撰写效率”和“模型理解成本”。常见的格式有Markdown和JSON，二者各有优劣，需根据场景选择。

（一）Markdown：复杂场景的首选

Markdown的优势在于“结构清晰、撰写方便、扩展性强”，适合包含多个模块、大量文本的复杂Prompt（如数据分析、维度解析任务）。

1. Markdown的核心优势

• 层级分明：通过“# 一级标题”“## 二级标题”划分模块，模型能快速识别“角色&任务”“核心原则”等不同部分；
• 撰写灵活：支持列表、代码块、标签等格式，可灵活组织上下文、CoT步骤、示例；
• 易于修改：迭代优化时，只需修改对应模块的内容，无需调整整体结构（如修改CoT步骤，不影响输出规范）。

2. Markdown格式的Prompt示例（片段）

# 角色&任务
- 角色：资深数据分析师，擅长SQL生成和维度解析，熟悉销售数据报表结构；
- 任务：基于提供的表结构和用户Query，生成符合要求的SQL查询语句，用于统计销售数据。

# 核心原则
1. 必须基于<context1>中的表结构生成SQL，表名、字段名需与表结构完全一致，不可使用外部表信息；
2. SQL中的时间筛选条件需符合表周期（月表用YYYYMM，日表用YYYYMMDD），格式错误需修正。

# CoT思考步骤
## 步骤1：解析用户Query
1. 提取Query中的核心需求（如“统计销售额”“按区域分组”）；
2. 识别维度条件（如“区域=华北”“日期=202505”）和指标（如“销售额”“销量”）；
3. 确认是否包含特殊逻辑（如“同比”“环比”）。

（二）JSON：简单场景的可选方案

JSON的优势在于“结构严谨、机器可读性强”，适合模块简单、输出需结构化的场景（如单轮问答、简单分类任务）。但在复杂场景中，JSON存在明显劣势：

• 扩展性差：若需新增模块（如在“角色&任务”后添加“要求和限制”），需修改整个JSON结构，容易出错；
• 撰写繁琐：长文本（如CoT步骤、Few-Shot示例）需处理转义字符（如引号、换行），容易导致格式错误；
• 可读性低：复杂Prompt的JSON结构会非常冗长，人工阅读和修改时，难以快速定位模块。

JSON格式的Prompt示例（简单场景）

{
  "角色": "简单文本分类师，擅长将用户Query分为“销售咨询”“技术问题”“其他”三类",
  "任务": "接收用户Query，输出对应的分类结果",
  "输出规范": {
    "格式": "仅输出分类结果（销售咨询/技术问题/其他）",
    "禁止内容": "禁止输出推理过程、补充说明"
  },
  "Few-Shot示例": [
    {
      "用户Query": "如何查询上月的销售额",
      "分类结果": "销售咨询"
    },
    {
      "用户Query": "系统登录失败怎么办",
      "分类结果": "技术问题"
    }
  ]
}

（三）格式选择建议

• 复杂场景（如SQL生成、维度解析、文献摘要）：优先选择Markdown，兼顾“撰写效率”和“模型理解成本”；
• 简单场景（如单轮分类、短句翻译、简单问答）：可选择JSON，若后续需扩展模块，建议切换为Markdown；
• 团队协作场景：统一使用Markdown，便于多人修改和版本管理，减少因格式不一致导致的沟通成本。

五、总结：提示词工程的核心逻辑

大模型提示词工程的本质，并非“掌握高深的技巧”，而是“建立一套科学的方法论”——通过“角色&任务”明确目标，用“核心原则”划定边界，靠“上下文”提供信息，以“CoT”规范推理，凭“输出规范”约束结果，借“Few-Shot”降低理解成本，最终通过“迭代优化”不断提升精准性。

不同的大模型（如GPT、文心一言、通义千问）、不同的应用场景（如数据分析、文本创作、医疗咨询），虽需调整Prompt的细节（如核心原则、CoT步骤），但这套“框架+迭代”的逻辑是通用的。

正如腾讯CSIG磐石数据中心在实战中所验证的：企业在数据时代不缺数据，缺的是“让数据产生价值的能力”；而提示词工程，正是让大模型成为“数据解读工具”的关键——掌握这套方法论，人人都能打造出“让模型听话”的高精准Prompt，从数据中洞见更多可能性。