Claude 101 第三课：Getting Better Results——让回答更贴合需求的七个技巧

预计阅读时间：25 分钟 | 难度：⭐⭐

目标读者：已经能和 Claude 正常对话，想让输出质量更稳定的学习者 核心问题：为什么回答总是"差一点"？怎么让它一次比一次更接近你要的？ 前置知识：第二课 你的第一段对话

学习目标

本节覆盖以下内容：

• 理解什么是 Few-shot（少样本示例）提示，以及什么时候该用它
• 知道新版 Claude 已经会自主思考，什么时候还需要显式要求分步骤
• 学会用结构化标签约束输出的格式和内容边界
• 掌握"先出初稿、再迭代修正"的低成本工作流
• 会用自查清单和正向表述，进一步压低回答跑偏的概率

这节课解决什么问题

很多人会用 Claude，但经常遇到这几类挫败感：

• 明明已经说了需求，结果回答还是偏题。
• 内容大体对，但格式、语气和详细程度完全不合用。
• 第一次回答一般，第二次追问又把前面的优点改没了。

这节课给出一套结构化的提问与修正方法，让 Claude 的输出更贴近你的真实目标——不是教你写"更玄学的提示词"。

适用场景

场景一：Claude 总能回答，但总离你想要的还差一点

这是最典型的使用场景。它"不完全错"，但就是不够可用。这通常不是能力问题——你还没有把约束、示例和结构说清楚。

场景二：你在反复做相似任务

比如润色邮件、生成摘要、写 README、整理会议纪要、比较方案。这类任务最适合用本课的方法做成稳定模板，而不是每次临场发挥。

场景三：你需要的是"更稳定"，不是"更惊艳"

本课更适合希望提高一致性和可控性的用户，而不是单纯追求一次性"神回答"。

从"答非所问"到"精准命中"

很多人在使用 AI 时会遇到这种情况：

你想要的是 A，但 AI 给了你 B、C、D，就是没有 A。

第二课讲过，好提示词的最小公式是目标 + 背景 + 结果形式。这一课在这个基础上往前走一步：当"说清楚"还不够时，怎么用示例、结构和迭代把回答钉在你要的位置上。

Anthropic 官方对提示词有一条黄金法则：把你的提示词拿给一位完全不了解这项任务的同事看，请他照着执行——如果他会困惑，Claude 也会。官方还有一个常用的比喻：把 Claude 当成一位聪明但没有你团队上下文的新员工，你说得越具体，它做得越好。

下面介绍七种最有效的技巧。

技巧一：Few-shot Examples（用示例引导）

什么是 Few-shot？

Few-shot 的字面意思是"少数例子"（官方文档里也把这种做法叫 multishot prompting），核心思想一句话：

与其用语言描述你想要的，不如直接给它看例子。

对比一下

没有例子：

帮我把这些客户反馈分类。

模型只能猜你要分几类、按什么标准分，每次给的类别名可能都不一样。

有例子：

帮我把下面的客户反馈分类。类别只能是这三种：功能建议、Bug 报告、账单问题。

<examples>
<example>
输入：搜索框输入中文后候选词会消失
输出：Bug 报告
</example>
<example>
输入：希望手机端也能用深色模式
输出：功能建议
</example>
<example>
输入：这个月被扣了两次费
输出：账单问题
</example>
</examples>

现在分类这条反馈：导出 PDF 时页面卡死

类别名、判定标准、输出格式全部被示例钉死了，换十条反馈来跑，输出结构也会保持一致。

用好示例的三条官方原则

Anthropic 官方文档对"怎么给例子"给了三条标准，可以直接当自查清单用：

1. 相关：例子要贴近你的真实使用场景，不要用明显造作的样本。
2. 多样：覆盖边界情况，别让 Claude 从例子里读出你不想给的规律（比如三个例子全是同一类输入，它可能以为只需要处理那一类）。
3. 结构化：像上面的例子一样，用 <example> 标签包住每个示例，多个示例外面再套一层 <examples>，让 Claude 分得清哪些是例子、哪些是指令。

官方还建议：效果要求越高，例子给得越足，3 到 5 个通常比 1 个好得多。你也可以直接让 Claude 评价你的例子是否够多样，或者基于现有例子帮你补充新的。

使用 Few-shot 的最佳场景

• 需要特定格式输出时
• 需要特定写作风格时
• 任务比较主观（比如"写得更有趣"）
• 反复执行类似任务时

技巧二：Chain of Thought（思维链）

先说一个重要的变化

老一代模型的教程都会教你：遇到复杂问题，先加一句"think step by step"。对现在的 Claude，这句话不再是必备咒语。

新版 Claude 默认运行自适应思考：简单问题直接回答，复杂问题它会自己多想几步，什么时候想、想多少，模型会自己判断。你不需要再手动触发推理。

但显式要求分步骤在两种情况下仍然有用：

1. 你想看到推理过程。模型内部怎么想你看不到，但你可以要求它把步骤写出来——学习场景尤其需要。
2. 问题真的容易跳步。多步数学、逻辑推理、多方案利弊权衡，显式要求分步能减少遗漏。

