上下文五问

一句话理解：设计上下文就是逐步回答五个问题——给什么（What）、何时给（When）、给多少（How much）、从哪来（Where from）、冲突时谁优先（Priority）。

前两课讲了上下文是什么、从哪里来。到了写方案的时候，产品经理常常卡在一个地方：知道“要给模型足够的信息”，却说不清 具体到这一步 应该给哪些、给到什么粒度。结果要么什么都往里塞，要么靠研发凭感觉决定。

“上下文五问”是一套可以落到文档里的设计方法。它的价值在于把一个模糊的目标——“让模型看到正确的信息”——拆成五个能讨论、能评审、能测试的决策。

五问总览

问题	要做的决策	答不好会怎样
What：给什么	这一步做判断所需的 最小充分信息集	缺信息就猜；多余信息造成干扰
When：何时给	预先装入、某一步触发、还是模型主动去取	太早给占预算，太晚给已经判断错
How much：给多少	原文、摘录、摘要还是一个 ID	全文淹没重点，摘要丢失关键细节
Where from：从哪来	用哪个系统、哪份文档、哪个版本	取到过期或非权威的数据
Priority：谁优先	信息冲突、预算不够时的取舍规则	模型随机选边，结论不稳定

五个问题按顺序回答，答案最终汇成一份“上下文规格”：

逐一回答五问：以一次退款排查为例

What：从“要做的判断”倒推信息

不要从“我们有哪些数据”出发，而要从“这一步要做出什么判断”倒推。

任务：判断订单 ORD-1024 的退款为什么迟迟没有到账。

写出“不需要知道”同样重要。它是之后砍上下文的依据。

When：信息在什么时机出现

同一条信息，放在不同的时机，效果不同。常见的四种时机：

时机	适合的信息	客服场景的例子
会话开始时预先装入	每一步都需要、体积小	角色、区域、问题分类标准
某个阶段开始时注入	只在特定阶段需要	进入“生成处置建议”阶段时，注入补偿标准
模型主动调用工具获取	是否需要取决于中间结果	发现订单已开票后，才去查发票作废记录
程序在触发条件满足时推送	必须遵守、模型可能忽略	当 Agent 准备建议“退款”时，程序注入资金操作审批规则

最后一种特别值得产品经理关注：模型不一定会主动去查它“应该”知道的规则。 对高风险规则，与其寄希望于模型主动检索，不如由程序在触发点强制注入，更关键的规则还应该由程序直接校验（参见 程序校验优先）。

How much：粒度的四个档位

以一次支付流水查询为例，四个档位分别是：

判断方法：

• 结论只依赖统计特征 → 摘要（档位 2），并由程序生成，而不是让模型从全文里数。
• 需要逐字核对 → 相关片段（档位 3），例如发票号、合同条款原文。
• 暂时不确定要不要看 → 只给引用（档位 1），让模型需要时再取。
• 全文（档位 4）只在信息量本身就小、或确实需要全局理解时使用。

这也是工具设计要回答的问题：工具默认返回哪个档位？能否通过参数选择？参见 并行调用与调用链 中关于“结果过大时怎么处理”的部分。

Where from：指定权威来源

同一个事实常常在多个地方都有：订单状态在订单系统里有，在客服工单的备注里也有，在上周导出的 Excel 里还有。必须为每类关键事实指定 唯一权威来源：

事实	权威来源	非权威来源（不应作为依据）
订单状态	订单系统实时接口	工单备注、导出表格
退款政策	知识库中标记“生效中”的最新版本	群聊截图、旧版 PDF
客户合同价	合同系统	销售口头说明

权威来源一旦确定，就能写进指令和工具描述，也能在评测中检查 Agent 有没有“用错来源”。

Priority：冲突与预算的两套规则

优先级要回答两类问题。

第一类：信息冲突时信谁。 一个常见的默认顺序（具体业务要调整）：

注意，“用户陈述优先级低”不等于忽略用户。好的做法是：以系统数据为准做判断，同时 在回复中明确指出冲突，例如“系统显示退款已于 9 月 12 日被驳回，与您的描述不一致，建议核对退款单状态”。

第二类：预算不够时先砍谁。 上下文快满时，需要一份事先约定的淘汰顺序，例如：先清理已使用过的旧工具结果 → 再压缩早期对话 → 再缩减知识片段数量 → 系统指令与任务状态最后才动。具体技术会在「长任务的上下文管理」一课展开。

把五问写成“上下文规格”

五问的答案最好写成一份简短的规格，放进 PRD 或技术方案，每个关键步骤一份：

step: 判断退款失败原因
what:
  required: [退款单状态与金额, 订单开票与发票作废状态, 退款错误码, 生效中的退款政策]
  excluded: [完整支付流水, 客户投诉历史]
when:
  preload: [用户角色与区域, 问题分类标准]
  on_demand: [发票作废记录]       # 发现订单已开票后再查
  forced: [资金操作审批规则]       # 建议涉及退款时由程序注入
how_much:
  支付流水: 摘要（程序生成）
  退款政策: 相关条款原文，最多 3 段
where_from:
  订单状态: 订单系统 API
  退款政策: 知识库 status=生效中
priority:
  conflict: 系统数据 > 知识文档 > 用户陈述；冲突需在回复中说明
  budget: 先清理旧工具结果，再压缩对话

这份规格就是研发实现、测试编写与线上排查的共同依据。

常见误区

• “多给点信息总没错。” 与判断无关的信息不仅浪费成本，还会成为干扰项，降低准确率。What 要同时写“需要”与“不需要”。
• “规则写进 System Prompt 就会被遵守。” 指令越长，单条规则越容易被忽略。关键规则要考虑在触发时注入，甚至由程序校验。
• “优先级让模型自己判断。” 模型在冲突面前没有稳定的偏好。不写清楚，就会得到时而信系统、时而信用户的结果。

产品经理检查清单

• 每个关键步骤有没有一份上下文规格？
• What 部分是否写了“不需要的信息”？
• 高风险规则是依赖模型主动检索，还是在触发时强制注入或由程序校验？
• 大体积数据的默认粒度是什么？由程序还是模型做摘要？
• 每类关键事实是否指定了唯一权威来源？
• 冲突优先级与预算淘汰顺序是否写清楚，并有对应的测试用例？

练习

为订单售后诊断 Agent（或你自己的 Agent）选 3 个关键步骤，例如“定位问题类型”“判断责任方”“生成处置建议”：

1. 为每一步写一份上下文规格（可以直接套用上面的 YAML 模板）。
2. 构造一个“信息冲突”的测试用例：系统数据与用户陈述不一致，写出你期望 Agent 的回复。
3. 和一位工程师一起过一遍，记录他认为实现难度最高的一项。

下一步

五问回答的是“应该给什么”。下一课「上下文腐化」会解释为什么上下文不是越多越好：注意力稀释、干扰信息与“中间遗忘”。