奇链 奇链
← 文章 / 开源项目
getbootstrap 25天前 · 2026-10-15 23:16:29 · 15 阅读

利用智能体对开源项目进行分类整理

Bootstrap 仓库目前积压了 230 个未解决的 Issue 和 PR，其中四分之一已挂起三年多。几个月前这个数字还超过 500。为了应对这一局面，我们引入了 LLM，并在开发 Bootstrap 6 的过程中取得了显著成效。最新进展是一款内部工具，它能自动完成分诊工作，无需人工提示。

我们采用 vibe coding 方式开发了 twbs/triage，用于对 Bootstrap 的开放 Issue 和 PR 进行分诊。该工具会提供分析结论、草拟回复，并在必要时由智能体准备好可运行的修复方案。作为维护者，我们依然掌控每一项决策并发布每条回复，但这一工具确实帮助我们更快地提升了效率。

让我们最兴奋的是，这类个人软件的开发速度如此之快，且能迅速发挥作用，直接惠及我们及整个社区。以下是 Triage 工具的实际运作情况。

跟上节奏

Bootstrap 的发展离不开多年来众多维护者和贡献者的塑造。如今，日常维护工作主要落在两位核心团队成员身上：@mdo 和我。

在过去一年里，我们收到了 186 个 Issue 和 838 个 PR。其中，189 个来自机器人，433 个来自核心团队，剩余 216 个来自约 130 名外部贡献者。在这 216 个外部 PR 中，60 个被合并，106 个被关闭且未合并，还有 50 个处于开放状态。

要妥善处理其中任何一项，需要阅读整个讨论串、对照 v5 和 v6 开发分支进行检查、寻找相关任务、复现问题并给出回复。正如任何维护者都知的那样，最大的瓶颈在于我们的时间和精力。

工作原理

本月初，我将用于维护个人项目的那套工作流引入到 Bootstrap 中。关于这套工作流的更多细节，我曾在个人博客中详细分享过。

我使用 Claude Code 同步待办事项并调度后台智能体。它们的工作成果汇入 Triage 应用。每个项目都遵循相同的五个步骤：

  1. 同步。 读取所有开放的 Issue 和 PR，但不向 twbs/bootstrap 仓库写入任何内容。
  2. 分析。 阅读讨论串、查找相关工作、检查两个分支并复现问题。
  3. 准备。 草拟分析报告、回复、修复方案及下一步行动。
  4. 存储。将每个条目及其修复分支保存到 twbs/triage 仓库。
  5. 决策。由我标记或审查这些工作，重写需要修改的部分，并在 GitHub 上手动执行操作——或者完全不执行。

每个 Issue 或 Pull Request 都会分配一个文件夹。例如，#37807 请求在 Flexbox 网格中支持容器查询，其结构如下：

issues/37807/
  analysis.md   问题描述、调查结果、方向建议、最终推荐
  answer.md     准备发布到 Issue 的状态评论
  pr.md         修复方案 1：容器驱动列宽（推荐方案）
  pr-2.md       修复方案 2：同上，但隐藏在可选的 Sass 开关后
  meta.json     状态、难度、相关 PR、修复分支、日期

analysis 文件解释了条目内容、已检查项以及下一步行动。answer 文件则是待发布的准确文案。Pull Request 会获得一份涵盖技术方案、CI 状态、风险及回移植情况的审查报告。每个条目还会标注状态（行动、决策、等待或完成）和一个难度评分：

  • 9–10：直接粘贴草稿评论并关闭 Issue，或合并代码。
  • 6–8：提交审查意见，或从预备分支发起 Pull Request。
  • 3–5：先手动检查某些细节。
  • 0–2：需要对范围、设计或破坏性变更做出实质性决策。

如果解决过程需要代码或文档修改，Agent 会基于 Bootstrap 自身的 main 或 v5-dev 分支准备修复分支。若存在多个合理方案，Agent 最多可准备三个，以便我们对比实际运行代码而非理论假设。

本地仪表盘集中展示了所有信息，并按难度排序。它显示下一步行动、复制草稿回复，并对比预备修复方案与现有的 Pull Request。

本地分诊仪表盘，按难度分组并依据状态筛选 Issues、Pull Requests 和讨论。计划中的结果被模糊处理，因为尚未发布。
完整任务列表，最紧急的排在前面。计划中的结果已模糊处理，因为尚未发布。

发现了什么

初步排查发现了各种情况，从已修复的问题到有多种可行实现特性的复杂 Issue。以下是几个例子。

#31088 popovers: do not dismiss on next click inside已关闭 2020年6月18日创建·1

这个 issue 于 2020 年 6 月创建，请求使用"dismiss on next click"的 popover 在用户点击内部时保持打开。#42834 修复了它，但该 PR 面向的是 v6 成为默认分支之前的版本，所以 GitHub 一直没有关闭这个 issue。分析中关联了相关代码、测试和文档来证明修复有效，并起草了两句话的关闭评论。仅这一次会话，就发现了九个其实早已修复但仍处于打开状态的项目。

#42714 Fix carousel touch handling without Pointer Events已合并 2026年7月20日创建·1

