📌 国内读者访问提示：由于 Anthropic 官网（anthropic.com）在国内网络环境下无法直接访问，国内开发者若希望第一时间体验 Claude Sonnet 5 的完整能力（包括其五档思考模式：low、medium、high、extra、max），可以通过国内可用的镜像站 AIGCBAR 进行注册使用。该镜像站同步了 Claude 全系列模型的 API 接口，并额外提供了 extra 与 max 两档扩展思考预算，适合需要长链路推理的复杂编码与代理任务场景。

---

第 1 章　引言：为什么提示词工程在 Sonnet 5 时代比以往更重要

2026 年 6 月 30 日，Anthropic 正式发布了 Claude Sonnet 5。官方将其定位为“迄今最具智能体特质的 Sonnet 模型”（the most agentic Sonnet model yet），主打多步骤计划、工具调用与长链路自主执行。在 SWE-bench Pro 上，Sonnet 5 达到了 63.2%，相比 Sonnet 4.6 的 58.1% 提升了 5.1 个百分点；在 Terminal-Bench 2.1 上更是达到了 80.4%，接近 Opus 4.8 的 82.7%。

然而，一个容易被忽略的事实是：模型的性能提升并不会自动转化为用户的使用体验提升。基准测试中的分数反映的是模型在理想提示条件下的上限能力，而实际使用中，提示词的质量直接决定了模型能否发挥其全部潜力。

这引出了一个核心问题：同样是 Claude Sonnet 5，为什么有的人用它写出了生产级代码、完成了复杂的多步骤任务，而有的人却觉得它“跟上一代差不多”？

答案在于提示词工程（Prompt Engineering）的差异。正如有开发者观察到的，从 Sonnet 4.6 迁移到 Sonnet 5 时，提示词工程策略需要微调——以前需要反复强调“请严格按照 JSON 格式输出”的指令，现在可能只需简单说明即可精准执行。这意味着，提示词策略需要随模型能力的进化而进化，而不是一套模板通吃所有版本。

本章作为全文的绪论，旨在说明为什么在 Sonnet 5 时代，提示词工程不仅没有被“简化掉”，反而变得更加精细化、策略化。后续各章将从 Claude Sonnet 5 的核心特性、提示词工程的基础框架、编程场景的实战策略、写作场景的实战策略、effort 参数的精准调优、进阶技巧与常见陷阱等维度，系统论述如何通过优化输入指令让 Sonnet 5 的输出结果更好。

第 2 章　理解 Claude Sonnet 5：智能体优先的模型特性

在讨论“如何输入指令”之前，必须先理解“模型期望什么样的指令”。Claude Sonnet 5 不是一个单纯的“聊天机器人的升级版”，而是一个以智能体（Agent） 为核心设计目标的模型。

2.1　从“回答问题”到“完成任务”的范式转变

Sonnet 5 最根本的特性是：它被训练成“做事情”，而不是“回答问题”。Anthropic 官方描述它“能够制定计划，使用浏览器和终端等工具，并以几个月前还需要更大、更昂贵模型才能达到的水平自主运行”。

这意味着，给 Sonnet 5 的指令不应该只是“请解释一下什么是 X”，而更应该是“请帮我完成 Y 任务，约束条件是 Z”。前者是对话模式，后者是任务模式。Sonnet 5 在设计上更偏向后者。

一个具体的例证来自早期用户的反馈：Sonnet 5 会在没有被明确要求的情况下，主动编写可复现问题的测试用例、实现修复后再回退验证问题是否真实存在。这种“主动核验、不轻易中途停止”的行为模式，正是智能体训练目标区别于传统对话训练目标的典型体现。

2.2　五档 effort 参数：思考强度的可调旋钮

Sonnet 5 引入了可调节的 effort 参数（努力档位），允许开发者在成本与性能之间自由权衡。这是 Sonnet 系列模型中首次获得 xhigh 档位的版本。

表 2-1　Claude Sonnet 5 五档 effort 参数详解

