上下文工程实战：让 AI 在正确时间知道正确的事
先区分五种完全不同的信息
很多人遇到 AI 输出不对，第一反应是往 prompt 里加更多内容。结果越加越乱：旧要求和新指令打架，临时偏好被当成组织政策，一次调试的修改被当成永久规范。问题不在信息少，而在没分清信息类型。
真正有效的上下文工程，得先把信息分成五类：
规则
规则回答“允许怎样工作”。比如安全边界、目录权限、数据外送限制、发布流程、是否需要人工审批。这类信息必须短、明确、可审计，不能指望模型靠记忆偶然想起来。
事实
事实描述系统或业务当前是什么样。包括架构图、接口定义、客户口径、产品状态、数据字典、部署环境。关键是有时间属性——得标清楚来源、更新时间和适用范围，否则很容易过期误用。
方法
方法讲的是某类任务通常怎么做。比如怎么写安全审查报告、怎么归类用户反馈、怎么跑浏览器验收测试。这类内容适合做成 Skill、模板、脚本或运行手册，而不是每次重新解释。
状态
状态记录当前任务进行到哪一步：完成了哪些、卡在哪个决定、验证结果如何、预算剩多少、下一步该做什么。它的生命周期短，但对长期任务能否中断后恢复至关重要。
证据
证据是支持当前判断的具体材料：代码片段、命令输出、截图、数据库查询结果、用户反馈原文。它通常只和单次任务相关，不能未经确认就自动升级成组织级事实。
把这五类混在同一个“超级 prompt”里，会导致权威性和有效期混乱。更好的做法是：规则进规则层，事实进文档库，方法封装成 Skill，状态记在任务记录里，证据留在可追溯的工作材料中。
上下文质量由四个属性决定
不是所有信息都值得放进上下文。高质量上下文得看四个维度：
权威性
谁发布的这条信息？有没有资格定义当前行为？比如公司安全政策的权威性远高于某个用户的临时要求。个人不能靠一句话就绕过组织设定的权限边界。
新鲜度
一年前的架构文档可能早就失效，昨天的命令输出也只代表那个时间点的环境状态。判断事实不能只看文件标题是否“正式”，还得看日期、版本号和实际部署情况。
作用域
这条信息适用于整个公司、某个项目、某个目录、某类任务、某个人，还是仅限当前会话？作用域越明确，越不容易被误用到不该用的地方。
可复核性
能不能找到原始出处？比如代码位置、数据查询语句、批准记录或会议纪要。如果没法复核，就应该标记为“推断”或“记忆”，而不是包装成确定事实。
上下文装载不是全文检索
很多人把 RAG 简化成“问题转向量，找最相似的文档”。但语义相似不等于任务相关，更不等于权威。
成熟的上下文检索通常经过这几个步骤：
- 范围过滤：先按项目、租户、权限和时间筛一遍；
- 候选召回：结合关键词、向量、关系图谱和结构化查询；
- 权威排序：正式政策、当前代码、已批准决定优先；
- 新鲜度判断：过期文档降权，但不一定直接丢弃；
- 去重与压缩：只保留关键段落，不是整份文件塞进去；
- 冲突标记：不同来源说法不一致时，同时呈现让用户判断；
- 引用绑定：最终输出能回溯到具体来源。
举个例子：用户问“当前接口是否只读”。最相似的可能是份旧设计稿，但真正需要查的是当前路由配置、权限策略、部署版本和正式安全政策。代码能证明某个版本实现了写入功能，但不能证明这个写权限已经被批准上线。
上下文预算应该按任务阶段分配
模型上下文再大也不是免费的。信息堆太多，关键约束反而被埋没。可以按任务阶段动态加载：
规划阶段
只给目标、边界、架构概览、核心规则和成功标准。别一上来就塞整个仓库。
实现阶段
聚焦当前模块、接口契约、相关测试用例、局部历史和参考样例。不需要一次性读取全部代码。
调试阶段
重点加载失败日志、最小复现步骤、最近变更记录和对应的运行时配置。
审查阶段
提供原始需求、确认过的计划、完整 diff、验证结果，以及明确声明“范围外”的内容，避免把实现者的自我辩护当成证据。
恢复阶段
只恢复已确认的状态：完成项、失败原因、下一步计划和环境差异，而不是重新回放整段聊天记录。
这个过程叫“上下文路由”——根据任务类型和阶段，决定信息从哪来、以什么优先级进入、何时退出。
冲突必须分成两类处理
指令与授权冲突
这类冲突决定“能不能做”。平台安全边界、组织政策、法律合规要求，不能被个人临时指令覆盖。用户可以在授权范围内调整任务细节，但不能悄悄扩大生产权限、客户数据访问范围或外送能力。
事实与证据冲突
这类冲突决定“实际是什么”。判断依据是直接证据、新鲜度、作用域和可复核性。当前代码说明被检查版本的实现；命令输出反映某个环境在某个时间点的状态；但生产行为还得核对部署记录、运行配置和监控数据。
这两类冲突不能用同一条“越新越优先”的规则处理。昨天的日志不能授权危险操作，高权威的旧政策也不能证明系统没发生回归。
Memory 的正确位置
Memory 适合减少重复解释，比如：
- 用户偏好的文档结构；
- 常用的表达风格；
- 长期项目的名称和缩写；
- 已多次确认的低风险习惯；
- 经常配合使用的工具和格式。
但它不该承载：
- 唯一的安全规则；
- 生产凭据或客户数据；
- 系统架构的唯一真相；
- 权限、支付、合规边界；
- 尚未确认的推测。
记忆只是召回辅助，不是强制执行机制。不可绕过的要求仍需靠权限系统、策略引擎、CI 流水线、Git Hook 或人工审批来保障。
上下文污染是怎样发生的
把一次纠正当成永久规则
用户某次为特殊场景临时改了格式，系统却把它推广到所有项目，导致后续输出风格混乱。
把 Agent 推断写入事实库
模型根据不完整资料得出结论，下次又把自己的旧结论当来源，形成“自己信自己”的循环确认。
保存完整聊天而不提炼
长对话包含大量试探、错误路线和过期决定，未来根本分不清哪句话还有效。
跨租户召回
检索系统只看语义相似度，没先过滤权限和租户，结果把 A 客户的数据召回给 B 客户的请求，造成泄露。
页面提示注入
网页、邮件或文档里的文字被当成系统指令，诱导 Agent 改变目标或外送敏感信息。
治理措施包括：给每条信息打上来源标签、批准状态、版本号、租户标识、写入权限、到期时间，并要求人工确认。未经确认的内容只能进暂存区，不能自动成为权威事实。
案例：一个持续三个月的产品项目
项目初期建立四类文档：背景说明、已批准需求、关键架构决定、术语表。团队规则明确哪些目录可改、必须跑哪些测试、哪些用户字段禁止外送。常见工作流（如发布检查、反馈归类）封装成 Skills。
每个迭代任务只加载当前需求、相关模块和最近决策。开发中产生的日志和方案算临时证据；只有经人确认的架构调整才写入决策记录。任务结束时生成简短 handoff：完成内容、验证结果、未解决风险、下一步计划。
当新任务和旧文档冲突时，系统不会自动选一边，而是提示：“旧决定是三个月前的，当前代码显示有写入逻辑，请负责人确认是文档过期还是实现回归。”
三个月后，Agent 不需要记住所有对话，却能通过稳定结构恢复项目上下文。这才是真正的上下文资产，而不是聊天记录的垃圾堆。
衡量上下文系统是否有效
别只看知识库有多大，要看这些指标：
- 首次任务需要人工补充背景的次数；
- 因错误或过期上下文导致的返工率；
- 输出结论能追溯到具体来源的比例；
- 跨项目或跨租户误召回的次数；
- 相同任务重复解释所花的时间；
- 上下文中实际被使用的信息比例；
- 规则冲突被自动发现的比例；
- 状态恢复后重复执行步骤的次数；
- 未确认推断进入事实库的数量；
- 文档过期后被发现和更新的平均时间。
如果知识库不断膨胀，但人工解释和返工没下降，那它只是个存储系统，不是上下文工程。
常见误区
一切都存下来
原始资料可以归档，但进入 Agent 工作上下文前必须筛选、分层、加权限控制。
只做向量搜索
权限、版本、结构化关系、权威性这些维度，光靠语义相似度解决不了。
把规则写得极长
规则越长越难维护，也越容易隐藏冲突。规则层只保留必须执行的硬性要求，背景说明链接到正式文档。
依赖单个超长会话
会话会被压缩、中断、过期。长期状态需要独立、可验证的载体，比如任务记录或状态快照。
自动学习所有人工修改
用户修改可能是一次性例外。得先判断原因和作用域，再决定是否沉淀为通用规则或方法。
落地检查清单
- 规则、事实、方法、状态、证据已经分层管理；
- 每条长期信息有来源、日期、作用域和负责人；
- 检索前先执行租户和权限过滤；
- 语义召回后还有权威性和新鲜度排序；
- 冲突信息不会被静默覆盖，而是显式提示；
- 当前代码、测试环境、生产事实被明确区分；
- Memory 不承载唯一的安全与权限要求；
- 未确认的推断不能直接写入事实库；
- 不可信的外部内容（如网页文本）与系统指令隔离；
- 长任务状态可以跨会话恢复；
- 过期内容有定期复审和淘汰机制；
- 最终输出能关联到实际使用的具体来源。
上下文工程的目标，从来不是让模型“记住一切”，而是让它在正确的时间知道正确的事，并且清楚这些信息从哪来、是否还有效、能支持什么行动。当五类信息各归其位，Agent 才能在减少重复解释的同时，守住治理底线。