摘要：JetBrains 调查 1.5 万名开发者：90% 每周用 AI agent，Claude Code 涨到 39%，Copilot 跌到 21%。涨的能离开 IDE 独立跑，跌的住在编辑器里。分水岭不在界面，在交互单位。
回想一下你最近一次让 AI 真正干完一件活。
不是补全半行代码，而是"把这个接口的超时配置改掉，跑一遍健康检查再提交"这种。
这句话，你是在哪个窗口里说的？
大概率不是 IDE 里那个侧边栏。
JetBrains 八月中旬发了份调查1，数据来自第十届开发者生态调查。
覆盖 1.5 万多名专业开发者，采样时间是今年 5 到 7 月。
数字比想象中激进。
排名不是重排，是反转
90% 的专业开发者每周至少用一次 AI agent，68% 每天用。
这一层已经不算新闻。真正扎眼的是再往下一层的排名。
Claude Code 的工作场景使用率从 1 月的 18% 涨到 39%，美国到 47%。
GitHub Copilot 从一年前的 29% 跌到 21%。它仍然是心智占有率最高的工具，79% 的人知道它，欧美能到 86% 到 90%。知道，但不用了。
Codex 从 3% 涨到 16%，五倍。同期它的认知度从 27% 涨到 65%。
Cursor 拿到了更多心智，从 69% 升到 75%，使用率却从 18% 掉到 12%。掉得最狠的是中国市场：1 月还有 28%，5 到 7 月只剩 16%。
至少在前排，规律几乎是明牌。
涨的是 Claude Code、Codex、OpenCode，三个都能不靠 IDE 独立跑，终端是它们最自然的落点。
跌的是 Copilot 和 Cursor，两个都把家安在编辑器里。
更值得琢磨的是粘性。31% 的开发者把 Claude Code 列为自己最常用的工具。
对比 39% 的总使用率，这意味着一件事：试过的人里，大约八成把它留成了主力。
工具类产品很少见到这种转化率。多数人是装一堆、用几个、留一个。
先说清这份数据的边界。它统计的是"用没用"，不是"用得好不好"，也不看营收。
样本是专业开发者，不等于所有写代码的人。而且这份让 IDE 显得被动的数据，是一家卖 IDE 的公司自己发的。
不是终端更好用，是单位变了
一个偷懒的解释是：终端更快、更轻、更自由。
这个解释站不住。
之前写过终端里的 agent 为什么"顺手"------工作本来就在终端发生，没有序列化边界，文本还能脚本化和审计。那是体验层的解释。
但体验层的解释撑不起这份数据。终端再顺手，也只对本来就熟命令行的人成立。
而使用率翻倍的不是小圈子的偏好，是主流开发者的选择。
真正变的是交互的单位。
补全的单位是一段代码片段。你把光标停在某个位置，它把接下来的几个词补齐。单位小到以行计。
你决定改哪里、改成什么样，它负责把那几个字打得更快。
在这个模式里，瓶颈是打字速度和一次改对的概率。编辑器把这个瓶颈压得越狠，你就越离不开它，这是 IDE 插件范式的全部价值。
Agent 的单位是一个完整意图。你说清要什么结果，它自己读文件、拆步骤、改多个文件、跑测试，最后交给你一个可验收的东西。
单位大到以"一件事"计。你的角色也跟着变了，从"写"变成"验收"。
bash
# 单位是片段：你决定改哪里，它补下一行
orderList.stream() # 光标停在这，它接 .map(o -> o.getId())...
# 单位是意图：你说清结果，它负责怎么改
claude "把 OrderService 里的 new Date() 换成注入的 Clock，改完跑订单模块测试"单位一变，编辑器最值钱的那个能力就不再是瓶颈。
补全这件事已经商品化了。今天几乎每家做模型的厂商都拿得出来，行内补全、多行补全、FIM，都是标配。
JetBrains 自家的 AI 在调查里只有 9% 的使用率。这个数字不足以为它的产品力下结论，但至少说明一件事：光靠补全，撑不起一个工具的份额。
而当单位变成"一件事"，问题就从"下一行写什么"，变成了"它有没有理解对整套上下文、有没有真的验证过"。
回答后一个问题，靠的是执行和验证的环境，不是输入的界面。
终端恰好天生就有这些原语：git、构建、测试、日志、管道，本来就在那儿。
所以它不是"因为好用"赢的，是"因为对了口"。终端只是第一个接得住"完整意图"这个单位的容器。
编辑器没出局，它被分到了后半场
这份数据里最微妙的一条，藏在一个不起眼的位置：39% 的 Copilot 用户，是在 JetBrains 的 IDE 里用它。
编辑器还在被用，只是它承载的是别人的 agent。
JetBrains 的应对很直接。Claude Agent、Codex、Copilot、OpenCode 被接进了 IDE 的 AI 对话。
其他 agent（包括 Cursor）通过 ACP 协议接入2。
它还在做一个叫 Air 的东西，agentic 开发环境，目前是预览版。
一家卖 IDE 的公司把对手的 agent 请进自己的界面，与其说这是开放，不如说是个信号：靠"代码在这里写"留人，已经不成立了。
那它靠什么？靠前后两头里它本来就更强的那一头。
把一次改动切成两段：生成，和验收。
生成这半正在往终端走，因为那边有现成的执行环境，改完能立刻跑。
验收这半留在编辑器里更划算。看 diff、跳调用链、断点调试、看堆栈、盯性能曲线，这些是几十年的编辑器积累，终端给不了。
有个场景印象很深。有次让终端里的 agent 顺手改一批调用点，回头一看改动散在十几个文件里。
git diff 在黑框里刷屏刷到翻不动，最后是回 IDE 打开对比视图，才看清哪几处改歪了。
生成交给终端，验收回编辑器。这不是谁替代谁，是分工被重新划了一遍。
那 90% 里，有多少是真在用
数据的另一面得说清楚。
90% 的周活听着像普及完成。但"每周用一次"和"把关键任务交给它"是两件事。
68% 的日活里，相当一部分人只是拿它解释报错、查一段老代码。这已经很有用，但和"让它改生产代码"是两种信任级别。
把执行权交给终端 agent，代价也更直接。
补全式的工具最多给你一段跑不起来的代码；终端 agent 直接落盘、直接跑命令、直接提 PR。权限开多大、哪些操作要卡住，这些闸门得自己搭。
所以这份调查真正说明的，不是"终端更好"，是重心挪了位置：从"谁帮我把代码写快"，挪到了"谁能接住一整件事，并且让我验得动"。
开头那个问题，答案其实不重要。
重要的是那句话的单位。当你说出口的不再是"下一行写什么"，而是一整件事，你需要的就不再是一个更好的输入框。
你需要一套能把它的产出验干净的流程。
终端赢的是这一件事。编辑器输的也不是界面，是"代码在你这里写"这个默认位置。
它要证明自己值钱的地方，换到了别处。
作者：唐悦玮 | 从后端出发，用 AI 拓展到全栈的工程师。