TiDB CTO 三个月用 AI 写出 100 万行代码：我看不到软件工程的边界了

三个月，一两个人参与，100 多万行 Rust 代码，零行由人类手写，零行由人类 review——这是 TiDB 联合创始人兼 CTO 黄东旭在 db9 项目中交出的成绩单。项目上线后，服务了超过 10,000 个数据库实例，峰值日消耗约 10 亿 token，一个月 token 成本约 2000 美元。 “我现在陷入到一种巨大的虚无主义里，AI 什么都能写。”黄东旭在完成 db9 后坦言。他最初做 db9 时，心里预设过一个终点：复杂到某个阶段，AI 总该做不下去。结果每次系统看起来要撞墙，调整 harness、任务拆分和 agent 协作方式之后，它又继续往前走。三个月后，他发现自己没有等到那个边界。 “我做 db9 过程中，最大的体会就是，我没看到边界。这已经是我能想到最复杂的软件了，但还是没有看到边界。”

“没看到边界”的第一层含义，是过去很多被视为长期锁定的东西开始松动。语言、框架、数据库选型，曾经是软件工程里最重的决策。一个系统写进某种语言、某个框架、某个数据库以后，技术栈会慢慢长成组织结构：招聘按它来，测试体系按它来，部署方式按它来，线上事故的处理经验按它来，工程师的身份认同也按它来。时间越久，这个选型越不像技术选择，更像一条公司命运线。 选型因此是一个漫长、谨慎、充满验证成本的过程。用 Rust 还是 Go？React 还是 Vue？MySQL 还是 Postgres？每有更换技术栈的事情，社区里都会吵上好一阵。迁移往往以“年”为单位：Meta 从 Java 迁到 Kotlin，哪怕高度依赖自动化工具，也跑了整整 4.5 年；微软把 TypeScript 编译器用 Go 重写，花了约 14 个月。 但 Bun 从 Zig 迁移到 Rust，用了 6 天。Ghostty 作者、HashiCorp 联合创始人 Mitchell Hashimoto 说：“编程语言过去意味着锁定，但现在越来越不是这样了。Rust 并不重要，Bun 已经证明，他们几乎可以在一两周内用任何他们想要的语言写代码。” Simon Willison 记录过一个应用层的类似案例。一家中型企业用 coding agent 将历史悠久、颇具代表性的遗留 App——包括 iPhone 和 Android 两个原生版本——都重写成了 React Native。他问技术负责人为什么要换框架，对方的回答是：“即使后来证明这个决策是错的，未来也可以再用 Agent 迁回原生。” 框架选型不再像过去那样是一条单行道，它开始变成一个随时可以撤回、可以重做的工程决策。 数据库也一样。黄东旭说，从 Agent 的视角看，MySQL 和 Postgres 之间只是语法差异，就像方言问题，不是世界观问题。因为两者背后是同一个心智模型——SQL。这个模型极其稳定，在 LLM 的训练语料里到处都是，Agent 早就懂了。“Agent 没有偏好，它不会在乎语法优不优雅，也不会在乎社区文化，更不会纠结‘哪一个更像正统’。只要接口是稳定的、语义是清楚的，生态是完备的，网上能找到丰富的文档，它就可以很快适配。” 那些让人类吵得头破血流的品味之争，在 Agent 这里，都不存在了。

