疯了！我那些怀疑 AI 的程序员朋友，都疯了！网友：越聪明越觉得 LLM 不行

他一直属于大语言模型（LLM）的质疑派，而有意思的是，正因为他对 Python 知识储备极深，他的提示词反而非常简略、疲软，甚至可以说“偷懒”。当然，有些事我还是不敢让 LLM 干，公司生产环境的东西，绝不会让它碰。听我的，用了之后你就会发现，再想靠这种方式 “摸鱼”，心里会更愧疚，最后还是得去干真正重要的活。我编写了大量测试用例，还摸索出一套让 Claude 在过程中记录设计意图的方法——这不仅

程序员的那些事_

684人浏览 · 2025-06-03 18:12:53

程序员的那些事_ · 2025-06-03 18:12:53 发布

关于讨论 AI 编程助手/ LLM 的文章，最近发了几篇：

今天在 HackerNews 看到一篇讨论 AI 辅助编程的文章，再次引爆这个话题了。

早上我刷到这篇文章收藏时也就 600 多个留言，在 18:01 已有 1830 个留言，也是吵得不可开交了。

我那些怀疑 AI 的朋友都疯了

这是一篇关于 AI 辅助编程的诚挚探讨。

科技公司高管们都在强推大语言模型（LLM）的应用，这策略着实不咋地，但我能理解他们的出发点。

我认识的一些聪明人坚信 AI 不过是昙花一现的潮流，就跟当年的 NFT 热潮差不多。我一直不太敢反驳他们，毕竟，人家确实比我聪明。但他们的观点站不住脚，值得好好说道说道。有些极有才华的人，纯粹出于抵触情绪，还在做那些 LLM 早已能出色完成的工作。

就算从今天起，LLM 的发展彻底停滞，它也依然是我职业生涯中第二重要的事物。

重要提醒：我这里只讨论 LLM 对软件开发的影响。至于在艺术、音乐和写作领域，我没啥看法。我倾向于认同这些领域里质疑者的观点，但在我自己的专业领域，我可不信他们那一套。

先自报家门：

从上世纪 90 年代中期起，我就开始搞软件开发了。最开始写盒装的 C 语言代码，还经历过一段不明智的 C++ 时期。写过不少 Ruby 和 Python 工具，也做过一些内核相关的工作，服务器端的 C、Go 和 Rust 代码更是写了一大堆。不管你怎么定义“资深开发者”，哪怕只是在较底层级代码，我都够格。

先统一认知

首先，咱们得达成共识。要是你 6 个月前用 LLM 写代码，结果总失败，那你跟现在大多数用 LLM 辅助编程的专业人士干的压根不是一回事。

如今用 LLM 写代码的人都用智能体（agent）。这些智能体可以自己在代码库里翻找，直接创建文件，运行工具，编译代码、跑测试，还能根据结果调整。

它们还能：

从代码库或线上其他代码库中，提取任意代码到上下文窗口；
运行标准 Unix 工具，在代码库里查找信息；
跟 Git 交互；
运行现有的代码检查工具、格式化工具和模型检查工具；
通过 MCP 执行你预先设置好的各种工具命令。

智能体里真正对代码 “动手操作” 的部分，其实并不是 AI。这点应该能让你安心，它就是些简单的系统代码，跟 Makefile 一样，基于编程的实际需求编写。你花个周末就能写出一个挺好用的编程智能体。它好不好用，更多取决于你对构建、代码检查和测试框架的设计思路，而不是 o3 或 Sonnet 这些模型有多先进。

要是你还在 ChatGPT 页面上提需求，然后把生成的（有问题的）代码复制到编辑器里，那你跟那些 AI 支持者的操作完全不同。也难怪你们总是鸡同鸭讲。

AI 辅助编程的优势

LLM 能写出你需要的大部分枯燥代码，而大多数项目里的多数代码都很无聊。用了 LLM ，你需要上网查的东西会大幅减少，因为它自己就能查资料。最重要的是，它不会累，也不会犯懒。

想想那些你一直想做却没动手的项目。你琢磨过起步的步骤，如果刚好对一门新编程语言感兴趣，可能就开始写代码了。但要是没这动力，这事就会被你一拖再拖，拖一天、一年，甚至整个职业生涯。

