一个系统工程师的十年：PingCAP 黄东旭眼中的数据库、云与 AI

“软件工程发展这么多年，大家最后会发现，这个系统的最大短板其实是人。”

INTRO

十年前，黄东旭和另外两位创始人联合创办 PingCAP，推出了 TiDB，将先进的分布式数据库系统设计推向国内，并建立了高度研究驱动的分布式系统技术社区，推动了 Paxos、Raft 算法，容错性系统和混沌工程理念的普及，激励了一批工程师的共同探索，见证中国互联网高歌猛进的时代和云计算产业的崛起。如今，站在AI浪潮前，这位有着研究者敏锐性和创业者思维的工程师，又将开始怎样的探索？

本篇为访谈提要。访谈双语全文请前往此处阅读：中文版 | English Version

Transcript & Translation: Carrie

Visuals & Editor: dca5 & Shiyu

Intro: Jiang

在加州，黄东旭向我们讲述了一个跨越十年的故事。他是一位典型的开源“黑客”、常在野外的户外爱好者、音乐人，也是知名开源数据库公司 PingCAP 的联合创始人。十年来，他的身份标签并没有改变：（研究型）工程师。

“Papers We Love”是一个分享论文的分布式活动组织，聚集同好们既讨论计算机方面的论文，也分享关于工程架构的思考。在本次的“Papers We Love”，黄东旭与同行同类们回顾了自己所经历的那些年，用一种独有的技术哲学微缩了顶级工程师在剧变时代不断涨落的热望与创想。

Codis 缘起：深夜机房里的“不得不做”

“operating system（操作系统）、compiler（编译器）、database（数据库）”，黄东旭说，这是程序员圈子里公认的“三大浪漫”。几乎每个热爱编程的人，都希望能有朝一日亲手打造一个属于自己的设计。十年前，PingCAP 的三位创始人正是怀着这样单纯的理想，一头扎进了数据库这个最硬核的领域。

但硬核的浪漫都是难啃的骨头。当时，黄东旭和后来 PingCAP 的 CEO Max 还在豌豆荚工作，负责维护公司的 MySQL 数据库。豌豆荚业务增长飞快，数据量爆炸式增长。因为 MySQL 是单机的数据库，面对海量数据时，他们唯一的解决办法就是“分库分表”，而他们觉得应该从更加根本的方式解决问题。

“所有做数据库的朋友都知道，（分库分表）这是个噩梦一样的词。”黄东旭回忆道。为了不影响白天的业务，所有扩容和维护都基本上要在深夜进行。他和 Max 只能经常通宵处理数据，“天天在倒腾数据、换分片，觉得很痛苦。”

更让他们受挫的是，业务团队也怨声载道。因为被“肢解”后的数据库，丧失了很多基础的功能，开发人员感觉自己处处受限。“我们属于两头受气：一方面感觉自己阻塞了业务，总被甩锅；另一方面自己也觉得维护这东西非常费劲。”

转机来自一个小小的“无心之举”。因为要解决 Redis 的 scalability（可扩展性）的问题，他们写出了一个叫 Codis 的开源项目。Codis 在当时的业界是几乎唯一的开源的分布式 Redis 解决方案。因此，这个花了他们两周时间写就的项目迅速火遍了中国互联网圈。

这个他们意料之外的结果，也了他们非常关键的启示。“那时候我们就发现，如果你真的解决了一个非常重要的问题，就会被人用。于是我们就想，为什么不把 MySQL 的扩展性问题也一起解决了？”

当时他们还看到 Google 在 2012 年跟 2013 年发表的两篇论文（一篇论文是 Google Spanner，另外一篇是 Google 发表了的 F1）。这两篇论文给了他们极大的鼓舞，证明了“分布式数据库”这条路是可行的。“我们得到的最大启发是，这件事情是可以被人类做出来的。”

基于上述两个启示，当时的黄东旭给出了他的下一个推论：“既然如此，反正我们是世界上最好的工程师，为什么我们不能做出来？”

底气：“我们只做工程师喜欢看的东西”

就这样，三个毫无营销经验的程序员，通过给投资人在黑板上画系统架构的方式，在当时中国VC的黄金时代，幸运地拿到了第一笔融资。

在提及产品营销相关的经历时，黄东旭的观点同样充满了“工程师式”的耿直。他去考察了当时流行的技术软文，看完后“非常生气”。“从工程师的角度一看，就知道这是广告，很水。”

于是他们决定反其道而行之。“我们不会做别的，我们只会做开源社区，我们只会在开源社区里面去讲我们这东西怎么做的。”当时他们每周举办线下技术分享会，像“Papers We Love”一样，和社区的工程师们一起探讨最新的论文和技术实现。他们靠着真诚的态度和深度的内容，吸引了最早的一批受众和贡献者。

黄东旭提到他自己喜欢社群中人和人之间的分享与交流，这种源于“自己喜欢”的社区驱动模式，填补了当时市场的空缺，也最终成为了 PingCAP 最坚固的护城河。

