我们该对做出来的软件更有野心

今年年初以来，Michael Malis（pgrust 的作者）一直在给我看他做的一些有意思的东西，并且说

我们构建软件时应该更有野心¹

对 pgrust 这类项目存在大量怀疑是可以理解的，因为市面上低质量的 AI 生成项目实在太多了。如果我不认识 Malis，也没有去了解过，我大概会直接认定 pgrust 又是一个永远不会成功的 vibeslop 项目。但我对 Malis 足够了解，不用细看也信得过他的工作；而如果你稍微了解一下就会发现，他在测试 pgrust 时测得足够彻底，甚至挖出了 Postgres 里的真实 bug，比如这个会导致合法的 SP-GiST 操作失败的数值 bug、这个会导致 JSONPath 返回错误结果的格式缓存 bug、这个会导致后续操作失败的 pgcrypto bug、字典加载器里的多个内存安全 bug²、这个 money 溢出 bug等等。

这并不是说 pgrust 没有 bug³，但它确实说明背后有大量的测试在进行；而且即便 pgrust 本身从未成功，仅仅做出这次尝试，也会以持久的方式改进 Postgres。pgrust 的主打卖点其实是性能，真正有意思的工作也发生在那里；如果 pgrust 失败，他们展示过的一些优化有可能进入 Postgres、Clickhouse 等，但这显然不如提交会被修复的 Postgres bug 来得直接。

话虽如此，我觉得可以理解：每次我在新闻聚合网站上看到关于 pgrust 的讨论，大多数人不屑一顾，觉得又是 vibeslop，因为这类重写项目几乎全都是。如果我不认识 Malis，我也会做出同样的判断，毕竟谁有时间去逐个了解这些项目呢？正因为认识 Malis，我压根没去看，直接就信了他（上面这些还是我为了在本文里拿 pgrust 举例、事先查了一下才发现的）。

作为软件使用者，放眼望去，到处都是创作者声称很快、实际却很慢的软件，因为创作者在吹嘘某个垃圾 benchmark，比如这是我昨天看到的多个例子之一。当然，不能用的低质量软件也比以往任何时候都更常见。

但作为软件开发者，这些项目几乎全是 vibeslop，别人在外面把一大堆垃圾当金子卖，这些都不重要。你可以做出像 pgrust 这样的东西，或者做出过去因为规模太大而根本不可行的项目；只要测试和 benchmark 做得像样，这些东西的质量其实可以好到足以使用。

如果是我来写，我会说“我们可以把软件做得更有野心”，而不是“我们应该”，但 Malis 跟我说这话时都是在闲聊，所以真写成文章他也许会说同样的话；这里的“应该”和“可以”不必过度解读。我觉得有意思的是，能力已经进步到让我们能多做很多事的地步。

举个例子，听说 OpenAI 要在他们的 SOTA 模型上用 Cerebras，而不只是用在 5.3-Codex-Spark 这种快但质量低的模型上之后，我盘算了一下，如果我用的是 SOTA 模型、但速度快 10 到 100 倍，我电脑上的时间会花在哪里。有些东西本来有时就已经是瓶颈，模型再快只会更糟。

1. Ripgrep
2. 编译 Rust
3. 系统调用和文件系统开销

在“能用就行”的项目层面，这些都是可以认真改进的。我现在没多少空闲时间，但即便如此，我还是做了这个正则引擎，可以针对我在意的任何特定工作负载调优到比其他通用正则库更快、这个 ripgrep fork，用上了正则引擎的原生代码编译器，在我 codex 的 ripgrep 工作负载上更快（当然文本索引是更好的方案，但我已经做过文本索引，而这个只是图一乐的项目，我没打算做最优解），还有一个能加快我项目构建的 Rust（冷构建提升巨大，热构建中等，受限于我不想 fork Rust 编译器前端）。至于系统调用和文件系统开销，光是把开发环境从 Mac 换到 Linux 就改善了很多；当然这块也还能大幅提速，尤其是 agent 频繁进行大量小文件系统操作的时候（经常能看到我的机器在等文件系统操作，因为标准操作系统文件系统接口设计时根本没考虑现代磁盘的性能）。用现代磁盘，没有理由再用 *nix 文件系统 API。过去，写一套用 direct I/O 而不是普通文件系统操作的开发者工具链是件荒唐的事，但现在完全可行。

