从去年 11 月以来我一直在重度使用 AI，整个体验挺荒诞的。智能体会干出那种事——如果是人这么干，你会立刻把他开掉。而我的反应，当然是觉得这太棒了，于是开了上千个智能体，让它们变本加厉地接着干。

去年年中，我让 GPT（可能是 5.0 或 5.1）去找一个 bug 的源头。那段代码自然没有测试，git bisect 也用不上，而且是个连我都没资格为它写测试的 UI 交互 bug，于是我让 Codex 在日期 X 到 Y 之间做二分查找，找出引入这个 bug 的提交。Codex 立刻告诉我，罪魁祸首的提交在这个日期区间之后（这不可能是对的）。我告诉它错了，它又一连一两次给出了明显也不可能是罪魁祸首的提交。我再说不对，它又给了一个看起来挺像那么回事的提交。当我让它证明或证伪自己的猜测时，它说自己写了测试并确认了那个提交就是导致问题的提交。

接着我让它用完整的端到端开发者栈，在常规的浏览器测试环境里录个视频来证明。它声称自己没有权限这么做（这是撒谎），但可以在 playwright 里用相应的测试代码录制提交前后复现过程的视频。视频很有说服力，显示功能在提交前正常工作，提交后失效。只是总觉得哪里不对劲，于是我手动在提交前后复现了一下，才发现整件事都是编的。视频看起来像是 Codex 复现了 bug，但那是一个被刻意设计出来制造假复现的人工浏览器环境，并非真实环境。

就像我说的，正因为这次体验好得毫不讽刺，我立刻想的是，“怎么才能多来点这种体验？”于是越来越重度地使用智能体，直到去年年中晚些时候已经在重度使用编程智能体。

由于本文涉及的话题比较分散，这里先给个简要提纲。

测试背景

说到测试，LLM 的杠杆效应极高。按投入的精力算，要达到某个质量门槛比以往任何时候都容易，可软件看起来却比以往任何时候都更差。十年前，我们曾盘点过在一周内随便遇到的 bug。那时 bug 就不少，现在我遇到的更多，但我觉得本不必如此。

一方面，bug 上线之后，用数据驱动的方式去发现和修复 bug 比以往任何时候都容易。就拿比如说，在公司里，我试着搭了一条从客服工单（聊天或邮件）到拉取请求（PR）的流水线。就我观察，效果还不错。由于我们公司走的是传统工作流，所有修复都会经过人工复审，到目前为止还没有已知的误报。

按单位时间投入算，也能做更彻底的测试。就我个人而言，我觉得这种做法可以有效到让我比较放心地通过“软件工厂”工作流来大量交付代码，因为我见过那种重测试、无复审的工作流，其质量远高于我见过或听说过的任何依赖复审的工作流。

和所有人一样，我的偏见来自我的经历。恰好我职业生涯的前十年在一家芯片公司 Centaur 度过，那里的测试流程在如今的 LLM 环境下意外地很适用。我在 Mastodon 上聊过把模糊测试作为默认测试方法，一位 skeptical 的网友试了一下立刻就发现了几个 bug：

所以我重读了那篇博文，本来是一脸怀疑，结果没错，Claude 做的模糊测试确实发现了几类值得修的 bug

我聊过的其他一些人也尝试了类似本文后面要讲的测试流程，他们都在自己负责的软件里立刻发现了 bug，包括那些光让 Codex 或 Claude 去审计代码、找 bug、 “测试”、“多测点”时根本发现不了的 bug。比如 Dennis Snell 提到，他和同事 Jon Surrell 不仅在自己维护的代码里发现了 bug，还“在上游依赖里也发现了，包括 HTML 规范、三大浏览器和其他开源项目”，而且花力气很小。

一般来说，当我和做软件的人聊测试时，我的出发点就和他们完全不同，他们会立刻觉得我是外星人，所以先说说我在 Centaur 这家硬件公司是怎么做测试的，这也塑造了我对工作方式的偏好。我们做的一些在软件世界看来离经叛道的事包括：

1. 雇佣专职的 QA / 测试工程师，测试是与开发平级的一流职业路径
2. 默认不做代码复审
3. 几乎没有手写测试
4. 通过程序员有时称之为基于属性的测试、随机化测试、模糊测试等的方式持续测试，不过我们就直接叫它们测试（手写测试则被称为“手测”）。
5. 庞大的回归测试套件（在计算集群上跑完需要 3 个月墙钟时间）
6. 没有单元测试

为了让你有个直观感受，我 2013 年离开时，我们大约有 1000 台机器一直在生成和运行测试，对应大约 20 名逻辑设计师和 20 名测试工程师。这些机器都是自建机房，占了所在大楼半层楼。

大体结构是，大约 20% 的机器跑回归测试，80% 生成并运行新测试。三个月的回归测试太长，没法用来卡提交，所以还有一份精简得多的测试清单，大概 10 分钟就能跑完，大家在提交前会跑一下。这些提交前测试会在专门为极速运行搭建的环境里跑，用的是能买到的最快的超频机器，以及不同的仿真器配置。

新的失败会随时被发现和上报，一到两名工程师负责分拣和分流（剔除误报、修复导致误报的测试生成器问题等）。

就影响量级而言，除非把文化单算一项，（1）可能是我们和典型软件公司最大的区别，但对本文读者来说也是最不相关的，所以我把它放到脚注¹里，只在这里简单说一句：测试和其他技能一样，投入时间越多技能越强；而在大多数大型科技公司，测试并不是一流的职业路径，所以软件公司里的人在测试技能上，普遍不如那些干了几十年 CPU 测试的工程师。就像一个花 20 年做分布式系统或 UX 的工程师，肯定比一个只花 5% 时间在这上面的同等天赋的工程师强得多，花 20 年做测试的人，也比只花 5% 时间做测试的人强得多。

（2）是我们芯片公司的测试实践适合 AI 工作流的原因之一。我们默认不复审代码，是因为我们足够信任自己的测试实践，复审对可靠性提升不大。我们每年向用户交付的重大可见 bug 不到 1 个，只有在有人觉得某处特别棘手、想多一双眼睛看看时，才会做复审²。在 AI 编程工作流里，一个人生成的代码量很容易超过任何一个人甚至十个人能手工复审的量。大家对不经复审就发布代码的接受度不同。就我个人而言，我非常乐意不经人工复审就发布代码，因为我见过有人这么做过，而且是在从正确性角度看比大多数软件公司都更具技术挑战性的产品上。

我经常看到有人说，“风险太大了；我们有几百万用户”，但就经验而言，他们所说的那个依赖复审来捕捉 bug 的工作流，人均 bug 率可能是我们的上千倍，如果按严重程度折算差距更大。如果一家公司靠主要依赖复审来捕捉 bug，却能做到只有我们 Centaur 百分之一的 bug 率，那我能理解他们的顾虑，但现实中那些不愿放弃人工复审的典型软件公司，情况并非如此，原因是担心发布 bug 的风险。

（3）和（4）是相辅相成的。我认识的几乎所有认真对待可靠性的软件团队（各种做可靠数据库、分布式数据库等的团队）至少在大方向上都在做同样的事，虽然他们手写测试的比例可能更高。就像靠自己与软件交互、观察软件是否“看起来正常”来做测试被认为是很差的主意一样，直接手写测试的输入和预期输出也是很低效的。如前所述，手写测试真的很低效。在同样的可靠性目标下，优先用随机化测试生成而不是手写测试，会更快达到目标。

（5）是因为大量测试发现了大量 bug 而自然形成的。一般来说，如果一个测试发现了后来被修复的 bug，我们就会把它永久保留在回归套件里。结果就是，如果你用好的测试发现了很多 bug，就会得到一个庞大的测试套件。但抛开这一点，只从测试效率看，软件里那种每个 PR 都在 CI 里跑同一套测试的标准做法极其低效——想想看，一天内把同一个测试跑一千遍，和在同样的测试时间里跑一千个不同的测试，哪个更可能发现 bug。

（6）也是出于测试效率的考虑，因为我们的团队比竞争对手小得多。这也是公司能存活那么久的原因之一。当 Intel 把除 AMD 之外的所有 x86 设计公司都挤垮时，我们的运营成本足够低，让公司一直撑到 2021 年才被 Intel 以 1.25 亿美元收购。以公司极小的团队规模，如果靠单元测试来获得合理的测试覆盖率是不可能的，雇足够的人去写单元测试，恐怕会让公司像 Transmeta、Rise、Cyrix、TI、UMC、NEC、VM 等的 x86 业务一样，提前一二十年就倒掉。从效率角度看，单元测试效果很差。

总结一下，我们做了不少软件同行告诉我是馊主意的事（专职测试工程师、没有单元测试、没有代码复审等），但我们的质量却远高于我待过的任何软件公司或用过的任何软件。每当我聊起这个，总有人说这不适用于软件，因为 CPU 只有 X 方面的顾虑，而 Y 方面不能这么做。刚从 CPU 设计转到软件时我也觉得可能有道理，但后来我把这种测试方法试遍了别人说“这招对 Y 不灵”的各种 Y，结果全都有效，所以我现在不太信这套说辞了（而且那些 X 通常都对硬件开发有错误假设）。硬件和软件确实有实质差异，但当有人拿这个当作测试技术无法迁移的理由时，往往是依赖于某个想象中的因素，而这个因素之所以显得相关，仅仅是因为那个人对硬件开发了解不多。

一个显著差异是测试与开发的投入比，但模糊测试的固定成本相当低，所以在任何投入水平上都能扩展，效率提升依然存在。而且由于测试效率的提升，投入比并没有软件工程师通常想象的那么大。我们测试工程师与开发者的比例大约是 1:1，然后大约有 10% 的时间处于“冻结”状态，目标是找 bug 而不是发新功能，所以粗略估算，我们把 55% 的精力花在测试上，45% 花在开发上，也就是说如果完全不做测试，我们可以把 2.2 倍的精力投入开发。看看那些以比我们快很多倍的速度发布重大 bug 的软件公司，就算你宣布进入紧急状态，让大家把 55% 的精力花在测试上，我觉得比例变化也不会太大。也许能降到之前的一半左右，但投入水平并不是造成差异的真正原因。

如今，另一种常见说法是，既然可以直接让 LLM 找 bug，何必还要做模糊测试？我两种都试过很多次，经验是模糊测试在发现 bug 的延迟上通常胜出，在发现更多 bug 和更低误报率上则完全碾压。LLM 的方差很大（后面会细说），所以单问 Codex 或 Claude 找 bug 有时也能赢，但平均下来还是模糊测试赢。