一想到新项目里那些繁琐的准备工作、查资料，还有处理依赖关系，我血压都要升高了。但你可以让 LLM 去搞定这些破事。很多时候，它能直接把你带到代码快能跑通的阶段，接下来的开发就只是调整代码，马上就能看到效果变好。这种成就感，就是我写代码的动力。

当然也有不好的一面。有时候有些棘手的活，你不想干，就去重构单元测试，还骗自己说这是正经工作。但 LLM 可不吃这一套，你让它去重构单元测试，智能体就能在虚拟机里花上好几个小时折腾测试，完了还给你提个合并请求。听我的，用了之后你就会发现，再想靠这种方式 “摸鱼”，心里会更愧疚，最后还是得去干真正重要的活。

“但你根本不知道代码写的啥”

你是那种搞 vide conding（氛围编程）的网红吗？连代码都看不懂？如果是，那你说得有点道理。要不是，那你到底咋想的？

不管什么时候，往 main 分支合并代码，你都得对它负责，五年前是这样，以后也一样，用不用 LLM 都没区别。

要是你用 LLM 开发供别人使用的东西，就好好看看代码。实际上，你可能还得花 5 到 10 分钟，把代码改成自己习惯的风格。虽说 LLM 已经开始表现出适应本地代码风格的迹象，但还没完全做到。

有人抱怨 LLM 生成的代码“有随机性”，根本不是这么回事。那就是代码，又不是 Yacc 生成的产物，是能看懂的。 LLM 运行的时候可能有随机性，但这不重要，关键是你能不能理解生成的结果，以及你设置的限制条件管不管用。

阅读别人写的代码本来就是程序员工作的一部分。要是你连 LLM 生成的那些枯燥重复的代码都搞不定，那就是能力问题！那你平时又是怎么处理人类开发者在截止日期前写出来的混乱代码的？

过去一个月左右，我常用 Gemini 2.5。它生成的代码，不修改根本没法合并。我知道肯定有高手能让最先进的模型一次就把功能写好还能直接合并，但我不在乎。我就喜欢自己调整代码，删掉那些蠢兮兮的注释，边改边乐。反正我本来就需要逐行读代码。

“但会出现幻觉啊”

要是“幻觉”问题让你担心，那是你用的编程语言不行。

智能体会做代码检查，会编译和运行测试。要是 LLM 凭空编造了一个新的函数签名，智能体马上就能发现错误，再反馈给 LLM ，它就会“认错”，然后重新生成。

除非你盯着智能体生成的思考过程记录，否则根本不会注意到这种情况。别这么干！这就是我喜欢 Zed 智能体模式的原因，它让你不用管它，自己去忙别的，等它干完了就发个桌面通知提醒你。

我肯定有些环境里，“幻觉” 问题确实还挺严重。但开发者一提到用 LLM ，就把 “幻觉” 挂在嘴边，可这问题其实（差不多）已经解决了。

“但生成的代码太烂了，跟新手写的似的”

实习生一个月就值 20 美元吗？Cursor 就这价格。

作为资深开发者，让能力稍弱的程序员高效工作是你的职责，不管对方是真人还是算法。熟练使用智能体本身就是一项技能，也是个工程，涉及到提示词优化、索引构建，尤其是工具配置。要是生成的代码烂，那是你没引导好。

现在大家可能还搞不清到底是谁在做什么工作。如今， LLM 承担了大量输入代码、查资料、写测试用例，还有编辑 - 编译 - 测试 - 调试的工作。但就算是最抗拒 AI 的资深开发者，也依然把控着筛选、判断、指导和决策的工作。

还有，别再自欺欺人，觉得人类写的第一版代码有多好了。

“但它不擅长 Rust”

想给 Brainfuck 找个好用的工具链也不容易，有些领域就是难搞。

很多人质疑 LLM，可能根本不是针对 LLM 本身，而是在投射自己的想法。有人说“ LLM 不会写代码”，其实心里想的是 “ LLM 不会写 Rust”。这也能理解！但现在很多人选编程语言，都会考虑 LLM 适配得好不好，Rust 开发者真该重视起来。

