“为什么你和别人用同一个大模型，但我得到的回答总是不够好？”原因很简单——你可能没有用对“提示词”（Prompt）。

Prompt Engineering（提示词工程）已经从“玄学技巧”变成真正的 技术活。

今天分享 Anthropic 官方发布的《Best practices for prompt engineering》，尽可能把抽象的方法讲得可落地、可使用、能马上提升效果。

如果你正在做 AI 应用、产品、内容运营、研发，这篇文章会让你立刻掌握一个更强的 AI。

“上下文工程（Context engineering）”正在成为使用大型语言模型（LLM）的关键能力，而提示词工程（Prompt engineering）是其中最基本的构建模块。

提示词工程是一门“结构化指令”的技艺，它让你能从 AI 模型中获得更好的输出。这包含你如何组织提问方式、指定风格、提供背景信息，以及引导模型的行为，使其更好地达到你的目的。

模糊的指令和精心设计的提示词之间，输出质量可能天差地别。糟糕的提示词会迫使你不断反复澄清，而优秀的提示词往往“一次就对”。

九章智算云⾯向AI开发者和AI应⽤⽅，提供⾼性能GPU算⼒，⽀持主流⼤模型⼀键部署、GPU弹性调度，让AI开发真正‘所想即所算’。

我们的核⼼使命：降低⼤模型训练与推理的算⼒⻔槛，实现算⼒普惠。

已⽀持场景：⼤模型训练和微调，模型推理、科研实验、Agent开发与部署等。

高效、稳定、成本可控的AI算力，从这里开始：
https://www.alayanew.com/?utm_source=online&utm_campaign=csdn

01 如何使用提示词工程

最基础的层面上，提示词工程就是修改你传给 LLM 的输入内容。通常，你只需要在提出真正请求之前向模型补充更多信息——而决定补充哪些信息正是提示词工程的关键所在。

02核心技术

以下提示词工程技术是有效 AI 交互的基础。只要持续使用，你会立刻看到输出质量的显著提升。

1. 明确且清晰（Be explicit and clear）

现代 AI 模型对明确的指令反应极好。不要假设模型能猜出你的意图——直接告诉它你要什么。使用简单、直接、毫不含糊的语言表达你的需求。

核心原则即：

告诉模型你要看到的内容，不要只描述你正在做什么。

如果你需要全面深入的输出，就明确提出；如果你想要特定特征，就一条条列出。

示例：创建分析仪表盘

❌ 模糊的指令：“创建一个分析仪表盘。”

✔ 明确的版本：“创建一个分析仪表盘。请包含尽可能多的相关功能和交互设计。不要只实现基础功能，而是构建一个完整、特性齐全的实现。”

第二个版本明确要求模型提供全面功能，并暗示“高标准”。

最佳实践：

• 用直接的动词开头：“写（Write）”、“生成（Generate）”、“创建（Create）”

• 跳过无意义的开场白，直接开始任务

• 描述你希望“看到的最终结果”

• 指明你对输出的质量、深度或细节的期待

2. 提供背景和动机（Provide context and motivation）

解释“为什么”某件事重要，会帮助 AI 更准确理解你的目标。这对能够更好推理的模型尤其有效。

示例：格式偏好

❌ 较弱：“不要使用项目符号。”

✔ 更好：“我更希望你的回答使用自然段落而不是项目符号，因为自然段落在我阅读时更流畅，也更像对话体。项目符号显得太正式，不适合我的学习方式。”

第二个版本让模型理解你的真正需求，而不是仅仅遵守一个规则。

何时提供背景？

• 解释成果将用于什么场景

• 阐明某些限制的原因

• 声明受众是谁

• 说明你要解决什么问题

3. 要具体（Be specific）

具体化就是用明确的结构、条件、限制去表达你的需求。说明越具体，结果越精准。

示例：饮食计划

❌ 模糊：“做一个地中海饮食计划。”

✔ 具体：“为一位前期糖尿病患者设计一个地中海饮食计划，每天 1800 千卡，强调低 GI 食物。请列出早餐、午餐、晚餐和一份加餐，并提供完整的营养成分。”

好的提示词应该包含：

• 明确的限制（时间、字数、格式、预算等）

• 必要的背景（用户是谁？目的是什么？）

• 输出结构说明（列表？段落？表格？）

• 任何要求或禁忌

4. 使用示例（Use examples）

示例并非总是必须的，但当你需要解释概念或展示特定格式时，示例非常有效。这类方法也被称作 one-shot / few-shot prompting，通过“展示而非描述”来帮助模型理解那些仅靠文字难以表达的细微要求。

注意（非常重要）：现代模型（如 Claude 4.x）对示例中的细节非常敏感。如果你给的示例包含你不想要的模式，它也会被模型模仿。因此务必确保示例完全符合你想要的输出风格。

