Context Is All You Need
发布时间：2025年8月22日
此处致敬 《Attention Is All You Need》
上下文工程已成为2025年 AI 应用的核心技能。
在通用大模型出现以前，传统的自然语言处理研究主要遵循预训练 - 微调 - 预测 范式，即先使用海量数据训练、再针对特定的功能场景进行微调，然后在业务中落地。
但随着模型参数的增大，出现了涌现效应， 通用大模型逐渐成为主流，为了让通用大模型在特定一类场景下更好的处理任务，出现了提示词工程，即通过精心设计的 Prompt 引导大模型将注意力放在特定的范围内。
时至今日，模型的能力还在不断增强，但随着 AI 脱离 Chatbot 的限制，以 Agent 的形式在业务中落地，大家发现即使再牛逼的大模型也无法完全了解一个复杂的应用的全貌，举一个最简单的例子：在 Cursor 中，就算你使用最好的编码模型 - Claude Opus 4，它也不可能一次性的、规范的完成一次页面开发。
在这个场景下，大模型在强业务性场景下的落地的可用性、大家对大模型的高期望值之间存在巨大的 gap，于是有两种方案：
- 微调大模型，但在实际场景中，大多数业务的复杂度根本没有到需要微调一个垂类大模型的场景
- 在和模型交互时，喂给大模型更多的业务信息，让它懂业务
第二种方案就是本文提到的「上下文工程」
上下文工程的必要性：
- 大模型是 无状态 的
- 大模型的 上下文 是有限的
一、什么是上下文工程？
上下文工程是一种系统化的方法论和技术栈，旨在为大型语言模型构建和提供动态、精准、高质量的上下文信息和工具，以期使LLM能够可靠、高效地完成特定任务，并生成更准确、更可靠、更具个性化的回答或内容。
上下文工程与提示词工程的对比如下
| 特征 | 提示词工程（Prompt Engineering） | 上下文工程（Context Engineering） |
|---|---|---|
| 定义 | 专注于设计、优化和精炼输入给大语言模型（LLM）的具体提示词（prompt），以引导模型生成期望的、更高质量的输出。 | 一种系统化的方法论，旨在为LLM构建和提供动态、精准、高质量的上下文信息和工具，使模型能够可靠、高效地完成特定任务。 |
| 核心关注点 | 优化单个查询的表述和结构。 | 优化LLM与外部环境、知识和工具的整体交互，提供完整的”背景故事”。 |
| 范围/广度 | 相对较窄，侧重于单个交互或某一轮对话的输入优化。 | 范围更广，涵盖了从提示词设计到外部知识检索、工具集成、多轮对话管理等多个方面。 |
| 目标 | 提升模型在特定提示下的即时响应质量。 | 提升模型在复杂、多变任务中的长期、持续、可靠性能，使其更像一个智能体。 |
| 输入形式 | 主要是一个或一系列精心设计的文本字符串（提示词）。 | 除了提示词，还包括：外部知识库检索结果用户历史对话记录结构化数据工具的使用方法及调用结果系统指令（规则、约束）等。 |
| 动态性 | 相对静态，通常是一次性或固定的输入。 | 强动态性，上下文会根据任务进展、用户反馈或外部信息变化而实时更新和调整。 |
| 与大模型的关系 | 一种与LLM”沟通”的技巧，是对LLM输入端的优化。 | 是一种为LLM”构建世界观”的学科，让LLM能够更好地”思考”和”行动”。 |
| 复杂性 | 相对较低，主要涉及语言理解和表达。 | 较高，涉及系统设计、数据管理、知识图谱、工具集成、推理链构建等复杂工程。 |
| 典型应用场景 | 问答、文本生成、代码生成、摘要等单次或短时任务。 | AI Agent、自动化工作流、复杂决策支持、领域专家系统等需要多步骤、长周期交互和外部能力的任务。 |
虽然提示词与上下文在定义上是分开的，但实际上两者的关系如下图
二、工作中使用上下文工程
实际上，大家在日常已经用上了上下文工程，拿我们现在使用的 cursor 来举例，里面就藏着各种各样的你可能知道的不知道的上下文工程实践
(一) Cursor 中的上下文工程
1. 规则上下文
上图里的相关内容，从本质上来说都是上下文工程中的「系统规则」，cursor 根据自己的理解认为将规则做了拆解，分成了三部分：
- Memory：这部分主要是大模型在和我们协作过程中自己总结的我们的偏好信息，比如我上面的偏好：该用户不需要助手修改项目中的任何脚本，在和大模型交互的时候会传递过去
- User Rules：用户规则，也可以理解成全局规则，在任何项目下适用，总是作为上下文传递给大模型并由大模型消费
- Project Rules：项目规则，和项目绑定的，写在项目的
.cursor/rules下的规则文件，根据apply的配置信息决定是否消费，大概有以下几种
| Rule Type 规则类型 | Description 描述 |
|---|---|
Always Apply |
始终包含在模型上下文中 |
Apply to Specific Files |
当引用匹配 glob 模式的文件时，自动包含 |
Agent Intelligently |
可供 AI 使用，由 AI 决定是否包含，必须提供描述 |
Apply Manual |
仅在使用 @ruleName 明确提及时包含 |
2. 结构化数据 & 知识库上下文
上图的内容，体现了上下文工程中的 结构化数据、知识库 部分
结构化数据：目前可用的只有代码仓库的向量化，通过为每个文件计算嵌入向量来索引代码库，在和大模型交互时传递
知识库：知识库这块提供了两种能力
外部文档：可以根据自己的需求在这里附加不同的知识库，cursor 会自动抓取其内容并建立索引，后续在使用对话弹窗中可以通过
@Docs的方式引用，为模型提供额外的上下文项目文档：根据自己的需求在本地创建笔记本，可以用作上下文的补充、复杂任务的描述等场景，在对话弹窗中使用 @notepad 方式引入
3. 外部数据 & 附加工具
主要体现在上面的 Integrations 和 MCP Tools 两个模块，分别提供了外部平台数据 & 附加工具两块
(二) Cursor 的最佳实践
从上面看到 Cursor 提供众多上下文工程能力，那么如何利用好这些东西呢，大概有几个最佳实践：
1. 规则约束
可以从 Bigfish、Smallfish、React、TypeScript、Less、CssInJS 等方面出发，制定一些标准化实践方案，并作为通用规则落在每一个仓库中，这样可以保证团队内代码规范的一致性
使用 cursor 的 generate cursor rules 能力 + 人工的方式，编写项目的特殊规则，可以保证每一个协作者代码规范的一致性
2. 知识库
一、通用文档
为常用的组件库的文档建立索引，现在有很多库已经提供了面向大模型的文档，比如：
- ant design 提供了官方维护的使用文档
- context7 提供了常用的各种库的文档，提供 MCP +
txt文档两种方式接入
当你的任务需要使用到对应的组件库时，便可以在任务描述中附加上对应的文档或者指定大模型先通过 context7查询怎么用再动手编写代码
二、需求/设计文档
如果你的需求或者系统设计文档写的足够细致 + 系统规则足够完善，完全可以通过附加相关文档的方式让大模型自己按照文档去实现代码
如果使用的是通用的框架，比如 cra、nextjs 之类，甚至可以实现无需依赖系统规则
3. 外部上下文附加
通过工具扩充工具和模型能力边界，比如：
- 关联 slack 查看个人的任务面板
- 关联 github 查看相关的 issue、pr
- 引入
sequential-thinking让大模型实现更深度的思考
三、总结
上下文工程的出现，标志着 AI 应用正试图走完从”惊艳的玩具”到”可靠的工具”的最后一公里。
提示词工程解决了”如何与模型对话”的问题，但模型本身是健忘的、无手的、与世隔绝的，而上下文工程 则直击这一痛处，它的本质不再是”教模型说话”，而是为模型打造一个可交互的”世界”。
- 用知识库给它”记忆”，解决”健忘”问题。
- 用工具集给它”手脚”，解决”无能”问题。
- 用外部数据和规则让它”感知现实”，解决”隔离”问题。
总而言之，上下文工程是驱动 AI 从”聊天机器人”进化为”智能工作体 (Agent)”的核心引擎，是让 AI 从”能说会道”迈向”能干实事”的关键一步。