一、数据库奠基人的警示：计算机行业红利消退

2026年1月，一则消息在技术圈引起了不小的波澜。2014年图灵奖得主 Mike Stonebraker 在一场播客对话中，给出了一个让许多从业者和准备入行的人感到意外的建议：他不太确定是否要推荐十八岁的年轻人去主修计算机科学，反而认为医疗和建筑业是更稳妥的选择。这话出自一个在计算机领域凭硬功夫拿了图灵奖的人之口，分量自然不一样。Stonebraker 的职业生涯几乎是一部浓缩的数据库发展史——从 Ingres、Postgres，到 Vertica、VoltDB、SciDB，再到最近的 DBOS，每一个都是真正成就了诸多商业公司的工程系统。他的判断，绝不是随便说说。

Stonebraker 的这番话，其实是建立在三重现实观测之上的。第一层，是他对行业红利的观察。他这一代人赶上了计算机从实验室走向商业化的黄金时代，从关系模型的验证到开源数据库的普及，再到云数据库的商业化，每一次技术跃迁都释放出巨大的职业红利。但如今，基础层的创新已经高度成熟，数据库、操作系统、编程语言等核心基础设施的格局基本固化，新的增长更多是存量竞争和微创新。这不是主观感受——他团队在真实生产数据仓库环境做的测试结果，从数据层面印证了这一点。第二层，是 AI 和数据库结合的现实瓶颈，这一点后面会展开说。第三层，是对科技公司战略的批判性审视。Stonebraker 说话一向直接，谈到 Oracle 创始人 Larry Ellison 时，他说那人“把现在时和将来时混为一谈，本质上是在对客户撒谎”；说到 Google 当年的 MapReduce 和最终一致性策略，他说那“不是 Google 唯一一件愚蠢的事”；谈到亚马逊同时维护十五个数据库系统，他说“多了十二个”。这些判断背后，是他对基础技术路线选择一贯严格且务实的标准。

将这些观测综合起来，可以得出一个清晰的判断：Stonebraker 并非在否定计算机本身的价值，而是在警示一个结构性变化——过去几十年那种因为“会写代码”就能获得超额回报的窗口期正在收窄。当一个行业的基础设施已经足够成熟，底层创新从“每五年一次范式转换”变为“每十年未必有一次根本突破”，那么对这个行业人力需求的结构也会随之改变。他的建议之所以值得认真对待，是因为他本人就是那个定义范式的人。当一个奠基者开始建议年轻人不要轻易踏入自己开拓的领域时，这本身就是一个值得行业严肃反思的领先指标。

二、硬核测试揭秘：大模型写SQL准确率仅为0%

Stonebraker在播客中甩出的几个数字，堪称对当前大模型SQL生成能力的一记重锤。在公开基准Spider、Bird上，最好的模型已经能拿到85%的准确率——这个数字看起来很漂亮，似乎距离生产只差临门一脚。但Stonebraker团队用四个真实生产数据仓库构建了一个名为Beaver的新基准，在这个基准上，大模型的准确率是多少呢？0%。这不是某个特定模型的偏差，而是所有参测模型的共同结果：在真实的生产数据仓库场景下，它们写不出一条正确可用的SQL。

这个“0% vs 85%”的反差值得深挖。公开基准测试之所以漂亮，核心原因在于它们被“简化”了。Spider和Bird面向的是相对干净、预先设计好的数据集，表结构清晰，关联关系明确，查询意图和模式已被训练数据大量覆盖。但真实的生产数据仓库是什么样子？表动辄数百列，命名充满内部缩写和历史遗留，join路径深达五六层，同一概念在不同表中以不同名称出现。Stonebraker团队把RAG（检索增强生成）加进去后，准确率也只升到10%；进一步把join条件直接喂给模型，最高才到35%。而一个懂schema的人类SQL工程师，在这个同样的测试下能做到90%以上——不仅是理解语义，更重要的是能辨识数据质量的“坑”：哪些字段冗余、哪些唯一标识符不可信、哪些join会导致数据膨胀。

