上下文工程是什么？让 AI 拿到当前任务真正需要的信息

区分指令、事实与工作状态

指令说明当前目标与约束；资料提供业务事实；状态记录已经完成什么、还有哪些问题未解决。混在一起时，模型可能把旧需求当成新任务，或把文档中的话当作操作要求。

为资料保留来源与版本，针对当前任务加载必要内容。已经失效的条件应明确移出，重要决定则保留简短而准确的记录，避免每次重新推断。

按当前问题选择资料

客户询问某个型号时，优先提供该型号的有效说明和当前需求，不必同时加载所有产品目录。需要比较时再增加相关资料，并保持不同来源之间的区别。

Anthropic 的上下文工程文章讨论了信息筛选与持续管理。实际采用摘要、检索或按需读取时，应检查是否遗漏否定、例外和未决条件，不能为了缩短内容删掉影响判断的事实。

用错误类型判断该补什么

模型不知道某条企业规则，先查是否提供了有效资料；混淆历史与当前要求，检查状态整理；引用无关内容，检查检索与筛选。并非每个问题都需要更大的模型或更长的提示。

把一组任务在调整前后对比，观察相关来源是否更容易被使用、回答是否减少无依据内容。上下文设计最终要服务于业务结果，而不是追求输入文本的数量。

上下文选择从下一步任务出发

一次回答可能需要用户问题、业务规则、检索片段、工具结果和会话历史。它们的用途不同，应区分长期约束、当前事实和暂时线索。不能因为某段资料可以放入上下文，就默认它对当前判断有帮助。无关材料会增加查找和核对负担。

例如处理产品询价，当前型号的有效资料和客户原文通常比大量旧对话更关键。可以保留必要的历史结论及来源，将已失效的猜测排除。摘要也可能遗漏条件，因此重要数字、型号和正式承诺应保留可回查的原始依据。

用错误类型判断该删除、补充还是重排

当答案使用了旧规则，检查版本选择；当型号被混淆，检查对象标识；当模型忽略限制，检查条件是否完整且与结论相邻。没有证据表明问题来自上下文容量时，不宜首先增加输入长度。

比较时保持模型与任务样例一致，观察关键事实是否正确、来源是否匹配以及调用成本变化。上下文设计和提示设计相互配合，但前者首先关心提供了什么信息，后者进一步规定如何使用这些信息。

每个步骤只取得当前必要信息

在整理某型号需求时，只提供有效产品资料、客户原文与当前状态，分别标明指令、事实和未确认推断。用一组历史与当前条件冲突的样例检查是否误用旧要求，不以输入越长判断效果。