想到什么说什么

过去两年，AI 编程圈一直在追求一件事：

“有没有一个 AI 能解决所有问题？”

但最近半年，我越来越明显地感觉到，很多团队已经不太讨论“哪个模型最强”了。

真正影响开发效率的，开始变成：

哪个模型适合哪个环节

尤其项目一复杂之后，这种感觉会特别明显。

真实工程里会同时出现很多完全不同的问题。

有的是架构。

有的是历史代码。

有的是 migration。

有的是 CI。

还有一堆 TypeScript 报错、上下文污染、模块联动。

这些事情本来就不是一种能力。

所以现在很多团队的 workflow，会慢慢变成类似这样：

Codex        → 做分析和规划
Claude Code → 做工程执行
DeepSeek     → 大规模生成代码
Cursor       → 日常开发

至少我最近接触到的一些团队，已经开始往这种方向走了。

它未必算行业标准。

但确实越来越常见。

---

AI 编程已经不太像“聊天”了

最早那批 AI Coding，其实非常简单。

问 ChatGPT
复制代码
粘贴 IDE

那时候大家更多是在“问答案”。

后来开始出现：

• Cursor
• Claude Code
• Codex CLI
• Gemini
• DeepSeek

整个事情就开始变化了。

因为项目一复杂，大家很快会发现：

有些模型更适合：

• 想方案
• 看架构
• 做 code review

有些模型则更适合：

• 改文件
• patch
• 跑命令
• 修 TypeScript

再后来，很多团队就不再执着于“一个 AI 全能”。

而是开始把不同模型放进不同环节。

现在大家聊 workflow 的频率，已经明显比前两年高很多了。

---

Cursor 为什么现在还是很多人的主力

前段时间一直有人说：

Claude Code 出来后，Cursor 会不会被淘汰？

但至少从实际使用来看，我没太感觉到。

很多人现在的状态反而是：

Cursor 干日常
Claude Code 干重任务

因为 Cursor 最强的东西，本来就不是 Agent。

而是开发流畅度。

尤其：

• Inline 编辑
• 自动补全
• 文件跳转
• 小步修改

这些东西会直接影响你一天写代码的节奏。

很多时候你只是：

改个接口
修个 bug
调个 API
改下组件样式

这种场景下，Cursor 的体验还是很舒服。

它有点像“AI 增强版 VSCode”。

尤其前端开发里，这种小步迭代特别重要。

真正长期写工程的人其实很清楚：

大部分时间并不是在“重构系统”。

而是在修各种细碎问题。

---

Claude Code 真正改变的是什么

Claude Code 火起来之后，很多人第一次感觉到：

AI 开始真的“参与工程”了。

以前的模型更像：

给建议

现在很多 Agent 已经开始：

• 改多个文件
• 跑 shell
• patch 工程
• 自动修错误
• 跑测试

这个变化其实挺大的。

因为它已经不只是“生成代码”。

而是在真正操作项目。

但这里有个很容易被忽略的问题。

Agent 一旦开始真正动工程，就很容易失控。

我之前有次只是让 Claude Code 修 websocket reconnect。

结果它顺手把整个状态管理从 zustand 改成了 xstate。

最后 git diff 接近两千行。

而且最离谱的是：

它甚至还顺便改了几个完全不相关的 hooks。

从那之后，我基本不太会让 Agent 自由发挥。

尤其大型 TypeScript 项目里。

因为 context 一长之后，模型真的会越来越“自信”。

后面甚至会开始引用已经删掉的 interface。

这种问题，只要长期跑过 Agent workflow，基本都见过。

---

Agentic Coding 和 Vibe Coding 其实不是一回事

现在很多人会把这两个词混着用。

但实际差别挺大。

Vibe Coding 更像：

想到什么
直接让 AI 写

很多 demo、个人项目、前端页面，其实很适合这种方式。

因为重点是：

快速出东西

