Claude Sonnet 使用教程：5.5 版从 Medium 上手

Claude Sonnet 使用教程：先用 Medium 跑通一个任务

最快的上手方式是在 Claude 应用中操作。选择 Sonnet 5.5，确认 Effort 为 Medium，只提供一组源材料，并要求它生成可以逐行核对的结果。

Anthropic 在自家应用和 Claude Code 中将 Medium 设为默认值，而 Claude Platform 默认使用 High，因此 API 用户应明确指定级别。对于客服摘要、客户简报、常规分析以及要求清楚的工具调用，Medium 很适合作为第一次测试的起点：反馈足够快，也没有直接降到最低档。

我的合成测试工单描述了这样一次故障：登录域名更改后，六名客服人员被锁在系统外，另有两人仍保持登录；页面报错为“Invalid organization”，而用户记录已经写入新域名。Sonnet 5.5 保留了这些细节，也遵循了四点输出格式。但它还推测组织映射很可能仍指向旧域名，并称其中一种修复方式影响更小——这两点都没有出现在工单里。

模型调用本身的成本很好算。按 Anthropic 公布的费率，194 个输入 token 需要 $0.000388，291 个输出 token 需要 $0.00291，合计 $0.003298。如果 10,000 次调用的 token 构成完全相同，模型原始支出就是 $32.98。但这不等于解决 10,000 张工单的总成本；检索、集成、重试、存储、监控和人工审核都在模型调用之外。

Claude Sonnet 5.5 到底是什么

Sonnet 5.5 是 Anthropic 5.5 系列中速度更快的通用模型。可以把它看作处理明确任务的主力模型；遇到开放性强、非常依赖判断的难题，再请 Opus 5.5 这位“资深专家”出场。

这次发布与 Sonnet 5 并不是同一个版本。Claude API 的直接调用 ID 是 claude-sonnet-5-5，没有日期后缀。它接受文本和图片输入、输出文本，拥有 1 million-token 上下文窗口，最多可输出 128,000 个 token。如果需要了解上一代模型的定价和 tokenizer 背景，请单独阅读 Claude Sonnet 5 评测。

Anthropic 表示，Sonnet 5.5 的输出速度比 Sonnet 5 快 30% 以上；在其测试中，每项已完成任务的成本最多可降低 30%。后一个说法指的是完成任务所需的 token 更少，而不是 token 单价下降。它的费率与 Sonnet 5 相同。

基准测试数据同样来自 Anthropic：Terminal-Bench 4.0 中，Sonnet 5.5 为 70.6%，Sonnet 5 为 10.3%；CursorBench 4.0 中，两者分别为 55.5% 和 34.1%。这些成绩足以支持你测试新模型，却无法证明它一定能通过你的工单政策、代码库或文档模板。Anthropic 的发布报告也明确区分了基准分数与开放式任务中持续稳定的判断能力。

按出错代价选择 Effort

Effort 控制的是质量、延迟和 token 消耗，而不是文章长短。提高 Effort 能给模型更多推理和自检空间，也可能意味着更长等待时间和更高费用。如果需要简短回答，应在提示词中另行说明。

Anthropic 针对 Sonnet 5.5 重新校准了这些级别，因此该模型的 Medium 并不代表与 Sonnet 5 的 Medium 相同的思考量。请用自己的样本重新跑一遍各档测试，不要仅因标签相同就照搬原设置。

近期回报最高的七种工作流

最值得尝试的用法通常有三个共同点：输入材料已经就绪、目标输出格式明确，而且有人或规则可以核验结果。

1. 客服工单分流

客服运营负责人可以把客户消息、账户状态、近期工单记录和升级处理政策放在一起。Sonnet 5.5 可整理出问题、影响、证据、缺失信息以及下一项允许执行的操作。它的价值在于减少分流或交接前的重复阅读，但涉及账户变更的建议、退款、承诺和根因判断仍须人工核对。

这是最适合首先落地的工作流，因为每一项输出都能回指明确的源字段，也能迅速暴露模型错误。如果一份摘要无法说明某个结论来自哪里，它就还不能触发后续操作。

2. 会前客户简报

客户负责人可以提供最近一次通话记录、工作说明书、未完成任务和续约备注，再要求模型用一页篇幅整理决策、承诺、风险、待解决问题以及下一次会议议程。这样，每次通话前都有统一的简报格式，不必重新面对空白页面。

把“已确认”和“推断”分成两个板块。这一个简单区分，就能避免模型看似合理的解读被误当成对客户的承诺。

3. Pull request 审查

工程负责人可以把代码 diff、仓库规范，以及安全、测试和向后兼容性检查清单交给模型。Sonnet 5.5 能给出按风险排序的第一轮审查结果并提出测试建议。它帮助审查者更快掌握改动重点，却不能自动批准合并；最终决定仍应由负责该系统的人作出。

4. 边界明确的 bug 修复

