上下文工程：它如何取代了提示词工程
很长一段时间里，“做 AI”几乎等于一件事：写好提示词（prompt）。到了 2025-2026 年，这已经不够了。模型会调用工具、通过 RAG 拉取文档、保留会话记忆，并以智能体链路运行。决定质量的不是措辞是否漂亮，而是上下文工程 - 一门设计模型在每一步究竟看到什么的学科：指令、事实、历史、权限与边界。下文说明它如何取代经典提示词工程，以及如何落到产品和内部流程中。
- 提示词 - 指令文本；上下文 - 某一步模型的完整输入
- 转向 - 从“找一句魔法话术”到“组装正确的数据包”
- 层级 - system、检索、记忆、工具、任务状态、策略
- 目标 - 稳定、少幻觉、控制 token 成本
- 实践 - 窄而相关的上下文，胜过“一股脑塞进窗口”
- 对企业 - 流程与架构，胜过 ChatGPT 里一次走运的对话
什么是提示词工程 - 以及它碰到的天花板
提示词工程（prompt engineering）是指把对 LLM 的请求写清楚，以得到期望的风格、格式与行为：角色（“你是资深分析师”）、few-shot 示例、思维链、严格输出模板。
它很适合：
- 聊天里的一次性任务；
- 生成草稿；
- 教团队“怎么问模型”；
- 没有内部数据的原型。
上限很快显现：
| 场景 | 为什么单靠提示词不够 |
|---|---|
| 需要最新价格与制度 | 没有检索，模型不知道你的价目表 |
| 长对话 / 带工具的智能体 | 窗口被噪声占满，焦点丢失 |
| 多角色、多系统 | 一个“万能”system prompt 会稀释 |
| 风险与合规控制 | 策略与 PII 脱敏不是“漂亮一句话” |
| API 成本 | 每轮多余 token = 直接亏损 |
提示词仍是系统的一部分。但它不再是质量的主杠杆。
什么是上下文工程
上下文工程（context engineering）是设计每次调用时模型的完整输入包：什么放进 system、从知识库抽什么、从记忆取什么、展示哪些工具结果、丢掉什么、禁止什么。
如果说提示词是“怎么问”，上下文就是“模型在怎样的信息环境里回答”。
典型上下文层级：
- 指令与角色 - system prompt、回答策略、JSON/Markdown 格式。
- 用户任务 - 当前请求与最少必要历史。
- 检索到的知识 - 来自 wiki、CRM、代码、FAQ 的片段，经搜索/RAG。
- 状态 - 漏斗阶段、成交 ID、文档版本、上一步结果。
- 工具观测 - API、SQL、浏览器、MCP 工具输出。
- 约束 - “不要承诺折扣”“不要引用 PII”“升级给人工”。
上下文工程师像流水线架构师一样思考，而不是像碰运气的文案写手。
上下文如何取代了“提示词魔法”
| 过去（以提示词为中心） | 现在（以上下文为中心） |
|---|---|
| 包打天下的长 system prompt | 窄 prompt + 动态组装输入 |
| 把整份 PDF 贴进聊天 | 检索：只取相关 chunk |
| “记住整段对话” | 压缩、摘要、选择性记忆 |
| 一个模型 - 一个聊天 | 智能体、编排器 + 子智能体、分开的窗口 |
| 质量 = 措辞手艺 | 质量 = 相关性、新鲜度、层级顺序 |
| 调试提示词文本 | 调试来源：检索 miss、工具失败、溢出 |
范式转变并不等于提示词“死了”。它们成了检索、记忆、工具与策略旁边的一层 - 就像 SQL 查询旁边还有库表结构与索引。
为什么 2025-2026 加速转向
多个因素叠加：
- 智能体与工具 - 模型不只回答，还会行动；上下文必须包含工具结果。
- 长窗口 - 能塞更多，但无筛选的“更多”= 噪声与更贵。
- 企业数据 - 没有 RAG 与文档版本，业务答案就没用。
- 多智能体 - 每个子智能体需要自己的窄 brief，而不是共享完整日志。
- 成本与延迟 - 上下文工程师像后端优化 payload 一样优化 token 预算。
因此实践从“prompt engineer”转向搭建上下文流水线的 platform/ML 与产品角色。
实践：为单一步骤组装上下文
调用 LLM 前的可用清单：
- 步骤目标 - 输出应是什么（JSON、决策、草稿）。
- 最少指令 - 不要重复工具与数据已提供的信息。
- 检索 - top-k 片段并带元数据（来源、日期、版本）。
- 历史 - 只保留相关回合或短摘要，不是整条线程。
- 工具输出 - 可保留原文但要截断；不含密钥与多余字段。
- Token 预算 - 硬上限；溢出时优先级：指令 → 任务 → 事实 → 历史。
- 策略 - 模型在没有人工时不得声称的内容。
客服示例：
[system] 角色 + 禁令 + 格式
[retrieved] 3 条知识库片段（带日期）
[state] 工单号、客户套餐、语言
[user] 当前问题
不要这样：
[system] 四页“请保持有帮助...”
[history] 完整 80 条消息
[files] 整个 Notion 空间
[user] 问题
上下文 vs 提示词：回答差时改什么
| 症状 | 常靠提示词修 | 常靠上下文修 |
|---|---|---|
| 语气/格式不对 | 是：收紧指令 | 很少 |
| 捏造事实 | “不要编造”帮助有限 | 检索 + 无来源则拒绝 |
| 内容过时 | 在 prompt 里加日期 | 文档版本 + 新鲜度过滤 |
| 模型“忘了”任务 | 结尾再强调 | 把 goal/state 单独成块 |
| 又贵又慢 | 删客套话 | 砍历史与检索噪声 |
| 危险动作 | “请谨慎” | 去掉工具 / 要求 human-in-the-loop |
调试原则：先数据和筛选，再措辞。
对企业意味着什么
若你把 AI 接入 CRM、客服、内部搜索或编码智能体：
- 预算从“给经理上提示词课”转向语料质量、索引、日志与访问策略。
- 质量 KPI：检索命中率、带来源回答占比、单场景成本、人工升级次数。
- 提示词手册对人工聊天仍有用 - 但产品级 AI 建的是上下文流水线。
- 长上下文、RAG、微调之间的选择是独立的架构决策；见选项解析。
老板成熟度自测：你能否说明昨天那个客户案例里，模型用了哪些来源？不能 - 你仍停留在聊天里的提示词工程，而不是系统里的上下文工程。
常见错误
- 因为窗口长，就把“所有东西”塞给模型。
- 维护一份巨型 system prompt，而不是动态组装。
- RAG 文档不版本化 - 自信但过时的回答。
- 把编排器完整日志交给子智能体，而不是短 brief。
- 把密钥和 PII 塞进上下文“因为对模型方便”。
- 把改措辞当成修数据缺口。
总结
提示词工程教会我们如何与模型对话。上下文工程教会我们构建系统：让模型恰好拿到该步骤需要的信息、工具与边界 - 不多也不少。2026 年，企业 AI 质量不由“魔法句子”决定，而由流水线决定：事实筛选、记忆、工具、策略与 token 预算。提示词仍是流水线的一部分 - 但已不是主角。
常见问题
上下文工程和提示词工程有何不同？
提示词工程聚焦指令文本。上下文工程覆盖模型的完整输入：指令 + 检索事实 + 历史 + 状态 + 工具结果 + 禁令。提示词是一层；上下文是组装这一层以及其他层的系统。
2026 年还需要提示词工程吗？
需要，作为技能与一层。 清晰指令、格式与 few-shot 仍然重要。但在产品和智能体场景，没有数据筛选、记忆与策略，一条“完美提示词”无法稳住质量。
这和 RAG 一样吗？
不一样，更广。 RAG 是用语料知识填充上下文的一种方式。上下文还包括对话记忆、工作流状态、工具输出、角色与安全策略。RAG 是典型且重要的组件，不是整门学科。
公司应从哪里开始？
选一个场景（客服、规章检索、销售助手）。固定事实来源，加上带日期/版本的检索，把历史压成摘要，并记录“什么进了上下文”。等数据不再说谎后再微调提示词。
怎么判断是上下文问题而不是模型问题？
如果换模型（GPT → Claude → Gemini）错误几乎不变，但换文档 / top-k / 裁剪历史会变 - 问题在输入组装。只有在上下文流水线透明可测之后，再考虑换供应商。