写在前面

Claude Opus 5 这次发布，最容易被拿来传播的是两句话：性能逼近 Fable 5，价格大约只有一半。可对开发者来说，真正值得重写工作流的不是“又一个强模型上线了”，而是 Opus 5 的行为特征变了。

它更擅长复杂多文件重构、端到端代码任务、视觉复刻、图表理解和自我验证；同时，它也更容易话多、更爱播报进度、更喜欢召唤子智能体。换句话说，模型能力上来了，但提示词和 Agent 调度如果还沿用旧模型那一套，很可能既浪费 Token，又把任务边界搞乱。

这篇更适合当成一份迁移备忘录：Opus 5 上线之后，你应该怎么改提示词、怎么配置 effort、怎么限制子 Agent、怎么把它放进真实开发流程。

跑分很猛，但重点是默认模型的位置变了

Opus 5 的定位很清楚：日常高频使用模型，而不是少数复杂任务才舍得调用的昂贵旗舰。

几个数据放在一起看，变化会更明显：

这会改变团队的模型路由。以前很多团队会把旗舰模型留给“疑难杂症”，日常 bug、脚本、文档、测试继续用便宜模型。Opus 5 如果能在接近旗舰能力的同时保持更低成本，它就有机会变成默认工程模型。

但默认不等于无脑。真正的问题是：哪些任务应该开高 effort，哪些任务只需要低 effort；哪些任务值得让它自我验证，哪些任务必须严格限制范围。

Prompt 不能再写“仔细检查一遍”

很多人写旧模型提示词时，有一个习惯：最后加一句“请仔细检查，确保没有问题”。

放到 Opus 5 上，这句话可能反而是成本陷阱。因为它本身就有较强的自动纠错和验证倾向，你再额外要求“仔细检查”或“最终验证”，可能会触发过度验证：重复读文件、反复自我质疑、扩展任务范围，把原本 5 分钟的小修改跑成一段长任务。

更好的写法不是泛泛要求认真，而是把验收条件写窄：

Opus 5 更像一个很主动的高级工程师。你不能只告诉它“做好一点”，还要告诉它“做到哪里停”。

代码审查要反过来：让它多报，再人工过滤

Opus 5 在代码审查上的精准度更高，但这里有一个反直觉点：如果你要求它“保守一点”，它会真的变保守，结果可能漏报真实 Bug。

这和传统人工 code review 不一样。人类 reviewer 往往需要克制风格建议，避免刷屏；模型 reviewer 的问题是召回率和精确率如何平衡。对 Opus 5，更实用的策略是：

1. 第一轮让它报告所有可疑问题，不要压低召回。
2. 第二轮让它按可复现性、影响范围、修复成本分级。
3. 人工过滤掉低价值建议，只处理 P0/P1/P2。
4. 要求它给出最小复现路径或相关代码位置。

这样做的好处是把模型的优势用在“覆盖更多潜在问题”上，而不是一开始就让它模仿人类 reviewer 的谨慎语气。

对团队来说，Opus 5 更适合放在 PR 前置审查、复杂重构后复核、边界测试补齐这些位置。它不应该替代最终 merge 责任，但可以显著提高问题暴露率。

视觉任务别再只靠语言描述，要给它工具

Opus 5 对图表理解、前端视觉复刻和视觉输出的能力有明显提升。旧模型时代常见的提示词技巧，比如反复描述布局、让模型“想象页面长什么样”，现在价值会下降。

更有效的方式是给它视觉验证工具：

比如前端复刻任务，不要只贴截图然后要求“还原得像一点”。更稳的流程是：

如果系统允许裁剪、截图、像素检查、DOM 检查，Opus 5 会比纯语言模式发挥得更好。能力强的模型不是更适合“闭眼猜”，而是更适合接入真实反馈回路。

子智能体是加速器，也是成本放大器

