AI使用进阶之二：上下文工程：给对信息，比写花哨提示词更重要
你能不能掌控 AI，很多时候不取决于你怎么说，而取决于你让它看到了什么。
Prompt 只是上下文的一部分，真正决定稳定性的，是整包上下文的组织方式。
先给结论
如果说提示词工程是在“写指令”，那上下文工程就是在“管信息流”。
真正进入工作场景后，模型看到的并不只有一段 prompt，还包括：
- system 指令
- 历史对话
- 检索回来的资料
- 工具返回的结果
- 用户状态
- 应用层总结
这些东西一旦组织不好，模型就会：
- 抓错重点
- 记住噪声
- 忽略真正重要的信息
- 把旧信息当新信息
为什么“提示词很好，结果还是飘”
因为很多问题根本不在提示词，而在上下文包：
- 历史消息太长，旧信息把新问题淹没了
- 检索结果太多，但真正关键的只占两段
- policy、事实、样例混在一起
- 用户临时要求和系统长期规则冲突
- 工具返回大量原始文本，没有被提炼
这就像总线带宽有限，但你把无关数据也全塞进来了。
不是模型笨，是喂进去的信息结构有问题。
上下文工程到底在管什么
1. 管“什么该进来”
不是所有信息都该给模型。
优先级应该是：
- 和当前任务直接相关的
- 最新的
- 来源可靠的
- 能减少歧义的
2. 管“什么不该进来”
很多噪声会降低结果质量：
- 已经过时的结论
- 冗长但无决策价值的聊天记录
- 没清洗的网页原文
- 不同来源互相矛盾、却没标注可信度的资料
3. 管“怎么进来”
同样是 2,000 个 token，不同组织方式，效果可能完全不同。
更稳的做法通常是：
- 规则和事实分开
- 背景和任务分开
- 原始材料和提炼摘要分开
- 当前回合所需信息放前面
一个好用的上下文分层法
你可以把上下文拆成四层：
第一层：长期规则
这层最稳定，变化少。
例如：
- 角色设定
- 输出风格
- 安全边界
- 不能做什么
第二层：当前任务
这层是每次调用都变的。
例如：
- 用户现在的问题
- 当前要完成的动作
- 本轮的输出目标
第三层：任务所需知识
这层来自外部信息源。
例如：
- 文档片段
- FAQ
- 产品资料
- 代码上下文
第四层：运行时状态
这层最容易被忽视，但对 agent 很重要。
例如：
- 上一步工具调用结果
- 当前失败原因
- 已尝试过哪些路径
- 下一步应该优先做什么
为什么这比“写一个超长提示词”更有效
因为超长提示词常常把四层内容混在一起。
一混，模型就容易出现两类错误：
- 该长期遵守的东西，变成临时参考
- 该临时更新的东西，被历史噪声盖住
上下文工程的价值，不是让模型知道得更多，而是让模型在正确的时候只看到正确的信息。
对嵌入式工程师来说，这件事很好理解
你可以把上下文窗口理解成一种受限资源：
- 容量有限
- 读写有成本
- 噪声会干扰有效信号
- 信息布局会影响最终行为
所以你管理上下文，本质上和管理缓存、内存、带宽、队列很像。
重点不在“多”，重点在“值不值”。
实战里最有用的四个动作
1. 摘要，而不是硬塞历史
长历史消息不要全保留。
把和当前任务相关的结论压成摘要，再继续传给模型。
2. 检索后再筛选
RAG 不是“检索回来就都喂进去”。
很多时候还要做二次排序、去重、提炼。
3. 把来源标清
不同材料的权威性不一样。
如果不标，模型容易把评论、规范、草稿混为一谈。
4. 定期清理状态
Agent 多轮运行时，状态会越来越脏。
该总结的总结，该丢弃的丢弃，不然上下文会越来越重。
一句带走
Prompt 工程解决的是“怎么表达”，上下文工程解决的是“给什么信息”。
当你开始管理上下文，而不是只会堆提示词，你才真正进入 AI 使用的中段。