测试的一些细节

尽管我把 LLM 测试说得很好，LLM 在测试方面其实挺差的。不过，在任何测试投入水平下，如果引导得当，LLM 能让你比以前轻松得多地投入测试精力。

一个极端的例子是，我认识的所有在乎质量或测试的人都觉得，LLM 默认生成的测试，或者你对它说“写测试”、“再多写点测试”等让它生成的测试，都很差。人们倾向于把这些测试评价为从毫无价值到勉强有用之间，取决于个人的标准。

比如，编译器工程师 Em Chu 说：

我手头现有的测试并不完美，但仍然高于 LLM 瞄准的水位，我会把 LLM 的水位形容为“刚好能把一个功能糊弄过人工代码复审”。对编译器（相比比如 UI）而言，我猜平均写一个测试更容易，但对最终产品的正确性要求也更高，LLM 就是不行。它们在那种对抗性的“那，如果我这么干呢”或“把所有东西交叉组合试一遍”的人类写测试思路上，糟糕透顶

与此同时，我也见过不少人盛赞 LLM 在测试上有多厉害，只要你对它说“写测试”、“再多写点测试”等等。我去深究人们为什么说 LLM 擅长测试，发现那些觉得 LLM 很厉害的人，基本上之前就没怎么做过测试。好吧，这就说得通了。如果你从基本零测试投入到有一点点测试投入，那当然是巨大的胜利。

截至 2026 年 6 月，让 LLM 去做模糊测试/随机化测试的感觉也类似。我试过让 LLM 生成模糊器，对大多数项目来说，几分钟内就能发现真实且往往很严重的 bug。然而，看看 LLM 创建的模糊器到底在测什么，我的反应就和一个在乎质量的普通程序员看到 LLM 创建的测试时一样：LLM 生成的模糊器的覆盖率出奇地差，漏掉了大量你会期待一个仓促手写的模糊器都会覆盖的基础东西。取决于你是半杯水空还是半杯水满的人，你可能会说这说明大多数项目的测试覆盖率有多差，或者说明模糊测试有多不讲道理地有效。

从高层次看，今天 SOTA 模型生成的 LLM 模糊器并不擅长“思考”应该如何变化输入来触发 bug。然后，如果你天真地告诉它应该如何变化输入并让它组合这些，它也不会以合理的方式组合 bug 要素。给出能有效工作的指令是可能的，但这高度依赖用户来提供方向。

如果你把随机化测试当作“额外加分项”，用来多抓几个 bug，或替代传统的软件测试流程，你可以直接让 LLM 去看代码中风险高的区域，找出可能被违反的不变量并对它们做模糊测试。这样做效果还行。当我劝人尝试一些随机化测试时，他们通常从这里开始，也能找到不少让他们高兴的 bug。由于对尝试新测试技术感兴趣的人的性质，这往往是那些在公司里负责最经测试、最可靠代码的人，他们也能在自己相对已经测得很充分的代码里找到 bug。

如果你想用随机化测试来约束那种智能体“软件工厂”工作流，让它保持诚实，那你就必须有办法应对 SOTA 模型的盲区，因为当你每天往项目里塞相当于数百上千个 PR 的代码量时，任何没有被约束住不让其退化的东西都会迅速退化。

从高层次看，整个系统需要某种反馈，能发现盲区并指示负责调整模糊器的循环去补上盲区。最近我在测试一些我既不懂领域也不懂项目或代码的东西，所以基本是在盲飞，知道自己想出来的东西会有很多盲区（而且如上所述，LLM 在这方面很差）。但即使在我熟悉领域、比较了解代码的领域，人也会遗漏东西、会犯错，所以始终需要某种能发现盲区并让人类或智能体去补上的反馈机制。

我一直在尝试让智能体们聚在一起、反复会商，以让智能体循环跑得更好，虽然这有帮助，但我还没找到一种能很好地做到这一点的方法，去创造某种不依赖外部反馈的智能体软件质量提升循环，无论是偶尔的人工输入，还是发布东西（理想情况下只做灰度、分阶段发布）然后让系统监控指标/日志/追踪/工单/ whatever 并以此作为反馈。上面提到的工单到 PR 的流水线就是这样一种反馈循环。该流水线不仅尝试生成 PR，还尝试让测试体系增加能发现该 bug 的测试覆盖，甚至可能发现其他 bug，或在未来回归时重新发现该 bug。这看起来效果还行，确实能发现真实 bug 并提升测试覆盖，但肯定还有很多改进空间。

相关地，我一直在好奇为什么 LLM 这么不擅长写测试。问了一圈，被告知这是因为 LLM 的能力来自人们构建的 RL 环境，这些环境让模型能在任务上提升，有时能泛化，有时不能。还听说有一个买卖 RL 环境的市场，但比较小，因为买家不多，你得认识实验室里负责采购的人或接近他们的人。如果你就是这样的人或者能帮我引荐，请务必联系我（我在 X、Mastodon、邮箱等渠道都很容易找到）。我很好奇这套机制是怎么运作的，以及为测试、优化或本文讨论的更长周期的任务卖一个 RL 环境有多可行，在这些任务上很容易观察到明显的差距。

回到测试话题，在做模糊测试或任何形式的 bug 审计时，检测误报是流程中至关重要的一环。至少就目前而言，拥有一个比公开可用模型更强的模型并不能救你。前段时间，Dennis Snell 沮丧地告诉我，他花了一整天清理 Anthropic 转发给其雇主的 AI 垃圾，那些垃圾来自他们那个据称太危险而不能向公众发布的 Mythos 模型。Anthropic 显然是在给这家公司帮个忙或做某种 EA 安全改进，只是他们连一个像样的误报剔除流程都没做，就直接把垃圾转发了过来。当时我用的模型，如果以 Fable 为参照，看起来比 Mythos 能力稍弱，但我却能毫无问题地生成源源不断的 bug（其中一些是安全问题）且没有已知误报，这似乎说明模型周围的合理配置至少和拥有最新最强的模型一样重要。

我一直在按项目/按问题尝试定制化工作流，还没有一个通用的误报剔除方案，但有一些做法似乎有一定通用性。如果你不介意多花 token，让独立的智能体反复检查所谓的 bug 复现（repro），能显著降低误报率。几个月前，我提到用不同“人格”做复审以及管理智能体循环效果不错，我收到了一些理论上认为这不怎么有效的回应，但在实践中似乎效果相当好。我的工作流经常变，大概在那次讨论一周后，我开始在组合中加入“唱反调”人格，在同样的墙钟时间或 token 预算下，效果有所提升。

对于任何需要人工复审的东西，有某种产物（例如，如果是预期在 UI 上可见的 bug，就提供视频）是必要的。即使不刻意让智能体去复审，光是生成这个产物似乎就能在一定程度上降低误报率，再让智能体去复审产物，误报率会进一步降低。让智能体独立地复审产物（例如，对比查看生成视频的测试代码 vs. 直接看视频本身）也能进一步降低误报率。总的来说，获得独立视角对降低误报很有帮助。在我做过的实验里，按墙钟时间或按花费算，这比让不同人格/视角的智能体效果要差一些，但即使只是反复问同一个问题多次也能改善结果，原因从 LLM 方差那一节的图表中应该很明显。

基本上我尝试过的每一种降低误报率的方法都有效，所以如果你还没把工作流扩展到需要优化成本的程度，做任何大致合理的事似乎都挺有效。

野人模式

我不断收到各种工具和工作流推荐，可当我去深究时，几乎找不到靠谱信息来判断到底该不该采纳。举个例子，我在公司里多次看到有人推荐“野人模式”。据称野人模式能减少 token 使用、加快提示词解析（README 声称 token 使用减少 75%、65%，以及 token 使用减半，还有 3 倍速度提升）。

搜一下信息（就直接谷歌搜 ‘caveman mode’，不加引号，除了野人模式本身的链接外，排名最靠前的结果是这个 reddit 帖子，其中三条最热评论里，一条是玩笑，另外两条都强烈推荐：

就是极致简洁，让人耳目一新……而且 token 数量大幅下降，却似乎完全不影响分析思考……但我没法做前后对比的基准测试。

公司有人在测试，好像真的省 token 而且效果一样好。

其余大多数靠前的结果也都是对野人模式的正面推荐，声称做了某种评测（虽然读起来像未经筛选的 LLM 文本），而 YouTube 上排名第一的则是最大的编程 YouTuber 之一说：

它真的有效；效果真的很好……不，我没有夸张

在公司一个推荐野人模式的 Slack 讨论串里，我问有没有人做过对比，并指出野人模式的作者在 HN 上回应相关帖子时说那是个玩笑。有人贴了一个声称有显著收益的野人模式分析，但那篇分析是 LLM 生成的 SEO 垃圾文章，错误百出。当我礼貌地指出这一点后，发链接的人说“我只是粗略扫了一眼”。

到这时，我决定花大约 15 秒每次来生成一些野人模式的基准测试（现在好像大家把基准测试叫 evals，那我也该叫 evals？）（之前在这里更详细地讨论过）。

先说说背景，当时这个讨论出现的前几个月我一直在大量使用 GPT-5.5 xhigh，所以我们先来看看 GPT-5.5 xhigh 在第一个基准测试上的表现，这是一个让智能体用 wasm 优化代码的简单基准。由于这是我花 15 秒让智能体生成的，我觉得不值得花太多时间讨论细节，但有一点要注意：比起智能体取得的任何结果，你完全可以做得好得多。我预期一个手工做这件事的人，或一个对智能体有明确指导的人，会比任何 AI 都取得好得多的结果。对于优化图表，1.0 表示没有加速，越高越好（低于 1.0 表示“优化”反而变慢了）。为了让你了解跑实验时的样子，你可以点击按钮交互式地跟随，或直接播放动画。

可以看到，对于第一个基准（在 wasm 中优化一个非平凡算法），跑一次之后，野人模式看起来不错。我们得到 1.027 倍加速 vs. 0.987，$12.10 vs. $23.10，墙钟时间（智能体耗时）8分51秒 vs. 14分9秒。但我们知道 LLM 是随机的，所以应该再跑一次。第二次跑后，结果出现了很大变化，平均加速都是 1.0，但野人模式花费 $12.45 用时 8分64秒 vs. $40.38 用时 17分57秒。这可是巨大的成本节省，和野人模式宣称的节省相符。逐帧解说动画有点傻，但如果直接跳到最后，可以看到50 次运行后的平均值仍然偏向野人模式，1.03 vs. 1.01 的加速，以及 $17.97 用时 13分46秒 vs. $24.21 用时 16分52秒。这没有两次运行后看到的那么好，但依然明显偏向野人模式。

