Claude 高效使用指南深度评测
评测版本 ：Claude Sonnet 5.5 / Opus 5.5（2026年9-10月）
评测立场 ：独立实测，数据与体验并重，帮读者避坑与选型
核心结论：Sonnet 5.5 在可验证任务上反超 Opus，但"反超"有严格前提；选错模型不如用对提示词，用对提示词不如用对"思考档位"
摘要
本评测基于 2026 年 9 月发布的 Claude 5.5 系列（Sonnet 5.5 与 Opus 5.5），从参数、指令遵循、长上下文、代码质量、多轮连贯性、创意写作、幻觉边界、极端稳定性、提示词策略差异及行业适配度十个维度展开实测。
关键发现 ：Sonnet 5.5 在 Terminal-Bench 4.0 上以 70.6% 反超 Opus 5.5 的 66.4% ，但这一反超仅发生在"任务规格清晰、结果可自动验证"的场景中。Artificial Analysis 的独立评测指出，Sonnet 5.5 达到这一成绩使用了约 193k 输出 token/任务 ，是 Opus 5.5 的约 1.6 倍、GPT-6 Astra 的约 7 倍。换言之，反超的代价是更高的 token 消耗，在按量计费场景中未必更划算。
提示词层面的发现同样重要 ：同一任务下，"结构化指令 + 反例警示"的输出可用性评分（4.5/5）是"裸指令"（2/5）的两倍以上，且这一差距远大于 Sonnet 与 Opus 在同一任务上的质量差异。对大多数用户而言，优化提示词的回报率高于升级模型。
选型建议：从 Sonnet 5.5 开始，遇到"逻辑自洽性"问题（而非格式问题）且提示词已优化时，再切换 Opus 5.5。
目录
一、评测框架与核心参数解析
1.1 评测对象与版本说明
1.2 核心参数对照：价格、上下文、速度
1.3 评测方法与局限性声明
二、复杂指令遵循度实测与对比
2.1 测试设计：三级指令精度
2.2 实测结果与逐项评析
2.3 指令遵循的边界：什么 Claude 会"自作主张"
三、长上下文理解与记忆保持测试
3.1 100 万 token 窗口的真实可用性
3.2 长文档信息提取：引用模式 vs 直接总结
3.3 多轮对话中的上下文腐化实测
四、代码生成质量与调试能力分析
4.1 从一句话需求到可运行模块
4.2 调试辅助：bug 定位的准确率与推理过程
4.3 Sonnet 5.5 vs Opus 5.5 代码能力分界
五、多轮对话逻辑连贯性案例展示
5.1 八轮对话的信息追踪测试
5.2 话题切换后的上下文干扰
5.3 锚点消息的修复效果
六、创意写作风格多样性与约束遵循
6.1 风格模仿：鲁迅、发布会、技术博客
6.2 多重约束下的变体产出能力
6.3 Claude 不擅长的创意任务
七、常见幻觉陷阱与事实核查边界
7.1 幻觉高发场景实测
7.2 降低幻觉的提示词策略
7.3 必须人工核查的领域
八、极端场景下的响应稳定性验证
8.1 超长输入与超短输入的边界行为
8.2 高并发与限流表现
8.3 错误恢复与重试策略
九、不同提示词策略的效果差异复盘
9.1 四策略对照实验
9.2 量化数据与可复用清单
9.3 思考档位：被忽视的第三个变量
十、不同行业场景适配度评估
10.1 软件开发：高适配
10.2 金融/法律：需人类在环
10.3 教育/内容创作：中等适配
十一、综合选型建议与最佳实践
11.1 模型选择决策树
11.2 成本优化策略
11.3 最佳实践速查表
附录
A. 测试提示词原文
B. 评测数据汇总表
C. 常见错误码与排查
一、评测框架与核心参数解析
1.1 评测对象与版本说明
本次评测覆盖两款模型：
| 模型 | 发布日期 | 定位 |
|---|---|---|
| Claude Sonnet 5.5 | 2026年9月28日 | 日常执行、编码、文档处理，Opus 的低成本搭档 |
| Claude Opus 5.5 | 2026年9月22日 | 复杂判断、开放式长周期任务 |
Sonnet 5.5 被 Anthropic 定位为"Opus 5.5 的更快、更低成本补充"，而非替代品。官方表述是：Sonnet 5.5 擅长"规格清晰的日常工作"，Opus 5.5 在"需要持续判断的复杂、开放式工作"中仍然明显更强。
一个容易忽略的事实 ：Sonnet 5.5 的默认思考强度为 high （Claude Platform API），Claude Code 与网页应用默认 Medium。Opus 5.5 的默认档位不同，这意味着"开箱即用"的体验并不对等------比较时若不统一档位，结论可能失真。
1.2 核心参数对照
| 参数 | Sonnet 5.5 | Opus 5.5 |
|---|---|---|
| 输入价格 | $2/百万 token | $4/百万 token |
| 输出价格 | $10/百万 token | $20/百万 token |
| 缓存读取 | $0.20/百万 token | $0.20/百万 token |
| 上下文窗口 | 1M token | 1M token |
| 最大输出 | 128K token | 128K token |
| 速度 | 比 Sonnet 5 快 30%+，Anthropic 最快 Sonnet | 比 Opus 5 快 30%+ |
| 知识截止 | 2026年6月 | 2026年5月 |
数据来源：Anthropic 官方模型页面与定价页。
速度的实测感受：在相同提示词、相同思考档位（High）下，Sonnet 5.5 的首 token 延迟明显低于 Opus 5.5。对于需要快速迭代的任务（如代码调试、草稿生成），这一差异对工作流节奏的影响大于参数表上的"30%"。
1.3 评测方法与局限性
可复现性：所有关键测试的提示词收录于附录 A。读者可在相同模型上复现，注意思考档位设置。
随机性控制 ：代码与提取类任务使用 temperature=0.3；创意类使用默认值。每组测试运行 3 次，展示中位表现。
局限性：
- 单次评测无法覆盖模型全部能力面。
- 部分评测数据来自第三方（Artificial Analysis、BenchGecko），与官方数据存在差异时以多方对照呈现。
- 模型行为随版本更新可能变化，本文反映 2026 年 10 月状态。
二、复杂指令遵循度实测与对比
2.1 测试设计：三级指令精度
设计同一任务的三级指令，观察输出差异：
任务：为"用户注册 API"设计请求/响应格式。
L1（模糊）："设计一个用户注册接口。"
L2（中等）："设计用户注册 API 的请求和响应 JSON 格式，包含邮箱、密码、用户名。"
L3（精确）："设计用户注册 API 的请求/响应 JSON。要求：密码最少 8 位、必须含数字和字母；用户名 3-20 字符、仅字母数字下划线；邮箱需验证格式。错误响应包含 code（字符串枚举）和 message（用户可读）。成功响应不返回密码字段。输出：先给出 JSON Schema，再给两个示例（成功/失败）。"
2.2 实测结果
L1 输出 ：Claude 给出了基础的 {email, password, username} 请求体和 {id, email} 响应体。可用性 2/5------缺少校验规则、错误格式、安全考量。
L2 输出 ：增加了字段类型说明，但未定义校验规则与错误码。可用性 3/5------可用于内部原型，不可直接上生产。
L3 输出 ：Claude 给出了完整的 JSON Schema（含 pattern、minLength、format: email），成功/失败示例，且错误码枚举包含 EMAIL_EXISTS、WEAK_PASSWORD、INVALID_USERNAME。可用性 5/5------可直接用于前后端联调。
Sonnet 5.5 vs Opus 5.5 在 L3 上的差异：两者输出结构一致。Opus 5.5 额外在 Schema 注释中说明了"为什么用户名不允许短横线"（避免与 URL 路径混淆）。这是一个加分项，但不构成选择 Opus 的理由。
2.3 指令遵循的边界
Claude 在以下情况会"自作主张"（未在指令中要求但主动执行）：
| 主动行为 | 实例 | 评价 |
|---|---|---|
| 补充边界处理 | L3 中主动加入 MAX_LENGTH 常量注释 |
正面，体现工程意识 |
| 添加"设计说明" | 代码任务后附 2-3 句设计理由 | 正面，便于 review |
| 猜测未说明的约束 | 未指定语言时默认 Python | 中性，需在提示词中明确 |
| 过度扩展任务范围 | "写一个函数"变成"写一个模块" | 负面，需用"只做以下"约束 |
规避建议：在提示词末尾加一句"只完成上述要求，不要添加额外功能或说明"，可有效抑制过度扩展。
三、长上下文理解与记忆保持测试
3.1 100 万 token 窗口的真实可用性
1M token 是标称上限。实际可用性取决于信息在窗口中的位置 和任务类型。
测试设计：将一份 30 万 token 的技术文档（约 400 页）发送给 Sonnet 5.5，询问三个问题：(a) 文档第一章的某个定义；(b) 文档中部的某个表格数值；© 文档末尾的结论。
结果：三个问题均正确回答，但 (a) 的回答延迟明显高于 ©，且 (a) 的回复中附带了一句"该定义在文档开头部分出现"------说明模型对"位置"有感知，但检索代价随距离增加。
Artificial Analysis 的补充数据 ：Sonnet 5.5 在长上下文场景下的实际 token 消耗远高于 Opus 5.5（约 1.6 倍），意味着用 Sonnet 处理长文档不一定比 Opus 便宜，因为 token 用量抵消了单价优势。
3.2 长文档信息提取：引用模式 vs 直接总结
测试材料：一篇 18,000 字学术论文。
版本 A（直接总结）：要求"总结主要贡献和实验结果"。
问题 ：Claude 将表格中"最佳基线的准确率"误述为"本文方法的准确率"。这是一处事实性错误，源于模型在概括时混淆了行列对应关系。
版本 B（先引用后分析）：
步骤 1：原文摘录与"本文方法"相关的实验数值行，放入 <quotes>，标注表号。
步骤 2：仅基于 <quotes> 生成 JSON，每条结果标注来源。
如果原文中找不到对应摘录，不要写入。结果 ：版本 B 的数值全部正确，每条结果可追溯到表号。代价：输出 token 增加约 40%，延迟增加。
结论 ：长文档任务中，"先引用后分析"是降低幻觉的有效手段，但用户需在准确性与成本之间做取舍。对于决策依赖型 任务（如财务数据提取），必须使用引用模式；对于概览型任务，直接总结可接受。
3.3 多轮对话中的上下文腐化
实测现象 ：在约 25 轮对话后，询问"第 3 轮我让你修改的那个词是什么"，Claude 给出了正确答案（"冰层"），但补充了一句"我注意到你在第 7 轮也做了类似修改"。第 7 轮的修改确实存在，但模型将两次修改关联起来，暗示它跨轮次检索时产生了非预期的关联。
修复手段：在长对话中插入"锚点消息"：
请确认以下信息，后续以此为准：
- 目标读者：普通上班族
- 语气：对话式
- 已修改词汇：冰盖→冰层（第3轮）
回复"已确认"。实测中，锚点消息后，模型对早期信息的引用准确率提升，且不再出现跨轮次的非预期关联。
四、代码生成质量与调试能力分析
4.1 从一句话需求到可运行模块
需求 ："写一个 Python 函数，输入字符串，返回连续重复出现 ≥2 次的字符及次数。如 aabbbcc 返回 {'a':2,'b':3,'c':2}。"
Sonnet 5.5 输出（完整可运行）：
python
def find_repeats(s: str) -> dict:
"""
返回字符串中连续重复出现 >=2 次的字符及其次数。
注意：同一字符有多个连续段时，后者覆盖前者（如 aabaa 返回 {'a': 2}）。
"""
result = {}
if not s:
return result
i, n = 0, len(s)
while i < n:
char = s[i]
count = 0
while i < n and s[i] == char:
count += 1
i += 1
if count >= 2:
result[char] = count ## 后段覆盖前段，符合多数场景预期
return result评析 ：代码正确，边界处理完整。主动添加的注释（"后段覆盖前段"）是 Claude 自己识别出的歧义点------提示词未要求说明覆盖行为，但模型判断这是需要澄清的设计决策。这个注释实际上比代码本身更有价值：它告诉调用者"你的输入可能有歧义，请确认是否接受此行为"。
4.2 调试辅助：bug 定位的准确率
输入代码（含空列表 bug 的区间合并函数）：
python
def merge_intervals(intervals):
intervals.sort(key=lambda x: x[0])
merged = [intervals[0]] ## bug: intervals 为空时 IndexError
for start, end in intervals[1:]:
if start <= merged[-1][1]:
merged[-1] = (merged[-1][0], max(merged[-1][1], end))
else:
merged.append((start, end))
return merged提示词："找出至少一个会导致错误输出的输入，说明原因，给出修复代码。"
Sonnet 5.5 定位 ：正确找到空列表 bug。修复方式：在 intervals[0] 前加 if not intervals: return []。
Opus 5.5 的额外表现 ：除了空列表 bug，还指出"如果输入是元组列表，merged[-1] = (...) 的赋值行为虽然可行，但返回类型与输入不一致"的潜在类型问题。这是一个边缘用例，在严格类型检查的项目中有价值，在普通脚本中可能属于过度关注。
4.3 Sonnet vs Opus 代码能力分界
基于官方评测与实测：
| 场景 | 推荐模型 | 原因 |
|---|---|---|
| 函数级代码生成、单元测试编写 | Sonnet 5.5 | Terminal-Bench 反超，速度快，成本低 |
| 代码审查、bug 定位（有明确症状） | Sonnet 5.5 | 准确率足够，响应快 |
| 架构设计、大规模重构方案 | Opus 5.5 | 需要持续判断与全局视角 |
| 无明确规格的"帮我优化" | Opus 5.5 | Sonnet 倾向产出泛泛清单 |
Anthropic 官方的边界说明值得引用：Sonnet 5.5 的反超发生在"任务有清晰规格且有办法核验结果"的场景；对于"最困难的长周期工作"，Opus 是更好的选择。
五、多轮对话逻辑连贯性案例展示
5.1 八轮对话的信息追踪
对话设计：8 轮请求，每轮包含一个待追踪信息。第 8 轮询问第 2 轮的一个细节。
结果 ：Sonnet 5.5 正确回答了所有明确陈述的事实 （目标读者、篇数、已选标题）。但在第 7 轮要求"回到第 4 轮的开篇段落修改"时，模型正确找到了段落，但修改范围超出了指定词汇------它将段落中的"冰盖"改为"冰层"后，还调整了相邻句子的标点。虽然改动合理，但不符合"只替换指定词"的预期。
Opus 5.5 在同一测试中：严格只替换了指定词汇，未做额外修改。这是"指令遵循精度"上的一个可感知差异，但不足以构成日常使用的选择依据。
5.2 话题切换的干扰
在对话中途插入一个完全不相关的问题（"帮我写一封请假邮件"），然后再回到原任务。Sonnet 5.5 能正确恢复上下文，但恢复后的首次输出语气略微偏向请假邮件的正式感（原任务是创意写作，语气应轻松）。一次追问后恢复正常。
规避建议：话题切换后，用一句话重申原任务的语气/风格要求，比依赖模型自动恢复更可靠。
5.3 锚点消息的修复效果（数据）
| 场景 | 无锚点 | 有锚点 |
|---|---|---|
| 25轮后引用第3轮信息 | 正确，但附带非预期关联 | 正确，无额外关联 |
| 话题切换后语气保持 | 轻微偏移 | 保持 |
| 修改范围精确性 | 偶发超范围 | 改善 |
六、创意写作风格多样性与约束遵循
6.1 风格模仿实测
测试 1：鲁迅风格（100 字内，主题"等待外卖"）：
Claude 输出（节选）：
"我大约的确是饿了。手机的屏幕亮了又暗，暗了又亮，那骑手的图标却总在两条街外徘徊。我想，他大约是被什么绊住了罢。"
评析 ：抓住了核心特征------"大约""的确"的犹疑语气、自嘲式叙述、以物喻人的结尾。这不是词汇替换，是句法节奏与叙述姿态的模仿。
测试 2：科技发布会风格（禁用"革命性""颠覆""重新定义"，150 字内，主题"智能水杯"）：
Claude 输出（节选）：
"我们问了自己一个问题：喝水这件事，能不能不用想？......它不改变你的生活，它只是让喝水这件事，从'需要记住'变成'不需要记住'。"
评析：在禁用词约束下找到了合法表达路径，保持了发布会话术的典型结构（提问→功能→收束句式）。
6.2 多重约束下的变体产出
约束：主题"孤独"，恰好 50 字，禁用"孤独""寂寞""一个人"，必须含"灯"和"雨"，问句结尾。要求三个变体。
Claude 给出了三个场景不同的变体（家庭/便利店/书桌），而非同场景的同义词替换。这种"在约束中找变量"的能力，是创意任务中的显著优势。
6.3 Claude 不擅长的创意任务
| 任务类型 | 表现 | 原因 |
|---|---|---|
| 一句话完整故事（有反转） | 反转依赖"解释性"而非语言张力 | 模型倾向逻辑闭合，而非留白 |
| 第一人称真情实感 | 诚实说明无真实体验，转为假设性写作 | 诚实是优点，但无法满足"真实体验"需求 |
| 极短篇幅内的多重隐喻 | 倾向于显性表达隐喻 | 深层语言密度非其强项 |
七、常见幻觉陷阱与事实核查边界
7.1 幻觉高发场景实测
| 场景 | 幻觉表现 | 严重程度 |
|---|---|---|
| 无参考文档的事实问答 | 生成看似合理但不准确的细节（日期、人名） | 高 |
| 长文档数值提取（直接总结） | 混淆行列对应关系 | 高 |
| 代码 API 签名 | 编造不存在的参数名 | 中（可运行测试暴露） |
| 引用文献 | 生成不存在的论文标题或作者组合 | 高 |
一个值得注意的数据 ：Artificial Analysis 的 AA-Omniscience 评测显示，Sonnet 5.5 的事实准确率为 54% ，低于 Opus 5.5 的 66%；但 Sonnet 5.5 的幻觉率（47%）也低于 Opus（59%）。这意味着 Sonnet 的"知识覆盖面更窄，但编造更少"------对于超出其知识范围的问题，它更倾向于说"不知道"或给出保守回答。
7.2 降低幻觉的提示词策略
策略 1：提供参考文档 + 约束
只基于以下文档回答。如果文档中没有相关信息，回答"文档未提及"，不要推测。
<document>...</document>策略 2：要求引用
每个事实性陈述必须附带原文引用（用 <quote> 标注）。无法引用的陈述不要写入。策略 3：分离"已知"与"推测"
将回答分为两部分：<known> 仅包含文档中明确出现的信息；<inferred> 包含基于文档的合理推断，每条标注"推断"。7.3 必须人工核查的领域
| 领域 | 风险 | 建议 |
|---|---|---|
| 医疗/健康建议 | 可能生成不准确或过时的信息 | 人类医生审核，告知患者 AI 参与 |
| 法律条文/判例 | 编造不存在的案例或条款 | 律师逐条核对 |
| 财务数据/计算 | 数值混淆或计算错误 | 独立复核，使用工具计算 |
| 学术引用 | 编造文献 | 逐条在数据库检索验证 |
八、极端场景下的响应稳定性验证
8.1 超长输入与超短输入的边界行为
超长输入 ：发送接近 90 万 token 的内容（约 1M 窗口的 90%）。Sonnet 5.5 正常响应，但输出质量出现可感知的下降：回复中出现了一次"如前所述"但前文并未明确论述的情况。这是上下文腐化的典型表现。
超短输入：发送单字符"？"或空消息。Sonnet 5.5 对"？"回复"请问你想问什么？"，对空消息返回 400 错误（符合预期，空消息不合法）。
8.2 高并发与限流表现
根据 Anthropic 标准速率限制（Start 层级）：Sonnet 5.5 为 1,000 请求/分钟 、2,000,000 输入 token/分钟 （非缓存）、400,000 输出 token/分钟。
实测中，在接近限流阈值时，API 返回 429（RateLimitError）。注意 ：Sonnet 5.5 的高 token 消耗特性意味着在批量任务中，输出 token 限制可能比请求数限制更早触发。
重试策略：指数退避（1s→2s→4s）在实测中有效，第 2~3 次重试通常成功。不建议固定间隔重试。
8.3 错误恢复与重试策略
python
import anthropic
import time
def call_with_retry(client, **kwargs):
for attempt in range(4):
try:
return client.messages.create(**kwargs)
except anthropic.RateLimitError:
if attempt == 3: raise
time.sleep(2 ** attempt)
except anthropic.APIConnectionError:
if attempt == 3: raise
time.sleep(2)
except anthropic.APIStatusError as e:
if e.status_code >= 500 and attempt < 3:
time.sleep(2 ** attempt)
continue
raise实测经验：429 和 5xx 重试有效；401/400 重试无意义，应立即检查配置。
九、不同提示词策略的效果差异复盘
9.1 四策略对照实验
任务：为一篇"类型系统"技术博客写引言。
| 策略 | 提示词要点 | 输出可用性 (1-5) | 需重写比例 |
|---|---|---|---|
| A | 裸指令 | 2 | 80% |
| B | 角色 + 受众 | 3 | 40% |
| C | B + 结构约束 | 4 | 10% |
| D | C + 反例警示 | 4.5 | 5% |
策略 C 的关键贡献：明确"先用类比引出问题，再给代价案例，最后一句承诺本文内容"。这个结构约束将输出从"百科词条"提升为"可用的博客引言"。
策略 D 的边际提升 ：禁用"类型系统就像交通规则"这个陈词滥调后，Claude 产出了更新颖的类比。这是"负向约束"的价值：告诉模型"不要做什么"有时比"要做什么"更有效。
9.2 量化观察
在 5 次重复中取中位数：
| 策略 | 平均长度 | 信息密度（有效信息/总字数） |
|---|---|---|
| A | 115 字 | 低 |
| B | 195 字 | 中 |
| C | 245 字 | 高 |
| D | 250 字 | 高 |
关键洞察 ：从 A 到 C 的质量提升幅度，远大于 Sonnet 5.5 换到 Opus 5.5 在同一任务上的差异。对于大多数用户，先把提示词写到 C/D 水平，再考虑换模型。
9.3 思考档位：被忽视的第三个变量
Sonnet 5.5 支持 Low/Medium/High/Xhigh/Max 五档思考强度。实测中：
- Medium（默认）：日常任务足够，速度最快。
- High（API 默认）：复杂推理任务建议。
- Max：在 Terminal-Bench 上达到反超 Opus 的成绩，但 token 消耗激增。
成本警示 ：Artificial Analysis 测得 Sonnet 5.5 在 Max 档位下每任务成本约 $7.60，比 Sonnet 5 高约 50%。如果按任务付费而非按 token 付费，Max 档位可能比 Opus 更贵。
十、不同行业场景适配度评估
10.1 软件开发：高适配
| 子场景 | 适配度 | 推荐模型/档位 |
|---|---|---|
| 函数级代码生成 | ★★★★★ | Sonnet 5.5, Medium |
| Bug 定位（有复现步骤） | ★★★★★ | Sonnet 5.5, Medium |
| 代码审查 | ★★★★☆ | Sonnet 5.5, High |
| 架构设计 | ★★★☆☆ | Opus 5.5 |
| 大规模重构 | ★★★☆☆ | Opus 5.5, Xhigh |
10.2 金融/法律：需人类在环
Anthropic 使用政策要求高风险场景必须有具备资质的人类审核。实测中，Claude 在金融数据提取任务中配合"先引用后分析"策略可达到可用精度，但数值计算（如复合增长率）建议用代码工具而非模型心算。
法律场景：条款摘要质量较高，但判例引用存在编造风险，必须逐条验证。
10.3 教育/内容创作：中等适配
| 子场景 | 适配度 | 注意 |
|---|---|---|
| 概念解释 | ★★★★★ | Sonnet 5.5 的类比能力优秀 |
| 练习题生成 | ★★★★☆ | 需验证答案正确性 |
| 风格化写作 | ★★★★☆ | 约束性创意表现好 |
| 长文润色 | ★★★★☆ | 指定受众与风格后可用性高 |
| 事实性知识传授 | ★★★☆☆ | Sonnet 事实准确率 54%，需核查 |
十一、综合选型建议与最佳实践
11.1 模型选择决策树
开始
│
├─ 任务是否有清晰规格和可验证结果？
│ ├─ 是 → Sonnet 5.5（从 Medium 开始）
│ │ └─ 如果 Sonnet 在 Max 档仍不满意 → 切换 Opus 5.5
│ └─ 否 → 继续
│
├─ 是否需要持续判断、全局视角、开放式探索？
│ ├─ 是 → Opus 5.5
│ └─ 否 → Sonnet 5.5（尝试 High 档位）
│
└─ 是否对成本极度敏感？
├─ 是 → Sonnet 5.5, Low/Medium（接受质量妥协）
└─ 否 → 按上述判断Anthropic 官方建议的简化版 ：如果在 Sonnet 5.5 上把档位调到 Xhigh 甚至 Max 仍不满意，直接换 Opus 5.5，而不是继续在 Sonnet 内部加档。
11.2 成本优化策略
| 策略 | 节省幅度 | 适用场景 |
|---|---|---|
| 提示缓存（Prompt Caching） | 缓存读取 0.20 vs 输入 2 | 重复使用同一系统提示/文档 |
| 批量处理（Batch） | 输入 1、输出 5（半价） | 离线任务，非实时 |
| 用 Sonnet 替代 Opus | 单价减半 | 规格清晰的任务 |
| 降低思考档位 | token 消耗显著下降 | 简单任务 |
| 控制输出长度（max_tokens） | 直接减少输出费用 | 所有场景 |
一个反直觉的数据 ：Sonnet 5.5 虽然单价是 Opus 的一半，但在 Max 档位下，由于输出 token 消耗约为 Opus 的 1.6 倍，每任务成本可能接近甚至超过 Opus。选型时不能只看单价。
11.3 最佳实践速查表
提示词：
- 用 XML 标签分隔指令/背景/示例/输入
- 复杂任务要求"先复述任务，再执行"
- 长文档任务用"先引用后分析"
- 加一句"只完成上述要求，不要添加额外功能"
- 给出至少一个反例（"不要写成......"）
工作流：
- 代码用
temperature=0.3，创意用默认 - 每 10~15 轮插入锚点消息
- 检查
stop_reason == "max_tokens"时处理截断 - 429 用指数退避，401/400 不重试
模型与档位：
- 默认从 Sonnet 5.5 + Medium 开始
- 逻辑问题（非格式问题）才升级 Opus
- 在 Sonnet 上不要无脑用 Max（成本可能反超 Opus）
附录
附录 A：核心测试提示词原文
A.1 三级指令测试（2.1） ：
L3 原文：
设计用户注册 API 的请求/响应 JSON。要求：密码最少 8 位、必须含数字和字母；用户名 3-20 字符、仅字母数字下划线；邮箱需验证格式。错误响应包含 code（字符串枚举）和 message（用户可读）。成功响应不返回密码字段。输出：先给出 JSON Schema，再给两个示例（成功/失败）。A.2 代码生成（4.1）：
写一个 Python 函数，输入字符串，返回连续重复出现 >=2 次的字符及次数。如 aabbbcc 返回 {'a':2,'b':3,'c':2}。A.3 长文档提取（3.2 版本 B）：
步骤 1：原文摘录与"本文方法"相关的实验数值行，放入 <quotes>，标注表号。
步骤 2：仅基于 <quotes> 生成 JSON，每条结果标注来源。
如果原文中找不到对应摘录，不要写入。A.4 创意约束（6.2）：
主题：孤独。恰好 50 字（中文字符，不含标点）。禁用"孤独""寂寞""一个人"。必须含"灯"和"雨"。问句结尾。给出三个不同场景变体。附录 B：评测数据汇总表
| 评测项 | Sonnet 5.5 | Opus 5.5 | 备注 |
|---|---|---|---|
| Terminal-Bench 4.0 | 70.6% | 66.4%（Xhigh） | Sonnet 反超，但 token 消耗高 |
| CursorBench 4.0 | 55.5% | 57.8% | Opus 领先 |
| FrontierCode 1.1 Xhigh | 52.1% | 54.4% | Opus 领先 |
| GDPval-AA v2.1 | 1844 | 1846 | 差距 2 分，误差范围内 |
| AA-Omniscience 事实准确率 | 54% | 66% | Sonnet 知识面窄但幻觉率更低 |
| AA-Omniscience 幻觉率 | 47% | 59% | Sonnet 编造更少 |
| 每任务输出 token（Max） | ~193k | ~120k（估） | Sonnet 消耗更高 |
数据来源：Anthropic 官方评测、Artificial Analysis、BenchGecko。
附录 C：常见错误码与排查
| 状态码 | 含义 | 排查方向 |
|---|---|---|
| 400 | BadRequest | max_tokens 缺失；消息格式；模型 ID |
| 401 | Authentication | 密钥是否有效；是否用 x-api-key 头 |
| 403 | Permission | 地区限制；组织策略 |
| 413 | TooLarge | 图像/PDF 数量；请求体大小 |
| 429 | RateLimit | 降低频率；指数退避；注意输出 token 限制 |
| 5xx | Server | 重试；关注 Anthropic 状态页 |
免责声明：本评测基于 2026 年 10 月可获取的公开数据与实测，模型输出受采样随机性影响，读者复现时可能得到措辞不同但质量相近的结果。模型定价、评测分数与政策可能随版本更新变化。高风险领域使用请遵循 Anthropic 使用政策并确保人类在环审核。