We should be more ambitious with the software we build

“我们在构建的软件上应该更加雄心勃勃”

今年年初以来，pgrust 的 Michael Malis 不断向我展示他完成的一些有趣项目，并提到：

[W]e should be more ambitious 1 with the software we build

鉴于目前存在大量低质量的 AI 生成项目，人们对于 pgrust 这类项目自然抱有相当多的怀疑。如果我不认识 Malis 且没有深入了解，我会直接假设 pgrust 只是又一个注定失败的“vibeslop”项目。但鉴于我对 Malis 的了解程度，我可以无须验证就信任他的工作。如果你稍微研究一下，会发现他在测试 pgrust 时已经深入到足以发现 PostgreSQL 本身真实漏洞的程度，例如这个可能导致有效 SP-GiST 操作失败的数值错误，这个可能导致 JSONPath 返回错误结果的格式缓存错误，这个可能导致后续操作失败的 pgcrypto 错误，字典加载器中的多个内存安全错误，这个货币溢出错误等。

这并不是说 pgrust 没有 bug 3 ，但确实表明有大量测试工作正在进行。即使 pgrust 本身最终未能成功，仅尝试实现这一目标就已以持久的方式改进了 PostgreSQL。pgrust 的核心卖点实际上是性能，而真正有趣的工作也正发生在这里；如果 pgrust 最终失败，它所展示的一些优化仍有可能被纳入 PostgreSQL、Clickhouse 等系统，但显然这比提交 PostgreSQL 的 bug 并获得修复要间接得多。

话虽如此，每次我在新闻聚合器上看到 pgrust 的讨论时，大多数人将其归类为“vibeslop 垃圾”也是可以理解的，因为几乎所有的重写项目都属于这类低质量作品。如果我不认识 Malis，我也会做出同样的假设——毕竟谁有时间去研究所有这些项目？正因为我认识 Malis，我才懒得去查看；我直接选择信任他（我之所以发现上述内容，是因为我想在使用它作为本文示例之前确认 pgrust 的情况）。

作为软件消费者，你到哪里都能看到这样的现象：软件开发者声称自己的软件很快，但实际上软件很慢，因为开发者在兜售一些“vibeslop”基准测试，比如这是我昨天看到的多个例子之一。当然，不工作且质量低劣的软件如今比以往任何时候都更加常见。

但作为软件开发者，其他人的行为——他们堆砌大量垃圾并称之为黄金——并不会影响你。你可以构建像 pgrust 或其他过去被认为难以真正实现的大型项目，只要你在测试和基准测试方面做得合理，这些项目实际上可以达到足够高质量的使用标准。

如果我要写的话，我会说“我们可以对构建的软件更加雄心勃勃”而不是“我们应该”，但 Malis 在和我随意聊天时就曾这样说过，所以也许他在正式文章中也会表达类似观点；此处不要过度解读“should”和“can”的区别。令我感兴趣的是，我们的能力已经发展到可以实现更多事情的程度。

例如，当我得知 OpenAI 将使用 Cerebras 来构建他们的最先进模型（SOTA），而不是像 5.3-Codex-Spark 这样虽然速度快但质量较低的模型时，我开始思考如果在我的电脑上使用一个比当前模型快 10 到 100 倍的 SOTA 模型，时间会如何分配。一些原本已经是瓶颈的问题，而且随着模型变快只会变得更糟，包括：

• Ripgrep
• 编译 Rust
• 系统调用和文件系统开销

在“对我个人来说可行”的项目层面，这些问题都可以显著改进。目前我没有太多空闲时间，但即便如此，我还是开发了一个可以针对特定任务优化得比其他通用正则表达式库更快的正则表达式引擎，一个使用正则表达式引擎原生代码编译器的 ripgrep 分支（对我的 codex ripgrep 工作负载更快，当然文本索引是更优的解决方案，但我在文本索引方面已经做过相关工作，这个项目只是出于兴趣，没有追求最优解），以及一个加速我项目构建的 Rust（对冷启动构建有巨大提升，对热启动有中等提升，受限于不想 fork Rust 编译器前端）。对于系统调用和文件系统开销，仅仅将开发环境从 Mac 切换到 Linux 就显著改善了这一问题，当然这也可以通过其他方式进一步优化，尤其是在代理频繁执行大量小文件系统操作时（我的机器经常因为标准操作系统文件系统接口未考虑现代磁盘性能而等待文件系统操作）。

