3天，19,000 行代码，一个能跑的数据库引擎。
这事儿要是放在几年前，你敢信？
但就在 2026 年 2 月，开发者 Kian Kyars 真的这么干了。他没找外包，也没通宵达旦，而是把 Claude、Codex 和 Gemini 扔进了一个“代码斗兽场”，让它们自己把自己变成了 SQLite。
Parser、Planner、B+树、WAL 日志、事务语义……这些让计算机系学生头秃的概念，这帮 AI 不仅全实现了，还顺便写了 282 个单元测试，而且全绿。
代码就躺在 GitHub 上，跑得通。
把 Git 当成交通指挥灯
Kian 干了一件很有意思的事：他把软件工程当成了分布式系统。
在这个实验里，AI 们不是在聊天框里陪聊，而是直接在命令行里干活。他搞了一套名为 "Harness" 的脚本系统，相当于给每个 AI 发了一个工牌和任务卡。
整个流程分两步走。
先是 Bootstrap 阶段，Claude 负责打地基，生成项目骨架、设计文档和测试框架。
接着是 Worker 阶段，重头戏来了。6 个 AI Worker（2 个 Claude、2 个 Codex、2 个 Gemini）开始无限循环干活。
它们的工作逻辑简单粗暴：
- 拉取最新代码；
- 认领一个任务；
- 写代码，然后拿真正的 SQLite 当“老师”来验证结果；
- 推送代码。
这就好比把一群顶级程序员关在一个屋子里，唯一的规则是：代码跑不通不准走，冲突了解决不了不准提交。
一半时间都在“抢锁”
但这事儿真有那么丝滑吗？
并没有。
Kian 翻了翻提交记录，发现了一个尴尬的数据：在 154 次提交里，有 84 次——也就是 54.5%——都是在处理锁、声明任务、清理过期锁。
这像极了我们在公司里开无效的会，或者在 Git 上解决冲突。
这说明什么？说明并行开发的代价是巨大的。哪怕是没有情绪、不会累的 AI，在处理共享状态时也会“打架”。
Kian 在总结里也说了，并行吞吐量高度依赖锁的卫生状况。这帮 AI 为了不踩到彼此的脚，花了一半以上的时间在协调步调。
我个人觉得，这反而让整个实验显得更真实。它证明了代码不仅是写出来的，更是“管”出来的。
代码质量：是奇迹还是垃圾？
实验做完了，库也建起来了，但外界的评价却两极分化。
有人在 Hacker News 上直言不讳：代码写得并不好。不管是质量、性能还是代码库的大小，都跟真正的 SQLite 没法比。而且测试覆盖率也很存疑，所谓的 Oracle 测试看起来只有三个简单的 SELECT 语句。
我不太认同完全否定。
虽然代码可能很臃肿，但有个思路我觉得特别牛：Oracle-style validation。
让 AI 去模仿 SQLite 的行为，拿 SQLite 的输出当标准答案。这本质上是一种自动化的逆向工程。正如一位评论者所说，这是 AI 最擅长的事情——通过观察输入输出，推导出背后的逻辑。
当然，Kian 自己也承认，文档量变得巨大无比，光是 PROGRESS.md 就有 490 行。那个专门用来去重的 Coalescer Agent，因为任务太重，跑到一半还挂了。
谁才是赢家？
在这场混战里，谁的表现最好？
说实话，很难说。因为每个平台的计费格式都不一样，Kian 根本没算清楚谁烧的钱最多。
只知道 Codex 的 Pro Plan 周额度被用光了（当时还在搞 2 倍促销），Claude 用了 70%。
有意思的是，只有 Claude 会自作多情地在 Commit 信息里把自己加为 Co-author（合著者），Codex 和 Gemini 就没这毛病，闷头干活。
这不仅仅是炫技
抛开代码质量不谈，这个实验其实暴露了一个很深刻的趋势。
未来的软件开发，可能真的不再是人盯着屏幕一行行敲，而是人定义好“模块边界”和“真理来源”（比如测试用例），然后放出一群 AI 去填空。
正如 Kian 的感悟：给 Agent 一个狭窄的接口、一个共同的真理源、快速的反馈，你就能在真实的系统代码上获得复利的吞吐量。
但是，这种模式真的能取代人类吗？
我看未必。那个半途而废的去重脚本，那个庞大到无法维护的文档，还有那 54% 的协调开销，都在提醒我们：
代码写得快是一回事，写得对、写得优雅，完全是另一回事。
如果让你带一队这样的 AI 员工，你敢把项目交给它们吗？
参考链接：
https://kiankyars.github.io/machine_learning/2026/02/12/sqlite.html