夜雨聆风
JetBrains Research 在 2026 年 4 月发了一篇研究文章《Understanding AI’s Impact on Developer Workflows》。这篇文章描述的是开发者在 IDE 里的真实行为，不是主观印象。
研究团队拉了 800 名开发者、两年的 IDE 遥测数据，总计 151,904,543 条行为事件，再配上 62 份问卷和访谈。样本分成两组：400 名 JetBrains AI Assistant 用户，400 名从未使用该助手的开发者。研究覆盖 IntelliJ IDEA、PyCharm、PhpStorm 和 WebStorm。
这篇研究没有把问题说得太虚。它把“用了 AI 之后，开发流程到底哪里变了”拆成五个可以直接观察的指标：输入字符、调试启动、删除与撤销、外部粘贴、IDE 激活。很多原本说不太清的感受，落到这些具体动作上，就清楚多了。
先看研究边界
JetBrains 在原文里说得很清楚，他们看的是行为模式，不是直接证明因果关系；文里用到的也是代理指标，用来识别长期变化的方向。
第一，样本全部来自 JetBrains IDE 和 JetBrains AI Assistant。这个结果更像是在描述一类主流专业开发环境，没法直接替所有编辑器、所有模型、所有团队下结论。
第二，代码质量这里用的是“调试启动次数”这个代理指标。有一定的关联关系，但它毕竟不是代码质量本身。
第三，这篇研究看的是两年里的变化，主要反映开发工作流有没有变；至于一次任务到底能快多少，不在它这次观察范围里。
这三点先记住，后面的数据就更容易看明白。
第一个信号：AI 用户确实写得更多了
先看一个最直观的变化：输入字符数。
JetBrains 的日志数据显示，AI 用户每月平均多增加接近 600 个输入字符，非 AI 用户同期平均增加约 75 个。问卷结果也对得上：超过 80% 的受访者认为，AI 编码工具提升了自己的生产力；超过一半的人觉得编码时间下降了，约 15% 的人觉得编码时间上升。
这和很多人的直觉是一致的。AI 最擅长的，就是先把第一版铺出来。起名、注释、文档、样板代码、重复性逻辑，这些地方最容易看到效果。
第二个信号：删改频率上升得更明显
但更有意思的地方，是写的更多，删得也更多。
AI 用户每月平均多出约 100 次删除行为，非 AI 用户同期只增加约 7 次。这个差值已经足够说明，开发动作的结构变了。
这组数据和很多开发者的体感基本一致。AI 让第一版来得更快，后面的筛选、修订、回滚、重写也跟着变多。JetBrains 在文中还引用了其他研究：最初被接受的代码里，接近五分之一后来会被删除，约 7% 会被大幅重写。
很多人现在的工作状态，其实都差不多：先拿到一个候选答案，再判断哪些能留、哪些要改、哪些干脆重写。
第三个信号：主观上觉得质量更好，调试行为却没有同步下降
代码质量这部分要单独看，因为这里最容易出现一种情况：主观上觉得更好了，效果上却没那么明显。
问卷里，接近一半的受访者认为代码质量有所提升。代码可读性方面，43.5% 的人觉得变好了，6.5% 的人觉得变差了，50% 的人觉得没有变化。
行为日志这边，JetBrains 用“调试启动次数”做代理指标。结果是：AI 用户在这个指标上没有显著变化，非 AI 用户有轻微下降。
这就意味着，大家对 AI 代码的观感偏正面，但真正花在排查和确认上的力气，并没有明显变少。访谈里有一句话很像真实心路历程：哪怕反复检查过，心里还是不太踏实。
这也正常。AI 给答案很快，很多时候看上去也能用，开发者以前要先想怎么写，现在要更常先想这段代码到底能不能留。
第四个信号：代码复用没有出现很大影响
代码复用这项变化没那么大。
JetBrains 看的是“外部粘贴次数”，也就是粘贴进 IDE 的内容，不是来自当前 IDE 会话里复制的内容。AI 用户整体水平更高，说明他们更常引入外部内容，但两组在时间维度上的变化都不大。
这说明，AI 带来的变化不是所有行为都受影响，主要还是集中在生成、删改、验证这几步。
第五个信号：注意力切换没有减少，但是切换模式变了
注意力切换这部分也挺有意思。
很多 AI 工具爱讲“减少注意力切换”，这篇研究给出的信号没那么乐观。AI 用户每月约增加 6 次 IDE 激活，非 AI 用户则每月约减少 7 次。原文的解释也很克制：即便有了 IDE 内 AI，开发者依然在切换注意力，有时还会更多。
说白了，注意力切换行为没有消失，只是换了个样子。
以前的切换常常发生在 IDE、浏览器、文档站、搜索引擎、论坛之间。现在，更多切换发生在生成建议、读建议、改提示、验结果之间。窗口可能少跳了一些，注意力并没有因此变得更完整。
这件事对团队挺重要。很多人会把“工具没有离开 IDE”理解成“注意力切换减少了”，这篇研究并不支持这么乐观的判断。
这项研究说明了什么
把这五个维度放在一起，能看到的变化其实很明确。
AI 确实让代码实现得更快，却也让删改和验证变得更频繁。代码写得更多，返工动作更多，调试压力没有明显下去，注意力切换也没真的消失。开发工作正在从“自己把答案一点点写出来”，变成“先拿到答案，再筛选、修订、确认”。
我读完之后最强烈的感受是，开发者的职责正在从手动编码往判断和负责这边挪。
写代码当然还重要，真正拉开差距的，更主要的下面这三件事：
• • 你能不能快速判断 AI 输出哪些能留
• • 你能不能及时发现隐藏的问题和边界条件
• • 你能不能把候选答案收敛成能上线、能维护、能负责的版本
团队可以怎么自己验证这件事
如果你在团队里推 AI 编码，这篇研究其实很适合拿来当一个参考方向。
做法不用很重，先盯四类数据：
1. 1. 第一版产出速度有没有提高
2. 2. 删除、回滚、重写次数有没有明显上升
3. 3. 调试、测试、回归验证时间有没有下降
4. 4. 任务切换和中断次数有没有变化
如果你的团队手上能拿到 IDE 遥测、代码审查数据、CI 时间、缺陷回流数据，其实就够做一个最小版本的对照观察了。挑两周到四周，对比同类任务在引入 AI 前后的输入、删改、验证、交付表现。
重点不是急着给 AI 打几分，重点是看清楚团队的时间到底花到哪儿去了，是否真正做到了合理提效，是否真正把精力从机械编码转移到了判断和负责上。
最后
我喜欢这篇研究，是因为它没有急着夸 AI，也没有把问题说得很吓人。它做的事其实很朴素，就是把开发者工作流里那些平时不太容易被注意到的变化，老老实实摊在数据里。
接下来再聊 AI 编程，我更想问的是：大家每天到底怎么用，哪些动作变多了，哪些动作没变，哪些地方反而更费劲。
这比一句“提效了没”更接近真实的工程现场。
参考来源
• • JetBrains Research, Understanding AI’s Impact on Developer Workflows
https://blog.jetbrains.com/research/2026/04/ai-impact-developer-workflows/