对于像我这样对正则表达式、字符串匹配算法、编译器、解释器等一无所知的人来说，要达到“对我个人来说可行”的质量水平，这些项目可能需要一年或更长时间。但事实上，这些项目只花费了我不到十个小时的时间。如果我要让这些项目达到“实用产品或开源项目”的质量标准，那需要付出更多努力，但即使如此，这个过程被加速到令人难以置信的程度。

对于 Malis 说的“我们应该在构建的软件上更有野心”，我的理解是，现在这些事情变得容易了，但人们甚至没有想到要去做。过去几周，每次登录 Twitter，我都能看到有人抱怨 Rust 编译速度慢，限制了开发速度（我认为当我看到这些抱怨时，这其实并不准确，因为当时还没有 5.6 Sol 和 6 Astra 在 Cerebras 上可用，如果当时测量实际时间消耗，Rust 编译时间其实并不是主要瓶颈）。当然，Rust 编译确实很慢。你可以直接编写一个 Rust 解释器，或者直接加速编译过程。我每天看到人们抱怨的这类问题，现在其实可以通过较少的时间和精力解决。据我所知，这些问题之所以存在，是因为人们默认使用了一种非代理式的成本模型。十年前，如果一个人的编译器速度慢到需要自己实现新编译器，那可能就像一个人想开发独立游戏时从零开始编写 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在中等和高难度条件下实现zstd的验证和测试技术评估。虽然还没时间整理成文，但当我发布该文章时，又用GPT-6 Astra重新进行了评估。Astra表现如此出色，以至于我不得不设计新的评估方式，因为模型进步太快了。对于zstd，6 Astra在所有条件下都能以超过99%的通过率完成所有注册测试，即使在显著影响性能的场景（如使用TDD）下也是如此（顺便说一句，它实现起来也更经济，只需约1美元就能实现zstd）。最终我选择了IMAP RFC（5.6 Sol无法有效处理）和Pandoc（需要实现多种格式的读写，是一项相当重大的任务）作为评估对象。

顺便说一句，当人们说他们使用了新模型后一切都能顺利运行、软件问题迎刃而解时，我完全没发现这种情况。确实，新模型能够一次性处理更多任务，让很多事情变得简单直接，但这恰恰意味着我开始着手更具挑战性的项目，而这些项目目前模型仍然难以应对。我确实变得更高效了，工作速度也更快，但就我所从事的工作而言，随着模型能力的提升，我反而离“一切都能自动运行”的状态越来越远。因为模型在无需大量人工干预的情况下能有效验证的内容与模型能实际实现的内容之间的差距正在扩大。以上就是我冗长而不够优雅的表达方式：我们应该更加雄心勃勃地构建软件。

感谢 Laurence Tratt、Yossi Kreinin、Alex Kolovsky 和 Michael Malis 提供的评论/更正/讨论。

我最近的帖子中都有这样一个备注，同样适用于本文。为了产出更多内容，我尝试在半小时内快速完成文章创作，而不会花太多时间审阅。这无疑会导致文章质量下降。如果我用标准风格写作，我一定会为提到的所有项目提供全面的基准测试。但这次我只是做了个快速对比以满足好奇心，没有进行严谨的基准测试，这篇文章中可能有二三十处内容是我很想做却还没完成的。

我甚至还没写完这个 Rust 解释器。如果五年前我拼凑出一个 Rust 解释器，实现了冷编译时 50 倍的速度提升和热/缓存构建时 2 倍的提升（如果对 Rust 编译器的修改在允许范围内，还能实现更多），这将是一个非常有趣的内容，值得我专门写一篇文章。但即使在这种我几乎不修改文章内容、只快速发布文章的模式下，这也不足以让我觉得值得专门撰写，因为如今要实现曾经被认为非常有趣的事情已经变得异常简单。

附录：我们应减少对软件构建的雄心

以下是 Yossi Kreinin 的评论（经许可引用）：

