还能组一辈子开源乐队吗？

开幕雷击。

有一说一，这个还真不算是玩梗。

八月份的时候，我把开发了两年左右的 Rust 异步原语项目捐赠给了 Apache 软件基金会，由于西语系老哥说原来的名字有些神秘的联想，于是我们几个开发者鬼脑发动，合计完最后采用了 Asyncband 作为项目名称。

然后就是项目合伙人 @PragmaTwice 开了一个乐队主题的 Logo 提案。可惜由于人均艺术细菌不足，暂时搁置，也欢迎各位反馈或投稿。

言归正传，本文写于下周我即将在 Scotland Glasgow 做演讲之前，内容与演讲主题相同，即讨论 AI 冲击下的开源范式进化和社群格局演变。一言以蔽之，就是作为一个朴素的软件工程师，在下一个时代还值得参与开源，加入建设开源社群吗？

大模型带来的产能升级

毫无疑问，现在的 SOTA 模型完全具备超越软件工程师平均水平的 coding 能力。在此之上，Agent 能够在 Harness 的支持下，不知疲倦的探索和自主迭代，极大降低了代码生产的成本。这种软件行业总体性的产能升级，给过往开源社群的假设带来了两大冲击。

参与开源的门槛急剧降低

过去，向开源项目提交 PR 大致需要你自己掌握：

1. 如何设置开发环境
2. 找到参与的切入点
3. 了解项目的协同风格

一个典型的情况是，你带着问题来到上游，比如使用过程里碰到了 BUG 或者可以改进的地方，运气好点项目的 README 或其他文档告诉了你如何设置环境，但这通常也需要你认真阅读理解才能真正上手；运气不好啥也没有，源码就在这了你自己逆向工程破解维护者的意图吧，那可能光是能成功编译开源项目，就已经把原本想要参与的动力磨灭了。

现在情况大有不同了。

大模型训练过程中，什么类型的项目没见过？什么语言和领域的最佳时间不在知识库里？加之 Agent 可以不知疲倦地分析和尝试，逆向工程破解项目的 setup 可说没有门槛。

于是，如果你带着需求来，如今的前沿模型完全可以在你提供意图和事后验证的基础上，直接帮你解决设置开发环境，起草解决方案，完成测试覆盖和性能评估等工作。

比如，有一位 iceberg-rust 的用户在使用过程中发现了一个 Apache OpenDAL 的正确性问题。这搁以前，可能首先就不知道报错的根因是 OpenDAL 的问题。但是现在，老哥用 Claude Code 作分析，写修复方案。我猜他可能都没怎么仔细研究 OpenDAL 的代码，看一眼 AI 生成的 diff 大致正确，就可以 ping Maintainer 来 Review 和合并了。

另一种情况是，单纯想参与开源项目，可能是为了丰富自己的简历，也可能是学了新知识想找个对象尝试一下。这种情况下，过往要找到一个合适的标的，首先得看看开源项目自己有没有标 good first issue 标签，然后找到合适的问题以后，得理解清楚 issue 的动机，阅读代码，找到修改点，手写补丁，提交待审，回复 Reviewer 的评审意见。

这样一套下来，对 contributor 的要求并不低。这也是之前实质性参与开源项目且有所贡献，能成为简历上的加分项的重要原因。

现在这一套流程，几乎每一步都可以让大模型辅助，于是就变成了：

• Aegnt(-assisted) inspects
• Agent(-assisted) implements
• Agent(-assisted) interacts

即在 Agent 的帮助下，完成问题的发现、PR 的撰写，以及跟 Reviewer 的互动。甚至有时候，这些动作完全由自主 Agent 完成，没有人类参与其中。

比如，我在 Asyncband 上发布的 good first issues，不少都会在 24 小时内被光速领走并光速实现。我再用 GPT 和 Kimi 混合双打 Review 一下，光速合并，再光速发版，这个功能就 deliver 出来了。

这是 @QwQBig 第一次参与 Asyncband 的场景，显然，他解决这个问题也高度依赖 AI 来进行分析和起草。不过，我在 Issue 和 PR 的对话里发现了他充满人性的一面，于是就尝试引导他 pick up 其他工作，并思考 Asyncband 的项目定位，逐步在项目里成长。

下面这个例子就是彻底没有人类的情况了。

正所谓，与其寻找一个 good first issue，不如自己创造一个 good first issue ☝️🤓

