上下文工程并非新概念，而是AI应用开发中不可获取的组成部分——它本质上是一门“为AI提供正确信息”的实践艺术。本教程将带你深入理解这一核心理念，探讨其在不同场景下的应用策略，帮助你在实际开发中做出更合理的技术选择。

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

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

我们从一开始构建AI应用就在做上下文工程——怎么获取更完整的上下文，上下文怎么拼接到提示词中，这些工作从使用GPT 3.5 Turbo就开始了。所谓的「上下文工程」，更像是对既有实践的重新包装和理论化。

核心要点：

• 上下文工程的定义与历史实践
• 不同AI编程工具处理上下文的策略对比
• 完整上下文对LLM理解力的决定性影响

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

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

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

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

3. 完整上下文 > 一切提示词

AI Coding 应该是AI最火热的赛道，没有之一。其中间出现了不少的玩家，例如Cursor、GitHub Copilot Agent、Cline、Claude Code等，这些产品在处理上下文的策略上却截然不同。

3.1 两种截然不同的策略

• 策略一：RAG + 向量检索
  使用RAG和向量检索来分析代码库，将代码库分块并嵌入，试图通过语义搜索来选择「相关」的代码片段填充上下文窗口。代表工具：Cursor、GitHub Copilot Agent。
• 策略二：完整背景 + 自主规划
  给AI更完整的问题背景，让AI自行规划、发现和跟踪代码关系。代表工具：Cline、Claude Code。

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

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

3.2 不同RAG策略的实验数据对比

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

• 纯向量RAG：用例通过率只有12%
• 向量+关键词查询混合检索：能达到60%+
• 让AI生成摘要，摘要 + 文本向量 + 混合检索：能达到81%

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