我让 GPT-5.5 xhigh 做了经典统计和贝叶斯统计，它生成的脚本显示，对于优化 1 基准，野人模式在加速、成本和墙钟时间上更好的 p 值分别为 0.1、0.005 和 0.001。用贝叶斯统计，P(野人更好)分别为 0.958、0.999 和 1.000。我们也可以看看另外两个我花 15 秒做的基准。优化 2 是另一个“在 wasm 中优化这段代码”的基准，而游戏 AI 是一个让智能体为《失落之城》实现一个棋盘游戏 AI 的任务，每步限时 10ms。

这些基准的结果看起来喜忧参半。对于优化 2，P(野人更好) = 0.17、0.999 和 1.000，而对于游戏 AI，P(野人更好) = 0.04、0.79 和 0.73，所以野人模式在优化 2 和游戏 AI 上实际上给出了更差的结果，这和我们在优化 1 上看到的相反。顺便说一下，我展示这些结果的顺序并非为了制造某种出人意料的叙事反转而刻意挑选的。如果到此为止，我们可能会认为野人模式结果更差但更省钱，或者在某些任务上更好、某些上更差但省钱。

如果我们再试几个模型（GPT-5.4 mini、GPT-5.4、GPT-5.5）在每个努力程度上的表现，得到如下平均值，整体图景就更不清晰了（在下面的图中，越往左上越好，越往右下越差；箭头从基线指向野人模式）：

这里有什么规律？举几个例子，对于优化 1，野人模式通常比标准模式结果更好，但对于优化 2 和优化 3，大多是反过来，虽然也有例外。在成本上也能看到各种模式。不同条件（任务以及模型和努力程度）之间的方差足够大，很明显我们得跑更多条件才能看清到底怎么回事，而总体上差异平均下来很小，似乎不值得使用野人模式。

LLM 的方差

最近新模型发布时，我都会去搜搜大家怎么说。一般来说，到处都能看到互相矛盾的评论。比如 GPT-5.5 发布时，有人说，GPT-5.4 比 5.5 好，因为 5.4 更能紧扣任务而 5.5 会跑题、过度思考，导致 5.5 更贵且没意义；也有人说 5.5 比 5.4 好太多，所以更便宜，因为它不会那么频繁地搞砸然后卡在修复自己的问题上；还有人说 5.5 比 5.4 便宜，因为它效果太好，你可以用更低的努力程度；还有人说 5.5 “就是能用”而 5.4 经常失败需要手把手，等等。通常，会有人跑个基准测试来证明自己的说法是对的。

看看这些基准测试，我们能为我在 reddit 上搜 GPT-5.5 发布后评论时看到的每一种说法都找到支持。在优化 1 上，GPT-5.4 的结果好于 5.5 且便宜得多。但在游戏 AI 上，GPT-5.5 明显好于 5.4，好到 5.5 high 的成本大约相当于 5.4 xhigh，但结果更好，而 5.5 medium 比 high 更便宜且结果明显更好。就靠这三个 eval，你就能为我看到的关于 GPT-5.5 的每一种说法找到支持，因为所有说法在某些时候都是对的。而且这还是在用比任何一个在网上随口评论的人会做的次数多得多的运行来平均掉方差的情况下。

一般来说，这就是为什么当我看到一个汇总一组基准测试的指标或图表时，我会想，“把分布给我看看”。对模型的基准测试往往被归结为一个漂亮、整洁的数字，你看到 X 比 Y 好，Y 比 Z 好。我觉得这些基本毫无意义，因为如果看的是 OpenAI 和 Anthropic 最新最强的模型，我们知道存在合理的基准测试让 X 比 Y 好，反之亦然。如果这组基准测试里多几个偏向 Y 而不是 X 的任务，结果就会反转。要让那种汇总指标对我有用，必须满足这组基准测试完美镜像了我所做任务的分布和权重，且我只能为所有任务选择一个模型。由于这两点都不成立，很难说我能从这些基准测试中得到什么可操作的结论。

如果更细致地看公开基准测试，情况似乎比上面抽象论证的还要糟。结果通常以很高的精度呈现，好像那很有意义。比如在 DeepSWE 上，我们可能看到（比如）GPT-5.5-xhigh 比 Fable 5 medium 好 1%，但成本低 19%。再和 Opus 4.8 比，也许 GPT-5.5 xhigh 比它好 13% 但成本高 11%。如果想知道这意味着什么，我们可以深挖数据，会发现某个号称有意义的基准测试，因为有一大堆多样化任务，但它们全是跑 4 次的通过/失败任务，而且大多数任务要么很简单，用最好的模型能 4/4 通过（只是由于随机噪声，有时会看到随机的 3/4），要么很难，基本都是 0/4。然后只有一小部分任务真正决定了这些 SOTA 模型之间的相对分数。如果把其中一个换成另一个，两个最高分模型之间的结果就可能对调。如果换掉几个任务（总共约 100 个里），那个看起来差很多的 Opus 4.8 就可能超过 GPT-5.5。再换几个，GLM-5.2 也可能反超。

当我看到这种事，就会想起 Miguel Indurain，他在我小时候算是家喻户晓的人物，尽管我并不关注自行车。几年前我好奇为什么自 Indurain 之后自行车界的家喻户晓人物都是和他完全不同类型的人，答案是这很随意。由于一些随意的原因，环法成了世界上最著名的自行车赛，而有过一段统治期的人就能出名到圈外人都知道。由于另一些随意的原因，有一段时间环法的个人计时赛段比现在长得多，这正适合 Indurain 这种类型的人。你稍微调整一下基准测试，Miguel Indurain 就会从一个家喻户晓的名字，变成一个除非关注自行车否则几乎没人听说过的史上最伟大计时赛车手。

回到编程智能体的话题，目前还不清楚到底谁真的需要关注这些给出模型表现汇总指标的基准测试。如上所述，作为模型用户，这些基准测试并没有有意义地告诉我该用哪个模型。

如果很多其他用户根据这些基准测试来做决策，那么 AI 实验室就需要关心它们在这些基准测试上的结果。但尽管 GPT-5.5 在其统治期间在大多数这类基准测试上都轻松击败了各代 Opus 4.x 模型，Anthropic 的业务在最好公开可用模型是 GPT-5.5 和 Opus 4.6/4.7/4.8 的那段时间里，增长速度远快于 OpenAI，以至于 OpenAI 一直在向企业赠送免费 token 来试图说服人们用 GPT。我的公司就是众多获得数月免费 token 的公司之一，而在那段时间里，大多数人仍然主要使用 Claude 和 Opus。Anthropic 的营收轨迹与这些基准测试是用户选择的主要决定因素这一说法不相容，所以我不知道为什么有人应该在意这些汇总指标显示了什么。

上一组图表展示了跨任务的方差有多大，但从前一组图表中，我们也看到在同一任务、同一模型和同一努力程度下，运行之间的方差也很大。如果只看少量单次运行，那么由于运行间的方差，几乎任何结论都是可能的。举个例子，只看优化 1，GPT-5.5 xhigh 单次运行之间的一个标准差是 0.075（即性能提升/下降 7.5%）。看看被测 GPT 中最好和最差的平均差异，分别是 1.055（GPT-5.4 xhigh 野人模式）和 0.986（GPT 5.4 mini low），这还不到 GPT-5.5 xhigh 跨运行的一个标准差（SD）。对于实际图表而不只是汇总统计，我们有：

对于每个任务，无论最佳条件是什么，都很容易得到一个最佳条件实际得分反而低于最差条件某次得分的结果。当我和 Max Bittker 聊天时，他因为经营一家 RL 环境初创公司而做了比我多得多的基准测试，他说：

是啊——任务之间和运行之间的噪声水平太高，难怪舆论会混乱。很容易犯像“哇，新模型太牛了” -> “哎呀，我其实一直用的还是旧模型”，或“这个新的 harness / 提示技巧太棒了！”之类的错误

但另一方面，基准测试也让我对一些说法有了信心，比如“Opus 模型在恢复和调试令人困惑的情况方面比 Sonnet 模型好得多”和“中国模型在 SWE-Bench 上得分很高，但在新颖任务上表现不佳”，这些都有更强的统计显著性。

另一条评论，这次是大意转述，因为是凭记忆，Matt Mullenweg 说，如果你观察那些从事高方差活动的人，比如赌徒，他们往往很迷信。你会看到有人穿幸运袜或在坐下来玩老虎机前做一套特定仪式。使用野人模式或因为编程智能体吐出一个好结果就认定某个模型好，差别也不大。

以上这些我都是在 Fable 发布前做并写成初稿的，然后 Fable 发布了，出于好奇，我又跑了几次 Fable 的基准测试，那时它又被下架了，所以也顺便跑了几次 Opus 4.8。[本文在 5.6 发布后编辑，加入了 5.6 的基准测试到下图]

就像我上面提到的，这些都是我花大约 15 秒让智能体敲出来的小基准测试。借助编程智能体让你能规模化流程，你完全可以在每项人类时间仅 15 秒的情况下创建大量合理的基准测试，但这并非某种为批量生产这些而精心设计的装置；我这么做只是因为想做个野人模式对比，而当我尝试让智能体在无监督下做这件事时，基准测试完全是垃圾。稍微花点时间，这些基准测试对评估野人模式、判断它不值得进一步研究来说已经足够好。如果我要公开发表，我会花更多几分钟在多个方面把这些基准测试做得更好，但我觉得它们对讨论方差来说已经足够了。我不会过度解读结果，但我确实做了一些基本检查，比如查看异常结果以确保智能体没有作弊或不存在某些问题（比如机器噪音导致异常差的运行时结果），智能体没有作弊，最慢的结果在安静的机器上也能复现，等等。

而且，抛开这个免责声明不谈，就像 GPT 的基准测试一样，我们在这些基准测试中也能看到反映网上讨论的方差，例如 Fable 在某些任务上很强而在另一些上不那么强，不少人正基于在一小部分事情上的表现来断言 Fable 的整体性能。如上所述，OpenAI 在 DeepSWE 上做得比 Anthropic 好（GPT-5.5 =~ Fable 5 > Opus 4.8），我们可以在优化 1 上看到类似的结果。另一个被人们反复发给我的广泛引用的基准测试是 Senior SWE-Bench，Anthropic 在上面比 OpenAI 好（Fable 5 > Opus 4.8 > GPT-5.6 Sol），我们也可以在游戏 AI 基准测试中看到类似结果，其中 Fable 5 > Opus 4.8 > GPT-5.6 Sol > GPT-5.5。

