上下文工程（Context Engineering）

在上一节中，我们学习了提示词版本管理，知道一条提示词要想长期稳定使用，不能只保存正文，还要记录模型、参数、测试结果和运行环境。

但新的问题又来了：大模型真正看到的内容，远远不只有一段 Prompt。

你上传的文件、前面的聊天记录、系统提示词、用户偏好、知识库资料、工具返回结果，甚至当前时间和登录身份，都会一起影响 AI 的回答。

有时候，提示词本身明明已经写得很清楚了，但 AI 还是把事情办砸了。这往往不是因为你 “不会提问”，而是它根本没拿到正确的资料，或者桌面上堆了太多过期、互相冲突的信息。

所以，我们需要把格局打开，从 “怎样写好一句 Prompt”，升级到 “怎样管理 AI 干活时能看到的全部信息” ——这就是所谓的 “上下文工程”。

什么是上下文工程？

简单来说，上下文（Context）是大模型在处理当前请求时，实际能够读取和利用的 “全部信息” 。它不仅包括你刚敲下去的那句话，还包括：

• 系统规则。
• 当前任务。
• 对话历史。
• 外部资料。
• 用户偏好。
• 工具定义和结果。
• 当前时间与业务状态。
• ……

而 “上下文工程”，就是研究如何挑选、整理并把这些资料喂给大模型的全过程。

很多小伙伴以为 “上下文工程” 只是给 “提示词工程” 换了个高大上的马甲，其实两者的侧重点是不太一样的：

• 提示词工程：重点研究 “怎么说” ，也就是怎么把任务说明白，包括角色、任务、约束等。
• 上下文工程：重点研究 “给什么” ，也就是让 AI 看见什么、不知道什么、什么时候看见。

一条真正在业务中干活的 Prompt，通常长这样：

最终请求 = 提示词（怎么做） + 上下文（给什么）

上下文中通常包含哪些内容？

对于一次会话来说，上下文一般会包含下面这几类内容：

• 系统规则：相当于 AI 的 “岗位说明书”，规定了它的角色和安全边界（比如 “客服助手只能根据政策回答，遇大额争议转人工”）。
• 当前任务：用户这次到底要干嘛。最好明确目标和限制，别只丢一句 “帮我处理下”。
• 对话历史：多轮对话的 “记忆”。但历史不是越长越好，如果前面换了三次方案，旧要求还留着，AI 就不知道到底听谁的了。
• 外部资料与知识库：决定了 AI 能不能基于事实说话，而不是靠训练时的老黄历瞎编。常见的 RAG 就是干这个的：先找资料，再让模型回答。
• 用户偏好与记忆：比如用户习惯看简短回答、对花生过敏，能让回答更贴心。但重要信息发生变化时仍需要确认更新。
• 工具及返回结果：比如旅行助手不仅得知道 “能查天气”，还得拿到具体的城市、日期和最新的天气数据，才能决定行程要不要调整。

为什么上下文不是越多越好？

很多小伙伴一听到上下文工程，第一反应就是：“那我把所有资料都塞进去，不就万无一失了吗？”

尽量别这么干，这容易把 AI 的脑子变成垃圾场。资料塞得太多，会带来几个挺要命的问题：

• 无关信息变多：你的核心要求被大量闲聊和旧资料淹没。
• 资料互相打架：不同版本的规则都在，AI 根本不知道信谁的。
• 信息过期：旧价格和旧政策继续影响答案。
• 又慢又贵：每次都传一堆冗余数据，Token 成本直线上升，速度更慢。
• 窗口占满：真正重要的新信息反而挤不进去了。

这就好比开会讨论活动方案，你把公司成立以来的所有合同和财务报表全搬进会议室。资料确实是全了，但大家可能连桌子在哪都找不到了

真正好的上下文，不是 “什么都有”，而是符合下面四个要求：

• 正确：资料本身可靠，没有明显错误。
• 相关：与当前任务直接有关。
• 及时：使用的是当前有效版本，而不是过期内容。
• 清晰：来源、结构和优先级都容易理解。

上下文工程的核心方法

要做好上下文工程，通常有下面几个核心思路：

