写在前面
Claude Opus 5 上线之后，最容易被讨论的是跑分：ARC-AGI-3 到了 30.2%，GPT-5.6 Sol 是 7.8%，Opus 4.8 只有 1.5%；AA 跑分甚至压过 Fable 5；输入每百万 Token 5 美元，输出每百万 Token 25 美元，和 Opus 4.8 一样；Fast Mode 速度大约提升 2.5 倍，价格翻倍。
但开发者真正该盯住的，不是“Opus 5 是否干掉 Fable 5”。更重要的问题是：模型能力又往前跨了一步后，我们之前给 Claude Code、Codex、各类 Skill 和本地规则塞进去的限制，是不是已经变成负担。
强模型时代的工作流，不再是“把所有规则提前写死”。更有效的方式，是给模型一个能执行、能反馈、能受控的环境，让它自己判断、调用工具、检查结果、重新尝试。
Opus 5 不是更大的 Fable，而是更成熟的执行 Agent
Opus 5 和 Fable 5 的差异，不能只靠总分判断。更准确的分工是：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Fable 5 更像一颗强大纯大脑，适合在复杂目标还没拆开时做顶层设计。Opus 5 更像一套成熟执行系统，特别会使用工具、检查结果、发现错误，再重新尝试。
这就是为什么它在很多 Agent、办公、代码任务上表现非常亮眼。真实开发里，能不能写出第一版代码已经不是核心瓶颈，能不能发现自己写错了、能不能定位边缘情况、能不能补一轮验证，才决定它能不能进入生产流程。
30.2% 的 ARC-AGI-3，说明模型泛化正在变成生产力
ARC-AGI-3 这类评测有一个价值：它不像普通知识问答那样容易被训练数据覆盖，更看重新规则、新任务、陌生场景下的抽象推理和动态适应。
Opus 5 在这个评测上达到 30.2%，而 GPT-5.6 Sol 是 7.8%，Opus 4.8 是 1.5%。这个差距对开发者的实际含义是：模型遇到没见过的任务时，开始更像“理解问题的人”，而不是“背过很多答案的补全器”。
放到工程现场，泛化能力会体现在这些地方：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
所以，Opus 5 的价值不是跑分本身，而是它更适合承担“没有标准答案的工程任务”。
最刺痛人的案例：多模型审查没发现，Opus 5 找到缓存击穿风险
这篇材料里最值得开发者警惕的，不是模型发布信息，而是一个真实重构案例。
一个 AI 资讯产品做 API、RSS 和 Skill 重构，先用 GPT-5.6 Sol 完成方案和执行，再用 Codex 上的 GPT-5.6 Sol、Kimi K3、Opus 4.8 做深度 Review。几个模型基本都认为没有大问题，只挑出一些小优化。
后来再用 Opus 5 审了一遍，它发现了一个严重漏洞：边缘缓存可能被击穿。这个风险不是纸面上的“安全建议”，而是两周前就曾经导致流量被攻击爬爆、账单崩坏的真实事故类型。
这件事说明两点。
第一，AI Review 不能只看“有没有模型说 OK”。几个模型都没发现，不代表风险不存在。不同模型的优势不同，Review 也需要分工。
第二，执行型模型的价值在边缘条件上。它不只是问“代码能不能跑”，而是问“会不会被极端流量、异常输入、缓存策略、权限边界击穿”。
对企业团队来说，这会影响审查流程。以后大型改动不应该只让一个模型写完、一个模型确认，而要按风险分层：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Opus 5 很适合放在“边界审查”和“执行审查”之间。
Claude Code 该做减法了
模型越弱，越需要手册、示例、流程和提示词把它扶住。模型越强，外部规则越多，反而越容易制造冲突。
Anthropic 在 Claude 5 时代做了一个很激进的动作：把 Claude Code 的 System Prompt 删掉 80% 以上，编码评测没有出现可测量的下降。这个信号很清楚：旧时代靠提示词堆控制，新阶段靠环境和工具塑形。
典型冲突是这样的：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
模型当然能尝试调和这些规则，但每一次调和都要消耗思考 Token，也会增加误判概率。规则堆得越厚，模型越像在解上下文谜题，而不是解决用户任务。
更合理的 Claude Code 使用方式，是把能放进环境的东西放进环境，把需要模型判断的东西留给模型。
从手册制转向 Harness：让模型在环境里完成目标
Claude 5 时代的工作流变化，可以概括成六个迁移：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
CLAUDE.md |
|
|
|
|
这其实就是从“手册制”转向 “Agent Harness”。
Harness 不是简单的 prompt。它是一套让模型完成目标的工程环境：状态在哪、权限怎么给、工具怎么调、失败怎么反馈、日志怎么记录、人工在哪里介入。
强 Harness 的重点不是把模型绑死，而是把风险收进边界：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
模型越强，越应该少写“你必须如何思考”，多设计“你能看到什么、能做什么、做错了怎么知道”。
一套更现实的模型路由
如果团队现在同时能用 Claude、GPT、Kimi、Codex，最糟糕的方式是每天问“谁最强”。更稳定的方式是建立模型路由。
可以先按这个思路拆：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这张表不是固定答案，但它说明一个趋势：AI 编程已经进入“模型调度”阶段。不同模型不再只是替代关系，而是分工关系。
团队真正要沉淀的，不是某个模型的迷信，而是可替换的任务接口。今天 Opus 5 强，明天 GPT 或 Kimi 追上来，你的任务拆分、验证方式和日志结构应该能继续复用。
Claude Opus 5 到底怎么用
Opus 5 是 Claude 系列里更适合高频工程执行的模型：它有 100 万上下文，知识截止时间到 2026 年 5 月；价格延续 Opus 4.8 的输入 5 美元 / 百万 Token、输出 25 美元 / 百万 Token；Fast Mode 适合时间敏感任务，但不适合默认常开。
使用上，建议分三层：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
常见问题
Q1：Opus 5 是否已经取代 Fable 5？
A：没有。Fable 5 仍适合大体量规划、无工具推理和一些高难专业任务；Opus 5 更适合真实执行、工具调用、审查和修复。
Q2：为什么说 Claude Code 要减负？
A：模型能力上来后，过多 System Prompt、Skill 和重复规则会制造冲突。很多约束应该移到工具、权限、测试和环境反馈里。
Q3：/doctor 这类清理命令有什么价值？
A：它的价值不是神秘优化，而是帮你发现上下文里过期、冲突、冗余的规则。强模型需要清晰环境，不需要一堆互相打架的手册。
Q4：Fast Mode 要不要默认开启？
A：不建议。它适合紧急排障和时间敏感任务，速度更快但成本翻倍。日常任务更该优先保证上下文、边界和验收条件清楚。
Q5：多个模型 Review 后还要不要人工看？
A：要。模型 Review 能扩大覆盖面，但责任不能外包。尤其是缓存、权限、账单、生产数据这类风险点，仍要有人工确认和测试。