最新版Claude 提示词工程最佳实践全指南：从“写请求”到“设计思维”的系统升级

什么是 Prompt Engineering？

Claude 团队将提示词工程定义为：

“为AI模型提供高质量指令，以获得更准确、有用、可控输出的艺术与科学。”

简单说，就是你如何跟AI说话，决定了AI的聪明程度。

模糊的提示会让AI输出泛泛之词，而精心设计的提示能让它一次命中目标。 Claude 官方认为：

“Prompt engineering is the craft of structuring instructions to get better outputs from AI models.” “Prompt Engineering 是上下文工程（Context Engineering）的基础模块。”

核心技巧：高质量提示的四大基础

1️⃣ 清晰直接（Be Explicit and Clear）

“AI 不擅长猜测。”

Claude 对“清晰”的定义是：让AI毫无猜测空间。

✅ 要做：

• 用命令式动词开头：“写、分析、生成、创建”
• 指明任务目标，不绕弯，不客套
• 明确说明你要的内容与深度，指定输出范围或格式

🧩 示例 / Example：

❌ 模糊提示：

“Create an analytics dashboard.” “创建一个分析面板。”

✅ 改进提示：

“Create an analytics dashboard that includes data filtering, interactive charts, and export functions. Use React and Tailwind CSS.” “创建一个包含数据筛选、交互图表和导出功能的分析面板，并使用 React 与 Tailwind CSS 实现。”

Claude 提醒：越明确的目标，越少的来回。

2️⃣ 提供上下文与动机（Provide Context and Motivation）

不仅告诉模型“要做什么”，还要告诉它“为什么这样做”。

💡 背景与动机包括：目标受众、使用场景、偏好风格、阅读目的等。

🧩 示例 / Example：

❌ 弱提示：

“Do not use bullet points.” “不要使用项目符号。”

✅ 优化提示：

“I prefer responses in paragraph form rather than bullet points because it feels more natural for my reading style.” “我更喜欢段落式的回答，而不是项目符号，因为那样更符合我的阅读习惯。”

Claude 指出：解释意图能帮助模型推断你没说出口的偏好。模型理解“原因”后，会主动在未来输出中保持这种风格，而非仅遵循一次性规则。

3️⃣ 具体可衡量（Be Specific）

Claude 的原则：

“Specificity equals precision.” ——越具体，AI 的输出越精确。

在提示中加入具体限制条件：

• 格式要求（表格/段落）
• 字数或时间
• 对象与目标受众
• 约束条件（预算、性能、数据规模）

🧩 示例 / Example：

❌ 泛化提示：

“Create a meal plan for a Mediterranean diet.” “制定一个地中海饮食计划。”

✅ 精确提示：

“Design a Mediterranean meal plan for pre-diabetic adults, 1,800 calories per day, focusing on low glycemic foods. Include breakfast, lunch, dinner, and one snack with nutrition details.” “为糖尿病前期人群设计一个地中海饮食计划，总热量1800卡路里，重点包含低血糖指数食物。请列出早餐、午餐、晚餐和加餐，并附上营养详情。”Claude 总结：

“具体性 = AI 的方向感。”

4️⃣ 举例说明（Use Examples）

“Show, don’t just tell.” ——展示比描述更有效。

Claude 4.x 对示例极为敏感，“一例胜千言”。

当你想要特定语气、格式或风格时，提供一到两个参考示例最有效。

🧩 示例 / Example：

Here’s the style I prefer:
Article: [link]
Summary: “EU passes AI Act regulating high-risk systems. Key requirements include transparency and human oversight.”

Now summarize this article in the same format:
[link to another article]

我希望你采用以下摘要格式：
文章：[链接]
摘要：“欧盟通过AI法案，监管高风险系统。主要要求包括透明度和人工监督。”

请用同样的格式总结以下文章：
[另一篇文章链接]

💡 Pro Tip：

• 从 one-shot（单例）开始；
• 如果效果不稳定，再加 few-shot（多例）。

进阶技巧：应对复杂任务的高级策略

1️⃣ 允许AI表达不确定性（Permission to Express Uncertainty）

“If information is missing, ask it to say so instead of guessing.” ——让AI承认不知道，比乱猜更有价值。

🧩 示例 / Example：

