什么是 AI 调试？

1947 年 9 月 9 日，哈佛 Mark II 计算机的工程师在一个继电器中发现了一只蛾子，并将其粘贴在日志中，记录为“首次发现真正的 bug（错误）案例”。该日志页面如今收藏于史密森学会。¹Mark II 团队的计算机科学家 Grace Hopper 推广了这一故事，不过“bug”这一术语早在她之前便已存在：Thomas Edison 曾在 1878 年的一封信中提到“bug”，而《牛津英语词典》将该工程术语的使用追溯至 19 世纪 70 年代和 80 年代。²

软件工程中的错误 (bug) 通常分为三类。³语法错误违反编程语言的语法规则（例如缺少括号），通常会在程序运行前被检测出来。运行时错误发生在代码本身有效但执行过程中失败的情况下，例如执行除以零的操作。逻辑错误最为隐蔽：程序可以正常运行，却产生错误结果。

开发人员可以通过自动化测试（例如用于验证每个代码单元是否符合预期结果的单元测试），以及可暂停程序运行以便检查的调试器来排查问题。断点——即程序暂停执行的位置——允许开发人员逐步执行代码并检查变量；Python 内置的 pdb 就是典型示例。程序发生崩溃时，通常会生成堆栈跟踪，其中记录了导致错误发生的函数调用路径。⁴

剑桥贾奇商学院 2013 年的一项研究估计，开发人员平均将一半的编程时间用于查找和修复错误，全球每年因此产生约 3120 亿美元的成本。⁵当然，AI 辅助调试的目标正是降低这一成本。

LLM 是一种通过海量文本和代码训练的机器学习系统，用于预测下一个“词元”（单词、词片段或符号）。它采用的正是 ChatGPT、Claude 等 AI 聊天机器人背后的自然语言处理技术。在训练过程中，LLM 实际上“阅读”了数十亿行公开代码，以及与之相关的错误消息、错误报告和修复方案。当 LLM 推向市场时，它很可能已经接触过数百万个错误，并学习了相应的解决方法。 

有文档记录的开放代码训练数据包括 GitHub 上的 “问题” 和 “拉取请求” 对话——即开发者报告错误和提交修复方案的记录——使经过专门训练的模型能够获取一份完整的过程记录，了解人类开发者如何修复存在问题的代码。

在常见的 AI 调试流程中，开发人员会向模型提供相关代码以及错误消息或堆栈跟踪信息；模型随后分析可能原因，并提出可选的修复方案。ChatDBG 等研究系统则更进一步，将 LLM 与 GDB、LLDB 以及 Python 的 pdb 等标准调试器连接，使开发人员能够用自然语言提出“为什么 x 为空？”之类的问题，同时由模型检查运行中的程序、执行根因分析并提出修复建议。6.

初次接触 AI 调试的用户需要了解其中的一些局限性。首先，上下文至关重要——这也是提示工程中的一项关键实践。模糊的提示往往会导致模糊的诊断结果；更有效的方法是提供准确的错误信息、失败的测试以及相关的可疑代码片段。用户还需要了解模型的上下文窗口，即模型一次能够处理的最大文本量（以“词元”衡量，即由若干字符组成的信息单元）。正如针对真实 GitHub 问题的 SWE-bench 基准测试所显示的那样，复杂代码库中的实际错误往往涉及多个文件；如果模型的上下文窗口无法容纳所有相关代码，就可能难以进行有效推理。

AI 调试通常通过嵌入开发人员编码工作区，或围绕该工作区构建的 AI 编码助手实现，而该工作区通常就是集成开发环境 (IDE)。例如，GitHub Copilot 是一款可在主流 IDE 中提供代码建议的编码助手；Cursor 和 Windsurf 则是面向 AI 的编码工作区，将类似的辅助能力置于编程体验的核心位置。⁷随着“智能体工程”的兴起逐渐成为趋势，一些软件开始将编码助手的聊天窗口设计为用户与 IDE 交互的主要界面；IBM Bob 等工具便采用了这种交互方式。