这说明一个本质问题：当前大模型的SQL生成能力，本质上停留在“句式模仿”层面，离“语义理解”和“数据语境认知”还差得很远。公开基准的竞争让大家以为这条路快跑通了，但一旦脱离训练数据分布，真实世界的复杂度立刻把模型推回原点。这在技术演进史上并不新鲜。上世纪80年代专家系统风靡一时，很多企业在演示环境里跑得很漂亮，一上生产就出故障，原因也是“现实世界远比训练集复杂”。Stonebraker带着团队设计Beaver基准，本质上是把聚光灯从好看的排行榜拉回到工程实践的边缘条件上——哪些场景能跑、哪些跑不了，这才是选择技术方案时应关心的问题。

从行业观察者的角度看，这个测试结果应该促使从业者重新审视“大模型替代DBA”的叙事。这不是否定大模型作为辅助工具的价值，而是在界定它的边界：它可以在查询模板匹配、简单过滤条件生成、语法修正等场景中帮助提升效率，但涉及复杂join、业务规则推导、数据质量判断时，它目前不具备可替代性。我在过去十余年的数据库运维实践中，衡量一个工具是否能上生产的核心指标，不是它处理99%常规任务的效率，而是它遭遇那1%异常情况时的处理能力。大模型在Beaver基准上的表现恰好暴露了它在后者上的根本性短板。正如Stonebraker所断言的：“这项技术，至少在可见的未来，还不够格进生产。”这一结论并非悲观，而是基于对工程严谨性的尊重。

三、从第一性原理看AI写SQL：未能突破事务与一致性的基本约束

Stonebraker 在播客中指出，当前多数 agentic AI 仍停留在“只读”阶段——给一个客户算个分、出个预测，并不真的去改数据库里的字段。这句话看似轻描淡写，实则点出了 AI 在数据库领域的根本性天花板。一旦 agent 开始做读写操作，比如两个 agent 协作完成一笔转账，问题就立刻落回数据库的老地盘：事务、一致性、原子性。这些不是学术概念，而是银行对账、库存扣减、订单状态变更时每一毫秒都在面对的生产级铁律。AI 在理解自然语言、匹配统计模式上固然有进步，但面对 ACID 这四个字符背后数十年的工程积累，它至今没有拿出任何实质性解决方案。这不是算力或数据量的问题，而是问题性质的根本不同：事务的正确性不能用“概率”来逼近，转账要么完成要么不做，不存在“90% 成功”这种说法。

更深一层看，大模型写 SQL 的本质是统计模式匹配，而非理解数据语义和业务逻辑。Stonebraker 团队用四个真实生产数据仓库构建的新基准 Beaver，暴露了这一点：最好的大模型准确率为0%；加上 RAG 也只到 10%；把 join 条件直接喂给模型，最多到 35%。而一个懂 schema 的 SQL 工程师能做到 90% 以上。这组数据的意义不在于数字本身，而在于揭示了一个结构性断裂——在公开基准 Spider、Bird 上，最好的模型已能拿到 85% 准确率，看起来差一步就能上生产。但公开基准的特点是 schema 简单、查询模式固定，本质上是在考察“见过的模式是否记住”。而真实生产环境中的数仓，常涉及数十张表的复杂关联、字段命名的不规则性、历史遗留的冗余逻辑，这些因素叠加后，统计模式匹配立刻失效。这让我想起数据库领域一个经典教训：早期试图用“自然语言查询”替换 SQL 的尝试，最终全部以失败告终，不是因为语言不够好，而是因为业务语义的精确性无法通过近似匹配来保证。