上面我们讨论过，为什么作为智能体用户，我或任何特定用户都很难有效利用这些给出排名或一小撮数字来告诉你模型有多好的基准测试。但即使深入到单个基准测试内部，作为用户，我仍然不清楚应该如何根据基准测试来改变自己的行为。

举个例子，我观察到 Opus 4.8 编造糟糕理由来解释事情的频率远高于 GPT-5.5。我曾多次让它们处理同一个问题（我经常让两者都去解决我实际遇到的问题，就看看会怎样）。这些往往是比这些基准测试问题大得多的问题，比如真实的调试任务，或在构建游戏 AI 的场景下，不只是简单提示生成一个 AI，而是一个智能体循环和/或一系列指令来让智能体生成一个相当强的 AI。我问过一小撮人，他们都观察到 GPT-5.x vs. Opus 4.6/4.7/4.8 有同样的现象，包括那些更喜欢 Claude、主要用 Claude 且对 Opus 经验更丰富的人。

反过来说，我见过两个衡量模型检测虚假信息和/或不胡编乱造能力的基准测试，这两个基准测试都显示 Opus 远好于 GPT，好到如果按基准测试的字面呈现来理解，我和其他人实际经历过的事似乎是不可能的。例如在一个基准测试中，按天真的解读，Claude Opus 和 Sonnet 在检测虚假信息方面远好于任何其他模型，而 Opus 4.8 绝对最好，有 95% 的时间能检测出虚假信息，包括在软件领域也有 95%。而 GPT 则很差，排名在 Qwen、Grok、Kimi、Minimax、Mimi 和 Nemotron 之后。

这是怎么回事？我不确定。

也许那些基准测试衡量的是与我（和其他人）在处理实际编程问题时遇到的胡编乱造不同的另一个维度，或者也许这只是小样本，而我和其他人只是从 Opus 那里随机抽到了差的运气，又或者我们“没用对”Opus。我猜测基准测试衡量的是与编程或调试时遇到的错误合理化不同的东西，但要对此有信心，我得跑一些相当昂贵的实验。如果你想支持我做实验，可以订阅我的 Patreon，或者如果你在 AI 实验室，给我一些免费额度来跑实验也行。

顺便说一句，在游戏 AI 基准测试里也有类似的情况，Opus 明显好于 GPT，但当我尝试去管理创建一个真正强大的（超人类）游戏 AI 的过程时，GPT 似乎表现更好，因为 Opus 总是陷入胡编乱造/胡乱合理化的失败模式。在无监督的情况下两者都很烂，各有各的失败模式，但在有指导的情况下，GPT 需要更少的推动就能保持正轨、持续做能奏效的事。这在小规模的游戏 AI 基准测试中完全没有体现，其中 xhigh 的一次运行只是单个提示，“仅”花费约 10 美元，而且小基准测试得出的结果与做真实版本任务时看到的相反。

但重点是，即使你找到衡量某个看似正是你在乎的东西的基准测试，那些基准测试往往也和你在实践中看到的不符。如果你是个像我这样的怪人，也许你会决定花大量时间和/或金钱跑些实验来搞清楚怎么回事，但如果你只是想完成某个工作（也许是你本职工作），这么做就相当不现实了。

顺便说一下，基准测试中还有一些人们常觉得反直觉的模式。与基于公开可用基准测试讨论哪个模型更好（这毫无意义）不同，我觉得这点倒有点意思也有些启发性。上面我们已经提到存在 GPT-5.4 表现优于 5.5 的基准测试。投入更多努力反而让结果变好或变差也是可能的。例如在优化 1 上，GPT-5.6 Luna 随着努力程度增加单调变差，在优化 2 上也大体变差，但在游戏 AI 上却随着努力程度增加而单调变好。我们还能看到 GPT-5.6 Sol 的 max 比 xhigh 在优化 1 和游戏 AI 上表现更差。而对 GPT-5.6 Sol 来说，ultra 在全部三个基准测试上都比 max 好，而且在优化 1 和游戏 AI 上实际上比 max 更便宜。即使在同一家提供商或同一模型内，很多人们直觉上会期待的事（比如更多努力带来更好结果）也不成立。当再加上跨不同提供商看到的更大差异时，结果呈现出高度异质性，使得像 X 比 Y 好这种简单说法，除了在模型能力差距非常大的情况下，通常都是错的。但如上所述，我们可以毫不费力地、不带挑选地找到 Anthropic 上一代模型优于 OpenAI 当代模型以及反过来的例子。

当我看到人们到处引用这些基准测试时，它们往往只是用来佐证某人的迷信，比如在公司里，我看到有人引用 Senior SWE-Bench 的结果 Fable 5 > Opus 4.8 > GPT-5.6 Sol，说这很现实（来自一个认为 Anthropic 远远领先 OpenAI 的人）。当然，也有人同样可以引用 DeepSWE，后者显示了相反的结果。

我信任的、在这些事上有判断力的人都觉得这些基准测试相当不靠谱，因为今天 Anthropic 上一代模型总体上比 OpenAI 当代模型好或反过来这种说法，对一个用过这些东西不少时间的人来说，根本经不起直觉检验。当我问我信任的 AI 实验室之外的人他们如何形成对模型好坏的印象时，通常就是凭感觉，以及收集其他凭感觉的人的印象，因为显然基准测试结果并不能比你肉眼观察得到更清楚的认识。

基准测试与数据分析

出于没什么特别的原因，我一直喜欢设计实验和做测量。这在我还没考虑职业之前就是如此，直到今天依然如此。如这里所讨论的，测量是这个博客的主要主题之一，也许是主要主题。幸运的是，这个终身爱好成了我赖以谋生的职业。更幸运的是，这项技能似乎因编程智能体而变得相对更有价值³。

如上所述，测试是高度智能体化工作流中的限速因素，因为当你让智能体开始做大量事情时，任何没有被充分测试的东西都会被随机性地劣化。你用智能体交付得越多，情况就越糟。如果所有事情都像这些模型评测中的任务那样，每个任务都是通过/失败且除了不把任务搞砸之外没法做得更好，那你只要确保测试足够好，就可以让智能体放手去干直到测试通过，一切都会很好。但在实践中，对于几乎所有非人为构造的问题，都有可能做出一个通过严格正确性评测但在某种非严格正确性意义上更好或更差的解。如果你想让智能体在一个问题上放手去搞（无论是快速宽松的 vibe coding 还是运行自主智能体循环），现在你就遇到了一个基准测试问题。

当放任自流、在自我改进的循环中运行时，智能体在这方面似乎相当差。我在过去几个月里一直在做各种小动作来让情况有所改善（让大量智能体独立思考并在多次迭代中重新会商，混合加入唱反调的智能体等），但如果没有人工干预，它们在这方面仍然表现不佳。

造成这种情况的一个原因似乎是智能体真的很不擅长理解数据和做数据分析。在某种智能体循环或大问题的背景下做这件事比做独立的数据分析更难，但当人们只是让智能体做独立的数据分析时，如果没有大量指导，结果通常也糟糕透顶。因为让智能体做数据分析太容易，我已经看过不少智能体主导的分析，至少到目前为止，我看到的每一个都完全是胡扯。我自己也做了不少（我觉得人们真的低估了从 LLM 得到完全错误输出的价值；稍后会细说），也发现了同样的情况。

当我说完全胡扯时，我指的是比如找出几个其实没什么关联的数字，却硬要推断它们之间有什么深刻关系，从众多数据中挑出两个数字或两个例子然后编出一套与数据中其他数字相矛盾的理论，做出一些看起来漂亮但毫无意义的图表，等等。举个随机的具体例子，我写本文时最后一次看智能体生成的分析，有人让智能体去分析某东西的资源利用率。用的是 Opus 4.8 max（当时 Fable 被禁用，所以这是能从 Anthropic 买到的最好的东西），智能体判断某任务消耗了 514% 的资源，而按任何方式都不可能超过 100%。我有个同事有时会评论这些事，会问一些看似无害的问题，比如“X 是什么意思？”。通常他要么得不到回应，要么得到一条看似 AI 写的、和第一条一样错误的回复。

话说回来，当我在 2025 年 11 月左右开始用智能体做数据分析时，我发现提速非常惊人。有些分析，粗略地说，原本要花几周的，现在几小时就搞定了。

我犹豫要不要描述接下来这件我一直在做的事，因为已经看到太多完全胡扯的数据分析，但我大量在做的一件事，我觉得比做“常规 vibe 式数据分析”提速更大的是，跑一个简单的智能体循环，让智能体（或多个智能体）去“理解”和分析问题，然后把需要修的地方修好，以便我能从智能体产出的东西中提取出好的分析。

这个胡扯的 LLM 循环到底能提速多少取决于问题，但上一次我尝试时，我觉得一个传统的、前 LLM 时代的分析大概需要我几天时间。姑且算两天吧。在那种我多任务并行、需要时去戳一下 LLM 的工作流里，我估计需要花我一到三小时，分散在一两天内。而用这种“让 LLM 循环去产出一个我明知是错的结果”的工作流，在几天时间里只花了我大约五分钟就得到了可接受的结果。字面意义上，每次我去看之前没纠正过的分析的任何部分，分析都是错的（有些情况下我不得不多次纠正），但不知怎么的，整个过程仍然比我试图引导 LLM 要快得多。

我觉得人们真的低估了从 LLM 那里得到完全错误结果的价值。这可不是讽刺，当引导得当时，这在积极意义上是游戏规则的改变者。

关于 SOTA 模型在数据分析上有多差，以及它们在多大程度上加速了人类的数据分析，有件事有点奇怪。我有一系列关于基准测试、评测和实验设计的练习（第 1 部分、第 2 部分、第 3 部分、第 4 部分、第 5 部分、第 6 部分）。GPT-o3 发布时，Tyler Cowen 说 o3

在几乎所有方面都把人类按在地上摩擦……我不在乎你是否想称之为 AGI。而且它也不是事事都对，有些方法可以 trick 它，通常是用对人类来说很简单的问题。但别自欺欺人了。在大量话题和方法上，它把人类按在地上摩擦。是时候承认现实了。

这促使我尝试把这些练习中的问题拿去问 SOTA 模型。除非你特意把问题措辞改成模型能回答的形式，否则它们的表现通常不如我对一个靠谱初级同事的预期。如果你只是像在现实中向一个靠谱的人类同事提问那样去问，它们通常表现不佳。这不仅仅是当有人问评测作业题时出现的理论问题。任何时候你让智能体去做某种实证性的、开放式的、长周期的改进任务时，这个问题都会出现。