对于我这种对正则表达式、字符串匹配算法、编译器、解释器一窍不通的人来说，这组项目本来得花一年甚至更久才能做到“我自己能用”的程度。而实际上，我只花了几个小时，还是个位数。要把这些东西做到“有用的产品或开源项目”的水准，那还得投入多得多的工作，但这个过程被加速的程度依然相当惊人。

Malis 说“我们做软件应该更有野心”，我的理解是，人们压根就没想到去做这些如今已经很容易的事。有好几周，我每次登录 Twitter，都能看到有人抱怨 Rust 编译慢、拖累了开发速度（我记得我看到这些抱怨的时候，这其实并不成立，当时 Cerebras 上还没有 5.6 Sol 和 6 Astra，而且如果去测时间到底花在哪，Rust 编译时间当时其实算不上多大的瓶颈）。Rust 编译确实慢。那你大可以顺手写个 Rust 解释器，同时直接把编译速度提上去。像这样的问题，我每天都能看到有人在抱怨，而现在解决它们并不需要多少时间和精力。据我所知，这些问题之所以还是问题，是因为人们心里默认还揣着一套前 agent 时代的成本模型。十年前，那种因为自己的编译器慢就去实现一个新编译器的人，和那种想做独立游戏就动手写一个新 3D 游戏引擎的人是同一类人，也就是那种永远交付不出东西的人。我认识的大多数高效程序员至今仍对这类做法心存抵触，尽管现在做这类事情其实已经相当合理了⁴。

我之前提到的另一个项目是这个 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 的时候，它们给出的建议几乎全是错的，我得大量引导才能让事情勉强说得过去。如果我让 GPT 去读一个代码库或一篇论文，把论文里的相关技术实现出来，它会失败。如果我自己读论文、点名某个技术，它会说它做了这个技术，但通常做出来的东西只是表面上像那个技术，实际上并不是，直到我提出一些纠正。当模型离做对还差那么远的时候，如果你在这个领域没有背景，检查模型有没有做对就相当费时，因为你得先学到足够多关于它应该做什么的知识，才能验证它是否做到了它声称做到的事。

我做那个项目的时候跟朋友说过，我不认为模型现在所处的状态能维持下去。它们迟早会好到能读一篇论文就把技术实现出来，这在我看来几乎是必然的；而且它们应该也能自己挑出可以借鉴的代码库和论文。从我折腾 Fable 5 的体验，以及 Cangussu 用 Fable 5.1 和 Opus 5.5 的经历来看，这件事似乎已经发生了。对我这种对桌游 AI 一无所知的人来说，这省下了大量时间（现在懂一点了，但还是不如任何一位真正的 AI 研究者）⁵。

针对某个具体领域，比如桌游 AI，你大可以说“谁在乎？桌游 AI 又不重要”，但我发现这种能力提升在不少不同领域都成立。举个例子，我用 GPT-5.6 Sol 在 medium 和 xhigh 两档上实现 zstd，做了一个关于验证与测试技巧的小型评测。我还没时间把它写成文章，不过在那篇帖子发布时，我也用 GPT-6 Astra 重做了一遍评测。6 Astra 太强了，我不得不换一套评测，因为模型进步得太快。就 zstd 而言，6 Astra 在所有条件下通过全部注册测试的比例都超过 99%，包括那些会显著拖累性能的条件，比如用 TDD（顺便说一句，它还更便宜，实现 zstd 大约只花 1 美元）。最后我换成了 IMAP RFC（5.6 Sol 做不好这个）以及 Pandoc，后者实现起来相当有分量，因为它需要能读写许多不同的格式⁶。

