Claude Opus 4.7 使用攻略：Claude Code 创始人教你榨干新模型的每一分性能

与虾牵手
7 阅读1分钟

Claude Opus 4.7 使用攻略：Claude Code 创始人教你榨干新模型的每一分性能

Claude Opus 4.7 是 Anthropic 目前正式上线的最强模型，在编程能力、自主任务执行和模糊问题推理上全面超越前代 4.6。 Claude Code 创始人 Boris Cherny 第一时间写了篇官方最佳实践，我在 ofox.ai 上跑了两天真实项目后，把他的建议和我自己踩的坑整理成这篇实操攻略——如果你准备升级，先看完再动手。

Opus 4.7 vs 4.6：到底升级了什么？

先说结论：4.7 不是小版本迭代，是底层能力的代际跳跃。

很多人看到版本号只差 0.1，觉得可能就是微调了一下。不是的。Boris 在文章里明确说了几个本质变化，我自己跑下来也验证了。

维度Opus 4.6Opus 4.7体感差异
模糊任务处理需要详细提示词引导能自主推理找方向给一句话需求就能干活，不用写小作文
Bug 定位能力能找到明显 bug能定位隐蔽的逻辑错误跨文件 debug 准确率明显提升
代码 Review偏表面风格检查能发现架构级问题会主动指出潜在的竞态条件、内存泄漏
跨会话记忆上下文偶尔丢失明显更稳定长项目不用反复交代背景
思考机制Extended Thinking（固定预算）Adaptive Thinking（动态分配）简单问题快，复杂问题深
Tokenizer旧版全新 tokenizer同样的文本，token 计数方式不同
默认 Token 消耗相对可控高 effort 下消耗上升需要重新调 effort 参数

一个直观感受：用 4.6 的时候，我得把需求拆成很细的步骤喂给它；4.7 我直接说"这个支付回调偶尔会重复扣款，帮我查一下"，它自己去翻了 6 个文件，定位到了一个 Redis 分布式锁的过期时间设置问题。这在 4.6 上基本不可能一轮完成。

交互编程四大原则

Boris 在文章里给了几条高效交互的建议。说实话，这些建议不是空话，我按他说的调整了工作流之后，单次会话的完成率确实高了很多。

原则一：第一条消息把任务说清楚

别像聊天一样一句一句挤牙膏。4.7 的理解能力足够强，你一次性把意图、约束、验收标准、相关文件位置都给它，它能规划出更好的执行路径。

# ❌ 低效写法
"帮我改一下登录接口"

# ✅ 高效写法
"重构 src/api/auth/login.ts 的登录接口：
- 当前问题：密码错误时返回 500 而不是 401
- 约束：不改动 src/middleware/auth.ts 的 JWT 签发逻辑
- 验收标准：密码错误返回 401 + 错误消息，账号不存在返回 404
- 相关文件：src/api/auth/login.ts, src/models/user.ts, src/utils/password.ts
- 改完跑一下 tests/auth.test.ts 确认通过"

原则二：减少中间交互，打包提问

每次你发一条消息，模型都要重新加载上下文。与其问五轮，不如一次性把五个问题列出来。

# ❌ 一个个问
"这个函数是干什么的？"
（等回复）
"能不能优化一下性能？"
（等回复）
"顺便加个缓存？"

# ✅ 打包问
"关于 src/services/search.ts 的 fullTextSearch 函数：
1. 帮我梳理一下当前的执行流程
2. 分析性能瓶颈在哪
3. 加一层 Redis 缓存，热门查询缓存 5 分钟
4. 改完确保现有的 12 个测试用例都能过"

原则三：善用 auto mode

在 Claude Code 里，Shift+Tab 可以切换到 auto mode。4.7 的自主性比 4.6 强很多，auto mode 下它会自己决定要不要读文件、跑测试、调用工具，不用你一步步确认。

# Claude Code 中切换 auto mode
# 按 Shift+Tab 进入自动模式
# 适合：多文件重构、跑测试、部署流程
# 不适合：涉及删除数据、修改生产配置等高风险操作

我自己的习惯是：探索阶段手动模式，确认方向后切 auto，收尾验证再切回手动。

原则四：设置任务完成通知

4.7 跑复杂任务可能要几分钟，你不用盯着屏幕等。Boris 提到可以用 hook 机制设置通知。

// .claude/hooks.json
{
  "onTaskComplete": {
    "command": "notify-send 'Claude Code' '任务完成了，回来看看'"
  }
}