在 PingCAP 创立初期，黄东旭面临着一个关键的技术路线选择：是基于 MySQL 进行改造，还是从零开始构建一个全新的分布式数据库。

起初，他的想法和大多数人一样是进行改造优化，但很快他就发现了问题的核心所在：传统单机数据库的 SQL 执行引擎和优化器都不是为分布式存储设计的。他意识到，“当你想要去做这些针对分布式场景的优化时，基于一个已经存在20年的系统是无法实现的。如果要让这件事的天花板更高，就必须从头构建。” 

Google Spanner 项目的 Jeff Dean 在被问及为什么 Spanner 要重新构建时，也给出了相似的理由：“当你基于现有系统进行改造时，会发现自己的手脚都被束缚住了。”

因此，PingCAP 用 Go 和 Rust 重新写了整个数据库系统，虽然从零开始是一条更加困难的道路，但它意味着更高的天花板和收益，为 TiDB的成功奠定了基础，让数据库真正进入云时代。

事实证明，这些基于工程师直觉和技术信仰的“反常识”决策，几乎都是正确的。

从以人为中心的系统设计到以 AI 为中心的系统设计

当谈到数据库的现状时，黄东旭的语气变得有些“无聊”。他认为，过去五年，除了云技术带来的基础设施的范式变革以外，这个行业并没有太多让他兴奋的东西。

因为，所有数据库——无论是 PingCAP 的 TiDB，还是声名显赫的 Snowflake——都面临一个根本问题：它们仍然是为人类程序员设计的。

“我非常痛恨 API（Application Programming Interface，应用程序编程接口）这个词，”黄东旭说，“未来，数据库的终端用户不再是人，而是AI Agent（智能体）。”

在他看来，AI 使用数据库的方式与人类截然不同。人类程序员写的查询大多是固定的、可预期的；而 AI 为了完成一个任务，会即时（ad-hoc）地、创造性地生成各种复杂的查询，它会像一个不知疲倦的侦探，主动组合关系数据、全文检索、向量搜索等多种工具，从海量信息中探寻答案。

那么，为 AI 设计的数据库会是什么样？黄东旭给出了一个极简的答案：它将不再有复杂的 SQL语言，而是像今天的 ChatGPT，会有两个接口：第一个是存储接口（save/memorize），可以存储任何自然语言数据；第二个是查询接口（chat/query），可以用SQL或自然语言问任何关于数据的问题。背后会连接各种 MCP 工具来处理数据——知识图谱、向量化、全文检索、SQL等。

在他看来，未来就不再以人类的交互方式设计接口了，而是将大部分复杂性将由系统/Agent 屏蔽在简化的接口之后。

编程的主语在更换

这个构想自然延伸到了编程领域。黄东旭坦言，自己现在可能 90% 的代码都是 AI 写的，但他认为这还远远不够。

这是黄东旭对当下 AI 编程工具热潮的冷静反思。他认为，像 Cursor 这样以“辅助程序员”为中心设计的产品，本质上还是把人放在了驾驶位，即便此类 AI 产品几个月就实现亿级美金的 ARR，也只是一个短暂的“童话故事”。其背后的原因仍然与人类中心主义有关：“（Cursor）仍然是以程序员为中心去设计产品，AI 只是你的副驾驶。但人是愚蠢的动物，就编程这件事来说，AI 能做得比人好，人的限制反而束缚了AI的手脚。”他更看好另一种范式：以 AI 为中心。在这种模式下，人类的角色不再是写代码的“码农”，而是给 AI 下达指令、定义目标的真正的产品经理。

“AI 写的代码还要人去维护，这件事本身就是错的。”黄东旭认为这是思维方式的变化，他相信未来的方向会从 AI 辅助转变为AI自主。如果人类能实现足够的“放权”，AI 或许就能打通整个闭环：未来的软件工程会由 AI 自己写代码，自己部署，也由它自己来修复漏洞、发布版本等等。虽然黄东旭现在的研究团队还是“以人为主、AI 为辅”地写代码，但他也直言未来或许会有更疯狂的想法，可能到了某个阶段，他不再会允许人来写代码。

在分享的最后，一名提问者将问题再往前推了一步：

“我觉得软件工程不管是人还是 AI 来写，归根结底要控制的是软件工程当中的熵。人和机器都会写出奇怪的东西。我们面临的问题可能并不是假设 AI 变得非常聪明就可以解决的。因为即使非常聪明的人在一起，他们可能写出来的复杂系统也会比较混乱。”

黄东旭从“上限”的角度回答了这个问题：从复杂度控制的角度，人跟一个精心设计的 AI 或计算机系统来说，上限是很有限的。而 AI 作为系统本身，先天在对复杂系统的理解上更有优势。

“软件工程发展这么多年，我觉得最后大家会发现，这个系统的最大短板其实是人。” 他诚恳地从一个人类工程师的角度，这样说道。