顺便说一句，当人们说他们用了新模型、一切都直接跑通、软件问题已经解决之类的话时，我完全不觉得这是真的。新模型确实能一次性搞定更多东西，那些事情基本就是直接跑通，但这只意味着我会去做更有野心的事，而在那些事上模型依然吃力⁷。我效率更高、干活更快了，但我发现，就我手头在做的事情而言，模型越强，我离“直接跑通”反而越远，因为模型无需大量手把手指导就能有效验证的范围，和它能实现的范围之间的差距一直在扩大⁸。说了这么多，啰嗦又不那么漂亮，其实就一句话：我们该把要做的软件定得更有野心一些。

感谢 Laurence Tratt、Yossi Kreinin、Alex Kolovsky 和 Michael Malis 的评论、指正与讨论。

我最近几篇文章都带着这样一段说明，这篇也一样。为了多发几篇，我尽量半小时赶出一篇，基本不怎么复查。这必然意味着文章论据不够扎实。按我平时的写法，文中提到的每个项目我都会配上完整的基准测试。可这次我只做了个能满足自己好奇心的快速对比，没做严格测试就写了出来。这篇里大概有二三十处我想做却没做的事。

这个 Rust 解释器我甚至都没写出来。五年前，如果我把一个 Rust 解释器拼凑出来，让冷编译提速 50 倍、热编译和缓存构建提速 2 倍（要是允许改 Rust 编译器，还能快得多），那会是一件极有意思、我很想写下来的事。可即便现在这种几乎不编辑、直接往外甩的模式下，它也还不够有意思，不值得写，因为放在不久以前会被认为很有意思的事，如今做起来太容易了。

附录：我们构建软件时应该少一点野心

下面是 Yossi Kreinin 的一条评论，经本人许可引用：

如果你发表这个，我会发一篇回应，说明对大多数人来说，用 AI 构建软件时应该少一点野心，否则会遭遇惨败。我认为很多问题并不太适合“智能体循环”，因为缺乏明确的通过/失败标准；即便有，大多数人也难以推理巨大的黑箱，他们能对其施加约束，却无法理解其内部[我也把自己算在这一类里]。这有点像微服务吧，有些人既需要它又非常擅长用它，但对大多数人来说，他们没那么需要，也根本用不好。我当然有点羡慕那些应该且确实能对软件构建如此有野心的人；不是说你不该更有野心，而是对大多数人来说，节制这份野心是应对当前局面的重要一环。顺便说，我对“软件没有理由慢”也有类似想法；很多情况下，如果你用 AI 加速某个流程，你会加进一堆凌乱的代码，它们会过拟合于你测试过的用例，既不能在性能上泛化到你真正该关心的所有用例，也无法在未来的改动中维护。如果你清楚自己在做什么，理解系统该如何拆分成部件、何时该全力优化某个部件或它们的组合、以及如何正确做基准测试等等，那一切都很好；但假如你有个经理，认为软件没有理由慢，还逼着大家用 AI 把软件里随机的部分弄快……赶紧跑。

我的感觉是，总体而言，这里的情况和之前那场讨论有点类似，也就是为什么我不喜欢人们谈 AI 带来 100 倍、1000 倍生产力提升的那种说法。有些环节确实被极大加速，轻松超过 1000000 倍；也有些环节目前压根没有加速。如果你做的还是五年前那套事，只是加上了 AI，那提速相当有限，因为 Amdahl 定律摆在那里。但一般情况下，加速什么由你自己决定；而当你去找那些值得做的事时，往往就是那些以前成本高到做不了的事。

