关掉大脑无济于事

# 关闭大脑无济于事 来源：http://danluu.com/brain-off/ 这个想法在我脑中萦绕已有一年半之久。如今随着LLM能力日益提升，我看到越来越多人在使用LLM时选择关闭大脑，这种想法在我心中愈发频繁。[\[返回\]](http://danluu.com/brain-off/#fnref:N)Luke Burton曾评论道： > 我认为这种能力更多反映的是工作类型本身，而非人们想象的那样。我只会在处理低价值任务时才会"放手不管"——那些即便失败也无伤大雅的任务。 > > 对于高价值任务，LLM一次性完成的可能性要低得多。我必须同时扮演测试工程师、技术经理和架构师的角色。这个循环过程常常让我感觉像在赶工期，总隐隐担心自己遗漏了什么，担心一个描述不周全的提示词可能导致需要推倒重来的架构决策。 > > 另一个观察是，高处理速度反而促使我提高了自己交付标准。以前我可能交付一个最小可行产品（MVP）然后迭代优化，现在我会让代理（Agent）打磨细节、探索边界情况，其深度远超我的常规要求——除非明确提示，否则它们注定无法主动做到这些。 或许这会引发一些令人不安的思考，但我想对那些"肉体代理"们说：如果代理能如此轻松地完成任务，那么：1）是否可能你已经在某种程度上"躺平"了？2）为何不推动代理挑战那些看似轻松却能拓展其能力边界的任务？ 我们一直在推进一项看似极适合"放手自动化"的工作：将[已编辑内容]迁移至Bazel构建系统。即便有代理协助，这个项目已耗时数月。这项任务中隐藏着许多难以言明的隐性需求，让代理在这条钢丝上行走意味着持续监督。给出类似"用Bazel构建"的提示然后撒手不管——这至少需要数月甚至数年才可能实现，或许永远无法达成？因为其中涉及太多决策点和未知因素。 比如这种情况多常见：你接触某段代码，不清楚它为何如此运作，但了解原因后会彻底改变应对策略——可能影响开发体验，或者你不确定是否有客户已在使用该功能，等等。面对这种情况，"肉体代理"们究竟该如何应对？ 反过来，当你与利益相关者评审成果时，对方却说："哦那个？那部分不需要，我们根本不再使用了。"这种基于错误假设（认为某元素必须保留）做出的决策，又该如何评判？ [\[Luke评论结束，以下为作者补充\]] 当代理遇到分布外问题时，需要人类决策的必要性会更加明显。一个轻微版本是我们曾比较代理使用不同编程语言的表现（http://danluu.com/pl-tokens/），代理在冷门语言上的表现远差于主流语言——尽管训练数据包含这些语言。更典型的分布外场景是尝试让代理玩桌游（尤其是现代桌游而非国际象棋、围棋等经典游戏）。总体而言，在《迷失之城》或《领土》这类游戏中，最先进的模型+工具链的效果，甚至不如一个有基本游戏素养但从未接触过该游戏的玩家。如果你向代理询问游戏规则，它能说出很多看似合理的表述，对不懂游戏的人而言可能很有说服力，但任何熟悉该游戏的人都能立刻发现其中的谬误。最近我和一位新手玩《领土》，对方试图借助ChatGPT理解游戏规则，这让我十分怀疑（据我观察确实适得其反）。几局之后，我查看了ChatGPT的指导内容，大约半对半错，但错误的那部分会把玩家引向比"运用通用游戏策略的合理玩家"更糟糕的境地。顺便说一句，公开资料非常充分——即使从未玩过，只要花五小时（若允许参考规则手册则可能仅需30分钟）研究现有攻略，任何人都能达到前1%的游戏水平（http://danluu.com/p95-skill/）。我认为这很无趣也不推荐任何人这样做，但这正揭示了当前人类与代理在处理分布外问题时的差距。或许下次大型模型发布会扭转局面，但今天这个差距依然显著。 总而言之，我想说的是：即使在编程任务中，你也常会遇到分布外问题，此时代理的表现会远逊于普通人类。想要获得理想的成果，你就必须发现并处理这些问题。 [\[返回\]](http://danluu.com/brain-off/#fnref:L)关于"假定一切都会顺利"导致的错误案例，这里有一些示例（http://danluu.com/pl-tokens/#fn:H）：代理（有时）会严重过拟合测试用例；或者（http://danluu.com/benchpocalypse/）过度优化某个指标。有理论认为代理更倾向于在类评估问题上作弊。虽然我不确定这是否属实，但即使假设为真——即便在我的工作和私人项目中，即使不运行评估，我也倾向于创建比多数人更多的评估式指令——我也见过其他不常编写评估式指令的人，当他们写下提示词后放任代理自由发挥（无需监督），同样遇到了相同问题（我认为实际上更严重）。我曾通过设置严格约束来最小化监督并成功让代理运作，但这使得整个过程更接近评估式，与多数人的做法不同。 当我试用那些将思考外包给LLM的人开发的软件时，总发现严重问题。虽然有人告诉我这类软件能用，但其水平往往低于本讨论（http://danluu.com/bug-blind/）的标准。 举个简单的例子：某编程领域意见领袖在推特宣称"编程问题已被解决"，理由是他尝试了各种（编程）领域的项目，Claude都能像专家一样解决所有问题。但当我查看其GitHub时，所有我检查的案例（不止一个）要么无法运行，要么运行效果极差。事实上，我在开发桌游AI、为自己的AI寻找对战目标时就遇到过这种情况。对方的AI是一个AlphaZero风格的机器人，其表现甚至不如让LLM编写简单的极大极小启发式算法机器人，再通过循环迭代优化启发式评分（按理说，这种游戏里平庸的AlphaZero风格机器人本应轻松取胜）。 另一个简单案例：遵循（真实商业产品的）标准流程会将你引入死循环。虽然技术上可以逃脱（大多数程序员可能想出逃脱方法），但该软件的目标用户（非程序员群体）很可能无法逃脱，也就无法使用其核心功能。 顺便说明，我为自己编写过大量"仅限自用"质量的软件——如果作为正式产品，我会评价为"基本不可用"。我认为软件"基本不可用"本身并非坏事（例如这里讨论的正则表达式引擎（http://danluu.com/perf-opt/），我让代理构建它来加速本机ripgrep搜索；以及这个Rust解释器（https://github.com/danluu/rust-interpreter），我让代理构建它以加速某些项目的代理迭代循环——两者都不应被实际使用）。我也在（http://danluu.com/ai-coding/）提到，让代理通过循环处理数据分析并生成完全错误的结果，再指导其修正，这极具价值。但为自己编写"仅限特定场景使用且存在已知缺陷"的软件，或先产出有缺陷的作品再修正，与编写大量不可用的软件后宣称"编程问题已解决"（或将同等质量的成果投入商业产品）之间存在本质区别。 审阅初稿时，我曾询问这组简短思考是否值得发表。Thomas Dullien（又名Halvarflake）说："好文章！必须发布，因为每当我表示'LLM无法解决所有编程问题'时，人们都用看疯子的眼神看我，而我看他们也是如此。"巧合的是，我完成初稿后，看到Gary Bernhardt发推："对比真实的代理输出与人们在此谈论的内容，简直超现实。日常改动中，我的代码审查常能将差异量削减至原始的25%。充满无用测试、过度谨慎、逻辑倒置。然后我读到推特上说'编程问题已解决'。"他又补充："我发推后一小时内的例子：让代理修复DATABASE_URL管理问题，它在NPM脚本中直接插入`if`语句，在CI中添加了运行内联JS脚本的条件节点调用。差异量约20处。经我修正后：增加0行，+1个单词。" 我认为任何持有Thomas或Gary态度的程序员，长久以来都会有同感。我曾一度疑惑，那些对LLM生产力给出极高评价的人，是否从LLM中获得了我认知范围外的更多价值。但正如我们在此讨论的（http://danluu.com/bug-blind/），随着更多证据浮现，我越来越确信这只是人们的自欺欺人。桌游案例的妙处在于你可以客观衡量AI的水平。在极端情况下，可能出现A>B>C>A的循环，但如果AI输出纯属无意义内容，这在客观上相当明显。商业软件也是如此——你可以与公司内部人员交流或自行查看数据，就能发现转化率低下、用户流失严重、满意度调查反映极高等问题。 [\[返回\]](http://danluu.com/brain-off/#fnref:H)在他的文章中，他并未明确提及用户实质上扮演while循环或for循环角色的情况，但这种日益普遍的行为同样符合文章主旨。[\[返回\]](http://danluu.com/brain-off/#fnref:G)或许这对创始人、大股东等群体有效，但据我所见，采用此模式的人大多是职场雇员或个人项目开发者，他们常宣称"这效果很好"、"编程问题已解决"等，暗示着对受雇软件工程师而言编程已是成熟领域。 另一种论调类似"我们都将过时，何必努力？"——除非能确保人类淘汰已迫在眉睫，否则这种逻辑在我看来本末倒置。若已财务自由准备退休，你当然可以关闭大脑，但这本就是你随时可做的选择，历史上从不缺乏敷衍了事之人。若尚未准备好退休，你可以选择能创造更多价值的事（这很可能需要保持思考）。若你认为人类不会被淘汰，则不必急着赚钱；但若你确信淘汰将至且需要赚钱，那么现在正是加倍努力、保持思考的关键时期。那种"反正努力工作也得不到更多回报"的推理，在我看来完全错误——通过主动发现问题并解决，我获得过加薪和奖金，我的朋友们也是如此（除非他们身处完全不认可优秀工作的糟糕环境，那他们自然会离开）。 [\[返回\]](http://danluu.com/brain-off/#fnref:F)