档位	适用场景	Token 消耗	响应速度	推荐用法
low	高并发简单任务、子智能体路由、基础分类	最低	最快	大批量、低成本场景
medium	日常开发、简单代码补全、常规问答	较低	较快	Claude Code 日常开发
high	默认档位、复杂推理、中等难度编码	中等	中等	大多数生产任务的首选
xhigh	困难编码任务、长程智能体运行（>30 分钟）	较高	较慢	最难的编码和智能体任务
max	前沿难题、需要最深推理的任务	最高	最慢	仅在真正需要强推理时使用

Sonnet 5 默认使用 high 档位。这意味着，如果你不主动调整 effort 参数，模型会以一个“中等偏上”的思考强度来响应你的请求。对于简单任务，这可能导致不必要的 token 消耗；对于极难任务，这可能又不够用。理解并善用 effort 参数，是提升 Sonnet 5 使用效果的第一步。

2.3　1M 上下文窗口与 Tokenizer 变更

Sonnet 5 拥有 100 万 token 的上下文窗口，这意味着它可以一次性处理长篇文档、大型代码库或多个文件的完整内容。然而，Sonnet 5 启用了一套更新后的分词器（tokenizer），同一段输入文本在新分词器下可能被切分成 1.0 到 1.35 倍数量的 token，具体取决于内容类型。

这一变化对提示词工程的直接影响是：以前习惯使用的 token 预算估算方法需要重新校准。如果按照旧模型的 token 计数来设计提示词，实际消耗可能会超出预期。因此，在编写长提示词时，建议预留一定的 token 缓冲空间。

2.4　Sonnet 5 与 Sonnet 4.6 的核心差异

理解 Sonnet 5 相比前代的提升维度，有助于针对性地调整提示词策略。

表 2-2　Claude Sonnet 4.6 vs Sonnet 5 关键差异

维度	Sonnet 4.6	Sonnet 5
定位	上一代中端主力	最擅长 Agent 的 Sonnet，性能逼近 Opus 4.8
Agent 能力	支持工具调用	自主规划 + 自我校验，长时运行更稳
SWE-bench Pro	58.1%	63.2%
Terminal-Bench 2.1	67.0%	80.4%
OSWorld-Verified	78.5%	81.2%
幻觉率	基线	明显低于 4.6
effort 参数	不支持	支持五档可调

这些差异意味着：以前需要复杂提示词才能实现的多步骤任务，现在可以用更简洁的指令完成；但同时，新的 effort 参数也带来了新的决策维度。

---

第 3 章　提示词工程基础：让 Sonnet 5 听懂你的“真实意图”

在深入具体场景之前，有必要建立一套通用的提示词工程框架。这套框架不依赖于特定任务类型，而是适用于所有与 Sonnet 5 的交互。

3.1　系统提示词（System Prompt）的黄金位置

系统提示词是向 Claude 提供上下文和指令的方式，例如指定特定目标或角色。有开发者通过对 Claude Fable 5 系统提示词的源码级拆解发现，提示词最开头的黄金位置，专门用来放核心规则——不讲原因、不做铺垫，直接给规则，保证优先级最高。

这一原则同样适用于 Sonnet 5：最重要的指令应该放在系统提示词的最前面。模型在处理长上下文时，对早期内容的权重往往更高。

表 3-1　系统提示词的四层结构

层级	内容类型	示例
第一层（黄金位置）	核心约束与红线规则	“禁止编造不存在的信息”“所有代码必须包含错误处理”
第二层	角色与目标定义	“你是一名资深 Python 后端工程师”
第三层	任务描述与背景	具体的任务说明、相关文档或代码片段
第四层	输出格式与示例	“请以 JSON 格式输出”“参考以下示例的格式”

这种四层结构在实践中被验证可以显著提升代码生成质量。采用系统指令、上下文示例、约束条件和输出格式的结构化提示词，能够减少错误和冗余。

3.2　上下文学习（ICL）：提供示例比“讲道理”更有效

上下文学习（In-Context Learning, ICL）是指通过在提示词中提供示例，让模型理解任务的模式，而不需要微调模型参数。研究表明，提供 3-5 个高质量示例，模型在复杂任务上的准确率可以从 65% 提升至 85%。

对于 Sonnet 5 而言，这一原则同样适用——甚至更加重要。因为 Sonnet 5 被训练成“做事情”而不是“回答问题”，示例能够让模型更准确地理解你期望的行为模式，而不仅仅是回答格式。