我在各种各样的现实问题上都见过这个问题，但即使在几乎没有现实问题那种杂乱的刻意构造问题上也会出现。我觉得一个很好的例子是构建棋盘游戏 AI。这比大多数现实问题更容易评测，因为归根结底，你想在一个胜负/平局结果明确的、定义清晰的游戏上击败人类和其他 AI。

智能体在放任自流的情况下基本搞不定这件事。对 AI 公平地说，这个问题比网上评论者说的要难一些。比如你只要去搜如何实现这些东西，就会看到各种像这样或这样的对话，没做过的人会解释为什么这很简单，而做过的人会告诉他们这比他们想的难。网上大多数教程也没什么用，以至于备受好评的 bullet 库作者建议初学者避免看“几乎任何一篇关于[某种棋盘游戏 AI 技术]的文章/博客/书籍，如果不是由作者强大的[棋盘游戏 AI]背书的”。虽然这个问题不算真的难，但似乎有足够多的坑能绊倒大多数人（以及所有公开可用的 LLM）。

当我最初尝试实现棋盘游戏 AI 时（那是 GPT-5.1 到 5.2 的时代），我对棋盘游戏 AI 一无所知，尝试让编程智能体去实现它们认为可行的方法。现在我对棋盘游戏 AI 略知一二，可以说 GPT 尝试建议的每个方向都是错的、行不通的。作为实验，我最近又试了一次，当时 GPT-5.5 和 Opus 4.8 是最好的公开可用模型，它们以完全相同的方式失败并提出了许多完全相同的馊主意（为了彻底确认，我让它们把馊主意实现出来，果然如预期失败了）。当 Fable 可用时，我也用 Fable 试了，它也以完全相同的方式失败。Fable 在实践中更好，因为它在 15-20 次纠正后能在自主循环中有效工作，而 Opus 4.8 和 GPT-5.5 则不行。顺便说一句，这又是公开基准测试无法捕捉到的一种情况。

但回到 LLM 在无指导下迭代的话题，我觉得在某种层面上，这是当今 LLM 一个相当被广泛认知的差距。碰巧在我用 GPT-5.1 或 5.2 尝试这个的时候，Code Clash 评测也创建了，它测试的也是同一件事并得到了同样的结果

无法迭代：模型难以在多轮中改进，表现出各种失败模式。

尽管智能体在设定方向上很差，而我对棋盘游戏 AI 一无所知，我还是不知怎么地用 GPT-5.1/5.2 在大约 5 小时内拼凑出了一个《璀璨宝石》(Azul) 的超人类 AI，并在大约 20 小时内把它提升到碾压性的强大水平，远超当时存在的任何其他 AI（我觉得现在依然如此）。《璀璨宝石》的世界冠军、也是总体上可能最强的玩家说：

这个机器人现在强得离谱。感觉肯定比我强，不过要真正测试它，我得像下回合制游戏那样跟它玩。在我时间有限的情况下，我毫无胜算 🙂⁴。

虽然我很想说有什么“奇技一招”，但其实有两招，不过两招也不算多，尤其当它们还能泛化到其他类型项目时。这两招是：

• 看数据 / 有一些还算靠谱的评测
• 系统性地解决问题

这些都不必很严谨。事实上，我会说这全是靠感觉（在 vibe coding 出现之前的“感觉”意义上）。在数据方面，对这个项目，我用了自己常见的习惯：画一堆看起来相关的东西，肉眼观察，然后往我希望能变好的方向推一把。更严谨（也可能更好）的做法是从头跑大量实验，做“消融”实验来增删单个想法等，搞清楚每个组件的作用和影响。但我想在尽量少花自己时间的前提下做出强 AI，只在自己笔记本上训练，而严谨地做似乎在这些约束下太贵了。

我敢肯定所有这些对有 ML 经验的人来说都是小菜一碟，但有大量小事需要我去观察然后想办法处理（这正是智能体目前极不擅长的事）。比如在搞清楚该看哪些评测来评估时，就有几件有意思的事。一是你可以轻易做出降低损失但不改变对实际对手（人类或其他机器人）胜率的改动，反之亦然。另一是，如果你尝试用你的机器人对战自己之前版本来跟踪提升，很容易做出一系列改动，让机器人击败自己所有先前版本，产生 1000 甚至 2000 分的 Elo 虚假提升，但对人类或走法不同风格的机器人却毫无提升。而且当时还没有可对战的超人类机器人，所以光靠和现有机器人群对战也得不到合理的评测。

对人类来说，这些都不是什么难题。一个靠谱的人类可以看看其中一个问题，想几分钟，就能提出一个可能有效的解决方案（当它不奏效时，他们可以再试另一个）。但其中有足够的微妙之处，以至于智能体今天在没有监督的情况下做不好（对编程智能体公平地说，很多或大多数人类也不行——我找到的几乎所有对战机器人都很差，尽管人们似乎在其中不少上花了不少时间，唯一公开可用的例外是 https://github.com/cestpasphoto/alpha-zero-general 中的“PJF98” Azul 机器人）。曾有一个比 PJF98 更强的机器人存在，但它没有公开发布对战，只被用来在 BGA 上赢了一个赛季（该赛季因使用机器人作弊被作废）然后就再也没出现过。

我提到的另一个技巧是采取系统化的方法。从高层次看，这是因为当处理一个带有一定复杂度的不透明系统时，每当你看到一个 bug 的症状，很有可能这是通向一个或多个你不知道如何观察的其他 bug 的窗口。如果你不系统地关上窗口而不修复其他 bug，那些其他 bug 依然存在；只是你不知道如何再找到它们了。

在构建使用神经网络的棋盘游戏 AI 时就是如此，因为你有一个不知道在干什么的网络和一个不知道在干什么的搜索函数，有时你能发现一些明显很烂的走法。这在使用 vibe coding 和/或智能体循环时也普遍成立，因为你有一堆不知道在干什么的智能体，而当智能体产生的巨大、过度复杂的代码堆发出某种明显很烂的行为时，你有时能窥见哪里出了问题。

具体到棋盘游戏，我看了现有的其他 Azul AI。很多人都做过机器人，尤其最近有了编程智能体，做个机器人变得如此容易。对其中一些，你甚至能看到作者是如何尝试微调机器人的（比如因为他们在仓库里留下了给 Claude 的指令），据我所知，这些其他机器人之所以差很多，尽管投入的人力时间更多，主要原因是使用了错误的评测以及只修复了问题的表象而非根因。

例如在一个作者把 Claude 指令留在仓库里的案例中，有段时间他们的机器人会走出一步非常糟糕的棋，差到即使刚学会游戏的人类都不会这么走。作者指示 Claude 做了一系列直接的修复来阻止机器人走那一步，确实奏效了，但这并没有修复导致机器人产生其他糟糕走法的系统性问题；只是修复了作者能看到的那一个非常明显的糟糕走法症状。

我的机器人也遇到过一个有点类似的问题，有段时间我的机器人几乎总是想在第 2 列开局。一个简单的修复，我觉得会奏效的，是调整机器人让它少走第 2 列。我试过各种“显而易见”的修复，比如增加噪声以增加自我对弈中的探索等，但除了直接降低第 2 列的价值外，没有一个显而易见的修复奏效，但那又有我们讨论过的并未真正解决问题的毛病。在那个具体案例中，一个更系统化且奏效、让机器人的下法整体更稳健的修复是，在游戏的各个时点把游戏分叉成一个列置换后的新游戏。这里的思路是，问题在于平均而言第 2 列是最好的列，所以即使机器人尝试在别的列开局，由于过去见过的对局，它仍会倾向于回到平均最好的列。如果你是 DeepMind，你可以砸钱让机器人多下很多盘棋然后学到别的东西。但如果你只在笔记本上跑，那可能要很久，而且如果你想调整让机器人偏离第 2 列的权重，也没法得到一组合理最优的权重。但如果你（比如）有时在接近终局时把第 2 列置换到第 4 列，机器人就会学到如果第 4 列快填满了，去完成它就是赢棋，这会帮助机器人在更早阶段学到，如果第 4 列部分完成，把它推进到接近完成是有意义的，依此类推，直到开局时机器人才会在开局时以合理的分布开局。

对我这种没有 ML/AI 背景的人来说，让机器人达到超人类表现就是一系列像这样的谜题，组合了搞清楚该用什么数据视角来发现问题，然后系统性地调整以解决问题。这和为一般性问题管理智能体循环没什么不同。Michael Malis 说过跑“软件工厂”工作流感觉像在玩《异星工厂》(Factorio)，我能理解他的意思。

杂项

我不确定谈具体的工作流技巧有多大价值，因为这些技巧的半衰期太短了。在我还没跑更自主的循环、更多做人机协同工作时，“我的”智能体经常会做出与 AGENTS.md 或其他指令直接矛盾的事。当我随口向 Yossi Kreinin 提到这事时，他建议在 AGENTS.md 底部加一条注释，让它在压缩后重读指令。据我所知，那可能只是迷信，根本没起作用，但它似乎把这类问题的发生率从每天几次（同时 juggling 几个智能体，所以大概每几个智能体-天一次）降到一两周一次（大概每 100 个智能体-天一次）。现在这似乎不再必要了，所以要么这本来就是从未起作用的安慰剂，我只是有段时间运气不好，要么就是 AI 实验室也加上了类似的东西。一个在 2024 年 8 月讨论过的技巧，那时 LLM 默认只会生成代码而不会运行，是让一个循环不断编译代码、运行测试并重新提示直到全部通过。那个技巧考虑到它有多明显和有用，竟然有惊人长的有效期，当然大 AI 实验室最终也意识到它有多有用，现在它们都有做这件事的工具了。

过去几个月我一直在用的“技巧”是有点类似于 Gas Town 的东西，但加上各种小改动来让它更可靠。看起来 Claude 的 Dynamic Workflows 把其中一半技巧打包成了一个易用的套件（我还没用过，因为听说它用的是瀑布模型，一个阶段要等前一阶段完成，但要么这迟早会被修复，要么会有人发布一个没有这个限制的东西），而 Codex 有一些已公布但尚未发布的功能，似乎也是冲着做同样的事去的。原则上，goal mode 应该能打包另外一半技巧，尽管目前效果还差得远（除了有时因 bug 而失败，它在追求目标方面似乎不如手写循环，而且还可能严重跑偏；Dennis Snell 提到让一个他以为是小任务的东西在 goal mode 下跑，结果发现按 Codex 的说法，要不是他的雇主有无限 token 套餐，那几天的花费会是 6000 万美元的 token；再问一次，它又说是 20 万美元）。想必这些东西会改进，而我现在做的大部分事情会在几个月内变成开箱即用？就像上面提到的技巧一样，这些都是足够明显以至于我不觉得花很多时间讨论细节有多大价值，但如果有人好奇，我会在后面的附录里放一些简要说明。