如果你发布这段内容，我会发布一篇回应文章，解释对于大多数人来说，他们应该在使用AI构建的软件上保持更谨慎的野心，否则将面临彻底的失败。我认为很多问题并不适合“代理循环（agentic loops）”这种模式，因为通常缺乏明确的通过/失败标准，即使存在标准，大多数人也难以理解那些无法窥见内部运作的庞大黑箱系统（我本人也包含在这一群体中）。这有点类似于微服务（microservices），一些人确实需要它并且擅长使用，但对大多数人来说，他们可能并不需要它，也无法有效利用。我有点羡慕那些确实有能力并且应该如此雄心勃勃地构建软件的人；当然，我并不是说你完全不应该更雄心勃勃，但对大多数人来说，适度控制这种野心是应对当前局面的关键。顺便说一句，我对“软件没有理由变慢”这一观点也有类似的看法：在许多情况下，如果你用AI加速某个流程，反而会引入大量凌乱的代码，这些代码在你测试的特定场景中表现良好，但无法在所有需要关注的场景中实现性能上的泛化，未来遇到变更时也难以维护。如果你清楚自己在做什么，了解系统应该如何分解为模块，知道何时应该全力以赴优化某个模块或多个模块的协同工作，并掌握如何正确进行基准测试等，那么一切都很顺利。但如果你遇到一个认为“软件没有理由变慢”的经理，他强制要求团队用AI加速软件中随机的部分……那你最好赶紧跑。

我的感觉是，总体而言，当前的情况与这里讨论的关于“为什么我不喜欢人们谈论AI带来100倍或1000倍生产力提升”的观点有些类似。某些任务确实能被加速到非常大的倍数，轻松超过一百万倍。而另一些任务目前根本没有加速。如果你只是机械地重复五年前的工作方式，但使用AI，由于Amdahl定律，加速效果会非常有限。但在一般情况下，你可以选择要加速的部分，如果你正在寻找有生产力提升价值的任务，这通常涉及那些之前因成本过高而无法执行的事情。

而且，我认为即使在大多数人不会考虑的情况下，你也可以经常设置一些具有某种自我检查属性的系统。关于《亚特兰蒂斯守卫者2》（Guards of Atlantis 2）实现方式的讨论就是这样一个例子。这并不是一个适合AI项目的良好选择，因为官方规则是一堆含糊且相互矛盾的英文文本（这可能是我见过人类在最高水平上失误率最高的游戏，规则的混乱程度甚至让设计者经常改变自己对规则含义的理解，尽管他们持续声称规则非常明确，只需按字面意思阅读规则即可进行游戏）。如果你以一种天真的方式尝试生成一套可行的规则，AI在这件事上其实帮不上太大忙（尽管一旦你拥有了清晰的规范，AI可以加速实现过程），但就这件事而言，我能够设置一套笨拙但有效的规则一致性检查机制，将所有相互矛盾的游戏规则解释进行比对，最终得到了一套接近正确规则的规则集（大约与其他人通过大量人工努力和较少系统化方法所达到的准确性相当），这足以与他人的实现进行对比，从而获得一套可行的规则。这种设置在token消耗上确实比手动方法要高很多。但这也只是“仅仅”花费了大约一两个月的OpenAI每月200美元订阅费用（使用GPT-5.1/5.2），这比我自己花时间撰写一份清晰的游戏规范（即一份真正一致且正确的规则副本）所耗费的时间成本要低得多。

我觉得很多问题都属于类似的情况，即可以通过投入少量时间，设置某种至少部分自我检查的机制来解决。这让我联想到软件测试领域的大规模情况，在引入代码代理之前，我发现模糊测试和基于属性的测试非常有效。对于大多数领域，人们曾告诉我某些原因，认为这类测试无法奏效，但当我尝试将这些技术应用于所有被指出不适用这些技术的领域时，它们都表现得非常好。它们的实施确实需要更多工作，但依然适用，而且据我所知，它们比编写传统的单元测试更高效、更有效。

约西（Yossi）评论的核心观点之一是，人们并没有在做这类事情。考虑到我现在看到的bug数量比以前多得多，例如，上一次我打开一家大型AI实验室的网页聊天界面时，一分钟内就遇到了两位数的bug，很难说约西是错误的。但就这一点而言，我仍然坚持我最初的立场。其他人的大量产出虽然质量参差不齐，但这并不意味着你也必须这样做。