对于古法编程时期写成的开源项目来说，一些边界情况没有考虑好，导致特定输入会引发问题，这是很常见的情况。实际上，开源项目的 BUG 修复一般都是有人遇到了问题，才会推进修复。如果没人这么用，甚至没人用，也就没有问题要修复。

但是，AI 最大的特点，就是不知疲倦。尤其是 GPT 5.6 以后重度被害妄想症和究极过度防御编程的特性，使得 Token 滞销的订阅者们，其中有一些就开始扫描知名开源项目，构造出能够触发问题的特殊输入，然后给上游推 BUG 修复。

Apache DataSketches 项目里，有一位老哥就是这样的。

他在 PR 回复里说，自己是用 fuzzing 找问题，然后就提交 PR 来修复。但是在我跟他的沟通过程当中，我发现回复的频率和内容完全没有半点人性，而且至少他提交给 datasketches-rust 项目的补丁大多需要我二次修改，甚至需要完全重写。我给的 PR Review 哪怕老哥处理了，也处理得不好，活脱脱像一个 token 质量不足的大模型。

这种情况也就是所谓的，订阅大模型的人只是模型的代理（Meat Proxy）。我也就不期望跟他本人能建立什么联系，而是当成一个可以调用的大模型，根据它的输出给到我订阅的模型，最后由我本人判断完成工作。

新和联胜唾手可得

今年第一个关于重写的大新闻，就是 Bun 把之前使用 Zig 语言开发的代码库，全部用 Rust 语言重写了。

关于这件事的讨论很多，我不再一一赘述，只强调两点：

1. Bun 的重写能够成功，很大程度上依赖于完整的测试套件，即软件行为本身已被相对充分地定义。这个测试套件显然深受先前已有的 JavaScript 运行时和包管理器的测试集的启发。
2. 即使有相对充分的测试和端到端可验证的行为约束，Bun 的 Rust 重写 PR 本身只花了 2 周就能合并，但第一个 Rust 重写后发布的版本，却要等到三个多月后才正式发布。

在这三个多月里，又有很多新问题在 Early Preview 版本中被发现和修复，Rust 版本也经历了一系列重构和调整。

这首先说明，开源项目，哪怕是几十万行上百万行代码的大型项目，其彻底重写已成为一种不再昂贵的可能。过去，这种级别的重写没有一整个研发团队搞个一年半载是办不到的，现在却只需要一个人主导，小团队验收，两三个月即可交付。

其次，即使生产代码的成本急剧下降，决定哪些 AI 生成的代码能发布交付，以及确定软件目标和用户体验的仍然是人。因此，就算 PostgreSQL 的测试集都是公开的，简单地推出一个 Rust 重写的版本，也很难获得用户的认可。如果没有自己对软件设计的判断，这种重写或者说 fork 最终也只能是吸上游尾气。

当前的所有 Agentic Coding 实践都表明，如果指挥 Agent 的人不能指明软件前进的方向，甚至摆烂让 Agent 自行决策一切事宜，基本上软件会很快熵增热寂，变成一团浆糊，啥也不是。

不过，对于有想法的软件工程师来说，大模型带来的生产力当然意味着可以轻而易举地搞新和联胜。

比如，由于 Rust 生态的哈希算法实现一家有一家的风格，且每家都或多或少在某个问题上做的有所缺憾，我们从 ScopeDB 实际的哈希算法出发，重新组织出了 fast/hashcrew 公共库，以相同的设计理念提供了一批典型的哈希算法实现。

这在以前是不太敢想的。因为正确实现哈希算法，确保测试覆盖，搞定各种硬件加速的集成，并通过 benchmarks 建立回归基线，还是很花时间精力的。而且手写的代码总是或多或少会有缺陷，如果出现正确性 BUG 又上线了，就有点难办了。这个时候，开源生态里捡一个大家都踩过坑的实现凑合，是比较经济的做法。

但是，Agent 对这种算法良定义，有明确的测试集和性能目标的任务，就非常擅长。Hashcrew 的 LICENSE 文件罗列了实现过程中参考的现成方案和测试集。这保证了 Hashcrew 的实现在正确性上可以信赖。当然，ScopeDB 本身有哈希计算相关的回归测试。

然后，通过重新组织哈希算法的实现，我们能够提供一致的接口，并且能汇集百家之长，把各种加速优化算法都拿到一起，而不用受限于某个上游维护力度有限，或者作者想法不同，而难以将需要的改动推回上游的情形。