我主要用 Go 语言开发。我觉得 Go 语言的设计者一开始可能没想把它做成最适合 LLM 处理的语言，但结果它就是很适配。Go 语言有足够的类型安全机制，标准库很丰富，还有重视（往往很重复的）惯用写法的文化，LLM 生成 Go 代码特别顺手。

这么说吧，我也写过一些 Rust 代码，挺喜欢这门语言。要是 LLM 和 Rust 配合不好用，我懂你的感受。但要是你只用这一点来反驳，那咱们说的根本不是一回事。

“但编程是门手艺啊”

你喜欢精致的日本木工活吗？全靠手工工具和榫卯工艺的那种？我也喜欢，但那是业余爱好。

我地下室有个简易木工坊。要是做张桌子，我肯定能从中获得不少满足感。要是做工作台或者烧烤用的桌子，那我肯定自己动手。但要是办公用的普通桌子，我直接买现成的。

职业软件开发者的工作是用代码帮人们解决实际问题，我们日常工作又不是搞艺术创作。乔布斯说错了，我们没必要雕琢那些别人看不见的细节。没人在乎逻辑板上的线路走得好不好看。要是我们开发的东西能一直用下去，肯定不是因为代码写得漂亮。

而且，现实往往不是这样。要是你花时间精心把函数写成优雅、简洁的表达式，那可要小心了，这可能是在“瞎忙活”，真正重要的工作耗尽了你的精力，你现在做的不是开发，而是在自我安慰。

巧了，这正是 LLM 擅长的。它能处理那些繁琐的工作，帮你扫清障碍，让你专注于真正重要的部分，在这些地方，你的判断和价值观才真正起作用。

“但用 AI 写的代码太普通了”

作为一个从业多年的程序员，我现在反而很看重“普通”。要是能轻松写出质量过得去的代码，那简直太幸运了。

我们都会写出普通的代码，普通代码其实也没什么问题。不是所有代码都一样重要，有些代码普通点也无妨。在一个普通的单元测试上花大力气？那肯定是你搞错了，团队领导应该纠正你。

开发者都喜欢吹嘘自己的代码，担心 LLM 拉低了代码质量的“上限”。也许是这样，但它也提高了“下限”。

Gemini 生成代码的下限比我自己写的还高。我的代码看着好看，但考虑得没那么周全。 LLM 生成的代码是很重复，但我自己写的代码里，为了实现代码复用，经常会搞出一些复杂又没必要的写法。

而且 LLM 也不是在所有方面都很普通，它们掌握的算法技巧肯定比你多，基数树、拓扑排序、图归约、低密度奇偶校验码等等。人类总觉得 rsync 很厉害（安德鲁・特里德尔还专门写过论文研究它！），但在 LLM 眼里，这可能跟 SQL 连接查询没多大区别。

不过我好像说远了，其实这都不重要。就算 LLM 只能生成普通的代码，那也意义重大，这样人类就不用写那么多普通代码了。

“但它永远成不了通用人工智能（AGI）”

我根本不在乎。

有些专业人士被 AI 和风险投资制造的炒作氛围搞得心烦意乱，我能理解。但这算不上反驳的理由，东西行不行，跟黄仁勋说什么没关系。

“但它会抢工作啊”

开源软件也抢过工作。以前我们买数据库还得花不少钱呢。

我们这个行业本就是靠自动化取代人力发展起来的，经济学家称之为“提高生产效率”。你明白这意味着什么吧？干同样的活，需要的人更少了。你最近还联系过旅行社代理、场内交易员、唱片店店员，或者暗房技师吗？

每次聊到这个话题，倾向自由主义的风险投资人就开始念叨：就像淘汰点灯人一样，这是创造性破坏，会催生新工作。也许吧，但我可没被忽悠。我完全不知道 LLM 普及后，我们的生活会变好还是变差，情况很可能变得更糟。

LLM 真的可能会取代很多软件开发人员。这不是我们能高高在上评判的事，过去 30 年，技术革新冲击了无数行业，现在轮到我们的工作了。我们又不是东海岸码头工人，靠自己根本挡不住技术进步。

