LLM 在编程领域的局限性

Source:https://x.com/lidangzzz/status/1871505849983594677?t=5UnA5rIonz0gelZk-LMAjQ&s=05 Author::lidangzzz

写在前面

这篇文章起源于立党老师的一条推文，讨论了 LLM 和 Agent 在编程中的真实能力边界。读完之后有不少共鸣，也有一些自己的想法，索性展开聊聊。

• The original
• 立党老师的核心论点
• 我的一些想法
• 再往深想一层
  • Reasoning 强不代表 Engineering 强
  • Context Window：必要条件，但不是充分条件
  • 被忽视的交互循环
  • 关于「替代」的粒度
  • 最后

The original

很多人说，reasoning=coding，o3就是最能写代码的模型。

我的看法是，reasoning指的是扔一个简单干净的问题，给出天才回答的能力。

这么说吧，如果把o3扔到20世纪，一定是全世界最牛逼的理论CS科学家，3-SAT、max flow、min cut、红黑树、LU分解、KMP、各种proof-base的加密算法，轻轻松松全拿下， 一口气构建整个TCS大厦。

解决TCS问题，就是解决抽象出来的数学、计算、拓扑问题，本质上可以认为和“解决数学难题”是一种类似的能力。

（但是解决CS问题不等于解决数学问题，我始终跟大家科普，cs不等于数学，cs和pure math没有直接关系）

但是，真正日常工作上班写代码，跟研究理论计算机问题，是完完全全的两种能力、两种模式、两种思维。

现实中真正的coding能力，不仅是把系统搭好，而且需要强烈的耐压能力和记忆力，还要不断动手配置、动手测试、动手调试、完成各种profiling的工作，

你不止需要跳跃式读代码，和机器互动，你还要跟同事互动，跟一大堆文档互动，跟不同配置环境互动，跟各种dependency的文档互动，然后把这些复杂的关系一一捋清楚，记在脑子里，然后一点点去把模块和功能摸索一遍。

这跟设计一个简单、干净、天才、杰出的TCS算法，是完完全全的两回事。

另外，你也千万不要认为architect（架构师）是在解决高级、抽象、干净、完美的数学题，

真正合格的architect，恰恰是手最脏、摸技术细节最多、调试最多、profiling最多的人——然后从这些反复枯燥的工作中，不断总结和思考，不断用脏手去尝试，做出正确架构和设计的选择，

说“真正的架构师，才需要o3级别的智能”的人，都是纯纯的大外行。

现在所有做coding agent的项目，都遇到一个最直接的死穴：context window太小了，几个文件还能喂进去，整个代码是不可能喂进去的。

现在一堆人在专注于给agent解决memory的问题，但是在针对coding问题上，用memory是不能解决任何问题的。

现在市场上的coding agent大概就是这么一个水平的人：

你给他看一个定义充足、干净、简单、难度高的问题，他可以通过step by step的reasoning，给你一个非常精美的解；

你给他一个20万行代码的巨型project，根本没办法下手；

然后coding agent的作者们，会用各种RAG的方法，去给model去喂一堆各种片段，试图用few shot的办法来直接幻想出答案——结果必然是错的（比如cursor、windsurf），

而另一些coding agent的作者们，试图step by step引导gpt-4o，去完成design driven或者test driven的开发流程，用大量的资源去保证每一步提供gpt-4o的信息量是充足的，以等待他进行下一步的action，包括添加文件、修改文件，或者在terminal里执行运行、编译、测试等等工作（比如devin），

而更麻烦的问题是，现实中绝大多数人还要跟aws打交道，跟database打交道，跟各种private key和权限打交道，跟各种container打交道——本质就是跟不同的环境和人打交道，

而这种coding以外的工作，要么交给一个human proxy，在适当的时刻引导人类去干预指导（非常复杂且需要实时盯着），要么你开始把所有密码、账户、权限都交给它，让它来决定什么时候去操作（非常危险），

总而言之，我反复讲的一点：

LLM和目前Agent技术，可以代替很多tcs（理论计算机） phd，

但是代替不了业务和工作稍微复杂一点点的程序员，包括设计复杂system（包括mlsys）的phd。

所以这也是我为什么从最最一开始就看好moonshot，其实context window在一些诸如coding或者法律工作中上限的能力，

如果你相信scaling law，你就应该不仅相信multi agent，parallel task scheduling，也应该相信context window的问题会逐步解决，

如果不把context window解决掉，或者坚信fine tuning比context window更重要——那么很多问题就会彻底卡死，成为这一轮AI、LLM、vertical AI agent浪潮的真正瓶颈。

立党老师的核心论点

简单提炼一下：

• 理论能力 ≠ 工程能力：o3 级别的模型可以当 TCS 天才，但面对 20 万行的真实项目就抓瞎——因为工程是脏活，不是解题。
• 架构师不是数学家：真正合格的架构师是手最脏、调试最多的人，不是在白板上画方块的人。
• Context window 是死穴：模型记不住整个项目，RAG 拼凑的碎片信息只是幻觉的另一种形式。
• 替代理论 PhD 可以，替代程序员不行：业务逻辑、环境配置、团队协作——这些才是真正的编程。