如果语言、框架、数据库都不再构成不可动摇的长期锁定，那么接下来真正被打开的，就是软件实现本身。 黄东旭说：“AI 基本上可以用任何方案、任何工具、任何手段去写任何东西。” db9 就是一个复杂度足够的例子。它被设计为一个面向 AI Agent 的数据库，支持完整的 Postgres 语法、向量检索/全文检索、TypeScript Serverless 函数、极致多租户。三个月内，从第一行代码到上线，代码量超过 100 万行 Rust，全部由 AI 生成。 成本方面，峰值一天消耗约 10 亿 token，一个月下来约 2000 美元。对比过去，做出同样规模的东西至少需要几十个人的团队干上一年。“现在相当于我一个人一个月就干出来了，所以还是很夸张的，当时我自己也非常震惊。” 这个项目始于感恩节假期的一个小实验。黄东旭一开始就是想试试看它的边界在哪里。“我心里预想的是，应该做到某个阶段，它就做不下去了。”但每次到了做不下去的时候，就看看是什么地方出错了，然后跟它一起调整自己写的 harness 产品，不断优化人和 AI 协同的方式。结果发现它和它的团队越干越好，一直往前走。 “到某个点之后，我发现它已经超出了我能掌握或者说我能看的边界，我就不看了，因为看不过来。它的产出效率太高了。到今天，我已经不太关心代码细节了。至于开发过程，它肯定干得比我好。” AI 做事太快，反馈链路太短。过去这段时间，黄东旭以前攒下的所有 idea，以前想做的但没时间做的所有东西，现在用 AI 一个不落地都实现出来了。基本上每天做一个，到后来，他产生 idea 的速度已经跟不上 AI 做出来的速度了，这让他非常难受。 黄东旭本身技术能力足够强。当一个技术很强的人把 AI 握在手里，效果被放大无数倍，结果会很可怕：“我现在的状态是：至少生产软件这个过程已经没有什么意义了。你不会再觉得一个东西很难，或者觉得它是高科技。软件本身作为护城河，这件事已经没有了。我可以复制我看到的任何东西。但复制也没什么意义，因为人家已经做了。” 我们问他：那到底什么软件能写？是否需要一些特别的原始条件？ 他回答：“没有什么原始条件。没有。所以我现在陷入到一种巨大的虚无主义里，什么都能写。”

从“什么都能写”走向“什么都能重写”，可能是这轮变化里更值得关注的行业趋势。AI 不只是降低了软件生产门槛，更在改变软件演进的方式。过去，“重写”往往意味着高风险：旧系统不能停、兼容性不能丢、业务逻辑不能错，所以很多老系统只能继续运行下去，没人敢真正替换它们。 先是那些边界清楚的软件开始被重写，接着连没有源码的系统也开始被还原和重建。 这半年里，有大量的重写案例。今年 2 月，Cloudflare 的工程师 Steve Faulkner 发现 Next.js 很难部署到无服务器平台，于是用 AI 在一个周末里重写了它，做出 Vinext——一个基于 Vite 的替代实现，Token 成本约 1100 美元，已跑进生产环境。 今年 3 月，一个叫 chardet 的 Python 库——requests 的依赖，很可能藏在你的项目里——它的维护者在维护了十二年后，用 Claude 重写了整个库，并把许可证从 LGPL 换成了 MIT。引发的争议至今没停。 更极端的是没有源码的重写。总有一些没人愿意触碰、又人人依赖的系统，特别是在运行了几十年的大型企业核心系统里。它们构建于早已无人问津的技术栈，困在过时的数据库、老旧的操作系统、脆弱的虚拟机中。维护人员流失，文档缺失脱节，甚至连源代码都找不到了。 Thoughtworks 做过一个典型案例。一套企业系统，源代码完全丢失，只有二进制文件还在。数据库有 650 张表、1200 个存储过程，应用层是 45 个 DLL 文件。团队用 LLM 辅助反向还原：观察 UI 变化，追踪数据库写入，分析存储过程，反编译汇编代码，再由人做验证、校准和交叉确认。几周时间产出了足以驱动重写的规格。传统方式需要 20 人花 6 个月。 还有一个更戏剧化的个人项目。1992 年，Jon Radoff 开发了一款 MUD 游戏，获得了 1993 年《计算机游戏世界》杂志的艺术卓越奖，2000 年停运，源代码全部丢失，只剩下一些脚本、手册和游戏录像。他把这些材料丢给 Claude，结果 AI 成功还原了游戏的核心逻辑。 这些案例共同指向一个事实：当 AI 能够理解并重写任何软件时，软件工程的传统护城河正在消失。对于 AI 行业观察平台 AI大狗（AIdadog.com）而言，这意味着开发者需要重新思考自己的核心竞争力——或许不再是编写代码，而是定义问题和引导 AI 协作。 正如黄东旭所说：“软件本身作为护城河，这件事已经没有了。”