从 1990 年代中期就开始从事软件开发的 Thomas Ptacek 写了一篇文章，字里行间透露出一种近乎无奈的挫败感。他精准捕捉了一个经验丰富的程序员在网上试图为“LLM 其实真的很有用”辩护时所感受到的孤立与无力。他写道：

在我认识的顶尖聪明人里头，不少都坚信 AI 只是一时得势——可以说是 NFT 热潮的又一个翻版。我一直不想反驳他们，因为人家确实比我水平高。但他们的论点却并不严肃，甚至可以说站不住脚。有些聪明人其实是心里不想承认，自己的很多工作已经可以被大模型替代乃至完成得更好。

简单来讲，哪怕大语言模型的发展就到目前的水平止步，那它也足以成为我整个职业生涯中亲身见证的第二大技术突破。

Thomas Ptacek 给这篇文章取名为《我那群怀疑 AI 的朋友，都疯了》，一半是吐槽，一半是真情流露。

但问题在于，“疯子”到底是谁？

对支持者来说，疯子是那些到了 2025 年还拒绝使用 AI 辅助开发的人。无独有偶，一位来自 TextToSlides.AI 的工程师在博客中写道：

昨天我看到一个场景让我当场愣住：一位同事坐在工位前，一行一行敲代码，没有 Copilot 自动补全，没有 ChatGPT 标签页，就那样……纯手打。2025 年了，还这样写代码？

一开始我以为他的 AI 工具坏了，后来才发现——他是故意不用。这让我开始重新思考整个现代软件开发流程。

——像个“精神病（Psychopath）”一样写代码。

但在反对者眼中，疯子则是那些一头扎进 AI 幻觉的人，一位 Hacker News 用户写道：

事情早就已经超出了炒作阶段，而现在去嘲笑那些一路上提出警告的怀疑论者“疯了”，本身才是疯了。

Thomas Ptacek 的这篇文章发布仅两小时，就在 Hacker News 上引发了近 700 条讨论（如今已接近 1500 条），很可能成为 AI 编程话题的讨论热度新高点。评论区中支持和反对的声音依然泾渭分明。

支持者认为，AI 工具已经在实际开发中带来了实打实的效率提升。比如 Simon Willison 就提到了 Cloudflare 的 Kenton Varda。后者仅用几天时间，就借助 AI 构建了 [cloudflare/workers-oauth-provider] 这个库 —— 如果手写，可能得几周甚至几个月。当然，这本身就是一个非常理想的用例场景：成熟平台、明确标准、清晰 API。但更关键的是，当 Kenton 要进入陌生而复杂的代码库时，AI 成为了他敢于上手的“心理支点”：能快速带他熟悉结构，降低入门门槛，而不是像以前那样宁愿找熟人帮忙也不敢动。当然他也坦言，真正修改 Cloudflare Workers Runtime 本身时，AI 并没有帮上太多忙。

与此同时，反对派的声音也毫不含糊。一位有着 25 年开发经验的自由软件开发者说：

我在不少知名公司做过，但这些 AI 的东西，我完全不碰。在我看来，它们就是一堆人工智能生成的垃圾。我不想看，不想用，也不愿和它们打交道。

为了更全面理解 Thomas Ptacek 的观点，我们翻译了他这篇文章的全文。你可以在下文中看到他对 AI 编程的焦虑与挣扎。

我那群怀疑 AI 的朋友，都疯了

科技企业的高管们正在强制推行大语言模型（LLM）。虽然承认这事让人不爽，但我能理解他们为什么这么做。

在我认识的顶尖聪明人里头，不少都坚信 AI 只是一时得势——可以说是 NFT 热潮的又一个翻版。我一直不想反驳他们，因为人家确实比我水平高。但他们的论点却并不严肃，甚至可以说站不住脚。有些聪明人其实是心里不想承认，自己的很多工作已经可以被大模型替代乃至完成得更好。

简单来讲，哪怕大语言模型的发展就到目前的水平止步，那它也足以成为我整个职业生涯中亲身见证的第二大技术突破。

