这篇文章整理自 Anthropic 官方博客《Best practices for prompt engineering》。原文发表于 2025 年 11 月 10 日，本文在保留原意的基础上做了中文整理和润色，便于直接阅读。

为什么提示工程仍然重要

Context engineering（上下文工程）正在成为构建大语言模型应用时越来越重要的一环，而 prompt engineering（提示工程）依然是其中最基础的构件。

所谓提示工程，本质上就是通过设计输入指令，让模型更稳定地给出你真正想要的结果。它不仅关乎你“问了什么”，也关乎你如何表达任务、如何补充背景、如何约束输出，以及如何引导模型的行为。

一个模糊的提示，往往只会得到泛泛而谈的回复；一个设计良好的提示，则更有机会一次到位。前者常常需要多轮来回澄清，后者则能显著减少反复沟通的成本。

如何理解提示工程

从最基本的层面看，提示工程就是对你发给模型的请求做有意识的调整。多数时候，它并不复杂，只是在正式提问之前补充一些必要信息。真正的关键不在于“加得多不多”，而在于“加的是不是对的信息”。

核心技巧

这些方法构成了高质量提示的基础。持续使用，通常就能明显改善模型输出。

明确、直接、清晰

现代模型通常对清晰明确的指令反应很好。不要假设模型会自动猜到你的意图，直接把要求说出来。

关键原则是：准确告诉模型你希望看到什么。如果你想要全面的输出，就明确说“全面”；如果你想要特定功能，就把它们列出来。像 Claude 这类现代模型，尤其受益于直接而具体的引导。

示例：创建分析仪表板

模糊的：

创建一个分析仪表板

明确的：

创建一个分析仪表板。包含尽可能多的相关功能和交互。不要停留在基础版本，而是实现一个功能完整的版本。

第二种写法清楚表达了你想要的不只是“能跑”，而是“尽可能完善”。

最佳实践：

  • 用直接的动作动词开头，比如“写”“分析”“生成”“创建”
  • 少写铺垫，尽快进入请求本身
  • 直接说明你希望输出“包含什么”
  • 对质量、深度和完成度提出明确预期

提供上下文和动机

解释“为什么要这样做”，往往能帮助模型更准确理解目标，并据此调整输出。

示例：说明格式偏好

效果较差：

永远不要使用项目符号

更有效：

我更喜欢自然段落形式的回答，而不是项目符号，因为我觉得连贯的散文更容易阅读，也更接近日常对话。项目符号对我来说显得太正式、太像清单。

第二种写法不只是给出规则，还解释了规则背后的原因。模型理解了原因后，通常也更容易在相近场景中做出一致判断。

适合补充上下文的情况：

  • 说明输出的用途或目标受众
  • 解释某些约束为什么存在
  • 说明结果会被怎样使用
  • 交代你真正想解决的问题

尽量具体

提示越具体，结果通常越可控。这里的“具体”，不是机械地堆细节，而是给模型足够明确的约束和目标。

示例：设计膳食计划

模糊的：

为地中海饮食创建膳食计划

具体的：

为前驱糖尿病管理设计一份地中海饮食膳食计划。每天 1,800 卡路里，重点选择低升糖指数食物。列出早餐、午餐、晚餐和一份零食，并给出完整的营养拆解。

一个足够具体的提示，通常会包含这些信息：

  • 明确约束，比如字数、格式、时长、时间表
  • 相关背景，比如受众是谁、目标是什么
  • 输出结构，比如要段落、表格还是列表
  • 额外要求或限制，比如预算、技术条件或饮食禁忌

用示例代替抽象描述

示例并非总是必须，但在说明格式、风格或隐含规则时尤其有效。它也常被称为 one-shot 或 few-shot 提示。

现代模型会高度关注示例中的细节，因此示例本身必须与你希望得到的结果保持一致，并尽量避免带入你不想鼓励的模式。

示例：文章摘要

没有示例：

总结这篇文章

有示例：

这是我想要的摘要风格示例：