一个常见的误区是只提供“正确答案”的示例。更有效的方式是同时提供“错误示例 + 正确示例”，让模型理解边界在哪里。

3.3　“单一职责”原则：一个提示词只做一件事

有开发者分享了一个深刻的教训：他曾经使用长提示词要求 Claude 在一次调用中完成“提取、评估、重写”三个任务，结果三个任务的表现都很平庸。后来他改为每次调用只做一个任务，并在顶部锁定角色，效果大幅提升。

这一经验对 Sonnet 5 同样适用。虽然 Sonnet 5 的多步骤能力比前代更强，但将复杂任务拆解为多个单一职责的子任务，每个子任务使用独立的提示词，往往比试图用一个超级提示词完成所有事情更可靠、更可控。

3.4　显式工具输入：用 JSON Schema 约束行为

对于需要工具调用的场景，开发者应保持工具输入的显式性，尽可能使用 JSON Schema，让模型从允许的工具中选择，而不是让它自己发明操作。

Sonnet 5 在遵循结构化指令方面比前代有了显著提升，但这并不意味着可以省略结构化约束。相反，明确的 JSON Schema 约束能够让 Sonnet 5 的工具调用更加精准、更少出错。

---

第 4 章　编程场景实战：让 Sonnet 5 写出生产级代码

编程是 Sonnet 5 最受关注的应用场景。CursorBench 从 Sonnet 4.6 的 49% 提升到了 57%——这意味着超过一半的复杂多文件编程任务，AI 可以自己搞定，不需要逐条交代。

4.1　代码生成的核心提示词框架

基于前文讨论的四层结构，针对编程场景可以进一步细化：

系统提示词模板（编程场景） ：

你是一名资深 [语言] 工程师，就职于 [公司类型]。
你的代码需要满足以下标准：
- 包含完整的错误处理
- 遵循 [语言] 的最佳实践
- 添加适量的注释解释关键逻辑
- 优先考虑代码可读性和可维护性

任务描述则应包含：功能需求、输入输出规格、边界条件、性能要求、依赖约束。

输出格式可以指定：是否包含测试用例、是否包含使用示例、是否需要解释设计决策。

4.2　遗留代码（Brownfield）场景的特殊技巧

Sonnet 5 在“存量遗留代码”场景下的优势尤为突出——尤其是在竞态条件排查、隐藏测试发现、定位故障真实根因而非仅仅修补症状这类需要持续推理与验证的任务上表现更稳健。

针对遗留代码场景，建议在提示词中明确包含：

1. 问题复现步骤：如何触发该 bug
2. 当前代码的关键片段：不要提供整个代码库，而是聚焦于相关模块
3. 预期行为 vs 实际行为：清晰描述差异
4. 已有的排查尝试：告诉模型你已经试过什么，避免重复劳动

Sonnet 5 的一个独特优势是：它会在没有被明确要求的情况下，主动编写可复现问题的测试用例，并在修复后验证问题是否真实解决。因此，在提示词中可以主动鼓励这种行为：“请在修复后自行验证问题是否解决。”

4.3　多文件修改的场景策略

CursorBench 测试的核心就是“这个文件改了之后，另外三个文件也得跟着改，但你得自己判断改哪”。这种多文件修改任务是衡量智能体编程能力的核心指标。

针对多文件修改场景，建议：

1. 提供完整的项目结构：让 Sonnet 5 理解文件之间的依赖关系
2. 明确修改的范围：指定需要修改的文件列表，或让模型自行判断
3. 要求输出完整的修改方案：包括每个文件的具体改动，而不是只描述“应该改什么”
4. 设置验证标准：明确“修改完成后如何验证正确性”

4.4　编程场景的 effort 档位选择

表 4-1　编程场景 effort 档位推荐

任务类型	推荐 effort	理由
简单代码补全、单函数编写	medium	日常开发够用，成本可控
中等复杂度功能开发	high（默认）	平衡性能与成本
复杂算法实现、多文件重构	xhigh	需要深度推理
系统级设计、架构决策	max	仅在最难任务时使用

