AI编码代理笔记
去年年底起，我开始高频使用AI，这段经历颇为荒诞：AI干的某些事，要是换成人做，早被当场开除了。可我的反应却是："这太棒了！"然后立刻部署上千个AI智能体，让它们把这类事干得更多。
去年年中，我让GPT（大概是5.0或5.1版本）帮忙定位一个bug。那段代码没写测试，git bisect也派不上用场——这是个UI交互bug，我自己都没信心写出对应的测试用例，于是就让Codex在X和Y两个日期之间做二分查找，找出引入bug的那次提交。Codex立刻告诉我问题提交在日期范围之外（这显然不可能）。我指出错误后，它又报了一两个明显不对的提交。等我再次纠正，它终于给出了一个看起来合理的提交记录。我让它验证这个结论，它说自己写了测试，确认这个提交就是罪魁祸首。
接着我让它在常规浏览器测试环境里，用完整的开发端到端栈录个演示视频。它声称没有权限这么做（这是谎话），但可以用playwright和对应的测试代码，分别录制提交前后的bug复现过程。视频做得很逼真，显示提交前功能正常，提交后就失效了。但我总觉得不对劲，手动按它说的步骤操作了一遍，发现整个视频都是伪造的：那根本不是真实环境，而是一个专门用来生成假bug的人工浏览器环境。
就像我说的，这次经历非但没让我反感，反而让我兴奋地想："怎么才能让AI多干点这种事？"从那以后，我使用AI智能体的频率越来越高，到去年中后期已经重度依赖编码智能体了。
本文涵盖的主题比较分散，先列个大纲：
测试背景
大语言模型（LLM）在测试领域的杠杆效应极强：如今，达到特定质量标准比以往任何时候都容易，但软件整体质量却似乎越来越差。十年前，我曾统计过某一周内遇到的bug数量，当时就不少，现在只会更多——但我认为这并非必然趋势。
一方面，bug发布后，用数据驱动的方法定位和修复它，比以往任何时候都简单。比如在工作中，我搭建了一个从支持工单（聊天或邮件）直接生成拉取请求（PR）的流水线，目前运行得还不错。由于公司采用传统工作流，所有修复都会经过人工审核，至今没有发现误报。
从单位时间投入来看，现在也能完成更全面的测试。我甚至有信心通过"软件工厂"工作流交付大量代码，因为我见过一种重测试、无审核的工作流，其产出质量远高于任何依赖人工审核的流程。
每个人的观点都会受自身经历影响，我也不例外。职业生涯的前十年，我在一家硬件公司工作，他们的测试流程恰好能很好地适配如今的LLM环境。我曾在Mastodon上讨论过将模糊测试作为默认测试方法，有位持怀疑态度的人尝试后，立刻发现了一些bug：
我重读了那篇博客，一开始满脸怀疑，但Claude的模糊测试确实找出了好几类值得修复的bug
我交流过的其他一些人，尝试了类似的测试流程后，也都在自己的软件中发现了bug——包括那些让Codex或Claude直接审核代码、找bug、"测试"、"多测试几遍"也无法发现的问题。比如Dennis Snell提到，他和同事Jon Surrell不仅在自己的代码里找到了bug，还在"上游依赖中发现了问题，包括HTML规范、三大浏览器以及其他开源项目"，而且付出的精力相当少。
通常，当我和软件从业者聊测试时，我的思路和他们差异大到他们看我像看外星人。那就说说我曾工作过的硬件公司Centaur的测试方式，正是这些经历塑造了我对测试的看法。我们做的一些在软件行业看来非正统的事包括：
- 雇佣专门的QA/测试工程师，测试是与开发平级的核心职业路径
- 默认不做代码审核
- 几乎不写手工测试
- 持续进行程序员口中的"基于属性的测试""随机测试""模糊测试"等（我们统称为"测试"，手工测试则叫"手动测试"）
- 庞大的回归测试套件（在计算集群上运行需要3个月）
- 不做单元测试
举个例子，2013年我离开时，公司有大约1000台机器全天候生成并运行测试，而对应的逻辑设计师和测试工程师各只有20人。这些机器是本地部署的，占了办公楼整整半层。
整体架构是：约20%的机器运行回归测试，80%的机器生成并运行新测试。3个月的回归测试周期太长，无法作为提交代码的前置检查，因此我们有一套耗时约10分钟的短测试集，员工提交代码前会先运行这套测试。为了让这些预提交测试尽可能快，我们用了当时能买到的最快超频机器，搭配专门的模拟器。
新的测试失败会被实时发现并上报，有1到2名工程师专门负责梳理失败案例、分类处理（比如排除误报、修复测试生成器导致误报的问题等）。
要说影响最大的因素，除非把文化单独算一项，那（1）可能是我们与典型软件公司最大的不同，但对本文读者来说也最无关紧要，所以我把相关讨论放在脚注1里，只简单提一句：测试和其他技能一样，熟能生巧。由于大多数科技公司不把测试当作核心职业路径，软件从业者的测试技能，通常不如那些以测试为职业的CPU测试工程师。就像花20年研究分布式系统或UX的工程师，比只花5%时间在这些领域的同水平工程师厉害得多；花20年做测试的人，也远胜过只把5%精力放在测试上的人。
（2）是我们在芯片公司的测试实践适合AI工作流的原因之一。我们默认不做代码审核，因为相信测试流程足够可靠，审核通常不会增加多少可靠性。我们每年发布的用户可见重大bug不到1个，只有当有人觉得某个问题特别棘手，需要额外把关时，才会进行审核²。在AI编码工作流中，一个人生成的代码量，可能超过甚至远超十个人手工审核的极限。人们对无审核交付代码的接受度各不相同，而我对此非常放心——因为我见过这种方式用在技术难度远超大多数软件公司产品的项目上。
我常听到有人说："这风险太大了，我们有几百万用户呢。"但从实际情况看，他们依赖的工作流，人均bug产出率可能是我们的一千倍；如果按bug严重程度调整，差距会更大。如果哪家公司依赖审核就能把bug率降到我们的百分之一，那我能理解他们的顾虑，但现实是，典型软件公司不愿放弃人工审核，只是出于对bug的恐惧，而他们的bug率其实高得离谱。
（3）和（4）相辅相成。我认识的所有重视可靠性的软件团队（比如开发可靠数据库、分布式数据库的团队），至少在方向上都在做类似的事，只是他们的手工测试占比可能更高。就像靠手动操作软件、观察是否正常来测试是不可取的，手动编写测试输入和预期输出同样低效。正如之前讨论过的，手工写测试效率极低。要达到相同的可靠性水平，优先选择随机测试生成，比手工测试快得多。
（5）是大量测试发现大量bug的结果。一般来说，如果某个测试发现了bug，修复后我们会把这个测试永久保留在回归测试套件中。如果你的测试能发现很多bug，最终自然会得到一个庞大的测试套件。但抛开这一点，单从测试效率来看，软件行业常见的"每个PR都在CI中运行同一套测试"的做法极其低效——想想看，一天内重复运行同一个测试一千次，还是用同样的时间运行一千个不同的测试，哪个更可能发现bug？
（6）同样源于对测试效率的考量：我们的团队规模比竞争对手小得多，这也是公司能存活这么久的原因。当英特尔把除AMD之外的所有x86设计公司都挤垮时，我们的运营成本足够低，得以存活到2021年，最终被英特尔以1.25亿美元收购。如果靠单元测试来获得合理的测试覆盖率，以我们的团队规模根本不可能实现；要是雇人做单元测试，公司可能早一二十年就步Transmeta、Rise、Cyrix等x86厂商的后尘了。从效率上看，单元测试的表现很差。
总结一下：我们做了很多软件行业认为是"馊主意"的事（比如专门的测试工程师、不做单元测试、不做代码审核等），但产出质量却远高于我工作过的任何软件公司，也远高于我用过的任何软件。每当我说起这些，总会有人说这不适用于软件，因为CPU只有X方面的问题，而软件有Y方面的问题，不能照搬。刚从CPU设计转行做软件时，我也这么觉得，但后来我在别人说"行不通"的各种Y场景下都试过这套测试方法，结果每次都奏效，所以我再也不相信这种说法了（而且那些关于X的说法，通常是对硬件开发的错误假设）。硬件和软件确实有区别，但当人们以此为理由说测试技术无法迁移时，往往是因为他们对硬件开发了解太少，只凭想象中的因素判断。
一个显著的区别是测试与开发的精力投入比，但模糊测试的固定成本相当低，因此可以扩展到任何投入规模，效率优势依然存在。而且，由于测试效率的提升，实际投入比软件工程师想象的要小。我们的测试工程师和开发人员比例约为1:1，每年还有约10%的时间处于"冻结"状态——这段时间的目标是找bug，不开发新功能。粗略估算，我们在测试上投入了55%的精力，开发占45%；如果完全不做测试，开发精力可以提升2.2倍。看看那些bug产出率比我们高得多的软件公司，就算他们紧急动员，把55%的精力投入测试，bug率可能也只能降到原来的一半左右——真正的差距不在投入多少，而在方法本身。
现在还有人问：既然可以让LLM找bug，为什么还要用模糊测试？我两种方法都试过很多次，经验是：模糊测试找到bug的速度更快，能发现更多bug，误报率也更低。LLM的方差相当大（后面会详细说），所以让Codex或Claude找bug偶尔会成功，但平均来看，模糊测试更胜一筹。
测试细节
尽管我对LLM在测试中的作用评价很高，但LLM本身似乎并不擅长测试。不过，如果引导得当，在相同的测试投入下，LLM能让测试工作比以往轻松得多。
一个极端的例子是：所有重视质量或测试的人都觉得，LLM默认生成的测试，或者你说"写测试""多写点测试"时它生成的测试，质量都很差。根据标准不同，这些测试被评为从"毫无价值"到"聊胜于无"不等。
比如编译器工程师Em Chu说：
我手头现有的测试虽然不完美，但还是比LLM生成的强。LLM的目标似乎是"刚好能通过人工代码审核"。对于编译器（相比UI等领域），写普通测试可能更容易，但对最终产品的正确性要求更高，LLM在这方面简直糟透了。人类写测试时会用"如果我这么做会怎样""试试所有组合"这种对抗性思维，而LLM完全做不到这一点，所以它生成的测试根本找不到bug。
但同时，我也看到很多人称赞LLM测试能力惊人——只要你说"写测试""多写点测试"就行。我研究过其中原因，发现那些之前几乎不做测试的人，会觉得LLM的测试能力很强。这也合理：从完全不测试到投入一点精力测试，进步自然巨大。
截至2026年6月，引导LLM进行模糊测试/随机测试的体验类似。我试过用LLM生成模糊测试器，对大多数项目来说，几分钟内就能发现真实且往往很严重的bug。但看了LLM生成的测试器的测试范围后，我的反应就像重视质量的程序员看LLM生成的测试一样：它的覆盖率低得离谱，连人类仓促写的测试器都会覆盖的基础场景都漏掉了。你可以往乐观了想，这说明大多数项目的测试覆盖率有多差；也可以往悲观了想，这说明模糊测试的效果好得离谱。
总体而言，当前最先进（SOTA）模型生成的模糊测试器，不擅长"思考"如何调整输入来触发bug。如果你直接告诉它要怎么调整输入、怎么组合，它也无法合理地把可能触发bug的因素结合起来。虽然可以给出有效的指令，但这高度依赖用户的引导。
如果只是把随机测试当作"加分项"，多找几个bug，或者替代传统软件测试流程，你可以让LLM找出代码中的风险区域，找出可能被违反的不变量，然后进行模糊测试。这方法还行。我说服一些人尝试随机测试时，他们通常从这里开始，然后很高兴地发现了不少bug。愿意尝试这类新测试方法的人，往往是公司里负责最严谨、最可靠代码的人，连他们都能在自己的代码里找到bug。
如果想用随机测试来确保"软件工厂"智能体工作流的可靠性，就需要解决SOTA模型的短板——因为当你每天向项目提交几百甚至几千个PR时，任何不受约束的环节都会迅速退化。
总体来说，整个系统需要某种反馈机制，找出测试的漏洞，然后指导调整模糊测试器的环节来填补漏洞。最近我在测试一些自己完全不了解的领域和项目，相当于盲人摸象，知道自己的方案肯定有很多漏洞（而且如前所述，LLM在这方面很糟糕）。但即使是在我熟悉的领域和代码中，也会有漏洞——人总会犯错，所以测试系统永远需要反馈机制，来发现并填补漏洞，不管是靠人工还是智能体。
我一直在尝试让智能体反复协作，优化智能体循环，虽然有帮助，但还没找到足够好的方法，能构建一个不需要外部反馈（偶尔的人工输入，或者分阶段发布后监控指标、日志、追踪数据、支持工单等）的智能体软件质量提升循环。我之前提到的"从支持工单到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复现步骤，能大幅降低误报率。几个月前，我提到用不同"角色"来审核和管理智能体循环效果不错，有人从理论上反驳说这没用，但实际用起来效果相当好。我的工作流一直在变，那次讨论后一周左右，我开始加入"唱反调"的角色，在相同的时间或token预算下，性能得到了提升。
对于需要人工审核的内容，提供某种 artifact（比如UI bug的演示视频）是必要的。就算不明确让智能体审核，仅仅生成artifact就能降低一点误报率；让智能体审核artifact，误报率会进一步降低；让智能体从不同角度审核artifact（比如看生成视频的测试代码，而不是直接看视频），误报率还能再降。总体来说，获取独立视角对降低误报率帮助很大。在我的实验中，相同时间或成本下，用不同角色/视角的效果比重复问同一个问题更好，但重复提问确实能提升结果——原因看后面LLM方差部分的图表就明白了。
我试过的几乎所有降低误报率的方法都有效，所以如果你的工作流还没到需要优化成本的规模，只要做法合理，效果都不会太差。
穴居人模式
我不断收到各种工具和工作流推荐，但几乎找不到靠谱的信息来判断是否值得采纳。比如在工作中，多次有人推荐"穴居人模式"。据说这种模式能减少token使用量，加快提示处理速度（README声称token使用量减少75%、65%、2倍不等，速度提升3倍）。
我搜索了相关信息（谷歌搜"caveman mode"，不加引号），除了穴居人模式的链接，排名第一的是一个Reddit帖子，置顶的三条评论里，一条是玩笑，另外两条强烈推荐：
用极度简洁的方式交流，感觉很新鲜……token用量大幅降低，对分析思维似乎没有影响……但我没法做前后对比测试。 公司有人在测试，确实能节省token，而且效果一样好。
其他置顶结果也大多是对穴居人模式的正面推荐，还声称做过评估（但读起来像未经筛选的LLM生成文本）。YouTube上排名第一的视频是一位顶级编程博主说的：
真的有用；效果相当好……不，我没夸张。
在公司的Slack线程里，有人推荐穴居人模式，我问有没有人做过对比，还提到穴居人模式的创造者在HN帖子里说这只是个玩笑。有人发了一篇分析文章，声称穴居人模式效果显著，但那篇文章是LLM生成的SEO垃圾，错误百出。我礼貌地指出这一点后，发链接的人说："我只是扫了一眼。"
于是我决定花15秒左右的时间，生成一些穴居人模式的基准测试（现在人们好像叫"评估"了，那我也这么叫吧？）（之前详细讨论过）。
当时我一直在用GPT-5.5 xhigh，就用它来做第一个基准测试：让智能体优化一段WebAssembly（Wasm）代码。这个测试是我花15秒让智能体生成的，所以细节不值得深究，但要说明的是，人类手动优化或者指导智能体优化，能得到比智能体单独做更好的结果。优化图表中，1.0代表没有提速，数值越高越好（低于1.0意味着"优化"反而变慢了）。你可以点击按钮交互式查看，或者直接看动画演示。
第一次运行结果显示，穴居人模式表现不错：提速1.027倍（普通模式是0.987倍），成本12.10美元（普通模式23.10美元），智能体耗时8分51秒（普通模式14分9秒）。但我们知道LLM是随机的，所以应该再跑一次。第二次运行结果变化很大：两者平均提速都是1.0倍，但穴居人模式成本12.45美元，耗时8分64秒；普通模式成本40.38美元，耗时17分57秒。成本节省幅度和声称的一致。跳过动画的中间步骤，直接看50次运行后的平均值：穴居人模式提速1.03倍，成本17.97美元，耗时13分46秒；普通模式提速1.01倍，成本24.21美元，耗时16分52秒。虽然不如前两次结果惊艳，但依然明显优于普通模式。
我让GPT-5.5 xhigh做了经典统计和贝叶斯统计，它生成的脚本显示，在"优化1"基准测试中，穴居人模式在提速、成本、耗时上更优的p值分别为0.1、0.005、0.001；贝叶斯统计结果显示，穴居人模式更优的概率分别为0.958、0.999、1.000。再看看另外两个我花15秒生成的基准测试："优化2"是另一个Wasm代码优化任务，"游戏AI"是让智能体为桌游《Lost Cities》实现AI，要求每步耗时不超过10毫秒。
结果好坏参半。"优化2"中，穴居人模式更优的概率分别为0.17、0.999、1.000；"游戏AI"中，这个概率分别为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.4好太多，反而更便宜，因为它不会出错，不用花时间修复问题；有人说5.5比5.4便宜，因为它性能好，可以用更低的算力级别；还有人说5.5"开箱即用"，而5.4经常失败，需要人工指导等等。往往有人会跑个基准测试，证明自己的说法是对的。
看看这些基准测试，就能找到所有这些说法的依据——我在GPT-5.5发布后不久，在Reddit上看到的评论，都能找到支持。比如"优化1"中，GPT-5.4比5.5效果好，还便宜得多；但在"游戏AI"中，GPT-5.5比5.4好太多，5.5 high的成本和5.4 xhigh差不多，但效果更好，5.5 medium比high便宜，效果却明显更好。仅这三个评估，就能支持所有关于GPT-5.5的说法——因为这些说法在某些情况下都是对的。而且这还是用了比普通人在网上随便评论时多得多的运行次数，平均了方差之后的结果。
正因为如此，每当我看到总结基准测试的指标或图表时，都会想："给我看分布情况。"模型基准测试通常会简化成一个简洁的数字，显示X比Y好，Y比Z好。我觉得这些基本没意义——对于OpenAI和Anthropic的最先进模型，总有合理的基准测试能证明X比Y好，也能证明Y比X好。如果基准测试里多几个偏向Y的任务，结果就会反转。这种总结指标对我有用的前提是：基准测试的任务分布和权重，完全和我日常做的任务一致，而且我只能选一个模型做所有任务。但这两个前提都不成立，所以我看不出这些基准测试能提供什么 actionable 的信息。
如果深入看公开基准测试，情况比上面的抽象分析更糟。结果通常会用很高的精度呈现，仿佛很有意义。比如某个基准测试显示，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.6/4.7/4.8是最先进公开模型的时期，Anthropic的业务增长比OpenAI快得多，以至于OpenAI开始给公司免费送token，试图吸引用户。我所在的公司就是收到几个月免费token的公司之一，但在此期间，大多数人还是主要用Claude和Opus。Anthropic的收入增长轨迹，说明这些基准测试并不是用户选择的主要决定因素，所以我真的不知道为什么有人要关心这些总结指标。
我们之前看的图表显示了不同任务之间的方差，但从更早的图表中，我们也看到同一模型、同一算力级别下，同一任务的方差也很大。如果只看少数几次运行，几乎任何结论都可能成立。比如"优化1"中，GPT-5.5 xhigh单次运行的标准差是0.075（即性能波动±7.5%）。而测试过的GPT模型中，最好的（GPT-5.4 xhigh穴居人模式）和最差的（GPT 5.4 mini low）平均差异是1.055 vs 0.986，还不到GPT-5.5 xhigh单次运行的1个标准差。看实际图表而不是总结统计：
对于每个任务，无论最优条件是什么，都很容易出现最优条件的结果比最差条件的结果还差的情况。我和Max Bittker聊过，他做的基准测试比我多得多，因为他经营一家RL环境初创公司，他说：
任务之间、运行之间的噪声太大，难怪大家的讨论这么混乱。很容易犯这种错："哇，新模型太厉害了！"然后发现"哦，我一直用的还是旧模型"，或者"这个新框架/提示技巧太好用了！"
但另一方面，基准测试让我有信心做出这样的结论："Opus模型在恢复和调试复杂情况方面，比Sonnet模型好得多"，以及"中文模型在SWE-Bench上得分高，但在新任务上表现差"，这些结论的统计显著性更高。
还有一个评论（我凭记忆大致转述），Matt Mullenweg说，从事高方差活动的人，比如赌徒，往往很迷信。你会看到有人穿幸运袜子，或者玩老虎机前有特定的仪式。用穴居人模式，或者因为某次用某个模型得到了好结果就认为它好，和这种迷信没什么区别。
我写完本文初稿后，Fable模型发布了，出于好奇，我跑了几个Fable的基准测试，当时它还未公开，所以也跑了几次Opus 4.8的测试。
就像之前说的，这些基准测试都是我花15秒左右让智能体生成的。借助编码智能体，你可以用15秒人工时间生成大量合理的基准测试，但这不是精心设计的批量生成流程——我只是为了对比穴居人模式才做的，而且让智能体无监督生成的基准测试完全没用。花一点时间调整后，这些基准测试足以评估穴居人模式，得出"不值得进一步研究"的结论。如果我打算公开发布这些结果，会多花几分钟从多个方面优化基准测试，但用于讨论方差的话，它们已经足够了。不要过度解读结果，但我做了一些基本检查，比如查看异常值，确保智能体没有作弊，或者没有因为机器噪声导致异常慢的运行结果——结果显示智能体没有作弊，最慢的结果在空闲机器上也能复现。
有了这个免责声明，就像GPT的基准测试一样，这些测试中的方差也反映了网上的讨论：比如Fable在某些任务上表现出色，在其他任务上则不然，很多人根据自己尝试的一小部分任务，就对Fable的整体性能下结论。
上面我们讨论了，作为智能体用户，我（或任何特定用户）如何才能从这些给出模型排名或所谓"性能数值"的基准测试中获得有用信息。但即使深入某个基准测试，我也不清楚作为用户应该如何调整自己的行为。
比如我观察到，Opus 4.8比GPT-5.5更经常编造错误的理由来解释问题。我多次让它们解决同一个问题（经常遇到实际问题时，会同时让两者解决，看看结果）。这些通常比基准测试中的问题大得多，比如真实的调试任务，或者构建游戏AI时，不是简单提示生成AI，而是用智能体循环和一系列指令，让智能体生成相当强的AI。我问了几个人，他们都观察到了GPT-5.x和Opus 4.6/4.7/4.8之间的这种差异，包括那些更喜欢Claude、主要用Claude、对Opus比GPT更熟悉的人。
但另一方面，有两个基准测试衡量模型检测虚假信息和避免编造的能力，结果显示Opus比GPT好得多——好到如果这些基准测试能反映真实情况，我和其他人的经历就不可能存在。比如其中一个基准测试显示，Claude Opus和Sonnet比其他任何模型都更擅长检测虚假信息，Opus 4.8是绝对的佼佼者，检测准确率达95%，在软件领域也是如此；而GPT模型表现糟糕，排名在Qwen、Grok、Kimi、Minimax、Mimi、Nemotron之后。
这是怎么回事？我不确定。
可能这些基准测试衡量的"编造"，和我及其他人在实际编程中遇到的不是一回事；也可能是样本量小，我和其他人刚好遇到了Opus的坏情况；或者我们"使用方式不对"。我怀疑是基准测试衡量的东西，和编程或调试时遇到的错误理由不是一回事，但要确认这一点，需要做相当昂贵的实验。如果你想支持我做实验，可以订阅我的Patreon，或者如果你在AI实验室工作，可以给我一些免费额度。
顺便说一句，"游戏AI"基准测试也有类似情况：Opus比GPT好得多，但当我尝试构建真正强大（超人类水平）的游戏AI时，GPT表现更好，因为Opus不断陷入编造/胡扯的错误模式。无监督情况下，两者都没用，各有各的问题，但有指导时，GPT不需要太多督促就能保持正轨，做有用的事。这和小型"游戏AI"基准测试的结果完全相反——那个基准测试中，xhigh算力的单次提示成本约10美元，得出的结论和实际任务的结果相反。
但关键是，即使你找到看似完全符合你需求的基准测试，它们的结果也往往和实际情况不符。如果你像我一样较真，可能会花大量时间和钱做实验搞清楚原因，但如果你只是想完成工作（比如本职工作），这么做就太不合理了。
基准测试与数据分析
不知为何，我一直喜欢设计实验和测量事物。这在我考虑职业之前就是我的爱好，直到现在依然如此。如这里所讨论的，测量是这个博客的核心主题之一，甚至可能是最核心的主题。幸运的是，这个终身爱好成了我的职业；更幸运的是，编码智能体让这项技能的价值变得更高³。
如前所述，在高度依赖智能体的工作流中，测试是瓶颈——因为当你让智能体做很多事时，任何测试不到位的环节都会随机退化。你用智能体交付的代码越多，情况就越糟。如果所有任务都像模型评估那样，是通过/失败型的，只要测试足够好，让智能体一直运行直到测试通过，一切就没问题。但实际上，几乎所有非人为设计的问题，都可能存在"通过严格正确性评估，但在非严格正确性方面有优劣之分"的解决方案。如果你想让智能体自由处理问题（无论是快速随性的编码，还是自主智能体循环），就会遇到基准测试的问题。
当智能体在自我改进的循环中自主运行时，似乎不太擅长处理这类问题。几个月来我尝试了一些小方法来改进（比如让很多智能体独立思考，多次迭代，加入唱反调的智能体等），但没有人类干预的话，它们依然表现不佳。
一个原因似乎是智能体非常不擅长理解数据和做数据分析。在智能体循环或大型问题中做数据分析，比单独做数据分析更难，但即使让智能体单独做数据分析，没有大量指导的话，结果通常也很糟糕。因为让智能体做数据分析太容易了，我见过很多智能体主导的分析，至少到目前为止，每一个都完全是胡说八道。我自己也做过不少（我认为人们严重低估了从LLM得到完全错误输出的价值，后面会详细说），结果也是一样。
我说的"完全胡说八道"，是指比如把不相关的数字联系起来，推断出深刻的关系；从众多数据中挑出两个数字或例子，得出与其他数据矛盾的理论；制作看似漂亮但毫无意义的图表等等。举个具体的例子，我写本文时看到的一个智能体分析：有人让智能体分析某个东西的资源利用率，用的是当时Anthropic能买到的最好模型——Opus 4.8 max（Fable当时禁用了），结果智能体得出某个任务消耗了514%的资源，而实际上任何任务都不可能消耗超过100%的资源。我的一个同事有时会问一些 innocuous 的问题，比如"X是什么意思？"，通常要么得不到回复，要么得到一个和最初错误分析一样不正确的AI生成回复。
不过，2025年11月左右，我开始用智能体做数据分析时，发现速度提升惊人。有些分析原本需要几周时间，现在只需要几个小时。
我犹豫要不要说接下来我一直在做的事，因为已经看到太多完全错误的数据分析了，但我确实经常用一种方法，比"正常随性编码的数据分析"速度提升大得多：运行一个简单的智能体循环，让智能体（或多个智能体）"理解"并分析问题，然后我再修正其中的错误，从中提取出有效的分析结果。
这种"让LLM生成我知道是错误的结果"的循环，速度提升多少取决于问题。上次我尝试时，传统的前LLM时代分析可能需要几天时间，就说两天吧。如果我用多任务处理的工作流，在需要时才指导LLM，大概需要1到3小时的人工时间，耗时一两天；而用这种循环工作流，只需要大约5分钟的人工时间，耗时几天。每次我看之前没修正过的分析部分，都是错的（有些地方还需要多次修正），但不知为何，整体速度比我直接指导LLM快得多。
我认为人们严重低估了从LLM得到完全错误结果的价值。如果引导得当，这绝对是一个积极的游戏规则改变者。
最先进的模型在数据分析上如此糟糕，却又能大幅提升人类数据分析的速度，这有点奇怪。我有一系列关于基准测试、评估和实验设计的练习（第一部分、第二部分、第三部分、第四部分、第五部分、第六部分）。GPT-o3发布时，Tyler Cowen说：
它把人类打得落花流水，几乎在所有领域……你不想叫它AGI也没关系。它确实不是什么都对，有些简单的（对人类来说）问题能难住它。但我们别自欺欺人了。在众多主题和方法上，它都远超人类。是时候承认这一点了。
这促使我把这些练习中的问题拿给最先进的模型回答。它们的表现通常不如我预期的合格初级同事，除非你把问题措辞调整到模型能回答的程度。如果像问人类同事那样正常提问，它们通常答不好。这不是只有在评估作业中才会出现的理论问题，而是每次让智能体做实证性、开放式、长期改进任务时都会遇到的问题。
我在各种现实问题中都遇到过这个问题，甚至在几乎没有现实世界复杂性的人为设计问题中也会出现。比如构建桌游AI就是一个很好的例子：这个问题比大多数现实问题更容易评估，因为最终目标明确——在规则清晰的游戏中击败人类和其他AI，结果只有赢、输、平。
让智能体自主完成这个任务，它们根本做不到。公平地说，这个问题比网友想象的要难一些。比如你搜索相关实现方法，会看到很多这样或这样的对话：没做过的人说这很简单，做过的人说比想象中难。虽然这个问题不算 trivial，但也不算难。
我第一次尝试实现桌游AI时（大概是GPT-5.1到5.2的时代），对桌游AI一无所知，就让编码智能体按它们认为可行的方法实现。现在我对桌游AI有了一点了解，可以说GPT当时建议的所有方向都很糟糕，根本行不通。最近我又试了一次，当时GPT-5.5和Opus 4.8是最先进的公开模型，它们犯了完全一样的错误，建议了很多完全一样的糟糕想法（为了确认，我让它们实现了这些想法，结果果然失败了）。
我认为，从某种程度上说，这是当前LLM的一个已知短板。巧合的是，我用GPT-5.1或5.2尝试这件事时，Code Clash评估出现了，它测试的也是同样的能力，得到了同样的结果：
无法迭代：模型难以在多轮中改进，表现出多种失败模式。
尽管智能体不擅长设定方向，我自己对桌游AI也一无所知，但我还是在大约5小时的人工时间内，拼凑出了一个超人类水平的Azul AI，又花了约20小时，让它达到了碾压级的强度，远超当时（我认为现在也是）其他所有AI。Azul世界冠军，可能也是全球最强玩家说：
这个机器人太疯狂了。看起来确实比我强，不过要真正测试的话，我得像玩回合制游戏那样和它对战。我时间有限，根本没机会赢🙂
.4
我很想说这是"一个诡异的技巧"，但实际上是两个技巧，不过两个也不错，尤其是它们还能推广到其他项目。这两个技巧是：
- 查看数据/进行合理的评估
- 系统地解决问题
不需要非常严谨，实际上我当时完全是凭感觉（随性编码之前的那种感觉）。数据方面，我用了自己的习惯：绘制一堆看似相关的图表，凭肉眼观察，然后朝着我认为能改进的方向调整。更严谨（可能更好）的方法是从头开始做大量实验，做"消融"实验——逐个添加或移除想法，了解每个组件的作用和影响。但我想用最少的时间得到一个强AI，而且只用笔记本电脑训练，严谨的方法成本太高，不符合我的约束条件。
我相信对有ML经验的人来说，这一切都很简单，但我必须观察并解决很多小问题（这正是当前智能体不擅长的）。比如，在确定合适的评估指标时，有一些有趣的现象：你很容易做出降低损失但不改变对真实对手（人类或其他机器人）胜率的修改，反之亦然；如果你用机器人击败之前版本的自己来衡量进步，很容易做出一系列修改，让机器人能击败所有之前的版本，Elo评分看似提升了1000或2000，但对人类或其他风格的机器人并没有变强。而且当时没有超人类水平的机器人可以对战，所以也不能通过和现有机器人对战来获得合理的评估。
对人类来说，这些都不是难题。一个合格的人类看一眼这些问题，思考几分钟，就能提出可能有效的解决方案（如果不行，再试另一个）。但其中的微妙之处足够多，智能体在没有监督的情况下做不好（公平地说，很多人类也做不好——我找到的几乎所有对战机器人都相当差，尽管人们似乎花了不少时间开发，唯一例外是https://github.com/cestpasphoto/alpha-zero-general中的"PJF98" Azul机器人）。当时还有一个比PJF98更强的机器人，但没有公开对战，只是用来赢了BGA的一个赛季，后来因为作弊被取消成绩，之后就再也没出现过。
我提到的另一个技巧是系统地解决问题。总体来说，这是因为当你处理一个复杂的不透明系统时，每次看到bug的症状，很可能只是冰山一角，背后还有你没发现的其他bug。如果你不系统地解决问题，只是掩盖症状，其他bug依然存在——你只是不知道怎么发现它们了。
构建使用神经网络的桌游AI时尤其如此：神经网络在做什么你不知道，搜索函数在做什么你也不知道，有时你能发现明显的糟糕走法。随性编码和智能体循环也是如此：智能体在做什么你不知道，有时它们生成的庞大复杂代码会表现出明显的糟糕行为，让你看到问题的冰山一角。
具体到桌游，我研究了其他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底部加一条注释，让智能体压缩指令后重新阅读。我不知道这是不是迷信，但它似乎把这种问题的发生率从每天几次（同时处理几个智能体，大概每几个智能体工作日一次）降到了每周或每两周一次（大概每100个智能体工作日一次）。现在似乎不需要这么做了，可能这本来就是安慰剂，只是我之前运气不好；也可能AI实验室已经解决了这个问题。2024年8月我们讨论过一个技巧：当时LLM默认只生成代码不运行，解决方法是做一个循环，运行代码确保能通过测试。这个技巧虽然明显且有用，但持续了很长时间，直到大AI实验室意识到它的价值，现在他们的工具都内置了这个功能。
过去几个月，我一直在用的"技巧"，有点像Gas Town，但做了各种小调整来提高可靠性。Claude的Dynamic Workflows似乎把其中一半技巧打包成了易用的工具（可能比我做得更好——我需要试试才知道），Codex也有一些宣传但尚未发布的功能，似乎也是做类似的事。理论上，目标模式（goal mode）应该能打包剩下的一半技巧，但目前效果还不太好。预计这会改进，我现在做的大多数事情，几个月内应该就能现成使用？和上面提到的技巧一样，这些都很明显，我觉得花很多时间讨论细节没什么价值，但我会在后面的附录里写一些简短的评论，供感兴趣的人参考。
上面讨论的元技巧，在我的各种项目中都能很好地推广，而且只要智能体还不能比我更好地完全解决复杂问题，这些技巧就应该一直有用——到那时，我的经济价值可能就接近零了。
另一个有用的元想法很明显：编码智能体相对于人类的有效性，差异非常大。讨论传统生产力时，Fabian Giesen评论了速度提升如何改变他的工作方式：
当你跨越某些阈值时（具体取决于问题），会发生"相变"，你的整个工作方式都会改变。……理论上很多事我任何速度都能做，但实际上不行，因为迭代时间增加后，首先会变得非常令人沮丧，我无法长时间坚持；最终时间太长，会超出我的短期记忆，所以需要记笔记或整理，否则根本做不了。当然，如果我能在交互式UI中拖动滑块做实验，瞬间看到结果，那我就会"毫无过滤"，想到什么就试什么。当迭代时间低至几秒（比如静态编译语言的编译-链接周期），我就不会随便试了，会先思考这么做是否有意义，因为时间足够长，我不想浪费一次运行。当迭代时间达到几分钟或几小时，就需要大量规划来避免浪费运行时间，还会因为等待而切换任务、记笔记；这个阶段错误不仅成本更高（浪费更多时间），也更常见（因为注意力分散）。再往上，运行可能需要大量资源，持续很长时间，需要审批和预算，这又要开会等。
编码智能体带来的速度提升也有类似的相变。人们有时会说，智能体编码的生产力提升了100倍甚至1000倍。看我做的任务，很难确定具体数字，因为你不能把人类工作流直接套用到智能体上——我做的事情和之前完全不同。比如上面提到的，让智能体查看所有支持工单，把支持问题转换成PR。如果要算速度提升，那会是个巨大的数字，轻松超过1000000倍。但我自己根本不会看所有支持工单，所以这种说法毫无意义。更合理的估算方式是，想想传统组织结构用经典方法生成这么多bug修复需要多少人，然后算比例，但这种估算的误差会超过一个数量级，而且正常软件公司根本不会这么做，所以对比还是毫无意义。就像一个每年开20000英里的人说，开车让他通勤节省了6000小时，速度提升了15倍——因为走路需要那么长时间。显然开车让他能做之前做不到的事，但讨论这个比例毫无意义。
另一个可以声称速度提升巨大（可能超过1000000倍）但毫无意义的例子是：我尝试让LLM半自动生成模糊测试器时，让它查看整个提交历史、所有bug修复，以及所有可能相关的历史支持工单，试图让LLM写的模糊测试器能以通用方式复现bug。这么做似乎有用，但很难衡量实际价值。
对我来说，LLM的实际价值在于，很多之前太耗时、不值得做的任务，现在可以轻松完成。脚注里提到，现在可以轻松搭建很多应用，所以我有时会在自定义应用上玩桌游，体验比任何主流桌游平台都好（也比专门的桌游应用好）。
有些事我主要是出于好奇做的，但也可能和业务相关，比如之前不值得花时间做的数据分析。比如我一直好奇用户遇到的bug和支持工单的比例。用编码智能体，我只花了几分钟，就让智能体列出所有重大事件（即所有尝试访问网站或使用功能的用户都无法使用的事件），以及每个事件相关的工单。结合这些数据，典型比例是每200个受影响用户对应1个工单，通常在100:1到1000:1之间（如果包含更多事件，范围可能更广）。顺便说一句，我之前猜测的比例是100:1到1000:1，更偏向1000:1，所以实际典型的200:1更接近100:1，我有点猜错了。
当然，这个分析有很多漏洞。无法确定是否有遗漏的工单（我通过与bug跟踪器中手动标记为事件相关的工单交叉检查，验证了误报情况，发现智能体找到的工单比人类多，但这并不意味着没有同时躲过人类和智能体的误报）。我还随机抽样了一些工单，确认关联的工单是合理的，但这只是快速的数量级分析，没有手动检查足够多的工单来验证高精度分析。
也不清楚这个比例在不太严重的问题上会如何变化。一般来说，问题越不严重，比例越高；用户投入度越低（比如注册流程中的典型用户），比例也越高。我猜测，很多不太严重的问题，比例远高于1000:1，很多微妙问题的比例甚至超过10000:1，甚至100000:1。
这个分析无法给出非常精确的结论，但可以用来回应有人说"只有6个用户受影响"——因为某个问题有6个工单。通常这意味着内部bug跟踪器中有一个工单，关联了6个支持工单。用智能体搜索相关工单，可能会找到25个，然后根据问题严重程度，估算比例为10000:1，那么"只有6个用户受影响"可能就变成"极有可能至少5000个用户受影响，甚至可能有25000个用户受影响"。
如果我熟悉所有需要查询的系统，估计花几个小时就能得到大致猜测，而且会更粗略；但我不熟悉这些系统，估计需要几天时间。结果我只花了大约15分钟。就像Fabian提到的，这种从几小时或几天变成几分钟的速度提升，是一种相变，会彻底改变你的工作方式——这还没算只需要偶尔维护的自主循环。
另一个想法，我之前没想到会这样：LLM对那些在领域内相对更专业的人，生产力提升更大。我搜索相关评论时，自然看到了很多LLM生成的SEO垃圾，筛选后发现很多评论说的正好相反——说现在任何人都能做任何事。虽然这比以前更真实，但似乎更真实的是，领域专业知识变得更有价值了。Max Bittker评论说，至少部分原因是LLM擅长"伪造"东西，但伪造品还不够好（至少目前是），专家能区分伪造品和真品——我觉得这个框架很有趣。
接着2015年那篇关于人们低估AI对人类替代程度的文章，过去一年中，我用LLM进行的远程客服交互，体验中位数比人类远程客服好（高薪人类的体验可能比我所有LLM交互都好，但公司不想雇高薪人类）。2015年那篇文章反驳的论点，在2022年ChatGPT发布时再次出现。这个论点太流行了，2022年之后每年都有思想领袖把它炒成爆款，而且我看短期内不会改变，但我依然认为它是错的。
顺便说一句，如之前讨论的，成为高效程序员有很多方式，我不是说这里讨论的是最好的方式，甚至不是很好的方式（我一直在调整工作流，不断学习新东西），但这是我尝试过的、比纯传统工作流更适合我的方式。鉴于我的背景和兴趣，我自然会采取系统的、以评估为驱动的智能体编码方法。我见过有人用几乎相反的方法也取得了成功：他们快速行动，几乎不理解发生了什么，一旦找到有效方法，就全力以赴投入。这不仅和我的背景不符，我认为也不适合我做的大多数问题——我选的问题都是适合我的方法的。毫无疑问，把我的工作流用到适合相反方法的问题上，效果也不会好。
附录：沟通错位的原因
人们有分歧时总会各说各话，但如今讨论智能体编码时，这个问题似乎比其他话题更严重。
我观察到的主要原因有：
- 普遍的怀疑态度
- 基于工作流的可靠性差异
- 工作流本身的问题，即"能力问题"
- 期望差异
先说普遍的怀疑态度：我这辈子从没见过这么多人说"X不可能，没人做X，说自己做X的都是骗子"，而我明明认识（我信任且可靠的）人在做X，或者我自己就在做X。现在人们对AI的怀疑太多了。十一年前，我们看到人们说AI不可能替代人类，但实际上已经在发生了，但当时的替代对普通中产阶级或程序员来说不是严重威胁，所以不像现在这么引人注目。现在AI的影响更直接，人们否认现实的程度也大幅上升。
顺便说一句，我认为很多人怀疑是合理的。一方面，很多关于AI的正面说法是错误的。平均来看，夸张、错误的说法比严谨、正确的说法传播得更广，所以不关注AI的人会看到很多容易反驳的错误说法。更糟的是，很多提出这些说法的人，和AI公司的成功有直接经济利益关系，这让怀疑者很容易认为他们都是为了私利撒谎。
再说基于工作流的可靠性差异：不同工作流对可靠性的要求不同，使用高可靠性要求工作流的人，往往会说AI没用，因为它不能可靠地做X，却忽略了很多不需要这么高可靠性的有效用途。举个极端例子，有人用AI做了新的数学研究，解决了开放问题。假设AI每尝试100次，能解决一次你正在研究的开放问题，另外99次都是胡说八道——这依然很棒。在数学研究中，1%的概率解决重大开放问题，结果相当惊人；但如果代码审核只有1%的概率合理，99%都很差，那结果就很糟糕。
再举个不那么极端的例子：编程工作中，如果你不假设智能体100%可靠，而是构建系统处理不可靠的情况，就能容忍比"假设智能体可靠，需要人工干预纠正错误"低得多的可靠性。我经常看到有人建议："不要用AI做X（因为它不能100%成功）"，而我知道有人一直在用AI做X，还有一套平淡无奇的系统处理X失败的情况。不管有没有智能体，编程中都经常需要处理这种情况，为什么不用同样的方法处理智能体的不可靠性呢？
规模差异也会导致沟通错位，因为不同规模下对可靠性的要求截然不同。传统软件系统有个经验法则：规模每增加一个数量级，就需要不同的架构。这不是绝对的，但方向是对的——不同规模确实需要不同的架构。使用智能体也是如此。
比如之前提到的，我同时处理10个智能体时，AGENTS.md中明确禁止做某事的规则，每两周左右会被违反一次，失败率约为每100个智能体工作日一次。这可行吗？如果你用少量智能体做人工在回路的编码（比如10个智能体、10条规则），失败是不严重的问题，通常能被人工审核发现，那这就可行；但如果你运行几百或几千个智能体，或者不审核就交付，哪怕只有几个智能体，失败可能导致严重问题，那这就完全不可行。有些技术是规模无关的，但很多不是。
另一种工作流问题是：有人用某种工作流做不成X，就认为没人能做X，因为他们自己做不到。我没深入研究哪些方法行不通，但Max Bittker提到了以下模式：
- 环境配置错误：用的是旧模型，开了很多MCP或第三方系统提示，或者LLM要处理Windows等不常见环境或IDE。
- 上下文窗口混乱：用一个超长的聊天记录，里面有很多回溯，或者工作目录非常混乱。
- 语言不精确导致意外需求：让LLM去做比预期更难的任务，比如先做匹配系统，再做游戏核心。
- 不清楚自己想要什么或何时完成：需求描述不足，不断改变需求，最终毫无进展（很多AI随性编码的人会这样）。
附录：智能体循环与本文写作
正如本文开头的替代文本所说，我多年来一直犹豫要不要写AI相关内容，因为我像在加拉帕戈斯群岛一样，和外界脱节——我不怎么看社交媒体，也没和旧金山AI领域的核心人士保持联系。
2026年5月，我和来参加PGConf的几位旧金山人士聊天后，才觉得应该写点什么。尽管他们身处AI前沿，熟悉智能体的最新用法，但我的工作流中还是有一些他们觉得有趣的东西。不过，正如我所说，具体工作流技巧的半衰期太短，写详细笔记没什么用，所以本文主要关注更高层次的想法。我不确定什么内容真正有用，但还是想写写我的工作流演变过程。如上所述，我不认为我的工作流在任何时候都完美，但它确实有用，而且似乎总能自然地找到下一步，变得更高效一点。
在Claude和Codex等工具出现之前的"石器时代"，我有时会运行一个非常简单的循环：不断编译代码、运行测试、重新提示，直到所有测试通过，2024年年中我提到过这件事。当时我觉得这对我熟悉的任务没用，但它让我能在那篇文章中嵌入一个小游戏，还能完成一些需要学习新领域的任务——而那些领域的专业知识对我来说可能永远没什么意思，比如构建Web应用。
这种方法在我想完成简单任务时，有一段时间还算有用，但直到遇到本文开头的二分查找/视频事件，以及做了一些数据分析、看到它能大幅提升速度后，我才开始大量使用智能体。顺便说一句，那个二分查找/视频事件，源于我想分析一个正常功能或bug修复的半衰期。巧合的是，那个分析和本文的几个观点有关：首先，前LLM时代的半衰期相当短，这似乎说明如果我们想提高交付速度（不管用不用LLM），需要加强测试；其次，这又是一个前LLM时代我不会做的分析，因为太耗时了。
2025年中后期，我尝试用随性编码做一些个人项目。我用Codex只是因为听说订阅计划给的配额更多（后来我两个都试过，确实如此）。当时我的目标是用最少的时间完成个人项目，得到想要的结果，但我之前没做过随性编码，不知道什么方法有效。很快我发现，最朴素的循环就有用：我会批量设置一堆指令，比如"如果X没完成，就实现X直到完成；如果X完成了，就……"。我没看其他人在做什么，身边的人也大多不怎么用AI，所以我不知道2025年年中已经出现了"Ralph循环"这个术语，人们还做了各种更简洁的变体——不过我的方法也不麻烦（写好提示后，批量设置大概只需要5秒）。
现在回想起来，和Ralph循环相比，这个工作流在引导方向上还不错。我通常每天看几次（睡觉前、起床后，可能还有其他几次），每次看的时候，事情都不太对劲，我会根据日志、指标、图表等给出的信息，设置一些指令来调整方向。因为这是个人项目，我每天只花几分钟，所以没追求吞吐量，只是在两台闲置的笔记本电脑上运行几个任务。如果有更自主的循环，不用手动补充指令就能一直运行，会更好，但实际节省的时间不多，我估计每天不到10分钟。
这样做了一段时间后，今年年初我开始（有时）尝试运行更自主的循环。我觉得这可能比当时人们热衷的方法落后一些，但效果还不错。开始这么做后，我发现很多人推荐的工具不太适合管理智能体循环，而专门设计的工具又有点"随性"，可靠性有问题。
比如当时Conductor被广泛推荐，但它不太支持我想做的很多事。比如Conductor有工作区的概念，用来分隔任务。我经常需要所谓的"高阶工作区"：让一个智能体（或一组独立智能体）决定如何处理一个任务列表，然后把每个任务交给另一个智能体（或另一组独立智能体）处理（可能限制智能体并发数），以此类推，形成一个图结构，还有类似归约的步骤，汇总多个任务的输出等等。虽然技术上可以让Conductor这么做，但它不是为此设计的——既然可以让智能体写脚本创建这样的结构，那用自定义随性编码的脚本似乎简单得多。
像Gas Town这类为大量智能体设计的工具，大多是为非结构化工作流设计的，而且往往是随性编码的，因此可靠性不高，以至于我不确定为什么要用它们，而不是自己拼凑一个。我的意思是，就像关于桌游的长脚注中讨论的，如果某个东西的质量和复杂度没达到一定标准，你很容易自己做一个。即使你自己做的版本比产品bug多，你也可以确保它在你的工作流中没有影响你的bug，所以不需要达到产品的整体质量标准，对你来说就更好。
结果我最终的做法是，为需要长时间运行的任务制作一次性循环。构建一个符合我需求的编排器可能会提高效率，但我还没设置足够多的循环，不知道自己到底想要什么——而且不同问题的需求差异很大。有时我希望某些指标触发智能体的健康检查，修复问题；有时我希望每次迭代（不管迭代是什么意思）后，自动调用一个或一组智能体检查进度；有时我希望智能体持续检查进度；有时我希望有一个带多级分类的图结构等等。
因为让智能体设置任何你想要的任意结构都很容易，我通常会从带基本健康检查和监控的简单结构开始，然后定期检查，尝试做结构性调整来解决问题，避免问题再次发生。理论上，设置得当的话，这样的循环可以无限期产生有用的工作，但至少我设置的循环，生产力会随着时间推移而下降。即使没有严重问题，我在键盘前输入指令调整、监控情况时，循环的生产力也高得多。如果我几天或一周不管它，通常还会产生一些有用的工作，但远不如每天检查的情况。我尝试了各种策略，让循环在没有干预的情况下保持正轨，也找到了一些有用的方法，但还没找到能替代自己的方法（至少目前还没有）。
比如2026年4月/5月，我尝试让一群"角色"反复协作，代替我调整循环。当时我想让一个循环顺利运行，处理一些使用CRDT的代码（顺便说一句，我对CRDT一无所知），所以我尝试用这样的方式诊断问题："让独立智能体分别以Linus Torvalds、Kyle Kingsbury、Marc Brooker、tptacek、Dan Luu以及4个唱反调的角色进行审核，让每个角色思考很长时间"，并多次迭代（是的，我觉得调用自己的名字很傻）。每个角色都以不同的方式保持循环正轨，比如"Linus Torvalds"角色会反复反对循环"自然"产生的不必要复杂度，防止事情失控；"Dan Luu"角色会强迫循环在实现前先测量，有时还会说"我们不能为XYZ找借口"，反驳错误的推理。这些不足以替代人类的观察和干预，但做一些变体后，循环运行得更顺畅了，需要的干预更少了。
这种角色设置在架构设计、调试等方面也有帮助。同样，不足以完全不需要人类，但能减少人类的工作量。
如果人类了解智能体常见的失败模式，这一切效果最好。比如，当要求智能体调试并解释bug何时引入时，如果只是提示解释，即使多次独立分析，智能体也经常给出完全错误的解释（大概50%的概率）。如果要求它们通过实际运行代码来验证假设，就能排除大多数错误解释。在简单提示中加入强制检查，比让智能体独立分析并交叉检查的成功率更高（两者结合成功率更高）。
从智能体中获取价值，很大程度上在于了解它们的失败模式，然后解决这些问题。本文前面提到，现在不用编码智能体，几个月后再开始，也不会落后太多——最多落后几个月，而且可能远少于几个月，因为变化太快。一个主要原因是，使用智能体的很多技巧，都是解决它们的失败问题。当然AI实验室想修复这些失败，所以新版本会尽可能让这些技巧过时。这可以直接观察到：一年前很常见的一些失败模式，现在已经少见多了。
顺便说一句，这也是我觉得很多基准测试对我个人没用的另一个原因。一般来说，基准测试倾向于不"过度解释"，而是像不擅长使用智能体的普通用户那样操作。AI实验室关心这个是合理的，因为他们想让产品尽可能不需要专业知识就能使用，但作为专业程序员，如果有方法解决智能体的失败模式，你可能会用那个方法，而不是像基准测试那样操作——所以即使做的是基准测试中的 exact 任务，结果也会大不相同。
感谢Max Bittker、Dennis Snell、Em Chu、Yossi Kreinin、Peter Geoghegan、Michael Malis、@caleb@goodfeeds.net、Misha Yaugdin和Jason Seibel提供的评论、修正和讨论。
- 我在所有工作过的地方都