应该说，AI 极大降低了代码生产成本以后，大家都可以观察到：所有应用软件乃至软件库的依赖都在大幅减少，只有确实比较大的场景才需要依赖第三方库。即使是依赖另一个库的情况，哪怕是 well-known 的开源库，下游自行维护 fork 的情况也明显增多了。至于 non-well-known 的库，很多本身完成度就很一般，下游 fork 以后很多都是深度魔改，都不太是原来的模样了。

这对近二十年的开源协同方式可算是一次颠覆：此前，大量的程序员没有足够的精力维护依赖库提供的功能；又或者行业劳动力密集型的性质，导致大量培训班出来的人是纯粹的拿来主义，根本也不想自行维护。因此，开源软件的上游从社会经济学层面就能自然地把有能力修改软件的人聚拢在一起形成上游，而其他开源软件的消费者在下游接受上游生产者交付的软件。

不过，如果把时间线拉长到三十年、四十年，我们就能惊讶地发现，这种直接交换源码，直接修改源码以满足自己需求的方式，正是开源软件，或说自由软件的最初的模样：我把源代码给你，你自己编译使用。如果你遇到了什么问题，既然你都有源代码了，自己改好就行了。

当时的说法是，源代码传递了软件的所有知识，因此只要你有源代码，就能够理解程序是如何运行的，从而能够修改程序。后来，随着软件规模增长，人已经看不动全量源代码了，而且只有源代码而不知道作者的意图，也很难人为逆向工程破解来学习。

但是，大模型是最擅长直接分析源代码，并根据中之人的要求直接改源码实现功能的，而直接基于源码的复用，能够给到下游充分的修改自由，而越是深度的集成，就有越多潜在的机会能做充分的优化。这就是现在越来越多软件减少基于包管理器的外部依赖，转而直接集成依赖的源码，也就是所谓的 fork 并魔改的原因了。

软件工程仍存于此

在大模型发展的过程当中，我们前后经历了多轮 Engineering 相关的炒作：

• Prompt Engineering
• Context Engineering
• Harness Engineering
• Loop Engineering
• …

这些炒作无一例外都以 Engineering 结尾，这种共同点指向一个历久弥新的行业实践：软件工程（Software Engineering）。

从定义上说，软件工程被定义为一门将系统化、规范化、可量化的工程原则和方法应用于软件的开发、运行与维护的学科。

站在今天往回看，我认为可以将软件工程重新表达为：组织软件开发上下文的艺术。

乍一听，这可能有点像 Context Engineering 的再次翻炒。不过，我要说的是，软件工程一直以来讨论的都是如何有效地组织项目的上下文。

烂炒的 Context Engineering 主要局限在讨论大模型语境下的 Context 该如何装配，使用 RAG 有没有帮助，如何管理 Agent 的记忆，是否存在更好的输入输出格式等等。

相比之下，软件工程所讨论的软件开发上下文组织，主要关注在：

1. 宏观的项目定位，即项目解决什么问题。具体到战术层面，某个接口的行为如何定义。
2. 工程实现上的约束，即哪些功能是明确不做的，哪些前提条件一定要满足。具体到战术层面，某个接口的实现如何设计。
3. 验证接口行为及其边界的套件，即如何证明一次修改是可靠的。具体到战术层面，就是行为测试和性能测试等等。

关于软件工程的主题，我或许接下来会找时间，对着某些经典的流派做一点解读。一言以蔽之，就是战术更迭，而战略长生。

例如，《重构》这本书最大的价值是告诉你“要记得重构”。只要记住这句话，整本书丢掉都没关系。《领域驱动设计》我比较认可的是，要为项目建立一套通用语言，不然项目团队内部的沟通都会鸡同鸭讲；至于“限界上下文（Bounded Context）”，你就简单理解成“要记得模块化，模块一定要设计好”就行了。这些书的具体战术案例，说句不客气的评价，就是凑页数卖钱。实践当中不出几年，就迭代到不知道哪里去了，甚至因为适用范围非常有限，早被淘汰了。

一直以来，软件工程在实践中遇到的一个巨大挑战就是应用成本太高。