摘要：欧盟通过了针对高风险系统的全面 AI 法案。关键条款包括透明度要求和人工监督机制。法案将于 2026 年生效。

现在请用同样的风格总结这篇文章：[你的新文章链接]

适合使用示例的情况：

  • 想要的格式更适合“展示”而不是“解释”
  • 你需要特定语气或文风
  • 任务里存在难以口头讲清的细微模式
  • 单纯描述无法稳定产出一致结果

实用建议：先从一个示例开始。只有在结果仍然不稳定时，再增加更多示例。

允许模型表达不确定性

要明确允许模型在证据不足时说“不确定”或“我不知道”，而不是强行补全。

示例：

分析这份财务数据并识别趋势。如果数据不足以支持结论，请明确说明，而不是推测。

这样做通常能减少幻觉，提高输出的可信度。

高级提示技巧

基础方法已经能覆盖很多场景，但如果你在构建智能体、处理复杂数据结构，或面对多阶段任务，就可能需要更高级的方法。

预填充响应

预填充（prefill）是指先替模型写好回复的开头，以此引导格式、语气或结构。它尤其适合强制输出格式，或者跳过寒暄式开场。

适用场景：

  • 你需要模型输出 JSON、XML 等结构化内容
  • 你想跳过“这是你要的结果”这类序言
  • 你希望模型以固定语气或角色开头
  • 你想控制响应第一行长什么样

示例：强制输出 JSON

没有预填充时，模型可能会输出：

这是你请求的 JSON：{...}

如果在 API 中做预填充：

messages = [
    {"role": "user", "content": "从这段产品描述中提取名称和价格，并输出为 JSON。"},
    {"role": "assistant", "content": "{"}
]

模型就会从左花括号继续，更容易只输出合法 JSON。

在聊天界面里，可以用更明确的要求近似实现：

只输出合法 JSON，不要任何前置说明。请直接以左花括号开始。

思维链提示

思维链（Chain of Thought，CoT）是指要求模型在给出答案前，先进行逐步推理。它对复杂分析类任务尤其有帮助。

现代模型有时支持 extended thinking（扩展思考）之类的能力，用来自动完成结构化推理。在可用的情况下，它通常优于手工写思维链提示。不过，手工 CoT 在以下场景仍然有价值：你需要可审阅的推理过程，或者当前环境并不支持扩展思考。

适用场景：

  • 当前环境不支持扩展思考
  • 你需要透明、可检查的推理过程
  • 任务涉及多个分析步骤
  • 你想确保模型逐项考虑特定因素

常见写法有三种。

基础思维链

直接要求“逐步思考”：

请为捐赠者起草一封个性化邮件，邀请其为今年的 Care for Kids 项目捐款。

<program>
...
</program>

<donor>
...
</donor>

在写邮件之前，请先逐步思考。

引导式思维链

把推理步骤直接写进提示里：

在写邮件之前先思考。首先，考虑哪些信息会根据这位捐赠者的过往捐赠记录打动他们。然后，考虑 Care for Kids 项目的哪些方面最可能引起他们共鸣。最后，根据上述分析写出个性化捐赠邮件。

结构化思维链

把推理和最终答案分开：

请先在 <thinking> 标签中思考。首先分析什么样的信息会打动这位捐赠者，然后识别与其相关的项目亮点。最后，在 <email> 标签中写出个性化捐赠邮件。

即使模型支持扩展思考，明确的 CoT 提示在复杂任务里仍然可能有帮助。两者并不冲突。

控制输出格式

对于现代模型，控制格式有几种常见且有效的做法。

1. 告诉模型“要做什么”，而不是“别做什么”

不要说：

不要在回答里使用 Markdown

更好的写法是：

请用自然、连贯的散文段落作答。

2. 让提示本身的风格与目标输出一致

你在提示里使用的表达风格，往往会影响模型输出的风格。如果你想减少 Markdown，就不要在提示里堆太多 Markdown 结构。

3. 直接写清格式偏好

例如：

