Claude Opus 4.7 上线实测：更能干，也更烧 Token

你要的不是“新模型有多强”的口号。

你要的是：

• 它能不能把你每天卡住的活儿干掉，让你早点下班一小时。
• 它会不会把你的限额吃到怀疑人生。
• 它那种“我偏要这么做”的自主风格，能不能被你按住。

基于一圈用户第一天的真实反馈，我把结论压缩成一份可直接照做的上手教程。

这波口碑最一致的亮点：计划能力明显变强

有位测试者直接夸：Opus 4.7 写出来的 plans 比预期好很多。

具体是什么感觉？

• 你丢一个大代码库现代化的任务（重构模块、替换组件、拆分服务）。
• 它能像资深工程师一样把活儿拆开：依赖、风险、迁移路径、验收点。
• 甚至能自己做一定程度的自检。

当然也有人提到小瑕疵，比如漏掉某些组件更新。

结论很现实：规划质量是大亮点，但你仍要给它“必须扫描的清单”，不然它会漏。

吐槽也很集中：它更自主、更犟了 😅

有人直接开喷：它不太理你的 workflow prompts，按自己想法干。

这类“更自主”的模型有个优点：更像 agent，会主动推进。

也有个缺点：

• 你让它“按我这 5 步走”。
• 它觉得你这 5 步不合理，然后自作主张改流程。

如果你是写代码/做方案的人，可能会觉得爽。

如果你是有严格合规流程、固定格式、固定审批路径的团队，可能会炸。

下面给你一套压住它的指令模板。

另一个关键词：Token 消耗，真的会痛

多位用户都提到：Opus 4.7 是个“大 token 消耗者”。

原因大概两块：

• tokenizer 变化，同样输入可能最多多吃 35% token
• 模型更爱“思考”，尤其在高 effort / 子代理（subagents）模式下

甚至有人实测：只用 1-2 次 subagents，就消耗掉 5 小时限额的 37%。

所以别一上来就全量切换。

你要做的是：把它用在值钱的地方。

上手策略：把 4.7 用在“赚钱的任务”上

适合直接上 4.7 的 3 类场景

1）大项目规划、迁移、重构

场景例子：

• “把这个老项目从 X 框架迁到 Y，给我一份能落地的迁移路线图。”
• “把 monorepo 拆成 3 个服务，列清楚边界、接口、风险、验收。”

你要的是：拆解 + 风险控制 + 验收点。

4.7 在这类任务上最容易体现“像 senior dev”。

2）Agent 类任务：让它连续推进

场景例子：

• “根据 PRD 生成任务拆分 → 出接口设计 → 写实现 → 自测用例 → 输出变更说明”

这类长链条任务，4.7 的可靠性更讨喜。

3）高分辨率图像阅读 + 专业输出

有人测试图像阅读、UI、文档、幻灯片，反馈是“incredible”。

如果你做产品/设计/内容交付，这块可能会让你惊喜。

不建议全切换的 2 类人

• 轻度聊天党：你可能感受不到“计划/agent”的增益，只会感受到限额掉得更快。
• 对 token/限额敏感的人：没做好策略前，先小范围试点。

让它听话：一套“压住自主性”的工作流 Prompt

模型更自主不等于你要跪着用。

你需要更像“项目经理”的写法：给它边界、检查点、禁止项。

把下面这段当模板直接抄：

你是我的执行助手。严格按我给的流程走，不要私自改步骤。

目标：{你要完成的结果}

工作流（必须按顺序执行）：
1) 复述目标与输出格式（不超过120字）
2) 列出你需要的输入清单（缺什么就问，不要猜）
3) 给出计划：分成{N}步，每步包含：动作、产物、验收标准
4) 执行第1步，输出产物
5) 自检：用清单逐条核对（每条“通过/不通过+原因+修复方式”）

硬性约束：
- 不要引入我没给的依赖/库
- 不要改变现有目录结构
- 不要输出说教或背景科普