比如测试，没有人会否定测试的重要性。即使我认为只有行为测试和回归测试是重要的，但我实际上也很少写测试。一方面，当然是因为生产代码本来就不包括测试，软件开发最终考验的还是生产代码的质量，写对了就差不多了；另一方面，作为实现功能的人，确实很难有使用功能的人的视角，每次想到要写测试，就觉得哪哪都不用测。

但是 AI 做这个角色转换是毫无压力的，而我来评审 AI 生成的测试用例，哪些是该删掉的垃圾测试，哪些确实覆盖了重要的接口行为约定，这就轻松多了。测试本身就有验证接口行为，保证在重构过程中不会破坏现有契约的价值。于是后续即使再放飞 AI 自由修改代码，只要 Review 一下没有偷偷改测试逃课，就能确定过往的行为都有回归保证。

又比如重构，同样没有人会否定其价值。但是，在实际工作当中，能找到时间重构代码的人又有多少呢？更不用说人工重构，尤其是大型重构，总是会引入一些新的故障，对于只是上班领个工资的 Team Leader 来说，重构代码只有风险没有收益。当然，欠下的技术债和累积的技术负担总有一天会爆炸，但是谁又不想赌一把，炸弹不会爆在自己任上呢？而且实在不行，成立一个新项目组，直接从头开始写，也挺好嘛。

而且，重构其实很花时间。比如，一个中型项目里日志乱打，整体整理一遍可能要花一两周时间，但收益几乎完全说不明白。

这里的一大问题就是，人的上下文是有限的，而稳健的重构往往需要全面评估重构可能带来的影响，这就需要在脑海里记住所有相关的模块代码逻辑。大型重构之所以很容易引入新的缺陷，很多时候就是因为人脑在 Compacting Context 时丢掉了某个约束。

显然，AI 的上下文比人脑要大得多，AI 做起这类工作来也比人要耐心的多，而且由于充分训练掌握了工具使用，速度比人也要快得多。

P.S. 其实，AI 用命令行工具或者写 Python 脚本来做重构，理论上来说人也可以写，但是人要把重构动作映射成一个脚本，本身也很累，可能不如直接手动改。我在处理 Apache ZooKeeper 的全局代码风格调整的时候，所有报错都是一个一个看过去手改的，大概全程花了我一个月的时间才全部合并；到了 TiDB 迁移测试的时候，多少能借助 JetBrains 家的 IDE 做一些全局正则表达式的查找替换，但是也止步于此了。而且每次想想那个正则怎么写，再真的敲出来，敲错了还要回滚重来，真挺累的。TiDB 的重构前前后后做了近一年才完成。这算是人和 AI 在产能/效率上差距的一个具象体现。

我一直认为，如果 Coding Agent 能把过往的软件工程实践都低成本地 apply 下去，整个软件行业的水平就能大幅度上升了。现在看来，这个期盼在一定程度上实现了。

这里我分享两个亲身体验的例子。

ScopeDB 作为一个云数据库，延迟方面的性能很大程度上依赖缓存能力，主要是减少需要回 S3 读取原始数据的比例。ScopeDB 首先实现了内存缓存，后来开发了 Percas 独立缓存服务。两个月前，@leiysky 带着 GPT 搞出了 C² (cache2) 作为最新的 RAM + SSD 混合缓存引擎。

不出意外地，AI 生成的代码里有很多难绷的毒电波，再加上 GPT 独有的超绝被害妄想症带来的过度防御编程，C² 的代码可以说亟需重构。

当然，即使完全不重构，AI 也能想办法帮你找到一种姿势，把对应的功能接上来，只是那样认知负担会很快堆积，人很容易看不懂。

一旦人逐渐看不懂代码，其实就无法准确的给到 AI 合适的提示词，而且 AI 的推理过程也会被认知负担压垮，最终变成按下葫芦起了瓢，只能被动应对线上问题，而不能明确某些问题一定不会发生。

可是，C² 的代码绝对算不上简单。可以说，这是 @leiysky 脑海中混合缓存集大成方案 roughly dump 出来的快照。如果要我直接手动重构这些代码，我多少会有些心惊胆战，因为不知道某个重构会不会破坏代码运行的前提条件。

但是，我的 Agent 能够阅读理解 @leiysky 的 Agent 输出的代码和文档，根据我指出的 Code Smell 给 C² 做动辄几千行的重构，而保证其端到端契约不会破坏：

