两天前林俊旸发了篇长文，标题叫《From "Reasoning" Thinking to "Agentic" Thinking》，核心观点是：推理模型的时代使命已经完成了，接下来是智能体的时代。
这篇文章在掘金热榜上也引发了不少讨论。说实话，我看到标题的第一反应是，终于有人把这事儿挑明了。
过去几个月，我在项目中把 Claude Opus 4.6、Sonnet 4.6、GPT-5.4、DeepSeek V4、o3 都轮了个遍。最大的感受是：选模型这件事，远没有跑个 benchmark 排行榜那么简单。
先说我走过的弯路
去年底 o3 发布的时候，我跟很多人一样，"推理能力强 = 编程能力强"这个等式在脑子里根深蒂固。毕竟 o3 在数学推理和竞赛题上的表现太炸裂了，很自然就觉得拿来写代码也是降维打击。
于是我把 Claude Code 和 Cursor 的默认模型都换成了 o3。
一个月下来，问题暴露得很明显。
首先是推理模型"想太多"。日常写个 CRUD 接口或者改个组件，o3 会生成一大段思维链，翻来覆去论证半天，最后写出来的代码和 Sonnet 差不多。但 token 消耗是 3-5 倍。
然后是推理不等于准确。像"写一个带搜索过滤的表格组件"这种需求，推理模型偶尔会因为想多了搞出过度设计，加一堆你根本不需要的抽象层。
最让我肉疼的是成本。o3 的推理 token 计费让月度账单直接涨了 60%，产出却没什么质的变化。个人开发者扛不住这个。
不同任务的表现差异，比我预想的大
踩完坑之后，我花了大概两个月时间，有意识地在不同任务上轮换模型，记录哪个好使。以下全是实际项目里的体验，不是对着 benchmark 表格编的。
日常开发（占工作量 70%+）
包括写 React 组件、调 REST 接口、改 CSS、写配置文件这些活儿。
我的体验是 Claude Sonnet 4.6 最好使。反应快，输出干净，理解上下文的能力很强。价格只有 Opus 的 1/5 左右。我现在 90% 的日常开发都扔给它。
复杂架构和大规模重构
需要理解整个项目结构、做跨文件改动的场景。
Claude Opus 4.6 的上下文理解目前最强，给它一个几万行的项目，它能准确定位改动点之间的依赖关系。不过 GPT-5.4 在 SWE-bench Pro（更难的多语言评测）上分数更高，57.7% vs Opus 的 45.89%。碰到不熟悉的语言框架时，GPT-5.4 泛化得更好。
算法和数学相关
这是推理模型真正的主场。涉及复杂算法设计、数学证明、逻辑推导的任务，o3-pro 的表现确实领先一截。Aider 的测试里 o3-pro 拿了 84.9%。
但这类任务在日常工作中占比不到 10%。为了这 10% 把所有任务都用贵 5 倍的推理模型，有点大炮打蚊子。
Debug 和错误排查
有点出乎意料，Sonnet 4.6 在 debug 上经常比 Opus 和 o3 还快。给它一段报错信息或者异常行为描述，它能很快锁定问题。我猜 debug 更需要直觉和模式匹配，不太吃长链推理那一套。
国产模型
DeepSeek V4 在中文文档生成和国内技术栈适配上表现不错，价格也低。但在处理大型英文代码库的复杂任务时，和 Claude/GPT 还有差距。适合做辅助，不建议当主力。
Benchmark 已经说明不了问题了
今年 3 月的 SWE-bench Verified 排名很有意思：
| 模型 | 得分 |
|---|---|
| Claude Opus 4.6 | 80.8% |
| Gemini 3.1 Pro | 80.6% |
| MiniMax M2.5 | 80.2% |
| GPT-5.4 | ~80% |
| Claude Sonnet 4.6 | 79.6% |
六个头部模型挤在 1.3% 的区间里。差距已经小到几乎没有实际意义了。
和林俊旸说的一样，模型本身的能力已经到了一个平台期。接下来的差距不在模型上。
我现在的选择策略
| 任务类型 | 首选模型 | 原因 |
|---|---|---|
| 日常开发（组件/接口/样式） | Sonnet 4.6 | 快、准、便宜 |
| 架构设计/重构 | Opus 4.6 | 上下文理解最好 |
| 不熟悉的语言/框架 | GPT-5.4 | 泛化能力强 |
| 算法/数学 | o3-pro | 推理能力确实强 |
| 中文内容/国内框架 | DeepSeek V4 | 中文生态好，价格低 |
| Debug | Sonnet 4.6 | 直觉式排查更快 |
实际操作中有个细节很重要：模型切换要无感。我现在用 API 聚合服务（类似 ofox.ai 这种），一个 endpoint 就能在不同模型之间切换。Claude Code、Cursor、Cline 全都指向同一个地址，改个模型名就行，比每个工具单独配 Key 省事太多。
比选模型更重要的事
林俊旸那篇文章里有句话我记住了：竞争优势不再来自更好的算法，而是更好的环境设计。
翻译成人话就是，你怎么给 AI 搭环境、写约束，比你选哪个模型重要得多。
最近很火的 Harness Engineering（驾驭工程）讲的就是这个。LangChain 做过一个实验：他们的 coding agent 在 Terminal-Bench 2.0 上，只优化了外部环境（文档结构、验证循环、追踪系统），成绩就从 52.8% 到了 66.5%。模型没换，参数没动。
我自己也深有体会。给 AI 编程工具配好详细的项目说明文件、设好 lint 自动检查和测试流水线之后，代码一次通过率至少提高了 30%。模型还是那个模型，但结果天差地别。
所以如果你现在还在纠结"到底哪个模型最强"，建议换个方向使劲：
写好项目约束文件，把编码规范、技术栈、架构决策都喂给 AI。配好自动化反馈，lint、type check、测试要能自动跑，AI 看到报错会自己修。还有就是别贪大，一次让 AI 改 20 个文件大概率翻车，拆成小任务靠谱得多。
总结一句话
头部模型之间的差距已经很小了，纠结选哪个不如琢磨怎么用好它们。
非要我只推荐一个的话：Sonnet 4.6 打底，复杂任务临时切 Opus 或 GPT-5.4。大部分开发场景，这套组合就够了。