而且，很多时候你可以搭出带有某种自检性质的系统，哪怕大多数人不会这么做。关于 Guards of Atlantis 2 实现的那场讨论就是一个例子。这个项目对 AI 来说是个糟糕的选择，因为官方规则是一团含糊又自相矛盾的英文（这大概是我见过人类误玩率最高的游戏，规则混乱到设计师本人也经常改变对自己规则的理解，尽管他一直坚称规则完全清楚，照着字面读就能玩）。如果你用朴素的方式去整理出一套可用的规则，AI 帮不上什么忙（不过一旦你有了干净的规格说明，它能加快实现），但在这个例子里，我设法在游戏规则那些互相矛盾的各种解释之间搭了一套粗糙的一致性检查，结果相当接近一套正确的规则（大致相当于别人投入多得多的人工、方法却没那么系统所达到的程度），这已经足够拿它和别人的实现做对比，从而得到一套能用的规则。这套做法的 token 开销比更手工的方式大得多。但也就是用 GPT-5.1/5.2 跑每月 200 美元的 OpenAI 订阅，“只”花了一两个月，比我坐下来为这个游戏写一份干净规格说明的时间成本要低。所谓干净规格说明，就是一份真正自洽且正确的规则副本。

我觉得很多问题都属于这一类，可以搭起某种至少能部分自检的机制，让人只需投入少量时间。这也让我想到整个软件测试领域的处境。在编码 agent 出现之前，我就发现 fuzzing 和 property-based testing 极其有效。对大多数领域，人们都给我讲过这类测试行不通的某种理由；可当我在那些被告知不适用的领域里实际试过之后，它们运行得很好。用起来确实要多花些功夫，但依然适用，而且据我所知，比写传统单元测试更高效、更有效。

Yossi 那条评论的要点之一，是大家并没有在做这类事。考虑到我现在看到的 bug 比过去多得多，比如上次我打开某家大型 AI 实验室的网页聊天，一分钟内就撞上两位数个 bug，很难说 Yossi 讲错了。但话虽如此，我仍然坚持原来的看法。别人在大量产出勉强能跑的垃圾，不代表你也得跟着这么干。

附录：几个“随手”的例子

正文里我举的那些自己做过的事，都是些我本来绝不会去做的工具类工作。类似的事情还有很多，因为打造“在我这儿能用”质量、只给自己用的工具实在太容易了。我确实认为，往前走也可能走过头，比如 Steve Yegge 写了很多关于 Gas Town 的文章，讲它有多高效，但等到他构建下一个 agentic 框架时，他提到自己从没成功用 Gas Town 构建过 Gas Town 以外的任何东西；有一阵子大家很迷 Ralph Loops，可我对比试过之后，觉得它还不如我当时用的笨办法，也就是普通的循环，带上上下文，在合适的时候偶尔清一下上下文，而不是默认在单轮对话结束这个完全随意的节点上清，等等。所以我尽量只做那些影响相当直接的事。除了这个显而易见的有效原因之外，模型和 harness 能力随时间剧烈变化，意味着值得构建什么样的工具也在快速变化；花大量时间打磨某个特定工具，最好的情况也只是次优，三个月后很可能就已过时，这实在没什么道理。

而且，我对自己很多个人工具的假设是：AI 实验室很快就会让我做的东西过时。举个很傻的例子：从 GPT-5.6 Sol 发布起，我有个工具一直很好用，它会在发现内存泄漏时重启 codex。OpenAI 迟早会修掉这个问题，到那时这个工具就一文不值了。再举个没那么傻的例子：我让某个 agent 写的那个 Rust 解释器。出于 token 预算的考虑，一个高性能解释器本该做的很多事情都没做。

比如，这个解释器没有去改 Rust 前端编译器本身，好让后续更新更容易接进来；如果我直接改 Rust 前端，性能会好得多，但我没有足够的 token 预算去维护一个兼容的 Rust 编译器 fork，而这对 OpenAI 来说应该不是问题。OpenAI 花了 100 亿美元以上拿到 Cerebras 的使用权，同时还让 Anthropic 拿不到。

有意思的是，在编程这件事上，很多任务里如果你真用上他们的 SOTA 模型，再和 Anthropic 的结果对比，实际提速并没有那么大，因为时间都花在编译 Rust 这类事情上了。既然他们愿意为此投入 100 亿美元以上，那他们最终在加速相关工具上做得比任何 AI 实验室之外的人能做到的都更好，也是顺理成章的，所以在这上面花太多精力没什么意义（如果短期内非编程任务预计会完全主导 OpenAI 未来的收入，这个说法可以说并不成立，但即便如此，考虑到他们为 token 付的钱和我付的钱的差距，既然我在实验室之外都能做，他们把这些东西加速起来似乎仍然说得通；也许可以这样论证：如果你能看到他们的用量数据，会发现有太多更重要的瓶颈，这一个不值得优先处理，但即便如此，哪怕它排不进 Cerebras 加持的编程 agent 的前 100 个瓶颈，对他们来说在某个时点做这件事似乎仍然合理）。