• build: adopt workspace repository layout
• feat: separate cache options from validated configuration
• refactor: organize modules and make result types explicit
• refactor: make configuration options consistent and extensible
• refactor: unify configuration semantics and naming
• refactor: remove leftover scaffolding from earlier rewrites
• refactor: collapse duplicated harness and engine implementations
• refactor: separate cache lifecycle, runtime, and persistence

上面这些改动，我自己手写的话，没有完整的不被打扰的一两个月是很难做到的。然而，在我负责指出明显的模块结构问题，Agent 分析和实现，对于我拿不准的少部分改动，再让 @leiysky 二次确认，上面所有这些 PR 实际上都是我在完全 part-time 期间走读代码发出来的。

注意到这组 Deslopify PR 的第一个是调整代码仓库的结构。这也是我上手任何开源项目的第一步：如果项目结构看着难受，我几乎无法开展任何后续工作。这一方面是强迫症，另一方面，也是把项目结构整理好之后，改动涉及哪些模块和功能就一目了然，实际上是一种把项目建模后放进人脑 Context 的手段。

这种项目结构我一开始放在了 fast/template 仓库模板里。不过现在更常见的是让 Agent 直接参考 apache/datasketches-rust 和 apache/asyncband 的结构，按需取用。

其主要结构就是：

1. 一个 Cargo Workspace 的主结构，用于组织多个 crates 的 Rust 项目。
2. 顶层的 Benchmarks 和 Integration Tests 目录，用于测试项目端到端的接口行为和性能。
3. 按需增加 Examples 顶层目录，主要是为了方便用户发现这些较为复杂的用例。简单的用例就放在文档注释里了。
4. xtask 是一组能用 cargo x 调用起来的开发者工具，主要包括运行测试、跑 Linter 和 Formatter 等。
5. 当然，还有按需给 Agent 提供的 AGENTS.md 文件和各类 Skills 目录。

这个结构目前用下来非常不错。

不过，我对 AI 的另一个判断也还没有过时。由于目前的软件工程实践仍然缺乏有效的可量化指标，比如模块化是否清楚，代码品味如何，具体的边界条件怎么设计才合理，目前都高度依赖人的判断。

例如，我在 DataSketches 项目上开发给 ScopeDB 用的 T-Digest 算法实现的时候，发现无论是 datasketches-java 的实现，还是论文作者 Ted Dunning 自己写的参考实现，对于各类极值的处理还是没有考虑的非常周全。

这些边界情况，最终代码当中的处理逻辑，实际上几乎每一个都是我决策的。你去让 AI 在 A 或 B 中间选，它能把 A、B 和“或”都选上。让它自己探索，更是离谱得没边。

从原理上说，大模型的训练过程，以及现在约束大模型行为的 Harness 的结构，都更适合面对确定性任务做极致的优化。这种非确定性环境下的决策，AI 只能看情况给你生成一些似是而非的回复，大部分情况下无法直接采用。

上面这个例子，最终我是通过同为 ASF Member 的联系找到了论文作者 Ted Dunning 交流，并且在他一开始反对我的选择的情况下，讲清楚实际输入会遇到什么情况，以及为什么会设计成这样。总之最后就是，前面忘了，后面忘了，但是 You have convinced me.

最后，我想讲一下开源协同的一个重要工程实践。

从上面 T-Digest 的例子看，可能我们会觉得，开源协同就是要很多人一起讨论，得出一个结论以后再合并代码。但是，其实 Apache 软件基金会里有相当一部分成员，也包括我，一直都比较推崇 Commit-Then-Review 的模式。

这实际上就是 @xuanwo 前段时间所说的“漩涡独裁模式”：

稍微解释一下漩涡独裁模式：所有的 Issues / PRs 一经创建视为已经完成对辞达的贡献，我可以不经讨论对其做任意修改，我会保留作者原始的 credits，但是可能不保留任何代码换言之，我会默认 takeover PR 而不是进行 review

其实，我从刚开始参与开源时，接触的就是这种模式。毕竟在 Perl 6 团队里，推崇的是给每个人发 Commit 权限。代码都是版本控制系统管理的，出现什么问题回滚就好，天塌不下来。

一般而言，如果是设计问题，我会好好讨论，看看到底设计成什么样比较好。毕竟，PR 是否应该合并的首要问题是这个事儿本身要不要做。至于具体实现，在大方向和主要涉及确定之后，迭代优化都比较自然。