重要提示：这里我只讨论大模型对于软件开发的影响。至于绘画、音乐和写作，我可说是一无所知。这些领域的怀疑论者可能是对的，但至少在编程层面，我投大模型一票。

先介绍一下我自己：我从上世纪 90 年代中期就开始从事软件开发工作，最开始编写的是整齐严谨的 C 代码。后来经过一段时间的 C++ 开发，我又转投 Ruby 和 Python 的怀抱，同时也做过一些内核开发的工作。对了，我写大量服务器端的 C、Go 和 Rust 代码。无论大家如何定义“真正的开发者”，包括底层代码编写，我肯定都符合这个标准。

开宗明义

首先，我们需要达成共识。如果大家是在半年之前尝试用大模型来编写代码却发现不太行（或者用的是两年之前的 Copilot），请相信我，如今严肃程序员们能够从大模型辅助编程中得到的支持已经远不可同日而语。

现在，使用大模型的程序员们已经用上了智能体。智能体可以自行浏览代码库，它们能够直接编写文件、运行工具、编译代码、运行测试并且迭代结果。更可怕的是，它们还可以：

从代码树或其他在线代码树中，将任意代码纳入其上下文窗口；

运行标准 Unix 工具来浏览代码树并提取信息；

与 Git 交互；

运行现有工具，例如代码检查器、格式化程序乃至模型检查器；

通过 MCP 在实质上实现对任意工具的调用（可由用户任意设置）。

智能体中实际负责使用代码来“执行操作”的部分并不是 AI，这点请大家放心。它只是非常简单的系统代码，跟编程中的 Makefile 差不多。大家可以在短短一个周末内编写出一个高效的编程智能体，它的实际表现更多取决于各位如何规划和设计 build、代码检查以及测试工具，而非目前 o3 或者 Sonnet 大模型到底先进到了什么程度。

也就是说，如果大家还在 ChatGPT 页面上直接编写请求，然后把生成的（错误）代码直接粘贴到编辑器里，那这跟当前最强大的 AI 辅助发展方向已经南辕北辙了——得出的结论自然也就大相径庭。

看几个积极的示例

大模型可以帮助我们编写出大部分琐碎的代码，而多数项目中的大部分代码都很琐碎。大模型可以显著减少我们需要谷歌搜索的内容，它们可以自行查找。更重要的是，它们不知疲倦、也完全不会受到倦怠或者惰性的影响。

有了大模型的帮助，我们可以做成自己想过但却始终没有成行的工作。相信很多朋友都曾经深深着迷于一门编程语言，心里也知道自己应该马上动手试写代码……但却最终因为懒惰而拖延了一天、一年、甚至一辈子，最终毫无所获。

再想想建立新项目涉及的所有手记、谷歌搜索还有依赖项设计……我的血压马上就升上去了。而大模型可以有效解决所有这些问题。很多人的热情就是被这些琐碎的杂事消磨掉的，而大模型可以立刻起效，帮我们调整代码并即时带来更好的效果。正是这种快速反馈带来的多巴胺，让我们能够把写代码这项艰难的任务坚持下来。

但缺点在于，大模型也消除了我们很多“自欺欺人”的借口。比如面对极其棘手、又不太想做的硬骨头时，我们往往会跑去重构单元测试，然后宣称“我正在做真正重要的工作”。可大语言模型可以替我们重构所有单元测试。比如智能体可以在虚拟机里花几个小时处理完所有测试，然后再回来提交 PR。相信大家都懂这种感觉——那种完全找不到借口，只能硬着头皮冲击难关的……愤怒感。

现在最关键的是，要看得懂代码

如果各位抨击大模型的只是在 Youtube 上贴自己氛围编程过程的 UP 主，那持怀疑论倒可以理解。但如果能看得懂代码，我实在不理解为什么还要质疑 AI 编程。

每一位从业者都得对自己合并进 main 的东西负责。五年前是这样、五年后也是这样，跟用不用大模型根本没有关系。

