关掉大脑行不通：肉体外挂这条路对员工没有未来

Footnotes

1. 这个想法我大概已经有一年半了。现在它出现得更频繁，因为 LLM 越来越好，我看到人们在跟 LLM 打交道时花更多时间把脑子关掉。 ↩

2. Luke Burton 有这样的评论：

   我觉得「能这么做」这件事，说明的东西比人们以为的更多，而且说的是所做工作的类型。只有当一个任务价值相当低、失败得起的时候，我才会这样甩手不管。

   对于高价值任务，LLM 一次做成的概率低得多。我必须同时扮演 QA、工程经理和架构师。这个 while 循环常常感觉像在赶工期。我总有一种隐隐的怀疑：我漏掉了什么，而一个描述糟糕的 prompt 可能导致某个架构选择，需要被推翻重来。

   另一个观察是：高吞吐让我抬高了对自己交付物的标准。以前我可能先发一个 MVP 再迭代，现在我会让 agent 去打磨、去探索边界情况，远超我平常的水准——而如果不提示，它们基本做不到。

   也许这会让一些人不太舒服，但我想问那些肉体外挂：如果 agent 这么轻松就能搞定，那么 1）有没有可能你本来就一直在混日子？2）你为什么不把 agent 逼到远超它们轻松能做的任务上去？

   我们一直在做一件你大概会以为极度适合「放手自动化」的事：把 [已删除] 改造成用 Bazel 构建。即便有 agent，我们也花了好几个月。这个任务里埋着大量难以言明、难以规范化的需求，让 agent 走好这条线意味着要持续监督。给它一个「把这个改成 Bazel」的提示然后走开，至少是很多个月之后的事，也许是几年，也许永远不行？决策点太多，未知的未知也太多。

   比如这种情况有多常见：你碰到一段代码，不清楚它为什么这样运作，而知道原因会实质性地改变你该采取的做法。也许它改变开发体验，也许你不知道某个客户是否已经在用它，诸如此类。这种情况你要怎么「肉体外挂」过去？

   反过来，你和某个利益相关者回顾你做的事，对方说「哦那个？那部分不需要了，我们早就不用了」。那么，围绕「某个东西必须保留」这个错误假设，都做出了哪些决策？

   [Luke 的评论结束，以下是我的评论。] 更明显需要做决策的地方，是 agent 撞上分布外的东西时。一个较小的例子是我们比较过 agent 使用不同编程语言的能力：agent 在冷门语言上差得多——它们被训练过，但训练量远不如主流语言。更属于分布外的一个例子是，让它们玩桌游（尤其是现代桌游，而非国际象棋或围棋这类经典棋类）。总体而言，像《Lost Cities》或《Dominion》这样的游戏，最先进的模型加 harness 会输给一个桌游水平不错、但从未玩过这游戏的人。如果你去问 agent 这个游戏，它知道很多，能说出一些在不了解这个游戏的人听来很有道理、但在懂的人看来明显是错的话。我最近和一个新玩家玩了几局《Dominion》，他以为用 ChatGPT 帮忙理解游戏会帮自己学会并玩得更好。我对此相当怀疑，并说这大概会让他更差（就我所见，确实如此）。玩了几局之后，我看了下 ChatGPT 告诉他的内容，大约一半对一半错，而错的那一半把他引向了比「一个擅长玩游戏、会用通用游戏启发式的人」更糟的位置。顺便说，公开信息足够多，我认为一个从没玩过的人，如果决定花比如五个小时读读这个游戏、看看有什么资料，很容易就能达到99 百分位或以上（如果允许边玩边查资料，也许只要 30 分钟）。我觉得那很不有趣，也不推荐任何人这么做，但既然 agent 能搜索、能查 API 等等，这恰好显示出今天在应对分布外问题时，人与 agent 的差距。据我所知，下一个大模型发布可能就把局面翻转过来，但今天这个差距还相当大。

   总之，我想说的是：即使在写代码时，你也常会遇到分布外的问题，而 agent 的表现比一个普通人类差得多。今天想要拿到好的整体结果，你需要察觉这些情况并处理它们。 ↩

