🐛 QA 已死（Agent 万岁）：Cursor 的 “Bug Bot” 如何在你睡觉时修复代码

Source: Dev.to

介绍

说实话：作为软件工程师最糟糕的部分不是写代码，而是调试代码。

我们都有过这种经历。用户报告一个 bug：“保存按钮不起作用。” 没有日志，没有复现步骤，也没有截图。你花了好几个小时去尝试重现只在某台特定机器上出现的状态。

如果可以把这种痛苦外包出去呢？

Cursor，这款 AI 驱动的代码编辑器，最近宣布了一个内部工具 Bug Bot。它的目标是自动化调试中最痛苦的环节：复现 bug。

📉 “复现”地狱

在传统开发中，修复一个 bug 大约 10 % 的工作是写代码，90 % 的工作是复现。如果复现不了，就修不好。大型语言模型（LLM）在这方面一直表现不佳——它们可以给出可能的原因，但并不会实际运行代码来验证。

🤖 代理登场：Bug Bot 的工作原理

Cursor 的 Bug Bot 是一个 自主代理，而不是聊天机器人。它既能读取代码 也 能执行代码。其工作流在他们的工程深度解析中有详细描述，主要分为三个阶段。

1. 上下文搜寻（强化版 RAG）

当 bug 报告到达时，Bot 会扫描整个代码库（使用检索增强生成，Retrieval‑Augmented Generation），绘制出与该问题相关的依赖、API 调用以及状态管理逻辑。

2. “科学家”循环（核心特性）

Bot 生成一个 复现脚本——一个小的测试用例（例如 Python 脚本或 Jest 测试），尝试触发 bug。随后运行该脚本：

• 如果脚本失败（未发现 bug）： Bot 分析错误，重写脚本并再次尝试。
• 如果脚本成功（发现 bug）： Bot 将问题标记为 “已复现”。

它会循环迭代，直至能够可靠地复现失败。

3. 修复

一旦得到一个始终失败的可复现测试，LLM 就可以修改源代码，直到测试通过，从而产生修复。

🧠 为什么这是一项“病毒式”技术

Bug Bot 把 生成 与 执行 两者结合起来：

• 眼睛： 它读取仓库。
• 手： 它写文件并运行终端命令。
• 大脑： 它分析自己的输出并调整行为。

这些反馈回路体现了 代理工程（agentic engineering），超越了“写完即忘”的代码生成方式。

🛠️ Bug Bot 的架构

如果你想构建类似系统，高层组件如下：

• 触发器（Trigger）： GitHub Issue、Linear 任务或其他 bug 报告。
• 规划器（Planner）： 决定在代码库中查找位置的 LLM。
• 执行器（Executor）： 一个沙箱环境（例如 Docker 容器），让代理安全地运行测试或脚本。
• 评估器（Evaluator）： 检查终端输出以判断是否成功或需要重试的逻辑。

🚀 对你的工作的意义

手动 QA 并不会消失，但其传统形式已经濒临危机。开发者正从“编写逻辑”转向 设计能够编写逻辑的系统。QA 工程师可能很快会专注于构建和监督执行重复测试任务的代理。

🔮 结论

Bug Bot 为 2026 年的软件开发提供了一瞥。你不再会在早晨醒来看到一条写着“修复此问题”的 Jira 票，而可能收到来自机器人的 Pull Request：

“我已经找到 bug，用这个测试用例复现了它，并提供了修复。请审阅。”

你准备好迎接 AI 同事了吗？

🗣️ 讨论

你会信任 AI 为你关闭 Jira 票吗？在下方评论区分享你的想法！