所以如果想用大模型开发为广大用户服务的产品，那就得认真读代码。比如说花 5 到 10 分钟把代码重新调整成自己的风格之类。其实大模型也在逐渐掌握不同用户的语言风格，但目前还没成熟，所以这个先不提。

有人抱怨大模型生成的代码完全是“基于概率”。不好意思，并不是这样。我们说的可是代码，这些结果是完全可知的。大模型本身也许有随机性，但决定成果能不能用的是我们自己能不能理解这些内容，包括评判的“护栏”是否可靠。

每一位程序员都躲不开阅读其他人的代码。如果大家连大模型写出来的那些枯燥重复的代码都消化不了，那只能说明业务能力有问题！或者说，各位根本就处理不了人类开发者为了赶工期而遗留的那堆乱七八糟的代码。

过去一个月来，Gemini 2.5 成为我的首选编程伙伴（因为它的上下文窗口能够容纳 5 万到 7 万行代码）。确实，它输出的结果几乎都得先做修改才能合并。但我压根不在乎，我喜欢一边浏览代码一边笑着删除那些愚蠢的注释。毕竟任何代码都得一行行读完、看懂才能使用，大模型也不例外。

聊聊幻觉

如果大家觉得幻觉是个大事……不好意思，大模型在编程语言上的幻觉并不严重。

智能体会检查代码，会编译并运行测试。如果大模型捏造出某个新的函数签名，智能体会立马发现错误，然后把结果反馈给大模型。大模型则乖乖承认问题，然后重新尝试。

而且这个过程大多是隐藏的，除非各位会去回顾智能体生成的思维日志。所以我特别喜欢 Zed 的智能体模式：它会提醒用户先离开一会，让它认真工作，并在完成之后通过桌面通知发出提醒。

我相信在某些环境中，大模型的幻觉问题仍然严重。但对于很多开发者一提大模型就抱怨“幻觉”的行为，我非常不认同，因为幻觉在编程领域很大程度上已经被解决了。

但大模型的代码很烂，跟新手开发者一个水平

对，问题是一个月 20 美元够不够请个实习生？当然不够，可够你足足用上 30 天的 Cursor.ai。

所谓高级开发人员，很大一部分工作就是要帮助能力较差的程序员们提高效率——无论他们是真人，还是大模型。善用智能体本身就是一项技能，也是一类工程项目，其中涉及提示词、索引以及工具。换言之，只有我们自己没把好关，大模型才会写出糟糕的代码。

也许很多人还没搞清楚 AI 辅助编程中的具体分式。当前大模型的主要任务是完成输入、谷歌搜索、测试用例，特别是编辑 - 编译 - 测试 - 调试的完整循环。至于我们人类用户，哪怕是对 Claude 模型依赖度最高的开发者，也仍然把握着策划、判断和方向指引的主动权。

另外：请大家不要再自欺欺人了，人类自己的初版代码也不咋地。

但大模型输出的 Rust 代码很差劲

我发现很多对于大模型的质疑并不是真的针对大模型，而更多是种无端猜测。人们常会说“大模型不会写代码”，但他们真正的意思是“大模型不会写 Rust”。这话说得没错，可我们在选择一种编程语言的过程中，就是要考虑它跟运行环境、也包括大模型之间的兼容性。所以，请各位 Rust 开发者能够把心态放开一点（而且别忘了，Rust 社区一直非常重视工具生态）。

我主要使用 Go 语言，也相信 Go 语言的开发团队在立项之初并没有考虑过大模型这码事。尽管如此，最终效果还是很好。Go 拥有良好的类型安全性和丰富的标准库，而且在文化上相当重视编程方言。正因为如此，大模型才能出色地生成这些方言。

总而言之：我也写过 Rust 代码，觉得这语言不错。如果大模型跟 Rust 之间的冲突实在让你难以接受，我也表示理解。可单纯因为这个就否定大模型的编程价值，那我就无法认同了。

聊聊所谓“工匠精神”

