LLM批判有理，但我仍使用

我几乎认同所有大语言模型（LLM）批评者的观点，却依然频繁使用LLM。这话听着像痴人说梦，这种认知失调也时常让我自我怀疑，但我知道有这种矛盾心态的不止我一个。

这周我在柏林参加了Local-First Conf，现场处处弥漫着这种矛盾感。Armin Ronacher刚做完一场题为《构建机器实体》的演讲https://app-2026.localfirstconf.com/schedule/day-2/1130-reflections-on-building-cloud-and-local-hybrid-mac。他是Flask框架的创造者，也是Sentry的早期核心成员，无疑是顶尖的软件工程师。最近他创立了Earendil公司，开发了Pi.dev——一款"开源编码代理工具"。演讲结束后，观众可以通过Discord提问，由工作人员在台上朗读，我问道：

你们接受Pi的PR（拉取请求）吗？或者说，你们如何应对LLM生成的海量PR？

他当着全场观众的面回答，他们几乎会自动关闭所有PR和议题，但这并不意味着大家不该提交PR，因为人类的价值永远会脱颖而出。

看来有这种矛盾心态的不只是我，还有不少聪明的工程师。那些打造LLM协作工具的人，自己正被亲手创造的产物淹没，为了自保只能一键关闭所有自动生成的内容。在他们的目标页面https://earendil.com/purpose/上写着：

在这个飞速迈向AI的世界里，我们相信人类才是最佳的行动主体。

又是一种矛盾。

坐在台下时，我看到很多人都开着Claude Code。而当演讲者发表批判LLM的言论时，台下会响起热烈掌声——包括那些正开着Claude Code的人。

这种矛盾感再次浮现。

我也在这次会议上做了演讲，会后和一些参会者交流，发现他们的感受和我如出一辙，这让我松了口气：原来我不是孤身一人。

于是我写下这篇文章，试图描述这种矛盾心态。我先梳理那些值得掌声、公允且合理的LLM批判观点，再解释我为何仍在使用LLM，最后分享我摸索出的一些使用模式。希望通过具体案例，能让更多人也分享自己的经历，一起更好地理解这种认知失调。

昨日演讲的一些瞬间 📸

@adamwiggins.com @martin.kleppmann.com @stevenruiz.bsky.social @jakelazaroff.com

—— Local-First Conf（@localfirstconf.com）2026年7月13日 下午3:44

LLM的弊端

通过与人交流、听演讲或浏览HN（黑客新闻），我很清楚为什么有些人拒绝使用LLM，而且我几乎认同他们所有的观点！

LLM确实充斥着受版权保护的内容，确实对环境不友好，也确实存在诸多伦理问题。而NVIDIA、OpenAI这类企业形成的资本闭环https://news.ycombinator.com/item?id=45771538，结局注定不会好。这是一个泡沫，迟早会破裂。

我来逐一梳理最关键的几点。

先从最常见的批判说起："LLM产出大量垃圾内容"。

没错，事实就是如此。

看看开源软件领域，越来越多的代码库和项目要么直接拒绝所有类型的贡献，要么设置筛选机制，就像Armin和Earendil那样自动关闭PR。

我认为核心问题在于信任。本来你就不该轻信网络上的陌生人，但在LLM出现前，提交一份规范的PR并附上完整说明，至少需要投入一定的人力时间，这能把恶意捣乱者和低质量提交挡在门外，至少你能在几秒钟内轻松筛选出来。就算是新人提交的内容，你也能相信对方至少花了几个小时，值得仔细看看。

现在这个基础前提不复存在了。任何人都可以注册一个新GitHub账号，让LLM批量生成PR，而项目维护者根本无法轻易判断：对方是花了大量时间打磨代码、只是用Claude写了PR说明，还是完全由LLM自动生成的？像Zighttps://ziglang.org/code-of-conduct/或Gentoohttps://wiki.gentoo.org/wiki/Project:Council/AI_policy这类项目，已经明确拒绝接受LLM生成的PR——但我不认为这是解决办法，毕竟你根本无从判断内容是否由LLM生成。

如果找不到重建信任的方法，LLM可能会严重威胁开源软件（OSS）的生存。或许可以考虑只允许经过验证的小群体贡献代码，比如要求验证者参加线下见面会之类的活动。

再说说初级工程师的处境，这里有两个层面的问题：一是你无法再信任初级工程师代码背后的付出；二是资深工程师失去了培养新人的动力。