上面讨论的元技巧在我做过的各种项目上泛化得相当好，只要智能体还不能仅凭一个非平凡的问题描述就比我更好地完全解决问题，它们似乎就应该能持续有效，到那时我也不用担心了，因为我的经济价值可能已接近于零。

另一个有用的元想法是非常明显的想法，即编程智能体相对于人类的有效性是高度不均匀的。在讨论传统生产力时，Fabian Giesen 对速度提升如何改变他工作方式有过这样的评论：

当你跨过某些阈值时，会出现“相变”（细节在一定程度上取决于问题），你的整个工作方式都会改变。…… 有很多事理论上我以任何速度都能做，但实践中做不到，因为随着迭代时间增加，一开始它变得如此令人沮丧以至于我无法长时间坚持，最终它耗时太长以至于 literally 从我的短期记忆中掉出去，所以我需要做笔记或以其他方式组织，否则根本做不到。当然，如果我能在交互式 UI 里通过拖动滑块并在几分之一秒内看到结果，那时就是非常“无过滤”的，想试什么就试什么。一旦到了以秒为单位的迭代时间（比如静态编译语言的编译-链接周期），你就不会随便试东西了，你还会花时间思考它是否会告诉你什么，因为一次运行耗时长到你不想浪费。一旦进入几分钟或几小时的迭代时间，就会有大量规划以免浪费运行，还会因为等待时做别的事而导致上下文切换，以及记笔记/簿记；同样在这种水平下，错误既更昂贵（因为一次浪费的运行浪费更多时间）也更常见（因为注意力如此分散）。当你进一步扩大规模，你可能现在需要为可观的时间占用大量资源并需要获得批准和预算，这又需要开会等等。关于智能体编程速度提升也有类似情况。人们有时会宣称智能体编程有100 倍或 1000 倍的生产力提升。当我看自己做的任务时，很难真正确定一个数字，因为你无法有效地把人的工作流原样搬到智能体上，所以我做的事和我原本会做的事非常不同。比如，我们看看上面讨论过的让智能体查看每个客服工单并把客服问题转化为 PR 的想法。如果我要宣称某种加速比，那会是一个巨大的数字，轻易超过 1000000 倍。但我当然不会自己去读每个客服工单，所以这种说法毫无意义。更合理的估计方式是去估算用传统组织结构、传统技术产生那么多 bug 修复需要什么样的组织，然后估算比率，但那种估计的误差条会超过一个数量级，而且那也不是任何正常软件公司会去做的事，所以比较再次毫无意义。这就像一个每年开 20000 英里的人说他通过开车节省了 6000 小时，在通勤上获得了 15 倍加速，因为那是走同样距离所需的时间。显然，开车让他们能够做否则无法做到的事，但讨论这个比率毫无意义。

另一个可以宣称巨大加速比、可能超过 1000000 倍但同样毫无意义的例子是，当尝试以半自动方式让 LLM 生成模糊器时，我曾让 LLM 查看整个提交历史和所有 bug 修复，以及历史上每一个可能相关的客服工单，来尝试让 LLM 编写的模糊器能够以某种通用方式复现 bug。这样做似乎有用，但很难给出一个实在的价值数字。

对我而言，LLM 的有效价值在于有很多以前因为太耗时而没法合理去做的任务，现在可以相当轻松地完成。在脚注中我提到现在可以轻易构建很多应用，所以我有时会在一个定制应用上玩在线棋盘游戏，那体验比我在任何大型棋盘游戏平台上能得到的都要好（也比典型的棋盘游戏专用应用要好）。

在那些主要为满足好奇心、但也可能与业务相关的事上，我也会做一些以前觉得不值得花时间的数据分析。比如，我一直好奇用户实际遇到的 bug 与客服工单之间的比例。有了编程智能体，我只花了几分钟就让智能体生成了一份重大事件清单，其中我们知道每个尝试访问网站或使用某功能的用户都无法使用该网站或功能，以及一份看似与每个事件相关的工单清单。把这些数据关联起来后，典型的比例是每张工单对应 200 个受影响用户，比例通常在 100:1 到 1000:1 之间（而且我确信如果纳入更多事件，会发现更宽的范围）。顺便说一句，我预先猜测的比例是 100:1 到 1000:1，更偏向 1000:1，所以我在这里有点猜偏了，因为典型的 200:1 更接近 100:1 而非 1000:1。

当然，这个分析有很多漏洞。无法确定是否没有遗漏工单（我确实通过与 bug 跟踪器中人工标记为与事件相关的工单独立交叉检查来检查误报，主要发现是智能体能找到比人类多得多的工单，但这并不意味着没有同时躲过人类和智能体的漏报）。我还随机抽样了几张工单来看关联的工单是否合理，它们看起来合理，但这只是一个快速的数量级分析，所以我并没有像做高精度分析那样手动检查足够多的工单来做真正的验证。

也不清楚这个比例在较轻微问题上如何变化。一般来说，对于较轻微的问题，比例应该更高，对于投入度较低的用户（比如注册流程中的典型用户）也是如此。我猜对于许多较轻微的问题，我们通常会看到远高于 1000:1 的比例，对许多微妙问题，比例很容易超过 10000:1 甚至 100000:1。

这个分析并不能让我说出什么太精确的东西，但它确实可以用来回应有人说“只有六个用户受影响”因为某个问题只有六张工单的情况。那通常意味着内部 bug 跟踪器里有一张工单附了六张客服工单。用智能体去搜索相关工单，你可能会找到二十五张，然后看看问题严重程度，你可能会估算出 10000:1 的比例，那么“只有六个用户受影响”就可能变成“压倒性可能至少有 5000 个用户受影响，很可能有 25000 个用户受影响”。

如果我已经熟悉这个分析需要查询的所有系统，我估计要得到一个粗略猜测也得花上数小时，而且会是更粗糙的猜测。但鉴于我并不熟悉，我估计那会花上几天。而现在，这只花了我大约 15 分钟。就像 Fabian 提到的，这种原本需要数小时或数天的应用或分析现在可以完成的加速，是一种真正改变你工作方式的相变，这还没算上那些只需偶尔维护的自主循环。

另一个想法，而且事先对我来说并不明显的是，LLM 似乎对在某件事上越专业的人，生产力倍增效应越大。找了一圈相关评论，我当然看到满屏 LLM 生成的 SEO 垃圾，筛过之后，我看到不少评论说恰恰相反。基本上是说现在人人都能做任何事。虽然这比以前更正确，但更正确的是在某个领域的专业知识变得更有价值。Max Bittker 有个评论说这至少部分是因为 LLM 擅长伪造东西，但伪造品还没那么好（至少目前），而专家能分辨出伪造品和真品的区别，我觉得这个视角很有意思。

再接着这篇 2015 年关于有多少人低估 AI 将在多大程度上取代人类的帖子说，过去一年里，我通过 LLM 驱动的远程客服获得的体验，中位数已经好于我通过人类远程客服获得的中位数（一个薪酬优厚的人类会提供比我所有 LLM 驱动体验中除 maybe 一次之外的更好体验，但公司并不想雇薪酬优厚的人类）。2015 年那篇帖子中被反驳的完全相同的论调在 ChatGPT 发布的 2022 年又被重复了一遍。这个论调太受欢迎了，以至于自 2022 年以来每年都会作为思想领袖的爆款反复出现，我看短期内也不会改变，但它今天在我看来依然是错的。

顺便说一句，如我们之前讨论过的，成为高效程序员有很多种方式，所以我不是说这里讨论的是最好的方式甚至是很好的方式（我随着不断摸索新东西，工作流也在定期变化），但这就是我一直在尝试的、对我而言似乎比纯传统工作流更有效的方式。就我的背景和兴趣而言，采用系统化、以评测驱动的方式来做智能体编程是很自然的。我也见过有人用几乎完全相反的方式也能奏效，他们飞快地推进，几乎不去理解发生了什么，而当他们撞大运时，就递归地把所有精力都投入进去。那不仅不太适合我的背景，我觉得对我所做的大多数问题也不会很有效，而我选择这些问题正是因为它们似乎适合我解决问题的方式。毫无疑问，把我的工作流搬到适合相反工作流的问题上，也不会很有效。

附录：各说各话

人们在意见不合时各说各话一直如此，但今天在聊智能体编程时，这个问题似乎比许多其他话题都更严重。

我看到的一些主要原因包括：

• 普遍的不信
• 基于工作流的可靠性差异
• 一般性的工作流问题，即“技术不行”
• 预期的差异

说到普遍的不信，比起我人生中任何其他时刻，我现在看到更多人说 X 不可能、没人做 X、任何声称自己在做 X 的人都是骗子，而我却认识在做 X 的人（我信任且他们可信）或我自己就在做 X。外界对 AI 的不信有很多。十一年前，我们就看到人们在说 AI 不可能取代或替代人类，尽管这种事已经在发生，但那里的替代对典型的中产或程序员来说还不是切肤之痛，所以对我在“街上”可能遇到的人来说不像今天这么显眼。如今这事更“怼脸”了，不愿正视现实的人也激增了。

顺便说一句，我觉得很多人持怀疑态度是完全合理的。一方面，很多关于 AI 的正面说法是错的。平均而言，离谱、错误的说法比 boring 精确正确的说法更容易获得传播，所以一个不关注此事的人会看到大量容易被驳倒的错误说法。更糟的是，很多做出这些说法的人在 AI 公司的整体成功上有直接经济利益，这让怀疑者很容易得出结论：这些人都是出于私利的骗子。

关于基于工作流的可靠性差异，我的意思是不同工作流对可靠性的要求不同，而使用要求更高可靠性的工作流的人，往往会因为 AI 达不到 X 可靠性就宣称 AI 无用，却忽略了有许多有效用例并不需要那种可靠性。举个极端的例子，有些人已经用 AI 做了新颖的数学研究、解决了开放问题。假设 AI 每尝试 100 次就有 1 次解决了你正在研究的某个开放问题，另外 99 次返回完全胡言乱语。这似乎很棒。每 100 次解决一个严肃的开放数学问题是非常了不起的结果，即使每 100 次才做出一次靠谱代码复审、另外 99 次都是糟糕复审会是糟糕的结果。

