提示词工程的艺术

关注我，获取最新AI思考。

引言

在 AI 时代，提示词工程（Prompt Engineering）已成为与大语言模型（LLM）高效协作的核心技能。一个精心设计的提示词可以显著提升模型输出的质量、一致性和可控性。本文基于 Anthropic 官方最佳实践，总结了提示词工程的核心技巧与设计原则。

免责声明：有些技巧因AI而异，请合理运用。

一、五大核心提示词技巧

1. Few-Shot Learning（少样本学习）

核心思想：用示例教学，而非规则解释。

想象你在教一个聪明的新同事如何写代码注释。你可以花 10 分钟解释注释风格的各种规则，也可以直接给他看 3 个好的例子。大多数情况下，看例子更快、更准确。LLM 也是如此------它们天生擅长模式识别，从示例中学习比从抽象规则中学习更自然。

要点：

提供 2-5 个输入输出示例对（通常 3 个是最佳平衡点）
示例比文字说明更有效，因为模型可以直接"看到"你期望的模式
示例越多准确率越高，但消耗更多 token，需要权衡成本
选择示例时要覆盖常见情况和边界情况

示例对比：

css 复制代码

❌ 规则描述方式：
"请将用户输入转换为JSON格式，键名使用camelCase，
字符串值用双引号，数字不加引号..."

✅ Few-Shot 方式：
输入: "用户名张三，年龄25"
输出: {"userName": "张三", "age": 25}

输入: "产品手机，价格2999"
输出: {"productName": "手机", "price": 2999}

现在处理: "城市北京，人口2100万"

适用场景：需要一致格式、特定推理模式、边界情况处理

2. Chain-of-Thought（思维链提示）

核心思想：要求模型在给出答案前，先进行逐步推理。

这个技巧源于一个简单的观察：当人类被要求"直接说答案"时，容易犯错；但如果被要求"先写出推理过程"，准确率会大幅提升。LLM 表现出类似的特性------它们在"思考"的过程中生成的中间 token，实际上帮助它们更好地组织推理链条。

要点：

零样本方式：只需添加一句"让我们一步步思考"，模型就会自动展开推理
少样本方式：提供带推理过程的示例，模型会模仿这种详细的思考方式
研究显示可提升分析任务准确率 30-50%，尤其在数学和逻辑任务上效果显著
额外好处：推理过程可见，方便发现模型在哪一步出错

示例对比：

ini 复制代码

❌ 直接回答：
问: 小明有5个苹果，给了小红2个，又买了3个，现在有几个？
答: 6个

✅ 思维链方式：
问: 小明有5个苹果，给了小红2个，又买了3个，现在有几个？
让我们一步步思考：
1. 初始：小明有 5 个苹果
2. 给小红后：5 - 2 = 3 个
3. 买了3个后：3 + 3 = 6 个
答: 6个

适用场景：复杂问题、多步逻辑、数学推理、需要可解释性的场景

3. Prompt Optimization（提示词优化）

核心思想：通过测试和迭代系统性改进提示词。

提示词工程不是一次性的工作，而是一个持续优化的过程。就像调试代码一样，你需要观察输出、分析问题、调整输入、再次测试。很多人犯的错误是一开始就写一个超复杂的提示词，结果难以调试。更好的方法是从简单开始，逐步添加约束。

优化路径：

从简单开始：先用最基础的指令测试，看看模型的"默认行为"
测量性能：定义清晰的评估指标（准确性、格式一致性、token 消耗）
迭代改进：每次只改一个变量，观察效果变化
使用 A/B 测试：对比不同版本的提示词，用数据说话

关键认知：小改动可能带来大影响。有时候把"请"改成"必须"，或者把指令从末尾移到开头，就能带来显著的效果提升。这也是为什么需要系统性测试，而不是凭感觉调整。

4. Template Systems（模板系统）

核心思想：构建可复用的提示词结构。

当你发现自己在重复写类似的提示词时，就是引入模板系统的时候了。模板让你把变化的部分（用户输入、具体参数）和稳定的部分（指令、格式要求）分离开来，既减少重复劳动，又确保一致性。

要点：

变量和占位符 ：用 {{variable}} 标记需要动态填充的部分
条件分支：根据不同情况选择不同的指令片段
模块化组件：把常用的指令片段封装成可复用的模块
减少重复，确保一致性，降低出错概率

模板示例：

bash 复制代码

