上下文工程：AI 时代的编程新范式

当我们谈论 AI 编程时，大多数人把注意力放在了模型能力上——模型够不够强、上下文窗口够不够大、推理速度够不够快。这些固然重要，但真正决定 AI 编程天花板的，是另一个被严重低估的维度：如何把正确的上下文，在正确的时机，以正确的方式交给 AI。

这个领域正在形成一门新的编程学问，我把它叫作"上下文工程"（Context Engineering）。

从"提示词工程"到"上下文工程"

2023 年，所有人都在谈"提示词工程"（Prompt Engineering）。技巧帖满天飞：要用 CO-STAR 框架、要用思维链、要在开头加角色设定。那个时候的核心假设是：只要我的提示词足够精巧，AI 就能给我足够好的输出。

这个假设在 2024 年开始崩塌。随着 Claude 3.5、GPT-4o、Gemini 2.0 这一代模型的出现，模型本身的指令遵循能力已经非常强了，绝大多数提示词技巧带来的边际收益趋近于零。你不需要再告诉模型"请一步步思考"——它天生就会深度推理。

但与此同时，一个更深层的问题浮出水面：AI 表现的上限，越来越取决于你给它输入的信息质量，而不是提示词的写法。

同一个模型，在处理一个干净、完整、格式良好的代码库时，和处理一个充满隐式依赖、交叉引用、文档残缺的代码库时，输出质量可以相差数倍。

这不是提示词的问题。这是上下文的问题。

上下文的四层结构

我在实践中观察到，有效的上下文工程需要处理四个层次的信息：

第一层：任务上下文——你要 AI 做什么。这是传统提示词工程覆盖的领域。它包括任务目标、约束条件、预期输出格式。在这一层，现代模型已经不需要太多技巧，给出清晰的目标描述就够了。

第二层：知识上下文——AI 需要知道什么才能正确完成任务。这包括项目架构、技术栈、业务规则、代码规范。一个关键的原则是：知识上下文应该是可验证的，而不是仅仅"描述性"的。换句话说，告诉 AI"我们使用 REST 风格 API"只是描述，而提供一份准确的 API Endpoint 清单才是可验证的知识。

第三层：状态上下文——当前代码库处于什么状态。这是被绝大多数人忽视的一层。AI 在一个代码库的不同状态下，需要不同的上下文。比如当 AI 刚刚完成了一个函数的实现，状态上下文应该包含这个函数的名字、签名、已经覆盖的测试用例、以及还缺少什么。如果 AI 不知道当前状态，它可能会生成重复的代码、或者与已有实现产生冲突。

第四层：交互上下文——本次对话中发生了什么。每一轮对话都是对状态的更新。AI 应该能够基于之前的交互历史，推断出当前任务的进展程度，而不需要用户重复解释。

为什么当前工具普遍做得不好

主流 AI 编程工具在这四层上下文上的处理，大多是残缺的。

VS Code 的 Copilot 在代码补全场景下做得好，但它几乎没有任务上下文的概念——它不知道你在做一个推荐系统还是一个支付系统。Cursor 的 Composer 功能尝试引入多文件编辑的能力，但它处理状态上下文的方式是暴力的全量索引，在大型代码库上要么太慢要么超出上下文限制。

更根本的问题是：大多数工具把上下文当作静态的东西——一次性加载，然后遗忘。 但真实的编程过程是动态的，每一行代码的改变都可能影响上下文的相关性。你改了函数签名，上下文中的"函数签名"那条信息就过期了。你删了一个文件，所有指向这个文件的引用就失效了。

静态上下文的问题在于它会产生"上下文污染"——陈旧的信息和新的信息混在一起，AI 会在错误的上下文中给出看似合理但实际错误的答案。

动态上下文管理的几个原则

基于我的实践，有几个原则值得分享：

按需加载，而非全量填充。 不要试图把整个代码库都塞给 AI。最好的做法是让 AI 在需要时主动获取相关上下文——类似数据库的 lazy loading 机制。你在实现一个 API 路由时，AI 只需要知道这个路由相关的 Controller、Service 和 Schema 定义，而不需要了解整个项目。

让上下文具备生命周期。 每一条输入给 AI 的上下文，都应该有明确的"有效期"概念。一段代码规范在什么时候适用？哪些知识是跨版本稳定的，哪些是随本次重构临时失效的？当 AI 生成的代码与某个规范冲突时，是规范过期了还是生成有误？这些问题需要工具层面的支持。

建立上下文的版本意识。 在 AI 读取一段代码之后，如果这段代码被修改了，AI 应该知道这个变化，而不是继续基于旧的认知工作。这听起来像是一个工程问题而非算法问题——但它对输出质量的影响是决定性的。

展望：上下文会成为新的软技能

未来三到五年，我认为"上下文工程"会成为工程师职业发展中最重要的软技能之一。

它的重要性会超过今天的"提示词工程"。提示词工程解决的是"怎么说"的问题；上下文工程解决的是"说什么"的问题。后者更难、需要更深的业务理解和对工具的精细掌控。

最终，能够让 AI 在正确的上下文中运行的人，会比那些只懂得调用 API 的人，效率高出几个数量级。这不是 AI 取代人的故事——这是善用 AI 的人取代不善用 AI 的人的故事。

上下文工程，是这场竞争的新赛道。