先看第一个问题：资深工程师向来会修正初级工程师的代码，而新人也总会写出糟糕的代码（我最烂的代码就是在LLM出现前写的）。但现在，资深工程师在评审时无法判断：新人是花10分钟随便写了点东西，还是真的花了几个小时但能力确实不足。

第二个问题关乎人才培养：过去存在一种平衡——"新人做一些基础工作，资深工程师通过评审代码帮助他们成长"。现在，资深工程师不再需要新人了，至少很多人都认同，基础工作完全可以交给LLM完成。那为什么还要招聘新人呢？

还有地缘政治风险。如果中美突然切断我们对这些技术的访问权限怎么办？就在几周前，美国政府展示了其能力和意愿：切断非美国公民对Anthropic最新前沿模型的访问https://www.forbes.com/sites/anishasircar/2026/06/16/anthropic-disabled-fable-5-and-mythos-5-after-a-us-export-control-order-heres-what-happened/。

Anthropic在2026年6月12日的声明中表示：美国的出口管制指令迫使他们立即向所有客户停用Fable 5和Mythos 5。

我不想危言耸听，但Martin Kleppmann在演讲https://app-2026.localfirstconf.com/schedule/day-1/0930-local-first-in-an-unstable-world中的描述很贴切：

欧美发生冲突的概率仍然很低，但去年这个概率还是零。

最后，即便只是用LLM做研究，它们也会不自觉地融入训练数据中大多数人的想法，甚至有时会带上模型开发者的政治立场。

这就像两个人交谈：时间久了，他们的观点会逐渐趋同。你有没有过这种经历：某个朋友总说一个奇怪的词，几周后整个朋友圈都开始用这个词？LLM的影响也是如此，只不过是观点层面的趋同。

而这场对话的参与者之一，并非人类。

LLM的价值

但我们已经无法彻底摆脱LLM了。它们已经到来，且会长期存在。与其逆流而上，不如顺势而为，同时加以控制和引导。

比如确保模型可以在本地笔记本电脑上运行。这类模型的性能正在提升，能让程序员不再依赖大公司。当补贴结束、价格上涨时，开源权重模型会牵制大型厂商。而且在本地硬件上运行的模型，不会被任何政府突然切断访问。我甚至认为，当泡沫破裂时，全球经济会遭受重创，很多公司会倒闭，但开源权重模型不会消失，程序员可以依靠它们继续工作。就连这次会议上，涉及AI的演讲也都认真对待本地模型。

想象一下：科幻作品里那种后台运行的AI，你随时可以向它提问，它总能给出回答——就像《星际迷航》里那样。

在很多演讲中，AI只是一笔带过："我们用Claude Code构建了这个工具"。有些演讲者甚至直白地说"我直接把活交给Claude Code了"，但他们的演讲不仅被接受，还赢得了包括资深业界人士在内的全场掌声。

关键在于，有人类为成果背书。这才是让你愿意倾听的原因。如果他们展示的是AI生成的垃圾内容，会损害自己的信誉。我认为这让他们对AI的使用方式有所不同。他们说"我让Fable 5实现这个功能"，听起来像个科技狂热者，我自己也会这么描述。但我猜测（也只能代表自己）：他们并没有让LLM替自己思考，而是用LLM强化和加速自己的想法。

LLM是放大器，放大你已有的东西：观点、结构、框架。如果你有想法，LLM能让它们更清晰、更快速地呈现。它们擅长辅助头脑风暴、检查语法、优化语句、提供备选方案，还能充当橡皮鸭（调试搭档）或唱反调的人。如果你毫无头绪，LLM也会流畅地产出一堆空洞内容——那些看起来不错，但没人愿意在观众面前读出来的内容。

对我而言，LLM的价值在于：它能让我产出比独自工作时质量更高的成果。我能用它完成更多事，但我选择用它"少做而精"https://nolanlawson.com/2026/05/25/using-ai-to-write-better-code-more-slowly/。我会消耗大量token，只为打磨几句给人看的话。我认为这是LLM的合理用法，而且我发现LLM能"辅助思考"https://www.theocharis.dev/beliefs/。

我坚信书面文本应该是人与人之间的交流，但我依然用LLM写所有东西，这并不矛盾。区分"AI垃圾内容"和"优质写作"的关键，在于背后是否有人类的思考。而"思考无法外包"https://paulgraham.com/writes.html。