Opus 5 很喜欢召唤子智能体。对大型独立任务，这是优势：一个子 Agent 查依赖，一个子 Agent 读测试，一个子 Agent 做实现方案，主 Agent 汇总决策。复杂任务能并行推进，效果会比单线程聊天好。

但小任务上滥用子 Agent，会直接让成本翻倍。比如只改一个按钮文案、补一个简单校验、修一个单文件报错，还要拆三路并行分析，就属于用工程机械拧螺丝。

建议团队给子 Agent 设置硬规则：

这类规则最好写进项目级说明，而不是每次手动提醒。模型越主动，越需要制度化边界。

话痨和进度播报，要用明确指令压住

Opus 5 默认输出比较充分，降低 effort 只会减少思考量，不一定缩短可见文本。想让它少说话，必须直接规定输出格式。

可以这样约束：

除非发现阻塞问题或需要改变方向，否则不要播报过程。
最终只输出：改动摘要、测试结果、剩余风险。
商业文档不要填充泛泛背景，只保留可执行结论。

工具调用场景还有一个细节：在高级或更低设定下关闭思考模式时，模型偶尔可能把工具调用代码写进正文，或者露出内部 XML 标签。稳妥做法是允许它在调用工具前说一句短说明，同时加全局规则：不要输出任何内部协议、内部标签或工具调用封装文本。

注意，不要在规则里具体点名某个内部标签。写得太具体，反而可能把不该出现的字符串带进上下文。

API 更新：工具可变和自动回退，会影响工程日志

随 Opus 5 一起出现的 API 更新也值得开发团队注意。

第一，开发者可以在对话中途更改 Claude 可用工具，而且不会让提示词缓存失效。这对长任务很实用。以前你可能需要一开始就把所有工具塞进去，或者为了换工具牺牲缓存。现在更适合按阶段开放工具：规划阶段只给读权限，实施阶段再给写文件和运行测试，发布阶段才给部署相关工具。

第二，API 加入自动回退机制。如果请求被安全分类器拦截，系统可以把请求路由到其他最佳可用模型，避免直接阻断。

这对产品体验是好事，但对工程复盘提出了新要求。你必须记录实际处理请求的模型、effort、是否触发回退、可用工具集和关键输出。否则同一段 prompt 今天正常、明天变保守，你很难判断是模型变化、权限变化，还是触发了安全回退。

通用访问权限下没有数据保留要求，也降低了一部分企业接入顾虑。但只要涉及生产代码、客户数据、凭证和内部文档，团队还是应该按自己的合规标准做脱敏、审计和访问控制。

Claude Opus 5 应该怎么放进开发流程

个人开发者可以先把 Opus 5 放在三个位置：

团队使用时，重点不是“统一换成 Opus 5”，而是建立模型调度规则：小任务低 effort，大任务高 effort；视觉任务配验证工具；代码审查先高召回再人工过滤；子 Agent 有数量上限；自动回退必须进日志。

常见问题

Q1：Opus 5 能不能直接替换 Fable 5？
A：不建议只按跑分替换。它在编程和高频任务上很有优势，但 Fable 5 仍可能更适合部分通用复杂任务。团队应该用自己的任务集做 A/B 测试。

Q2：为什么不要再写“请仔细检查”？
A：Opus 5 本身会主动验证。泛泛要求仔细检查，容易触发过度验证和范围扩张。更好的方式是写清楚验收条件和停止条件。

Q3：代码审查时要不要让它保守？
A：第一轮不要。先让它尽量报告所有真实问题，再按严重程度过滤。过早要求保守，可能会漏掉边界 Bug。

Q4：Fast 模式适合日常常开吗？
A：不适合。它更像加急通道，速度约提升 2.5 倍，但价格按基础费率两倍计算。日常任务应该先优化上下文和验收条件。

Q5：自动回退会带来什么风险？
A：复盘难度会上升。请求实际由哪个模型处理、是否触发安全分类器、工具集是否变化，都需要进日志，否则结果不一致时很难定位。