示例：文章摘要

❌ 无示例：“总结这篇文章。”

✔ 使用示例：

以下是我想要的摘要风格示例：文章：（AI 监管相关内容的文章链接）摘要： 欧盟通过全面 AI 法案，重点针对高风险系统。核心条款包括透明度要求与人工监督，2026 年生效。现在，请用同样的风格总结下面这篇文章：（你要总结的文章）

何时使用示例：

• 当格式“展示比描述更容易”

• 当你需要非常特定的语气或风格

• 当任务包含微妙的结构或模式

• 当你发现“仅靠描述”无法稳定生成正确格式

问题	解决方式
输出太泛	增加具体要求、示例、明确深度
输出偏离主题	提供更多背景：目的 / 受众 / 使用场景
输出格式不稳定	提供示例 + 预填
复杂任务效果差	使用 Prompt chaining
模型编造信息	明确允许“不确定”
模型只给建议不执行	明确要求“直接执行修改”
出现无关的开头说明	指令中加入“跳过前置说明”或使用 prefill

专业提示：先从 one-shot（一个示例）开始。如果效果仍不稳定，再尝试 few-shot。

5. 允许模型表达不确定性（Give permission to express uncertainty）

你可以明确告诉模型：“当信息不足时，请说不知道，不要猜测。”

这样可以显著减少模型幻觉（hallucination）。

示例：

“分析这份财务数据并找出趋势。如果数据不足以支撑结论，请直接说明，而不是进行推测。”

这一简单的指令会让模型输出更可信、更稳健。

— 以上为核心技术；以下是进阶提示词工程 —

03 进阶提示词工程技术（Advanced techniques）

以上基础技巧已经能处理绝大多数日常场景，但在以下情况中，你可能需要更高级的方式：

• 构建 agent 级别工具

• 处理复杂数据结构

• 解决多阶段任务

• 需要更高的稳定性或更明确的结构

以下是高级方法。

6. 预填（Prefill the AI’s response）

“预填（Prefill）”是指你可以提前写出模型回答的开头，引导它生成特定格式、语气或结构。

对“格式化输出”尤其强大。

何时使用 Prefill：

• 输出必须是 JSON / XML / 结构化格式

• 你想跳过“以下是你要的 JSON”之类的前缀

• 你想维持统一语气 / 人设

• 你想控制模型输出的开头方式

示例：强制生成 JSON 输出

❌ 常见问题：模型会说：“这里是你要的 JSON：{……}”

✔ 使用 Prefill（API 示例）：

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

AI 会从开启的大括号处继续，并且只输出有效的 JSON。

注意：在聊天界面中，你可以通过非常明确的方式来实现这一点：“只输出有效的 JSON，不要有任何前置说明。回答以一个左大括号开始。”

7. Chain-of-thought（思维链）

链式思考是指让模型“先推理，再回答”。适用于逻辑推理、分析类任务。

现代方式：Claude 具备原生“扩展思考（extended thinking）”，无需手写 chain-of-thought。如果不能使用该功能，可以通过手动提示实现。

何时使用 chain-of-thought：

• 你需要可检查的推理过程

• 任务包含多步骤分析

• 单步指令无法得到稳定结果

链式思考常见三种方式：

① 基础 CoT：只需在指令中添加“一步步思考”即可。

起草个性化电子邮件，向捐赠者请求为今年的“关爱儿童”项目捐款。
项目信息:
  <program>
  {{PROGRAM_DETAILS}}
  </program>
  捐赠者信息:
    <donor>
    {{DONOR_DETAILS}}
    </donor>
    在撰写邮件之前请逐步思考。

② 引导式 Chain-of-thought：将你的提示结构化为具体的推理阶段。

请在写邮件之前，先分析：
1）该捐赠者可能关注什么内容
2）该项目的哪些亮点与其兴趣相关分析完成后，再基于推理写出个性化邮件。

③ 结构化 Chain-of-thought（用标签区分推理和最终答案。）

<thinking>
请分析这个捐赠者的历史捐赠倾向……
</thinking>
<email>
基于以上分析，以下是个性化邮件……
</email>

这种结构非常适合需要“可审查推理”的任务。

注意 ：即使可以进行延伸思考，明确的 CoT 提示对于复杂任务仍然有益。这两种方法是互补的，而非互斥。

8. 控制输出格式（Control the output format）

现代 AI 有多种方式可以控制格式。

方法 1：告诉模型要做什么，而不是不要做什么

❌ “不要使用 markdown。”✔ “请使用整段自然语言，不使用标题符号或项目符号。”

方法 2：你的提示格式会影响输出格式

如果你希望尽量减少 Markdown，就在提示中减少 Markdown 的使用。

方法 3：明确格式偏好

关于格式的详细控制：

