企业应用大模型时，一旦输出质量不稳定，最先被修改的通常是提示词。团队不断增加要求：语气要专业、结论要准确、格式要统一、不能遗漏信息。提示词越来越长，效果却未必持续改善。
这是因为大模型的回答不仅取决于“怎么问”，还取决于它在回答之前“看到了什么”。
同一句提示词，如果提供的客户资料、业务规则、历史记录和实时数据不同，最终结果自然不同。很多被认为是模型能力不足的问题，实际来自上下文缺失、过期、冲突或过量。
所谓上下文，可以理解为模型完成当前任务时获得的全部信息。它不仅包括用户的问题和提示词，还可能包括企业制度、产品资料、聊天历史、数据库查询结果、工具返回内容、用户身份以及当前任务状态。
提示词告诉模型应该做什么，上下文则决定模型依据什么完成。
例如，让大模型“判断客户是否可以退款”，仅仅把退款制度写进提示词还不够。模型还需要知道客户购买了什么产品、支付时间、服务是否已经使用、是否存在特殊协议，以及当前制度的生效版本。任何一项信息缺失，都可能改变结论。
上下文管理的第一个难点，是信息不完整。
员工可能只输入一句“这个客户能退款吗”，却没有提供订单编号和购买时间。模型如果为了完成任务而自行推测，就可能生成错误答案。
更可靠的系统应先检查必要信息是否齐全。缺少关键字段时，主动要求补充；能够从业务系统查询时，则在获得相应权限后自动获取。与其让模型在不完整信息上反复推理，不如先保证输入条件满足任务要求。
第二个难点，是信息已经过期。
企业的价格、产品规则、组织结构和审批流程都会变化。如果系统检索到旧版本文件，大模型可能非常准确地复述一条已经失效的规定。
因此，资料不能只标注标题，还要包含生效时间、失效状态、负责人和适用范围。检索时应优先使用当前有效版本；历史资料需要保留时，也要明确告诉模型它只用于追溯，不能作为当前结论的依据。
第三个难点，是不同来源互相冲突。
同一个业务规则可能同时出现在正式制度、会议纪要和员工笔记中，内容却并不一致。如果系统把这些材料一起交给大模型，模型可能自行选择其中一种说法，或者把不同规则拼接成一个看似完整的答案。
企业需要提前定义资料优先级。例如，正式发布的制度高于讨论稿，经过确认的产品说明高于个人记录，最新生效版本高于历史版本。无法判断时，模型应指出冲突并转交负责人，而不是替企业作出未经授权的选择。
第四个难点，是上下文过多。
一些团队认为，大模型能够读取的内容越多，回答就越准确，于是把大量文档、完整聊天记录和多年的业务数据一次性提供给模型。结果不仅增加了处理时间和成本，还可能让真正重要的信息被无关内容淹没。
上下文不是越长越好，而是越相关越好。
一个有效的检索过程，应根据当前问题找到最有可能提供答案的少量资料，同时保留必要的来源信息。对于篇幅很长的文件，可以先定位相关章节，而不是每次都发送全文。
对话历史也需要管理。用户前几轮表达的目标可能仍然有效，但早期的临时要求可能已经被后续决定替代。如果系统机械地保留全部聊天内容，大模型容易受到旧信息干扰。
比较合理的方式，是把长期有效的信息与临时对话分开。用户身份、业务规则和任务目标可以持续保留，已经完成的步骤则压缩为简短状态，过时内容及时移除。
第五个难点，是工具返回的信息缺少解释。
当大模型连接客户系统、数据库或搜索工具后，工具可能返回大量字段、状态码和空值。如果应用没有说明字段含义，模型只能根据名称猜测。
因此，工具设计也属于上下文管理。返回内容应尽量结构清楚，只包含当前任务需要的数据，并说明关键字段代表什么。发生查询失败时，要明确返回“未找到”还是“系统异常”，避免模型把技术故障理解为业务上不存在记录。
企业可以为高频任务建立一套稳定的上下文结构：任务目标是什么，需要哪些输入，允许使用哪些资料，哪些实时数据必须查询，输出采用什么格式，遇到什么情况应该停止并转交人工。
这套结构比一段不断加长的提示词更容易维护，也更容易测试。
评估大模型应用时，也应该记录每次任务实际使用了哪些上下文。输出错误后，团队需要判断是模型理解错误、检索遗漏、资料过期，还是业务数据本身有问题。
如果只保存最终答案，就很难找到真正原因。保留资料来源、工具调用和关键任务状态，才能让系统持续改进。
大模型本身具备的是通用语言和推理能力，企业上下文提供的才是具体业务事实。没有准确上下文，再强的模型也只能在不完整信息上进行猜测。
提示词决定了模型如何工作，上下文决定了模型有没有条件把工作做好。企业想让大模型从偶尔表现出色变成长期稳定可用，真正需要建设的，不只是一套提示词，而是一套能够持续提供正确、相关、及时信息的上下文机制。