让步骤显式可见

官方推荐的做法是用标签把推理和答案分开：

请先在 <thinking> 标签里逐步分析，再在 <answer> 标签里给出最终结论。

问题：一个自行车店有 30 辆车，上午卖了一半，下午又卖了剩下的三分之一，最后还剩多少辆？

这样输出会分成两段：推理过程在前，干净的结论在后，方便你检查它是在哪一步开始跑偏的。

什么时候需要显式思维链？

技巧三：指定输出结构

为什么结构很重要？

没有结构约束时，AI 的输出可能是：

• 太长或太短
• 缺少你想看的部分
• 格式不统一

常用结构技巧

技巧 A：明确要求长度和形式

用一段话（不超过 100 字）解释什么是数据库索引，读者是刚学编程的新手。

技巧 B：用 XML 标签分区

提示词里的内容一多（指令、背景资料、要处理的问题混在一起），Claude 就可能分不清哪段是让它做什么、哪段是原材料。官方推荐用 XML 标签给每类内容划清边界：

<context>
[粘贴三个版本的功能对比表]
</context>

<input>
用户问题：哪个版本适合自由职业者？
</input>

请只根据 <context> 里的信息回答 <input> 里的问题。

标签名保持一致、见名知义（<instructions> 放指令、<context> 放背景、<input> 放待处理内容），内容有层级时可以嵌套。

技巧 C：指定输出格式

请用 Markdown 表格输出对比结果，包含三列：功能、免费版、专业版。
表格后面用一段话给出选择建议。

技巧四：控制长度和详细程度

有时候短更好

把下面的段落压缩成一句话，保留核心结论，不要举例。

有时候需要详细

详细解释这段代码为什么会有性能问题。
要求：先指出问题，再逐行解释原因，最后给出修改建议，每一步都说明理由。

控制长度的魔法词

两个经验：

• 数字比形容词可靠。“200 字以内"比"简短一点"执行得准。
• 不同模型的默认话痨程度不一样。如果换了模型后发现回答明显变长或变短，把你的长度偏好直接写进要求里，别指望它自动延续你的习惯。

技巧五：迭代优化

什么是迭代？

迭代就是不指望一次就完美，而是：

1. 先让 Claude 给一个初步版本
2. 指出需要改进的地方
3. 让它修正
4. 重复直到满意

第二课的三轮对话演示就是这个方法。这节课补一个关键细节：每次迭代只提一两个新要求，并明确告诉它哪些部分不要动。

迭代模板

这一版方向对了，但有两个问题：
1. 语气还是太正式，改得像同事之间说话
2. 第二段和第三段内容重复，合并成一段

其他部分保持不变，只改这两处。

“其他部分保持不变"这句话，直接对应开头说的第三种挫败感——追问修新问题时把旧优点改没了。明确圈出修改范围，就是在保护已经满意的部分。

实际例子

用户：帮我写一封拒绝 offer 的邮件，语气礼貌。
Claude：（给出第一版，约 300 字）

用户：不错。但太长了，对方没时间读。压缩到 100 字以内，
保留关键信息：感谢、决定、祝愿。

Claude：（给出更短的版本）

用户：很好。最后把"经过慎重考虑"换成更自然的说法。

三轮下来，邮件从"能用"变成了"想发”。你会发现改一段对话，远比重新想一个完美提示词省力。

技巧六：利用 AI 的自我纠错

让它先检查再输出

把你的验收标准直接写进提示词，让 Claude 交答案前先自查一遍。官方给的模式是：在指令后面追加一句"完成前，先对照 [验收标准] 核验你的答案”。实践证明这一招对代码和数学类任务尤其可靠。

写完之后，先对照下面的检查清单自查，有问题就修正后再给我：
1. 所有数字都与原文一致
2. 没有添加原文没有的信息
3. 语气专业但不生硬

自查清单要用可验证的标准。“写得更好"没法自查，“没有添加原文没有的信息"可以。

要求它解释自己的推理

给出结论之前，先列出你做出这个判断的三条主要依据。
如果依据之间有冲突，请直接指出。

让它把依据摊开，你就多了一个检查点——依据站不住，结论自然不可信。

技巧七：Negative Prompting（负面提示）

告诉它你不想要什么

写一份产品更新公告。

要求：
- 语气平实，像工程师在同事群里发通知
- 突出"这次更新解决了什么问题"
- 每个功能点不超过两句话
- 不要出现"强大""颠覆""极致"这类营销词

一个重要的官方提醒

Anthropic 官方最佳实践的第一条格式建议是：说要什么，而不是不要什么。与其写"不要用 Markdown”，不如写"用连贯的段落陈述”；与其写"不要太啰嗦"，不如写"控制在 150 字以内"。

原因很直觉：正向描述给出的是可执行的目标，负面清单只圈出禁区，Claude 仍要自己猜禁区之外该怎么做。

所以推荐的配比是：正向要求为主体，负面提示做补充——上面那份公告要求里，前三条都在说"要什么"，只有最后一条在堵具体的漏洞。当你发现 Claude 反复出现某个特定坏习惯时，负面提示再出场，效果最好。

