最近一段时间，我中高强度使用了一阵子 Codex 5.4 和 Opus 4.6。
如果仅看外界的舆论，你大概会觉得软件工程的终结已经近在咫尺。社交媒体上充斥着关于大模型编码能力的神话：动辄就是“一人公司”、“我花5分钟做出了某某软件”，仿佛程序员这个职业明天就能就地解散。在他们的描绘中，未来的日子里只需要有一个懂点 Prompt 的产品经理，软件开发就能万事大吉。
这种叙事听起来非常振奋，因为它满足了人们对“复杂劳动终将被自动化”的终极幻想。但我却产生了一种截然相反的预感：LLM 的能力边界，似乎已经快要摸到天花板了。
不过，在彻底审视 LLM 之前，我们得先从一个古早，却被严重误解的话题说起。
编程，仅仅是“产出代码”吗？
长期以来，无论是在大众眼中，还是在管理者的 Excel 表格里，编程都被简单粗暴地等同于“写代码”。在这个视角里，程序员就是流水线上的翻译官，负责把需求翻译成机器指令，谁打字更快、产出更多，谁就更优秀。
可如果这种“代码中心论”成立，它根本无法解释现实工程中反复出现的幽灵现象：
- 为什么一名核心程序员离职后，面对逻辑完备的源码，继任者往往还是无从下手？
- 为什么编写了再详尽的文档、再规范的接口说明，也无法让一个对业务陌生的新手快速发力？
- 为什么有的旧系统明明还能跑，但全团队都心照不宣地拒绝维护，可以说只是“在等一个重构的机会把它埋了”？
- 同样的源代码，为什么在不同的团队手里，其发挥的业务功能、维护的稳定性和新功能的演进速度会天差地别？
难道编程真的只是写出那一堆纯文本吗？
关于这个问题，图灵奖得主 Peter Naur 在其经典名篇 Programming as Theory Building（将编程视为理论构建）中给出了极其深刻的批驳。Naur 认为，编程的本质并不是产出可执行的代码文本，而是在程序员头脑中，构建起一套关于“现实问题”以及“系统如何映射现实问题”的理论。
软件一定会被修改，但真正的修改绝不仅仅是在文本编辑器里增删字符。它是让系统继续匹配现实世界中不断变化的新需求、新约束和新关系。要做到这一点，开发者必须理解：系统为什么被这样设计？哪些是核心约束，哪些只是历史的权宜之计？
所以，当一个系统失去了其原有的开发团队后，接手者是没有办法仅仅通过阅读代码和文档来“复活”它的——因为他们拿到的只是被抛弃的外壳，而支撑这副躯壳的“认知理论”已经随着原团队的离开消亡了。很多时候，与其艰难地去接手一套失去灵魂的代码，还不如重新回到问题本身，再构建一套新的理解，并将其落实为新的代码。
代码，只是理论的外化，是思考的排泄物，而不是编程的全部。
没有银弹，只有不断被折叠的“附属复杂性”
如果我们再援引软件工程圣经《没有银弹》中的观点，事情的脉络就更清晰了。
回顾漫长的编程史，程序员这个群体其实一直都在光明正大地“偷懒”。从打孔纸带到汇编语言，再到高级语言；从裸文本编辑到 Vim，再到如今庞大的 IDE。软件工程的发展史，就是一部不断把脏活累活交给工具的历史。
但 Fred Brooks 早就指出，软件的复杂性分为两种：附属复杂性（如何分配内存、如何配置环境）和本真复杂性（复杂的业务逻辑、混沌的现实约束、人性的多变）。
无论工具怎么进化，我们只能不断消除“附属复杂性”，却永远无法消除“本真复杂性”。现实世界的业务关系和边缘情况，本来就是这么复杂且混沌的。
从这个角度看，LLM 当然是一次人类“偷懒”的巨大进步。它可以让我们从无聊的 CRUD、繁琐的正则、样板代码的拼装中抽离出来。 但是，系统的本真复杂性永远存在。
我并不是鼓吹代码的实现细节不重要，没有代码机器依然什么也做不了。只是相比于“把代码打出来”，对现实业务的理解、对系统结构的把握、对“变化如何进入系统”的预判，往往更重要。而这，恰恰是 LLM 无法替代的。
语言之外：文字的狂欢不等于真实的智能
如今的 LLM 以“语言（文本）”作为训练材料而兴盛，但它的阿喀琉斯之踵也在于此——它最终会因为无法理解“语言之外”的现实世界而碰壁。
语言并不等于智能。如果“能说会道”就是最高智能的体现，那世界上最聪明、最能解决实际问题的人，应该是那些整天在办公室做 PPT 汇报、满嘴黑话的雄辩家，而不是真正在一线造桥、治病、写系统的人。
视觉、听觉、触觉、空间经验、甚至是业务运转中那些隐蔽的利益冲突，这些非结构化的、难以用语言完美表达的真实反馈，才是认知世界的基础。文字，仅仅是对现实世界极度有损的压缩倒影。
LLM 只是在学习这些被压缩后的倒影。它会流畅地复述世界，却未必真的理解世界。这也是为什么多模态、世界模型、具身智能会开启新一轮爆火——因为业界已经隐约察觉，只在语言文字里打转，永远无法真正触碰物理世界与复杂系统的底层逻辑。
就如同你知道了许多大道理，但你无法获得智慧，你无法知道如何在结构不良环境下使用才是正确的。你只是知道，但从未理解。
逼近极限：一场被工程化包装的停滞
就我深度的使用体验来看，我越来越怀疑 LLM 正在逼近其主路线的极限。
现在的 LLM 动不动就是万亿级别的参数量，消耗着一整个机房的算力。面对如此庞大的规模，我越来越难以相信“继续堆算力就能带来逻辑质变”的纯粹 Scaling Law 神话，我也很难相信世界上还有多少未被污染的高质量数据可供吞噬。
你看看现在的头部企业，OpenAI 或是 Anthropic，发个新模型要在营销上做足戏份。连公认目前体验最好的 Opus，其实也在变得更偏向于“工程化”的缝合——比如通过 Claude.md、Skill 工具调用、复杂的系统提示词（System Prompt）以及外部的长上下文记忆组织，来维持其强大的表象。这反而说明了一点：单纯依靠模型本身，已经无法稳定承担复杂的逻辑任务，必须依赖大量外部的脚手架来兜底和纠偏。
只要稍微把任务链条拉长一点，你就会立刻意识到 LLM 犯下的错误有多么离谱且致命。它会在单轮对话中显得极为聪明，但一旦涉及多模块交互、多轮次修改、长期一致性的挑战，它就开始出现逻辑死循环、遗忘隐式约束，或者理直气壮地胡说八道：包括但不限于编造第三方库，引入多个相互冲突的库。
崩溃何时到来？
让我们回顾一下历史。很久之前，当计算机专业还籍籍无名之时，我们在大学里找到的，往往是对计算机抱有极高热情、底子扎实的好学生。企业可以放心招人，因为这些人的“理论构建”能力极强。
后来计算机大热，企业为了扩张愿意招收只会背八股文的学生，学校为了蓄水疯狂扩招。
如今到了 LLM 时代，资本的逻辑又变了。企业开始幻想开掉外包和初级程序员，指望着不断升级的 LLM 神话能够跑赢人员流失带来的生产力损失。短期看，财报好看了；但长期看，这种行为正在摧毁行业的土壤。没有了在屎山代码中痛苦摸爬滚打的初级程序员，未来的高级系统架构师从何而来？当老一代掌握“系统理论构建”的人离去，留给企业的将是一个由无数代不同 LLM 生成的、毫无连贯性可言的超级代码黑盒。
同时，各个AI公司，我在这里尤其指名OpenAI，是否能够偿还扩张期的债务？为什么要通过相互投资来抬升股价？
这就如同 21 世纪初的那场互联网泡沫，只不过这次的主角换成了 LLM。或许人类唯一吸收的历史教训，就是人们从来不吸收任何历史教训。泡沫正在越来越大，我等待着崩溃到来的那一天。或许只有当神话破灭，人们才会理性地审视大模型真正的能力边界。
好帮手，但也仅仅是个帮手
我写下这些，并非要全盘否定 LLM，说它是一无是处的垃圾。相反，我认为它已经很有用了，而且会继续有用。LLM不是无所不能的神话，也不是一无是处的垃圾。
它确实改变了软件开发。它帮我写好了恶心的正则表达式，补全了冗长的类型定义，让我得以从无穷无尽的样板劳动中脱身。但它从未改变编程的本质——程序员依旧需要去理解复杂的现实业务，去倾听那些充满歧义的真实诉求，去构建稳健的系统架构。
从这个角度来看，LLM 只是软件工程漫长历史中，又一个让程序员“偷懒”的高级工具而已。它和之前的编译器、垃圾回收机制、IDE 之流并无本质不同。它可以提高局部效率，却不能替代全局理解；它可以放大人类的能力，也可以掩盖低水平的无能。
我？
在这个喧嚣的时代，我对这位“超级帮手”的定位已经非常清晰克制。摒弃幻想，物尽其用：
- 作为高级搜索引擎： 用模糊语言查找资料，或者检索特定报错的可能原因。它在信息压缩和提取上比 Google 快。
- 写临时脚本： 比如“用 ffmpeg 把目录下所有视频压制成 1080p 并提取音频”，或“写个 Python 脚本清洗这个几万行的脏乱 CSV”。这类生命周期短、边界清晰的任务，它是绝佳的代劳者。
- 翻译与润色短句： 处理英文文档，或是润色对外的 Release Notes。
- 作为一个永远耐心的“小黄鸭”： 当思路卡壳时，我不是让它替我做决定，而是把它当做一个对话对象。帮我梳理思路、暴露盲点。它在“陪你想”这件事上，远比在“替你做”这件事上可靠。
本文由本人初稿，Chatgpt5.4 Extend Thinking和Gemini3.1Pro Preview共同润色后，本人校对修改后发出。