有开发者反馈，在 Claude Code 里日常开发用 medium 档位效果就很不错；但在 Codex 等更复杂的环境中，需要用 xhigh 才能达到可用效果。这说明了 effort 档位的选择需要结合具体工具和任务复杂度，而不是一刀切。

---

第 5 章　写作场景实战：从“能写”到“会写”

除了编程，写作是 Sonnet 5 的另一个重要应用场景。Sonnet 5 在 GDPval-AA V2 知识工作基准上取得了 1618 分，甚至略高于 Opus 4.8 的 1615。这意味着它在专业知识工作产出方面的能力已经非常接近旗舰模型。

5.1　写作任务的核心提示词框架

系统提示词模板（写作场景） ：

你是一名 [领域] 专业写作者，曾在 [媒体/机构] 发表过作品。
你的写作风格：[具体描述，如“清晰简洁、逻辑严密、适当使用修辞”]
你的目标读者：[描述读者特征，如“技术背景的中层管理者”]

任务描述应包含：主题、核心论点、篇幅要求、风格要求、需要包含的关键信息。

输出格式可以指定：标题层级、段落结构、是否需要摘要、是否需要引用。

5.2　风格迁移：让 Sonnet 5 模仿你的写作风格

一个常被忽视的技巧是：把你自己的写作样本喂给 Claude。你说“按我的风格写”，然后什么例子都不提供——Claude 无法读心术。把你的旧推文、邮件、文章粘贴进去，Claude 会学习你的节奏、句子流、用词习惯。这是最快的风格校准方式。

对于 Sonnet 5，这一技巧尤其有效，因为它的上下文窗口足以处理多个写作样本，从而更准确地捕捉风格特征。

5.3　长文生成的结构化控制

让 Sonnet 5 生成长篇连贯文本的关键在于结构化控制。一个有效的做法是在提示词首行直接声明：

请严格按以下结构撰写一篇不少于 [字数] 字的 [文体]：
引言（[字数]字）→ 主体分 [N] 部分（每部分约 [字数]字，分别对应 [主题1]、[主题2]、[主题3]）→ 结尾（[字数]字，仅复述结论，不新增观点）

这种结构化控制能够显著提高长文生成的质量和一致性。

5.4　写作场景的 effort 档位选择

表 5-1　写作场景 effort 档位推荐

任务类型	推荐 effort	理由
简单摘要、改写、校对	low-medium	不需要深度推理
常规文章、报告撰写	high（默认）	平衡质量与成本
复杂分析报告、学术写作	xhigh	需要深度推理和逻辑链
创意写作、长篇叙事	max	需要最高质量的输出

---

第 6 章　Effort 参数的精准调优：成本与性能的艺术

effort 参数是 Sonnet 5 最独特的功能之一，也是很多用户最容易忽视或误用的功能。本章专门讨论如何精准调优 effort 参数。

6.1　Effort 参数的技术本质

effort 参数控制的是模型在生成响应时愿意投入的“思考量”。更高的 effort 意味着更多的 token 消耗和更高的准确性，但收益并不是线性的——在某些任务上，从 high 提升到 xhigh 可能带来显著的性能提升；在另一些任务上，提升可能微乎其微。

Sonnet 5 是 Sonnet 系列中第一个获得 xhigh 档位的模型，这意味着在 Sonnet 价格带上首次可以获得接近 Opus 级别的推理深度。

6.2　不同 effort 档位的性能-成本曲线

根据 Anthropic 官方公布的成本-性能曲线，在不同 effort 档位下，Sonnet 5 的表现呈现以下特征：

• 在 low 到 medium 区间：成本极低，适合高并发、大批量任务
• 在 medium 到 high 区间：性能提升明显，是大多数任务的最佳平衡点
• 在 high 到 xhigh 区间：性能继续提升，但边际收益递减
• 在 xhigh 到 max 区间：仅在最困难的任务上值得使用

一个重要的发现是：在 low 到 high 区间，Sonnet 5 相对 Sonnet 4.6 是“无条件改进” ——同等成本下能力更强。但在 xhigh 这一最高投入档位，由于深入探索本身会显著推高 token 消耗，运行成本有可能反超 Opus 4.8 标准档位。