3. 「直接假定它能用」会出什么问题的例子：这个案例里 agent（有时）严重过拟合测试；这个案例里 agent 严重过拟合某个指标。我听过一种说法：agent 在「评测形状」的问题上作弊更多。我不确定这是不是真的，但即便假定为真——而且我在工作与个人项目里，即使不跑评测，也倾向于造出比多数人更「评测形状」的指令——我也见过那些不造评测形状东西的人，在写下一些指令、让 agent 无监督地放飞时，撞上同样的问题（我认为实际上更严重）。（我自己在极少监督下这么干有过好结果，但前提是把 agent 用围栏圈得相当紧，那反而比我见到的大多数做法更有「评测形状」。）

   当我试用那些把思考外包给 LLM 的人做的软件时，软件存在严重问题。有人告诉我这类做法可行，但软件往往处在一个我会说「按这里讨论的标准它不工作」的水平。

   举个荒唐的例子：我在推特上看到一位「编程思想领袖」宣称编程已经解决了，因为他在各种（编程）领域试了项目，Claude 都能像专家一样解决。我真的去看了他的 GitHub，我看过的所有例子（不是零个）要么跑不起来，要么跑得很糟。我碰到这件事，是因为我在做桌游 AI、正在找现成的 AI 来和我的 AI 对打。他的 AI 是一个 AlphaZero 风格的机器人，比「让 LLM 写一个简单的 minimax 启发式机器人、再让 LLM 循环跑一会儿微调启发式打分」的结果还弱（而对这游戏来说，后者的水平会被一个平庸的 AlphaZero 风格机器人彻底碾压）。

   再举个荒唐的例子：按（一个真实商业产品的）标准流程走，会让你陷入一个技术上可以逃出的死循环（大多数程序员大概能想出怎么逃），但一个典型用户（这软件不是给程序员用的）很可能逃不出来，于是用不了这个软件的主要功能。

   顺便说，我自己做了很多「对我能用就行」的软件——如果它是真实产品，我会评为「基本不能用」，所以我不认为「软件基本不能用」本身是坏事（例如这里讨论的正则引擎，我让 agent 造来加速自己电脑上的 ripgrep；还有这个 Rust 解释器，我让 agent 造来加速某些项目里 agent 的迭代循环——两个你都不该用）。我也在这里说过，让 agent 循环跑数据分析、产出完全错误的结果、然后我指它去修，这件事对我很有价值。但「为自己做一款在你清楚的使用方式下能用、你也知道一旦用错就不行的软件」或「产出你知道是错的、然后你修好」，跟「写了一堆不能用的软件之后宣布编程已解决」，或者把那种质量的东西放进商业产品，是两回事。

   在读了这篇的草稿后，我问这组短想法是否值得发布，Thomas Dullien（即 Halvarflake）说：「好文！对，发布吧，因为每当我说『LLM 并没有解决所有编程问题』，别人看我像看疯子，而我看他们像看疯子。」巧合的是，我写完草稿后看到 Gary Bernhardt 发推：「把实际的 agent 产出和人们在推特上对它们的说法对照，实在太超现实了。日常改动里，我的评审经常把 diff 砍到原来的 25%。大量没用的测试、偏执、逻辑反向。然后我刷推特，看到『编程已解决』」，接着又说：「我发那条推之后一小时内就有一个例子：我让它修一下 DATABASE_URL 的管理。它直接在 npm script 里加 if，还在 CI 里加了一个在内联 JS 脚本上跑的条件式 node 调用。diff 里大概二十处改动。我改正之后：+0 行，+1 个词。」

   我认为任何持有 Thomas 或 Gary 那种态度的人，早就有这种感觉了。有一阵我怀疑，那些对 LLM 生产力叫得最响的人，是不是真的从我认识的人都见不到的方式里获得了大得多的价值；但正如我们这里讨论过的，随着证据增多，我越来越确定：只是这些人在骗自己。桌游这个例子我很喜欢的一点是，你能直接测量产出的 AI 有多强。极端情况下你可以有某种「石头剪刀布」式的局面，观察到 A > B > C > A，但如果某个东西纯粹是 AI 胡说，这一点会以客观的方式相当明显地暴露。商业软件同理：你可以找公司里的人聊，或者自己看数据，发现转化率很低、流失率很高、用户满意度调查显示不满程度很高等等。

   如果你想要另一个荒唐但更不聚焦软件的例子：最近一篇帖子下，有人给我发来一份 ChatGPT 事实核查，配上居高临下的评论，说我犯了错；但当然我早就用 ChatGPT 核查过那篇并改掉了真正的错误，所以剩下的全是 ChatGPT 自己的错误。总的来说，我发现对这类事情（任何人的内容，不只是我的），假阳性率（精确率）很差，假阴性率（召回率）中规中矩。如果你稍微动动脑子，我认为跑这些事实核查仍然值得：让我把一堆假阳性剔掉，仍然比再找一个人类来读草稿便宜得多。

   再一个荒唐例子：tpatcek 最近提到的一个话题——不要让自己被 LLM 的奉承哄得以为自己的某件作品很好（他说的是写作，但这同样适用于其他类型的工作）。如果你有上面 Gary 或 Halvarflake 的态度，这话不必说；但有些人不愿意知道这一点（我认为你必须非常刻意地回避才能不知道），因为我看到有人拿 LLM 对自己作品的吹捧来证明它有多好。也许有一天，LLM 宣布你的作品是天才之作、你的推理彻底击溃了对手的推理会变得可信，但今天我们还离得很远（就准确性而言，这不是对时间距离的预测），所以一个人拿 LLM 对自己作品或推理的吹捧来证明其优秀，主要是「他把脑子关掉了」的标志，也是一个相当强的信号：那件作品或推理很差。 ↩