macOS 用户可以换成 osascript -e 'display notification "任务完成" with title "Claude Code"'，或者接个 Slack webhook 推到手机上。

Effort 等级怎么选？

这是 4.7 最重要的配置项，没有之一。Boris 反复强调：升级后不要沿用 4.6 的 effort 设置，必须重新实验。

因为 4.7 换了新 tokenizer，高 effort 下思考量增加，token 消耗模式和 4.6 完全不同。

Effort 等级适用场景Token 消耗思考深度自主性推荐度备注
low格式转换、简单查询、代码补全最低（约为 xhigh 的 20-30%）几乎不思考低⭐⭐⭐ 成本敏感场景同等 effort 下表现优于 4.6
medium单文件修改、明确的 bug 修复较低（约为 xhigh 的 40-50%）简单推理中低⭐⭐⭐⭐ 日常开发性价比甜点
high多文件改动、并发会话中等（约为 xhigh 的 60-70%）中度推理中⭐⭐⭐⭐ 并发场景首选适合同时开多个会话
xhigh（默认）复杂编程、自主任务、模糊 debug较高深度推理高⭐⭐⭐⭐⭐ 大多数场景最优Boris 推荐的默认选择
max极端复杂的算法、架构设计最高（可达 xhigh 的 2-3 倍）极深度最高⭐⭐⭐ 谨慎使用存在收益递减，容易过度思考

几个实操建议：

关于 max 等级：Boris 明确说了存在收益递减。我自己测试了一个中等复杂度的重构任务，xhigh 和 max 的结果几乎一样，但 max 多花了将近一倍的 token。真正需要 max 的场景是那种"涉及 5 个微服务的分布式事务一致性问题"这种级别的。

关于 low/medium：别小看这两个等级。4.7 在低 effort 下的表现已经超过 4.6 同等级，我用 medium 跑日常的单文件修改完全够用，成本大概是 xhigh 的一半不到。

我的日常配置策略：

代码补全、格式化 → low
单文件 bug 修复 → medium  
多文件重构 → xhigh（默认就好）
同时开 3-4 个会话 → 全部用 high（控制总成本）
真正卡住的疑难杂症 → max

Adaptive Thinking 实操指南

4.7 最大的架构变化之一：Extended Thinking 被 Adaptive Thinking 取代了。

之前 4.6 的 Extended Thinking 是固定预算制——你给它分配多少 thinking token，它就用多少。问题是简单问题也会把预算用满，白白浪费。

Adaptive Thinking 完全不同：模型自己决定要不要思考、思考多深。 你问"Python 怎么读文件"，它直接给答案，不浪费一个 thinking token。你问"这个分布式锁为什么偶发死锁"，它会自动投入大量 thinking token 做深度推理。

但有时候你需要手动干预。Boris 给了两个方向的控制方法：

想让它多思考

# 方法一：在提示词里显式要求
"请仔细一步步思考，这个问题比看起来更难。
分析 src/services/payment.ts 中的并发扣款问题，
考虑所有可能的竞态条件。"

# 方法二：强调问题的复杂性
"这个 bug 在生产环境只有 0.1% 的概率复现，
涉及 Redis 集群主从切换的时序问题，
请深入分析所有边界条件。"

想让它少思考（省 token）

# 方法一：明确表达偏好
"优先快速回答而不是深度思考。
把这个 Python dict 转成 TypeScript interface，不需要解释。"

# 方法二：限定输出格式
"直接给代码，不要解释：
给 User 模型加一个 email_verified 字段，boolean 类型，默认 false。"

实际效果对比

我在 ofox.ai 上用同一个 debug 任务测了三种提示词：

提示词策略Thinking Token 消耗结果质量总耗时
不加任何引导~800 tokens找到了主要 bug12s
加"请仔细一步步思考"~2400 tokens找到主要 bug + 2 个潜在问题28s
加"快速回答不要深度思考"~200 tokens找到了主要 bug 但遗漏一个边界条件5s

大部分场景下，不加引导让 Adaptive Thinking 自己决定就好。只有两种情况需要手动干预：你确定问题很复杂但模型低估了（强制多想），或者你只是要个快速答案不需要深度分析（强制少想）。

从 4.6 迁移的三个坑

我第一天从 4.6 切到 4.7 的时候踩了三个坑，Boris 的文章里也提到了，这里展开说说怎么解决。