在撰写报告或分析时，请使用清晰、连贯的散文段落，采用完整句式和自然段组织内容。Markdown 仅保留给内联代码、代码块和必要的简单标题。除非内容天然适合列举，或者用户明确要求，否则不要使用有序列表或无序列表。

不要把内容拆成项目符号，而是自然地融入句子和段落。目标是写出可读性高、流畅自然、能顺着逻辑带领读者理解的文本。

提示链

提示链（prompt chaining）不是在一个提示里塞进所有要求，而是把复杂任务拆成多个连续步骤，让每一步只处理一个明确问题，再把上一步的输出喂给下一步。

这种方法通常是用更多延迟，换更高的准确性和稳定性。它特别适合复杂工作流。

示例：研究摘要

第一个提示：

总结这篇医学论文，涵盖研究方法、主要发现和临床意义。

第二个提示：

审查上面的摘要，从准确性、清晰度和完整性三个维度给出分级反馈。

第三个提示：

根据这些反馈改写摘要：[步骤 2 的反馈]

适用场景：

  • 请求本身太复杂，适合拆成阶段
  • 你需要迭代式打磨结果
  • 任务包含多个不同分析步骤
  • 中间结果需要单独验证
  • 单个提示输出始终不稳定

代价也很明确：提示链通常意味着更多轮调用和更高延迟。

那些你可能听说过，但不再那么必要的方法

有些技巧在早期模型时代很流行，但对现在的模型来说，重要性已经下降。你仍可能在旧文档里见到它们，或在特定场景中继续使用。

XML 标签

XML 标签过去常被用来提升结构清晰度，尤其是在一个提示里混合大量数据时。现代模型即使不用 XML，也往往能理解结构；不过在某些情况下，XML 依然有价值。

示例：

<athlete_information>
- 身高：6'2"
- 体重：180 磅
- 目标：增肌
- 饮食限制：素食
</athlete_information>

请根据上面的运动员信息生成膳食计划。

仍可能适合使用 XML 的情况：

  • 提示非常复杂，混合了多种内容类型
  • 你必须非常严格地划定内容边界
  • 你正在使用较旧的模型

在多数现代场景里，更轻量的替代方案通常已经足够，比如清晰标题、空行分隔，以及像“请使用下面的运动员信息”这样直接的表述。

角色提示

角色提示是指先给模型设定一个身份，比如“你是一位财务顾问”。这种方式有时有效，但现代模型通常不需要很重的角色设定也能完成任务。

示例：

你是一位财务顾问。请分析这个投资组合。

需要注意的是，不要把角色写得过度夸张或过度收紧。像“你是一位世界顶级专家，绝不会出错，只能使用专业术语”这类设定，往往反而会限制输出质量。

仍然适合使用角色提示的情况：

  • 你需要在大量输出中保持统一语气
  • 你在构建需要固定角色的应用
  • 你希望模型从某个专业视角来组织分析

很多时候，更直接的写法反而更有效：

请从风险承受能力和长期增长潜力两个角度分析这个投资组合。

组合使用这些技巧

单个技巧各有价值，但真正强大的地方在于组合使用。提示工程的重点，不是把所有技巧一股脑加进去，而是为当前任务选对组合。

示例：

请从这份季度报告中提取关键财务指标，并以 JSON 格式输出。

这个格式很重要：我需要将这些数据直接加载到仪表板中，因此我只需要干净、结构化的 JSON，不要任何额外说明。

下面是格式示例：
{
  "revenue": {"q3": 2400000, "q2": 2100000},
  "profit_margin": {"q3": 0.18, "q2": 0.15}
}

如果你无法确定某个数字，请使用 null，而不是猜测。