这意味着：不要默认认为“更高的 effort 总是更好” 。对于简单任务，使用高 effort 只会浪费 token；对于极难任务，可能需要考虑是否直接使用 Opus 4.8 更划算。

6.3　基于任务类型的 effort 选择矩阵

表 6-1　基于任务类型的 effort 选择矩阵

任务复杂度	典型任务	推荐 effort	备选方案
极低	简单分类、关键词提取	low	—
低	常规问答、简单摘要	medium	—
中	代码补全、文章撰写	high（默认）	—
高	复杂编码、多文件修改	xhigh	考虑 Opus 4.8
极高	系统设计、前沿研究	max	优先 Opus 4.8

6.4　动态调整策略：一个任务，多次尝试

一个实用的策略是：对于重要任务，先用较低的 effort 快速尝试，如果结果不满意，再逐步提高 effort。这比一开始就用最高 effort 更经济、更可控。

例如，对于一个复杂的编码任务：

1. 先用 medium 快速生成一个初步方案
2. 评估方案质量
3. 如果不满意，用 high 重新生成
4. 如果仍不满意，用 xhigh 或 max 进行深度推理

这种“渐进式”策略能够在保证质量的同时最大限度地控制成本。

---

第 7 章　进阶技巧与常见陷阱

7.1　进阶技巧：提示词链（Prompt Chaining）

提示词链是指将复杂任务分解为多个步骤，每一步的输出作为下一步的输入。这种方法比单次长提示词更可靠，因为每一步都可以独立验证和修正。

对于 Sonnet 5，提示词链尤其有效，因为：

1. 每一步都可以使用不同的 effort 档位（简单步骤用 low，困难步骤用 high）
2. 每一步的输出都可以被人工审核，及早发现问题
3. 总 token 消耗可能低于单次长提示词（因为避免了重复的上下文）

7.2　进阶技巧：Prompt Caching（提示词缓存）

对于高频使用的系统提示词，可以使用 Prompt Caching 来减少冗余 token 的输入。这在 Sonnet 5 的 API 调用中尤其重要，因为 tokenizer 的变更可能导致相同的提示词消耗更多 token。

缓存高频系统提示词的核心策略是“上下文管理”与“渠道优化”。

7.3　常见陷阱 1：过度详细的指令

一个常见的误区是认为“指令越详细越好”。实际上，过度详细的指令可能会限制模型的创造性，甚至导致模型“顾此失彼” 。

对于 Sonnet 5，由于其指令遵循能力已经比前代更强，可以适当简化指令，让模型有更多的自主判断空间。以前需要反复强调的格式要求，现在可能只需简单说明即可。

7.4　常见陷阱 2：忽略 effort 参数的默认值

Sonnet 5 默认使用 high 档位。这意味着如果不主动调整，所有请求都会以中等偏高的思考强度处理。对于简单任务，这会造成不必要的 token 浪费；对于极难任务，这可能又不够用。

务必根据任务复杂度主动调整 effort 参数，而不是依赖默认值。

7.5　常见陷阱 3：上下文窗口的“虚耗”

Sonnet 5 拥有 100 万 token 的上下文窗口，但这并不意味着应该把所有内容都塞进去。无关的上下文会稀释模型对重要信息的注意力，同时增加 token 成本。

只提供任务相关的上下文，而不是“能提供的所有上下文”。对于长文档，可以先让模型做摘要，再基于摘要进行后续工作。

7.6　常见陷阱 4：忽视 Sonnet 5 的“自我校验”能力

Sonnet 5 的一个独特优势是它会在未被明确要求时也会检查自己的输出。然而，很多用户的提示词仍然停留在“请生成代码”的层面，没有利用这一能力。

主动鼓励 Sonnet 5 的自我校验：“请在输出前检查你的方案是否满足所有约束条件”“请验证你的代码是否处理了所有边界情况”。这能够进一步发挥 Sonnet 5 的优势。

---

第 8 章　总结：从“会用”到“用好”的路径

8.1　核心要点回顾

本文从理论到实践，系统论述了如何通过优化输入指令让 Claude Sonnet 5 的输出结果更好。核心要点可以归纳为以下几条：