当然另一方面，我想现在这个话题被再次提起来的一种重要原因，就是开源社群当中越来越多 Autonomous Agents 提交的 PR 了，也就是完全没有人类参与，纯 Agents 扫描问题和提交补丁，你给 Review 也是收到一个自主 Agent 似是而非的答复。这种情况通常我是先确认问题是否存在，然后直接让我的 Agent 接管自主 Agent 的上下文搞定就行。

Attention Is All You Need, But Lack Of

前面提到，现在 AI 带来的产能升级，极大降低了 fork 或 rewrite 一个开源项目的成本。那么，是不是说开源的根基就彻底毁坏，所有人都直接让 AI 实现所需功能就可以了呢？

从现在发生的事情上看，显然不是。至少 Bun 和 Astral 这样属于应用开发入口级的开源项目，仍然能引起 AI 企业收购的兴趣。大模型在完成 Coding 任务时，往往高度依赖各类开源工具、库和框架。而且，AI 企业和云原生时代的地主巨头，在 AI 给全行业降本的当下，反而更愿意支持这些帮助它们的 AI 更好的完成任务的开源项目。

应该说，对于具体一个团队是否采用一个开源项目而言，直接 fork code 二次开发深度集成，变成了一个负担得起的选项，而不是像之前一样几乎想都不用想。但是，负担得起毕竟不是免费，哪怕不考虑 fork code 二次开发的 Token 开销，维护这个二次开发的人力成本也没有彻底消失。

大模型方案的研究方向有一篇名为 Attention Is All You Need 的著名论文。我在这里沿用其字面意思：随着软件工程规模化，以及软件本身成为社会生活方方面面都不可或缺的组成部分，其实开发者的注意力早就变成稀缺资源了。

无论是数据库这样的基础软件，还是应用服务这样的终端软件，无论如何，最终的研发团队都不可能构建、验证并维护所有它所需要的功能。哪怕你让 AI 来实现你的业务，它也会优先选择已有的开源方案来实现。如果你连这些基础方案也挨个让 AI 去实现，实际上大量的方案是缺乏完整的测试集的，于是你要投入人力去验收和测试 AI 生成的东西。

可能有人会来一句经典的 AI 维护就行，但是以目前 AI 的能力和实践而论，完全让 AI 自行迭代一个项目，结局就是认知负担持续累加，AI Context 不断磨损，项目逐步熵增，直至热寂。

所以，在人的注意力既必要又稀缺的情况下，开源协同以提供坚实的基础软件，就仍然很有必要。

那么下一个问题就是，什么软件是应该开源协同来创建的呢？这就又要回到软件工程最基础的项目定位和模块设计了。

比如，ScopeDB 的索引、统计信息和支持的函数，有些会依赖某种近似算法结构：

1. approx_count_distinct 起初依赖 HyperLogLog 算法，后来采用了改进的 FM85 算法
2. approx_quantile 依赖 T-Digest 算法，未来可能还会用 DDSketch 或者 UDDSketch 的方案
3. 部分索引依赖 BloomFilter 或 XorFilter 等算法

@andylokandy 在实现 approx_quantile 的时候，发现 Rust 生态里的实现都不太如人意，于是手写了一个 tdigests 库。我在实现 approx_count_distinct 的时候，也发现 Rust 生态里的实现都不太如人意，于是在 ScopeDB 内部 vendor 了一个 HyperLogLog++ 式的实现。

但是在这个过程里，我发现开源生态当中有 Apache DataSketches 这样的方案，其项目团队明显都是近似算法的专家，而且有丰富的实践经验。只可惜 DataSketches 没有 Rust 实现，而我在 2025 年初考虑这个问题的时候，当时连 Claude Code 都没有，实际上 AI 能帮上忙的也不多。

转机出现在 2025 年底，这个时候 @xuanwo 的兴趣点漂移到了 iceberg-rust 项目上，发现 Apache Iceberg 的 Java 实现依赖了 DataSketches 库，但是 DataSketches 没有 Rust 实现，所以直接 port 代码会有困难。@xuanwo 在 ASF 的圈子里寻找了解 DataSketches 的人，我正好在几个月前调研过，就跟他同步了一下情况。

然后 @xuanwo 就表示，要不要到 DataSketches 项目里提议搞一个 datasketches-rust 分支？我说如果你有空搞的话，你就发起这个讨论吧。于是就有了 proposal: datasketches-rust 的讨论。

