上下文工程：比提示词工程更值钱的那一层能力
提示词写得好只是及格线，真正决定 AI 输出上限的是喂进去的上下文。本文讲清上下文工程的四个组成部分、组装顺序与常见误区。
提示词不是天花板，上下文才是
很多人把效果不好归咎于”提示词没写好”。但当你的模型已经能理解自然语言时，瓶颈往往不在措辞，而在你给了它什么信息。
同一句提示词，配上一份准确的参考文档，输出质量可以天差地别。这层能力，叫上下文工程（Context Engineering）。
上下文的四个组成部分
一个完整的上下文窗口，其实是四种信息的组合：
1. 指令（Instructions）
系统提示 + 当前任务要求。定义角色、硬约束、输出格式。这部分要稳定且精简，不要塞满风格废话。
2. 知识（Knowledge）
检索到的文档、数据库记录、用户历史。这是最容易失控的部分——检索系统一多，噪音就多。
3. 工具定义（Tools）
可调用的函数、API 说明。工具越多，模型越容易选错；工具描述写得好，比数量多更重要。
4. 历史与状态（Memory/State）
对话历史、任务进度、中间结果。长任务里这部分会迅速膨胀。
上下文工程的核心工作就是：在有限窗口里，把这四样东西按优先级组装好。
组装顺序：一条实战规律
经验法则，按”模型注意力”的规律排布：
开头放稳定指令，中间放参考资料，结尾放当前任务。
原因很简单：模型对开头和结尾的关注度最高，中间容易稀释。所以：
- 硬约束、角色定义 → 开头
- 检索到的长文档 → 中间
- 本次要处理的具体问题 → 结尾
如果只把任务丢在中间，模型最容易”跑偏”。
三个反直觉的实践
反直觉一：删信息比加信息更有效
新手总想多喂一点”以防万一”。但上下文里每多一段无关内容，都在稀释关键信号。
先做减法：这段材料真的会影响输出吗？不会就删。
反直觉二：结构化比自然语言更省
把会议记录原样贴进去，模型要花力气理解结构。改成带字段的结构化格式（时间、参与人、结论、待办），同样的信息占用更少 Token，且准确率更高。
反直觉三：示例比解释更管用
与其长篇解释”要什么样的风格”，不如给 2–3 个正例和反例。模型对示例的模仿能力，远强于对抽象描述的遵循能力。
常见的死法
死法一：窗口一满就截断 简单粗暴地把最早的对话删掉，结果丢失关键约束。正确做法是渐进式摘要：把老对话压缩成要点，保留主干。
死法二：检索全塞进去 Top-20 全贴进去，噪音淹没重点。应该先粗排再精排，控制在 3–5 条高相关片段。
死法三：工具描述含糊 工具越多，描述越要精确。写清”什么时候用、什么时候不要用”，否则模型会乱调。
死法四：不做上下文缓存 固定的系统提示和长文档如果每次都重传，成本和延迟翻倍。支持缓存的接口要用上。
一个可复用的上下文模板
[系统指令]
角色 / 硬约束 / 输出格式
[知识]
检索到的 3–5 条高相关片段（带来源标注）
[工具]
可用工具及其适用边界
[历史摘要]
长对话的压缩要点
[当前任务]
本次要解决的具体问题 ← 放最后小结
提示词工程关心”怎么说”，上下文工程关心”给什么、怎么排”。后者的杠杆更大，因为模型的能力上限，常常是被喂进去的信息决定的。
记住三个动作：做减法、结构化、把任务放最后。