为什么 AI 使调试变慢 20%

Source: Dev.to

引言

AI 编码助手已经改变了我们的软件编写方式——自动补全、模板生成、重构——让开发速度前所未有地快。
但在调试方面，研究团队发现了一种反直觉的现象：AI 能加快写代码的速度……却会拖慢修复代码的速度。这不是猜测；它出现在 METR、Microsoft Research 和 Google 开发者研究的数据中。解释揭示了调试实际工作方式的根本问题。

METR 研究（2025）

METR 2025 年的研究考察了专业开发者在大型代码库中解决真实 GitHub Issue 的表现。

关键发现

• **编码时间：**下降
• **调试时间：**增加约 20%

为什么会这样？

开发者花了更多时间在：

• 审查 AI 生成的代码
• 追踪看似正确但实际有逻辑错误的代码
• 调试与运行时行为不匹配的修复
• 重构不匹配的模式

METR 引用的示例

// JavaScript
const filtered = items;

代码表面上看很完美，但在 item.data 为 null 的特定情况下会立即报错。关键在于 AI 只能看到静态代码，无法感知运行时实际发生的情况。

Microsoft 研究

Microsoft 对 200 个真实企业 Bug 进行了 AI 工具测试。

额外洞察

• 22% 的 AI 生成修复引入了回归。
• 几乎所有失败都归因于同一个原因：大语言模型从静态文本推断行为，而不是从运行时状态推理。

Google 研究

Google 调查了开发者在调试过程中使用 AI 的方式。大部分时间并不是在修复 Bug，而是在为 AI 重建情境：

• 15% – 解释上下文
• 23% – 在 DevTools 中重现发生的情况
• 18% – 尝试 AI 修复但未成功
• 12% – 回滚错误的补丁

**总体来看：**约 70% 的调试时间用于弥补 AI 缺乏运行时可视性的不足。

运行时 vs. 静态上下文

调试时，开发者依赖于：

• 实际的变量值
• DOM 快照
• 事件序列
• 网络时序
• 组件状态
• UI 崩溃的瞬间

AI 助手通常只能获得：

• 堆栈跟踪
• 单个文件
• 错误信息
• 开发者手动输入的上下文

它们不会获得：

• DOM
• 状态历史
• 渲染顺序
• 未解决的 Promise
• 时序边缘
• 用户输入序列
• 网络条件

调试本质上发生在运行时行为中，而大语言模型工作于静态文本。这种不匹配是悖论的核心。

theORQL 团队视角

我们 theORQL 的工作聚焦于运行时感知的调试，特别是理解为何 AI 在缺少开发者从 DevTools 自动获取的上下文时表现不佳。我们并不是说 AI 在调试上不好；研究显示的更简单的事实是：AI 调试差是因为它看不到实际发生的事情。

一位在 Dev.to 上的前端开发者最近写了篇文章，说明获取运行时上下文后她的调试时间大幅下降（链接到帖子）。这段真实的经验与研究结果高度吻合——可视性是关键因素。

我们的目标是探索能够弥合运行时上下文与编辑器上下文之间鸿沟的工具。我们并不打算取代调试，而是让 AI 拥有人类已经依赖的情境感知能力。

社区提问

• 你是否看到使用 AI 后调试变慢了？
• 在使用 AI 修复 Bug 时，你是否感受到“可视性差距”？
• 对你而言，理想的调试工作流是什么样的？

这个悖论影响所有前端代码编写者。随着调试日益与 AI 交织，社区的观点将决定未来十年工具的形态。