Claude Opus 4.7 的正确姿势：把 Claude 当「工程师」，而不是「实习生」

多数人用 Opus 4.7 时只发挥了它 30% 的实力——不是模型不行，而是交互范式还停留在「结对编程」时代。本文从委派模式、Effort 档位、自适应思考三个维度，讲清楚怎么让它真正干活。

一、范式转变：把 Claude 当「工程师」，而不是「实习生」

这是最反直觉、也是收益最大的一条认知升级。

错误姿势：逐行引导式结对编程

很多人习惯像带新人一样喂提示：

• 「先看看这个文件」
• 「好，现在帮我改一下这里」
• 「等等，你刚才那个改法不对，再来一次」
• 「对了忘了说，还要兼容 XX」

这种交互方式有三重代价：

正确姿势：一次性把「任务书」写清楚

把 Opus 4.7 当作一个有能力、值得信任的资深工程师，你给的应该是一份完整的工单，而不是一连串的小指令。

一份合格的初始 prompt 至少包含 4 个要素：

1. 意图（Why）：为什么要做这件事？业务目标是什么？
2. 约束（Constraints）：技术栈、性能要求、不能动的部分、向后兼容性
3. 验收标准（Definition of Done）：怎样算完成？要跑哪些测试？要满足哪些行为？
4. 相关位置（Where）：涉及哪些文件、模块、接口；参考实现在哪里

反例 vs 正例：

反例：
「帮我加个登录功能」

正例：
「在 src/auth/ 下新增一个基于 JWT 的登录接口（参考 src/api/users.ts 的路由风格）。
要求：
- 复用现有的 bcrypt 密码校验逻辑（src/utils/crypto.ts）
- Token 有效期 24h，refresh token 7 天，存 Redis
- 失败 5 次锁定 15 分钟（复用 src/middleware/rateLimit.ts）
- 必须通过 tests/auth/ 下的现有测试 + 新增登录失败/锁定的测试用例
- 不要改动现有 user model 的 schema」

核心原则：模糊提示用多轮补救，不如初始 prompt 写厚一点。前者是「低带宽多次往返」，后者是「高带宽一次到位」。

二、减少交互次数：把问题「打包」提

每一次用户输入，对模型来说都是一次新的推理启动开销——包括重新理解上下文、重新规划行动。哪怕你只补了一句话，背后也是一整轮推理。

实操技巧

• 批量提问：发现遗漏信息时，列一个清单一次性问完，而不是想到一条问一条
• 预判反问：在初始 prompt 里就主动声明「如果遇到 X 就按 Y 处理」，避免模型停下来等你
• 延迟纠偏：模型跑偏时，先看完它整段输出再统一纠正，比中途打断更高效（除非已明显走错方向）

三、Auto Mode：信任带来的速度红利

Auto Mode 适合你已经给足上下文、且任务安全可控的场景，它的本质是砍掉确认循环。

什么时候开 Auto Mode

判断标准：如果你预期「全程都得盯着按 Yes」，就开 Auto；如果你需要「在关键节点拍板」，就别开。

四、Effort 档位：钱、时间、智能的三角权衡

Opus 4.7 在 Claude Code 中的默认 effort 已经升级为 xhigh——这是介于 high 和 max 之间的新档位，也是官方推荐的「甜点」。

五档全景对比

关键判断

• xhigh 是新基准线：在不产生 max 那种「token 失控」的前提下，提供了强大的自主性和智能。不知道选什么就用它。
• max 不是「更好」，是「更贵」：边际收益递减明显，且更容易过度思考——把简单问题搞复杂。仅用于：
• 评估模型能力上限
• 真正卡住的硬骨头
• 智能敏感到值得烧钱的关键决策
• 降档不丢人：CRUD、加日志、改文案这种活，medium 完全够用，省下的预算留给真正难的部分

五、自适应思考：从「调旋钮」到「会写提示词」

这是 Opus 4.7 在交互模型上的一个底层变化：

不再支持固定 thinking budget 的 Extended Thinking——取而代之的是自适应思考（Adaptive Thinking）：模型自行判断在哪些步骤需要更深入推理，哪些步骤可以快速决策。

这意味着你不能再靠参数旋钮控制思考深度，而要靠提示词来引导。

想要更多思考（拉高深度）

在 prompt 中明确加入类似句式：

Think carefully and step-by-step before responding;
this problem is harder than it looks.

适用场景：

• 架构设计、安全审计、性能瓶颈分析
• 涉及微妙边界条件的算法
• 你直觉认为「模型可能会想当然」的地方

想要更少思考（拉快响应）

Prioritize responding quickly rather than thinking deeply.
When in doubt, respond directly.

适用场景：

• 大量重复性小任务（批量改注释、批量重命名）
• 已经验证过的成熟模式套用
• 你愿意用一点准确率换响应速度

代价提示：拉低思考会省 token，但在较难步骤上可能损失精度。如果任务里混合了简单和困难步骤，宁可让模型自适应判断，不要强行压低。

六、效率组合拳：一个推荐工作流

把上面所有原则串起来，一个高效的 Opus 4.7 使用流程长这样：

1. 任务规划阶段（你做）
   - 写一份完整的工单：意图 / 约束 / 验收 / 文件位置
   - 预判可能的歧义点，提前在 prompt 里给出处理策略

2. 档位选择阶段（你选）
   - 默认 xhigh
   - 简单批量任务降到 medium
   - 真正难题再上 max

3. 思考调控阶段（你提示）
   - 关键决策处加一句 think carefully
   - 重复性步骤加一句 respond directly

4. 执行阶段（它干）
   - 上下文充足 + 任务安全 → 开 Auto Mode
   - 否则保留关键节点的人工确认

5. 复盘阶段（你审）
   - 一次性看完整段输出再反馈
   - 有问题就批量纠偏，不要打断式纠正

总结：效率的本质是「信息密度」

用好 Opus 4.7 的核心，不是学技巧，而是改变协作心智：

• 多说一次，胜过追问十次——前置信息密度决定上限
• 选对档位，胜过堆叠预算——xhigh 是甜点，max 不是银弹
• 会写提示，胜过调参数——自适应思考时代，prompt 就是旋钮

把它当工程师，它就给你工程师的产出；把它当输入框，它就只能给你输入框的回报。