附录：几个“随机”示例

文章正文中我给出的个人经历示例，都是些我从未真正投入开发的工具类项目。由于构建“仅适用于我的”工具非常容易，这类项目其实还有很多。我认为确实存在过度开发的情况，比如Steve Yegge曾大量撰文讨论Gas Town及其生产力，但当他开发下一个代理框架时指出，自己从未成功用Gas Town构建出除Gas Town本身以外的任何东西。Ralph Loops也曾一度流行，但当我尝试比较时发现，它们似乎不如当时我采用的简单循环方式，这种循环在适当的时候会清除上下文而非在单次交互完成时强制清除。因此我倾向于选择那些影响直接可见的工具。除了显而易见的有效性原因，模型和框架能力的显著变化也意味着值得开发的工具类型会快速演变，因此投入大量时间开发某个可能在三个月内就过时的工具并不明智。

对于很多个人工具，我的假设是AI实验室会很快淘汰我开发的任何东西。以一个荒谬的例子来说，我开发了一个在GPT-5.6发布后有用的工具，当检测到内存泄漏时会重启Codex。但OpenAI最终会修复这个问题，这个工具就会变得毫无价值。再举个稍微不那么荒谬的例子，我曾让某个代理构建了Rust解释器。由于令牌预算限制，很多高性能解释器本应实现的功能都没有完成。

例如，这个解释器没有修改实际的Rust前端编译器以简化更新；如果直接修改Rust前端，性能会显著提升，但我不具备维护Rust编译器兼容分支的令牌预算。这显然不是OpenAI需要考虑的问题，他们为获取Cerebras访问权限而投入了100亿美元以上，同时阻止Anthropic获得访问权限。

有趣的是，在编程任务中，当实际使用他们的SOTA模型与Anthropic的模型进行比较时，实际加速效果并不像预期那么显著，因为需要花费大量时间在编译Rust等操作上。考虑到他们愿意投入100亿美元，可以推断他们最终会比任何非AI实验室的人更高效地优化相关工具。因此，投入过多精力在此领域并不值得（当然，如果非编程任务短期内完全主导OpenAI收入，这一结论可能不成立，但即使如此，考虑到他们为令牌支付的费用与我相比，他们显然仍有动力加速这些工具的优化；或许存在某种论点认为，如果能访问他们的使用数据，会发现更多关键瓶颈，但无论如何，最终他们仍会在某个时间点对此进行优化，即使这并非Cerebras赋能的代码代理的前100个瓶颈）。

另一种人们可能不会称之为雄心勃勃，但能体现某些可能性的事物，就是我制作的游戏。我曾构思并渴望制作一些游戏，但认为它们对普通观众来说乐趣不足，无法成为真正意义上的商业作品，但这些是我自己想玩的游戏。例如，自上世纪90年代阅读大卫·杰罗尔德的《星狼》系列书籍以来，我就一直想玩一款能实现书中描述战斗方式的游戏——这种战斗方式类似于潜艇作战。在现实主义战争游戏中，这类题材极其小众，因为几乎所有人都觉得海战枯燥，而潜艇战更是海战游戏中最无聊的子类型。因此，这显然不适合作为赚钱的商业游戏，但实现这类游戏的难度却非常低，所以我曾让代理人为我开发了这款游戏，让我能玩上一两个小时。我绝不会花10到20小时去开发一款只玩一两个小时的游戏，但花5分钟却很乐意。我之前也提到过，曾想实现一款规则与《侦察兵与亚特兰蒂斯守卫2》相同的游戏。我从未想过要花时间手动开发这些游戏，只为和朋友在无法线下聚会时有个玩耍的方式，但让LLM来快速生成这些内容却让我非常满意。当然，对于那些希望面向更广泛受众开发游戏的人来说，由于代码代理的出现，目前正迎来一场游戏复兴浪潮。现在有编程技能和时间投入不再是开发游戏的瓶颈，令人惊叹的是，如今涌现出大量有趣且富有创意的游戏。