还有一类东西，或许算不上雄心勃勃，却能说明哪些事是可能的，比如我自己做的游戏。有些游戏我想过、也想做，但我觉得它们对真正的玩家来说不够好玩，做出来没什么意义，可我自己想玩。比如，自从 90 年代读了 David Gerrold 的 Star Wolf 系列，我就一直想玩一款把书里描述的战斗做进游戏里的作品，那种战斗有点像潜艇战。至少在写实向战争游戏里，这个品类极其小众，因为几乎所有人都觉得海战无聊，而潜艇战又是海战游戏里格外无聊的一个子类，所以做成一款赚钱的游戏并不合理。但做游戏实在太容易了，我让一个 agent 把这款游戏做了出来，好让我玩上一两个小时。我绝不会花 10 到 20 个小时去实现一款游戏，只为了玩一两个小时，但花 5 分钟我愿意。我之前也提过，我实现过规则与 Scout 相同的游戏和 Guards of Atlantis 2。我永远不会专门花时间手动实现这些游戏，只为了在朋友们没法线下聚齐的时候有个一起玩的途径，但让 LLM 把这些东西赶出来，我很乐意。当然，对于想做面向更广受众的游戏的人来说，眼下正因 coding agent 而兴起一场游戏复兴。如今编程能力和投入其中的时间不再是做游戏的瓶颈，涌现出的有趣又有创意的游戏之多，着实令人惊叹。

数据分析是另一件生产力乘数可以非常高的事，我能做各种以前绝不会去做的事情。正如我在最近几篇文章里提到的，这类项目我攒了太多，实在写不过来，哪怕我尽量写得快、每篇半小时赶出来也不行。

我和人聊起他们的一次性工具时，发现大家做过不少有意思的东西。比如 Peter Geoghegan 一两个月前提到的这个：

我让 Fable 写了一个自定义的 Neovim Lua 函数，按我那套非常具体的要求格式化代码。这东西我既不想自己维护，本质上又是个 Rube Goldberg 式的装置。理论上，我可以通过给 clang-format 打补丁，用一套有章法的方式达到同样的效果，但我的要求太精确了，我觉得那种做法永远不会让我满意。我们用的是一个叫 pgindent 的工具，它是我们 fork 出来的 bsd_indent。用 clang-format 可以近似实现同样的格式化规则，但还不够好。如果我提交的代码没有完全按照 pgindent 的要求格式化/缩进，CI 就会失败，而且我得尽快修好，这是我最想避免的情况……实际来说，想要得到 clang-format 那种漂亮顺滑的格式化效果，又不收到抱怨缩进错误的邮件，就得把整个架构搞得一团糟（我 也 不想花时间去开发一套有章法的方案，但那是另一个问题）。这个函数让我可以从 Neovim 里毫不费力地格式化指定的代码块，类似 clang-format 的 LSP 集成。当然，我在这里挑剔得有点不讲道理，但我发现 LLM 让我可以在工具上这么较真。这个函数会执行多轮处理：先用 clang-format/clangd 做一轮初始格式化，再用 pgindent 单独做一轮格式化。我需要两者都做，因为有些情况 clang-format 处理得对，pgindent 却会漏掉。这很脆弱，因为我只想格式化通过块可视模式选中的那几行范围内的代码（我不想对补丁没有新增的代码运行 clang-format）。这与 pgindent 的设计相冲突；它只能格式化整个 C 文件。要弄清楚临时生成的整个文件缓冲区中哪一部分相关子集需要复制回我的工作缓冲区，并不简单。我最初选中的行范围并不直接对应受影响的 C AST 元素。所以这个函数用 tree-sitter 来智能地划定临时缩进后的 C 代码中需要复制回来的确切子集。这些规则需要以恰到好处的方式保持模糊，以应对我的选择跨越同一代码块的情况。这里有一堆边缘情况。另一个复杂因素是，pgindent 依赖一个用 objdump 生成的 typedef 文件来识别类型；没有那个文件，格式化结果就会很奇怪。这个格式化函数会针对那一个文件，从 clangd 动态生成所需的额外 typedef，所以我不必担心 typedef 文件过期（我可能在运行格式化工具前几秒才创建了一个新 struct，我不想每次都对整个 postgres 二进制运行 objdump，那会严重拖慢延迟）。这似乎运行得很完美。延迟完全可以接受。不过，我对这一切如何运作只有一个模糊的理解。我甚至不懂 Lua。即使我们 fork 的 bsd_indent 后续有所改动、在一定程度上改变了代码的格式化方式（这种情况时不时会发生），这大概也会继续有效。我对 saaspocalypse 持怀疑态度。但我确实认为，LLM 正在编写大量有用的软件，而用其他任何方式编写这些软件都会极其不经济。