我的一些想法

大方向上我是同意立党老师的，但有几点想展开说说：

「解题」和「干活」真的是两个物种。 你让 o3 去 LeetCode 上刷 hard 题，它可能比 99% 的人强。但你让它去接手一个跑了三年的 Spring Boot 项目，光是理清楚哪些接口还在用、哪些是历史遗留，它就已经转不动了。因为这不是智力问题，是信息量问题。

Context window 确实是命门，但可能不是唯一的命门。 就算哪天 context window 真扩到无限大，模型就能当程序员了吗？我持怀疑态度。因为编程不只是「读懂代码」，还有大量的试错循环——改一行，跑一下，看报错，再改。这种跟环境的实时交互，光靠文本上下文是不够的。

AI 写代码的真正价值，在于消灭重复劳动。 生成 CRUD、写单元测试、补文档注释、做格式转换——这些事情交给 AI 是真的爽。但涉及到「这个接口要不要做幂等」「这个字段该放 Redis 还是数据库」这种需要业务判断的决策，目前还得靠人。

安全问题被严重低估了。 文中提到把密钥和权限交给 AI 操作，这不是「非常危险」——这是「一定会出事」。我见过太多 .env 文件被提交到公开仓库的案例了，何况让一个会幻觉的模型去操作生产环境？

借用一位朋友的话：「技术可以外包，判断、责任、创新永远属于人。」 这句话放在 AI 编程这个语境下再合适不过了。

（说句不好听的：现在的 coding agent 就像一个刷了 3000 道 LeetCode 的应届生，面试的时候惊为天人，入职第一天面对屎山代码直接精神崩溃）

再往深想一层

Reasoning 强不代表 Engineering 强

这一点其实很反直觉。我们日常接触到的 AI benchmark——数学竞赛、代码题、逻辑推理——都在考察一种「干净」的智力。问题定义清晰，边界明确，答案可验证。

但工程不是这样的。工程世界里，需求是模糊的（「这个页面加个按钮，具体什么按钮我也没想好」），代码是有历史的（「这个函数为什么写成这样？因为三年前有个 bug workaround」），环境是脆弱的（「本地跑得好好的，一部署就挂」）。

所以我一直觉得，用 LeetCode 和数学竞赛来衡量 AI 的「编程能力」是有误导性的。真正的编程能力，很大程度上是信息管理能力——你能不能在脑子里同时 hold 住业务逻辑、技术栈限制、团队约定和历史决策。

Context Window：必要条件，但不是充分条件

立党老师把 context window 说成是「死穴」，这个判断我基本同意。但我想补充一点：即使 context window 扩展到百万级，模型依然需要学会「选择性注意」。

想象你是一个刚入职的程序员，leader 给你扔了一个百万行的 monorepo，说「你先看看代码熟悉一下」。你不会真的从第一行读到最后一行——你会先看目录结构，再找入口文件，然后顺着调用链追踪。

这种「知道该看什么、该忽略什么」的能力，比单纯的「能看多少」更关键。目前的 RAG 方案本质上是在用检索来模拟这个过程，但检索的质量取决于 query 的质量，而 query 的质量又取决于对整体架构的理解——这就变成了一个鸡生蛋的问题。

被忽视的交互循环

文中提到了 Devin 的 step-by-step 模式，我觉得这其实是目前最有希望的方向之一。但问题在于，一个真正的开发循环远比「读代码 → 改代码 → 跑测试」复杂：

• 你需要在本地起一个完整的开发环境（Docker、数据库、消息队列...）
• 你需要在浏览器里点击验证前端交互
• 你需要看日志里那些不会被测试覆盖到的 warning
• 你需要和 PM 确认「这个边界情况怎么处理」

这些都不是文本层面能解决的。AI 需要的不只是更大的上下文，还需要更丰富的感知通道——能看到屏幕、能操作终端、能理解 HTTP 响应。某种意义上，这比扩展 context window 更难。

关于「替代」的粒度

与其讨论「AI 能不能替代程序员」，不如问一个更精确的问题：AI 能替代程序员的哪些工作？

我个人的感受是，大概 30-40% 的日常编码工作已经可以有效借助 AI 完成——代码补全、boilerplate 生成、简单 bug fix、文档编写、正则表达式拼写。这些都是「定义清晰、反馈明确」的任务。

但剩下的 60-70%——系统设计、性能调优、故障排查、需求对齐、技术选型——这些需要跨越代码边界的判断力，短期内看不到被替代的可能。

所以与其焦虑「AI 会不会抢我饭碗」，不如想想怎么把那 30-40% 的时间省下来，投入到真正需要人类判断力的事情上。

最后

这篇文章写于 2025 年初，AI 编程工具还处于「能用但不好用」的阶段。也许一年后回头看，有些判断会过时，有些会被验证。但有一点我比较确定：编程永远不只是写代码——它是在混乱的现实世界中建立秩序的过程。 而这件事，目前还是人比机器擅长。