大家喜欢那种精致的木工活吗？包括各种手工打造的精美物件？我也喜欢，但这是种奢侈、是有闲人的娱乐。

我自家地下室就有个简易的木工房，偶尔会在那里做件小家具，比如工作台或者烧烤桌。但如果我需要的是一张……放在办公室里的大写字台，那我肯定会去直接买。

对专业软件开发者来说，代码是用来帮人们解决实际问题的。我们不是工匠，至少在大部分日常工作中算不上。没人在乎整个业务逻辑是否优雅完美，而且即使我们开发出的东西真能经得住时间考验，靠的也绝对不是代码库足够简洁漂亮。

再说，如果各位有工夫仔细把函数精简成优雅、流畅且极简的函数表达，反而应当引起警惕——这就像是在给泥巴雕花。我们的注意力应该被放在更重要的工作上，而前面提到的这些只是在自我感动。

而这恰恰是大模型的强项——它们能承担起各种琐碎的杂事，帮我们节约下处理核心业务的精力，真正发挥出不可替代的判断力与价值主张。

但这样不就太平庸了吗？

作为一名干了大半辈子的程序员，我开始总觉得平庸并不是坏事。因为让平庸的成果像从水龙头中流淌出来般轻松落地，本身就是件非凡的壮举。

我们都写过平庸的代码，而且大多可以良好起效。并不是所有代码都必须精彩纷呈，很多代码就应当甘于平庸。在随机单元测试上狠下心力？你疯了吗？项目负责人就该及时介入，骂醒你这个自以为是的家伙。

我知道开发者们很喜欢炫耀代码，担心大模型会降低质量的“上限”……也许没错，但大模型同时也在提高“下限”。

Gemini 的下限就比我高。我有些代码写得不错，但这样的质量不可能一以贯之。大模型的代码虽然重复性很强，可往往比我为了避免重复而刻意变换表达方式的结果更加稳定可靠。

而且，大模型也不是在方方面面都平庸。它们几乎必然比咱们人类程序员掌握更多算法技巧：基数树、拓扑排序、图归约和 LDPC 码等等。人类总觉得 rsync 有某种神圣光环，但在大模型眼里，它跟 SQL 连接差不多、都是手段。

而且哪怕大模型能提供的只是平庸的代码，也丝毫不影响它作出的重大贡献。这至少意味着这些平庸代码不用由人类亲手编写了。

但现在的大模型永远成不了 AGI

我压根不在乎。

很多聪明的践行者也被 AI/ 风投的炒作周期蒙蔽了双眼，这个我能理解。可不论那帮家伙怎么煽动，大模型生成的代码能不能用才是衡量结论的唯一准绳。

他们只是在开玩笑

真是在开玩笑吗？他们也曾经认为开源这事不可行，但开源成果真的取代了当初那些昂贵的专有数据库。

编程是个高度强调靠自动化来削减工作岗位的领域。经济学家们常说的“生产力提升”其实就是这个意思，也就是用更少的人手就能完成更多工作。

所以每当有大模型这类新方法出现时，风险投资者们就会高呼：新灯塔、创造性颠覆和带来全新工作岗位之类。这话可能是对的，但我不会被洗脑。我不知道大模型普及之后到底会怎样，但在特定阶段内让情况变糟的可能性肯定很大。

大模型可能真会取代很多软件开发人员，但我觉得程序员也不该觉得自己有什么不同。过去三十年间，我们跟各行各业一样都面临着科技进步的威胁。我们不是东海岸那帮行会制度保护下的码头工人，我们也不该、也不可能阻止科技进步。

那……抄袭问题呢？

人工智能正在以深刻、也称不上公平的方式威胁着视觉艺术创作者们。没错，如果大家不从事这方面工作，可能很难体会到这样的冲击。

我们想象艺术家们的主要工作，就是努力突破视觉表达的边界。但普通艺术家创作的并不是画廊作品，他们只是在为杂志绘制封面、给博物馆展览提供宣传素材、制作动态影像和游戏资产等等……创作插图和宣传画，才是他们的主要工作内容。