有一类小众软件很有意思：它创造的价值有多大，维护起来就有多繁琐，繁琐到令人难以想象。

写这篇文章时，我又和 Malis 聊了一次，发现他一直在做各种有意思的事。这些事要是详细写下来，足够单独写一篇，但其中一件挺有意思：上次和他聊 pgrust 验证时，他提到用 Kani 验证了部分代码。后来他转用 Lean，用它验证 Kani 处理不了的复杂部分。这又是另一个可以单独写的话题，不过我很好奇，为什么大家在 LLM 驱动的证明上普遍选择了 Lean（而不是 ACL2 之类）。我也想知道，如果更新这份定理证明器对比，Lean 会处在什么位置；或者有人跑一次定理证明器评测，类似这次语言评测那样。

当然，AI 实验室的例子能举出很多，比如一个中等规模的团队 Anthropic 用五个月时间为 GitHub 造了一个内部替代品，还顺带做了些别的工具。

七个人的团队同时做出了 Scion 和 Antique（我们的代码审查工具，光这个就够再写一篇博客），外加五六个相关系统，并在五个月内完成了全面迁移。

这类例子很有意思，也指向了行业不远处的样子。但无限 token 能做什么，而且还得依赖同样用无限 token 堆出来的其他基础设施和工具，这并不能说明你今天没有无限资金时能做成什么。pgrust 这样的项目，以及我认识的人在业余时间做的项目（我大概只提到过其中的 1%，这类项目实在太多了，比如 David Turner 做了一个播客 skipper，质量就是“在我这儿能用”，却比他找到的任何方案都好用；Dennis Snell 在这里提到的业余项目，等等），更能代表你今天能做成什么。

Footnotes

1. 本文中“ambitious”的用法在我看来前后一致，但也可以说这个词被赋予了太多含义。我用它泛指“做到以前做不到的事”。有人会说，做一个比以前合理可行范围更大的项目，和做一个本来就能做、只是不值得花时间做的超专用工具，是两回事。这两者确实很不一样，但我认为它们都源于同一件事（造软件变得容易多了），所以我觉得用这个可能有歧义的定义也没什么问题。 ↩

2. Alex Kolovsky 指出，这些问题并不被视为 bug。从安全角度看，我理解这个论点，而且我对 Postgres 的了解不足以专门就这一点发表意见。但我想说，在我参与过的项目里，我很喜欢把这类问题彻底消除，因为如果努力让代码不受这类问题影响，找真正的 bug 会容易得多。 ↩