数据分析是另一个生产力倍增器效果显著的领域，我能完成许多以前从未想过会做的事情。正如我在之前的多篇文章中提到的，我手头有太多这类项目，即使尝试快速撰写，每篇只花半小时，也难以一一详细说明。

我让 Fable 实现了一个自定义的 Neovim Lua 函数，根据我非常具体的要求对代码进行格式化。这既是我自己不想维护的东西，本质上也属于一种复杂繁琐的装置。理论上我可以通过修改 clang-format 以系统化的方式实现相同的效果，但我的要求如此精确，我认为这种方法永远无法令人满意。我们使用了一个名为 pgindent 的工具，这是 bsd_indent 的一个分支版本。虽然可以使用 clang-format 近似实现相同的格式规则，但这并不足够。如果我提交的代码没有完全按照 pgindent 的格式/缩进要求进行格式化，CI 会立即报错并要求我快速修复——这显然是我非常希望避免的情况。实际上，要实现类似 slick 的 clang-format 风格格式化并避免因代码缩进问题收到催促邮件，需要构建一个完全混乱的架构（我也不想花时间开发系统化方案，但这确实是另一个独立的问题）。该函数允许我轻松地从 Neovim 中格式化选定的代码块，类似于 clang-format 的 LSP 集成。当然，我在这里的要求有些过分挑剔，但我觉得 LLMs 让我能够如此精确地控制工具的使用。该函数执行多轮格式化：首先使用 clang-format/clangd 进行一轮格式化，然后使用 pgindent 进行另一轮格式化。我需要同时执行这两步，因为 clang-format 在某些 pgindent 无法处理的场景下表现更优。这种实现方式很脆弱，因为我的目标是仅格式化通过块可视模式选择的特定行范围内的代码（我不希望对未经过我补丁修改的代码运行 clang-format）。这与 pgindent 的设计存在冲突；它只能对完整的 C 文件进行格式化。确定临时完整文件缓冲区中需要复制回工作缓冲区的相关子集并非易事。我最初选择的行范围并不能直接映射到受影响的 C AST 元素。因此，该函数使用 tree-sitter 来智能地确定需要复制回的临时缩进 C 代码的精确子集。规则需要在特定场景下保持适当的模糊性，例如当我的选择跨越同一段代码时。存在大量边界情况。另一个复杂因素是 pgindent 依赖通过 objdump 生成的 typedef 文件来识别类型；缺少该文件会导致格式化效果异常。格式化函数会动态生成所需的额外 typedefs（仅针对该文件），因此我无需担心 typedef 文件过时的问题（我可能在运行格式化工具前几秒就创建了新的 struct，我不想每次都要对整个 postgres 二进制文件运行 objdump，这会显著增加延迟）。这似乎能完美运行。延迟完全可接受。尽管如此，我对所有这些机制的工作原理只有模糊的理解。我甚至不懂 Lua。即使我们对 bsd_indent 的分支版本进行进一步修改，导致代码格式化方式发生轻微变化，该方案似乎仍会继续正常工作（这种情况偶尔会发生）。我对 saaspocalypse（软件即服务灾难）持怀疑态度。但我确实认为 LLMs 正在编写大量有用的软件，这些软件通过其他方式开发将变得极其不经济。有一类有趣的软件子集，其维护成本相对于其创造的价值来说，对人类来说几乎不可能持续进行。

在撰写本文时，我还与Malis进行了交流，了解到他最近参与了许多有趣的项目。详细描述这些内容本身就可以写成另一篇文章，但其中一件有趣的事情是，上次我们讨论pgrust验证时，他提到使用Kani来验证代码的某些部分。此后他转向了Lean，并用Lean验证了一些Kani难以处理的复杂内容。这本可以作为另一篇文章的主题，但我好奇的是，为什么人们普遍选择Lean作为LLM驱动证明的工具（而不是像ACL2这样的工具）。我也好奇，如果更新这一定理证明器比较文章，Lean会呈现出怎样的表现，或者如果有人运行一个类似这种语言评估的定理证明器评估，会得到怎样的结果。

当然，你也可以想到许多来自人工智能实验室的例子，例如Anthropic这个中等规模的团队在五个月内不仅构建了内部的GitHub替代方案，还开发了其他一些工具。