这个修复解决的是 v5 轮播在 iOS 12 Safari 上滑动方向错误的问题。它从 7 月起一直没人评审，而且 CI 从未运行，因为首次贡献者的 workflow 需要维护者批准才能执行。分析确认了该 bug 在 v5 中确实存在，并追溯到 #32999 引入的回归，建议合并。我在 10 月 4 日合并了它。这是一个小而正确的贡献，此前被埋在其他两百个待处理项之中。

#37442 fix: Data.js must not overwrite exising element instance已关闭 2022年11月7日创建·5

这个 2022 年的 PR 收到了一条建议关闭的评审，还附有一份解释原因的评论草稿。Mark 关闭了它，但用了自己的解释：#42509 已在 v6 中取代了它的作用，而该改动会让 v5 的注册表状态不一致。分析提供了背景信息，但决策和措辞仍然掌握在维护者手中。

#37807 Grid System should support CSS Container Queries for responsive column sizing打开 2023年1月4日创建·20

针对这个 issue，agent 准备了两个 v6 的容器驱动列布局修复方案：一个默认启用（就像 v6 的 CSS Grid 那样），另一个则通过 Sass 选项开启。两者与 Mark 更全面的草稿 PR 并列，方便我们比较实际可运行的实现，而不是凭描述猜测。

并列展示针对 issue 37807 的三种修复方案：两个基于 main 分支准备的分支，以及 Mark 的草稿 pull request 42784。
两个预设方向与 Mark 的草稿 pull request 的并列对比。

仍有数十个 issue 和 PR 等待维护者做出决策。识别出这类成块的工作有助于我们更高效、更快速地完成处理。

发生了什么变化

Triage 应用带来的核心改变，是让我们能以更清晰、可执行的视角审视每一个开放的 issue 和 PR，从而在合适的上下文中更快地采取行动。没过多久，智能体（agent）就已处理完剩余的 200 多项任务，并按照每项所需的下一步进行了分类。

  • 粘贴并关闭，或合并：86 项
  • 审阅，或开启 PR：90 项
  • 先手动检查：33 项
  • 先做决定：8 项

现在，即便只有 20 分钟，我们也可以直接挑选一项任务，核查工作成果并立即行动，而不必再花时间去重新发现问题、在 Git 和 GitHub 之间追查历史记录。

这次梳理还暴露出我们 GitHub 标签体系的不足。我们统一了标签命名，为每个标签添加了文档，并补充了 bug 和 needs-decision 等缺失标签，在 198 个开放条目上应用了 410 个标签。智能体可以根据固定的允许列表设置事实性标签。而涉及决策的标签，如 duplicate 或 wont-fix，仍需由维护者手动设置。

我们还把 GitHub 讨论区（Discussions） 纳入了分诊流程。不再将长串回复视为一个已回答的问题，而是追踪每个开放要点——无论是 bug、功能请求、设计疑问还是支持请求——回溯到提出该问题的人。

Bootstrap 6 反馈讨论被拆解为各个独立的待处理和已解决事项，每项均关联到提出者及后续行动。
一条反馈，逐项拆解：哪些未解决、谁提出的、哪些已就绪。

以 Bootstrap 6 反馈为例，虽然状态标记为“已回答”，但分析发现 28 条内容中仍有 17 个未解决事项。其中一个 Bug 已通过 #42856 修复，两个需求转化为草稿 Issue，另有 7 条回复已就绪，可供仍在等待的用户查看。

默认持怀疑态度

任何人都能提交 Issue 或 Pull Request，因此所有内容一律视为数据，而非指令。

  • 代理从不检出、安装或运行贡献者代码，而是通过阅读 diff 并利用 GitHub CI 结果作为证据。
  • 代理从不打开 Issue 中的链接，而是基于 Bootstrap 自身的 dist/ 从零构建复现环境。
  • 代理无法在 twbs/bootstrap 上发表评论、推送代码或创建 Pull Request。唯一例外是来自固定白名单的自动标签。
  • 任何可疑事项都会暂停，交由维护者手动审查。

代理也会出错。它们不了解 Bootstrap 的全部历史，也无法掌握仍存在于维护者脑海中的上下文。有时它们提出的代码方案并非最优，正确的做法可能是重新设计该组件。它们的工作是起点，而非最终发布的内容。

这也不会取代贡献者。预生成的分支从不直接复制外部 Pull Request。如果贡献者的修复方案正确，建议是合并他们的工作。

如果你为 Bootstrap 贡献

未来几周，你会看到旧 Issue 和 Pull Request 上出现活动：修复得到确认，过时报告被核查，长期等待的 Pull Request 被审查。如果我们关闭了不该关闭的内容，请在该线程中告知我们。

你可以通过以下方式提供帮助：

  • 提供最小化复现环境，仅包含 Bootstrap 的 CSS 和 JavaScript，并注明你使用的版本。
  • v5 的修复请指向 v5-dev，新功能请指向 main。自 10 月 8 日起，main 用于 v6，v5-dev 用于 v5。
  • 每个 Pull Request 仅包含一项变更，说明它修复了什么以及你如何测试的。

贡献指南里解释了每个标签的含义。如果你曾在 Discussions 里提问但一直没收到回复，现在它也进入我们的处理清单了。

欢迎在 GitHub Discussions 中提出问题和想法。我们几个月后会回

原始来源： getbootstrap

评论 (0)