但 Agentic Coding 更偏工程。

它重点不是“生成”。

而是：

AI 开始真正参与执行

比如：

• 自动改多个文件
• 自动 patch
• 自动执行命令
• 自动跑测试

某种程度上，它更像一个“会操作终端的 AI 实习生”。

而且还是那种：

很积极。

但偶尔会过度发挥的实习生。

---

为什么很多团队开始把 DeepSeek 当“工程劳动力”

这件事其实挺现实的。

因为真实工程里，大量工作并不需要最强 reasoning。

很多任务本质上就是：

改文件
补接口
批量 patch
修 ts error

这种事情数量特别多。

而且会持续消耗 token。

所以很多团队现在会把：

• Claude
• GPT
• Codex

放在：

分析
规划
code review

再把大量执行类任务丢给 DeepSeek。

核心原因其实就两个：

便宜
够用

尤其长任务里，成本差距会非常明显。

很多 Agent workflow 一跑就是几十分钟。

如果全部用高价模型，成本会非常夸张。

所以现在不少团队会形成一种比较固定的模式：

贵模型负责思考
便宜模型负责执行

这其实比“全程一个顶级模型”更符合真实工程。

---

很多人误解了 Claude Code

很多新人会以为：

Claude Code = Claude 模型

但其实不太准确。

至少在很多开发者实际 workflow 里：

Claude Code 更像一个工程操作层。

真正负责输出代码的模型，反而可能是：

• DeepSeek
• GPT
• Gemini
• Claude 本身

也就是说：

很多时候真正重要的，不只是模型能力。

而是：

谁在控制工程

因为一旦 Agent 能：

• 读项目
• 改文件
• 跑 shell
• patch
• git 操作

事情就已经完全不一样了。

---

我后来为什么不再追求“全自动 Agent”

一开始很多人都会觉得：

自动化越高越高级

但真跑过大型 workflow 之后，会慢慢发现：

全自动其实非常容易翻车。

尤其：

• context 污染
• 无限 patch
• overengineering
• token 爆炸
• agent 死循环

这种问题。

有时候你只是想修一个登录 bug。

结果 Agent：

• 顺手重构 auth
• 改 middleware
• 更新 schema
• 调整目录结构

最后 CI 直接炸掉。

而且很多修改单看其实都“有道理”。

但合在一起之后，项目会开始慢慢失控。

所以现在很多成熟 workflow 其实反而没那么自动化。

甚至很多所谓“双终端并行”：

左边 Codex
右边 Claude Code
中间人类复制粘贴

听起来很土。

但意外地稳定。

因为：

人类仍然在控制上下文

这一点其实特别重要。

---

真正重要的能力，其实是“任务切割”

现在很多人会误以为：

高手 = 自动化程度高

但我自己的感觉反而是：

真正稳定的 AI Coding，核心一直是任务拆分。

比如很多人让 Agent 干活时，任务会写成：

重构整个 auth 系统

这种 prompt 很容易失控。

但如果换成：

把 auth service 拆成：
- token.service.ts
- session.service.ts
保持 API 不变
不要修改 controller

模型稳定性会高很多。

很多长期跑 Agent workflow 的人，最后都会慢慢收敛到这种方式。

也就是：

• 大任务拆小
• 上下文隔离
• 明确边界
• 控制 diff

因为 AI 最大的问题之一，其实不是能力不够。

而是太容易“顺手多做”。

---

现在很多 workflow，本质上还是“半自动”

这一点很多新人刚接触时会很意外。

因为大家会以为：

AI 自动调用 AI
AI 自动同步 AI
AI 自动调度 AI

但现实里，很多高手 workflow 其实没那么科幻。

很多时候就是：

tmux 开几个窗口
不同 Agent 干不同事情
人类负责调度

甚至很多流程仍然靠复制粘贴。

但这种方式有个很大的优点：

可控。

尤其大型工程里，这件事比“全自动”重要得多。