举个不那么极端的编程工作例子，如果你不假设智能体 100% 可靠并构建系统来处理这种情况，你可以容忍比那些假设智能体可靠、需要某种人机协同纠正来处理智能体不可靠情况的人低得多的可靠性。我经常看到有人给出建议说，“别用 AI 做 X [因为它不会 100% 奏效]”，而我认识有人一直在做 X 并有一套 boring 的系统来处理 X 不 100% 可靠的情况。这是编程中无论是否与智能体打交道都常见的事，那为什么不用同样的技术来处理智能体不可靠呢？

规模差异也会导致各说各话，因为人们在不同规模下对可靠性的要求非常不同。有句老话说，对于传统软件系统，规模每扩大一个数量级，就需要不同的架构。这话不完全对，但它方向上正确地指出了在不同规模下你确实想要不同架构。这对使用智能体也成立。

举个例子，前面提到过的那个关于在我做的任务中，在 AGENTS.md 中加入一条清晰、严格的“不要做某事”指令，每 juggling 10 个智能体时大约一两周失败一次，失败率大约是每 100 个规则-智能体-天一次。这算有效吗？如果你做的是人机协同编程，智能体和规则数量相对较少（比如 10 个智能体、10 条规则），且失败是非灾难性的、通常能被人工复审捕获，这就没问题。如果你运行数百或数千个智能体，或者即使只有几个智能体但不经复审或其他护栏就直接发布，且失败可能导致严重问题，这就完全不行。虽然有些技术是规模不变的，但很多不是。

另一种工作流问题是，人们有一种对 X 行不通的工作流，然后就得出结论说没人能做 X，因为他们自己没能做到 X。我还没太深想具体哪些做法行不通，但 Max Bittker 有如下评论：

我注意到的一些模式，不分先后：

1）人们有时环境配置错误：他们用的是旧模型，开了一堆 MCP 或第三方 system prompt，或者 LLM 在试图应对 Windows 或某种不寻常的环境或 IDE。

2）人们有时通过使用单个超长对话、大量回溯或单个超乱的工作目录，把上下文窗口搞得一团糟。

3）通过不精确的措辞注入意外需求，把 LLM 引向比他们本意更难的任务，比如在游戏核心完成前就去构建匹配系统

4）如果你对自己想要什么或何时算完成没有清晰想法，你可能会描述不足，然后在协作过程中不断漂移、改变需求，漫无目的地打转（许多 AI 幻觉式 vibe coder 就是这样）

附录：智能体循环与本文写作

如本文开头 alt 文本所述，我多年来一直很犹豫要不要写 AI，因为我在加拉帕戈斯岛上，与外界高度隔绝，因为我不太看社交媒体，也没怎么和那些真正在旧金山风口浪尖上的人保持联系。

我是在 5 月和几位来参加 PGConf、正好在城里的旧金山朋友聊过后，才确信写点东西或许有意义。尽管他们身处风口浪尖，似乎紧跟人们用智能体做事的最前沿，我工作流中的一些东西他们仍觉得有意思。但是，就像我说的，特定工作流技巧的半衰期很短，我觉得详细记录某个确切工作流没什么用，所以正文更聚焦于更高层次的想法。我不确定什么才真正有用，但我想试着写写我工作流的演变。如上所述，我不觉得在任何时间点我的工作流是顶级的，但它是有用的，而且似乎总有自然的下一步能让它更高效一点。

回到石器时代，在 Claude 和 Codex 这类工具出现之前，我有时只会跑一个非常简单的循环，不断编译代码、运行测试并重新提示直到全部通过，我在 2024 年年中在这里提到过。当时，我觉得这对我懂行的事来说不够有用，但它让我能在那篇帖子里嵌入一个小网页游戏，并完成其他一些需要我在某些领域学点东西的任务，而在那些领域拥有真正专业知识对我来说可能永远不会特别有意思，比如构建一个网页应用。

那种做法在有段时间里对我想完成的简单任务来说还有点用，但直到遇到本文开头的二分查找/视频故事，以及做了一些其他数据分析并看到它能在多大程度上加速数据分析，我才开始大量使用智能体。顺便说一句，二分查找/视频故事源于一个我在分析某个功能和/或 bug 修复能正常工作多久的半衰期时会用到的分析。碰巧那个分析与本文中的几个想法相关联。首先，半衰期在 LLM 出现之前就相当短，这似乎是支持多做测试的一个论据，如果我们想把速度调快的话（无论是否用 LLM）。其次，这又是另一个如果没有 LLM、耗时太长以至于我根本不会去做的分析。

在 2025 年年中晚些时候的某个时候，我尝试用 vibe coding 做一些个人项目。我用 Codex 只是因为有人说订阅计划里它给的额度更多（后来我两个都试过，似乎确实如此）。那时我的目标是在得到想要输出的同时尽量少花自己的时间，但我之前基本没做过 vibe coding，也不知道什么会奏效，但很快就发现我所做的最天真可能的循环——就是把“如果 X 没完成，就实现 X 直到完成；如果 X 已完成，就……”排上一大堆副本——其实并不那么笨。我当时没看别人是怎么做的，和我私下交流的人一般也不怎么用 AI，所以我完全不知道“Ralph 循环”这个词在 2025 年年中就已被造出来，人们在做各种不那么笨重的变体，尽管这其实也不算太笨重（一旦写好提示词，排队也就花个 5 秒左右）。

而且回过头看，这个工作流在引导方向方面相比 Ralph 循环也不算差。我通常每天会看几次（睡前、醒来、可能还有其他几次），一般来说每次看时，情况都有点不对劲，我就会在查看解释情况的日志/指标/图表等之后，排一些指令来把事情推向正确方向。由于这是我每天只花几分钟的个人项目，我并不是在追求最大吞吐，只是在手头两台闲置笔记本上各跑几件事。如果有能无限期持续、无需手工补充队列的更自主循环会更好，但实际节省的时间其实没那么多，我觉得每天不到 10 分钟。

这样做了一段时间后，今年早些时候我开始（有时）尝试运行更自主的循环。同样，我觉得这一定程度上落后于任何时候人们热衷的东西，但似乎效果还行。开始这么做后，我发现很多人推荐的工具其实不太适合管理智能体循环，而那些为此设计的工具似乎有点“味儿很重”(vibe-y)且会有可靠性问题。

前者一个例子是当时被广泛推荐的 Conductor，它并不是为支持很多我想做的事而设计的。比如 Conductor 有工作区的概念来隔离事物。我经常想要调用可称为“高阶工作区”的东西，让一个智能体（或一组独立智能体）决定该对一个清单做些什么，之后每项都应被喂给另一个智能体（或独立智能体组）（可能限制智能体并发数），之后等等，用某种图结构来决定任务如何流转，其中还有类似 reduce 的步骤来查看一批任务的输出，等等。虽然技术上可以让 Conductor 做到这些，但它并非为此设计，鉴于你可以直接让智能体写脚本来创建这样的结构，直接用定制化的 vibe 式脚本似乎简单得多。

那些为大量智能体设计的工具，比如 Gas Town，大多似乎面向不那么结构化的工作流，而且它们往往高度 vibe 化、因此有点不可靠，以至于我不确定为什么要用它们而不是自己拼凑一个。我的意思是，按关于棋盘游戏的长脚注中的讨论，如果某个东西达不到一定的质量和复杂度门槛，自己做一个版本是相当容易的。即使你自己做的东西比产品更 buggy，你也可以确保在你的工作流中，它没有会影响你特定工作流的 bug，所以你甚至不需要达到和产品相同的整体质量门槛，它对你来说就已经更好了。

结果，我现在的做法是为需要运行一段时间的任务制作一次性循环。构建一个符合我需求的编排器可能会有一定效率提升，但我觉得我还没搭建足够多的这类循环来搞清楚自己到底想要什么，而且想要的东西因问题而异很大。有时我想让某些指标触发一次由能修复问题的智能体执行的健康检查，有时我想让智能体或智能体组在每次迭代（无论那意味着什么）后自动被调用来检查进展，有时我想让智能体持续检查进展。有时我想要一个带某种多级分流的图结构，等等。

因为让智能体搭建你想要的任意结构相当容易，我通常会从某种带基本健康检查和监控的简单结构开始，然后定期去查看并尝试做结构性修复来解决问题，使问题不再复发。原则上，这样一个设置良好的东西可以无限期地产生有用工作，但至少对我搭建的这些循环来说，它们会随时间推移在生产力上退化。即使没有严重问题，如果我积极地坐在键盘前输入指令来以各种方式推动事情，同时监控进展，循环的生产力会高得多。如果我让其中一个循环单独跑几天或一周，它通常仍会产生非零的有用工作，但远不如我每天查看时那么多。我尝试过各种策略来让这些循环在无需干预的情况下更保持正轨，也发现了一些有帮助的方法，但还没找到如何取代我自己（至少目前还没有）。

例如，在 2026 年 4/5 月，我尝试让一堆“人格”聚在一起反复会商来代替我自己推动循环。当时，我正试图让一个在处理使用 CRDT 代码的循环平稳运行（顺便说一句，我对 CRDT 一无所知），所以我尝试用类似“让独立智能体分别以 Linus Torvalds、Kyle Kingsbury、Marc Brooker、tptacek、Dan Luu 和 4 个唱反调人格的视角来复审。让每个都长时间思考”来诊断问题，并进行多轮迭代（是的，我觉得搬出自己的名字挺傻的）。这些人格似乎各自以不同方式让事情保持正轨，例如“linus torvalds”人格会倾向于抵制循环因反复添加不必要复杂性而自然失控的倾向，“dan luu”人格会迫使循环在实现前先做测量，有时还会说“我们绝不能为 XYZ 做合理化”并抵制一些糟糕的推理。所有这些都不足以取代人类的观察和干预，但做这类变体足以让这些循环运行得更平稳，需要的干预更少。

这种人格设置对架构设计、调试等也有改善。同样，还没到完全不需要人的程度，但足以让人类少做一点工作。

所有这些似乎在人类理解常见失败模式时效果最好。例如，当被要求调试并解释某个 bug 是何时引入的时，如果只是提示去解释，即使经过多轮独立分析，智能体也经常会给出完全错误的解释（大概 50% 的时间）。当被要求通过实际执行代码来验证假设是否正确时，大多数错误解释就被消除了。仅仅给简单提示加上强制检查，成功率就比让智能体做独立分析并交叉检查更高（两者一起做似乎成功率更高）。

