提示词工程的艺术

桦说编程
53 阅读16分钟

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

引言

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

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

一、五大核心提示词技巧

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

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

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

要点：

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

示例对比：

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

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

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

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

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

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

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

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

要点：

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

示例对比：

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

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

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

3. Prompt Optimization（提示词优化）

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

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

优化路径：

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

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

4. Template Systems（模板系统）

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

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

要点：

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

模板示例：

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

代码：
{{code}}

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

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

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

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

设计要素：

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

二、关键设计模式

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

渐进式披露（Progressive Disclosure）

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

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

指令层次结构

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

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

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

错误恢复设计

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

  • 包含回退指令：例如"如果无法确定类型，归类为'其他'"
  • 请求置信度评分：让模型说明它有多确定，方便后续人工复核
  • 不确定时请求备选解释：例如"如果有多种可能的理解，列出前 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）

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

运用方式：

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

示例：

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

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

2. 承诺（Commitment）

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

运用方式：

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

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

3. 稀缺性（Scarcity）

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

运用方式：

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

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

4. 社会认同（Social Proof）

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

运用方式：

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

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

5. 统一性（Unity）

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

运用方式：

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

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

6. 互惠（Reciprocity）

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

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

7. 喜好（Liking）

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

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

原则组合建议

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

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

五、性能优化技巧

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

Token 效率

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

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

优化前后对比：

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

延迟优化

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

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

六、常见陷阱

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

  1. 过度工程：未尝试简单方案就使用复杂提示词

    • 症状：提示词很长，但效果并不比简单版本好
    • 解决：遵循渐进式披露原则，从简单开始

  2. 示例污染：使用与目标任务不匹配的示例

    • 症状：模型在示例类似的场景表现好，其他场景崩溃
    • 解决：确保示例覆盖典型情况和边界情况

  3. 上下文溢出：过多示例或说明超出 token 限制

    • 症状：模型"遗忘"早期指令，输出变得混乱
    • 解决：精简内容，保留最关键的信息

  4. 指令模糊：留下多种解释空间

    • 症状：同样的提示词每次得到不同风格的输出
    • 解决：用具体的词语替代模糊的词语（"简短" → "50字以内"）

  5. 忽略边界：未测试异常或边界输入

    • 症状：正常情况表现好，遇到空值或异常数据就出错
    • 解决：在示例中包含边界情况的处理方式

七、实践检查清单

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

  1. 这是什么类型的提示词？

    • 纪律执行（强制规范） vs 指导（提供建议） vs 参考（纯信息）
    • 不同类型需要不同的语气和说服策略

  2. 我想改变什么行为？

    • 明确目标：是要让模型做什么新事情，还是阻止它做某事？
    • 一个提示词最好只解决一个核心问题

  3. 哪些说服原则适用？

    • 纪律执行通常用权威 + 承诺
    • 指导通常用统一性 + 社会认同
    • 参考文档不需要说服原则

  4. 是否组合过多？

    • 不要同时使用所有七个原则，选择 2-3 个最有效的
    • 过度使用会让提示词显得刻意和操纵性

  5. 这符合伦理吗？

    • 说服技巧是否真正服务于用户利益？
    • 是在帮助用户得到更好的结果，还是在操纵模型做不该做的事？

总结

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

  1. 简洁优先：LLM 已经很聪明，只提供它真正不知道的信息。冗余的解释不仅浪费 token，还可能引入噪音。

  2. 示例胜于说明：Few-Shot 比长篇解释更有效。模型擅长模式识别，给它看你想要的输出，比解释规则更直接。

  3. 渐进式设计：从简单开始，只有当输出不符合预期时才逐步增加约束。这样既能避免过度工程，又便于调试。

  4. 匹配自由度：高风险任务用精确指令（低自由度），低风险任务给模型发挥空间（高自由度）。关键是评估"出错的代价"。

  5. 善用说服原则：权威、承诺、社会认同是最有效且安全的组合。但记住，说服技巧是为了帮助用户，不是操纵模型。

  6. 持续迭代：提示词工程是一个实验过程。小改动可能带来大影响，用数据而非直觉来指导优化。

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

avatar
文章
阅读
粉丝