夜雨聆风别急着选 AI 编程工具，先看它们在抢什么
更新时间：2026-05-24适用范围：AI 编程工具、Coding Agent、个人开发流、团队研发流程、AgentOps 产品观察。资料口径：本文只讨论截至 2026-05-24 仍有公开资料可核验的产品或开源项目，主要依据官方文档、官方博客、项目 README 和公开架构说明。资料不足的同类产品，只放在背景里，不作为主要论据。
过去一年，AI 编程工具的名字开始变得密集。
Cursor、Claude Code、Codex、Jules、Devin、Replit Agent、Lovable、Bolt.new、v0、Conductor、Orca、Superset、Superconductor、Multica。
一串名字排下来，很像一张新教派名录。
每个产品都说自己更接近未来。每个发布页都像在暗示：开发这件事终于要被重新发明。评论区也很配合，有人忙着迁移，有人忙着站队，有人焦虑自己是不是又落后了一轮。
这些讨论常常漏掉一个更朴素的问题：
它们到底在抢开发流程里的哪一段？不问这个问题，讨论很快会滑向工具崇拜。
今天相信 Cursor 是未来，明天相信 Claude Code 是未来，后天又相信 Devin 是未来。工具换了一批，人的判断方式没有变，仍然是被新品发布牵着走。
AI 编程产品确实在变多，但它们没有在做同一件事。
有的产品想守住编辑器入口，有的想占领终端，有的想把 issue 变成远程任务，有的想让非程序员直接生成应用，有的在做多 Agent 工作台，有的在做 Agent 团队管理，还有的在定义 Agent 该读什么规则、调什么工具、记住什么习惯。
所以这篇文章不评测谁最好。
这种评测本来就站不住。一个 IDE Agent、一个云端 Agent、一个 App Builder、一个 MCP 协议，放在同一张排行榜里，本来就很荒唐。
更该看的，是这些产品分别卡住了开发流程里的哪一段，又把开发者推到了什么位置。
先放一张地图。
下面这些方向是观察角度。同一个产品常常占好几格：Cursor 既是 AI IDE，也有 Cloud Agents；Codex 同时有 IDE 扩展、CLI 和云端任务；Claude Code 有 VS Code 扩展，也保留终端 CLI；Windsurf 本地跑 Cascade，也能一键委派给 Devin Cloud。读表时先看它抢的是哪段流程，再看它还有哪些入口。
一、IDE 扩展：先贴在旧工作台上
代表产品：
GitHub Copilot Chat / Copilot 编辑器体验 Cline / Roo Code Continue Claude Code VS Code extension Codex IDE extension
IDE 扩展先占的是开发者已经花在编辑器里的时间。
这条路线很克制。它不要求开发者立刻换工作台，也不急着重写整个 IDE。它默认一个现实：编辑器、快捷键、插件、主题和窗口布局，都是长期积累出来的习惯，不会因为 AI 出现就马上重来。
GitHub Copilot Chat、Cline、Roo Code、Continue、Claude Code VS Code extension、Codex IDE extension，都在处理同一个问题：不让开发者离开原来的编辑器，也能获得 AI 读文件、改代码、跑命令、解释上下文的能力。
它们的做法也很像：先接入文件树、终端、诊断信息和项目上下文，再把 Agent 能力贴进旧工作台。AI 先进去，再慢慢扩大权限。
这条路线的价值很直接，迁移成本低。开发者不用立刻搬家，团队也不用马上重建习惯。
代价也同样清楚。IDE 扩展受制于原 IDE 的界面、权限模型和产品节奏。它可以增强旧工作台，但很难彻底改造旧工作台。
所以看这类产品，重点是它拿到了多少上下文和权限，同时把迁移成本压得多低。
二、AI IDE 产品：重新设计开发者每天打开的工作台
代表产品：
Cursor Windsurf Cascade（含 Devin Cloud 委派） Kiro（AWS 团队出品，独立产品品牌）
AI IDE 争的是整个工作台。
如果说 IDE 扩展是在旧工作台里加 AI，AI IDE 就是在重写工作台本身。它不满足于做一个插件，而是想把文件树、索引、终端、规则、Agent 模式、审查流程和云端任务入口都放进同一个界面里。
Cursor 把 Ask、Plan、Agent、Debug 分成不同模式。Ask 偏探索，Plan 偏规划，Agent 负责动手，Debug 面向需要运行证据的排障。它把「问 AI」「先做计划」和「让 AI 动手」拆成了不同权限。
Windsurf Cascade 把对话、代码修改、检查点、错误检查和云端委派放到同一个工作流里。到了 Windsurf 2.0，本地 Cascade 会话还可以一键交给 Devin Cloud 继续执行。
Kiro 更像流程派。它把 specs、steering、hooks 放在前面，让 IDE 不只是接一句话然后吐出一堆代码。
这条路线真正争的是工作台控制权。AI 能看到多少上下文，能改哪些文件，能不能跑命令，什么时候必须停下来等人确认，这些问题比「生成速度快不快」更重要。
所以看 AI IDE，先别急着看 demo 漂不漂亮。先看它怎么分权限，怎么组织人和 Agent 的配合，再看它的生成能力。
三、终端 Agent：它不哄人，直接面对工程现场
代表产品：
Claude Code CLI OpenAI Codex CLI OpenCode
终端 Agent 抢的是最接近结果的一段：命令执行。
它没有那么会包装。终端里出现的是报错、diff、测试失败、依赖安装和 Git 状态，很难剪成「一句话生成一个产品」的短视频。
Claude Code、Codex CLI、OpenCode 的共同点，是把 Agent 放回 shell、Git、测试命令和项目脚本里。它们可以有 IDE 或桌面入口，但终端路线的标准更硬：命令跑不跑得过，diff 能不能看，失败后能不能继续修。
这条路线的价值也很朴素。一个项目能不能跑起来，最后还是看命令。pnpm test、pytest、cargo test、npm run build、go test ./...，这些命令比一段漂亮解释更可靠。AI 如果能读报错、改代码、再跑命令，就进入了实际开发循环。
终端 Agent 也最容易暴露人的短板。不会写任务、不会看测试、不会读 diff 的人，用起来很容易把项目改乱。Agent 没有替人承担工程判断，只是把判断提得更频繁。
配合终端 Agent，至少要把三件事准备好。
第一，把项目命令写清楚。测试命令、类型检查命令、本地启动命令，最好都能在 README、AGENTS.md 或项目说明里找到。
第二，所有重要改动都走 Git。branch、worktree、diff、commit、PR 是人机协作的安全带。
第三，给 Agent 留可执行的检查点。少说「优化一下」，多写「改完后运行 pnpm test，新增逻辑覆盖 A、B、C，不改 public API」。
终端路线的价值，主要来自它离真实工程更近。工具越会动手，人越要会验收。
四、云端 Agent：把任务交出去，也把模糊放大了
代表产品：
OpenAI Codex Cloud Google Jules GitHub Copilot coding agent Cognition Devin Cursor Cloud Agents
云端 Agent 盯着的是任务委派这一段。
把任务交出去，Agent 在远端环境里干活，回来交计划、日志、diff 或 PR，这套设想很容易让人兴奋，因为它看起来像终于有人可以替你陪跑那些重复工作。
OpenAI Codex Cloud、Google Jules、GitHub Copilot coding agent、Cursor Cloud Agents 的产品形态都很接近：把任务放进远端隔离环境，让 Agent 自己 clone 代码、装依赖、改文件、跑测试，最后交回计划、日志、diff 或 PR。
Devin 的包装更激进，直接称自己为 AI software engineer。先不谈这个说法有多大，产品形态大体还是同一类：输入任务，远程执行，拿回结果，再由人审查。Devin 现在也进入了 IDE，本地规划和云端执行开始被放进同一个控制面板里。
这条路线的好处，是把异步执行做得更像真的外包流程。任务边界清楚，依赖环境可复现，验收标准明确，就可以先交给远端 Agent 跑一轮，人回来再看结果。
问题也会一起被放大。任务写得含糊，Agent 会按自己的理解展开；项目环境复杂，它可能卡在依赖、权限或测试数据上；验收标准不清楚，PR 看起来像完成了，实际留下新债。
所以云端 Agent 很考验写 issue 的能力。一个能交给异步 Agent 的 issue，最好包含背景、目标、范围、非目标、参考文件、验收标准和测试命令。写 prompt 是聊天能力，写 issue 是工程能力。云端 Agent 越普及，这个差距越明显。
PR 也会越来越像 AI 交付物的标准形态。让 Agent 交一个能 review、能跑 CI、能 revert 的 PR，比交一段解释更有用。
云端 Agent 普及以后，会不会派活会比会不会聊天更重要。
五、App Builder：它卖的是「我也能做出来」
代表产品：
Replit Agent Lovable Bolt.new Vercel v0
App Builder 想占住的是从想法到可点击产品的最短路径。
它面对的是另一群人。他们不想学开发流程，不想理解框架争论，也不关心组件抽象。他们想要的是一个能打开、能点击、能发给别人看的东西。
Replit Agent、Bolt.new、Lovable、v0 都在把提示词、代码生成、预览、数据库、部署这些环节放进更短的产品路径里。
这类工具的评价标准和传统开发工具不太一样。普通用户先看结果：能不能打开，能不能点，能不能保存数据，能不能发给朋友，能不能部署到线上。
代码只是其中一段。依赖安装、预览、数据库、鉴权、支付、部署、回滚、错误恢复，这些脏活更容易决定 App Builder 的上限。
它的真实增量也在这里。很多小工具、原型、内部系统，本来就不值得走完整软件工程流程，AI App Builder 确实能把门槛压下来。
它制造的幻觉也在这里。会生成界面，不代表理解产品；能跑 demo，不代表能长期维护；能部署上线，也不代表知道数据、权限、支付和安全意味着什么。
这类工具反过来也提醒开发者，「开发」不只是 repo、branch、component、API、test，还包括把一个想法做成能用的东西。
六、多 Agent 工作台：一个人开始管理一群不会累的实习生
代表产品：
Conductor Orca Superset Superconductor 多 worktree / 多 session / 多 CLI Agent 管理工具 围绕 Claude Code、Codex、OpenCode 的本地编排工作台
多 Agent 工作台处理的是并行调度和现场管理。
当一个开发者同时跑多个 Agent，问题就不再只是「AI 会不会写」，而是：
哪个 Agent 在跑？ 哪个卡住了？ 哪个改了哪些文件？ 哪个结果值得保留？ 哪个分支可以合并？ 哪个任务需要人接管？
普通终端窗口很难管住这些状态。
Orca 之外，类似产品正在变多。Conductor、Orca、Superset、Superconductor 说法不同，但共同点很清楚：同时跑多个 coding agent，用 workspace 或 worktree 做隔离，再把终端输出、代码改动、review 和合并放到同一个工作台里。
这类产品的核心机制其实很简单：先隔离，再并行。一个任务一个 worktree，不同 Agent 的改动互不污染。人可以看 diff，可以比较结果，可以丢弃失败尝试，也可以把某个方向合并回主线。
它解决的不是自动完成一切，而是并行工作时的现场管理。没有 branch、worktree、sandbox，就别急着同时放飞多个 Agent。
收益很明显，代价也很明显。多 Agent 很容易把人从「写代码的人」变成「清理现场的人」。同时开很多 Agent，看起来像效率翻倍，也可能让人同时背上很多审查债务。
更稳的用法是并行探索。同一个 bug，让两个 Agent 走不同修法；同一个功能，一个写实现，一个补测试，一个做 review。人从执行者变成调度者，但还是要判断方向。
所以这类工具的重点，在于能不能把并行带来的混乱和审查成本压住。
七、Agent 团队管理平台：把 Agent 当成团队资源来管理
代表产品：
multica-ai/multica Devin Enterprise 接入 issue、project board、runtime pool 的平台
Agent 团队管理平台争的是组织层的控制面。
「AI 员工」是这轮 AI 编程里最会讲故事的词之一。它比「工具」更有想象空间，因为员工意味着组织扩张、成本下降和管理半径变大。这个词一出现，融资 PPT 和老板的眼睛通常都会亮一点。
Multica 的话说得很直白：Your next 10 hires won’t be human。它想把 issue 分配给 agents，让 agents 像队友一样更新状态、评论、报告 blocker。
Devin Enterprise 走的是另一条团队控制平面：session 管理、权限、审计日志、service user、使用量视图。到了团队规模，问题就不只是「Agent 会不会写代码」，还包括谁能启动它、谁能看日志、谁来审查结果。
这类产品和个人工作台的区别，在于它不只关心「这次改了什么」，还关心「谁有权启动、谁在跟进、日志留在哪、失败怎么追」。Multica 的典型架构就是这种思路：Next.js 前端、Go 后端、PostgreSQL、本地 Agent Daemon 负责发现 CLI agents，服务器分配任务，Daemon 创建隔离 workspace 执行任务，再把日志和结果回传平台。
到了这一步，聊天窗口已经不够用。团队级 Agent 协作至少需要 issue、agent、runtime、run、status、comment、metadata 这些对象，每个状态都能被记录，每次失败都能回头追。
问题也很直接。「像员工一样被管理」离「像员工一样可靠」还有很远。权限、安全、日志、上下文、失败恢复、任务定义、质量审查、组织信任，一个都绕不开。Agent 越像员工，管理系统就越不能像玩具。
所以判断这个方向时，先看它有没有把对象和状态系统化，再谈「AI 员工」的叙事。
八、能力与协议层：最不像产品，却最可能留下来
代表方向：
Rules：AGENTS.md、项目内 rules、instructions、playbooks、runbooks Skills：Anthropic Agent Skills、Warp Skills、mattpocock/skills MCP：连接外部工具、数据源和上下文的协议层
能力与协议层处理的，是规则、复用和连接。
这一层没有漂亮演示，也很难拿来讲最吸睛的故事，但它往往留得最久。它处理的是更枯燥的事：Agent 到底该遵守什么规则、复用什么能力、调用什么工具。
第一类是 rules，告诉 Agent 在这个项目里应该怎么做。AGENTS.md 就属于 rule。除此之外，各 IDE 和 Agent 工具也常有自己的 rules、instructions、playbooks、runbooks。
第二类是 skills，把可复用的任务能力封装起来，让 Agent 不必每次从零开始。Anthropic Agent Skills、Warp Skills、mattpocock/skills 名字和实现不同，方向都差不多：把某类任务的说明、脚本、模板或判断路径封装成可复用能力。
第三类是 MCP。MCP 处理的是连接问题。Agent 要接数据库、浏览器、仓库、文档、内部系统，总要有一套可复用的工具协议。
把三者放在一起看，rules 管约束，skills 管复用，MCP 管连接。它们都在回答一个问题：Agent 怎么拿到稳定、可复用、可执行的上下文和能力。
落到项目里，问题通常就是这些：
这个项目怎么跑测试？ 代码风格是什么？ 哪些文件不能动？ PR 描述怎么写？ 遇到数据库迁移怎么办？ 什么情况要先写 spec？
这些东西如果只存在人的脑子里，Agent 每次都得猜。写成 rules、skills、MCP server、runbook 以后，它们才会变成团队资产。
所以这一层看着最不像产品，最后反而最可能留下来。以后开发者手里多半会多一套东西：专门写给 Agent 看的工作规矩。
九、这些探索共同暴露出的变化
把这些产品放在一起看，AI 编程已经不只是聊天窗口里的问答了，它开始往真正的软件生产流程里走。
聊天窗口处理一次对话，生产流程要处理长期协作。
跟着冒出来的，是一批更像基础设施的对象。
1. 任务身份
一次聊天不够。任务得落成 issue、spec、ticket、run、session 这类对象，不然状态很难追。
2. 隔离空间
AI 不该直接在主分支上乱动。branch、worktree、sandbox、workspace、cloud VM，都是安全边界。
3. 状态可见
Agent 不能只显示「正在想」。created、assigned、running、blocked、failed、done 这些状态越清楚，人越知道该等、该催，还是该接管。
4. 人工关口
AI 写出来的东西不能直接进真实系统。diff、test、review、PR、CI 还是闸门。工具越强，闸门越重要，因为它一旦犯错，影响范围也更大。
5. 经验复用
一次成功经验不能只留在聊天记录里。它得变成 skill、rule、template、AGENTS.md、runbook，不然下次还是从头猜。
这些变化最后都逼着人回答同一个问题：当 AI 可以执行更多动作时，人怎么不被执行速度拖着走？
十、开发者该学什么
工具会变。今天 Cursor 热，明天 Claude Code 热，后天可能又是 Codex、Jules、Devin、OpenCode 或某个新名字。开发者要稳住节奏，把几层真正能留下来的东西积起来，别被每一个新入口带着跑。
1. 积累能力与协议层
第一层是 rules、skills、MCP。
这听起来最不性感，却最容易留下来。工具会换，模型会换，但项目怎么跑、代码风格是什么、哪些文件不能动、PR 描述怎么写、遇到数据库迁移怎么办，这些东西不会因为换了一个 Agent 就消失。
不要把经验只留在聊天记录里。能写进 AGENTS.md 的，就写成 rule；反复出现的做事方法，就写成 skill；需要连接外部工具和内部系统的，就研究 MCP server。
这层东西越完整，Agent 每次要猜的东西越少。长期看，它比某一次 prompt 写得漂亮更重要。
2. 积累个人工作流
第二层是围绕 Cursor、Claude Code、Codex 这些主力工具，做自己的个人工作流。
这类工具现在最常用，也最现实。开发者每天真正会打开的，大概率还是编辑器、终端、Git、测试命令和项目文档。与其幻想一个全自动 Agent 团队，不如先把自己的开发流跑顺。
比如：
用 Cursor 做阅读、定位、局部修改和上下文编辑。 用 Claude Code 或 Codex 处理更长的终端任务、重构、测试修复。 用 Git branch / worktree 隔离每一次重要尝试。 让每个任务都有明确目标、相关文件、验收标准和测试命令。 改完以后看 diff、跑测试、写 PR 描述，而不是只看 Agent 的解释。
个人工作流的重点不在于把 AI 用满，而是把「提问、规划、执行、验证、回滚」变成一套稳定动作。AI 写代码越快，这套动作越重要。
3. 研究团队工作流
第三层是团队工作流。
个人用 Agent，混乱还可以自己消化。团队用 Agent，混乱会进入 issue、PR、CI、权限、日志、审计和责任边界。
Multica 这类产品值得单独观察。它把 issue、agent、runtime、run、status、comment 这些对象摆出来，也把团队用 Agent 时真正要管的东西摆出来了：任务系统。
这里更值得研究的是一组更具体的问题：
什么任务可以交给 Agent。 什么任务必须先写 spec。 Agent 产出的 PR 谁来 review。 失败日志和历史 run 怎么保留。 哪些权限不能给 Agent。 团队经验如何变成 rules、skills、runbook。
最后拉开差距的，往往是先把个人工作流和团队工作流做成可复用系统的人。
十一、结尾
AI 编程当然有用。
这篇文章不是在主张回到手搓一切的古典时代。那种姿态看起来很清高，其实也很偷懒。
另一种偷懒也一样常见，就是把工具选择当成判断力。
看见新工具就迁移，看见新 Agent 就兴奋，看见「AI 员工」就默认组织要被重写。看起来像在拥抱未来，其实还是被未来叙事牵着走。
AI 编程产品的这些探索，最后都在逼开发者回答同一个问题：
当 AI 越来越能执行，人还保留什么？人手里还得握着这几件事：定义问题，切分任务，审查结果，在工具变强时不急着跪下。
AI 可以提供推力。方向盘还得有人握着。
参考资料
Cursor Docs: Agent mode Cursor Docs: Cloud Agents Windsurf Docs: Cascade Windsurf Docs: Cascade Modes Windsurf Docs: Devin in Windsurf Kiro Docs: Kiro documentation Kiro: About Anthropic Docs: Claude Code overview Anthropic Docs: Claude Code in VS Code OpenAI: Introducing Codex OpenAI Developers: Codex IDE extension OpenAI GitHub: Codex CLI GitHub Docs: Start Copilot coding agent sessions Google Jules: Jules docs OpenCode: opencode Cline: GitHub README Roo Code: GitHub README Continue Docs: Introduction Replit Docs: Replit Agent Lovable Docs: Lovable documentation Bolt.new Docs: Introduction to Bolt Vercel v0 Docs: v0 docs Cognition: Devin Devin Docs: Enterprise quickstart Conductor: Official site Orca: GitHub README Superset: Official site Superconductor: Official site Multica: GitHub README Multica: CLI and Daemon Anthropic: Model Context Protocol Anthropic Docs: Agent Skills overview Warp Docs: Skills as Agents AGENTS.md: Open format for guiding coding agents mattpocock/skills: GitHub README