七人团队在五个月内构建了Scion和Antique（我们的代码审查工具，我们甚至可以单独写一篇博客文章来介绍它），更不用说开发了多个相关系统，并完全迁移到了这些系统上。

我认为这些例子很有趣，它们指出了行业在不远的将来可能的发展方向。但如果你依赖由无限token支持的其他基础设施和工具，即使拥有无限token，这些例子也并不能说明你今天在没有无限资金的情况下能完成什么。像pgrust这样的项目，以及我认识的人在业余时间进行的项目（我可能只提到其中的1%，因为这类项目实在太多了，比如David Turner开发了一个“对我有效”的播客跳过工具，其效果优于他能找到的任何现有工具，还有Dennis Snell在这里提到的业余项目等）更能代表你今天能完成的事情。

• 在本文中，我会以一种对我来说感觉一致但可能被过度使用的方式使用“ambitious”这个词。我用这个词来表示以一种通用的方式完成比以前更多事情。有人可能会说，构建一个比以前合理可行范围更大的项目，与构建某种超专业化的工具（这种工具以前本可以完成，但当时不值得花时间开发）之间存在差异。虽然这两者差别很大，但我认为它们都源于同一件事（软件开发变得容易得多），因此我对这种可能被过度使用的定义感到相当放心。[返回]

• Alex Kolovsky指出这些问题不被视为错误。我理解从安全角度的论点，但我不具备足够的PostgreSQL背景来对此进行具体评价。不过，就我参与过的项目而言，我喜欢消除这类问题，因为如果你努力让代码从所有类似问题中保持干净，就更容易发现真正的错误。[返回]

• 我信任Malis的一个原因是他对所声称的内容比典型的创始人更加谨慎。例如，当我加入pgrust的discord频道查看人们讨论时，看到了Malis一个月前（2026-09-17，在代理编程领域堪称永恒）发的一条消息，这是针对有人询问pgrust是否适合作为生产数据库的回应：我目前不建议将其作为主要的生产数据库使用。我们正在为一家公司部署生产环境，但该公司对数据库宕机的容忍度比大多数人更高。在他们开始运行后，我们将获得pgrust可靠性的实际证据。Malis似乎不是那种在项目明显远未准备好时就声称其已具备生产就绪状态的人（许多知名项目都曾这样做过），事实证明他确实没有这样做。我在发布这篇文章前一周就写好了草稿，但当时没时间发布。此后，pgrust与Clickhouse的基准测试争议引发了关注。经过调查，关于存在恶意作弊的指控似乎不成立，而关于过早提交pgrust预览版参与基准测试的指控是Malis承认的。我认为这类事件是项目难以摆脱的污点，无论事实真相如何，人们多年后仍会反复提及。你可以在围绕该争议的讨论中看到这一点，正如我们之前讨论Ed Zitron的预测记录时，以及分析Kurzwil等未来学家的预测时所发现的，几乎没有人真正关注实际发生了什么，人们会无限期地重复基于直觉的错误说法。我无法完整呈现所有证明我信任Malis的证据（技术上我可以做到，但那将是一篇20000字以上的长文），但如果你比较他讨论pgrust的方式与典型数据库创始人宣传新数据库项目的方式，你会发现两者存在显著差异。当然，像MongoDB这样的极端案例也存在，尽管Kyle Kingsbury反复证明人们关于数据损坏的轶事是真实的，但MongoDB多年来一直争议这些正确性问题。以一个更典型的例子来说，我的一位朋友曾是某数据库初创公司的早期员工。他们网页上吹嘘实现了某个巨大的QPS数量。在测试时，我的朋友发现该数据相差几个数量级，并建议修改网页内容。创始人却不同意，因为他们计划实现这些性能指标，因此这个说法仍然是正确的。经过多年的性能优化后，公司最终将声明减少了一个数量级，而他们目前只能在非常刻意且不现实的工作负载下达到该数值。不幸的是，这在以性能为卖点的公司中相当常见。相比之下，当我查看pgrust的discord以了解Malis对性能的看法时，他最近的发言是：目前最能帮助项目的方式是发现0.4-beta版本中的bug和性能问题。新查询引擎在某些工作负载下非常快，但在其他工作负载下会导致性能下降，且不支持一些更复杂的查询。我们正在追踪所有比Postgres慢或导致错误的查询。鉴于可运行查询的巨大空间，这并不容易。我们希望在0.4-beta正式发布前解决这些问题。凭记忆来说，快速查询存在较大的性能退化问题。这是因为我们主要优化新查询引擎以处理大规模OLAP类工作负载。我正在做优化工作来解决非常慢的查询。我认为新引擎在快速查询上不应该比旧引擎更慢，这没有根本原因。尽管他之前在启动pgrust项目前曾是成功初创公司的创始人和高管，但他从未真正陷入大多数创始人似乎拥有的那种思维模式，即他们似乎可以说任何话并相信自己所说的一切。你可能会说这是一条很低的标准，我同意，但我仍然认为这种做法很罕见，这也是我无需深入调查就信任他对pgrust的说法的原因，同时当我深入调查时，他的说法似乎得到了现实的验证。[返回]

