当 AI 代理成为贡献者：KubeStellar 如何实现 81% 的 PR 接受率

来源: Cloud Native Computing Foundation
作者: Andy Anderson, KubeStellar Console 首席维护者
原文链接: https://www.cncf.io/blog/2026/05/14/when-when-ai-agents-become-contributors-how-kubestellar-reached-81-pr-acceptance/

---

12月中旬，我从零开始构建 KubeStellar Console。这是一个面向 Kubernetes 的多集群管理仪表板，属于云原生计算基金会（CNCF）沙箱中的 KubeStellar 项目。技术栈是：后端用 Go，前端用 React 和 TypeScript，打包用 Helm。没有团队。只有我和两个在并行终端会话中运行的 AI 编码智能体（coding agent）。

最初的两周就像这类项目中常被描述的那种“蜜月期”。智能体生成的代码快得让我来不及阅读。我原本计划三天完成的功能，两小时就出来了。我在心里列了一张一直想实现的功能清单，一个接一个地划掉。

然后，问题来了。

构建突然崩溃，原因很难追溯。前一天做的架构决策悄悄被覆盖。范围在无要求的情况下自行膨胀。智能体会不断修改我并未指向的文件，而最糟糕的是级联问题——修好一个，另外三个就坏了。我开始花更多时间回滚而不是审查。所谓 10 倍效率开始感觉像是净亏损，于是我决定彻底放弃这套方法。

用编码智能体构建 KubeStellar Console 时，最令人惊讶的不是模型能力的边界，而是周边代码库需要承担的繁重工作。

从欣喜若狂到备受挫折，这一过程似乎具有普遍性。行业常规建议是给智能体更多自主权：让它运行更久、接触更多文件、自行纠错。但根据我的经验，这往往会让失败模式变得更糟，而不是更好。杠杆效应的方向恰好相反。在 AI 辅助的代码库中，智能并不主要存在于模型本身，而更多地存在于代码库围绕模型构建的那些循环中。如果你想让智能体做得更多，那么周边的代码就必须测量得更多。

四个月后，KubeStellar Console 的状态已经好多了。现在共有 63 个 CI/CD 工作流、32 个夜间测试套件，以及分布在 12 个分片上的 91% 覆盖率。在 82 天里，PR 接受率稳定在 81% 左右。社区提交的 bug 报告大约在 30 分钟内就能转化为已合并的修复。功能请求大约在一小时内就能变成 pull request。这些都不是因为更好的模型带来的。变化的是代码本身学会了如何测量。

五个收紧循环让我达到了这个状态。我把它们看作是所谓“AI 代码库成熟度模型”的阶梯——辅助型、指令型、可测型、自适应型和自维持型。我将按它们出现的顺序逐一讲解，因为我认为这个顺序不可调换。

1. 记下你一直在纠正的东西（指令型）

最便宜且回报可能最高的干预方式，就是把你自己的偏好外化。我首先在仓库根目录下创建了一个 CLAUDE.md 文件，接着又为 pull request 约定创建了 .github/copilot-instructions.md 文件。然后我写了一篇卡片级别的开发指南，列出了我拒绝 AI 生成的 PR 的主要原因。

那篇指南最终覆盖了大约 90% 的拒绝标准。会话变得更具一致性。同样的错误不再跨智能体重现。我还不把这称为“测量”——在那一刻我仍然凭直觉行事——但它足以过滤掉大量噪声，使得标准的测量成为可能。

2. 把测试当作信任层，而非仅正确性层（可测型）

这是最关键的一步。为自主工作流做测试，与为人工作流做测试是不同的。这是智能体判断自己是在改善系统还是在破坏系统的唯一信号。

在四周内，我新增了 32 个夜间测试套件，将覆盖率推高到跨 12 个并行分片的 91%。这些套件涵盖了合规性、性能、空安全性、可访问性、国际化和视觉回归。与此同时，我开始按类别将 PR 接受率记录到 auto-qa-tuning.json 文件中。事实证明，这个文件对后续所有工作都至关重要。

覆盖率数量重要，广度也同样重要。但几乎让我功亏一篑、并且我会对任何尝试这么做的人重点强调的问题，是确定性。

“在人工作流中，一个不稳定的测试只是烦人。而在自主工作流中，它却是对整个信任模型缓慢、无声的侵蚀。”