---

现在比较常见的几种组合

虽然每个人 workflow 不一样。

但有几种组合出现频率确实特别高。

---

Cursor + Claude

这个应该是现在最常见的组合之一。

尤其前端。

很多人现在基本就是：

Cursor 写日常
Claude 处理复杂逻辑

Cursor 的优势主要还是开发流畅度。

而 Claude 更适合：

• UI 重构
• reasoning
• code review
• 长逻辑分析

尤其 React 项目里，这套组合其实已经很成熟了。

---

Cursor + Claude Code + DeepSeek

这个组合在 Agent workflow 里特别常见。

通常是：

Cursor        → 日常开发
Claude Code → 工程操作
DeepSeek     → 生成代码

因为很多真正耗 token 的任务，其实都是一些重复工程活。

比如 patch、批量改文件、修 ts error。

这些东西如果长期用高价模型跑，成本会很夸张。

所以不少团队现在已经开始：

贵模型负责思考
便宜模型负责执行

这个模式最近越来越常见。

---

Codex + Claude Code + DeepSeek

这套组合最近其实特别常见。

尤其已经开始长期跑 Agent workflow 的团队。

很多人的流程现在会变成：

Codex
  ↓
Claude Code
  ↓
DeepSeek

Codex 负责前面的分析和拆任务。

比如：

• 看项目结构
• 找技术债
• 拆 migration
• 做 refactor 方案

很多时候我会先让它：

先别改代码
先分析

因为一旦直接进入 Agent 执行阶段，context 很容易越来越脏。

后面甚至会开始：

• 引用已经删掉的 interface
• patch 错文件
• 重复修改逻辑

尤其大型 TypeScript 项目里，这种问题特别明显。

所以很多人现在会先让 Codex 做：

任务切割

然后再把小任务交给 Claude Code。

Claude Code 负责真正操作工程。

比如：

• 改文件
• 跑 shell
• patch
• 跑测试

但真正大量生成代码的时候，很多团队又不会全程用 Claude。

因为太贵。

尤其长时间 Agent workflow，token 消耗会非常夸张。

所以最后很多执行类任务，会继续接 DeepSeek。

特别是一些高频工程活。

像：

• CRUD
• 批量修改
• 接口补全
• 重复逻辑

现在越来越多团队其实已经慢慢形成一种固定模式：

Codex 负责分析
Claude Code 负责操作工程
DeepSeek 负责大量生成代码

而人类负责：

控方向
控上下文
控 diff

---

Claude Code + Gemini

这个组合比较适合大型仓库。

尤其：

• monorepo
• 老项目
• 多模块系统

因为 Gemini 长上下文确实有优势。

很多人会让 Gemini：

读全局
分析依赖
整理调用链

然后再交给 Claude Code 真正执行。

尤其代码历史很乱的时候，这种 workflow 会舒服很多。

---

AI 编程真正变化的，其实不是模型

这两年最大的变化，我觉得未必是哪个模型突然碾压所有人。

更明显的变化其实是：

很多团队开始慢慢形成自己的 workflow。

比如：

任务	工具
自动补全	Cursor
架构分析	Codex / GPT
工程执行	Claude Code
大规模代码生成	DeepSeek
长上下文分析	Gemini
PR Review	Claude

而且这种分工，未来大概率还会越来越细。

因为真实工程本来就不是单一能力。

至少我现在已经很少再纠结“哪个模型最强”了。

更多时候我关心的是：

哪个模型放在哪个环节
能少翻车
workflow 怎么稳定

尤其项目规模一大之后，这种感觉会特别明显。

因为真正复杂的工程问题，很多时候根本不是“写代码”。

而是：

• 怎么拆任务
• 怎么控制上下文
• 怎么减少 diff
• 怎么避免 Agent 失控

某种程度上说。

AI 编程的核心，确实已经开始慢慢变成“工作流设计”了。