当你想改变流程时：先停下来，说明理由，等我确认。

这个模板的核心是两点：

• 不让它自由发挥到失控（先确认再改流程）
• 每一步都有验收标准（减少“看似完成，实际没法落地”）

省 Token：别让“思考”把你限额烧穿

下面这几招很朴素，但真能救命。

1）让它默认“短思考”，必要时再加档

你可以直接在提示词里写：

默认用最省token的方式回答。
只有在涉及安全风险/架构决策/会影响大量代码时，才提高思考深度。

你会发现它没那么爱写一大堆“内心戏”。

2）把长上下文改成“检索式输入”

有人提到长上下文检索像是有回归，部分人觉得不如 4.6 稳。

解决办法是：别把整本书塞进去。

换成这种喂法：

• 你先给它目录/文件树
• 让它点名要看的文件
• 你再按它的清单分批贴

可用模板：

下面是仓库文件树。
你先告诉我：为完成目标你必须阅读的文件清单（最多10个），并说明原因。
等我把文件内容贴给你后再开始写方案/改代码。

3）高 effort / subagents：用“预算”锁死

想用更强模式也行，先讲清楚预算：

token预算：最多消耗{X}。
subagents最多启用1次。
如果预计超预算，先给我更省的替代方案。

这句很关键：预计超预算就停。

不然它能一路“认真”到你账号见底。

一套 30 分钟试跑方案：判断你该不该上车

别靠感觉。

用同一份任务对比 4.6 vs 4.7，30 分钟就有结论。

测试任务 A：计划能力

把你手头真实项目丢进去：

我有一个{技术栈}项目，要完成{迁移/重构/新增模块}。
给我一份可执行计划：
- 目标与范围
- 风险点（按严重程度排序）
- 里程碑与验收标准
- 回滚方案
要求：假设团队只有2个人，周期2周。

看它有没有：

• 真正的验收标准（不是“完成开发”这种废话）
• 真正的回滚路径（不是“如果失败就回滚”这种空话）

测试任务 B：指令遵循

用强约束测试它会不会“擅自改流程”：

按我给的输出格式来，不要多写任何段落。
输出必须只有两部分：
1) JSON
2) SQL

它如果还能乱加“解释/建议”，你就知道它的犟劲有多大。

测试任务 C：Token 体感

同样任务跑一遍，记录：

• 生成时长
• 输出长度
• 你账户消耗

如果 4.7 的增益不明显，但消耗明显增加，那就别强上。

小技巧：Notion AI “近乎不限量”的玩法怎么用（思路版）

有人分享过一个思路：用 Notion AI 去调用/体验 Opus，体感接近“不怎么受限”。

这里不展开平台细节，给你一个靠谱用法：

• 把 Notion 当成“任务面板”：PRD、需求列表、代码片段、验收清单都在一个页面
• 让模型围绕这个页面做：拆任务、写文档、输出测试用例

你会明显感觉：

• 信息不容易丢
• 迭代更顺

提醒一句：别把敏感代码/密钥直接扔给任何第三方工作区。

避坑清单（真的会踩）

• 别一上来开 xHigh effort：你是在测试模型，不是在烧香。
• 别把整仓库一次性贴进去：改成“文件树 → 点名 → 分批贴”。
• 别默认它会更新所有组件：加一条“必须扫描依赖与组件更新点”。
• 别把它当乖宝宝：它现在更像“很会做事但很有主见的同事”。边界写清楚。
• 别用它做轻度闲聊还抱怨贵：这属于开跑车买菜，然后嫌油耗。

结论怎么选：你用它来干什么？

• 你是重度 coding / agent 用户：4.7 值得上，计划与推进能力确实更像“老手”。
• 你对限额敏感、主要做聊天：先拿真实任务小范围试跑，满意再切换。

对了，有个梗我也忍不住：强大的 Opus 4.7 依然没过“洗车测试”🤣

你现在用 4.7 感觉怎样？是“更能干”，还是“更能烧”？