AI 如何悄然改变开发者工作流？我们用长达两年的日志数据做了次验证……
Research @约 11 分钟AI 编码助手早已不是锦上添花的可选配件——它已经是当代开发者日常工作流的标配。已有研究记录了开发者对 AI 工具的短期感受，大量开发者也表示，有了 AI，他们能搞定更多事、少写很多样板代码、不用再在繁琐任务上耗时间。
但长期来看呢？在真实项目中用了一年、两年之后，工作流到底会发生什么变化？开发者自己感受到的那些改变，真的发生了吗？
这些问题，现有研究还没能给出令人信服的答案——已有的研究要么规模有限、要么缺乏深度，长期追踪更是凤毛麟角。
为此，JetBrains 的人机 AI 体验研究团队（HAX）启动了一项规模较大的研究：分析 800 名软件开发者长达两年的 IDE 使用日志，同步开展问卷调查与深度访谈，将客观行为数据与主观感知进行系统比对。
本文是 HAX 团队混合方法研究论文的解读，该论文最近于里约热内卢举行的 ICSE 2026 大会上正式发表。
研究的核心发现是：AI 在悄悄重新分配和重塑开发者的工作流——而开发者自己，往往没有意识到这一点。
本文将依次介绍：
• 研究方法（两年日志数据 + 调查访谈） • 开发者工作流的五个关键维度及相关背景 • 混合方法研究的具体发现
我们怎么研究的？
两套方法，互为补充
这项研究同时采用了两种方式：看行为（日志数据）和听感知（问卷 + 访谈）。
为什么要两手抓？因为各有盲区：日志能告诉你行为在变，却说不清楚为什么变；主观反馈能解释动机和情境，但容易受偏见影响，往往捕捉不到细微的行为变化。两者结合，才能发现"感受"与"实际"之间的落差，更立体地还原 AI 重塑开发日常的全貌。
遥测数据：IDE 里的"行为黑匣子"
遥测（Telemetry）是一种成熟的远程数据采集方法，早在 19 世纪就已投入使用。这个词源自希腊语，tele 意为"远"，metron 意为"测量"。
在我们的研究中，遥测是指 IDE 在开发者工作时自动记录的一系列细粒度、匿名化事件——开发者做了什么操作、什么时候做的、按什么顺序做的。具体包括：输入的字符数（只记录数量，不记录内容）、调试会话启动次数、代码删除与撤销次数、外部内容粘贴次数、窗口焦点切换次数等。如果你想了解更多，可以查看 JetBrains 产品数据收集和使用声明。
遥测数据的价值已被前人验证。比如，有研究者通过遥测数据发现，开发者有多达 70% 的时间花在了"理解代码"上——阅读、导航和审查源代码——而非动手写代码。
日志数据：追踪 800 人两年的真实行为
本研究的遥测数据来自 IntelliJ IDEA、PyCharm、PhpStorm、WebStorm 等多款 JetBrains IDE 的匿名使用日志。我们筛选出在 2022 年 10 月和 2024 年 10 月均活跃的设备，确保可以对同一批开发者进行完整的两年跟踪。
起始时间选在 2022 年 10 月，是因为 ChatGPT 正是在那时首次亮相。
在此基础上，我们构建了两组对比样本：
• AI 用户组（400 人）：2024 年 4 月至 10 月间，每月至少使用过一次 JetBrains AI Assistant • 非 AI 用户组（400 人）：在整个研究期间从未使用过 AI 助手
选择 2024 年 4 月作为判断节点，是因为那时 AI 助手在 IDE 中已趋于成熟稳定，我们也希望确认 AI 用户是真正将其纳入了日常工作流，而非偶尔尝鲜。
从日志中，我们提取了五类具体事件作为五个工作流维度的行为指标：
1. 输入字符数 → 工作效率 2. 调试会话启动次数 → 代码质量 3. 删除与撤销操作次数 → 代码编辑 4. 外部粘贴次数（非来自 IDE 内复制）→ 代码重用 5. IDE 窗口激活次数 → 上下文切换
整个数据集共包含 800 名开发者产生的超过 1.5 亿条日志事件。
当然，任何代理指标都有局限性，这些指标也不例外。我们的目标是识别工作流的变化趋势，而非推断因果关系。
问卷与访谈：开发者自己怎么说？
为了与行为数据形成对照，研究团队还面向专业开发者开展了一项在线问卷，围绕同样的五个工作流维度设计题目，共有 62 名开发者完成了调查。
问卷结构包括：
1. 量表题：整体使用体验与对 AI 工具的依赖程度（5 分制） 2. 维度量表题：针对各工作流维度的主观感知变化（1 = 显著降低，5 = 显著提升） 3. 开放题：列举一个 AI 工具对工作流影响的具体例子
问卷完成后，研究团队邀请部分参与者进行了简短的半结构化访谈，深入探讨他们日常使用 AI 的真实情况：什么时候会用 AI、如何判断是否信任某条建议、工作是否变得更碎片化了。
这些定性访谈帮助我们"读懂"遥测曲线背后的故事——比如，为什么有人的日志显示输入量、删除量和外部粘贴量都发生了明显变化，他们自己却说"感觉没什么不同"。
我们关注的五个维度
研究将开发者工作流拆解为五个维度，每一个都对应一个关于"AI 到底改变了什么"的核心问题。
1. 工作效率
这是大家问得最多的问题：AI 能让开发者干得更快、做得更多吗？
听起来答案显而易见，但研究结论其实相当复杂。已有大量针对 LLM 编码工具的生产效率研究，却没有形成一致结论。更耐人寻味的是，一项研究发现，开发者认为用了 Copilot 之后效率变高了，但实际数据并不支持这个判断。另一项研究同样发现：开发者估计自己处理代码仓库问题的速度提升了 20%，但实际数据显示他们完成任务的速度反而慢了 19%。
在本研究中，我们用输入字符数来衡量代码产出量。
2. 代码质量
关注点从"写了多少代码"转向"代码写得怎么样"。
我们没有直接分析代码内容，而是把调试会话启动频率作为行为信号——它反映了开发者需要"步进排查"程序的频率，是遇到问题或产生不确定感的间接体现。
有研究发现，开发者会花超过三分之一的时间来复查和修改 Copilot 的建议代码——这说明 AI 生成的代码并不能直接信任。
3. 代码编辑
初稿写完之后发生了什么？开发者是在接受 AI 建议、还是在大量改写它？
我们用删除与撤销操作次数来衡量编辑强度，这反映了 AI 辅助编程中不可忽视的"筛选"成本。
一项研究发现，AI 最初生成并被接受的代码中，近五分之一最终被删除，约 7% 被大幅重写——AI 生成代码并不意味着代码可以直接留用。
4. 代码重用
开发者历来都会重用代码——从库、Stack Overflow、内部代码片段。AI 助手带来了一个新的、往往不够透明的"外部代码入口"。
我们用非 IDE 内复制来源的粘贴操作来捕捉这种行为，探究代码来源的整体结构是否因 AI 的引入而发生了变化。
5. 上下文切换
现代开发本就是在 IDE、浏览器、终端和各种沟通工具之间反复横跳。集成在 IDE 内的 AI 助手，真的能让开发者减少"出戏"、保持专注吗？
我们用IDE 窗口激活次数（即从其他窗口切回 IDE 的次数）来量化这种注意力游走行为。
有研究指出，与 AI 助手交互本身就会带来认知开销——开发者需要在写代码、看建议、和 AI "对话"之间不断切换。这些工具到底是在减少打断，还是换了一种打断方式？
研究结果
“
行为数据与主观感知，谁更接近真相？
下表是五个维度的结果概览。
工作效率：感知与数据，罕见一致
在这个维度，日志数据和问卷结果难得地指向了同一个方向：用了 AI，开发者真的写了更多代码。
从图中可以看出，AI 用户的月均输入字符数持续多于非 AI 用户，且差距在两年间不断扩大。具体来看，AI 用户每月输入字符数增加了约 600 个，而非 AI 用户仅增加约 75 个。这不是短暂的热情，而是持续的行为转变。
问卷数据同样印证了这一趋势：超过 80% 的受访者表示 AI 工具在一定程度上提升了他们的工作效率；超过半数的人说自己在编码上花的时间减少了。
访谈中，开发者的描述更加直接。一位有 3 至 5 年经验的开发者说：
在命名或写文档上卡壳的时候，我会立刻去问 AI，它真的帮了很大的忙。
小结： 在工作效率这个维度，行为数据和主观感知高度吻合——用了 AI，代码产出确实在增加。
代码质量：感觉好多了，但行为没变
这个维度出现了第一个有趣的分叉：开发者觉得代码质量变好了，但实际调试行为并没有显著变化。
从日志数据看，AI 用户和非 AI 用户的调试会话启动次数相差不大，两年间也没有明显变化趋势——统计上不显著。非 AI 用户的调试次数甚至略有下降。
但在问卷中，近半数受访者表示 AI 工具让他们的代码质量有所提升，43.5% 的人认为可读性也变好了，只有约 10% 认为质量有所下降。
这种"感觉好，但行为没变"的现象也许可以从访谈中找到线索。一位有 3 至 5 年经验的开发者说：
我会反复检查 AI 生成的代码，即便如此，我还是觉得有点不踏实。
小结： 开发者主观上感知到代码质量提升，但从调试行为这一客观指标来看，AI 用户并没有发生显著变化。感觉与行为，在这里出现了分离。
代码编辑：数据大幅跳升，开发者却没察觉
这是五个维度中感知与行为差距最悬殊的一个，也是最值得深思的发现之一。
日志数据显示，AI 用户的月均删除与撤销次数比非 AI 用户高出显著一截——每月约增加 100 次，而非 AI 用户同期仅增加约 7 次。换句话说，引入 AI 之后，开发者在"改"和"删"这件事上的工作量明显变大了。
但问卷里，受访者怎么说的？半数人表示没有感觉到任何变化，约 40% 说变化不大，只有少数人认为变化很明显。
访谈中，一位有 15 年以上经验的系统架构师用了个很有意思的比喻：
AI 就像另一双眼睛，提供结对编程的价值，却没有社交压力——对神经多样群体尤其友好。它不会全程盯着你，但需要代码审查和反馈的时候，随叫随到。
小结： 数据显示，使用 AI 助手后，开发者的代码编辑和删改量大幅增加；但开发者自己几乎没有察觉到这种变化。这是本研究最显著的"感知盲区"之一。
代码重用：预期中的变化没有出现
在这个维度，AI 用户和非 AI 用户之间的差距相对较小，主观感知和客观行为之间的分歧也不算明显——总体上是"变化不大"。
从日志来看，AI 用户的外部粘贴次数整体略高于非 AI 用户，但两组人在两年间均没有明显的趋势性变化。
问卷里，约三分之一的人说外部代码使用频率有所增加，约五分之一说有所减少，44% 的人认为没有变化——结论相当分散。
这个结果有点出乎意料。按理说，有了 AI 提供的代码建议，开发者应该更多地"借用"外部代码才对。但现实并非如此。访谈中，一位有 15 年以上经验的开发者给出了他的解释：
对我来说，最好是为自己写的东西负责，而不是去采用别人的方案。
小结： AI 在代码重用这个维度的影响并不显著，预期中的大幅变化没有发生，开发者对自己代码来源的把控意识依然较强。
上下文切换：AI 在 IDE 里，但注意力还在到处跑
"有了 AI，就不用老是跑去 Google 了"——这是很多 AI 工具宣传的核心卖点之一。但数据给出了一个更复杂的答案。
从日志来看，AI 用户的 IDE 激活次数整体高于非 AI 用户，且在两年间还在缓慢增加——每月约增加 6 次。非 AI 用户则呈现相反趋势，每月减少约 7 次。
也就是说，用了 AI 的开发者，上下文切换的次数并没有减少，甚至比不用 AI 的人还要多。
问卷结果比较分散：约四分之一的人说切换次数增加了，约五分之一说减少了，约半数说没变化。
访谈中，一位开发者的描述听起来很像"好转了"：
我不再频繁切换了，以前每次要去 Google 的事情，现在几秒钟就能解决。
但客观数据告诉我们，这很可能只是一种感知偏差。AI 也许把"去浏览器查资料"这种切换替换成了"在 IDE 里和 AI 对话"的切换——打断的形式变了，但打断本身并没有消失。
小结： 集成 AI 并没有让开发者减少上下文切换；相反，日志数据显示 AI 用户的切换频率还在增加。AI 可能只是改变了切换的形式，而非消除了切换本身。
核心洞察
“
AI 改变了开发者，开发者却没意识到。
把五个维度放在一起看，这项研究传递出一个清晰的信号：
AI 编码助手正在悄悄重塑开发者的工作方式，但这些变化很多都发生在开发者的感知之外。
代码产出在增加，删改量也在大幅上升——但开发者自己往往没意识到自己"改"了多少东西；上下文切换的频率并没有降低，但开发者感觉自己"更专注"了。这种感知与行为之间的落差，正是仅靠问卷或访谈无法发现的东西。
这也是本研究方法论上的核心价值所在：只有把遥测数据和定性调研结合起来，才能同时看到"发生了什么"和"为什么这么发生"。
对正在构建或推广 AI 工具的团队，我们有一个简单的建议：不要只问用户喜不喜欢这些工具——去看看他们实际在做什么。
💡 写在最后
这项研究的数据采集于 2022 至 2024 年间——彼时 AI 编码助手的主要形态还是"补全建议"和"对话问答"。而现在，故事已经翻篇了。
从 Cursor、Windsurf 到 Claude Code、Codex、Junie、Air……，AI 不再只是在你旁边给建议，而是开始独立拆解任务、跨文件修改代码，甚至跑完整条开发链路。
这让这项研究的结论变得更值得警惕：如果在"AI 只是帮你补代码"的阶段，开发者已经对自己行为的变化浑然不觉——那在智能体时代，这种感知盲区只会更大，不会更小。
你现在的开发日常是什么样的？AI 有没有改变你的工作方式——或者，改变了你自己都没发现？
欢迎在评论区聊聊。
更多阅读推荐
产品动态
“非商用免费” IDE 家族
申请免费学生许可证
👉 戳这里看保姆级申请攻略 👈