第一步：定义证据清单
先写清回答一类问题需要哪几类证据，例如制度条款、历史工单、产品参数、变更记录。把类型与来源列成清单，再决定接哪些数据源；没有清单就接检索，往往接进大量无关内容，后面清理成本更高，值得先做。
第二步：搭上下文骨架
固定骨架：系统约束、任务说明、证据区、问题区、输出格式。证据区按来源与时间标注，问题区只放当前问题。骨架稳定后，换模型或换数据源只改局部，不必每次重写整段提示，便于交接，也减少重复沟通。
第三步：设预算与压缩
为每类内容设字数或条数上限，超出时按规则压缩：去重、摘要、只留结论句、截断旧历史。被丢弃的内容要记录，便于复盘答错原因；没有记录时，问题一出现就只能靠猜，改进也无从下手，容易反复返工。
第四步：消融与灰度
上线前做消融：去掉某类上下文，看准确率与引用正确率如何变化，保留真正有贡献的部分。上线后按小流量灰度，比较新旧链路的错误类型，确认不是靠更多上下文掩盖了检索质量问题；评分标准要前后一致。
验收与边界
验收看三项：答案是否有可核对出处、超出知识范围是否明确说不知道、同类问题回答是否稳定。不承诺具体准确率，但抽样方法与判定标准要事先写清，由业务方参与盲评，技术方只提供记录与材料。
适用与不适用
适合谁
- 已有结构化文档与责任人的企业，且有人牵头
- 问答场景需要引用出处与版本，错答代价高
- 技术团队愿意配合业务做盲评的项目
不适合谁
- 知识还在个人电脑里、也无责任人的团队
- 期望一次调优长期不改、也不做评测的项目
典型场景
某城商行的信贷政策问答，先把制度按章节切成条目并标注生效时间，上下文骨架固定为约束、条款、问题三段，每段限字数。上线前做消融，发现历史问答记录贡献很小，去掉后准确率未降反而更快，于是从默认上下文中移除。
可执行步骤
- 写出回答一类问题所需的证据清单，标明来源与用途，形成一页纸便于评审
- 把上下文拆成约束、证据、问题三段，固定顺序与标签，减少随意改动并便于交接
- 为每段设字数上限，超出时按规则摘要或截断，并记录被丢弃的内容与原因
- 用同一批问题做消融，再小流量灰度，比较新旧链路的错误类型与引用正确率
常见坑
- 直接接检索不设计骨架，模型每次收到格式不同的拼接文本，输出忽好忽坏，问题无法复现，也无法归因。
- 不设预算，多轮对话与工具返回把证据挤出窗口，答案开始绕圈，用户以为系统坏了，客服只能人工兜底。
- 证据不标时间，旧政策混进答复，业务照做后被驳回，返工与投诉一起来，信任受损，最终只能停用重做。
- 只做一次调优就上线，文档更新后上下文失效，没人发现，直到客户投诉才紧急回滚，代价更高，也更被动。
自检与验收清单
- 是否列出每类问题所需的证据清单、来源与用途
- 上下文是否固定骨架，并标注来源、时间与版本，可追溯
- 是否为每段内容设了预算与压缩规则，并留丢弃记录
- 是否做过消融与灰度对比，并留下结论，定期演练
常见问题
上下文骨架需要多复杂？
够用即可，通常五段：约束、任务、证据、问题、输出格式。段数越多维护越难，团队往往写得很长却没人更新。先用最小骨架跑通一个场景，再按实际问题增加段落，比一次设计完美结构更可靠。
预算怎么定？
按模型窗口与业务需要分配，给证据留出主要空间，历史与工具返回设硬上限。定完用真实问题压测，看关键条款是否被挤出；若经常被挤，说明检索筛得不够准，应先改筛选而不是简单加预算。
验收要业务方参与吗？
要。出处是否正确、答复是否符合业务口径，只有业务方能判定。技术团队可以提供准确率与引用率，但最终结论应由业务盲评给出；否则系统可能指标好看，实际答复却不能用，上线后返工更贵。