但问题在于：外人无法判断内容背后是否有人类思考。"我用AI更好地思考"这句话，从我嘴里说出来和从某个AI狂热者嘴里说出来，字面上完全一样，你根本无法仅凭这句话判断是不是空话。你做不到这一点。因为被放大的空话听起来也像真知灼见，最后只剩下信任。而信任难获易失，在LLM时代更是如此。我自己就有这种感觉：一个多余的破折号，都可能让我质疑整个内容——难道这个人连AI生成内容的明显痕迹都懒得删掉吗？

在会议的Discord频道里，有人提问如何应对这种矛盾：很多关注本地优先（local-first）理念的人也强烈反对LLM，用LLM开发软件会不会担心被社区排斥？有人回答，包括当时正在演讲的嘉宾在内，很多人都对此有"复杂的想法"。这很能说明问题：即便在这里，人们也不敢公开承认自己在用LLM。我自己也有点害怕说出来：上个月我在token上花了近1万美元，听起来简直疯了。

这是我2026年6月按模型统计的token支出（单位：美元），直接来自支出报告。我知道这太夸张了，后来做了两处调整：现在只在特定场景下使用Fable，它太贵了；纯代码任务则用OpenRouter和更便宜的模型，比如GLM 5.2。

AI刚出现时，我曾因滥用它损害了自己的信誉。后来我意识到，信誉是赢得信任的关键：你愿意站在观众面前把内容读出来吗？如果答案是"我得先解释一下内容的意思"，那就是垃圾内容；如果你能一字不差地读出来，且毫不羞愧，那就是优质内容。

我摸索出的一些使用模式

我是怎么用LLM的？这里有一条难以言说的微妙界限，只能通过开放心态使用工具去体会。我知道这句话听起来像科技狂热者的论调，甚至邀请你尝试的话都会显得和他们一样。所以我试着描述一些我摸索出的模式，不是为了说"就该这么做"，而是希望能澄清这种矛盾的处境。

如果LLM不理解实际问题和需求，肯定会写出糟糕的代码。但只要掌握正确的技巧和工具，也能产出不错的软件。但你和优质软件之间隔着一道坎：LLM不会告诉你它没听懂，只会硬着头皮继续做。这就是为什么脱胎于Matt Pocock"拷问我"技巧https://www.aihero.dev/my-grill-me-skill-has-gone-viral的/grill-me指令如此强大。指令非常简短：

针对这件事的各个方面反复拷问我，直到我们达成共识。逐一梳理决策树的每个分支，逐个解决决策间的依赖关系。每个问题都给出你的建议答案。
一次只问一个问题，等我反馈后再继续。一次问多个问题会让人困惑。
如果能通过探索环境（文件系统、工具等）找到答案，就自己去查，不要问我。但决策由我来做——每个决策都要先问我，等我回答。
在我确认我们达成共识前，不要采取行动。

说实话，这种"拷问"体验很好。当我发现这个技巧时，简直兴奋不已：这么简单的指令，效果居然这么好。因为它会逼着你一步步理清自己的想法。从那以后，我把这种循序渐进的方法应用到所有事情上——包括写文章时，花大量token打磨一句话。比如这篇文章，我先随意写下想法，再逐句让LLM"拷问"我。

每次写代码，哪怕是小事，我都会遵循Basecamp的"Pitch"方法https://basecamp.com/shapeup/1.5-chapter-06，认真构思简短的"问题""交付内容""不交付内容"。我强迫自己写三句话的问题陈述。用LLM填内容非常容易，但要写好却无比困难。这种方法在LLM工作流中效果极佳，恰恰因为它是为人类设计的：三句话的长度会逼着我去读，既然我能读，别人也能读。

现在我基本不会通读LLM的输出，只是快速浏览，看看是否符合我的思路。但三句话的问题陈述，我会认真核实。这就像代码评审：1000行代码的评审可能只得到一句"通过（LGTM）"，而100行代码的评审会收到15条评论。

我在PR描述上也花了很多时间，确保内容易读、简洁，始终说明实际问题、交付内容和不交付内容，还会附上功能正常运行的截图，让评审者一眼就知道这个PR值得关注，因为它确实能正常工作。但我总得和Claude较劲，它总喜欢往描述里加冗余内容。如果不是重要的PR，有时我会妥协。