# 代码审查模板
你是一位资深的 {{language}} 开发者。
请审查以下代码，重点关注：
{{#if security_focus}}
- 安全漏洞（SQL注入、XSS等）
{{/if}}
{{#if performance_focus}}
- 性能问题和优化空间
{{/if}}
- 代码可读性和最佳实践

代码：
{{code}}

适用场景：多轮对话、角色交互、相同模式应用于不同输入

5. System Prompt Design（系统提示词设计）

核心思想：设置全局行为和约束。

系统提示词就像是给模型的"工作手册"------它定义了模型应该扮演什么角色、遵循什么规则、输出什么格式。与用户消息不同，系统提示词在整个对话过程中保持稳定，是设置全局约束的最佳位置。

设计要素：

定义角色和专业领域：告诉模型它是谁，擅长什么（例如："你是一位精通 Java 8 的后端工程师"）
设置输出格式要求：统一响应格式（JSON、Markdown、特定模板等）
明确安全规范：设置边界，防止模型做不该做的事
稳定指令放入系统提示词：这样每次用户对话都自动生效，不需要重复说明

二、关键设计模式

设计模式是经过验证的解决方案模板。以下三个模式在提示词工程中特别有用。

渐进式披露（Progressive Disclosure）

从简单开始，按需增加复杂度。这个原则来自用户界面设计，但同样适用于提示词------先让模型尝试简单的指令，只有当输出不符合预期时，才逐步添加约束。

Level 1 - 直接指令："总结这篇文章" → 先看看模型默认会怎么做
Level 2 - 添加约束："用3个要点总结，聚焦关键发现" → 如果输出太长或不够聚焦，添加具体限制
Level 3 - 添加推理："先识别主要发现，再逐一总结" → 如果模型遗漏重点，引导它的思考过程
Level 4 - 添加示例：包含2-3个示例 → 如果格式还是不对，用示例来"教"它

指令层次结构

一个完整的提示词应该按照逻辑顺序组织，让模型能够清晰理解上下文和任务：

css 复制代码

[系统上下文] → [任务指令] → [示例] → [输入数据] → [输出格式]

这个顺序是有讲究的：先告诉模型"你是谁"（上下文），再告诉它"做什么"（任务），然后"怎么做"（示例），最后给它"处理什么"（数据）和"输出成什么样"（格式）。

错误恢复设计

好的提示词不仅要处理正常情况，还要考虑异常情况。提前设计错误恢复机制，可以让模型在遇到困难时有明确的处理方式，而不是随机应对：

包含回退指令：例如"如果无法确定类型，归类为'其他'"
请求置信度评分：让模型说明它有多确定，方便后续人工复核
不确定时请求备选解释：例如"如果有多种可能的理解，列出前 3 种"
明确如何表示信息缺失：例如"如果找不到相关信息，返回 null 而不是编造内容"

三、Agent 提示词最佳实践

Agent（智能体）是能够自主执行任务的 AI 系统，比如 Claude Code。为 Agent 编写提示词与普通提示词有一些不同的考量。

1. 简洁是金（Concise is Key）

核心原则：上下文窗口是公共资源。

Agent 需要在有限的上下文窗口中同时容纳系统指令、工具描述、对话历史和当前任务。如果你的提示词太啰嗦，就会挤占其他重要信息的空间。这就像在一个小房间里------每多放一件不必要的家具，可用空间就少一分。

检验问题（在写每一句话前问自己）：

"Claude 真的需要这个解释吗？" → 如果是常识，删掉
"我能假设 Claude 知道这个吗？" → 如果是通用编程知识，删掉
"这段文字值得消耗 token 吗？" → 如果不是关键信息，删掉

默认假设：Claude 已经很聪明，只添加它真正不知道的信息------比如项目特定的约定、业务规则、或者你独特的偏好。

2. 设置适当的自由度

不同的任务需要不同程度的指令精确度。关键在于评估任务的"风险"和"变化性"：

自由度	适用场景	指令风格
高自由度	多种方法都有效、依赖上下文决策	给出方向，信任模型选择路径
中自由度	存在首选模式但允许变化	提供模板，允许定制
低自由度	操作脆弱易错、一致性关键	提供精确指令，不允许修改

形象比喻：

悬崖边的窄桥：只有一条安全路径 → 低自由度，必须精确告诉模型每一步怎么走
没有危险的开阔田野：多条路径都能成功 → 高自由度，给个大方向就行

实际例子：

写单元测试 → 高自由度（测试方法很多，让模型发挥）
修改数据库 schema → 低自由度（一步错可能丢数据，必须精确指令）

四、七大说服原则

这是一个有趣的发现：研究表明，LLM 对人类说服原则有类似反应。Meincke 等人（2025）的研究显示，在提示词中运用说服技术可将遵从率从 33% 提升至 72%。这些原则源自心理学家 Robert Cialdini 的经典研究，现在被证明对 AI 同样有效。

1. 权威（Authority）

原理：人们倾向于服从权威。在提示词中使用强势、明确的语气，模型会更认真对待指令。

运用方式：

使用祈使语气："必须"、"禁止"、"始终"、"绝不"
不可协商的框架："没有例外"、"无论如何"
消除决策疲劳：明确告诉模型该怎么做，不给它"自由发挥"的空间

示例：

arduino 复制代码

❌ "如果可以的话，请尽量使用类型注解"
✅ "所有函数必须包含类型注解，没有例外"

适用场景：安全关键实践、代码规范强制、最佳实践执行

2. 承诺（Commitment）

原理：一旦公开承诺某事，人们更倾向于坚持到底。让模型先"声明"它会做什么，可以提高遵循率。

运用方式：

要求公开声明："首先，宣布你将使用的方法"
强制明确选择："在继续之前，选择 A、B 或 C 并说明原因"
使用跟踪机制："在每一步结束时，确认该步骤已完成"

适用场景：确保技能被实际遵循、多步骤流程、问责机制

3. 稀缺性（Scarcity）

原理：稀缺的东西更被珍视。通过创造紧迫感，可以让模型更专注于当前任务。

运用方式：

时间限制要求："在继续之前，先完成验证"
顺序依赖："在 X 之后立即执行 Y，不要跳过"
防止拖延："现在就检查，不要留到后面"

适用场景：即时验证要求、时间敏感工作流

原理：人们倾向于跟随大多数人的行为。暗示"这是标准做法"可以增强指令的说服力。

运用方式：

普遍模式："每次提交代码前都要运行测试"、"资深工程师总是这样做"
失败模式："没有测试的代码 = 生产事故等着发生"
建立规范："这是我们团队的标准流程"

适用场景：记录通用实践、警告常见失败模式

5. 统一性（Unity）

原理：人们更愿意帮助"自己人"。创造共同身份感，可以让模型更投入。

运用方式：

协作语言："我们的代码库"、"我们是同事"、"我们一起来解决这个问题"
共同目标："我们都想要高质量的代码"、"我们的目标是让用户满意"

适用场景：协作工作流、建立团队文化

6. 互惠（Reciprocity）

原理：收到好处后，人们倾向于回报。但在 AI 交互中，这个原则效果有限。

建议：谨慎使用。容易显得操纵性，而且 AI 没有真正的"回报"动机，通常不需要。

7. 喜好（Liking）

原理：人们更容易被喜欢的人说服。

建议：不要用于合规目的。这会导致模型过度讨好用户（谄媚问题），与诚实反馈文化冲突。

原则组合建议

不同类型的提示词需要不同的说服原则组合。过度使用说服技巧会适得其反，选择 2-3 个最适合的原则即可：

提示词类型	推荐原则	避免原则	说明
纪律执行型	权威 + 承诺 + 社会认同	喜好、互惠	如代码规范检查、安全审计
指导/技术型	适度权威 + 统一性	重度权威	如技术指导、最佳实践建议
协作型	统一性 + 承诺	权威、喜好	如结对编程、代码评审
参考文档型	清晰度即可	所有说服原则	如 API 文档、配置说明

五、性能优化技巧

在生产环境中，提示词的效率直接影响成本和响应速度。以下是两个关键的优化维度。

Token 效率

Token 是 LLM 计费的基本单位，优化 token 使用可以显著降低成本：

删除冗余词语：把"请帮我"改成"请"，把"我希望你能够"改成直接的动词
首次定义后使用缩写：第一次写"JavaScript Object Notation (JSON)"，之后都写"JSON"
合并相似指令：把分散的格式要求合并成一条
将稳定内容移至系统提示词：系统提示词可以被缓存，重复使用时不会重复计费

优化前后对比：

arduino 复制代码

❌ "我希望你能够帮我将下面的这段文字翻译成英文，请确保翻译准确、流畅"（27字）
✅ "翻译为英文，保持准确流畅"（10字）

延迟优化

延迟是用户体验的关键指标，尤其在交互式应用中：

最小化提示词长度：在不牺牲质量的前提下，越短的提示词处理越快
使用流式输出：长文本响应时，流式输出让用户能立即开始阅读，体感延迟大幅降低
缓存常用提示词前缀：许多 API 支持前缀缓存，重复的系统提示词不需要每次重新处理
批量处理相似请求：如果有多个类似任务，可以打包处理减少 API 调用次数

六、常见陷阱

在提示词工程实践中，以下是最常见的错误。了解这些陷阱可以帮助你少走弯路：

过度工程：未尝试简单方案就使用复杂提示词
- 症状：提示词很长，但效果并不比简单版本好
- 解决：遵循渐进式披露原则，从简单开始
示例污染：使用与目标任务不匹配的示例
- 症状：模型在示例类似的场景表现好，其他场景崩溃
- 解决：确保示例覆盖典型情况和边界情况
上下文溢出：过多示例或说明超出 token 限制
- 症状：模型"遗忘"早期指令，输出变得混乱
- 解决：精简内容，保留最关键的信息
指令模糊：留下多种解释空间
- 症状：同样的提示词每次得到不同风格的输出
- 解决：用具体的词语替代模糊的词语（"简短" → "50字以内"）
忽略边界：未测试异常或边界输入
- 症状：正常情况表现好，遇到空值或异常数据就出错
- 解决：在示例中包含边界情况的处理方式

七、实践检查清单

在编写或审查提示词时，用以下问题检验你的设计：

这是什么类型的提示词？
- 纪律执行（强制规范） vs 指导（提供建议） vs 参考（纯信息）
- 不同类型需要不同的语气和说服策略
我想改变什么行为？
- 明确目标：是要让模型做什么新事情，还是阻止它做某事？
- 一个提示词最好只解决一个核心问题
哪些说服原则适用？
- 纪律执行通常用权威 + 承诺
- 指导通常用统一性 + 社会认同
- 参考文档不需要说服原则
是否组合过多？
- 不要同时使用所有七个原则，选择 2-3 个最有效的
- 过度使用会让提示词显得刻意和操纵性
这符合伦理吗？
- 说服技巧是否真正服务于用户利益？
- 是在帮助用户得到更好的结果，还是在操纵模型做不该做的事？

总结

提示词工程既是技术，也是艺术。它的核心不是记住一堆技巧，而是理解 LLM 的工作方式，并用恰当的方式与它沟通。以下是本文的核心要点：

简洁优先：LLM 已经很聪明，只提供它真正不知道的信息。冗余的解释不仅浪费 token，还可能引入噪音。
示例胜于说明：Few-Shot 比长篇解释更有效。模型擅长模式识别，给它看你想要的输出，比解释规则更直接。
渐进式设计：从简单开始，只有当输出不符合预期时才逐步增加约束。这样既能避免过度工程，又便于调试。
匹配自由度：高风险任务用精确指令（低自由度），低风险任务给模型发挥空间（高自由度）。关键是评估"出错的代价"。
善用说服原则：权威、承诺、社会认同是最有效且安全的组合。但记住，说服技巧是为了帮助用户，不是操纵模型。
持续迭代：提示词工程是一个实验过程。小改动可能带来大影响，用数据而非直觉来指导优化。

掌握这些技巧，你将能够设计出更可靠、更高效、更可控的 AI 交互体验。但最重要的是------多实践，多测试，从反馈中学习。没有"完美的提示词"，只有"适合当前任务的提示词"。

提示词工程的艺术

引言

一、五大核心提示词技巧

1. Few-Shot Learning（少样本学习）

2. Chain-of-Thought（思维链提示）

3. Prompt Optimization（提示词优化）

4. Template Systems（模板系统）

5. System Prompt Design（系统提示词设计）

二、关键设计模式

渐进式披露（Progressive Disclosure）

指令层次结构

错误恢复设计

三、Agent 提示词最佳实践

1. 简洁是金（Concise is Key）

2. 设置适当的自由度

四、七大说服原则

1. 权威（Authority）

2. 承诺（Commitment）

3. 稀缺性（Scarcity）

4. 社会认同（Social Proof）

5. 统一性（Unity）

6. 互惠（Reciprocity）

7. 喜好（Liking）

原则组合建议

五、性能优化技巧

Token 效率

延迟优化

六、常见陷阱

七、实践检查清单

总结