回顾技术史，无论是关系模型还是 SQL 本身，它们的成功恰恰在于定义了不可动摇的基本约束。Codd 的关系模型之所以战胜 CODASYL 和 IMS，不是因为它在所有场景下性能最优，而是因为它提供了数据独立性——逻辑层与物理层的分离，让 schema 变更不再需要“把所有东西扔了重来”。SQL 的成功也类似：它用一套声明式语法，让用户描述“要什么”，而不是“怎么取”，从而为查询优化器的演进留出了空间。这些突破都有共同点：它们没有绕开数据库的基本问题，而是正面解决了它们。反观当前 AI 写 SQL 的路径，它试图用统计模型绕过语义理解，用海量训练数据覆盖模式，而不是去解决“模型是否真正理解 join 条件背后的业务含义”这一核心问题。这就像试图用更多轮子的马车去追赶火车——方向如果不对，提速只会让偏离更远。据此推测，至少在可见的未来，AI 写 SQL 进生产这件事，不具备技术可行性。真正的突破可能不会来自更大的模型或更多的训练数据，而来自对数据库基本约束的重新思考——而 Stonebraker 本人，正是在这条路线上不断推动的人。

四、技术成熟度评估：AI写SQL仍处概念验证早期

Stonebraker 团队用 Beaver 基准做的那组测试，本质上是一次“可靠性压力测试”。在 Spider 和 Bird 这类公开基准上，最好的模型已经能拿到 85% 的准确率，这个数字乍看很接近投产水平。但要理解这个差距有多大，先要搞清楚这两个基准的定位。Spider 和 Bird 本质上是学术竞赛数据集，它们的问题设计有明确的边界：每个问题对应固定的表结构、已知的 join 路径、不存在数据倾斜和业务歧义。就像在一个封闭考场里考 SQL，所有条件都是摆好的。而 Beaver 测试的是“真实生产数据仓库”里的任务，那里的 schema 往往有几十上百张表，字段命名不规范、join 逻辑隐含业务规则、同一个结果可以用三种不同写法实现——这才是数据库工程师日常面对的真实环境。

Stonebraker 给出的数字链条非常清晰：

这组数据的核心含义是：从公开基准到真实环境，准确率从 85% 直接跌到 0%，这不是“再调调就能上生产”的差距，而是模型是否能理解实际业务语义的根源性差距。哪怕加上 RAG（检索增强生成），把相关表信息和文档注入 prompt，也只到 10%。即便我们把最关键的 join 关系直接告诉模型，它也只能做到 35%，而人类工程师能做到 90% 以上。这 55 个百分点的差距，恰好落在了数据库工程师最核心的价值上——理解业务逻辑、识别歧义、在复杂的 schema 中找到正确的执行路径。

按照技术成熟度曲线（Technology Hype Cycle）来分析，text-to-SQL 目前所处的位置就非常清楚。公开基准上 85% 的准确率让它看起来正在接近“主流采用”的门槛，学术论文和厂商宣传稿都倾向于放大这个信号。但 Beaver 测试把这一进程直接打回了“概念验证早期”——在真实环境中还远不具备工业级可靠性。要实现真正可用，横亘在面前的障碍远不止模型精度提升这么简单：

• 定制化 schema 理解：每个企业的数据仓库 schema 都是独特的，模型需要理解字段命名习惯、隐含的业务规则、历史遗留的历史前缀等上下文，这是通用预训练无法覆盖的。
• 高成本的 RAG 流程：要把 schema 文档、数据字典、历史查询案例塞进 prompt 里，token 消耗巨大，而且 RAG 本身也会引入新的错误——检索到的文档未必正确，多轮对话中的上下文可能被稀释。
• 人工监督与纠错：即使模型生成了一条语法正确的 SQL，业务语义是否准确也需要人工逐一验证。这跟直接让工程师写 SQL 相比，只是把写的过程变成了审的过程，效率提升有限，而且审错 SQL 的风险依然存在。

