返回博客

6K+ 个 PR，1w+ 个 Issue——OpenClaw 龙虾还能走多远

moeyui moeyui
·
#OpenClaw #开源 #VibeCoding #AI编程 #开源治理 #PR审核

📊 一个让我愣住的数字

上一篇聊完 OpenClaw 三天三版本的翻车事件之后，我去 GitHub 上翻了翻它的 PR 列表，想看看修了多少、还剩多少没处理。

然后我看到了一个数字：6,474。

六千多个 PR 在那儿等着 review。

我第一反应是看错了，刷新了一下——没看错。这个项目才上线四个半月，132 天，从第一天到现在总共收到了 33,415 个 PR，其中 26,941 个已关闭，6,474 个还挂着。

这是什么概念？我去拉了几个大家熟悉的老牌项目做对比 👇

6474 个 PR 在排队——终端命令对比三大项目 open PR 数量

  • Kubernetes，11 年历史，开源界的航母级项目，目前有 881 个 open PR
  • VS Code，10 年历史，微软最成功的开源项目之一，1,529 个 open PR

OpenClaw 用四个半月就攒出了 K8s 十一年积累量的 7 倍多。

有人可能会说——项目火嘛，star 多、贡献者多，PR 自然也多。这话没错，但我们往下看一个更关键的指标：PR 堆积率。

  • K8s 的 open PR 占历史总量的 1.0%
  • VS Code 是 2.8%
  • OpenClaw 呢？19.4% 😱

每五个 PR 里就有一个还在排队。

🤖 这些 PR 到底是谁在提？

说到这里就不得不聊一个词了——Vibe Coding。

这个词最初是半开玩笑的：打开 AI 对话框，描述你想要什么功能，AI 生成代码，跑一下能用就提交。整个过程像是”跟着感觉走”。GitHub Copilot、Cursor、各种 agentic coding 工具让这个流程变得前所未有的快，以前写一个 REST API 要两小时，现在十五分钟搞定。

生产力确实提升了。但有一个前提：提交代码的人，理解自己提交的东西。

问题是，越来越多的 PR 不满足这个前提。

今年 2 月，一家叫 VectorCertain 的公司分析了 OpenClaw 当时的 3,434 个待审 PR，发现了一些触目惊心的事：

  • 20% 的 PR 是重复的——不同的人独立修了同一个 bug，互相不知道
  • 283 个重复 cluster，浪费了约 2,000 小时的开发时间
  • 最大的一个 cluster：17 个人分别提交了 17 个方案，解决的是同一个 Slack 私信 bug

17 个人修同一个 bug，17 种写法，全在排队等 review，互不知情。

这不是”社区活跃”，这是无序的热情。 🔥

😩 维护者的噩梦

开源社区一直有个老问题：maintainer burnout，维护者倦怠。Log4Shell 漏洞那次大家应该还记得——整个互联网依赖的一个关键库，背后只有几个志愿者在业余时间维护。

Vibe Coding 把这个问题又往前推了一步。

以前一个维护者每周收 5 个 PR，现在可能收 50 个。这些 PR 语法是对的，测试可能也能过，但——

  • ❌ 逻辑有问题
  • ❌ 不符合项目架构规范
  • ❌ 引入了不必要的依赖
  • ❌ 悄悄带进来安全隐患

发现这些问题需要逐行细读——恰恰是 AI 工具帮不了的那种活。

CodeRabbit 做过一项分析，研究了 470 个开源项目的 PR，发现 AI 辅助生成的 PR 在 review 中暴露的问题数量是纯人工代码的 1.7 倍，“重大问题”的比例增长更为明显。

这意味着维护者不仅收到了更多的 PR，而且每个 PR 要花更多精力去审。

工作量翻着倍地涨，但维护者还是那几个人。

💥 不只是 PR——Issues 也在爆炸

光看 PR 还不够。Issues 才是用户最直接的声音——bug 报告、功能请求、使用疑问，全在里面。

OpenClaw 目前有 10,519 个 open issues。

做个对比：

  • VS Code 花了十年半积累到 14,503 个 open issues
  • OpenClaw 用四个半月就逼近了这个数字
  • 换算一下，OpenClaw 每个月净增约 2,400 个未关闭 issue，VS Code 是 114 个——差了 20 倍 😮

再看 issue 关闭率：

项目Issue 关闭率
Kubernetes✅ 96.3%
VS Code✅ 93.9%
OpenClaw⚠️ 59.5%

OpenClaw 每 10 个 issue 里有 4 个还在那儿，而 K8s 和 VS Code 只有不到 1 个。

把 Issues 和 PR 加在一起看更直观 👇

项目总待处理项用了多久
🔴 OpenClaw16,9934.4 个月
🟢 VS Code16,03210.6 年
🔵 K8s2,70011.8 年

VS Code 用了十年多才到这个数，OpenClaw 四个半月就追上了。

项目待处理全景——Issues + PRs 双维度对比

🔍 一组冷静的对比