在撰写报告或分析时，请使用清晰、连贯的散文式表达，并使用完整的段落。通过标准的段落分隔来组织内容。Markdown 主要仅用于行内代码、代码块以及简单标题。除非确实需要呈现彼此独立的项目，且列表格式是最佳方式，或者用户明确要求使用列表，否则不要使用有序列表或无序列表。不要用项目符号罗列内容，而是将信息自然地融入句子当中。你的目标是让文本可读、流畅，并能自然地引导读者理解你的思想。

“格式清晰指令”可以显著提高一致性。

9. 提示词链式分解（Prompt chaining）

与之前技术不同，提示词链式分解无法在一条提示词里完成。提示词链（Prompt chaining）就是把复杂任务拆分成多个连续步骤，每一步都用独立提示词处理，上一步输出作为下一步输入。

这种方式牺牲一些速度（需要多轮），但换来更高的准确性与稳定性。通常应用在工作流、程序调用等真实场景中；当然，你也可以手动执行。

示例：研究论文总结

第一步：

“请总结这篇医学论文，包括方法、发现和临床意义。”

第二步：

“请审查上述总结，在准确性、清晰度与完整性方面给出评分和反馈。”

第三步：

“根据第 2 步提供的反馈，改进摘要。”

每个阶段让模型专注于一个目标，使最终结果质量更高。

何时使用 Prompt Chaining：

• 任务太复杂，无法一次完成

• 需要迭代改写

• 涉及多阶段分析

• 需要中间验证步骤

• 单条提示词结果不稳定或不一致

权衡：

链式分解会减慢整体速度（多次调用），但对复杂任务来说，提升的准确性往往非常值得。

10. 你可能听说过的技巧（旧方法 vs 现代模型）

过去一些提示词工程技巧曾很流行，但随着模型能力增强，它们变得不那么必要。你可能仍会在旧文档或教程中看到它们。

10.1 XML 标签结构（XML tags for structure）

早期模型理解上下文较弱，人们常用 XML 标签来明确结构。

例如：

<athlete_information>
- Height: 6'2"
- Weight: 180 lbs
- Goal: Build muscle
- Dietary restrictions: Vegetarian
</athlete_information>
根据以上运动员信息，生成一个饮食计划

何时仍可用 XML？

• 你处理极其复杂、混杂的内容

• 你需要严格隔离上下文区域

• 使用旧版模型时

现在的替代方案：清晰的标题、空行或简单自然语言结构就能达到同样效果：

“根据以下运动员信息生成计划：（信息列表）”同样有效且成本更低。

10.2 角色扮演提示（Role prompting）

这类技巧是让模型“扮演”某个专家角色：

“你是一位金融顾问，分析以下投资组合……”

虽然这可能有效，但现在的模型已经足够先进，通常无需过度依赖这种强制性的角色设定。

重要提醒：

不要把角色设定得过于限制：不要把角色限制得过于严格。“你是一个乐于助人的助手”通常比“你是一位世界知名的专家，只用技术术语、从不犯错”更好。过于具体的角色设定可能会限制 AI 的实用性。

何时仍需要角色设定？

• 你需要大量内容保持一致语气（如生成一批客服回答）

• 构建应用时需要某一个固定角色

• 用“从某个观点出发”表达任务需求

现在的替代方式：很多时候，直接明确你想要的分析视角会更有效，比如使用“分析这个投资组合，重点关注风险承受能力和长期增长潜力”，而不是给模型分配一个角色。

11. 综合使用技巧（Putting it all together）

上面介绍了许多独立技巧，但它们真正的力量来自“组合使用”。提示词工程的艺术不是用尽所有技巧，而是根据需求选择正确的组合。

以下示例结合了多种技巧：

示例：结合多项技术的高级提示词

