上下文工程：提示词和可靠 AI 产品之间的新层
上下文工程不是把提示词写得更花，而是设计 AI 系统在回答或行动前应该看到哪些信息。
最后更新
上下文工程是指在 AI 系统回答或执行动作之前，设计它应该看到什么信息、如何使用这些信息、以及如何验证结果。提示词只是其中一部分，更完整的上下文还包括文档、用户状态、历史记忆、检索结果、工具权限、输出格式和评估标准。
这个概念变重要，是因为很多 AI 产品失败并不是模型能力不够，而是上下文设计不对。模型可能很强，但它拿到的是过期政策、错误文件、缺失的用户状态，或者根本不知道应该引用哪段资料。
一个真实的失败场景
假设客服助手要回答退款问题，只给它一句：
按照我们的退款政策回答用户。
这不够。它还需要：
- 当前退款政策
- 用户购买时间和套餐
- 所在地区
- 历史工单
- 升级规则
- 不能承诺的边界
- 引用政策条款的方式
缺少任何一个关键输入，AI 都可能回答得很自信但事实错误。
四个层次
| 层次 | 解决的问题 | 常见产物 |
|---|---|---|
| 来源选择 | AI 应该看哪些资料 | 文件选择、检索器、数据库查询 |
| 状态管理 | 哪些信息要跨步骤保留 | 用户目标、会话历史、权限、上一步决策 |
| 指令设计 | AI 应该如何使用上下文 | 系统提示词、任务约束、输出结构 |
| 评估 | 上下文变好后结果是否变好 | 测试集、日志、回归检查 |
对团队来说，上下文工程把 AI 可靠性从“玄学调提示词”变成了系统设计问题。
和相邻概念的区别
| 概念 | 重点 | 和上下文工程的关系 |
|---|---|---|
| 提示词工程 | 指令怎么写 | 上下文工程的一部分 |
| RAG | 检索外部资料 | 来源选择的一种方法 |
| Agent 工作流 | 多步骤执行任务 | 依赖上下文、工具、状态和评估 |
| MCP | 模型连接工具和数据的协议 | 能让上下文和工具访问更标准 |
| 记忆 | 跨会话保留信息 | 状态管理的一层 |
中文内容里不要只把它解释成“高级提示词”。真正的购买信号在调试：为什么 AI 答错了，是拿错文件、缺少状态、检索失败，还是工具调用不安全。