什么是上下文工程 Context Engineering？

2026-06-17

上下文工程（Context Engineering）是一种系统设计方法：它不只是写好一句提示词，而是设计并管理”喂给模型的全部上下文”——包括规则、检索到的资料、历史记忆、可调用的工具，让模型在每次回答时都拿到刚好够用、且准确的信息。它比提示词工程更上位：提示词是其中一环，上下文工程管的是整个”信息进料系统”。

这篇讲给写代码、做 AI 应用、用 Claude Code / Cursor 这类工具的人。读完你会明白：为什么同样的模型，有人用得神、有人用得废，差距往往不在模型本身，而在上下文工程。

为什么需要上下文工程

大模型有个硬约束：它只知道你告诉它的，加上它训练时记住的。你的代码库、你团队的规范、昨天聊到一半的需求、内部 API 的用法——这些它一概不知，除非你想办法塞进上下文窗口。

只靠”把提示词写得更妙”很快会撞墙：

提示词再精巧，也喂不进一个 10 万行的项目——模型看不到代码就只能瞎猜。
上下文窗口有限，一股脑全塞进去既贵又会”注意力稀释”，关键信息被淹没。
多轮对话会”失忆”，前面定好的约束，后面模型就忘了。

上下文工程就是来解决”该让模型在此刻看到什么”这个问题的。它把”喂料”当成一个要设计的工程系统，而不是碰运气的一次性输入。

上下文工程是怎么工作的

可以把模型想成一个能力极强但刚入职、记性只有一次对话的天才顾问。上下文工程要做的，就是在他每次开口前，把桌上的资料摆对。通常包含四类”料”：

规则（Instructions）：角色设定、输出格式、编码规范、禁止事项。在 AI 编程里常落到一个项目级文件（如 AGENTS.md），相当于”新人入职文档”。
检索（Retrieval）：临时从代码库、文档、知识库里捞出与当前任务相关的片段塞进去，这就是 RAG 干的事——相当于让模型”开卷考试”。
记忆（Memory）：把长对话压缩成摘要、把用户偏好沉淀下来，跨轮、跨会话保留关键信息，避免失忆。
工具（Tools）：告诉模型它能调用哪些函数、查哪些接口、跑哪些命令，让它从”只会说”变成”能动手”。

这四样组装起来，在每次请求前动态拼成最终上下文。核心原则只有一句：在有限窗口里，让模型拿到”刚好够用、且准确”的信息——不多塞干扰项，不漏掉关键项。这个机制是长青的，具体窗口大小、token 计费等参数以官方文档为准。

拿一个真实场景对比一下就懂了。假设你让 AI 给电商项目加一个”订单退款”接口：

只有提示词、没有上下文工程：你写”帮我写一个退款接口”，模型只能按教科书套路给你一个通用的 refund(orderId, amount)，字段命名、错误码、事务处理全是它猜的，和你项目里现有的订单模型、状态机对不上，改起来比重写还费劳动。
上下文工程组织好：规则文件写明”错误处理统一用 AppError 类，状态流转必须调用 OrderStateMachine”；检索环节自动把 order.model.ts、payment.service.ts 片段喂进去；工具环节开放”读取数据库表结构”的调用权限。同样一句需求，这次写出来的代码字段对齐、调用现有服务、状态流转合规，你几乎不用改。

差距不在模型聪明不聪明，而在它这次到底”看到”了什么。

规则文件不是写几句口号就行。一份能打的 AGENTS.md 至少要包含：技术栈版本、目录约定（“接口逻辑放 src/services，禁止在 controller 里写 SQL”）、命名风格（“变量小驼峰，数据库字段下划线”），以及一份”禁止事项”清单（“禁止引入新状态管理库”、“禁止绕过现有鉴权中间件”）。写得越具体，AI 跑偏概率越低——这份文件的边际收益往往比你多写十条提示词更高。

检索（RAG）最容易被简化理解成”塞文档”，其实分块（chunk）参数直接决定效果。切成 2000 token 一块噪音多；切成 200 token 一块又容易把完整逻辑切断，模型看到的是”半句话”。工程上常用折中是 300～500 token 一块、留 10%～20% 重叠（overlap）。检索到的片段还要做相关性排序（rerank），别让语义沾边但用不上的内容挤掉真正关键的那一条。

记忆这块，长对话最容易踩”越攒越多、越攒越糊”的坑。稳妥做法是分层：短期靠最近几轮原始对话；中期每隔几轮做一次”决策摘要”，把已拍板的结论钉住；长期才沉淀成偏好或项目级知识跨会话复用。别指望模型自己会记，除非你显式设计了这套机制。

