你在写prompt时候，是不是总觉得大模型它不听话。要么答非所问、要么一堆废话。扒开思考过程仔细阅读时而觉得它聪明绝顶，时而又觉得它愚蠢至极。明明已经对了怎么又推理到错的地方去了，明明在提示词中提醒过了不要这么思考它怎么就瞎想了。这也许就是每一个Prompt Engineer的困扰。怎么能让模型按照要求去思考。长提示词到底应该怎么写，有没有方法可以一次命中，找到那个终极的提示词。 答案是否定的，一篇成功的长提示词总是要经历初始版本、调优、测试、再调优。不过这个过程中有规律可循，有方法可套。 以下就是被提示词反复捶打，经历无数痛苦经历后总结的一套提示词写作方案，保你可以得到满意的长提示词，让模型听话。

1. Prompt格式

md或者json，推荐md格式。不仅仅是因为md格式比较好看，主要是为你md格式结构清晰，撰写方便，而且拓展性很好。总结下来md是比较好的选择。json格式虽然结构清晰，但是扩展性太差，写的太长了容易把自己搞晕，慎重选择。

2. Prompt模块

不同模块承担不同的作用，复杂程度不同需要的模块也不同。
角色&任务
角色辅助，讲清楚任务。 此部份在prompt最前面，是最高指令，告诉模型它是谁，要干嘛。
角色：模型本身是具备各领域知识能力的，解决当前具体问题需要调用模型哪方面的能力，是通过角色定位完成的。 你是一名牙科医生，你是一名数据分析师、你是一名川菜厨师等让模型从一个杂学家变成专业领域的科学家。
任务：一句话讲清楚模型要干嘛，数据分析师可以写sql查询数据、可以使用python分析数据、可以数据可视化，也可以写分析报告。角色和任务约束模型调用某方面能力完成一个具体的事情。
核心原则
核心原则可以一开始就输出，也可以在调优过程中生成。 可以理解为模型执行任务时要遵守的最高原则，纲领性质的要求。所以核心准则不能多，3条以内，超过3条很容易就失效了。比如在生成sql的prompt中，为了保证生成的sql可以查询出数据，就得有以下核心原则：

比如在做分词提取时，我们的分词倾向性也可以写在核心原则内：

一开始实现某个任务时，核心原则可能还没有，在优化过程中有些问题在提示词主体中总是解决不了，可以考虑在核心原则中优化。对于模型来源核心原则会被考虑的权重是比较高的，仅次于角色和任务。

3. 上下文处理

当前Context Engineering概念比Prompt Engineering更加流行，一句话概括就是让上下文以恰当的格式出现在恰当的位置，知识库可以包括：多论对话的长短记忆、知识库rag结果、提示词、工作流上游输出等。能让上下文发挥最大作用，就必须把上下文讲清楚，放对位置。
上下文模块组织原则：

• 上下文内容比较长，最好放到最后，以免打断提示词
• 上下文结构讲清楚，合适和组织形式影响token数量也会影响性能
• 上下文在任务中承担的作用和价值

举例：在生成sql环节，上下文输入较多，具体组织形式如下：

上下文输入：一般放在提示词结尾处：

4. CoT(Chain of Thoughts)

CoT本来是提示词的一种框架，是针对逻辑比较强的任务场景提出的。就是要提醒或者约束模型按照要求思考，以提升准确率
在复杂场景下，CoT，也可以理解为执行流程或者说思考过程，可以作为整个prompt一部份，模型在充分理解任务和上下文之后，再按照CoT步骤执行拆解任务，往往可以让模型按照要求执行，听话程度高出很多。我们的经验是可以提升准确了20个percent。
示例如下：维度解析

要求和限制
看是什么级别，可以写在CoT模块内，也可以单独一个模块，因地制宜即可。要求和限制一般是任务中需要特殊强调、特殊处理的逻辑，建议二者分开写。举例：

特殊逻辑表达
在写prompt中有些逻辑用文字特别难以准确表达，有时候准确表达出来需要上百字，对于模型准确理解就更难了。 这个时候可以考虑使用伪代码来表达，模型理解起来既快又准。比如，收入月报每月定稿时间13日，如何根据当前时间取出月表的最新时间，并考核时间的格式。

5. 输出规范

模型太爱表达了，它往往不会只输出你想要的内容，总是输出很多自己的思考过程或者考虑的因素，以表达自己的聪明。又或者是不按照要求的格式输出，对输出的规范要求必不可少，一些平台可以实现结构化输出，不过结构化输出的基础是要模型能输出结构清晰的结构。
输出规范一般包含两部分内容：
1 期望输出的内容和结构
2 禁止输出的内容和结构