而大模型很轻松地就通过了行业质量考查。更令人恼火的是，它们最擅长的工作就是批量产出“过得去”的人类创意产品。我有家人从事视觉艺术工作，现在我在他们面前根本不敢提“大模型”几个字。我能理解他们，但这就是现实。

另一方面，软件开发者们发现大模型生成的代码片段似乎从 GitHub 上的公共 repo 处抄袭而来，顿时勃然大怒。问题是……各位是律师吗？如果不是，这里我想说句难听的：世界上再没有什么职业比程序员更习惯抄袭、更蔑视知识产权的了。既然没人来挑我们的刺，那我们最好也别跳出来去挑别人的刺。

很多开发者都觉得《星球大战》和 Daft Punk 的歌属于公共资源，程序员文化也一直反对任何可能给消费体验带来不便的媒体盈利保护手段。程序员们建立起了全球规模的盗版网络，而且对最新剧集设置的独家放映保护期不屑一顾。

大家想第一时间看到 TED 演讲，想第一时间观看收费剧集，对吧？既然我们自己都不相信知识产权，那跑到大模型这高举大旗有什么意思？

总之最终还是实力说话，我们唯一的价值就是在综合开发能力上与大模型对抗。既然大家对设计师们费心费力搞出来的字体拿来就用，那也别抱怨自己的代码片段会被用于训练更强的大模型。

这并不是坏事

几天前在写这篇文章时，我本想以开宗明义的方式概括大模型辅助编程的最新水平。可现在还没等一块鱼肉变质，大模型的基准性能排名就变了，所以在阅读这篇文章的同时，里面很多内容可能已经过时了。

现在的新一代开发者可不光使用智能体：他们用的是异步智能体。他们一觉醒来，大开脑洞想到 13 个不同的探索方向，然后就会交给大模型去做。在最终得到的 13 个待审核 PR 中，有 3 个完全不能用，他们会重写提示词再次生成。有 5 个约等于新手程序员水平，还须修改。还有 5 个则可以直接合并。

有位好友告诉我，“现在我的工作效率就像坐上了火箭。至于团队里那帮坚持拒绝 AI 的人，则像是在原地踏步。”我相信他说的话，能用好大模型的人跟用不好的，差距大得如同互联网时代会不会上网的区别。

当然，很多事情还是不能交给大模型去做，毕竟迄今为止还没有谁敢把生产环境直接交给大模型。但我曾经收到过一起意外故障，我把日志记录提交给了 4o 大模型（注意，不是 4o-mini），它在几秒钟内就发现了我们抱怨好几个月的主机 LVM 元数据损坏问题。所以，谁敢说自己一定比砸开的智能体更擅长审阅 OpenSearch 日志？反正我不敢。

更让很多好友惊讶的是，我既不是那种技术激进分子、也不是未来主义者。我这个人很保守，相信复杂系统、机构和回归均值都存在偶然性。我老老实实编写 Go 和 Python 代码，从不会盲目追求那些酷炫的最新技术成果。

但有些改变真的正在发生。也许很多最聪明的头脑仍然对此嗤之以鼻，但……我想大模型的崛起至少值得我们拿点时间认真讨论。

但到处都是大模型的内容，听得人想吐

一点没错。如今的技术资讯几乎把所有头版都让给了大模型：渐进式模型更新、利用大模型开展业务的初创公司、大模型使用教程、反对大模型普及的陈词滥调等等……真的烦人！

但 AI 确实非常重要——它值得的关注虽然不及当初的互联网，但至少也应该等同于 2008 年蹿红的智能手机。这不是判断，而是事实。

我认为明年情况会更加明朗。那些关于“随机鹦鹉”和对“氛围编程”的嘲笑在现实面前越来越站不住脚。虽然这篇文章似乎在抨击他们，但我得严肃承认：各位其实比我聪明。所以等大家放下这种矫揉造作的姿态，相信切实的努力会让未来的编程智能体较如今更上一层楼。

(来源：新浪科技)