负面提示的常见场景

高级技巧组合

单个技巧解决单类问题，真实任务往往要组合。

组合一：完整任务规范

我需要你帮我写一封客户回复邮件。

<context>
客户投诉上个月的账单多收了 200 元。已核实确实多收，
退款已提交，需要 5 个工作日到账。
</context>

<instructions>
1. 先致歉，再给方案，语气诚恳但不过度道歉
2. 明确告知退款金额和到账时间
3. 结尾主动提出：到期未到账可直接联系你
</instructions>

请用 150 字以内的中文写这封邮件。
写完后自查：金额和时间是否与 <context> 完全一致。

这一段里用了四种技巧：<context>/<instructions> 划清结构（技巧三）、正向要求加负面兜底（技巧七）、长度约束（技巧四）、结尾自查（技巧六）。

组合二：角色 + 格式 + 约束

你是一名资深技术编辑，擅长把复杂的工程概念讲给非技术同事听。

请把下面的技术方案改写成一段面向销售团队的说明。

要求：
- 用流畅的段落陈述，不要用列表和术语
- 保留关键结论，删掉实现细节
- 控制在 200 字以内

<input>
[粘贴你的技术方案]
</input>

练习

练习一：Few-shot 实践

让 Claude 用"……是因为……“的句式改写以下句子：

1. “外面下雨了，所以我迟到了。”
2. “他很努力，所以他成功了。”
3. “我不喜欢吃蔬菜。"（改写成因果形式）

先不给示例让它做，再给一个示例让它做，对比结果。

练习二：显式思维链

让 Claude 解决这道逻辑题，并要求它把推理步骤写在 <thinking> 标签里、答案写在 <answer> 标签里：

“一个自行车店有 30 辆车，上午卖了一半，下午又卖了剩下的三分之一。 最后还剩多少辆？”

（答案应该是 10 辆。检查它的推理过程，看有没有跳步。）

练习三：迭代优化

让 Claude 帮你写一封拒绝 offer 的邮件，然后：

1. 第一轮：让它改成更正式的版本
2. 第二轮：让语气更温和但依然坚定
3. 第三轮：把长度压缩到 100 字以内

每一轮都试试加上"其他部分保持不变”，对比效果。

什么时候这些技巧最有效

常见误区

误区一：技巧越多越好

不是。很多简单问题，直接问反而更快。技巧的作用是提升复杂任务的稳定性，而不是把每个问题都变成"提示词工程项目”。

误区二：只要提示词写得足够好，就不需要迭代

现实里，大多数高质量结果都来自"第一版 + 修正 + 再修正"。真正高效的使用方式是学会如何低成本迭代，不是追求一步到位。

误区三：让 Claude 展开推理一定更好

并不总是这样。简单问题上过度要求分步骤思考，往往只会让回答更慢、更啰嗦，甚至让重点被淹没。何况新版 Claude 已经会自己判断什么时候该多想——你要做的是在它该想而没想的时候补一句，而不是处处都补。

行动建议：把技巧变成自己的模板

最有价值的动作是把它们转成你自己的高频模板，不是继续收藏技巧。

例如：

1. 为"总结会议纪要"做一个固定模板。
2. 为"写专业邮件"做一个固定模板。
3. 为"让 Claude 解释代码并给出改进建议"做一个固定模板。

当一个任务你已经连续做过 3 次以上，就值得把它从"临时提问"升级成"稳定模板"。

FAQ

Q1：Few-shot 和直接描述需求，哪个更重要？

答： 如果你的任务对格式、风格或口吻要求很强，Few-shot 往往更有效；如果任务更偏事实解释或简单问答，直接描述需求通常已经够用。

Q2：是不是所有复杂问题都应该加"step by step"？

答： 不是。新版 Claude 默认会自主思考，多数情况不需要你触发。显式要求分步骤留给两类场景：你想看到推理过程，或者问题确实容易跳步。

Q3：我已经会写提示词了，为什么结果还是不稳定？

答： 很多时候问题不在"不会写"，而在于缺少示例、输出结构和迭代机制。把提示词当成一次性交付，通常不如把它当成可逐步调优的工作流。

下一步

掌握了"怎么拿到更好结果"，接下来可以看这些技巧放进更完整的工作流里是什么样：

• Claude 桌面应用：官方系列的第 4 课，Chat、Cowork、Code 三类工作方式
• Projects 和 Artifacts：用项目组织长期上下文，用 Artifacts 管理结构化产出

参考链接

• Claude 101 官方课程（Anthropic Skilljar） —— 课程名 “Getting better results”、课程大纲与课序的出处
• Anthropic 提示工程最佳实践 —— 示例三原则、XML 标签、自查指令与自适应思考口径的出处
• 第二课 你的第一段对话
• 第四课 Claude 桌面应用

文档元信息 难度：⭐⭐ | 类型：技巧实操 | 更新日期：2026-09-22 | 预计阅读时间：25 分钟