一个用于拖放操作的 放操作的 Playwright 端到端测试 大约有 85% 的时间能通过。在人工工作流中，这可以容忍：你重新运行一次，然后继续。但在一个测试结果决定合并的自主工作流中，85% 的 85% 85% 的通过率就是一场灾难。好的 PR 被随机阻塞，而弱的 PR 却被放行。我花了三天时间处理这一个测试，结果发现是 CI 中的动画完成时序问题。这个教训具有普遍性：你不能在不可靠的信号之上构建自动化。一个不稳定的测试在人工工作流中只是烦人，在自主工作流中，它是对整个信任模型的缓慢、无声的侵蚀。

3. 在能测量之前不要自动化（自适应）

随着接受率被记录，自动化变得更安全。自动 QA 开始每天运行四次，跨越八个质量检查层。决定系统关注哪些工作类别的轮换权重开始根据数据自我调整。可访问性 PR 的接受率为 62%，因此其权重上升到 0.93。操作员类别 PR 的接受率为 8%（11 次合并对 129 次关闭），因此该权重降至零，CI 周期被重新分配。

围绕这个核心又闭环了几个流程：

• 一个分类流程每 15 分钟扫描四个仓库。
• 一个 PR 监控器每 60 秒轮询构建状态。
• 一个错误恢复工作流使用指数退避来处理卡住的代理。
• 一个 GA4 查询每小时针对生产分析运行，并在用户报告之前为错误峰值提交 GitHub 问题。

“没有测量的自动化不是成熟——而是规模化的失败。”

所有这些模式的共同点是：先测量，后自动化。颠倒顺序是自主系统脱轨的原因。没有测量的自动化不是成熟——而是规模化的失败。

4. 让代码库成为操作手册（自我维持）

在某个时刻，我无法指出具体是哪一天，系统不再需要我在循环中操作。它的行为由其产物决定：指令文件、测试、工作流规则和接受率历史。社区开始全天候提出问题，这些问题在我醒来之前就已经被分类、分配、修复、测试并排队等待审查。

一个案例清晰地体现了这种转变。4 月，一位用户提交了一个 bug，报告一个集群被标记为“健康”，而 Pod 却卡在 ImagePullBackOff 状态。在我查看之前，系统已经回答了：集群健康反映的是基础设施健康（节点就绪、API 可达性），这在架构上与工作负载健康是分离的。这不是一个 bug，而是一个 Kubernetes 心智模型与仪表盘显示不完全匹配的问题。设计决策已经编码在测试、健康检查逻辑和文档中；代理能够解释它，因为代码库已经知道了。

这比任何吞吐量数字都更能体现“代码即模型”在实际中的样子。

5. 问“为什么”，而不是“什么”

一个提示习惯产生了不成比例的效果。我不再问“修复这个 bug”，而是开始问“你为什么没有抓住这个？”第一个表述产生一个补丁。第二个往往会产生根因分析，并作为副作用，产生一个新的测试、指令或规则，从而阻止一整类类似的失败。

命令式会得到一系列孤立的修复。提问式则会积累。随着时间的推移，问题才是将代码库变成自我改进系统的关键，如果你从零开始，它们也是最初产生指令文件的东西。

这对维护者和领导者意味着什么

如果你领导工程团队，请停止优化你正在使用哪个模型。模型是一个商品组件，换一个只需要一个周末的工作。重建周围的反馈系统则需要一个季度的工作。差异化在于智能基础设施：指令文件、测试套件、指标和工作流规则。

对于开源维护者来说，这直接解决了在 CNCF 社区对话中不断出现的倦怠问题。如果一个代码库能够编码足够编码维护者的判断，使得代理能够处理分类、生成拉取请求并向用户解释设计决策，那么社区就可以主要通过提交问题来引导项目。

维护者成为系统的架构师，而不是日常操作者。对于 KubeStellar Console 来说，这并非假设。它现在正在工作。它是否能超越一个单人维护的 Sandbox 项目，需要更广泛的社区来测试。我真的很想知道。

大多数团队仍处于第一个循环中，编写提示词并审查输出。这是每个人的起点。关键不在于争分夺秒地冲向最后一个循环，而在于识别出当前真正阻碍你的那个循环，并在下一步将其闭合。

代码库承载着我已掌握的知识，测试则捕捉我无法时刻记在脑中的细节。而真正属于我——并且我认为这部分将始终属于我——的职责是：判断什么值得构建、什么该拒绝，以及“好”好”的标准应该是什么样子。