“但它会抄袭啊”

对视觉艺术家来说，人工智能带来的威胁非常大，而且可能还不公平。如果你不是艺术行业的人，可能很难体会这种感受。

我们总以为艺术家整天都在突破创作边界，但实际上，大部分艺术家都在按需求创作，画些合格的插画，设计杂志封面、博物馆展品、动态图像和游戏素材。

LLM 轻轻松松就能达到行业质量标准，这真让人担忧。最气人的是，它们特别擅长批量生产质量尚可的仿制品。我家里有人从事视觉艺术，我都不敢跟他们聊 LLM ，不怪他们，他们的担心可能是对的。

反观软件开发人员，一看到 LLM 生成的代码片段好像抄了 GitHub 上的公开代码，就炸毛了，还担心授权问题。要是你是律师，我听你的。但要是普通开发者拿这个说事，恕我直言，省省吧。没有哪个行业比我们更不把知识产权当回事了。

大多数开发者觉得《星球大战》和蠢朋克乐队的作品都是公共资源。开发者们一直反对任何可能影响盈利性媒体分享网站的保护措施。政策上反对不成，就用强制手段绕过。我们搭建起全球规模的盗版网络，有人想给电视剧保留一个窗口期再上线，都会被我们嘲笑。

你要是敢批评这些现象，马上就会有人跟你扯在 LibreWolf 浏览器上看《苍穹浩瀚》有多难。得了吧，我们都懂，你根本不相信知识产权那一套，那就别再拿知识产权说 LLM 的事了，自己种的因，就承受相应的果吧。

说到底，这都是双重标准。 LLM 对代码的处理比你更深入。要是你觉得字体设计师没资格对字母的边角和弧度主张权利，那你肯定也没理由对红黑树代码这么计较。

再说回优势

几天前我刚开始写这篇文章的时候，专门写了一部分来介绍 LLM 辅助编程的现状。但 LLM 发展太快，一篇文章的保质期还不如一条蓝鳍金枪鱼。你读完这篇文章的功夫，情况可能又变了。

现在的年轻人用的不只是普通智能体，而是异步智能体。他们早上起来，随意给 LLM 布置 13 项任务，然后去泡咖啡、填 TPS 报告、开车去火星奶酪城堡，回头一看通知，已经有 13 个合并请求等着审核了。3 个直接废弃重新生成，5 个跟新手写的一样需要修改，还有 5 个直接就能合并。

“我现在干劲十足，”一个朋友跟我说，“我们团队里那些不用 AI 的人，感觉就像在原地踏步。”他没骗我，他不在旧金山湾区工作，没必要说谎。

当然，有些事我还是不敢让 LLM 干，公司生产环境的东西，绝不会让它碰。但有一次系统出故障，我把 4o（不是 o4-mini，是 4o）的日志发给它，几秒钟它就发现了我们抱怨好几个月的主机上 LVM 元数据损坏问题。在分析 OpenSearch 日志和 Honeycomb 追踪数据方面，我真比不上 LLM 智能体。

让很多朋友不满的是，我不是激进派，也不是未来主义者，我比较保守，相信复杂系统、机构会以一种偶然的方式持续发展，最终回归常态。我就写写 Go 和 Python 代码，不是什么盲目追捧 AI 的人。

但有些变化实实在在发生了，我那些聪明的朋友却不当回事。也许我能说服你，也许不能。但别再给那些站不住脚的观点留空间了。

但我真的听腻了

其实我懂你的感受。我平时看看西蒙・威利森的文章就够了，但现在，每天 Hacker News 首页都有大量关于 LLM 的内容：模型的小更新、用 LLM 创业的公司、教程，还有批判 LLM 的文章，真的很烦！

但 AI 真的【非常】（我认真想过才用这个词）重要。它现在受到的关注，跟 2008 年智能手机差不多，还比不上互联网刚兴起的时候，我觉得这关注度挺合适。

我觉得未来一年，情况会更明朗。那些对“随机鹦鹉”“感觉编程”的傲慢态度，在现实面前撑不了多久。虽然我一直在吐槽这些人，但我之前说的也是真心话：他们比我聪明。等他们放下这种偏见，编写出的智能体会比现在强大得多。

