大模型能力的发展会碾压一切大模型应用工程吗？

不断被挑战的“应用价值” ​

其实这一观点并不少见，过去经常有朋友问我：“大模型上下文越来越长，RAG 还有用吗？”

随着以 Claude Code 为首的 Coding Agent 在过去一年里强势崛起，类似的质疑不仅仅来自“外行”的朋友，越来越多的身处大模型应用行业其中的朋友也开始持有这样的观点。

从 CSAPP 的“抽象泄露”说起 ​

我想先从一个似乎不相干的角度来切入：

有一位朋友向我抱怨**前缀缓存（Prefix Caching）**的不合理，表示缓存应该是模型供应商自己处理的优化，凭什么要求应用工程师去考虑？这不是妥妥的“抽象泄露”吗？

是的，以工程师的审美来说，这就是抽象泄露，是“丑”的。

但我随即想到 CSAPP（《深入理解计算机系统》）的开篇：为什么软件工程师要学习体系结构？

书里给出的理由是：软件工程师要理解体系结构的运行原理，才能优化软件的效率、写出符合底层逻辑的代码。

这一理由总令人觉得牵强。事实上，今天的大多数程序员都根本不考虑分支预测、内存缺页云云，编译器之类的中间层早就把这些包圆了。不如说程序员人工试图做的优化反而会是累赘。

大模型尚未进入“稳态期” ​

出现这种脱节的原因也不难猜测：体系结构的设计已经非常稳定了。

除了嵌入式或者超算之外的通用计算设备（服务器、桌面、手机），底层逻辑几乎没有区别。因此中间层可以做充分的封装抽象，程序员再也不必关心体系结构的问题。

而大模型不是这样的。

• 一方面，大模型的效率还远远没有像硬件那样可以大手大脚地挥霍；
• 另一方面，大模型的底层结构仍在快速发展：智力能力也好、底层架构也好，随时都会发生改变。

因此 CSAPP 所述的情形对于大模型应用来说是成立的：为了设计出效率更高的应用，程序员需要理解大模型底层架构是如何运行的。 这一原则的显著体现就是“前缀缓存”。如果应用不尊重前缀缓存，它只能接受又贵又慢的代价。

工程的本质是解决当下的问题 ​

那有朋友自然要问了：抽象泄露导致耦合怎么办？如果有一天 Diffusion 架构崛起了，再也没有人用 Transformer 了，前缀缓存不就凉了吗？

是的，这也是大模型基础能力碾压应用工程的一大可能样本。回答是别无他法：快速转身迎接新的架构。

事实上，一切工程实践都会被底层科技的更新所颠覆。砖石建筑会被钢筋混凝土颠覆，屹立千年的斗兽场最终也不过景观。但所谓的工程学是什么？不就是在现有的科技条件下去解决问题吗？ 科技发展或快或慢，但你总要在现有科技下解决问题。

从工程师到黑客 ​

最近人们经常提到一个概念叫 “低垂的果实” ：大模型可以解决很多有价值的问题，对于工程师来说轻易就能做掉，举手之劳。什么时候会出现这样的低垂果实？那就是底层科技发生快速更新的时候。

快速地接入新的科技，在别人意识到问题之前就解决问题：这正是过去那个群星璀璨的时代的人们所做的事情。

第一代网红 LangChain 和第二代网红“小龙虾” OpenClaw 则是最近的例子。工程师的能力是稳固、负责任地解决问题，而黑客除此之外，还要动作更快一点。