使用以下结构：
{"revenue": "带单位的数值",
 "profit_margin": "百分比",
 "growth_rate": "百分比"
}
如果报告中未明确说明某项指标，请使用 null，而不要猜测。
请以左大括号 “{” 开始你的回复。

这条提示结合了：

• 明确指令（提取什么）

• 背景（为什么需要 JSON）

• 输出模板（提供结构）

• 不确定性处理（未知用 null）

12. 如何选择合适的提示词技巧？

并非所有提示词都需要所有技巧。

你可以按照以下流程选择：

1. 选择流程（Decision Framework）

你的请求是否清晰？→ 如果不清晰，优先明确需求

2. 任务是否简单？→ 是：用基础技巧（清晰 / 具体 / 提供背景）→ 否：继续往下判断

3. 任务需要特定格式吗？→ 用示例、模板、预填

4. 任务很复杂吗？→ 用提示词链式分解（prompt chaining）

5. 需要模型进行推理吗？→ 使用 extended thinking 或 chain-of-thought

你可参照这个提示词技术选择指南：

需求	使用技巧
需要特定格式	示例、预填、明确格式指令
需要步骤推理	扩展推理 / Chain-of-thought
任务复杂	Prompt chaining
需要透明推理过程	结构化 CoT
避免幻觉	允许“不确定”
想让模型直接执行而不是提出建议	明确要求“直接修改”

13. 常见提示词问题（Troubleshooting）

以下是常见错误和解决方案：

• 问题：回复过于泛泛 → 解决方案：增加具体性、示例，或明确要求提供全面的输出。让 AI “超越基础内容”。

• 问题：回复偏题或没有抓住重点 → 解决方案：更明确地说明你的真实目标。提供你提出问题的背景原因。

• 问题：回复格式不一致 → 解决方案：添加示例（few-shot），或使用预填充来控制回复的开头。

• 问题：任务过于复杂，导致结果不可靠 → 解决方案：将任务拆分为多个提示（链式处理）。每个提示只专注做好一件事。

• 问题：AI 加入了不必要的前置说明 → 解决方案：使用预填充，或明确要求：“跳过开场白，直接给出答案。”

• 问题：AI 编造信息 → 解决方案：明确允许它在不确定时说 “我不知道”。

• 问题：当你想要的是直接修改实现时，AI 却只给出了修改建议 → 解决方案：明确你的意图，例如使用“修改这个函数”，而不是“你能给点修改建议吗？”。

专业提示：从简单开始，逐步增加复杂度。每加一个技巧都测试一下是否真的提升效果。

14. 常见错误（Common mistakes to avoid）

• 不要过度工程化：并非越长、越复杂的提示就越好。

• 不要忽视基础：如果核心提示词模糊不清，再高级的技巧也无济于事。

• 不要指望 AI 能读懂你的心思：明确说出你的需求。留下模糊空间只会让 AI 有误解的可能。

• 不要试图一次性用尽所有技巧：选择能解决你具体问题的方法即可。

• 不要忘记迭代优化：首次给出的提示词很少能完美生效，多测试、多打磨即可。

• 不要依赖过时的技巧：现代模型已不太需要 XML 标签和复杂的角色设定。直接用明确、清晰的指令开头即可。

15. 提示词工程与长内容（Context considerations）

使用高级提示词工程的挑战之一，在于额外的提示词使用会增加上下文开销。示例、多轮提问、详细指令 —— 这些都会消耗 Token，而上下文管理本身就是一项必备技能。

仅在确有必要且能体现其价值时，再运用提示词工程技巧。

上下文感知能力升级：现在的 AI 模型，已大幅提升上下文感知能力，有效解决了以往长文本中 “中间信息丢失” 的问题 —— 此前模型难以对长上下文的所有部分给予同等关注。

任务拆分为何仍具价值？即便有了这些改进，将大型任务拆分为更小的独立模块仍是高价值技巧 —— 这并非源于上下文限制，而是因为拆分能让模型聚焦特定需求与范围，发挥最佳效能。一个边界清晰的专注任务，比在单一提示词中试图完成多个目标，更能持续产出高质量结果。

建议：

• 将技术用在真正需要的地方

• 对于长内容，合理组织信息结构（重要内容放前后）

• 对于复杂任务，适当拆分步骤会提升质量

16. 一个好的提示词长什么样？

提示词工程是一项需要打磨的技能，想要精通绝非一蹴而就。判断方法是否得当的唯一标准，就是动手测试验证。第一步不妨亲自尝试 —— 你会立刻发现，运用我们分享的这些技巧，与直接抛出原始问题的效果截然不同。

快速评估建议 ：

• 输出是否符合你的要求？

• 你是否“一次”就得到满意结果？

• 多次尝试是否保持一致？

• 是否避免了前文列出的常见错误？

17. 最后的建议（Final words）

提示工程归根结底是沟通：说出最能帮助 AI 清晰理解你意图的语言。从本指南开头介绍的核心技巧开始。持续使用，直到它们成为第二天性。只有在解决特定问题时才加入高级技巧。

• 从核心技巧开始

• 熟练后自然知道什么时候加入进阶技巧

• 不要追求“最多技巧”，而是“最少但足够”

• 提示词越是明确、结构越合理，模型越能稳定输出

随着“上下文工程”兴起，提示词工程并没有变弱，相反，它是上下文工程的核心构件。

写在最后

AI 时代，懂 AI 的人不是最厉害的；

能让 AI 更好用的人，才是真正的增幅者。

Prompt Engineering 不是程序员才能学的，而是每个内容创作者、运营、产品经理都应该掌握的核心技能。

把这篇文章收藏起来，每天用 1～2 条技巧练习，你会发现：

你的 AI 输出质量可以在一周内提升一个等级。

高效、稳定、成本可控的AI算力，从这里开始：
https://www.alayanew.com/?utm_source=online&utm_campaign=csdn