掌握Prompt Engineering核心技巧，让你的AI大模型精准执行指令！从角色定位到输出规范，这篇完整指南帮你打造高效提示词，提升模型输出质量。
前言
你在撰写提示词时，是否经常感觉大模型不太听话？要么答非所问，要么输出一堆冗余信息。翻看它的思考过程，时而觉得它思维敏捷，时而又觉得它逻辑混乱。明明已经接近正确，怎么又推理到错误方向？明明在提示词中明确提醒过不要这样思考，它却偏偏走上歧路？这几乎是每个Prompt Engineer都会遇到的困扰。如何才能让模型严格按照你的要求去思考？
长提示词到底该如何编写？是否存在一种方法能够一次命中，找到终极版本的提示词？答案是否定的，一篇成功的长提示词通常需要经历初始版本、调优、测试、再调优的循环。但在这个迭代过程中，有规律可循，有方法可依。以下是我在反复被提示词折磨、经历无数痛苦试错后总结的一套提示词写作方案，保证你能获得满意的长提示词，让模型乖乖听话。
结构
也许你在小红书、B站上看过各种提示词结构，比如CRISE、BROKE、ICIO等等。这些框架在非精准类问题（精准类问题：数据查询分析；非精准类问题：文本解析、写作、翻译等）或非复杂性问题中确实很有价值。但在高复杂度的精准性问题中，它们的效果往往不够理想。我们团队长期探索大模型在数据分析场景中的应用，对准确性要求极高，场景也非常复杂。经过反复探索和尝试，我们总结出一套行之有效的提示词结构：
角色/任务 + 核心原则 + 上下文处理 + CoT(Chain of Thoughts) + 输出规范 + Few-Shot
还需要适当添加要求和限制，下面我将结合实战经验，逐一讲解每个模块的写作方法。
写在前面
模型是接收Prompt的主体，同时也是编写Prompt的高手，在初始版本和调优过程中可以发挥关键作用。
借助模型生成初始版本Prompt
- 准备query和期望输出的结果30条
- 准备上下文输出，以及文本结构介绍
- 清晰描述模型要实现的目标以及输出的提示词框架
将以上内容提供给大模型，可以快速获得初始版本的提示词，比自己从头开始写第一版要高效得多。
借助模型优化Prompt
- 准备测试集以及当前prompt生成的结果
- 添加准确结果和备注，备注描述生成错误结果的原因
使用模型初始化和优化可以解决基础问题，但真正的深度优化还需要自己完成。
Prompt格式
md或者json，我选择md格式。
不仅因为md格式视觉上更清晰，更重要的是md格式结构明确、撰写方便，而且扩展性很好。综合来看，md是更优的选择。
json格式虽然结构清晰，但扩展性太差，若写得太长容易把自己搞晕，建议慎重选择。
小提示：如果你需要严格的结构化输出（如API调用），json可能更适合，但日常迭代建议先用md，后期再转为json。
Prompt模块
不同模块承担不同的功能，复杂程度不同，所需模块也不同。
角色&任务
角色辅助，讲清楚任务。这部分放在prompt最前面，是最高指令，告诉模型它是谁，要做什么。
角色：模型本身具备各领域知识能力，解决当前具体问题需要调用模型哪方面的能力，是通过角色定位完成的。例如：你是一名牙科医生，你是一名数据分析师，你是一名川菜厨师等。让模型从一个杂学家变成专业领域的科学家。
任务：用一句话讲清楚模型要做什么。数据分析师可以写SQL查询数据、使用Python分析数据、数据可视化，也可以写分析报告。
角色和任务约束模型调用某方面能力完成一个具体的事情。
核心原则
核心原则可以一开始就输出，也可以在调优过程中生成。可以理解为模型执行任务时要遵守的最高准则，是纲领性质的要求。所以核心原则不能多，3条以内，超过3条很容易失效。
比如在生成SQL的prompt中，为了保证生成的SQL能查询出数据，就得有以下核心原则。
比如在做分词提取时，我们的分词倾向性也可以写在核心原则内。
一开始实现某个任务时，核心原则可能还没有，在优化过程中有些问题在提示词主体中总是解决不了，可以考虑在核心原则中优化。对于模型来说，核心原则被考虑的权重较高，仅次于角色和任务。
上下文处理
当前Context Engineering概念比Prompt Engineering更加流行，一句话概括就是让上下文以恰当的格式出现在恰当的位置。知识库可以包括：多轮对话的长短记忆、知识库RAG结果、提示词、工作流上游输出等。要让上下文发挥最大作用，就必须把上下文讲清楚，放对位置。
上下文模块组织原则：
- 上下文内容比较长时，最好放到最后，以免打断提示词
- 上下文结构要讲清楚，合适的组织形式会影响token数量也会影响性能（不展开讲）
- 上下文在任务中承担的作用和价值
举例：在生成SQL环节，上下文输入较多，具体组织形式如下：
上下文输入：一般放在提示词结尾处：
特别注意：上下文的结构和形式的优化通常需要与提示词的优化协同进行，二者同步优化才能达到最佳效果。
CoT(Chain of Thoughts)
CoT
CoT原本是提示词的一种框架，针对逻辑性较强的任务场景提出。它的核心是提醒或约束模型按照指定步骤思考，从而提升准确率。
举个经典例子：小明有5个苹果，3个梨。妈妈拿走2个苹果，爸爸给了1个梨，小明拿1个梨和姐姐换了1个苹果，请问最终小明有几个苹果几个梨。
提示词1: 请回答最终小明有几个苹果几个梨； 这时候答案很有可能是错的。
提示词2: 第一步：将小明每次获取、失去、交换所有物品作为一个节点，将整个过程按照节点切分成不同的计算任务 第二步：计算每一个节点结束后小明所有物品的数量 第三步：计算出最终的结果后复盘是否准确；这时模型会一步一步计算，更容易得到正确答案。
在复杂场景下，CoT也可以理解为执行流程或思考过程，可以作为整个prompt的一部分。模型在充分理解任务和上下文之后，再按照CoT步骤拆解任务，往往能让模型按指令执行，听话程度大幅提升。根据我们的经验，准确率可以提升20个百分点。
示例如下：维度解析
小提示：CoT步骤不宜过多，3~5步最佳，步骤过多可能让模型陷入细节混乱。
要求和限制
要求和限制，根据其重要级别，可以写在CoT模块内，也可以单独作为一个模块，因地制宜即可。
要求和限制一般是任务中需要特殊强调、特殊处理的逻辑，建议二者分开写。举例：
特殊逻辑表达
在写prompt时，有些逻辑用文字特别难以准确表达，有时准确表达需要上百字，模型准确理解就更难了。这时可以考虑使用伪代码来表达，模型理解起来既快又准。
例如，收入月报每月定稿时间13日，如何根据当前时间取出月表的最新时间，并考核时间的格式。
输出规范
模型太爱表达了，它往往不会只输出你想要的内容，总是输出很多自己的思考过程或考虑因素，以显示自己的聪明。或者不按要求的格式输出，因此对输出规范的要求必不可少。一些平台可以实现结构化输出，不过结构化输出的基础是模型能输出结构清晰的内容。
输出规范一般包含两部分：
- 期望输出的内容和结构
- 禁止输出的内容和结构
举例如下：
Few-Shot
提升准确率非常有效的手段，就好比一个应届生，你让他看一份文件然后按文件要求做事，很难理解到位。如果你再提供一两个例子，聪明的同学就能很好地完成任务。模型当然属于聪明的同学这一类。示例一定要按照上述CoT的过程来写，二者一致则能让模型最大限度地按照既定要求思考。
举例如下：
常见问题：为什么我的提示词很长但模型还是不听话？
答：可能原因有：1）核心原则超过3条，权重被稀释；2）CoT步骤不清晰，缺少关键步骤；3）示例与CoT不一致，导致模型困惑。建议先检查核心原则是否精简，再逐一验证CoT的每个步骤。
小提示：Few-Shot示例最好覆盖边界情况，比如正常输入、异常输入各一个，能让模型更鲁棒。
总结
不同模型、不同场景下写prompt的细节可能不尽相同，但整体框架是相通的。按照这个框架，人人都可以写出满意的Prompt！记住：角色定位、核心原则、上下文处理、CoT步骤、输出规范、Few-Shot示例，这六大模块缺一不可。反复迭代，你的模型会越来越听话。