核心结论
上下文工程不是把资料全塞给模型，而是筛选、组织、排序、压缩和隔离信息，让 AI 在正确边界内完成任务。
适合谁
任务依赖内部知识库、客户资料、合同、历史案例、项目记录，且不同角色看到的信息不同的团队。
交付什么
上下文地图、知识分层、检索规则、权限策略、记忆策略、上下文压缩规范和敏感信息边界。
上下文工程的五个组成部分
业务背景
让 AI 理解任务发生在哪个业务场景。
知识来源
定义哪些文档、记录和数据可以被引用。
权限边界
明确不同角色、部门和任务能访问什么。
记忆策略
决定哪些历史信息需要保留，哪些应该丢弃。
压缩规则
把长资料压成可用上下文，减少噪音。
为什么 Prompt 不够了
Prompt Engineering 假设任务所需信息已经在当前对话里，或者用户能一次性提供清楚。但企业任务往往不是这样：资料散落在文档、表格、CRM、飞书、Notion、项目记录和历史邮件里，且每份资料都有时效、权限和可信度差异。
如果没有上下文工程，AI 会出现三类问题：第一，缺少关键背景，只能给通用建议；第二，被无关材料干扰，回答看似丰富但偏离业务；第三，读取了不该读取的数据，带来合规和信任风险。
上下文分层：不要把所有资料混在一起
| 层级 | 内容 | 管理重点 |
|---|---|---|
| 任务上下文 | 本次任务目标、输入材料、约束和输出要求。 | 保证短期任务清晰，不夹带无关信息。 |
| 业务上下文 | 客户背景、项目阶段、行业规则、内部术语。 | 让 AI 理解“为什么要做”和“给谁看”。 |
| 知识上下文 | 制度、案例、合同、FAQ、研究文档、产品资料。 | 控制来源、更新周期、引用规则和可信度。 |
| 权限上下文 | 角色、部门、数据等级、访问范围和脱敏规则。 | 防止越权读取和敏感信息泄露。 |
| 记忆上下文 | 历史偏好、历史决策、任务进展和用户反馈。 | 决定保留、更新、遗忘和人工确认机制。 |
四步建设上下文工程
第 1 步：画出上下文地图
先列出一个任务需要哪些信息：业务背景、输入资料、历史记录、权限规则、输出受众。不要先急着接知识库，否则很容易把“资料多”误认为“上下文好”。
第 2 步：给资料分级
按公开资料、内部资料、客户资料、商业机密、合规敏感数据分级。每一级对应不同处理方式：可直接使用、需脱敏、只本地检索、必须人工审批。
第 3 步：设计检索与压缩规则
检索不是越多越好。要定义召回数量、排序逻辑、去重规则、过期资料处理、长文摘要方式和引用来源，避免模型被噪音淹没。
第 4 步：设置权限和审计口径
谁触发任务、任务调用了哪些资料、哪些内容被模型读取、最终输出给谁，都应该能被记录。上下文工程和安全治理天然绑在一起。
上下文工程自检清单
- 这个任务需要哪些背景信息，哪些只是噪音？
- 资料来源是否有可信度、时效性和负责人？
- 不同角色是否应该看到不同上下文？
- 是否存在客户数据、合同、报价、内部制度等敏感资料？
- 长资料是否有压缩规则，而不是直接全部塞给模型？
- AI 输出是否需要引用来源或保留证据链？
- 上下文调用过程是否能被审计和复盘？
建议交付物
上下文地图
列出任务需要的背景、资料、权限、记忆和输出受众。
数据与资料分级表
标注哪些资料可用、需脱敏、需本地处理或需人工审批。
检索与压缩规范
定义召回、排序、引用、摘要和过期资料处理规则。
权限与审计口径
明确角色访问边界、调用日志和异常处理方式。