请直接以左花括号开始响应：
{

这个提示同时使用了：

  • 明确指令：说明要提取什么
  • 上下文：解释为什么格式重要
  • 示例：展示目标结构
  • 不确定性约束：不知道时用 null
  • 格式控制：指定响应起始形式

怎么选技巧

可以按下面的顺序判断：

  • 你的请求是否已经清晰？如果没有，先把它说清楚
  • 任务是否简单？如果是，通常只需要核心技巧
  • 是否需要固定输出格式？优先考虑示例、预填充或明确格式说明
  • 是否是复杂任务？考虑拆成提示链
  • 是否需要推理？优先用扩展思考；不可用时再考虑思维链

技术选择指南：

目标更适合的方法
特定输出格式示例、预填充、明确格式指令
逐步推理扩展思考或思维链
复杂多阶段任务提示链
透明推理过程结构化思维链
减少幻觉明确允许说“我不知道”

常见问题与排查

即使出发点没问题，提示也可能给出偏差结果。下面是一些常见问题及其修正方向。

问题：回答太泛。 解决：增加具体约束，补充示例，或者明确要求“更全面”“不要停留在基础层面”。

问题：回答跑题，或者没抓住重点。 解决：更明确地说明你的真实目标，并补充提问背景。

问题：格式不稳定。 解决：加入示例，必要时使用预填充控制开头。

问题：任务太复杂，结果不可靠。 解决：拆成多个提示，让每一步只处理一件事。

问题：模型总爱加无关序言。 解决：明确写出“跳过序言，直接给出答案”，或者使用预填充。

问题：模型编造信息。 解决：明确允许它在不确定时说“我不知道”。

问题：你要它执行，它却开始建议。 解决：把动作指令写清楚。例如说“修改这个函数”，不要说“你能建议怎么改吗？”。

一个实用原则是：先从简单提示开始，只在确实有收益时再增加复杂度。

常见误区

  • 不要过度工程化。提示更长、更复杂，不等于结果更好。
  • 不要忽略基础。如果核心请求本身就模糊，再高级的技巧也救不了。
  • 不要假设模型会“读心”。你想要什么，就尽量明确说出来。
  • 不要每次都把所有技巧一起用上。只选当前问题真正需要的。
  • 不要忘记迭代。第一版提示很少就是最佳版本。
  • 不要过度依赖旧技巧。对于现代模型，清晰直接通常比 XML 和重角色设定更重要。

长上下文下的提示工程

高级提示技巧往往会增加上下文开销。示例、详细说明、链式提示，都会消耗更多 token，因此上下文管理本身也是一项能力。

要点不是“能不用就不用”，而是“只在值得的时候使用”。如果一种技巧确实能提升准确性、稳定性或可控性，那么它就有存在价值。

现代模型在长上下文理解上已经比过去强很多，对“中间信息容易丢”的问题也有明显改善。但把大任务拆成更小、更聚焦的子任务，依然常常是更好的策略。原因不只是上下文限制，而是因为明确边界的任务，更容易产出稳定的高质量结果。

实践建议：

  • 处理长上下文时，尽量把信息组织清楚
  • 把最关键的内容放在开头或结尾
  • 面对复杂任务时，优先考虑是否适合拆分成多个聚焦子任务

怎样判断一个提示是否足够好

提示工程本质上是一种需要反复练习的沟通能力。判断提示是否有效，最终还是要靠测试结果。

你可以用几个简单问题来快速评估：

  • 输出是否满足你的具体要求？
  • 你是否一轮就得到了可用结果？
  • 多次尝试时，格式和质量是否足够稳定？
  • 你是否避开了前面提到的常见误区？

最后的建议

提示工程归根结底是在做更高质量的沟通：用模型最容易准确理解的方式表达你的目标。

建议从基础方法开始，把“清晰、具体、补充上下文”先用熟。只有当它们无法解决问题时，再逐步叠加更高级的方法。最好的提示，不是最长的提示，也不是最复杂的提示，而是那个用最少必要结构，最稳定地实现你目标的提示。

从这个角度看，上下文工程的兴起并没有削弱提示工程的重要性。相反，提示工程正是上下文工程最基础的组成部分之一。每一条高质量提示，都会与对话历史、附加材料和系统约束一起，构成最终影响模型行为的完整上下文。