网友留言

先插一下：其实早上那会扫了一眼这篇热文后，小程程想到之前发过一张“疯子”趣图：

jhancock 留言：

我不是怀疑论者，但我对大语言模型（LLMs）始终保持严格控制。

这是一篇很有见地的文章，感谢tptacek（作者）。

我使用大语言模型的场景主要有两个：

繁琐工作：比如开发与领域后端交互的网页；
领域探索：通过模型理解陌生领域的结构。

最近有一次经历，我用 Claude 4 梳理一个大型图模式中的参数。这既属于繁琐工作，也涉及领域探索（毕竟不是我熟悉的图结构，我也不是领域专家）。第一天，Claude 4 发现了其他大语言模型和谷歌搜索都没覆盖的属性和关系，而且真的有效！

但第二天我让它继续工作时，结果开始经不起推敲。我检查了 Claude 的思考过程，发现它竟然“主动”决定编造模式属性，还在报错时用更多虚构的属性生成回退查询。等我发现时，它已经污染了不少代码。虽然大量合理的 Git 提交帮我回滚了代码，但问题没那么简单——这些提交里还包含很多我不想丢弃的有效信息。我花了两天时间仔细梳理代码，提取有用内容再回滚，直到第五天终于整理好代码，记录下所有经验教训。

我相信工具链的持续改进会解决这些问题，但在此之前，必须对大语言模型保持严格控制。

thoughtpeddler

最近我和一个比我“聪明得多”的人一起“氛围结对编程”——至少在编程领域，尤其是 Python 方面，他确实更厉害。他一直属于大语言模型（LLM）的质疑派，而有意思的是，正因为他对 Python 知识储备极深，他的提示词反而非常简略、疲软，甚至可以说“偷懒”。因此，他用 o3 完成我们的任务时，输出结果相当平庸，还出现了一些幻觉（如果他多花几秒或几分钟优化提示词，这些问题本可以避免）。

我对 Python 的了解远不如他，所以会写出更细致的提示词，而 o3 在我的提示下也确实表现得更胜任任务。但我的朋友因为本身知识渊博，对模型的期待值很高，他觉得 AI 应该仅凭几句简单提示就能完成更多工作……然而正因如此，他对模型不可避免的平庸输出产生怀疑（这其实可以理解）。

这就是为什么所有关于“为什么聪明人会质疑大语言模型？”的争论都毫无意义。你越聪明，需要的帮助越少，所以提示词写得越简略，模型获得的上下文越少，输出就越不起眼，聪明人就越觉得大语言模型不行。按照这个逻辑，最聪明的人当然会成为最大的质疑者！

bloat

所以我们把写繁琐模板代码的任务，换成了阅读 AI 生成的繁琐模板代码。这两者花的时间一样长，却让你对代码的理解更少，还更无聊。

mathgorges

根据我的经验，与其说最新一代的大语言模型（LLMs）本身有多强大，不如说将它们集成到程序员工作流中的工具链已经变得非常出色。

这篇文章直到后面几个段落才明确提到这一点，但我认为你引用的这句话其实在暗示：像 Cursor、Cline 等工具在消除开发过程中的繁琐工作方面可能具有革命性意义。

比如，需要进行一项复杂的重构——虽然需求很容易描述，但由于代码分散在整个代码库中而难以实现？让 LLM 处理，然后检查结果即可。因为某个 CVE 漏洞更新了一个软件包，却陷入了依赖地狱？ LLM （通常）能帮你解决。甚至，IDE 的重构工具又一次在重命名函数时出错了？还是可以找 LLM。

不过，我对基于 LLM 的开发仍持怀疑态度，因为我认为当“魔法赚钱机器”（指资本驱动的繁荣）崩溃时，“屎化”（enshitification，指平台从造福用户转向榨取用户）必然会发生。而且我也不打算雇佣一个需要 LLM 辅助才能编程的程序员。但不可否认的是，它确实让我的工作效率大幅提升。以目前的成本，使用它完全是理所当然的选择。