从智能体中获得价值的很多部分似乎在于理解其失败模式然后加以规避。前面我们提到，人们不会因为现在不用编程智能体、过 M 个月才开始就被落下，因为他们最多落后 M 个月，但很可能会落后得远少于此，因为变化太快。据我观察，一个重要原因是，使用智能体的很多技能在于规避其失败。而 AI 实验室当然想修复这些失败，这意味着新版本被设计为尽可能让这些技能过时。这可以直接观察到，一些一年前很常见的失败模式现在已经少见得多。

顺便说一句，这也是我个人觉得很多基准测试没什么用的另一个原因。一般来说，基准测试已转向尽量“不过度解释”，而是表现得像一个不太会用智能体的天真用户。这对 AI 实验室来说是合理的，因为它们想做出一个需要尽可能少专业知识就能操作的产品，但作为专业程序员，如果有办法绕过智能体的某种失败模式，你大概会去用它而不是表现得像个基准测试，于是即使你在做基准测试中的完全相同任务，得到的结果也非常不同。

感谢 Max Bittker、Dennis Snell、Em Chu、Yossi Kreinin、Peter Geoghegan、Michael Malis、@[email protected]、Misha Yaugdin 和 Jason Seibel 的评论/纠正/讨论。

1. 到处都能听到的反对设专职测试工程师的论调，大致是“最能测试代码的人就是写代码的人；而且如果把测试外包给别人，程序员就会在测试上偷懒”，但这只是一个有两面性的权衡中的一面。

   一般来说，专业化会带来效率提升，因为人们在专业领域发展出更深的技能，也会带来效率损失，因为技能分割会导致各种碎片化问题。把针对专职测试人员的同样论调套用到设专职前端和后端、移动工程师等身上，也都成立。但另一面也有成立的论点，人们普遍承认，一旦达到一定规模，拥有理解特定领域的专家所带来的收益，会超过拥有一群在每件事上都只有点水平的通才团队的好处。从见识过人们如果花一二十年专攻测试技能能达到多高的水平来看，我觉得软件公司错过了拥有这些技能的人才，但这可以说超出了本文范围，因为你不可能马上就去雇一堆在软件方面具备这种技能的人。要让这样的人群存在，你需要像硬件公司那样的文化和职级体系，让验证工程师成为与逻辑设计师平起平坐的一等公民，在同一薪酬体系、同样比例晋升到高级别、享有同样声望等等，然后你还得坚持二十年。

   这里的收益不仅仅是花整个职业生涯做一件事所获得的直接专业知识。在公司内存在大型实践社群也意味着人们在公司内成长更快。就像我很幸运因为恰好坐在一位分布式追踪专家旁边而学到很多分布式追踪知识，可能几个月学到的就相当于自己摸索几年一样，我也很幸运因为坐在一个世界级测试工程师集群中而学到很多测试知识。即使在那些规模是那家硬件公司一千多倍的软件公司，我也不确定他们是否有那么多花了 40 多年专攻测试的人才集群让我去学习（即使有，那个群体离我也太远，我根本接触不到）。

   [返回]

2. 有一次作为实验，我们对代码做了一次复审，一群人坐下来看了所有代码。这确实发现了非零数量的 bug，但据我记忆，只有个位数的 bug。你可能会说，我刚才说的关于测试技能的话反过来对一个默认不做代码复审的团队也成立，如果人们有更好的代码复审技能，就会发现更多 bug。毫无疑问这是真的，但即使如此，如果我想想我认识的最擅长在代码复审中发现 bug 的人，再想象一个比他们更厉害的人，那在单位时间内发现 bug 的有效性上，仍然远不及 Centaur 测试工程师的中位数水平。

   [返回]

3. 而且，碰巧和测试一样，这也是一项在 CPU 公司比在典型软件公司中发展得多的技能，即使是那些做高性能敏感产品如数据库的公司。上面我们估计在芯片设计公司花在测试上的精力大约是传统软件公司的约 2:1。而说到基准测试/评测/实验设计，传统软件公司分母太低，以至于很难估计比例，但肯定至少是 10:1，100:1 和 1000:1 也是合理的数字。

   当然，通过在这些领域比软件公司投入和培养多得多的专业知识，芯片公司在许多其他领域往往相对还处于石器时代。相对而言，我在大多数那些领域也比较弱。我觉得在公司环境中这没什么问题，有互补技能的人很有价值，但在面试中肯定会带来一些麻烦。

   [返回]

4. 顺便说一句，我很好奇在线棋盘游戏会怎样（除了本脚注末尾，这整个脚注都是关于棋盘游戏的，如果你对棋盘游戏没兴趣可以直接跳到底部）。一个问题是对作弊的“需求”很高，即使在 LLM 出现之前，竞技性在线对局中就有相当多的作弊。如今，做一个能作弊的机器人并不难，而且只会越来越容易。我个人不太喜欢和随机陌生人在线对战，所以一般不玩排名/竞技性在线棋盘游戏，但不少人会。很难想象如果作弊增多，这种模式还能维持。

   我好奇的另一件事是大游戏平台的价值。Board Game Arena（BGA）似乎是目前遥遥领先的最大平台，Tabletop Simulator（TTS）排第二。BGA 是，呃，你如果客气点可以说它相当古怪。比如平台默认并不真正允许玩家并发操作。如果你在另一名玩家点击的同时点击任何东西，只要你的点击稍微早一点到达服务器，就会阻止对方执行操作。对于有同时行动或选择的游戏，这会导致人们的回合被卡住几十秒，因为其他玩家在执行操作。我可以就 BGA 的各种问题写一篇和整篇文章一样长的帖子，但可以说，你对一个如果玩家尝试并发操作就根本无法正常工作的多人在线平台所能预期的其他问题，在这个平台上都是问题。平均而言，TTS 用起来甚至更笨重。

   因此，为那些不需要复杂界面的游戏实现一个更 nice 的用户体验是相当容易的。游戏规则和机制不受美国版权法保护，所以只要你不使用其图形、注册商标等，实现一个规则完全相同的游戏似乎完全合法。我个人并不想尝试去构建一个用未授权游戏与 BGA 竞争的平台，但我确实有时想玩一个没有 BGA 那些怪癖的游戏（或 BGA 上没有的游戏）。取决于游戏，我只花了从几秒到几小时不等的个人时间就让一个看起来合理的规则版本跑起来了。几秒就能搞定的是那些对简单提示就基本能直接跑起来的简单游戏（比如这个规则与《Scout》相同的游戏，我实现它是因为我的朋友们找不到在线玩 Scout 的方式。顺便说一句，我不保证你去试时游戏一定能跑——它托管在某种简陋的免费层上，因为如我所说，我并不想构建什么大平台，只要在我和朋友用时比 BGA 好用就行，这是我追求的（很低）质量门槛，即我们玩时不遇到 bug，而不是它是一个普遍健壮的实现。尽管我的游戏实现的运行时性能与技术上可能达到的水平相比很差，但习惯了 BGA 的朋友都评论说感觉是瞬时的，因为他们习惯了 BGA 慢得多的性能。当人们习惯的平台既极慢又极 buggy 时，随手 vibe 出一个更好的东西是很容易的。

   有些游戏会花更长时间，因为当前模型无法一次性搞定。就我个人时间而言，《亚特兰蒂斯卫士》(Guards of Atlantis) 可能是我尝试实现的最耗时的游戏。它有很多规则，因为每张卡都有自定义规则，而且规则对人类来说似乎异常难以理解，这也让它们对 LLM 不太友好。相对而言，我观察到人们意外玩错规则的比例远高于大多数游戏，而且我不确定是否见过有人能完全玩对，除非他们在官方 discord 上并关注规则讨论，或是由那样的人教的。鉴于此，期待 LLM 一次性搞定游戏是不现实的。

   话说回来，鉴于只需花一个人几秒到几小时就能以比主导性在线棋盘游戏平台更 nice 的形式实现一个棋盘游戏，我很好奇主导性棋盘游戏平台会怎样？人们会因为网络效应而留下来吗？我认识的少数在线玩棋盘游戏的人中，有相当一部分觉得网络效应并不重要。比如看看前述世界排名第一的 Azul 玩家的这些话：

   最近用[你的机器人]玩游戏时我玩得很开心。这个机器人能找到非常酷/有创意的走法，是我永远不会考虑的，这帮助我对每回合的处理方式更 open-minded

   ...

   和这些机器人对战会很有趣（我已经几个月没在 BGA 上玩 Azul 了），如果它们实力相当的话

   看到世界最强玩家连续几个月和机器人对战而不是在 BGA 上玩，我觉得有意思但并不意外。今天大在线平台的一个问题是，要匹配到实力相当的对手其实相当难。玩家越强，这个问题越严重。就像我上面说的，我不太喜欢和随机陌生人对战，所以不怎么玩，但在 BGA 上玩竞技排名游戏的人几乎普遍抱怨天梯太肝。如果你是强的竞技玩家，几乎所有匹配到的对手 Elo 都低得多，所以你在这些无聊的对局中碾压对手，每局只涨一点点 Elo。而一旦你失误一次，就会因为单次失败掉大量 Elo。有一段时间我病得没法做太多事，就在 BGA 上试了某个游戏的竞技排名爬到了世界第 4。在整个爬到第 4 的过程中，我只和世界前 10 的人打了两局。其他每一局都是和明显更弱对手的相当无聊的对局。对于竞技玩家来说，有作弊泛滥的迫在眉睫问题，以及竞技排名对局大多无聊透顶的现有问题。

   对于非竞技性对局，BGA 的问题少一些，但我碰巧在写这个脚注时正在教某人玩一个游戏就在他们思考走法时写这个脚注，他们就在我写这个脚注时遇到了三个不同的 bug。而且除非你玩的是最热门的游戏，否则往往要等很久才能开一局（即使是最热门的游戏，在非高峰时段也要等）。我不太明白人们除了惯性之外为什么还要在这些平台上玩。也许惯性本身就足够让这些平台继续成为人们玩游戏的地方，但对我这种在线时大多只和本地朋友玩的人来说，完全没有理由不去用某个在午休时 vibe 出来的、bug 更少、性能更好的应用。

   同样的道理似乎应该适用于很多其他类型的应用。例如，这里是 Josh Bleecher Snyder 在购物时随手写了一个购物清单应用的事。理论上，如果软件能正常工作，你会想用某家公司制作的高度打磨、经过充分测试的版本，但软件大多不能正常工作，而且有很多应用是相当容易就能做出比今天大多数人用的更好的版本的。当然，仍有许多情况这不现实，但我依然惊讶于有多少我会定期使用的软件可以相当容易地以更 nice 的方式重做。

   [返回]