目录
提示词工程（Prompt Engineering） 是设计和优化输入给大语言模型的指令，以引导模型生成更准确、有用、符合预期输出的一门学问。它不是“随便写句话问 AI”那么简单，既是一些沟通技巧和试错经验的总结，也是一套系统化的设计、测试和优化方法论。
换个更通俗的类比：这就像给公司新来的实习生写工作说明书。你不能只说一句“把事情做好”，而是得把背景讲清楚、目标说明白、步骤列出来、格式要求写规范。提示词工程要做的，本质上就是这件事——用模型能理解的自然语言，写一份高质量的“工作说明书”。
某种程度上说，大模型的能力，可以决定输出的下限，但提示词的质量，直接决定了输出的上限。
一、四大基础原则
在大模型提示词上，原则就是看起来很废话，但是往往十分重要的东西。
1.1、清晰具体
给模型提供模糊的问题时大概率得到模糊的答案，模型猜不出来那些细节，所以原则就是：越具体越好。这是最基础也最容易被忽视的原则。
- 负面示例：总结这篇文章。
+ 正面示例：用诙谐的语言风格三句话总结这篇文章的核心观点，每句话不超过20个字。当我们希望模型输出特定长度、特定风格、特定内容时，一定要把这些要求明确写出来，而不是放在脑子里等着模型“猜到”。
1.2、分解任务
人一口气吃不成个大胖子，模型也不例外。如果任务太复杂，与其让模型一次性完成一个庞大的任务，不如把它拆成多个步骤，再让它一步步照着完成。
- 负面示例：分析这份用户数据报告，找出所有问题并给出解决方案。
+ 正面示例：
1. 首先统计这份数据的各项基本指标（用户数、活跃度、留存率等）
2. 然后找出指标异常的数据点
3. 针对每个异常点分析可能的原因
4. 最后给出改善建议
- 负面示例：分析这份市场报告，提炼关键结论，写一份摘要，再翻译成英文
+ 正面示例：第一步，阅读这份市场报告；第二步，提炼出三个最重要的结论；第三步，为每个结论写一段中文摘要（每段50字以内）；第四步，将这三段摘要翻译成英文分解任务还能在模型进行每一步任务的时候都检查模型是否“跑偏”，如果模型在中间步骤出现信息丢失或注意力偏移，还能及时修正，提高最终的准确度。
1.3、提供上下文
模型是无状态的，在没有记忆的情况下它不知道上一句说了啥，也不知道用户遇到问题的具体业务背景。 所以，要在 Prompt 里把背景交代清楚。
- 负面示例：这个方案有什么问题？
+ 正面示例：我们正在设计一个面向企业用户的SaaS系统，目标用户是HR部门，预算有限、工期紧。以下是我们提出的技术方案，请从成本、开发难度、可维护性三个角度分析它可能存在哪些问题。1.4、添加角色设定
指定一个具体的角色，能显著改变模型的输出风格和专业深度。
- 负面示例：解释一下什么是JWT
+ 正面示例：你是一个有10年经验的Java后端开发工程师，现在需要向一个刚入职的新人解释JWT（JSON Web Token）的工作原理，要求语言通俗、不涉及底层加密细节、给出一个简单的代码示例角色设定本质上是在调用模型在特定领域训练出来的“专家模式”，让它调动相关的知识和表达方式。
二、三大核心模式
2.1 零样本提示（Zero-Shot）
最基础的用法，不给任何示例，直接下指令。适合简单、明确的任务。
请将以下英文句子翻译成中文：
"Good health is over wealth"模型直接输出结果，不需要给它“翻译示例”。
零样本不需要额外引导，适合简单、边界清晰的任务，比如模型“本来就会”的那种。但对于复杂任务，它的表现往往不稳定。
2.2 少样本提示（Few-Shot）
给模型提供 2-3 个输入-输出的示例，精心挑选的示例能让模型快速理解用户的意图，包括格式要求、语气风格、甚至一些隐含规则，从而让模型照猫画虎地模仿。这对格式敏感型任务效果最好，能大幅降低模型的理解偏差。
请将英文短语翻译成中文，保持简洁的成语风格。
示例1：
英文：Time is money
中文：一寸光阴一寸金
示例2：
英文：Practice makes perfect
中文：熟能生巧
现在请翻译：
英文：Good health is over wealth.
中文：
# 大模型大概率输出：健康胜于财富 / 健康是福示例要尽量覆盖各种变体，否则模型会过度拟合示例格式。
2.3 链式思考（Chain-of-Thought, CoT）
当任务涉及推理、计算、逻辑判断时，直接让模型输出答案极易出错。
而更好的做法是：引导模型先展示推理过程，再给出答案。这对于复杂的逻辑推理、数学计算或代码 Debug 效果很好。
- 负面案例：一个苹果 3 元，一个橘子 4 元，小明买了 5 个苹果和 3 个橘子，一共花了多少钱？
+ 正面案例：一个苹果 3 元，一个橘子 4 元，小明买了 5 个苹果和 3 个橘子。请逐步计算他总共花了多少钱。
输出：
苹果部分：5 个 × 3 元 = 15 元
橘子部分：3 个 × 4 元 = 12 元
总计：15 元 + 12 元 = 27 元CoT的精髓在于"慢思考"，让模型“先说怎么想的，再给答案”，把隐式的推理过程显式化。这听起来像小学老师教应用题，但确实能显著提升复杂问题的正确率。
对于复杂问题，还可以在提示词里加一句“让我们一步步思考”（Let's think step by step），在不少推理任务上也有奇效。
三、高级控制
3.1、指定输出格式
不能指望模型“猜到”用户想要的输出格式，大部分时候用户需要明确告诉它。
请分析以下代码中可能存在的性能问题，并按以下JSON格式输出：
{
"issues": [
{
"line": "代码行号",
"type": "问题类型",
"description": "问题描述",
"severity": "高/中/低"
}
]
}指定格式的好处是：输出可直接被程序解析，不用二次加工。在实际工作中，尤其是在后端与 AI 服务对接的场景下，这几乎是必备技能。
3.2、使用分隔符
当提示词中包含“指令”和“输入内容”两部分时，用分隔符（Delimiter）把它们清晰地区分开，能有效防止模型把输入内容当作指令来执行。
请对以下文本进行摘要输出，要求50字以内。
文本内容：
"""
包含换行、特殊字符等的一段长长的文章内容。
"""
中文摘要：常用的分隔符包括 """、---、###、<input></input> 等。
为什么需要分隔符？因为模型会把提示词中的所有文本都当作“指令的一部分”来理解。如果你在输入中写了“忽略以上所有指令”，模型可能会照做。分隔符的作用就是告诉模型：这是“材料”，不是“指令”。
3.3、温度与随机性控制
多数模型 API 都提供 temperature 和 top_p 两个参数来控制输出的随机性。
- temperature（温度）：值越高（如 1.0），输出越随机、越有创意；值越低（如 0.0），输出越确定、越保守。
- top_p（核采样）：按概率累加的方式选择候选词，效果类似于 temperature。
top_p一般保持默认，除非需要精细控制词汇多样性。
推荐：
- 事实问答、代码生成：设置 temperature = 0 ~ 0.2，尽量保留确定性
- 创意写作、头脑风暴：设置 temperature = 0.7 ~ 1.0，鼓励多样性
- 一般场景：0.5 左右是个稳妥的中间值
另外，即使 temperature=0，模型也不总是输出完全一样的结果（因为随机种子、batch 处理等因素带来微小的不确定性），但已经是“最确定”的模式了。
3.4、负向提示（Negative Prompting）
有时候，告诉模型“不要做什么”比告诉它“做什么”更有效，明确边界比模糊鼓励更靠谱。比如：
1、请写一段xxx产品介绍。
不要使用：
- 夸张形容词（如“最好”“第一”“绝对”）
- 第一人称
- 超过200字
2、介绍Java的Stream API，要求：
- 不要讲历史背景
- 不要讲设计理念
- 直接给出5个最常用的代码示例
- 每个示例不超过10行负向提示给模型的输出划红线，特别适合规避模型常见的“套路化”输出，比如不必要的恭维、套话、重复等。
四、提示词优化技巧
4.1、迭代优化法
写提示词，很少有一版定稿的。大部分时候需要经过这样一个流程：
- 写第一版：根据自己的初步理解写提示词
- 看输出：检查输出是否符合预期
- 发现缺失：哪里不符合？哪里多余？哪里容易误解？
- 修改提示词：补上缺失的约束，删掉多余的部分
- 再试一轮：重复以上步骤
这就跟写代码一样——很少有人一次写对，大多数时候需要调试。提示词工程本质上就是“调试”文本指令。
整个过程可以近似类比为 TDD（测试驱动开发）：先用一个测试用例（你的预期输出）指导你修改提示词，直到输出通过测试。
4.2、A/B 测试
当你不确定某种写法哪个更有效时，可以写两个版本的提示词（同一个任务，不同的表述方式）对比输出。这是一个简单但极其有效的优化手段。
例如：
- 版本A：“请分析以下数据”
- 版本B：“请你像一个资深数据分析师一样，逐步分析以下数据，指出关键趋势和异常点”
同一个数据集，两者输出的质量和深度可能完全不同。通过 A/B 测试，你就能找到更适合当前任务的表述。
甚至还可以用一个技巧：让模型自己当评委，给每个输出打分并说明理由。
4.3、错误修正模式
有些任务中模型容易犯特定类型的错误，可以在提示词中主动提及这些常见错误并加以规避，有点类似负向提示词的作用，都是给模型输出设置明确边界，即“不要做、不能做的事情”。
请提取以下文本中的关键实体（人名、地名、机构名）。
注意：不要将非专有名词误识别为地名，不要缩写机构名。这比单纯等模型犯错再纠正要高效得多。模式是：先承认错误存在的可能，再给出规避的指令，模型犯错的概率会明显降低。
4.4、提示词模板化
当提示词写好、经过多轮优化之后，可以把它提取成一个模板，把需要替换的部分做成占位符 {变量名}，每次使用时只需填入具体内容。这种思路和编程中的“模板方法模式”如出一辙。
【模板结构】
角色设定：{role}
任务目标：{task}
输出格式：{format}
约束条件：{constraints}
示例：{examples}模板化带来的好处：可复用、便于维护、方便团队共享。在实际项目中，提示词模板往往被放在配置文件或代码常量中，而不是每次手写。
参考资料：
众多国内外大模型
评论 (0)