上下文工程：一直都存在，只是没有这么叫

date

Jun 24, 2025

slug

context-engineering-reality

status

Published

summary

最近上下文工程（Context Engineering）成了某些人用来营销的新名词，用各种观点和文章来说明这个「新」东西的重要性，我觉得有些好笑。。。

提示词不重要，上下文才是王道

LangChain 将上下文工程定义为「构建动态系统，以正确的格式提供正确的信息和工具」，同时提到「很多人专注于巧妙地措辞提示来诱导更好的答案，但随着应用变得更加复杂，向 AI 提供完整和结构化的上下文远比任何魔法措辞更重要」（非常对）

现实中，有太多人花费大量时间调试提示词的措辞，试图找到那个什么所谓道，语言的本质。

完全南辕北辙，鸡同鸭讲，就像你和一个专家交流时，用词技巧远不如你提供的背景信息重要，专家需要的是完整的问题背景，而不是花哨的修辞手法，所谓的提示词工程也就是上下文工程。

AI Coding 应该是 AI 最火热的赛道，没有之一。

其中出现了不少的玩家，例如 Cursor、GitHub Copilot Agent、Cline、Claude Code 等，这些产品在处理上下文的策略上却截然不同。

Cursor 和 GitHub Copilot Agent 使用 RAG 和向量检索来分析代码库，将代码库分块并嵌入，试图通过语义搜索来选择「相关」的代码片段填充上下文窗口。

而 Cline 和 Claude Code 则选择了另一条路：给 AI 更完整的问题背景，让 AI 自行规划、发现和跟踪代码关系。

从我个人的使用体验来看，后者的效果要好得多，解决一些复杂的横跨非常多模块的问题成功率或定位成功率会更高。

Cline 的博客文章《为什么 Cline 不索引你的代码库》说得很透彻：当你将代码分块用于嵌入时，你实际上是在撕裂它的逻辑，想象一下试图通过听随机的 10 秒片段来理解交响乐——这就是 RAG 对代码库做的事情。

我自己曾经在一些项目中也做过一个对比实验，测试不同 RAG 策略的效果：

数据很说明问题，纯向量检索根本不 work，它破坏了信息的内在逻辑关系，而要保持语义关系又需要过于复杂的内在工程，而且就算做了过于复杂的内在工程，也未必能达到真正的生产可用。

因此我发现只有当 LLMs 能看到完整的上下文时，才能真正理解问题的本质，这也是为什么我认为完全基于向量的 RAG 是不成立的，没有任何实际意义。

有一个容易被忽略但极其重要的点：聊天历史也是上下文，而且是最重要的上下文之一。

构建 AI 应用本质上就是在聊天——你一句我一句的对话过程，即使是那些看起来「一键AI生成」的应用，背后也需要精心构建聊天历史，此时上下文如何管理和处理变得极其关键。

每次交互都在构建和累积上下文：用户的历史偏好、之前的决策、对话的演进轨迹——这些都是 AI 理解当前问题不可或缺的背景。

但现在大多数讨论「上下文工程」的文章都把焦点放在如何从外部数据源获取信息，却忽略了对话历史本身就是最宝贵的上下文来源。

这也有点本末倒置了。

说白了，如果模型的上下文窗口是无限的，根本不需要什么「上下文工程」，直接把所有相关信息都塞进去得了。

正是因为模型的上下文有限制，我们才需要思考：什么时候放什么样的上下文到提示词中？如何构建和管理模型的聊天历史？哪些信息是当前任务最关键的？

这才是上下文工程的核心：在有限的窗口内，确保 AI 获得最有用、最完整、最有序的信息。

我知道很多产品选择 Cursor 这样的方案，很大程度上是为了控制成本，向量检索确实能减少 tokens 消耗，降低费用。

但我们依然需要明白：如果你的目标是最佳效果，那么完整上下文就是王道，因此就算你避免不了分片，那么也尽可能保持语义最大完整性，用来达到尽可能好的效果。

重要的还是这个意识，因为我才发现很多人还是以为搞 AI 应用，就是要什么文本切分、转成向量、检索这一套才算是搞了开发，不是套壳，而且觉得这一套会比全部丢上下文里更加准确，回答质量会更佳。。。

「上下文工程」这个词可能是新的，但它描述的实践一点都不新，从我们开始构建第一个 AI 应用时，就在思考如何给模型提供最正确的信息。

真正重要的不是这个概念的包装，而是对核心问题的理解：在当前业务场景下，AI 需要什么样的信息才能有效工作？我们如何在技术限制下提供这些信息？

在这个基础认知上，无论是调用外部 API、检索历史数据、还是管理对话状态，都只是具体的实现手段。