指南指南 · 自主工程开发

根据错误报告自动草拟拉取请求的 AI

作者: Doğan Turan,联合创始人,Qualia8 min read

简而言之。 当生产环境触发错误时(Sentry、Rollbar、日志聚合器),大多数团队只能手动排查:阅读堆栈追踪、查找对应文件、理解上下文、编写修复代码、创建 PR。而一个 AI 员工 能全自动完成这一切,直接呈上可供审查的 PR 而不是一条报警通知,从而大幅削减积压的 Bug。在 2026 年,有三种方案可实现这一点:Qualia(覆盖整个产品组合,一个 AI 员工贯穿所有产品)、 Viktor (作为其工程师角色的一部分),以及基于 Cursor 或 Claude Code 加上自定义自动化的自建方案。

你真正付费的工作流。

2026 年的手动 Bug 排查流程是这样的:

  1. Sentry 触发告警。
  2. 有人收到通知(非工作时间则要等到第二天早上)。
  3. 工程师打开 Sentry,阅读堆栈追踪,打开代码库。
  4. 阅读周边代码以理解具体情况。
  5. 如果修复方法显而易见,直接编写修复代码。
  6. 如果并非如此,打开 Slack 查找最后修改该文件的人。
  7. 附带上下文创建 PR。
  8. 合并。

最好情况:每个错误 30 分钟。对于多项目组合运营者的现实情况:每个错误 2 小时,因为"打开代码库"需要重新加载你数周未曾查看的产品上下文。

对于每天产生数十个错误的 15 款产品来说,这相当于一个全职岗位。否则,积压任务就会每周与日俱增。

AI 员工取而代之的做法。

  1. Sentry 触发告警。
  2. AI 员工会阅读告警、堆栈追踪、周边代码、git blame、近期提交记录以及 Slack 上下文。
  3. 判定:是真正的 Bug 还是噪音?(过滤不稳定的测试、第三方 API 抖动、已知重复项。)
  4. 如果确实是 Bug:起草修复方案,针对正确的分支创建 PR,在 PR 描述中添加上下文,并标记审查者。
  5. 工程师进行审查(通常仅 5 到 20 行代码),批准或修改。
  6. 合并。

节省时间:简单修复节省 90%,复杂修复节省 60%。

在多项目组合规模下,这就是"我们有专门的 Bug 分流处理"与"修复一出现我们就立即交付"之间的差距。参见 自主化运营 了解更广泛的模式。

评估 PR 起草 AI 时需要关注的要素。

  • 1. 阅读实际代码,而非仅看报错信息。 仅查看错误消息的产品往往会产生幻觉修复。
  • 2. 读取 git 历史记录。 最后是谁修改了这个文件?不了解 git 的产品很容易重新引入已修复的 bug。
  • 3. 遵循团队的 PR 规范模式。 描述清晰的提交信息,并在需要时附带测试。
  • 4. 过滤噪音。 并非每次警报都是真实的 Bug。
  • 5. 具备产品组合全局视野,而非仅限于单一代码库。 对于单一产品,任何编程 AI(Cursor、Claude Code、Codex)均可胜任。但对于包含 5 个以上产品的组合,AI 必须清楚具体涉及哪个产品、哪个代码库、哪个团队。
  • 6. 从容应对误报 PR。 关闭错误的 PR 应仅需一键。

2026 年实现这一能力的产品。

Qualia

覆盖整个产品组合的 AI 队友。读取所有产品中的 Sentry 警报,并针对正确的代码库起草 PR。专为运营 3 到 20 款产品的 2 至 10 人团队打造。

Viktor

属于其"工程师" AI 员工角色的一部分。最适合希望每个团队都拥有一位专属指定 AI 工程师的团队。不适用于多项目组合范畴。参见 Qualia 对比 Viktor.

Cursor / Claude Code 加自定义自动化

自行搭建方案。如果您有足够的工程时间来构建,此方案可行。

Sentry AI Autofix

Sentry 自身的测试版。仅限于 Sentry,并与其产品路线图绑定。

GitHub Copilot Workspace

适合提供修复建议;需要人工触发。不具备自主性。

Devin / Cognition

通用自主编程智能体。对于大多数 PR 起草工作流而言有些大材小用。

在做出承诺前如何进行评估。

  • 步骤 1。 从过去 30 天中挑选 10 个真实的 Sentry 错误,兼顾简单与复杂问题。
  • 步骤 2。 将每个错误输入给 AI 队友,让其起草 PR。
  • 步骤 3。 评估每个 PR:正确性、完整性、代码规范、上下文理解。
  • 步骤 4。 横向对比不同产品。一个能正确解决 10 个中的 8 个且能体面处理其余 2 个的产品,远胜过在简单错误上拿到 10/10 却在复杂问题上产生幻觉的产品。

常见误区。

  • 未设置审查关卡就直接部署。 切勿让 AI 起草的 PR 自动合并。
  • 未将 AI 连接至 Git 历史记录。 仅能看到错误信息的 AI 会重新引入已被修复的 Bug。
  • 过滤规则过于严苛。 "只处理真正的 Bug"会遗漏边缘情况。"全部处理"又全是噪音。建议迭代测试 2 周。
  • 误以为单仓库级产品具备跨产品组合的视野。 单代码库工具(Cursor、Copilot)无法原生处理"哪个产品、哪个代码库"。

继续阅读。

常见问题。

针对高频问题的简要解答。如有其他疑问,可在列表底部咨询团队。

  • 对于简单修复(空值检查、类型强制转换、缺失导入),答案是肯定的。对于复杂修复,AI 应当标记不确定性,而不是自信地给出错误修复。

  • 可以。大多数组合管理者使用 Cursor 进行交互式编码,使用 AI 队友进行自主分类处理。

  • 配置过滤规则,使其仅在超过设定阈值时触发。每周进行迭代调优。

  • 不会。它替代的是工程师用于问题分流的时间。

  • 按产品组合定价的产品将此作为其中一项能力包含在内。专用的 Bug 修复产品则按次或按代码仓库计费。

  • 单仓库工具可能就足够了。拥有 3 个以上产品时,产品组合维度的管理才真正显现价值。

  • 几天内即可提交首批 PR。几周完成过滤器校准。几个月内,反馈闭环将使其在分流排查上持续优于中级工程师。

有想要解决的问题?

包在我们身上。

预约演示