定义：决定看什么
上下文工程是在每次调用前决定三件事：给模型哪些信息、按什么顺序排列、留多少空间。它不是写更长的提示，而是像编辑一样筛选、排序与压缩，让有限的上下文窗口装进最相关的证据与约束，其余果断舍弃。
检索只是其中一环
检索负责找资料，上下文工程还要管重排、去重、版本与冲突。同一份制度有新旧两版时，若两段都被塞进去，模型可能引用作废条款；上下文层要能判断哪一版有效，并在输入里标注时间与出处，否则越检索越乱。
结构比长度重要
把材料按标题、字段、来源、时间组织成结构，比堆成一段长文更容易被正确使用。实践中常把证据放在前、问题放在后，并给每段加简短标签；顺序与标签看似琐碎，却直接影响模型引用哪一条，值得在验收时固定下来。
预算要显式分配
上下文窗口有限，系统指令、知识片段、对话历史与工具返回都要占位。若不设预算，历史会越滚越长，把关键证据挤出窗口。常见做法是给每类内容设上限，超限时按重要性摘要或截断，并记录被丢弃的内容。
评测靠消融实验
判断某类上下文是否有用，可以把它拿掉再跑同一批问题，看准确率与引用正确率的变化。加内容不一定变好，有时反而引入冲突；用消融而不是直觉决定保留什么，是上下文工程与调提示最大的区别，也最容易被忽略。
适用与不适用
适合谁
- 已有知识库或文档系统、问答质量不稳的企业
- 客服、售后、法务等需要引用出处的场景
- 准备把检索接进业务系统的技术团队
不适合谁
- 知识尚未整理、也没有责任人的团队
- 只需要单轮生成、不依赖外部资料的场景
典型场景
某电梯企业的售后助手要回答故障处理问题。团队把备件手册、故障码表与近两年工单整理成带出处的条目，每次提问按机型与故障码筛选，只投放相关段落并标注版本。答不出时明确回复信息不足，转由工程师处理，答复里一并给出条款号。
可执行步骤
- 列出回答一类问题所需的三到五类证据，写清每类来源与用途，形成清单
- 为每类证据设字数上限与优先级，超限时按规则压缩或摘要，并记录丢弃内容
- 按来源、时间与适用范围给证据打标签，标明版本与生效时间，方便复核与追溯
- 用同一批问题做消融，逐类删掉看指标变化，再决定保留、压缩还是彻底替换掉
常见坑
- 把整份手册塞进窗口，关键条款被大量无关段落稀释，模型引用错误页，返工难定位，排查时只能从头再来。
- 检索结果不标版本，新旧制度同时进入上下文，模型引用作废条款，对外答复出现偏差，责任却由一线承担。
- 不设预算，多轮对话把历史越滚越长，最后把证据挤出窗口，答案退化成闲聊，用户不知道该信哪一次。
- 只加内容不做消融，无法判断哪类材料有用，系统越改越贵，准确率却不动，最后只能整体回退重做。
自检与验收清单
- 是否列出每类问题所需的证据类型、来源与用途
- 证据是否带来源、时间与适用范围三类标签，并标注版本
- 是否给每类内容设了预算上限与压缩规则，并留记录
- 是否做过删除某类上下文的对比实验，并留结论
常见问题
上下文工程和提示工程是什么关系？
提示工程管指令怎么写，上下文工程管材料怎么选，两者互补。指令再清楚，证据缺失或过期也没用；材料齐全而指令含糊，模型同样会答偏。实际项目里通常一起改，但要分开评测，才能知道问题出在哪一环。
上下文越长效果越好吗？
不是。过长会稀释约束、引入冲突，还推高延迟与用量。有效做法是按问题筛选相关证据，控制每类内容的篇幅，并保留来源与时间；宁可少给几段可靠材料，也不要把整个窗口塞满，后者的维护成本更高。
没有知识库能做上下文工程吗？
可以先做小范围，例如只整理一个产品线的手册与常见问题。但没有结构化底稿时，筛选与标注的成本很高，效果也不稳定。更稳的顺序是先整理知识与责任人，再做上下文组装，否则只是把混乱搬进窗口。