目前 Google、微软、OpenAI 等厂商都有面向 text-to-SQL 的产品或功能，Salesforce 也有基于 NLP 的查询工具。它们在一个界限清楚的单表查询场景里体验不错，能帮助企业做一些低门槛的数据探索。但一旦涉及生产级的数据仓库任务——跨 10 张以上的表做复杂 join、涉及时间窗口聚合、需要在查询中嵌入业务规则判断——这些产品就退回了“可演示但不可信赖”的状态。Stonebraker 那句“至少可见的未来还不够格进生产”，不是保守，而是基于实际测试数据的冷静判断。

从我这个在数据库领域从业十几年的观察者角度看，这个局面其实不意外。SQL 从来不只是“用自然语言描述查询需求然后转成语法”这么简单，它是对数据模型、业务逻辑和系统约束的综合理解。AI 目前在很多任务上表现出了惊人的模式匹配能力，但它仍然不懂“如果这个字段为空怎么办”“这个 join 是全连接还是左连接更符合业务预期”这类需要判断力和业务知识的问题。真正的突破可能不会来自更大的模型或更多的训练数据，而来自一个根本前提的重新建立：AI 必须学会理解数据与业务之间的映射关系，而不仅仅是语法转换。在那之前，text-to-SQL 在企业级生产系统中的市场渗透率，我认为仍将停留在极低的水平——就像 Beaver 测试沉默地宣告的那样，0%。

五、系统思维下的连锁影响：专用数据库与AI的错位竞争

Stonebraker 对行业巨头的数据库策略毫不留情。他批评 Larry Ellison 时，直言那人“把现在时和将来时混为一谈，本质上是在对客户撒谎”；谈到 Google 当年力推的 MapReduce 和最终一致性，他说“那不是 Google 唯一一件愚蠢的事”；而面对亚马逊同时维护着十五个数据库系统的现状，他的评价更直接——“多了十二个”。这些看似尖锐的个人表态，背后是一个系统设计者从根儿上的判断：专用数据库远优于通用的万金油方案。

他用自己的履历为这个判断背书。从 Ingres、Postgres，到 Vertica、VoltDB、SciDB，再到最近的 DBOS，每一行代码最终都长成了商业公司的核心引擎。他的逻辑链条很清晰：真实世界的负载千差万别，一个时序分析场景、一个高并发事务场景、一个科学计算场景，对存储模型、索引结构、查询优化器的要求截然不同。用一台“通用机器”去适配所有场景，必然要在某些维度妥协——要么牺牲性能，要么牺牲一致性，要么牺牲运维的简洁性。这和 Oracle 的闭环商业策略、Google 试图用 MapReduce 一招通吃的做法、亚马逊维护十几个风味各异的数据库却仍不觉得够用的局面，形成了根本冲突。

那 AI 在面对这种复杂性时表现如何？Stonebraker 的团队用行动给出了答案。他们为真实生产数据仓库定制了一个新基准 Beaver，不是为了刷排行榜，而是为了暴露问题。结果触目惊心：在 Spider、Bird 这些公开 text-to-SQL 基准上，最好的模型已经能拿到 85% 准确率，看起来差一步就能上生产；但在 Beaver 上，大模型的准确率是 0%；加上 RAG 也只到 10%；把 join 条件直接喂给模型，最多到 35%。而一个懂 schema 的 SQL 工程师能做到 90% 以上。这组数据揭示了一个关键事实：公开基准经过大量样例训练和过拟合，已经不能衡量真实工业场景中的“理解能力”。真实数据仓库中复杂的业务实体关系、历史遗留的脏数据、潜规则式的字段含义，大模型目前根本无法建模。

由此可以得出一个推论：未来 3-5 年，AI 在数据库领域的真正突破口，不会是“用一个大模型去理解所有数据库”，而是“针对某个专用数据库，用精心设计的 AI 策略去辅助特定任务”。比如在 Vertica 这样的列存分析数据库中，AI 可以帮助优化物化视图的选择策略，或动态调整压缩算法的参数；在 VoltDB 这样的内存关系数据库中，AI 可以预判事务冲突热点，辅助分区键的设计。但这要求 AI 系统本身必须理解底层存储引擎的设计哲学——这正是当前通用大模型最欠缺的能力。要彻底重构现有技术路线，让 AI 从“学语法”转向“学物理设计”，这需要新一轮的基础研究，而不是在现有的 NLP 模型上加一层 RAG。