第一，理解模型的定位转变。Sonnet 5 不是一个“更好的聊天机器人”，而是一个“智能体优先”的任务执行模型。给它的指令应该是“做事情”，而不是“回答问题”。

第二，善用 effort 参数。Sonnet 5 首次在 Sonnet 价格带上提供了 xhigh 档位，这是成本与性能之间的关键调节旋钮。根据任务复杂度选择合适的 effort 档位，是提升使用效果的第一步。

第三，结构化提示词。采用“核心约束→角色定义→任务描述→输出格式”的四层结构，能够显著提升输出的质量和一致性。

第四，提供示例。3-5 个高质量示例可以将复杂任务的准确率从 65% 提升至 85%。

第五，单一职责。一个提示词只做一件事，比试图用一个超级提示词完成所有事情更可靠。

第六，主动利用自我校验。Sonnet 5 具备自主校验的能力，在提示词中主动鼓励这一行为，可以进一步提升输出质量。

8.2　从“能用”到“好用”的进阶路径

对于刚开始使用 Sonnet 5 的用户，建议按照以下路径逐步进阶：

第一阶段（“能用”） ：使用默认的 high effort，采用基本的四层提示词结构，专注于让模型完成简单到中等复杂度的任务。

第二阶段（“会用”） ：根据任务类型主动调整 effort 参数，开始使用示例和提示词链，尝试多步骤任务的自动化。

第三阶段（“好用”） ：精准调优 effort 与提示词的配合，利用 Prompt Caching 优化成本，充分发挥 Sonnet 5 的智能体能力，完成复杂的多文件修改和长链路自主任务。

8.3　Sonnet 5 的定位与选型建议

最后，需要明确 Sonnet 5 在整个模型矩阵中的定位：

• 对于日常的智能体编码、终端自动化、知识工作流程编排：Sonnet 5（配合 medium 到 high effort）是当前性价比最优的选择
• 对于要求最高准确度的关键决策场景：Opus 4.8 仍是更稳妥的选择
• 对于极简单、高并发、延迟敏感的任务：更轻量的 Haiku 档位性价比更高

Sonnet 5 的出现，使得“智能体能力”不再是旗舰模型的专属。但能力的下沉并不意味着使用门槛的自动消失——恰恰相反，如何通过精准的提示词工程和 effort 调优来释放这些能力，反而成了区分“会用”和“用好”的关键分水岭。

声明：本文所有数据均来自 Anthropic 官方发布材料、System Card 以及第三方独立评测机构公开披露的资料，已尽力核实并标注出处。受限于行业评测方法论本身的局限，具体数值在不同测试环境下可能存在合理误差，建议读者在做生产决策前以 Anthropic 官方最新发布与自身实测为准。文中推荐的 AIGCBAR 为第三方镜像服务，使用前请自行评估其合规性与稳定性。

---

参考文献

[1] Anthropic. Introducing Claude Sonnet 5. 2026 年 6 月 30 日. 链接

[2] Anthropic. Claude Sonnet 5 System Card. 2026 年 6 月 30 日. 链接

[3] Anthropic Platform Docs. Effort Parameter. 链接

[4] Claude Sonnet 5 深度评测：Anthropic 新一代 Agentic 编码模型的技术解构与实战剖析[EB/OL]. CSDN, 2026-07-01. 链接

[5] Claude Sonnet 5 上手记录：从 $2/$10 引入价到 1.0-1.35× tokenizer 变更的工程评估[EB/OL]. 博客园, 2026-07-01. 链接

[6] Claude Sonnet 5: Complete Guide to Benchmarks, Pricing, and Features (2026)[EB/OL]. DEV Community, 2026-07-01. 链接

[7] Claude Sonnet 5 发布：新一代低成本 Agent 模型怎么选[EB/OL]. 博客园, 2026-07-01. 链接

[8] 我在 Cursor 里用了一天 Sonnet 5，试了三件事[EB/OL]. CSDN, 2026-07-02. 链接

[9] Claude Sonnet 5 发布：我如何理解更强的 Agent 编程[EB/OL]. 51CTO, 2026-07-01. 链接

[10] Claude Sonnet 5’s effort parameter: the new agent cost control[EB/OL]. Barista Labs, 2026-07-01. 链接