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

其实这一观点并不少见，过去经常有朋友问我，大模型上下文越来越长，RAG 还有用吗？随着以 Claude Code 为首的 coding agent 在过去一年里强势崛起，类似的质疑不仅仅来自“外行”的朋友，越来越多的身处大模型应用行业其中的朋友也开始持有这样的观点。

我想先从一个似乎不相干的角度来切入：有一位朋友向我抱怨前缀缓存的不合理，表示缓存应该是模型供应商自己处理的优化，凭什么要求应用工程师去考虑前缀缓存？这不是妥妥的抽象泄露吗？

是的，以工程师的审美来说，这就是抽象泄露，是丑的。但我随即想到 CSAPP 开篇的引语：为什么软件工程师要学习体系结构呢？书里给出的理由是，软件工程师要理解体系结构的运行原理，才能优化软件的效率、写出符合底层逻辑的代码。

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

出现这种脱节的原因也不难猜测：体系结构的设计已经非常稳定了，除了嵌入式或者超算之外的通用计算设备，包括服务器、桌面和手机，几乎没有区别。因此中间层就可以做充分的封装抽象，程序员再也不关心体系结构的问题。

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

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

那有朋友自然要问了：抽象泄露导致耦合怎么办？比如说我按前缀缓存原则吭哧吭哧设计了一套应用，结果有一天 diffusion 架构崛起了再也没有人用 transformer 大模型了，前缀缓存不就凉了吗？

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

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

最近人们经常提到一个概念叫“低垂的果实”：大模型可以解决很多有价值的问题，对于工程师来说轻易就能做掉，举手之劳。

什么时候会出现这样的低垂果实？那就是底层科技发生快速更新的时候。快速地接入新的科技，在别人意识到问题之前就解决问题：这正是过去那个群星璀璨的时代的人们所做的事情。

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