编程助手通常与具体模型无关。例如，GitHub Copilot 可以使用包括 OpenAI、Anthropic 和 Google 在内的多家提供商的模型；xAI 也表示，其 Grok Code Fast 1 模型专为编码智能体工作流打造，可通过 Copilot、Cursor 和 Windsurf 等工具使用。^{8 9}另一方面，IBM Bob 支持多种模型，并会根据查询的复杂度和成本自动将请求路由至合适的模型；2026 年发布资料提到，其采用“包括 Anthropic Claude、Mistral 开源模型和 IBM Granite 在内的多种前沿模型，以及用于代码推理、安全分析和下一步编辑预测的专用微调模型组合”。

一些 AI 调试智能体属于通用型工具，另一些则专注于特定领域。在通用型工具方面，GitHub 于 2025 年推出的 Copilot 编码代理可以接收 GitHub issue 分配，在后台通过 GitHub Actions 执行任务，并将建议的修改作为拉取请求（供开发人员审核的一组代码变更）提交。¹⁰凭借其多模型组合，IBM Bob 同样更偏向通用型智能体。在专业型工具方面，则有专门针对安全漏洞的 Copilot Autofix。它通过将 GitHub 的代码扫描引擎 CodeQL 与 AI 生成的问题解释和修复建议结合，实现漏洞检测与修复辅助。节省的时间十分可观；GitHub 表示，自动修复的中位耗时为 28 分钟，而人工修复平均需要 1.5 小时。¹¹

尽管表现令人瞩目，但生成式 AI 前沿领域的成果仍存在差异。IBM 最近针对 2,000 名首席执行官开展的 CEO 研究发现，近年来仅有 25% 的 AI 项目实现了预期投资回报。

AI 调试领域同样呈现出类似的复杂情况。在 2024 年 DebugBench 研究中，研究人员发现，闭源模型整体表现仍未达到人类水平，而且逻辑错误相比语法错误和引用错误更难修复。¹²

不过，更先进、更专业化的工具正在改善这一前景。例如，ChatDBG 可将 LLM 连接至实时调试器，使其能够观察程序发生故障时的实际运行状态，而不仅仅分析可疑代码文本。在一项评估中，单次 ChatDBG 查询为 Python 程序提供可执行修复方案的比例达到 67%；如果允许提出一个后续问题，该比例则提升至 85%。¹³

更复杂的是，用于评估模型的标准也在持续变化。作为著名 SWE-bench ¹⁴的更高难度后继版本，SWE-bench Pro 旨在提供更真实、更抗数据污染的评测环境；在最近一次评估中，表现最佳的前沿模型得分仍低于 25%，其中 GPT-5 为 23.3%。¹⁵  

开发者行为的变化速度可能已经超过了科学测量能够准确捕捉的范围。METR 在 2025 年初进行的一项随机对照试验发现，经验丰富的开源开发者在使用 AI 工具时，完成任务反而多花了 19% 的时间；但 METR 很快指出这一结果已经过时。2026 年的一项后续研究则发现了一定的生产力加速证据，不过同时也指出这种加速效应很难被精确测量。¹⁶METR 对这一测量困难的解释很能说明问题：“我们观察到，越来越多的开发者选择不参与该研究，因为他们不愿意在没有 AI 辅助的情况下工作，这很可能导致我们对 AI 辅助带来的速度提升估计值偏低。” 

AI 辅助开发和调试显然将长期存在。但目前来看，AI 调试工具更适合作为强大的辅助工具，而非完全可靠的自动驾驶系统。它们可以解释堆栈跟踪信息、发现语法错误，并快速生成候选修复补丁。但对于最复杂的问题——例如逻辑错误、复杂代码库以及安全敏感代码——仍需要测试、断点调试，以及经验丰富的开发人员在将修复合并到代码库前进行审核。