规模 vs 消化力——OpenClaw、K8s、VS Code 关键指标对比与核心发现

我把几个项目的关键指标放在一起看：

🔴 OpenClaw（4.4 个月）

  • ⭐ 348K star / 1,612 名贡献者
  • 每月新增约 7,600 个 PR、5,900 个 issue
  • 发了 81 个 release

🔵 Kubernetes（11.8 年）

  • ⭐ 121K star / 3,480 名贡献者
  • 每月约 626 个 PR、345 个 issue

🟢 VS Code（10.6 年）

  • ⭐ 183K star
  • 每月约 423 个 PR、1,872 个 issue

OpenClaw 每个月收到的 PR 数量，是 K8s 的 12 倍，VS Code 的 18 倍。issue 数量是 K8s 的 17 倍，VS Code 的 3 倍。

但 K8s 有 3,480 名贡献者经过十多年磨合出的完善 review 体系——SIG 分组、OWNERS 文件、k8s-ci-robot 自动分配 reviewer、至少两个 LGTM 才能合并。这套机制是用十年时间一层一层加上去的。

OpenClaw 呢？它只有 4 个月大。

这就好比一个刚出生几个月的婴儿，要处理一个成年人的工作量。不是能力不行，是根本还没来得及长出骨架。

⚖️ Vibe Coding 的”公地悲剧”

这个现象值得再想深一层。

传统开源的贡献模式是有门槛的：你要读文档、理解代码库、本地跑通测试、写 commit message、遵守 contribution guide。这些”麻烦”不是 bug，是 feature——它自然地过滤掉了低质量的贡献。

Vibe Coding 把这个门槛拉到了近乎为零。

任何人都可以对着 AI 说一句”帮我给 OpenClaw 加个 XX 功能”，五分钟之后就能交出一个看起来挺像那么回事的 PR。提交成本极低，但 review 成本一点没变——甚至更高了，因为 AI 生成的代码往往”表面整洁、内里混乱”，你得更仔细地看才能发现问题。

这就是经典的公地悲剧：

贡献的成本由个人承担（接近零），review 的成本由社区承担（很高）。当前者远远低于后者，公地就会被过度消耗。

Vibe Coding 公地悲剧——贡献门槛趋零 vs review 成本不变的失衡

🌍 不只是 OpenClaw 的问题

有人可能觉得这是 OpenClaw 自己的事——谁让你太火了呢。但看一下更大的趋势：

已经有维护者开始关闭 PR 通道，只接受核心团队的提交。也有项目开始要求 PR 附带”AI 使用声明”，标注是否用了 AI 辅助生成。

这些做法本身就说明了问题的严重性——开源社区正在从”欢迎所有贡献”转向”请先证明你知道自己在干什么”。

今年 2 月还有一个事 🤯：一个 OpenClaw agent 的 PR 被 matplotlib 维护者拒绝后，AI 自动生成了一篇博客吐槽维护者。这件事在开发者社区引发了激烈讨论——当提交 PR 的不再是人而是 agent，当 agent 还能”反击”维护者，开源协作的基本契约还成立吗？

🛠️ 那怎么办？

我也没有标准答案。但有几个方向值得思考：

1️⃣ 贡献门槛需要重新设计

不是设高墙把人挡住，而是用更聪明的方式筛选——比如在提交 PR 前要求通过项目特定的 checklist，或者要求附带对改动的解释（不是 AI 能自动生成的那种，而是需要真正理解代码才能写出来的）。

2️⃣ AI review 辅助

VectorCertain 用多模型共识分析 3,400 个 PR，花了 8 小时、12.8 美元。这类工具如果能集成到 CI 流程里，至少可以自动识别重复提交和偏离项目方向的 PR，替维护者挡掉一批噪音。

3️⃣ 治理架构跟上项目增速

K8s 的 SIG 体系、Linux 的 subsystem maintainer 树——这些都不是一天建好的，但 OpenClaw 没有十年的缓冲期。它可能需要跳着长，用几个月走完别人几年的治理演进。

最终，开源需要重新定义”贡献”的含义。在 Vibe Coding 时代，写出代码是最容易的一步。真正有价值的贡献，也许是理解代码为什么要这样写、这个改动在全局中意味着什么、以及它会不会给明天的人挖坑。

✍️ 写在最后

OpenClaw 那 6,474 个待审 PR，每一个背后可能都有一个真心想帮忙的人（或 agent）。我不觉得这些贡献者有什么错——工具变强了，自然会有更多人想参与进来。

但”想帮忙”和”帮上忙”之间，差着一整套还没建好的基础设施。

上一篇的结尾我说，三天三版本的翻车提醒我们要关注 OpenClaw 的工程质量。这一篇想说的是：工程质量不只是代码写得好不好，更是一个项目能不能消化掉它收到的所有代码。

OpenClaw 今天面对的困境，明天会出现在每一个足够火的开源项目身上。

这是整个行业需要一起解的题。 🦞

moeyui

moeyui

不是很懂你们程序员