Analyze this financial data and identify key trends.
If the data is insufficient to draw conclusions, state that directly instead of speculating.

分析以下财务数据并指出主要趋势。
如果信息不足以得出结论，请直接说明，而不是进行推测。

告诉 Claude：

“如果信息不足，请不要猜测。” 这可有效减少“幻觉”与错误信息。

2️⃣ 预填响应（Prefilling）

在提示中提前提供部分结构或框架，让Claude按指定格式继续输出。

通过在提示中部分写好格式，引导AI续写。

🧩 示例 / Example：

Output only valid JSON. 
Begin your response with:
{

仅输出合法的 JSON。请以以下符号开头：
{适用于：

📘 用途：

• 生成结构化数据（如JSON、YAML、HTML）
• 保持输出格式一致
• 避免出现解释性前缀（如“Here’s the result:”）

3️⃣ 思维链提示（Chain of Thought Prompting）

“Encourage step-by-step reasoning.” ——鼓励AI分步推理。

引导 Claude “逐步思考”再回答，适合复杂推理任务。

三种用法：

• 简单版：“请一步步思考后回答。”
• 引导版：“先分析用户历史，再生成营销邮件。”
• 结构版：用 <thinking> 和 <answer> 标签区分思考与输出。

🧩 示例 / Example：

<thinking>
First, analyze the user’s purchase history to identify their top interests.
Then, generate a personalized product recommendation email.
</thinking>
<email>

<thinking>
首先分析用户的购买历史，识别其主要兴趣。
然后撰写一封个性化的产品推荐邮件。
</thinking>
<email>

这种结构可让Claude先“推理”，再“输出”，适合复杂逻辑任务（分析、规划、编程等）。

💡 Claude 4.x 已内建 “Extended Thinking” 模式，无需显式提示即可启用自动推理。

4️⃣ 提示链（Prompt Chaining）

将复杂任务拆分为多个步骤。 每一步独立验证与改进，再把结果传给下一步。

🧩 示例 / Example：

Step 1: Summarize the research paper in bullet points.  
Step 2: Evaluate accuracy and completeness.  
Step 3: Rewrite the summary in plain language for a general audience.

第1步：用项目符号总结研究论文。  
第2步：评估摘要的准确性与完整性。  
第3步：将摘要改写为通俗语言，适合大众阅读。

Claude 依序执行更稳定、更可靠，拆解是高质量输出的捷径。

5️⃣ 输出控制（Output Control）

“Define what you want, not what you don’t.” ——告诉AI你要什么，而不是你不要什么。

Claude 提供三条格式控制原则：

• 告诉AI要什么，而不是不要什么；
• 保持提示与输出风格一致；
• 明确说明排版规则（如段落、列表、代码块等）。

🧩 示例 / Example：

Write in plain text paragraphs, no Markdown or lists.

以纯文本段落书写，不使用 Markdown 或项目列表。

Claude 输出严格遵守格式，更利于自动处理或前端渲染。

现代提示词写作的取舍（Modern Prompt Design Tradeoffs）

Claude 团队明确指出： 旧时代的一些“提示词技巧”已不再必要。

🧩 示例 / Example：

You are a professor of economics analyzing labor data.
→ Replace with:
Analyze this dataset using economic reasoning and cite key labor market indicators.

📘 解析：角色标签（Role Prompting）在Claude 4系列中意义减弱，直接陈述任务目标更有效。

“过度设定角色会让模型陷入风格限制，而非思考优化。”

现代提示词写作的取舍（Modern Prompt Design Tradeoffs）

Claude 团队明确指出： 旧时代的一些“提示词技巧”已不再必要。

Claude 的提示哲学

Claude’s Prompting Philosophy

“Prompt engineering is communication design.” ——提示词工程本质上是沟通设计。

Claude 团队总结出的三条黄金法则：

1️⃣ 少即是多 最好的提示不是最长的，而是结构最清晰的。

2️⃣ 上下文 > 技巧 Prompt 是 Context Engineering 的一部分， 每条指令都在塑造模型的整体语境。

3️⃣ 清晰、具体、带示例 结构决定可控性

📘 总结： 最好的提示不是最复杂的，而是最结构化、最清晰、最贴近意图的。

一句话总结

Prompt engineering isn’t about magic words — it’s about structured, intentional communication with an intelligent system. 提示词工程不是“咒语”，而是一种结构化、有意图的沟通方式，让AI理解你的意图并输出符合目标的结果。

官方原文翻译

Best practices for prompt engineering

Claude 提示词工程最佳实践

上下文工程（Context engineering） 已经成为使用大语言模型时越来越重要的一部分，而提示词工程则是它最核心的构建单元。

提示词工程（Prompt engineering） 是通过有结构地编写指令，从而让 AI 模型给出更好输出的“手艺”。它涉及你如何提问、如何指定风格、如何提供上下文，以及如何引导模型的行为去实现你的目标。

含糊的指令和精心设计的提示之间，往往意味着“泛泛而谈”和“刚好就是你要的”之间的差距。写得不好的提示，可能需要和模型来回多轮澄清意图，而一个设计合理的提示往往一次就能到位。

为了帮你快速上手，我们整理了一些团队的最佳实践，其中很多方法可以立刻改善你的结果。我们会从你今天就能用上的简单习惯讲起，然后再扩展到适合复杂项目的高级方法。

How to use prompt engineering

如何使用提示词工程

在最基础的层面上，提示词工程就是修改你发给 LLM 的那条请求。很多时候，只是简单地在真正提出“核心请求”之前，先给这条请求补充一些信息。但关键在于，你要知道“补充哪些信息才是对的”，这正是把提示写好的秘诀。

Core techniques

核心技巧

这些提示词工程技巧构成了高质量 AI 交互的基础。只要坚持使用，你就会明显感觉到回答质量的提升。

Be explicit and clear

要清晰、要直白

现代 AI 模型对清晰、明确的指令反应特别好。不要指望模型自行“揣摩”你想要什么，而是直接说清楚。用简单的语言，明确表达你要什么，尽量减少歧义。

核心原则：直接告诉模型你“想看到什么”。如果你想要全面的结果，就直说。需要具体功能，就明明白白列出来。像 Claude 这样的现代模型，对这种明确的指令尤其受益。

示例：创建一个分析仪表盘

Vague（含糊的提示）: "Create an analytics dashboard." “创建一个分析仪表盘。”

Explicit（明确的提示）: "Create an analytics dashboard that includes data filtering, interactive charts, and export functions. Use React and Tailwind CSS." “创建一个包含数据筛选、交互图表和导出功能的分析面板，并使用 React 与 Tailwind CSS 实现。”

第二种写法明确要求“尽量多的功能”和“使用 React + Tailwind CSS”，并且暗示你希望模型做的是“完整方案”，而不是只给一个最基础的版本。

最佳实践：

• 用动词开头：例如 "Write"、"Analyze"、"Generate"、"Create"

“写……”“分析……”“生成……”“创建……”

• 不要长篇铺垫，直接说需求
• 说清楚“输出里要包含什么”，而不是只说“你要处理什么素材”
• 对质量和深度要有明确预期

Provide context and motivation

提供上下文和“为什么”

解释为什么这件事重要，可以帮助模型更好理解你的目标，从而给出更有针对性的回应。对能进行深入推理的新模型来说，这一点尤其有效。

示例：格式偏好

效果较差： "NEVER use bullet points." “绝对不要使用项目符号。”

效果更好： "I prefer responses in natural paragraph form rather than bullet points because I find flowing prose easier to read and more conversational. Bullet points feel too formal and list-like for my casual learning style." “我更喜欢使用自然段落形式的回答，而不是项目符号，因为连贯的文字对我来说更容易阅读，也更有对话感。项目符号对我来说太正式、太像清单了，不适合我这种比较随意的学习方式。”

第二种写法让模型理解了这条“规则背后的原因”，于是它在处理相关格式选择时，也能做出更靠近你真实偏好的决定。

适合补充上下文的场景：

• 需要说明这段输出是给谁看的、用途是什么
• 想解释某些限制为何存在
• 想说明输出会在什么场景里被使用
• 想描述你真正想解决的是什么问题

Be specific

要具体

在提示词工程里，“具体”就是用清晰的规则和要求来组织指令。你越具体，结果通常越好。

示例：饮食计划

Vague（含糊）: "Create a meal plan for a Mediterranean diet." “制定一个地中海饮食的餐单。”

Specific（具体）: "Design a Mediterranean diet meal plan for pre-diabetic management. 1,800 calories daily, emphasis on low glycemic foods. List breakfast, lunch, dinner, and one snack with complete nutritional breakdowns." “设计一个用于糖尿病前期管理的地中海饮食餐单。每天 1800 千卡，重点选择低 GI 食物。请分别列出早餐、午餐、晚餐和一份加餐，并给出完整的营养成分。”

怎样算“足够具体”的提示？ 可以包含：

• 清晰的约束（字数、格式、时间范围等）
• 相关上下文（面向谁、目标是什么）
• 期望的输出结构（表格、列表、段落等）
• 必要的要求或限制（饮食禁忌、预算上限、技术约束等）

Use examples

使用示例（one-shot / few-shot）

示例并非总是必需，但在说明格式、语气或微妙要求时特别有用。也就是我们常说的 one-shot / few-shot 提示，通过“给一个例子”来告诉模型你想要什么，比单纯文字描述更直观。

对现代模型的重要提醒：Claude 4.x 这类模型会非常认真地模仿示例里的细节。所以，务必保证你的示例完全符合你想要的行为，并尽量避免出现你不想被模型模仿的模式。

示例：文章总结

不带示例的提示： "Summarize this article." “总结这篇文章。”

带示例的提示：

Here's an example of the summary style I want:
“I want the summary written in this style:”
“我希望总结按照下面这种风格来写：”

Article: [link to article about AI regulation]
“Article: [link to article about AI regulation]”
“文章：[一篇关于 AI 监管的文章链接]”

Summary: EU passes comprehensive AI Act targeting high-risk systems. Key provisions include transparency requirements and human oversight mandates. Takes effect 2026.
“Summary: EU passes comprehensive AI Act targeting high-risk systems. Key provisions include transparency requirements and human oversight mandates. Takes effect 2026.”
“总结：欧盟通过了一部针对高风险系统的全面 AI 法案。关键条款包括透明度要求和人工监督义务。该法案将于 2026 年生效。”

Now summarize this article in the same style: [link to your new article]
“Now summarize this article in the same style: [link to your new article]”
“现在请用同样的风格总结下面这篇文章：[你的新文章链接]”

适合用示例的情况：

• 目标格式“说不如直接给你看一个例子”
• 你需要一个非常具体的语气或文风
• 任务涉及一些微妙的模式或写作习惯
• 只用文字指令时，输出总是不稳定

小技巧：先用一个示例（one-shot）。只有当输出仍不符合预期时，再逐步增加示例数量（few-shot）。

Give permission to Claude to express uncertainty

明确允许 Claude 说“我不确定”

在指令中明确写出“允许不确定、不要乱猜”，可以有效减少幻觉，让回答更可靠。

示例提示： "Analyze this financial data and identify trends. If the data is insufficient to draw conclusions, say so rather than speculating." “分析这些财务数据并识别其中的趋势。如果数据不足以得出结论，请直接说明，而不是进行猜测。”

这一句简单的补充，就能显著提高回答的可信度。

在 Claude 中试试这些技巧。

Advanced prompt engineering techniques

高级提示词工程技巧

前面的基础习惯已经可以应对很多场景，但你仍会遇到需要“进阶操作”的情况。高级技巧在你构建 agent、处理复杂数据结构，或拆解多阶段问题时特别有用。

Prefill the AI's response

预填 AI 的回复开头

“预填”是指你先写好 AI 回复的一部分，引导它按照某种格式、语气或结构往下写。这对强制输出格式或跳过“客套开场白”尤其好用。

适合用预填的情况：

• 你需要 AI 输出 JSON、XML 等结构化格式
• 你想跳过“这是你要的 JSON：”这类前缀，直接进入内容
• 你想维持特定的语气或角色
• 你希望控制 AI 回答的开头形式

示例：强制 JSON 输出

不使用预填时，Claude 可能这样回答： "Here's the JSON you requested: {...}" “这是你要的 JSON：{...}”

使用预填（API 调用）：

messages=[
    {
      "role": "user",
      "content": "Extract the name and price from this product description into JSON."
    },
    {
      "role": "assistant",
      "content": "{"
    }
]

上面用户提示： "Extract the name and price from this product description into JSON." “从下面的商品描述中提取名称和价格，并用 JSON 格式输出。”

然后通过预填，让 assistant 这轮的开头直接是 {，模型就会自动补全一个合法 JSON。

注意：在普通聊天界面里，你可以用非常明确的提示来模拟预填，比如： "Output only valid JSON with no preamble. Begin your response with an opening brace: {" “只输出合法的 JSON，不要任何前言。请用左大括号 { 作为整段内容的开头。”

Chain of thought prompting

链式思维提示（Chain of Thought）

链式思维提示，是在指令中要求模型在给出答案前先“按步骤思考”。这对复杂分析任务帮助很大，因为它鼓励模型把问题拆解为多个清晰步骤。

现代做法：Claude 提供了 extended thinking 扩展思维 功能，可以自动进行结构化推理。如果可以使用扩展思维，通常推荐直接用它。不过，在扩展思维不可用或你希望审阅具体推理过程时，手动 CoT 依然很有价值。

适合使用链式思维的情况：

• 无法使用扩展思维（比如免费版 Claude.ai）
• 你需要一个可以人工审查的推理过程
• 任务本身需要多步分析
• 你希望 AI 明确考虑某些特定因素

链式思维常见有三种写法：

1. 基础版链式思维

在指令最后加一句： "Think step-by-step before you answer." “在回答之前，请一步一步思考。”

示例：

Draft personalized emails to donors asking for contributions to this year's Care
for Kids program.
“Draft personalized emails to donors asking for contributions to this year's Care for Kids program.”
“为今年的 Care for Kids 项目撰写个性化募捐邮件。”

Program information:
<program> {{PROGRAM_DETAILS}} </program>

Donor information:
<donor> {{DONOR_DETAILS}} </donor>

Think step-by-step before you write the email.
“Think step-by-step before you write the email.”
“在撰写邮件之前，请一步一步地进行思考。”

2. 引导式链式思维

通过文字告诉模型要分成哪些推理阶段。

Think before you write the email. First, think through what messaging might appeal to this donor given their donation history. Then, consider which aspects of the Care for Kids program would resonate with them. Finally, write the personalized donor email using your analysis.
“Think before you write the email. First, think through what messaging might appeal to this donor given their donation history. Then, consider which aspects of the Care for Kids program would resonate with them. Finally, write the personalized donor email using your analysis.”
“在写邮件之前先思考。首先，根据这位捐赠人的历史捐赠记录，思考哪些表达方式可能对 TA 最有吸引力。然后，考虑 Care for Kids 项目中哪些方面会与 TA 产生共鸣。最后，基于你的分析撰写一封个性化的募捐邮件。”

3. 结构化链式思维

用标签把“思考过程”和“最终结果”分开。

Think before you write the email in <thinking> tags. First, analyze what messaging would appeal to this donor. Then, identify relevant program aspects. Finally, write the personalized donor email in <email> tags, using your analysis.
“Think before you write the email in <thinking> tags. First, analyze what messaging would appeal to this donor. Then, identify relevant program aspects. Finally, write the personalized donor email in <email> tags, using your analysis.”
“请先在 <thinking> 标签中进行思考。首先分析哪些表达方式会吸引这位捐赠人，然后标出项目中与之最相关的部分。最后在 <email> 标签中撰写个性化募捐邮件，基于你之前的分析。”

即便有扩展思维功能，显式 CoT 提示在复杂任务中仍然非常有用，两者是互补关系，而不是二选一。

Control the output format

控制输出格式

对现代模型来说，有几种非常实用的格式控制方式。

1. 多说“要做什么”，少说“不要做什么”

比如，不要只说： "Do not use markdown in your response." “不要在回复中使用 markdown。”

可以改为： "Your response should be composed of smoothly flowing prose paragraphs." “请用连贯自然的段落文本来回答。”

2. 提示怎么写，输出往往就怎么写

你在提示里用什么样的格式、结构和风格，模型通常会在输出里部分“照抄”。如果你想要更少 markdown，就尽量在提示里减少 markdown 的使用。

3. 对格式偏好说得更具体

例如：

When writing reports or analyses, write in clear, flowing prose using complete paragraphs. Use standard paragraph breaks for organization. Reserve markdown primarily for inline code, code blocks, and simple headings.
“When writing reports or analyses, write in clear, flowing prose using complete paragraphs. Use standard paragraph breaks for organization. Reserve markdown primarily for inline code, code blocks, and simple headings.”
“在撰写报告或分析时，请使用清晰、连贯的自然段落。通过标准的段落分行来组织内容。markdown 主要用于行内代码、代码块和少量简单的小标题。”

DO NOT use ordered lists or unordered lists unless you're presenting truly discrete items where a list format is the best option, or the user explicitly requests a list.
“DO NOT use ordered lists or unordered lists unless you're presenting truly discrete items where a list format is the best option, or the user explicitly requests a list.”
“除非你在说明一组彼此完全独立的条目，而且列表格式是最合适的方式，或者用户明确要求，否则不要使用有序或无序列表。”

Instead of listing items with bullets, incorporate them naturally into sentences. Your goal is readable, flowing text that guides the reader naturally through ideas.
“Instead of listing items with bullets, incorporate them naturally into sentences. Your goal is readable, flowing text that guides the reader naturally through ideas.”
“与其用项目符号列点，不如把这些要点自然融入句子当中。你的目标是写出可读性高、行文流畅的文字，自然地带领读者理解你的想法。”

Prompt chaining

提示链（Prompt chaining）

和前面的技巧不同，提示链本身无法完全靠“一条提示”解决。它的思路是：把复杂任务拆解成多个顺序步骤，每一步单独用一条提示完成，然后用上一轮的输出作为下一轮的输入。

这种方法以“多轮调用”为代价，换来了更高的准确率和可控性，因为每一步都更简单、更聚焦。通常会在工作流或者程序里实现，但也可以手动一轮轮发提示来实现。

示例：研究总结

1. 第一条提示：

"Summarize this medical paper covering methodology, findings, and clinical implications." “总结这篇医学论文，覆盖其研究方法、主要发现和临床意义。”

2. 第二条提示：

"Review the summary above for accuracy, clarity, and completeness. Provide graded feedback." “检查上面的总结，从准确性、清晰度和完整性三个维度进行审阅，并给出分级反馈。”

3. 第三条提示：

"Improve the summary based on this feedback: [feedback from step 2]" “根据以下反馈改写总结：[第二步的反馈内容]”

每一步都是一次“针对性很强的小任务”，比一次性让模型完成所有工作更稳。

适合使用提示链的情况：

• 你的需求本身很复杂，需要拆解
• 你希望能做多轮“迭代优化”
• 你在做多阶段分析
• 每一阶段的中间结果本身很有价值
• 一条提示的结果总是不稳定

权衡点：提示链会增加延迟（多次调用），但在复杂任务中通常能显著提高准确性和可靠性。

Techniques you might have heard about

你可能听说过的其他技巧

有些在早期模型时代很流行的提示方法，在现代模型中没那么必要了。但你仍然会在旧文档中见到它们，或者在少数场景下觉得好用。

XML tags for structure

用 XML 标签做结构标记

XML 标签曾经是为提示增加结构和清晰度的推荐方法，尤其是在你需要在一条提示里塞很多不同类型的信息时。虽然现代模型即使不用 XML 也能理解结构，但在某些情况里标签仍然有用。

示例：

<athlete_information>
  - Height: 6'2"
  - Weight: 180 lbs
  - Goal: Build muscle
  - Dietary restrictions: Vegetarian
</athlete_information>

Generate a meal plan based on the athlete information above.
“Generate a meal plan based on the athlete information above.”
“根据上述运动员信息生成一份饮食计划。”

什么时候 XML 仍然有帮助：

• 提示极其复杂、混合了多种内容类型
• 你必须非常确定不同内容边界
• 你在使用旧版本模型

现代替代方案：多数情况下，清晰的小标题、空行，以及类似“根据下面的运动员信息……”这种显式语言，已经足够用，而且更简单。

Role prompting

角色提示（设定人设）

角色提示是通过给模型设定一个“身份”或“专家角色”来提问。虽然在很多场景依然有效，但现代模型本身已经具备很强的通用能力，所以不必过度依赖“重人设”。

示例： "You are a financial advisor. Analyze this investment portfolio..." “你现在是一名理财顾问。请分析这份投资组合……”

重要提醒：不要把人设约束得太死。 "You are a helpful assistant." “你是一个乐于助人的助手。” 往往比 "You are a world-renowned expert who only speaks in technical jargon and never makes mistakes." “你是一位只说专业术语、从不犯错的世界级专家。” 更好用。过度严格的人设反而会限制模型的灵活性。

适合使用角色提示的场景：

• 你需要在大量输出中维持统一语气
• 你在构建一个需要特定“人格”的应用
• 你希望在复杂话题中强调某种专业视角

现代替代方案：很多时候，直接说你要的“视角”更有效，例如： "Analyze this investment portfolio, focusing on risk tolerance and long-term growth potential." “请分析这份投资组合，重点关注风险承受能力和长期增长潜力。” 比单纯设定角色更直接。

Try in Claude “Try in Claude” “可以在 Claude 中直接试一试这些写法。”

Putting it all together

把这些技巧组合起来

前面我们是把每个技巧单���讲解的，但它们真正的威力体现在组合使用的时候。提示词工程的艺术，不在于“把所有技巧都用上”，而在于为你的具体场景挑对组合。

一个综合示例：

xtract key financial metrics from this quarterly report and present them in JSON format.

I need this data for automated processing, so it's critical that your response contains ONLY valid JSON with no preamble or explanation.

Use this structure:
{
  "revenue": "value with units",
  "profit_margin": "percentage",
  "growth_rate": "percentage"
}

If any metric is not clearly stated in the report, use null rather than guessing.

Begin your response with an opening brace: {

“Extract key financial metrics from this quarterly report and present them in JSON format.”
“从这份季度报告中提取关键财务指标，并用 JSON 格式输出。”

“I need this data for automated processing, so it's critical that your response contains ONLY valid JSON with no preamble or explanation.”
“我需要将这些数据用于自动化处理，因此你的回复必须只包含合法的 JSON，不要任何额外说明或前言。”

“Use this structure:”
“请使用如下结构：”

“If any metric is not clearly stated in the report, use null rather than guessing.”
“如果报告中没有明确写出某个指标，请使用 null，而不是进行猜测。”

“Begin your response with an opening brace: {”
“请用左大括号 { 作为你回复内容的开头。”

这个提示结合了：

• 明确指令（要提取哪些指标）
• 使用场景（自动化处理，对格式非常严格）
• 结构示例（给出 JSON 模板）
• 允许不确定（不清楚时用 null）
• 格式控制（要求用 { 开头）

Choosing the right techniques

如何选择合适的技巧

不是每条提示都要用上所有技巧。你可以用一个简单的决策流程来选择：

从这里开始：

1. 你的请求是否已经足够清晰、明确？如果没有，先改写。
2. 这个任务是否简单？如果是，只用基础技巧（清晰、具体、补充上下文）就够了。
3. 任务是否需要特定格式？如果需要，用示例或预填。
4. 任务是否复杂？如果是，考虑用提示链拆解。
5. 是否需要推理过程？如果需要，可以用扩展思维或链式思维提示。

技巧选择速查表：

如果你需要…… 可以使用…… 特定输出格式 示例、预填、或明确的格式指令 按步骤的推理 扩展思维（Claude 4.x）或链式思维 处理复杂多阶段任务 提示链（prompt chaining） 透明、可审查的推理过程 带结构标签的链式思维输出 减少“胡编乱造” 在提示中明确允许说 “I don't know / 信息不足” 这类表达

Troubleshooting common prompt issues

常见提示问题及排查

即便是出于好意的提示，有时也会产生奇怪的结果。下面是一些常见问题及应对方法：

• 问题：回复太泛，像套话

解决：提高具体程度，增加示例，明确要求“超出基础水平的输出”，例如： "Go beyond the basics and include advanced insights where relevant." “请不要只停留在基础内容，如果有可能请加入更深入的见解。”

• 问题：回复偏题或抓不住重点

解决：更具体地说明你的真实目标，多讲一点“你要拿这东西干什么”。

• 问题：输出格式不稳定

解决：增加示例（few-shot），或用预填控制回复开头。

• 问题：任务太复杂，结果不稳定

解决：用提示链拆成若干步骤，让每条提示只处理一件小事。

• 问题：AI 总爱加多余开场白

解决：在提示中写明： "Skip any preamble and go straight to the answer." “请跳过任何开场白或客套话，直接给出回答。”

• 问题：AI 捏造信息

解决：在提示中写明： "If you are uncertain or if the information is not available, say so rather than guessing." “如果你不确定或者信息不存在，请直接说明，而不是进行猜测。”

• 问题：你想让它“直接改代码”，它却只给“修改建议”

解决：把 "Can you suggest changes to this function?" “你能给这个函数提些修改建议吗？” 改成： "Change this function to improve performance and show me the updated version." “请直接修改这个函数以优化性能，并给出修改后的完整代码。”

小提示：先从简单提示开始，只在确实有必要时再加复杂度。每多加一个技巧，都要看它是否真的改善了结果。

Common mistakes to avoid

常见误区

避开这些误区，可以帮你省下很多时间：

• 不要过度工程化：更长、更复杂的提示不等于更好。
• 不要忽视基础：如果提示本身又长又糊涂，再高级的技巧也救不了。
• 不要指望 AI“读心”：要具体写出你想要什么。模糊空间越大，误解概率越高。
• 不要一次把所有技巧都堆上：只挑与你现实问题最相关的那几个。
• 不要忘记迭代：第一版提示很少就完美。要敢于修改几次。
• 不要只用过时方法：例如大量 XML 标签、极端角色人设提示，在现代模型里不再是默认必要手段。先从“清晰明确的自然语言指令”开始。

Prompt engineering considerations

使用提示词工程时的一些注意事项

Working with long content

面对长上下文内容

应用高级提示词工程的一个现实问题是：它会增加上下文开销。示例、链式提示、详细说明，这些都会消耗 token，而“上下文管理”本身也是一门技术活。

记住，提示技巧的使用要物有所值。若想系统学习如何管理上下文，可以参考我们的上下文工程指南。

上下文感知能力的进步：包括 Claude 4.x 在内的现代模型已经大幅改善了“lost-in-the-middle（中间内容被忽略）”的问题，对长上下文的整体关注能力更强。

为什么拆分任务仍然有用：即便如此，把大任务拆成更小、更聚焦的子任务依然非常有价值。原因不在于“模型记不住”，而在于拆分可以让模型在一个清晰的边界内、针对一个明确的小目标做到最好。聚焦任务通常比大杂烩式任务输出质量更高。

策略：处理长上下文时，用清晰结构组织信息，把最关键的内容放在开头或结尾。处理复杂任务时，思考一下：如果把它拆成几个子任务，是否能提升质量和可靠性？

What does a good prompt look like?

什么样的提示算“好提示”？

提示词工程是一项技能，不太可能“第一次就完美”。唯一的办法是：先去试，再评估，再改进。你很快就能看到，有和没有这些技巧，输出会有多大差别。

要真正练好这项技能，你还需要客观评估提示效果。好消息是，我们在 anthropic.skilljar.com 上的提示词工程课程，正好详细讲了这一点。

快速评估小 checklist：

• 输出是否真的满足了你一开始写下的“具体要求”？
• 你是一条提示就搞定，还是需要多轮修修补补？
• 多次尝试时，格式是否稳定？
• 你是否成功避开了前文列出的那些常见错误？

Final words of advice

最后的一点建议

提示词工程本质上是一门“沟通艺术”，是学习用一种 AI 最容易理解的方式来表达你的意图。从本指南前半部分的基础技巧开始，把它们变成你的“默认写法”，然后只在确实遇到问题时再叠加高级技巧。

记住：最好的提示不是最长的，而是用最少的结构，稳定实现你目标的那一个。随着练习，你会慢慢形成直觉，知道什么时候该用哪种技巧。

从“提示词工程”走向“上下文工程”，并不会削弱提示词的重要性。恰恰相反，提示词是上下文工程的基本构件。每一个写得好的提示，都会成为塑造模型行为的上下文的一部分，与对话历史、附件、系统指令一起，共同决定结果。

"Start prompting in Claude today." “从今天开始，在 Claude 里多试试这些提示写法吧。”

Additional resources

更多资源

• Prompt engineering documentation

“Prompt engineering documentation” “提示词工程文档”

• Interactive prompt engineering tutorial

“Interactive prompt engineering tutorial” “交互式提示词工程教程”

• Prompt engineering course

“Prompt engineering course” “提示词工程课程”

• Context engineering guide

“Context engineering guide” “上下文工程指南”