• 按需提供，别一次塞满：用户问退款，你只给对应订单和退款政策就行了，没必要把整个商城的用户记录全扔过去。这种思路叫 “按需检索”。
• 标清来源和优先级：给了多份资料时，告诉 AI 谁说了算。比如 “以最新版为准，冲突时列出差异，别自行决定”。
• 压缩又臭又长的对话：聊了几十轮后，可以让 AI 把前面的结论写成一个小摘要，只保留有效约束，扔掉已淘汰的废话。
• 及时更新和删除过期信息：价格变了、项目结项了，旧信息就要及时标记失效或删除。不然 AI 可能会一直拿三年前的偏好来敷衍今天的你。
• 将不同任务和用户隔离开：上一秒在写活动方案，下一秒要改代码，最清爽的做法是直接新开一个对话。不同用户、不同任务的数据更要严格隔离防串台。

普通用户怎样做好上下文工程？

上下文工程听起来很像开发者的专属技能，其实普通用户每天也都在用，只是以前没有给它起名字而已。

平时我们使用 ChatGPT、Claude 或其他 AI 工具时，可以遵循下面几个简单做法：

• 一个对话尽量只聊一个核心任务，换主题就新开对话。
• 传文件时只传相关的，顺便提一嘴哪个是最新的。
• 长对话聊到一半，让 AI 先总结一下已确认的结论，再接着聊。
• 重要日期、预算等条件，尽量在当前消息里重新确认一下。
• 遇到资料打架，要求 AI 先把冲突点列出来，别让它擅自补全。

我们可以参考下面这个模板，来组织背景信息。

示例：

# 当前任务
[说明这一次需要 AI 完成什么]

# 关键背景
[只填写会影响结果的重要信息]

# 可用资料
[列出文件、链接或数据，并注明日期和来源]

# 已确认约束
[预算、时间、范围、禁止事项等]

# 仍不确定的信息
[存在冲突或需要补充的内容]

# 输出要求
[说明需要的格式和详细程度]
要求：如果信息不足或资料冲突，请先指出问题，不要擅自补全。

开发 AI 应用时，还要注意什么？

对于普通用户来说，整理好文件和聊天记录已经很管用了。但如果你是在开发 AI 应用，那就需要把上下文做得更系统一些：

• 动态检索：根据问题从数据库搜出少量资料，而不是一次塞满，控制噪音和成本。
• 保存信息溯源：回答最好能追溯到具体的文件片段和更新时间，出了问题好排查。
• 区分长期记忆和当前事实：语气偏好可以做长期记忆；但库存、订单这种变量，应当实时查，不能依赖死记硬背。
• 控制工具和数据权限：扔进上下文的数据必须经过后端权限校验，不能让 AI 越权。
• 测试上下文变化：检索规则调整了，旧的评测结果可能就失效了，上下文组件也需要回归测试。

完整实战：给 AI 旅行助手准备上下文

假设我们想让 AI 帮忙规划一次三天旅行。最简单的提问可能是：

帮我安排一份北京三日游行程。

这句话没有错，但 AI 缺少太多关键信息：哪三天、从哪里出发、预算多少、同行者是谁、有没有已经订好的酒店、能不能走太多路。如果它只能自己猜，生成的行程看起来可能很完整，实际却不一定适合你。

更完整的上下文可以这样组织：

# 系统规则
你是一名旅行规划助手。只能根据用户已确认的信息和最新查询结果安排行程。
如果营业时间、天气或交通信息无法确认，请明确标记。

# 当前任务
安排一份北京三日游行程。

# 用户与同行者
- 两名成年人和一名 8 岁儿童。
- 不希望每天步行超过 12 公里。
- 喜欢传统建筑和当地美食，不安排购物中心。

# 已确认信息
- 旅行日期：[填写日期]
- 酒店位置：[填写区域]
- 已预订项目：[填写项目，没有则写“无”]
- 每日预算：[填写预算]

# 可查询工具
- 天气查询
- 地图与交通时间
- 景点营业时间

# 输出要求
- 按上午、下午、晚上安排。
- 每天保留休息时间。
- 对需要预约的项目进行标记。
- 不要擅自修改已确认的酒店和预订。

这份上下文里，没有塞进去用户之前的电影清单和工作总结，只保留了刚好够做这份行程的 “纯净” 数据。

这就是上下文工程的核心：不是把 AI 喂得越撑越好，而是让它在需要的时候，刚好拿到完成任务所需的那一盘资料。