产品工程师遇到可复现的 bug 时，可以提供失败表现、相关文件和验收检查。对于规格清楚的修复，Medium 是合理起点；如果问题跨越多个服务，或者第一次运行跳过了核验，再切到 High。验收检查负责约束任务范围，模型则负责缩短实现和测试循环。

5. 经营复盘与董事会材料初稿

财务或运营团队可以提供源材料以及获批的幻灯片或文档模板，让 Sonnet 5.5 起草结构化复盘、指出材料缺口，并排出第一版格式。Anthropic 也明确将精致的文档、幻灯片和电子表格列为它的适用场景。它能减少拼装材料的时间，但每一项财务结论仍须对应具体单元格或文档出处。

6. 事故总结

事故指挥者可以把事件时间线、告警、处置动作和负责人备注交给模型，并要求把已确认事件、假设、客户影响、未决问题和后续任务分块呈现。这样能让交接和事故复盘初稿更清楚，但不能让模型把相关性直接提升为根因。

7. 视觉 QA 与界面打磨

产品设计师或前端工程师可以把截图、品牌规范和验收清单组合起来，让 Sonnet 5.5 找出不一致之处、排列修复优先级，并协助完成一轮范围明确的修改。这样能更快迭代可见缺陷；审美判断、无障碍测试和最终产品决策仍应由人负责。

三个值得做成产品的方向

仅提供模型调用并不是一门生意。真正可销售的产品还需要专有上下文、受控工作流、可核查证据，以及让人做最终决定的环节。

1. 证据可追溯的客服分流：最强机会

可以做一款客服 copilot：把工单和账户记录整理成结构化摘要，为每项结论附上来源链接，根据政策检查拟议操作，再把草稿送交审批。客服负责人和外包服务团队会愿意为更快、更一致的分流付费。

需求信号很明确：在本次关键词数据中，ai customer service agent 在美国每月有 1,300 次搜索，属于商业意图查询，年增长率为 815%。Intercom 对 Fin 的定价是每个 outcome $0.99。它不能与一次摘要调用直接对比，因为解决一个 outcome 是更大的任务，但这至少说明买家已经接受按使用量为客服自动化付费。

最小可售版本需要一个收件箱连接器、一个账户数据连接器、四字段摘要、来源引用、政策检查，以及批准或拒绝控件。真正的难点是集成与信任：如果无法证明一条建议从何而来，客户仍会保留现有工作流。

2. 理解团队政策的代码审查层

可以构建一个 GitHub 应用，读取 diff 和每个团队自己的规则，然后给出按风险排序的审查结果、测试缺口和简短合并摘要，目标买家是工程经理与平台团队。

ai powered code review platform 在美国每月有 1,900 次搜索，年增长率为 19%。CodeRabbit 公布的价格从每位开发者每月 $24 起（按年计费），更高档方案分别为 $48 和 $72。MVP 只需支持一个代码仓库提供商、pull request webhook、自定义检查、评论视图，以及说明每项问题由哪条规则触发的审计记录。

问题在于市场已经非常拥挤，通用审查工具没有可防守的优势。应选择一个真实而尖锐的细分痛点，例如受监管的发布检查、数据迁移安全，或某个特定框架；衡量误报时也要像衡量漏报一样认真。

3. 垂直领域的简报转 PRD 工具，而不是通用生成器

可以设计一个窄工作流，把通话、约束条件和既有决策整理为产品简报，其中包含验收标准与未决问题。当模板真正贴合业务时，产品咨询公司或垂直软件团队可能会购买。

精确关键词 ai product requirements document generator 在美国每月仅有 70 次搜索，而且同比下降 50%。这是警示，不是卖点。独立的通用 PRD 生成器是这里最弱的机会；更可行的做法，是把它嵌入价值更高的工作流，例如代理机构需求调研、医疗实施或企业变更控制。

MVP 包括一套固定源材料、一个主张鲜明的模板、决策溯源能力，以及导出到买家现有系统的功能。它的短板是需求有限、容易复制。除非你已经掌握客户关系或垂直数据渠道，否则不要做。

单价没有变，工作流成本可能下降

Sonnet 5.5 每 million 个输入 token 收费 $2，每 million 个输出 token 收费 $10，每 million 个缓存读取 token 收费 $0.20。这些公开费率与 Sonnet 5 相同。Anthropic 所说的成本下降，来自用更少 token 完成任务。

做成本预测时必须分清这一点。即使价格表不变，更短的模型推理轨迹也可能同时降低延迟与 token 支出；但如果检索、第三方工具、重试和人工审核才是成本大头，产品总成本也可能几乎不变。因此应衡量每份被接受结果的成本，而不是每次调用的成本。

Claude 应用订阅和 API 用量属于两种不同产品。订阅 Pro、Max、Team 或 Enterprise，并不包含 Claude Console 或 API 用量。Claude 套餐指南介绍了不同套餐的一般边界；API 工作流还需要单独开通 Console 访问并按量计费。