坑一：回复突然变短了

现象：4.6 习惯性输出很长的回复，代码 + 解释 + 注释一大堆。4.7 切过去之后，回复明显短了，有时候改了三个文件只给你看 diff，不展开完整代码。

原因：4.7 的回复长度会根据任务复杂度自动调整。简单改动它就不啰嗦了。

解决方案：

# 如果你确实需要完整代码（比如要复制粘贴）
"请输出修改后的完整文件内容，不要省略未改动的部分。"

# 如果你需要详细解释（比如在学习）
"请详细解释每处改动的原因和涉及的设计考量。"

其实这个变化是好事。4.6 那种不管什么任务都输出一大坨的风格，在真实开发中反而低效。适应几天就好了。

坑二：工具调用变少了

现象：4.6 动不动就调用文件读取、搜索、执行命令等工具。4.7 在很多场景下选择先推理，不急着调工具。

原因：4.7 的推理能力更强，很多时候它通过上下文就能推断出答案，不需要真的去读文件。

解决方案：

# 如果你确实需要它去读文件/跑命令
"请先读取 src/config/database.ts 的当前内容，
然后再做修改。不要基于假设修改。"

# 如果涉及运行时状态
"请实际运行 npm test 查看当前测试结果，
不要假设测试状态。"

坑三：子代理生成变少了

现象：4.6 在处理复杂任务时经常自动生成子代理（sub-agent）来并行处理。4.7 默认倾向于自己串行处理。

原因：4.7 对自己的单线程处理能力更有信心（确实也更强了），所以不轻易拆分任务。

解决方案：

# 需要并行处理时明确指出
"这个任务涉及 4 个独立的微服务改动，
请为每个服务创建子代理并行处理：
1. user-service: 修改用户模型
2. order-service: 修改订单查询
3. payment-service: 修改支付回调
4. notification-service: 修改通知模板"

怎么用 ofox.ai 调 Opus 4.7

我第一时间在 ofox.ai 上测试了 4.7，这里分享一下接入方法。ofox 的好处是一个 API Key 能切换所有主流模型，不用分别管理 Anthropic、OpenAI 的 key。

Python 调用示例

import openai

client = openai.OpenAI(
    api_key="your-ofox-api-key",
    base_url="https://api.ofox.ai/v1"
)

# 基础调用
response = client.chat.completions.create(
    model="claude-opus-4-20250918",
    messages=[
        {
            "role": "user",
            "content": "分析这段代码的并发问题：\n\n```python\nimport threading\n\ncounter = 0\n\ndef increment():\n    global counter\n    for _ in range(100000):\n        counter += 1\n\nthreads = [threading.Thread(target=increment) for _ in range(10)]\nfor t in threads: t.start()\nfor t in threads: t.join()\nprint(counter)\n```"
        }
    ],
    # 配置 effort 等级（通过 extra_body 传递）
    extra_body={
        "thinking": {
            "type": "enabled",
            "budget_tokens": 10000  # 对应大约 xhigh 级别
        }
    }
)

print(response.choices[0].message.content)

配置不同 Effort 等级

# Low effort - 简单任务
response = client.chat.completions.create(
    model="claude-opus-4-20250918",
    messages=[{"role": "user", "content": "把这个 JSON 转成 YAML"}],
    extra_body={
        "thinking": {
            "type": "enabled",
            "budget_tokens": 1024  # low effort
        }
    }
)

# Medium effort - 日常开发
response = client.chat.completions.create(
    model="claude-opus-4-20250918",
    messages=[{"role": "user", "content": "修复这个 null pointer 异常"}],
    extra_body={
        "thinking": {
            "type": "enabled",
            "budget_tokens": 5000  # medium effort
        }
    }
)

# xhigh effort - 复杂任务（推荐默认）
response = client.chat.completions.create(
    model="claude-opus-4-20250918",
    messages=[{"role": "user", "content": "重构整个认证模块，从 session 迁移到 JWT"}],
    extra_body={
        "thinking": {
            "type": "enabled",
            "budget_tokens": 10000  # xhigh effort
        }
    }
)

# Max effort - 极端复杂问题
response = client.chat.completions.create(
    model="claude-opus-4-20250918",
    messages=[{"role": "user", "content": "设计一个支持百万级并发的消息队列架构"}],
    extra_body={
        "thinking": {
            "type": "enabled",
            "budget_tokens": 30000  # max effort
        }
    }
)