上下文工程和相邻概念怎么选

概念	管什么	一句话区别
提示词工程	单次输入的措辞、结构	怎么”把话说好”
上下文工程	整个进料系统（规则+检索+记忆+工具）	怎么”把料备齐”
RAG	其中的”检索”环节	上下文工程的一个组件
微调（Fine-tuning）	改模型参数本身	改”大脑”，而非改”喂料”

判断口诀： 一次性能写清楚的，用提示词工程就够；要让模型反复、稳定地处理你专有的数据和任务，就得上上下文工程；其中”找资料”这步交给 RAG；只有当上下文怎么调都满足不了、需要模型固化某种风格或能力时，才考虑微调。多数 AI 编程场景，上下文工程的性价比远高于微调。

能用来做什么

在 AI 编程里，上下文工程几乎决定了 AI 帮你写代码的上限：

让 AI 读懂你的项目：用项目规则文件交代技术栈、目录约定、命名风格，AI 生成的代码才贴合你的工程，而不是教科书式的通用写法。
跨长任务不跑偏：长会话靠记忆压缩和阶段性小结，把已确定的决策”钉住”，AI 不会改着改着忘了需求。详见 Claude Code 的上下文管理（规划中）。
接私有知识：用检索把内部文档、API 说明动态喂进去，AI 才答得出”你们这套系统该怎么调”。
配合规格驱动开发：先把需求和约束写成规格，再交给 AI 执行，本质就是把上下文前置、结构化，参见规格驱动开发 SDD（规划中）。

怎么上手

不用先学一堆框架，从你正在用的工具就能起步：

写好项目规则文件。在 Claude Code 或 Cursor 里建一个项目级规范文档，把技术栈、编码约定、禁止事项写清楚——这是投入产出比最高的一步。
学会管上下文。任务切换时主动清理或新建会话，别让无关历史塞满窗口；长任务让 AI 阶段性总结进度。
按需引检索。需要 AI 了解专有资料时，再把相关文档喂进去，而不是一次性堆满。
把高频任务沉淀成模板：固定的规则 + 检索方式做成可复用流程，团队共享。

先把第 1、2 步做扎实，多数人的 AI 编程效率就能上一个台阶。

具体到工具层面：在 Claude Code 里，AGENTS.md（或 CLAUDE.md）会被自动读取，写完开个新会话验证”AI 是不是真照着规则走”；规则文件要跟着项目迭代，接口改了不同步更新，AI 照旧规则写照样跑偏。Cursor 里的 .cursor/rules 写法略有差异，具体以官方文档为准，思路一致：把”新人该知道的事”写成文档。

任务切换要不要开新会话，判断标准很简单：这轮任务和上一轮还有没有共享的上下文。改同一个模块的两个 bug 可以继续；从”改前端样式”跳到”设计数据库表结构”，果断开新会话——旧对话里堆的样式细节对新任务是纯噪音。

上手时最容易踩的坑

规则文件写成”愿望清单”：写”代码要优雅”等于没写。换成”函数不超过 50 行”这类可判断的硬约束，AI 才能照做。
检索片段和当前任务不匹配：改前端组件却把整个后端代码塞进上下文，模型注意力被分走，生成质量反而下降。
长会话不做阶段小结：聊到第 50 轮才发现第 5 轮定的技术选型早被模型”忘了”，回头改的成本比早做总结高得多。每完成一个子任务就让 AI 总结一次当前决策。
工具权限开得太宽或太窄：给”能执行任意 shell 命令”这种粗粒度权限风险不可控；什么都不给又只能”纸上谈兵”。按需配最小权限集，比如只开”读文件”和”跑测试”。

常见问题

上下文工程和提示词工程是一回事吗？ 不是。提示词工程是”把单次输入写好”，上下文工程是”设计整个喂给模型的信息系统”，提示词只是其中一环。上下文工程更上位、更系统。

我只是用 AI 写写代码，需要懂上下文工程吗？ 需要，而且收益很直接。哪怕只是给项目写一个规范文件、学会及时清理无关对话，AI 生成代码的贴合度和稳定性就会明显提升。

上下文工程是不是就是 RAG？ 不是。RAG 只负责”检索”这一环，是上下文工程的一个组件。上下文工程还要管规则、记忆、工具的组织与取舍。

上下文塞得越多，模型答得越好吗？ 恰恰相反，窗口有限且会”注意力稀释”，无关信息塞太多反而拖累效果、还更贵。追求的是”刚好够用且准确”，不是”越多越好”。

👉 看看我们的 AI 编程实战体系课，或逛 AI 编程教程大全把基本功打扎实。