任务验证通过后，再迁移 API 工作流

更稳妥的迁移顺序是：先用有代表性的样本验证提示词，再固定新模型 ID、明确设置 Effort，随后修正 thinking 与工具调用约定，最后才导入生产流量。

如果只是发起带 adaptive thinking 的普通请求，请省略 thinking 字段，并按类型读取文本 block：

from anthropic import Anthropic

client = Anthropic()
response = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=4096,
    output_config={"effort": "medium"},
    messages=[{
        "role": "user",
        "content": "Summarize this ticket as Issue, Impact, Evidence, and Next action.",
    }],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

迁移时有四项变化需要专门检查。

1. Anthropic 的 Claude 直接 API 已不再接受 thinking: {"type": "disabled"}。如果不需要预先思考，应改用 thinking: {"type": "between_tools"}。该设置支持 Low、Medium 和 High，但不支持 Xhigh 或 Max。
2. Claude 直接 API 也不再接受强制 tool_choice 的 any 和具名 tool 值。请使用 auto，在支持时把 schema 设为严格模式，并在提示词中说明何时应调用工具。
3. 响应可能以 thinking block 开头。必须按 type 解析每一个内容 block，绝不能假设 content[0].text 一定存在。
4. 在工具调用循环中，thinking block 必须原样传回。它们携带与此前对话绑定的签名，因此消息历史只能追加，不能改写。

下面这段最小示例使用 between_tools，将工具选择保持为 auto，并保留完整的 assistant 回合：

tools = [{
    "name": "lookup_ticket",
    "description": "Look up a support ticket",
    "strict": True,
    "input_schema": {
        "type": "object",
        "properties": {"ticket_id": {"type": "string"}},
        "required": ["ticket_id"],
        "additionalProperties": False,
    },
}]

messages = [{"role": "user", "content": "Use lookup_ticket for T-42."}]
response = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=4096,
    thinking={"type": "between_tools"},
    output_config={"effort": "medium"},
    tools=tools,
    tool_choice={"type": "auto"},
    messages=messages,
)

# Keep every block, including signed thinking blocks, exactly as returned.
messages.append({
    "role": "assistant",
    "content": [block.model_dump() for block in response.content],
})

tool_call = next(block for block in response.content if block.type == "tool_use")
messages.append({
    "role": "user",
    "content": [{
        "type": "tool_result",
        "tool_use_id": tool_call.id,
        "content": "Ticket T-42 is open and assigned to Support Ops.",
    }],
})

follow_up = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=4096,
    thinking={"type": "between_tools"},
    output_config={"effort": "medium"},
    tools=tools,
    tool_choice={"type": "auto"},
    messages=messages,
)

Anthropic 的 Sonnet 5.5 迁移指南记录了直接 API 会返回的 400 错误及替代字段。我的本地 Medium between_tools 请求在 1.35 秒内返回 HTTP 200。另一次采用 adaptive thinking 的工具循环生成了带签名的 thinking block；在下一回合原样重放完整 block 后，请求成功。

这里还有一个重要细节：我的调用经过了 AI gateway。即使我故意发送旧的 disabled thinking 值和强制 tool_choice: any，这个兼容层依然返回 HTTP 200，而 Anthropic 文档指出它们在直接 API 中都会报错。因此，中间件接受请求，并不能证明你的直接集成兼容。切换前，请在 Anthropic Playground 检查原始请求，或直接测试端点。

Sonnet 5.5 解决不了什么

它无法把缺乏依据的推断变成事实，本地客服测试已经说明了这一点。高影响结论必须附带来源，退款、账户变更、法律承诺、医疗决定和安全操作等环节也必须保留审批。

它也不会让所有任务都适合 Medium。当自己的样本暴露出推理遗漏或工作不完整时，应提高 Effort。开放式、需要持续判断的任务可以使用 Opus；Opus 5.5 对比文章说明了这个更高档位适合放在哪里。

它同样不能把一次裸模型调用直接变成产品。连接器、权限、政策检查、评测、可观测性、降级方案和好用的审核界面，才是生产落地的大部分工作。

它也没有消除使用最新资料的必要。如果客服或研究答案取决于当前允许什么、要求什么或如何收费，就应给模型配置搜索或知识工具，并明确要求它查询。

周一就能开始的动作

选择一个拥有明确事实来源的任务队列。周一取出近期 20 个样本，移除不需要的隐私数据，以 Medium 和一套固定输出 schema 运行 Sonnet 5.5。分别评估事实准确性、无依据推断、完整性、耗时和 token 用量。只有这套提示词通过测试后，才应更换现有 API 的模型 ID，并执行上面的迁移检查。

如果希望为自己的业务搭建一套基于可靠来源的 Claude 工作流，请查看 AI 生产系统。