在 Claude Code 中配置 ofox 端点

# 设置环境变量
export ANTHROPIC_BASE_URL="https://api.ofox.ai/v1"
export ANTHROPIC_API_KEY="your-ofox-api-key"

# 启动 Claude Code
claude

curl 调用示例

curl https://api.ofox.ai/v1/messages \
  -H "Content-Type: application/json" \
  -H "x-api-key: your-ofox-api-key" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-4-20250918",
    "max_tokens": 4096,
    "thinking": {
      "type": "enabled",
      "budget_tokens": 10000
    },
    "messages": [
      {
        "role": "user",
        "content": "Review this pull request for security vulnerabilities..."
      }
    ]
  }'

ofox.ai 支持同一个 Key 调用 Claude、GPT、Gemini 等所有主流模型，在做模型对比测试的时候特别方便——改一个 model 参数就行，不用换 Key 换 base_url。

FAQ

4.7 比 4.6 贵多少？

API 单价没变，但因为新 tokenizer 和 Adaptive Thinking 机制，实际 token 消耗会上升 15-40%（取决于任务复杂度和 effort 等级）。简单任务可能更省（Adaptive Thinking 不浪费 token），复杂任务会更贵。通过 ofox.ai 调用可以看到每次请求的详细 token 消耗，方便做成本核算。

Effort 设什么最划算？

xhigh 是综合最优解。 Boris 的原话是"大多数编程和自主任务的最佳选择"。如果你要控制成本，日常单文件改动用 medium，复杂任务用 xhigh。不建议无脑用 max，收益递减很明显。

老项目要不要迁移到 4.7？

要。 但不要直接切换就完事。你需要：

  1. 重新测试你的 effort 设置（4.6 的配置在 4.7 上可能不是最优）
  2. 检查依赖回复长度的自动化流程（4.7 回复更精简）
  3. 如果有依赖子代理的工作流，可能需要在提示词里显式要求

Adaptive Thinking 和 Extended Thinking 到底什么区别？

维度Extended Thinking（4.6）Adaptive Thinking（4.7）
思考预算固定分配，用完为止动态分配，按需使用
简单问题也会消耗预算思考直接回答，不浪费
复杂问题可能预算不够自动增加思考量
控制方式设置 budget_tokens提示词引导 + budget_tokens 上限
Token 效率较低（固定开销）较高（按需分配）

简单说：Extended Thinking 像是给你一张固定额度的购物卡，不管买什么都要刷完。Adaptive Thinking 像是按需付费，买多少花多少。

怎么控制 token 消耗不失控？

五个实操方法：

  1. 根据任务选 effort 等级，不要所有任务都用 xhigh/max
  2. 提示词里加"快速回答"，简单任务抑制过度思考
  3. 打包提问减少轮次，每轮都有上下文加载开销
  4. 设置 max_tokens 上限，防止回复过长
  5. 用 ofox.ai 的用量面板监控，及时发现异常消耗

4.7 最适合拿来干什么？

根据 Boris 的建议和我自己的测试，4.7 最能拉开差距的四类任务：

  • 复杂多文件改动：涉及 5 个以上文件的重构，4.7 的全局理解力远超 4.6
  • 模糊 Debugging：只知道"偶尔出问题"但不知道具体原因，4.7 能自主排查
  • 跨服务代码 Review：能发现跨服务调用链上的一致性问题
  • 多步骤自主任务：比如"搭建一个完整的 CI/CD 流水线"，auto mode 下一路跑完

总结一下

Opus 4.7 不是换皮升级，是真正的能力跃迁。核心变化三句话概括：

Adaptive Thinking 让它变聪明了——不再一刀切地思考，该快快该深深。

Effort 等级体系让你能精细控制成本——从 low 到 max 五档，覆盖从代码补全到架构设计的全场景。

自主性大幅提升——模糊任务不再需要你手把手带，给个方向它自己能跑。

Boris 的建议归结为一点：忘掉你在 4.6 上养成的习惯，重新学习和 4.7 协作。 它不需要你写那么详细的提示词了，但它需要你在第一条消息里把任务定义清楚。它不需要你一步步确认了，但它需要你在关键节点做质量把关。

如果你还没试过 4.7，去 ofox.ai 上申请个 Key 跑一下，用 xhigh effort 给它一个你手头最棘手的 bug，感受一下和 4.6 的差距。相信我，回不去了。

avatar
文章
阅读
粉丝