事件概述

Dan Luu 在个人博客发表文章《We should be more ambitious with the software we build》，讨论在 AI 辅助开发能力快速提升的背景下，开发者是否应当尝试规模更大、过去被认为不现实的软件项目。

文章的引子是 Michael Malis（pgrust 项目作者）反复对作者说的一句话：”我们应该对我们构建的软件更有野心。”pgrust 是一个用 Rust 重写 Postgres 的项目。作者坦言，这类”重写”项目在新闻聚合网站上几乎总被当成 AI 生成的”vibeslop”（凭感觉糊出来的垃圾）而遭到群嘲，因为市面上低质量 AI 生成项目实在太多，他自己若不是认识 Malis，也会做出同样假设。

关键技术点

1. pgrust 的测试深度与意外收获

作者没有直接评估 pgrust 本身，但指出 Malis 在测试 pgrust 的过程中，测试充分到发现了 Postgres 自身的真实 bug，包括：

  • 一个会导致合法 SP-GiST 操作失败的数值 bug；
  • 一个会导致 JSONPath 返回错误结果的格式缓存 bug；
  • 一个会导致后续操作失败的 pgcrypto bug；
  • 字典加载器中的多个内存安全 bug；
  • 一个 money 类型的溢出 bug。

作者强调这不代表 pgrust 没有 bug，但说明背后有大量测试在进行。即便 pgrust 最终不成功，仅仅是这次尝试就已经以一种持久的方式改进了 Postgres。pgrust 的主要卖点是性能，若项目失败，其展示的某些优化也可能进入 Postgres、ClickHouse 等项目——不过这条路径显然不如直接给 Postgres 提 bug 来得直接。

2. AI 让”过去要一年”的项目变成”几小时”

作者以自己为例：在听说 OpenAI 将把 SOTA 模型跑在 Cerebras 上（而不只是 5.3-Codex-Spark 这类”快但质量低”的模型）之后，他思考如果使用快 10 到 100 倍的 SOTA 模型，自己电脑上的时间会花在哪里。他列出的既有瓶颈包括 ripgrep、编译 Rust、系统调用与文件系统开销。

作为一个自称”对正则、字符串匹配算法、编译器、解释器一无所知”的人，他利用 AI 构建了：

  • 一个可在任意关心的工作负载上调得比通用正则库更快的正则引擎；
  • 一个使用该正则引擎原生代码编译器的 ripgrep 分支，在作者自己的 codex ripgrep 工作负载上更快；
  • 一个能加速其项目构建的 Rust（冷构建提升巨大，热构建中等，受限于不愿 fork Rust 编译器前端）。

这些项目若在他没有 AI 辅助的情况下，达到”自己能跑”的质量可能需要一年以上；实际上他只花了低个位数的小时。作者也指出，要把这些东西做到”有用产品或开源项目”的质量线，还需要多得多的工作。

3. Azul AI：零 AI 背景到超人水平

作者此前构建过一个在国际象棋（Azul）匹配时限下达到超人水平的 AI。当时使用 GPT-5.1/5.2，在零 AI 知识背景下，约 5 小时做到超人水平，约 20 小时做到当时看起来最强的 AI，甚至对人类的表现强于那个被用来在 Board Game Arena 上作弊的 AI。

Gabriel Cangussu 后来构建的 AI 大幅击败了作者的 AI，且据作者判断，花费时间显著更少。交流后作者认为一个关键差异是：Fable 5.1 和 Opus 5.5 对棋类 AI 的理解好得多。而作者当时用 GPT-5.1/5.2 时，几乎每个建议都是错的，需要大量引导才能让结果勉强合理；让模型读代码库或论文去实现相关技术会失败；作者自己读论文并点名某项技术时，模型会声称做了，但通常只是表面上像，直到作者提出修正。当模型离”做对”还很远、而你又没有该领域背景时，验证模型是否做对相当耗时。