3. 我信任 Malis 的一个原因是，他对自己所声称的东西比典型的创始人谨慎得多。比如，我加入 pgrust discord 想看看大家在聊什么时，看到 Malis 的一条消息（一个月前发的，2026-09-17，在 agentic coding 的世界里已经算很久了），是在回复有人问 pgrust 是否已经可以当作生产数据库使用：

   我今天不建议把它当作你的主要生产数据库。我们目前正在为一家公司做生产部署，但他们对生产数据库宕机的容忍度比大多数人高。等他们开始跑起来之后，我们就能拿到关于 pgrust 可靠性的可靠实证数据了

   Malis 看上去不像是那种明明东西远远没准备好、却硬说已经能上生产的人。不少知名项目就是这么干的。结果发现他确实没这么干。这篇稿子我在发布前一周就写好了，只是一直没空发。就在这期间，pgrust 的 Clickhouse 基准测试争议出来了。我去了解了一下，所谓恶意作弊的指控站不住脚；至于“把 pgrust 的预览版提交到基准测试为时过早”这个批评，Malis 本人是认了的。不过我确实觉得，这种事一旦沾上就洗不掉：不管真相如何，几年后人们还会把它翻出来。眼下围绕那场争议的讨论就是现成的例子；我们之前查 Ed Zitron 的预测记录、看 Kurzweil 这类未来学家式预测者时也谈过，几乎没人真的去核对后来发生了什么，那些凭感觉编出来的错误说法会被无限重复下去。要说清楚我为什么信任 Malis，我没法把所有证据都摆出来（技术上做得到，但那轻松就是两万词以上的长文）。不过你只要对比一下他谈 pgrust 的方式和典型数据库创始人推销自家新项目的方式，在我看来差别大得离谱。当然，极端例子也有，比如 MongoDB，明明 Kyle Kingsbury 一再证明用户关于数据损坏的传闻是真的，他们还是争了好几年。再举个更典型的：我有个朋友在一家数据库创业公司做早期员工。他们官网吹嘘自己能跑到某个天文数字的 QPS。我朋友一测，发现这个数字差了好几个数量级，就建议把官网改掉。创始人不同意，理由是性能迟早会达到那个数，所以这个说法仍然成立。性能优化做了好几年之后，公司终于把数字下调了一个数量级，而且即便如此，也只有靠极其刻意、完全不现实的负载才能跑到。对一个靠性能卖产品的公司来说，这很不幸，但确实挺常见。相比之下，我去 pgrust 的 discord 看 Malis 怎么谈性能，这是他最近的一条消息：

   眼下最能帮上忙的，是在 0.4-beta 里找 bug 和性能问题。新的查询引擎在某些负载上非常快，但在另一些负载上会造成性能回退，而且还不支持一些更复杂的查询。我们正在把比 Postgres 慢的、以及直接报错的查询都找出来。考虑到可运行的查询空间极其庞大，这并不容易。我们希望在 0.4-beta 正式发布之前把这些修好。凭印象说，极快的查询上出现过一次明显的性能回退。原因是我们主要针对大规模、类 OLAP 的负载来优化新引擎。我正在做优化，解决那些非常慢的查询。我不认为新引擎在快查询上比旧引擎慢有什么根本性的原因。

   在启动 pgrust 项目之前，他曾做过一家成功创业公司的创始人和高管，但他始终没有真正进入大多数创始人似乎都会进入的那种心态，那种仿佛什么话都说得出口、并且对自己说的每句话都深信不疑的状态。你也许会说这个标准很低，我同意，但我仍然觉得这很罕见，也正是因为这一点，我没有去核实就相信了他关于 pgrust 的说法；也是因为这一点，在我去核实之后，发现他的说法似乎与现实相符。 ↩

4. 换个角度看，也可以参考 [Thomas Ptacek 的这个说法]：

   过去一年，技术行业给人的感觉像是一百年的事挤在一起发生了。我们这个行业正处在一种自个人电脑问世以来没人经历过的动荡之中。AI 撞上的每一道限制，都在一个月之内崩塌。今天我们用前沿模型做的所有事情，几年之后都会瞬间完成，而且免费。

   考虑到近来的变化速度，我觉得大多数人，甚至大多数程序员，不太清楚现在能做到什么，这可以理解。说到非程序员的反应，我觉得有意思的一点是，有很多人反对这篇对 Ed Zitron 预测准确度的评论，因为他们认为 AI 能力在过去两年里没有提升。在我交谈过的大多数人看来，“AI 从 2024 年秋到 2026 年秋毫无进步”这个说法完全不可理喻（即便你把编程视为例外、转而去看其他能力也是如此）；但外面有很多人，也许只是看看搜索结果顶部的 Google AI 摘要，或者用着集成在某个 Microsoft 套件里的 Copilot，并不知道能力已经进步了。每一个层级上似乎都有这样一条信息梯度：实验室之外，很少有人清楚今天最高产的那批人拿模型在做什么。 ↩