六、趋势研判与启示：计算机行业的真实门槛正在提高

Stonebraker 的警告——“不确定是否要推荐十八岁的小孩去主修计算机科学，医疗和建筑业是稳妥的选择”——在整个对话中分量极重。它不是一个功成名就者的故作惊人之语，而是一个在数据库领域深耕五十年、亲眼见证了计算机从实验室走向每个桌面、每个数据中心的亲历者，对行业当前状态做出的冷静判断。我们需要拆解这个判断背后的逻辑。

Stonebraker 的核心论据之一来自真实生产环境的测试。他的团队构建了一个名为 Beaver 的新基准，基于四个真实数据仓库，在这个基准上，大模型写 SQL 的准确率是 0%；加上 RAG 后提升到 10%；即便把 join 条件直接喂给模型，最高也只到 35%。而一个懂 schema 的 SQL 工程师能做到 90% 以上。这组数字揭示了当前 AI 能力的真实边界：在公开的学术基准 Spider、Bird 上，最好的模型已经能拿到 85% 的准确率，看起来差一步就能上生产。但Stonebraker的团队用真实业务的数据仓库去测，结果直接归零。这个差异说明了什么？公开基准和真实生产环境之间的鸿沟，恰好是计算机行业从增量红利转向存量竞争的缩影。在增量红利期，市场快速扩张，只要会写代码就能找到工作，标准化的任务占据了主导。而在存量竞争期，考验的是解决真实世界复杂问题的能力——理解业务 schema 背后的语义、处理数据质量不一致、应对各种边界情况。这些是通用模型短期内难以跨越的门槛。

结合 Stonebraker 对其他数据库厂商的批评，我们可以看到更深层的趋势。他说 Oracle 的 Larry Ellison“把现在时和将来时混为一谈”，是指技术承诺和能力交付之间的差距；他说亚马逊“多了十二个”数据库系统，是对过度复杂化技术栈的质疑；他说 Google 的 MapReduce 和最终一致性“不是唯一一件愚蠢的事”，是对技术路线选择失当的直言。这些批评的共性在于：当行业从“造轮子”阶段进入“用轮子”阶段，真正有价值的能力不再是做出一个能跑的原型，而是做出一个能在生产环境稳定运行、性能达标、便于维护的系统。Stonebraker 本人用 Ingres 和 Postgres 证明过这种能力——“Ingres 我们先投入了第一个 90% 让它能跑起来，然后不知道为什么，又投入了下一个 90% 让它真正好用”。这种对工程质量的极致追求，恰恰是当前技术泡沫中最容易被忽略的。

对这一趋势的应对，可以从两个层面来看。对已经在行业内的从业者而言，与其追逐 AI 泡沫的短期热点，不如深耕数据库、系统等基础领域。Stonebraker 的事业轨迹是很好的例证：从 Ingres 到 Postgres，再到 Vertica、VoltDB、SciDB、DBOS，他没有在各个热点之间切换，而是在数据管理这个主线上不断深化。每一次他都在针对上一代系统的局限提出新的解决方案。对正在考虑职业选择的年轻人而言，核心问题不是“计算机行业还有没有机会”，而是“我是否愿意投入那个‘第二个 90%’的苦功”。医疗和建筑被 Stonebraker 称为“稳妥的选择”，背后的逻辑是这些行业的专业门槛来自领域知识的深度积累、对错误后果的严格管控，以及不可替代的实践判断——这些特征，恰恰也是数据库核心工程领域的真实写照。计算机行业的红利褪去，留下的不是“没机会了”，而是“赚快钱的阶段结束了，真正考验专业能力的时候到了”。