作者当时就对朋友说，他不认为模型当时的状态能持续多久——模型迟早能读论文并实现技术、能自己挑选可借鉴的代码库和论文。从他对 Fable 5 的尝试和 Cangussu 使用 Fable 5.1/Opus 5.5 的经验看，这似乎已经发生了。

4. zstd 验证评测

作者提到自己做过一个关于验证与测试技术的玩具评测，用 GPT-5.6 Sol 在 medium 和 xhigh 两档实现 zstd，但还没时间写出来。文章发布后他又用 GPT-6 Astra 重做了评测，结果 Astra 太强，他不得不换用不同的评测，因为模型进步太多。在 zstd 任务上，6 Astra 在所有条件下通过全部已注册测试的比例超过 99%，即使是在 TDD 这类显著拖累表现的条件之下也是如此。原文在此处被截断，后续内容未说明。

对数据科学或 AI Agent 落地的意义

这篇文章虽然以软件工程为主，但对 AI Agent 落地有几点直接启示：

  • 验证能力是瓶颈，也是价值来源。 pgrust 之所以值得被认真看待，不是因为”AI 写了代码”，而是因为它做了足够彻底的测试，甚至反向发现了 Postgres 的真实缺陷。Agent 在真实系统中的落地同样如此：能跑通 demo 不稀奇，能把验证做到发现上游 bug 才说明工程到位。
  • 模型能力跃迁改变的是”从零到能用”的成本结构。 作者强调自己零背景、几小时就能做出过去要一年的东西。这对数据科学团队意味着：原型探索、工具链优化、小规模专用 AI 这类过去”不值得立项”的工作，ROI 正在被重新计算。
  • “看起来做了”与”真的做了”仍需人类把关。 作者详细描述了旧模型会声称实现某项技术、实际只是表面相似。这对 Agent 落地的警示是：在缺乏领域背景时，验证成本可能被严重低估；而作者也观察到新模型在这方面的改善，意味着验证负担本身也在被 AI 分担。
  • 基础设施成为新瓶颈。 作者指出当 Agent 高频操作大量小文件时，系统调用与文件系统开销会成为瓶颈。对运行大量 Agent 的团队，这是需要提前关注的资源约束。

我的技术点评

这篇文章最有价值的地方，是它没有陷入”AI 能不能写代码”的老争论，而是换了一个更实际的视角：在 AI 降低实现成本之后，我们的项目野心是否还停留在旧时代？

作者的论证结构相当克制。他没有说”vibeslop 不存在”——恰恰相反，他承认绝大多数重写项目就是垃圾，也承认自己若不是认识 Malis 也会直接忽略 pgrust。他要说的是：作为构建者，别人的垃圾与你无关；只要测试和基准做得扎实，过去因规模过大而不可行的项目，现在可以认真尝试。他甚至把 Malis 的”should”改成自己的”can”，这种措辞上的克制值得学习。

pgrust 的例子尤其有说服力：一个尚未成功的重写项目，仅凭测试过程就发现了 Postgres 的多处真实 bug。这说明”野心”的价值不完全取决于项目本身是否成功——高标准的尝试会以副产品形式改善生态。这一点对评估 AI 辅助项目很有启发：不要只看项目是否交付，还要看它在过程中是否产生了可复用的验证资产。

不过也有需要冷静的地方。作者自己承认，从”自己能跑”到”有用产品或开源项目”之间隔着大量工作，而他列举的那些项目大多止步于前者。文章对模型能力的描述（Fable 5.1、Opus 5.5、GPT-6 Astra 等）依赖的是作者个人体验与单一评测，样本有限；zstd 评测细节也尚未完整公开，原文在该处截断。因此在把”几小时做出超人 AI”当作普遍规律之前，仍需区分”个人玩具级验证”与”生产级可靠性”。

总体而言，这是一篇立场清晰、论据具体的行业观察。它给出的不是”AI 万能”的口号，而是一个更朴素的建议：既然实现成本下降了，就请把节省下来的时间投入到测试、基准和验证上，然后把项目做大一点。

原文链接

https://danluu.com/ambitious/