5. 这条关于线上作弊增多的评论应验了。重读我当初写的那条评论，我并没有明确写过作弊大幅增加似乎不可避免，尽管把其中的说法串起来可以推出这个意思，而且我也在一些 Discord 等公开场合表过态。我不关注线上游戏圈，但听说 Azul（BGA 上最火的游戏，BGA 是现代桌游最大的线上平台）上赛季前十名里有三个是作弊者，包括第一名。另外，正如我过去在别处提过的，BGA 似乎在任何层面都不具备做出合理政策决策的能力。他们的 Elo 排名算法机制、赛季结构、反串通政策、反作弊政策等等，都比你所能想到的最朴素直接的方案还差，所以不出所料，他们并没有合理的反作弊政策。最火游戏的高排名已经被作弊者占据，而且这理应会蔓延到其他游戏。在 AI 带来的各种危害里，这算是相当温和的一种。它恰好是我上周看到的两位数个例子之一，这些例子都显示人们在所创建的软件上变得更有野心。我提这件事，一半是因为它容易量化，一半是因为我预测过这会发生，跟进看看结果如何似乎也合理。 ↩

6. Pandoc 支持的输入格式有 {html, docx, xlsx, pptx, csv, markdown, gfm, commonmark, commonmark_x, markdown_strict, markdown_mmd, markdown_phpextra, markdown_github, rtf, epub, odt, tsv, latex, ipynb, mediawiki, rst, asciidoc, bibtex, biblatex, org, typst, jira, docbook, endnotexml, ris, opml, dokuwiki, textile, man, mdoc, jats, csljson, fb2, pod, vimwiki, djot, creole, tikiwiki, twiki, t2t, haddock, muse, json, xml, native}，输出格式有 {pdf, html, html4, docx, plain, pptx, markdown, gfm, commonmark, commonmark_x, markdown_strict, markdown_mmd, markdown_phpextra, markdown_github, rtf, epub, epub2, odt, latex, ipynb, mediawiki, rst, asciidoc, asciidoc_legacy, bibtex, biblatex, org, typst, bbcode, bbcode_phpbb, bbcode_steam, bbcode_xenforo, bbcode_fluxbb, bbcode_hubzilla, jira, docbook, docbook4, revealjs, beamer, opml, dokuwiki, textile, man, texinfo, context, jats, jats_publishing, jats_articleauthoring, tei, icml, opendocument, csljson, fb2, ansi, chunkedhtml, djot, xwiki, zimwiki, vimdoc, haddock, markua, muse, ms, slidy, s5, dzslides, slideous, json, xml, native}（native 是 Pandoc AST 的序列化版本）。 ↩

7. 顺带一提，这导致公开评测在很多场景下没什么意义，因为我和其他使用模型的程序员通常关心的是：模型在仍然需要人类引导的任务上表现如何，而不是模型在对其而言轻而易举的任务上表现如何。 ↩

8. 这不是对未来的断言。也许在不久的将来，我所拥有的几乎全部乃至全部软件技能都会变得无关紧要。但我们还没到那一步。眼下，编程技能的影响力似乎比以往任何时候都大。当下这一刻有点好笑：拥有模型正在取代的那些技能的人，似乎比那些试图在没有这些技能的情况下使用模型的人效率高得多。我喜欢 Max Bittker 的说法：模型非常擅长伪造，而随着模型不断进步，分辨真伪所需的专业水平也在不断提高。 ↩