← 返回博客
Bug Reports Should Fix Themselves: Dogfooding Our Slack Cloud Agent with GitHub and Linear

Bug 报告应自行修复：通过 GitHub 和 Linear 对我们的 Slack 云代理进行内部测试

BekahHW2025年12月15日 · 4分钟阅读

当你正处于专注状态时，Slack 突然弹出一个你“必须”修复的通知，这种体验是非常痛苦的。Continue 的云智能体可以将 Slack 对话转化为 GitHub Pull Request。

通过 Continue 的 Mission Control 集成连接 Slack 和 GitHub，开发者无需离开他们现有的工作工具，即可修复 Bug、解决安全问题并发布更改。

也许是一个错误报告、新页面上的 404，或者某个端点中的逻辑错误。当然，这些都很重要，但它们是一种干扰。通常，工作流看起来是这样的：

  • 阅读 Slack 消息
  • 叹气
  • 打开 Jira 或 Linear 并创建一个工单
  • 打开 IDE，暂存当前工作，并切换到一个新分支
  • 复现 Bug
  • 修复它
  • 推送提交、打开 PR，然后切换回原来的上下文

那个所谓的“快速修复”让你损失了 45 分钟的心流时间。

在 Continue，我们正在构建一个世界，让你的工具与 Continue 对话，并由 Continue 云智能体采取行动——请参阅我们的何时使用云智能体指南以了解更多信息。

我们坚信，如果你能在 Slack 中描述修复方案，就不应该为了实现它而离开 Slack。

以下是我们如何利用自身的 Slack 集成，在不离开对话的情况下将错误报告转化为 Pull Request。

“顺手”修复：将 Slack 错误报告转化为 Pull Request

有时，修复方法显而易见，但实现它的阻力很大。与打开 Pull Request 的同一个 Slack 智能体，还可以创建和更新 Linear 工单、指派负责人、更改状态，并跨系统链接工作任务。

最近，我们的团队发现了一个 Bug：收件箱列表视图因为默认选中了错误的标签页而显示为空。我发布了该问题的屏幕录制。

Nate 准确地知道问题出在哪里。在传统的工作流中，Nate 不得不停止手中的工作，去修复 InboxPageClient.tsx 中的默认状态。

但实际上，对话是这样进行的：

Continue

  • 查看所选仓库： continuedev/remote-config-server
  • 操作： 创建了工单 CON-5031。
  • 操作： 将默认预设从 "review" 修改为 "all"。
  • 结果： GitHub PR 已创建。

Nate 没有打开 IDE，也没有暂存更改。他将实现工作委托给了云智能体，然后继续做别的事。几分钟后，修复已部署完成。

Slack 到修复的工作流是如何运作的

  1. 触发： 团队成员报告 Bug 或在 Slack 线程中标记 @Continue。
  2. 分类： 云智能体分析对话历史以理解复现步骤。
  3. 上下文： 智能体连接到 GitHub 以定位相关文件。
  4. 操作： 智能体在新分支中生成修复方案，并自动打开 Pull Request。

将 Slack 作为 Linear 的控制平面

能创建 Pull Request 的同一个 Slack 智能体也可以直接与 Linear 协作。我曾通过一条 Slack 消息，要求 Continue 更新分配给我的 Linear 工单、更改状态并留下评论。我没有打开 Linear，没有搜索工单，也没有切换上下文。

在后台，Slack 智能体执行了该请求。

Slack 智能体通过 Linear MCP 完成的操作：

  • 根据名称和指派人识别出正确的 Linear 工单
  • 将工单状态更新为 进行中 (In Progress)
  • 添加了带有可操作后续步骤的结构化评论
  • 链接了相关的内部工单以实现可追溯性

这只是一个简单的例子，但它具有基础意义。你可以直接从 Slack 更新状态、指派负责人、更改优先级、链接工单。Slack 变成了接口，Linear 变得可编程。智能体处理了连接工作。如果你想更进一步，甚至可以在 Linear 工单中调用 @Continue 并要求它同时起草一个 PR。

From context switching to flow state.Continue turns Slack conversations into actions across your tools, so bug reports don’t pull you out of the zone.

利用云智能体 (Cloud Agents) 处理逻辑与安全漏洞

人们很容易认为 AI 智能体只擅长处理简单的一行代码修复。但我们也用它们进行架构层面的修复。

团队中的另一位工程师 Dallin 发现我们在处理编辑智能体端点的权限方面存在漏洞。该端点在客户端检查当前选定的组织，而不是在后端验证用户对特定智能体文件的权限。

这是一个需要理解代码库才能发现的细微差别。Dallin 附上上下文标记了 @Continue：

编辑智能体文件的 trpc 端点有个缺陷。它检查了当前选定的组织并发送了该信息，它应该只需在后端检查用户是否有权编辑该智能体文件...

智能体并没有胡乱捏造补丁。如果我们查看该会话的 Mission Control 视图，可以看到云智能体做了什么：

  1. 搜索： 它搜索了 editAgentFile 和 updateAgentFile 以定位相关路由器。
  2. 读取： 它读取了 src/trpc/routers/agent/agentRouter.ts 以了解当前的实现。
  3. 分析： 它发现了 updateVisibility 突变，并看到它正在接收 orgOwnerId 作为输入参数（安全漏洞所在）。
  4. 修复： 它从突变中删除了该参数，并验证了 packageProcedure 已经在正确处理授权。
  5. 清理： 它甚至更新了前端的 NewAgentFileForm，停止传递现已删除的参数。

智能体消除了安全隐患，清理了更改导致的 TypeScript 错误，并打开了一个 PR。Dallin 审查了代码，给出了赞同，安全漏洞随之被修复。

为什么这对于开发者工作流和心流状态至关重要

Continuous AI 的目标不是取代开发者，而是消除摩擦。

当你将 Slack、Linear 和 GitHub 等工具连接到 Mission Control 时，你不仅仅是在创建一个聊天机器人，而是在创建一个可编程的自动化层，它利用云智能体具备了你代码库的上下文。

  • 线程上下文： 智能体读取线程。如果你在标记 @Continue 之前讨论了 Bug，它会将该对话用作上下文。
  • Mission Control： 你可以实时查看智能体的工作过程。如果它卡住了，你可以随时介入。如果它成功了，你会得到一个 PR 链接。
  • 心流状态： 你始终保持在高效工作的区域。

我们构建这个集成是因为我们厌倦了“上下文切换税”。

如果你不想再用心流状态去换取 Bug 修复，今天就开始尝试将 Slack 连接到 Continue 吧。

开始使用 Slack 集成