LLM 批评有据,我仍在使用
作者承认 LLM 批评者的顾虑合理,但在实际工作中继续使用 LLM,呈现实用主义与理想之间的平衡思考。
作者承认 LLM 批评者的顾虑合理,但在实际工作中继续使用 LLM,呈现实用主义与理想之间的平衡思考。
我几乎赞同所有对 LLM 的批评,但我依然频繁使用 LLM。我知道这听起来像是在自欺欺人,而且这种认知失调有时也确实让我产生这样的感觉,但我认为有这种感受的不止我一个人。
本周,我参加了在柏林举行的 Local-First Conf,这种认知失调随处可见。Armin Ronacher 刚刚做了一场关于构建机器实体的演讲。他创造了 Flask,也是 Sentry 早期团队的成员之一,所以显然是一位优秀的软件工程师。不久前,他创办了 Earendil,该公司正在开发 Pi.dev——一个“开源编程智能体框架”。演讲结束后,观众可以通过 Discord 提问,问题会在台上被大声念出来。我问道:
你们接受向 Pi 提交的 PR 吗?或者说,你们如何应对 LLM 带来的海量 PR?
他当着全场观众的面在台上直接回答说,他们会自动关闭几乎所有 PR 和 issue。但大家不应该因此不敢提交 PR,因为人类的特质总会显露出来。
所以,不只是我,显然一些相当聪明的工程师也有同样的感受。那些构建 LLM 协作工具的人,如今也被自己创造出来的东西淹没了;为了保护自己,他们选择将其全部自动关闭。他们的宗旨页面上写道:
在这个飞速奔向 AI 的世界里,我们相信人类才是最好的智能体。
当我坐在观众席时,可以看到很多人都开着 Claude Code。随后,演讲者会说出这些批评 LLM 的话,而台下则会爆发出热烈的掌声。甚至那些开着 Claude Code 的人也在鼓掌。
又一次出现了这种认知失调。
我自己也在那场会议上做了演讲。后来和一些参会者交流时,他们描述的感受与我非常相似。这让我松了一口气,因为我知道有这种感受的不止我一个人。
所以,这篇文章就是我尝试描述这种感受的过程。我会先逐一讨论使用 LLM 时那些公平且合理的担忧,也就是那些会赢得热烈掌声的观点。然后,我会解释为什么自己仍然在使用 LLM。最后,我会总结一些自己观察到的模式,希望通过提供具体示例,让其他人也能参与进来,分享各自的经历,从而让我们共同更深入地理解这种认知失调。
昨天演讲现场的一些照片 📸
@adamwiggins.com @martin.kleppmann.com @stevenruiz.bsky.social @jakelazaroff.com
通过听人们讨论、听演讲以及阅读 HN,我想自己已经相当清楚为什么有些人拒绝使用 LLM。而最奇怪的是,我几乎赞同他们提出的所有观点!
它的训练数据里充斥着受版权保护的材料,是的。它对环境有害,是的。所有那些伦理问题,也确实存在。而 NVIDIA、OpenAI 以及资本之间这种相互炒作、资金来回流转的圈子,最后不会有好结果。这就是一个泡沫,而且必然会破裂。
接下来,让我逐一讨论其中最主要的几个问题。
先从最常见的批评开始:“LLM 会制造大量垃圾内容。”
是的,确实如此。毫无疑问。
观察开源软件,你会发现越来越多的代码仓库和项目要么直接拒绝一切形式的贡献,要么尝试在前面设置某种过滤机制。就像 Armin 和 Earendil 所做的那样,自动关闭收到的内容。
我认为这里的核心问题是信任。无论如何,你本来就不应该信任互联网上的陌生人。但在 LLM 出现之前,至少存在这样一个基本门槛:要创建一份格式规范、描述完整的 PR,至少需要投入一些人的时间,因此这能够挡住恶意捣乱者和低质量提交。或者至少,你可以在几秒钟内轻易把它们筛掉。所以,即使来了一个新人,你也可以相信这个人至少在这件事上花了几个小时。这样一来,这份提交通常就值得你仔细看一看。
如今,这个基本前提已经不复存在。任何人都可以随手创建一个新的 GitHub 账号,然后放任自己的 LLM 四处行动。作为维护者,你无法轻易判断提交者究竟是否在 PR 上投入了大量时间——也许只是在撰写 PR 描述时使用了 Claude——还是这根本就是一台自行行动的 OpenClaw 机器。Zig 或 Gentoo 等项目已经拒绝接受由 LLM 生成的 PR(但我认为这并不是解决方案,因为你到底要如何判断呢?)
我认为,如果我们找不到恢复这种信任的方法,LLM 很可能会对 OSS 造成致命打击。一种办法或许是,只允许一小群经过验证的人为项目做贡献;而要获得验证,则需要参加线下聚会之类的活动。
接下来还有初级工程师的问题。这里实际上包含两个不同的方面:a)你无法再相信初级工程师在代码背后付出的努力;b)资深工程师不再有动力教导初级工程师。
先说 a):资深工程师一直都会纠正和修复初级工程师的代码,而初级工程师也一直会写出一些相当糟糕的代码(我自己最糟糕的代码就写于 LLM 出现之前)。只不过现在,当资深工程师进行代码审查时,已经不知道这个初级工程师究竟是用 10 分钟凭感觉编程搞出来的,还是确实坐在那里花了几个小时,只是真的缺少一些关键洞见。
再说 b),也就是教学问题,换句话说:“我们该如何培养新人?”过去存在这样一种平衡:“初级工程师负责一些相当枯燥的任务,而作为交换,资深工程师会和他一起审查这些任务,并帮助他成长。”如今,作为资深工程师,你已经不再需要初级工程师。至少我发现很多人都认同一点:这些枯燥的任务完全可以外包给 LLM。那么,为什么还要雇用初级工程师呢?
此外,还有地缘政治紧张局势。如果中国或美国一夜之间切断我们使用这些技术的渠道,会发生什么?就在几周前,美国政府已经表明,它有能力、也愿意阻止非美国公民使用 Anthropic 最新的前沿模型。
我并不想在这里危言耸听。我认为 Martin Kleppmann 在演讲台上对此描述得非常到位:
欧洲与美国发生冲突的概率依然很低。但在去年,这个概率还是零。
最后同样重要的是,即使你只是使用 LLM 做研究,它们也天然倾向于悄无声息地将训练材料中占多数的思想,甚至有时是模型创造者的政治立场,夹带进结果中。
这就像两个人彼此交谈:随着时间推移,他们的观点会慢慢趋同。你是否注意过,某个朋友总是反复使用一个奇怪的词,几周之后,整个朋友圈都开始使用这个词?观点的传播也是这样。
只不过这场对话中的一方并不是人类。
但我们已经不可能让它们彻底消失了。它们已经到来,而且会一直存在。与其逆流而行,不如顺流而下,并在这个过程中对它加以控制和塑造。
例如,确保模型能够在你的笔记本电脑上运行。本地模型已经越来越好,它们能让我们程序员摆脱对这些大型公司的依赖。当补贴结束、价格上涨时,正是开放权重模型能够制约大型供应商。而且,任何政府都无法在一夜之间切断你在自有硬件上本地运行的模型。我甚至认为,当泡沫破裂时,世界经济将遭受巨大损失,许多公司也会倒下。但开放权重模型不会消失,因此我们程序员仍然可以退回去使用它们。即使在这次会议上,那些讨论 AI 的演讲也大多认真对待了本地模型。
想象一下:你拥有这样一个在后台运行的科幻式 AI,可以随时向它提问,而它也总会回答你。就像《Star Trek》里的场景一样。
在许多演讲中,AI 只是被顺带提及:“我们用 Claude Code 构建了这个。”有些演讲者甚至公开表示:“是啊,我只是把它交给了 Claude Code。”但他们的演讲仍然获得了会议的接纳,也赢得了观众的热烈掌声,其中包括一些资历深厚、备受尊敬的人。
最重要的是,有人类愿意拿自己的信誉为这些成果背书。正是这一点让你愿意听下去。如果他们展示的是 AI 制造的垃圾内容,就会失去自己的信誉。我认为,这会让他们以不同的方式使用 AI。他们会说:“我只是让 Fable 5 实现了它。”这听起来就像一个科技兄弟会说的话。我自己也会完全用同样的方式来描述。不过这只是我的猜测,我也只能代表自己:他们并没有让 LLM 负责思考。那仍然是他们自己的思想,只不过如今被大幅增强,仿佛磕了药一样。
LLM 放大你已有的东西:观点、结构、框架。如果你有想法,它们就会更清晰、更快速地呈现出来。它们在头脑风暴、检查语法、迭代句子、提供替代方案、充当橡皮鸭或魔鬼代言人时表现出色。如果你什么都没有,就什么都出不来,只是流畅得很。LLM 擅长生成大量看起来不错的内容,但没人会在观众面前大声朗读。
对我来说,价值就在这里:我可以简单地让事情质量比我单独完成时更高。我可以用它做更多事情,但我用它来让更少的事情质量更高。我倾向于消耗极端数量的 token,仅仅是为了准备几句话供一个人类使用。我认为这是对 LLM 的好用法。而且我发现 LLM 确实可以支持你的思考。
我强烈同意书面文本应该来自人类对人类的交流。但我仍然用 LLM 来写我所有的文本。我不认为这是矛盾的。区分「AI 垃圾」和「好文章」的是一个人类是否投入了思想。而你不能把思考外包出去。
但这里有个问题:一个人类是否投入了思想,正是你从外部看不出来的东西。「我用 AI 来更好地思考」这句话,从我嘴里说出来和从某个随机的 AI 科技大佬嘴里说出来,字面意思完全一样,而你无法根据我说的话判断这是否是胡说八道。你根本无法判断。由于放大的废话听起来像天才之语,剩下的就只有信任了。而信任很难获得,也很容易失去。特别是在 LLM 的时代。我自己看到过:一个破折号似乎就能让整个东西失效,因为我发现自己在想,这个人难道不想至少删除一些明显的 AI 垃圾迹象吗?
在会议的 Discord 中,在其中一场演讲期间,有人问其他人是如何处理这种紧张关系的:很多政治上关注「本地优先」的人也坚定地反对 LLM。他们知道用 LLM 写软件可能会被社区拒绝,这会让他们担心吗?有人回答说,包括那时在舞台上的演讲者在内的许多演讲者都在说关于这个问题的「复杂想法」。我觉得这很说明问题:即使在这里,人们也害怕大声说出他们使用 LLM。我也有点害怕说这个:上个月我花了将近 1 万美元的 token。听起来太疯狂了。
当 AI 还很新颖,我在尝试它的时候,我一定程度上毁了自己在这方面的信誉。但随后我意识到,信誉就是你赢得信任的方式:你会站在观众面前大声朗读它吗?如果答案是「嗯,我会解释它的意思」,那就是垃圾。如果你真的会一字一句地朗读它,而不为此感到羞愧:恭喜,这就是一篇好文章。
那么我是怎么用它们的呢?有一条无法解释的细微分界线,很难描述,我认为它只能通过经验来学习,通过带着开放的心态使用这些工具来学习。我知道这句话听起来怎样。这正是科技大佬会说的。我甚至无法邀请你尝试它而不显得像他们。所以我会尝试描述一些我发现的模式。不是作为「这是如何做的」指南,而是希望澄清这一情况。
是的,如果它不理解实际问题和需求,它会编写出坏软件。有了正确的技能和工具,你可以生成一些相当不错的软件。但在你和那份不错的软件之间,存在着讨好的问题:它不会告诉你什么时候它没有理解什么,只是继续前进,做一些东西。这也是为什么 /grill-me skill(改编自 Matt Pocock 的「grill me」技术)非常强大。它非常简短:
Interview me relentlessly about every aspect of this until we reach a shared understanding. Walk down each branch of the decision tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
Ask the questions one at a time, waiting for feedback on each question before continuing. Asking multiple questions at once is bewildering.
If a fact can be found by exploring the environment (filesystem, tools, etc.), look it up rather than asking me. The decisions, though, are mine — put each one to me and wait for my answer.
Do not act on it until I confirm we have reached a shared understanding.
老实说,grill-me 感觉不错。当我发现这个 skill 时,我对这样简单的东西竟然能有这么大的影响感到非常兴奋。因为它迫使你逐个问题地形成自己的想法。从那以后,我为所有事情都采用了这种逐步方法,这种在单句话上花费极端数量 token 的方法,比如写文章。这篇文章是我混乱地写下我的想法,然后逐句地让 LLM 批评的结果。
每当我编写代码时,即使是小事,我也遵循 Basecamp 的「Pitch」方法,真的、真的非常努力地思考一份简短的「问题」、「我们在交付什么」、「我们不在交付什么」。我强迫自己写一个三句话的问题陈述。填充这些框非常容易,用 LLM 甚至更容易。但让它变好非常困难。我认为这在 LLM 工作流中之所以有效,正是因为它是为人类设计的:三句话强迫我真的去读它们。而如果我读了它们,另一个人类也可以读它们。
我现在倾向于不真正阅读大多数 LLM 输出;我扫一眼,检查我是否对它有感觉。但三句话的问题陈述,我会非常努力地进行事实核查。这就像代码审查:一份有 1000 行代码的审查得到「LGTM」。一份有 100 行的审查得到 15 条评论。
同样的关注也进入了我的 PR 描述:我花费大量时间来确保它们保持可读性,简洁明了,并总是描述实际问题、我们在交付什么和我们不在交付什么。我还添加了它工作的截图,以给审查者一个明显的迹象,表明这个 PR 值得与之互动,因为它显然可以工作。但我必须总是与 Claude 争执描述,因为它不断地向其中添加垃圾。有时如果不是一个重要的 PR,我就在那里让 Claude 赢太多。
你需要一些对策来对付它们产生的大量东西。在我的编码工作流中,我加入了较小的智能体来反制那些。
另一个我喜欢的技术(Ralph Wiggum 循环,或更现代的 Claude 的 ultracode)是用文本或计划或陈述或代码或任何东西锁定 LLM,并不断产生子智能体(具有新鲜上下文的 LLM),其唯一任务是撕裂上下文。他们一直这样做,直到被迫产生幻觉。只有那样我才继续工作流。
如果他们被迫产生幻觉,你实际上可以利用他们的弱点:他们试图让你同意其中存在问题,但他们找不到任何问题。
特别是如果你将它与 /grill-me skill 结合起来,你最终会得到一个结果,其中你作为人类没有进一步的评论或想法,甚至没有最微小的想法。LLM 也试图撕裂你的想法,有时甚至对你挑剔了几个小时,并迫使你形成自己的想法。
甚至有一种方法来使用幻觉本身:在去年的会议上,Anselm Eickhoff 描述了你如何可以让 LLM 幻觉 API 或它期望的 UX,然后才向它展示真实的东西。无论它猜测什么,可能都是大多数人类也会猜测的。所以与其与幻觉对抗,你不如利用它:作为你的设计是否符合人们期望的廉价测试。我也为这个构建了一个 skill,如果你想尝试的话。
不过,所有这些模式都有一个要求:我需要能够判断结果是否好。而我使用的 LLM 越多,我最终涉及的领域就越多是我不太了解的。然后我需要专家。因为我只能在理解的情况下编程。这就像委派:我只有在至少理解基础知识并知道什么是好的情况下,才会向我团队的另一个成员委派任务。对 LLM 也是一样。
如果我非常了解某些东西,我可以快速分辨「好」和「绝对垃圾」。如果我不太了解某些东西,我只用 LLM 来帮助我学习它。因为如果我在无法区分好坏时使用它们,我最终会得到彻底的垃圾生产。
根据结果能否被明确区分为好或坏,学习有两种方式。这里的好或坏是指:代码能否编译、测试套件是否全部通过、协议能否解码。而不是“代码好不好”,因为代码质量是另一回事。在那些有明确检验标准的领域,你可以让 LLM 直面这个标准,和它一起学习。会议上有个人讲述了他如何使用 Opus 4.6 对二进制文件和协议进行逆向工程,而他唯一需要的只是逆向工程的基础知识。他修补后的二进制文件要么能正常工作,要么会让设备变砖。结果是否正确一目了然,因此他甚至能在这个过程中摸索出自己的技术方法。
在编程这类充满不同观点的领域,LLM 只会告诉你大多数人想听的答案:最流行的技术,而它对你的具体情况来说未必是最好的选择。
有一次,我们在团队里讨论,有人说某段代码是 AI 垃圾,而且认为这是 AI 普遍存在的问题。深入讨论后才发现,他们其实只是不喜欢 TDD。但我们团队里还有另一个人,早在 LLM 出现之前就已经大量使用 TDD。于是,AI 垃圾突然不再是 AI 垃圾的问题,而是人类持有不同观点的问题。正如我之前所说,LLM 只会放大。有了它们,你可以放大自己的观点。在这里,你需要人类大致为你指出正确的方向,并为你提供一些良好的初始观点;你先以这些观点为基础,直到自己有能力继续前行。
我希望你能信任我;如果你不信,我也完全理解。真正了解我的唯一方式,是深入接触我创作的内容,但这需要投入大量时间,所以你不愿意这样做,我也能理解。不过,如果你读到这里,就已经在这篇文字上投入了相当长的时间。或许你已经看得出来,我为这篇文章付出了大量心血,它并不是什么显而易见的垃圾内容。
并非只有我感受到了这种矛盾。
仅靠写作本身,并没有让我意识到这一点。但在写作过程中,我浏览了这场会议的 Discord,直接询问了参会者,还阅读了过去几周 Hacker News 上的文章。这让我发现:还有其他人也在描述同样的矛盾。或许其他人也可以分享自己的经历和学习路径,帮助我们厘清这条微妙的界线。
这一切之中,确实存在一些非常好的东西。不是那些炒作,而是一种真正出色、能够丰富你思考方式的工具。不过,它永远无法取代你自己的思考。
去吧,亲自试试看。我知道,这恰恰是科技圈兄弟会式的人会说的话。但我实在找不到别的表达方式。
感谢 Local-First Conf 的所有人。你们带来的海量信息让我的大脑彻底炸开了。