4. 他那篇帖子里技术上没有提到「人基本上充当 while 循环或 for 循环」这种情况，但那种行为——我越来越常看到——也符合那篇文章的精神。 ↩

5. 也许这对创始人、大股东之类的人成立，但我个人见到的这么做的人，截至目前都是受雇员工或做个人项目的人，他们在表态「这有多好、软件已解决」等等，暗示着「对受雇的软件工程师来说，软件是个已解决的问题」。

   另一个论点可能是「我们都要被淘汰了，那为什么不干脆放弃」，但除非「人类被淘汰」是极近的必然，这个论点在我看来是反的。如果你财务上已准备好退休，你当然可以把脑子关掉——但你一直都可以这么做，而且一直有大量人敷衍了事、什么也不干。如果你还没准备好退休，你可以去做能让你赚更多钱的事，而那大概不包含把脑子关掉。如果是「不会被淘汰」的未来，那也没有特别理由急着赚钱；但如果你认为淘汰很快到来、而你需要赚钱，那现在正是该赶紧赚钱的时候，该做的是把脑子关掉的反面。有一种论证是「何必努力工作或做对的事，反正也不会多拿钱」，这在我看来相当错误：我因为主动发现问题、修好问题而拿到过加薪、奖金等等，这也是我朋友们的经历——除非他们身处一个完全不奖励好好做事的地方，那样他们会离开去别处。

   也许还有一个论证是：「由于惯性，在 LLM 已经强到能取代程序员之后，会有一段窗口期，你可以作为肉体外挂混过去。」现实地看，考虑到公司裁人有多积极，这同样是反的：如果你的目标是把工作量降到最低，那么最好的时机是过去。如果你跟大公司的人聊过这类事，会听到各种故事：有人干脆不来上班（也不远程工作），而开除他们要花几个月甚至几年。最近两年我听到这类故事少了，但我待过的一个团队里有人这么干过，如果我没记错（我以前知道具体数字，但现在不确定记得对不对），在他决定退休、盘算着只要不来上班就能多领几份工资之后，公司花了六个月才开除他（这是疫情前、非远程公司）。我另一个在别的公司的朋友碰到的情况是两年。很长一段时间里甚至没人启动开除流程，然后又是一堆缓慢升级的警告，最后才被开掉。我朋友说，那位经理说，如果他们当时想钻空子，只要开始来上班、装装样子干点活，就会重新起算一个时钟，开除他们会更久。如果是个称职的摸鱼者，按当时的情况可以无限期保住工作。我不确定公司为什么会变成那种状态，但公司似乎正拿 AI 当借口离开那种状态——这让现在以及可预见的近期，成为很久以来最不适合「不花力气、不产出价值还想保住工作」的时期。毫无疑问会有一些公司仍然混得过去，但如果你想什么都不做还领工资，你早就可以那么干了（也许别做到极致、别真的从不去上班），而且那时的环境比不久的将来更容易。 ↩