你需要一些方法来对抗LLM生成的海量内容。在我的编码工作流中，我会加入一些小型代理来平衡这种情况。

我还喜欢另一种技巧（"Ralph Wiggum循环"https://ghuntley.com/ralph/，或者现在更常用的Claude"ultracode"https://code.claude.com/docs/en/workflows）：用一段文本、计划、声明或代码锁定LLM，不断生成子代理（拥有全新上下文的LLM），唯一任务就是挑上下文的毛病。直到它们开始编造问题，我才继续后续工作。

当它们被迫编造问题时，你反而可以利用这个弱点：它们想附和你说内容有问题，却根本找不到任何问题。

尤其是结合/grill-me技巧使用时，最终结果会让你——作为人类——再也没有任何意见或想法，哪怕是最微小的念头。LLM会试图挑你的想法的毛病，有时会"拷问"你好几个小时，逼着你理清自己的思路。

甚至可以利用LLM的编造特性：在去年的会议上，Anselm Eickhoff介绍了如何让LLM先编造它预期的API或用户体验https://www.youtube.com/watch?v=e3-yIWGNBLQ，再展示真实的设计。它猜的内容很可能就是大多数人会想到的。与其对抗编造，不如利用它：低成本测试你的设计是否符合用户预期。我把这个方法做成了一个工具https://gist.github.com/JeremyTheocharis/83c76da5a10bcf495d4298c70fee91b4，你可以试试。

我的intuition-probe工具：一个"盲代理"在看到真实设计前就确定它预期的设计。可从gist免费获取

所有这些模式都有一个前提：我必须能判断结果是否优质。使用LLM越多，我接触不熟悉领域的机会就越多，这时就需要专家帮忙。因为我只有理解了才能编程，就像"委派任务"https://www.theocharis.dev/beliefs/：只有我至少了解任务的基础知识、知道什么是优质成果时，才会把任务交给团队成员。对LLM也是如此。

如果我对某个领域非常熟悉，能快速区分"优质"和"垃圾"。如果不熟悉，我只用LLM帮助自己学习。因为如果在无法区分好坏时就用LLM，只会产出一堆垃圾。

学习分为两种情况，取决于成果是否有明确的好坏标准。这里的好坏指：代码能编译或不能，测试用例通过或不通过，协议能解码或不能——不是指"代码质量高"这种主观判断。在有明确标准的领域，你可以借助LLM一起学习。会议上有个人说，他用Opus 4.6逆向工程二进制文件和协议，只需要具备基础的逆向工程知识就行：要么打补丁后的二进制文件能正常工作，要么会把设备搞坏。结果对错一目了然，他甚至能摸索出自己的技巧。

在主观性较强的领域，比如编程风格，LLM只会告诉你大多数人的偏好：最流行的技术，但可能并不适合你的情况。

我们团队曾有过一次讨论，有人说某段代码是AI生成的垃圾，是普遍的AI问题。深入探讨后才发现，他们只是不喜欢测试驱动开发（TDD）。但我们团队里有个人在LLM时代之前就一直在做TDD。突然之间，"AI垃圾内容"的指责就不再是针对AI，而是人类之间的观点分歧了。正如我所说，LLM只会放大。有了LLM，你可以放大自己的观点。这种情况下需要人类的帮助：给你大致的方向，提供好的初始观点，直到你能独立前行。

我不是孤身一人

我希望你能信任我，也完全理解你可能不信任。你真正了解我的唯一方式是关注我的内容，但这需要花费大量时间，所以我理解你可能不会这么做。但如果你读到了这里，说明你已经花了不少时间看这篇文章，或许你已经能感受到我投入的精力，知道这不是那种一眼就能看穿的垃圾内容。

有这种矛盾心态的不止我一个。

独自写作时我并没有意识到这一点，但在写作过程中，我翻了会议的Discord记录，直接问了参会者，还浏览了过去几周的HN文章，发现其他人也在描述同样的矛盾感。或许其他人也可以分享自己的经历和学习路径，来厘清这条微妙的界限。

在这一切背后，LLM确实有真正的价值。不是炒作，而是一个能丰富你思考的好工具。但它永远无法取代你的思考。

去试试吧。我知道，这听起来完全像科技狂热者的话，但我找不到别的说法。

感谢Local-First Conf的所有参会者，你们的分享让我大开眼界。