• 另一种看待方式是[Thomas Ptacek的表述]：过去一年，科技行业的发展速度仿佛让百年历史在瞬间发生。我们所处的行业正在经历自个人电脑诞生以来前所未有的动荡。AI遇到的每一个限制，往往在一个月内就会被突破。如今我们用前沿模型能完成的事情，几年后将变得即时且免费。鉴于最近的变化速度，我认为大多数人，甚至大多数程序员，对当前技术可能性的不了解是完全可以理解的。在与非程序员交流时，我发现一个有趣的现象：许多人反对对Ed Zitron预测准确性的评价，因为他们认为过去两年AI能力没有显著提升。对于我接触的大多数人来说，认为2024年秋季到2026年秋季AI没有进步的想法完全令人费解（即使你将编程视为例外，只看其他能力），但确实存在大量用户可能仅通过查看Google AI在搜索结果顶部的摘要，或使用集成在微软套件中的Copilot，却未意识到AI能力已取得显著进展。在各个层面，似乎都存在这样的信息梯度：实验室之外的大多数人对当前最高效人员正在如何利用模型进行工作，几乎毫无概念。[return]

• 关于网络作弊增加的评论已成为现实。重新阅读我之前写的评论时，我并未明确表示作弊行为的大幅增加是不可避免的，但通过将其中的陈述串联起来可以推断出这一结论。我在一些Discord等公开场合的发言中曾明确表达过类似观点。虽然我不关注在线游戏领域，但据我所知，在BGA（现代桌游最大的在线平台）最受欢迎的Azul游戏中，上赛季前十名中有三名是作弊者，其中还包括第一名。此外，正如我之前在其他地方提到的，BGA在几乎所有层面似乎都缺乏制定合理政策的能力。从其Elo排名算法的机制、游戏赛季的结构、应对合谋的政策、打击作弊的政策等方面来看，其设计甚至比最基础的解决方案还要糟糕。因此，正如预期的那样，他们并没有合理的政策来应对作弊问题。最受欢迎游戏的排行榜已被作弊者占据，这种情况很可能会蔓延到其他游戏中。从AI带来的影响来看，这属于相对温和的一类。这恰好是我上周看到的十多个例子之一，这些例子显示人们在开发软件时表现出更大的野心。我之所以提到这一点，一方面是因为它很容易量化，另一方面是因为我曾预测过这种情况会发生，现在跟进查看结果似乎也合情合理。[return]

• 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 的序列化版本）。[return]

• 顺便说一句，这使得公共评估对许多使用场景的意义不大，因为我和经常使用模型的其他程序员真正关心的是模型在仍需要人类指导的任务中的表现，而不是模型在对模型本身来说微不足道的任务中的表现。[return]

• 这并不是对未来的一种断言。也许我目前掌握的几乎所有软件技能，甚至全部技能，都可能在不久的将来变得无关紧要。但目前我们还没有到达那个阶段。现阶段，编程技能似乎比以往任何时候都更具杠杆效应。当前的处境有些讽刺意味：拥有被模型取代的技能的人，似乎比那些试图使用模型却缺乏这些技能的人更有效率。我赞同 Max Bittker 的观点，即模型在伪造方面非常擅长，而随着模型能力的提升，区分伪造品和真品所需的专业水平也在不断提高。[return]