当一个客服系统答错问题时，团队常常先修改提示词。但如果传入的是旧规则、错误订单或不完整的行程资料，再好的表达要求也无法修复事实本身。上下文设计应当与界面、接口一样，成为独立的工程工作。
把资料分成三个层次
Anthropic 将上下文工程描述为持续选择和维护模型所需信息的过程，而不只是编写一次提示词。[1] 对企业应用，我们建议先区分三类信息：相对稳定的规则、随业务变化的状态，以及本次任务的目标。
退款政策属于规则，订单是否已出库属于状态，客户希望改地址属于当前目标。混在一份长文档里，系统很难解释信息冲突时该如何处理。分层之后，可以分别设置负责人、更新频率和读取方式。
每条关键事实都应能回答“从哪里来”
一条可用于决策的业务事实，至少应带有来源、更新时间和关联对象。比如“车辆已归还”必须对应具体行程和记录时间；它不应因为上一次对话提到过，就被无条件沿用到新的订单。
可以为界面设计一个简短的依据区：本次使用的订单、引用的政策版本，以及无法确认的字段。它不需要展示模型内部推理，而是呈现业务人员能核对的证据。来源不可用时，应清楚说明缺失项，并把下一步交给合适的人或系统。
只取当前任务需要的信息
资料越多并不必然意味着回答越好。[1] 在实际设计中，可先用身份、订单和业务类型缩小范围，再检索与问题有关的规则。这样的查询路径也更容易解释：系统为什么读取这些内容，而没有读取其他客户的数据。
例如处理还车地点问题，通常需要本次行程的地点说明和有效时间，不需要整个客户历史。权限过滤应发生在数据读取环节，不能依赖一句“不要透露无关信息”来补救。涉及跨客户资料时，要用测试验证隔离边界。
让信息缺失成为一种正常状态
上下文设计还包括如何承认不知道。没有最新物流状态时，系统可以返回最后确认的时间并提示人工核实；政策适用条件不完整时，可以先补问条件。凭空补齐一个看似合理的答案，会把数据问题隐藏得更深。
我们建议把资料维护纳入运营流程：谁更新、谁审核、旧版本如何退出、异常由谁处理。评估时除了检查答案，还要检查所用依据是否属于正确对象和有效版本。对企业系统而言，可核对的回答比流畅但无法追溯的回答更容易进入日常工作。
挑一条系统最常回答的问题，逐项核对：对象是否正确、来源是否可靠、规则是否有效、缺失时如何处理。
参考资料
本文结合公开资料与 Terriva 的方法建议整理。文中的假设场景用于说明设计思路，不代表客户实绩。