抛开 @xuanwo 最后跑路没搞不谈，我印象深刻的是这个讨论激发了两个意料之外的收获：

1. 原先持有 datasketches 名字的 crate 作者在 DataDog 工作，且其同事已经深度参与开发 datasketches-go 并成为 DataSketches 的 PMC 成员；这个 Issue 吸引到了他，并且他愿意把 crate name 捐赠给 DataSketches 团队。后来，他也给 datasketches-rust 贡献了 HllSketch 和 BloomFilter 等算法，在我的推荐下成为了 DataSketches 的 PMC 成员。
2. 原来 DataSketches 的 PMC Chair Lee Rhodes 是支持搞分支的。我在调研 DataSketches 的时候提过 Issue 跟他交流过一些 Sketches 的实现问题，感觉好像不是很积极。后来我才发现大叔年纪不小，原来是代沟问题。

这个 Issue 里，还有一个印象深刻的发言，就是 Lee 的回复里写到：

please, please, don’t just throw stuff into this project and disappear!

我回复说：

At least @Xuanwo and I have been active ASF members for years, lol ;-)

但是 @xuanwo 最后跑路没搞，老李前两个月还问我说 @xuanwo 到底什么时候来 🤣

Anyway 我是没跑，迄今为止刷了 158 个提交，其中最近一轮爆发是在发布 0.5.0 前，使用自研发布前 Deslopify 提示词，两天刷了 45 个提交。此外，两年间我给 datasketches-rust 项目发展了 3 名新的 PMC 成员，虽然主要是为了发版的时候不用去求其他分支的人 😇

除了 ScopeDB 在依赖 DataSketches 项目，Tantivy 和 Foyer 等开源项目也用上了 DataSketches 的近似算法实现。我还了解到有其他数据应用在使用，现在 datasketches-rust 的下载量已经是所有分支断崖式领先的第一，有 450 万左右。

我在这里重新提一下 Bun 的例子，如果没有 AI Coding 的支持，其实 Bun 很可能无法跑得这么快。

我想说的是，随着 AI Coding 逐渐成为大众采用的编程方式，或许会有很多现有的开源项目受到冲击，变得不再需要或难以维护；但是，更多的开源项目会随着 AI 带来的生产力革新，如雨后春笋一样冒出来。

Fork 是好事还是坏事呢？我觉得都不是。这只是新的生产力在呼唤新的软件行业分工模式的一个过程。大家之所以想要 fork 二次开发，一方面是成本大幅下降，这件事能做了，另一方面也是现有开源生态的结构有很多大家一直以来都不满意的问题，之前只是受制于生产力的局限捏着鼻子认了。

但是最终，软件工程总是强调可复用的基础构件块。我想最有可能的情况是，一段时间的震荡以后，开源生态收敛成一系列主要适合 AI Coding 的基础构件块，并继续稳定运行和维护下去。

回看上面提到的 DataSketches 的例子，以其代码库的质量和项目范畴的界定，我很难想象它会遇到大规模分叉。

而且，现在的新项目几乎都还在重度使用 AI 之前时代开发出来的开源工具、库和框架，不是吗？

进一步说，AI 本身也在降低维护一个开源软件的成本。于是，我们可以看到：

1. 参与开源协同的人数在增加
2. 高水平程序员生产好的开源软件的带宽在增加

后一点我想毋庸置疑，以我自己为例，在 AI Coding 之前，我是无法维护这么多在 ASF 治理下，加上归属在 fast org 下的项目的。

至于前一点，我想到有蛮多人在社交媒体上担心未来的初级工程师要如何成长。其实，在开源项目不断增加，参与开源项目门槛不断降低的当下，加入一个有价值的开源项目，或者自己发起一个开源项目，都是比以前更简单，且非常适合个人成长的路径。

我可以看到在 Apache Maka (Incubating) 项目上快速成长的新人，也亲自在几个项目里指导过在校学生参与开源，其中有几位成为了具体项目的 Commit 或 PMC 成员。

所以，我对初级工程师的成长路径非常乐观。而且无论是 AI Coding 之前还是现在，其实对人才的判断一直都没有太大的变化：

The nominee should be a real human spending time on the project, taking actions bravely with caution, knowning when to ask for help.

AI Agent 到底还是一个生产力工具。或许，只是过往培训班三个月出炉，依靠背诵接口和固定方案就能生存的“码农”大军会被淘汰。但是这对行业来说，或许是一件好事。