错误来自缺信息吗
抽查一批错误回答，逐条标注是没拿到关键条款、拿到了旧版本，还是被无关内容干扰。若多数错误与材料有关，上下文工程的收益最直接；若错误集中在指令含糊或输出格式不对，先改提示更划算。两类问题常混在一起，最好由业务与技术各判一次。
知识有无底稿
有结构化文档、有版本与责任人，才谈得上筛选与排序。若知识还散在个人电脑与聊天记录里，先做知识整理，再谈上下文组装。在混乱数据上做上下文工程，只会把噪声更快地送进模型，返工的成本更高。
问题类型集中吗
问答类型越集中，上下文骨架越容易设计，维护成本也越低。若每天面对上百种互不相关的问题，一套骨架难以覆盖，收益会被维护成本吃掉。先做占比最高的一两类，验证效果后再扩展，是更稳的顺序。
有无评测集
没有一批带标准答案的问题，就无法判断上下文改动是否有效。问题集不必很大，几十条覆盖常见与边界即可，关键是答案可核对、判定标准一致。评测集要随业务变化更新，否则半年后就失去参考价值。
谁维护规则
上下文规则会随文档更新、业务调整而失效，必须有人负责版本、来源与冲突处理。文档变更时同步更新规则，听起来琐碎，却是系统能活过半年的关键。没有人维护时，系统会在几个月内给出过期答案，而且很难被察觉。
适用与不适用
适合谁
- 已有文档系统与知识责任人的企业
- 问答错误集中在材料层面的业务场景
- 技术团队能与业务共同做归因的企业
不适合谁
- 知识散落、无人整理也无责任人的团队
- 错误主要来自指令与交互设计的问题
典型场景
某连锁药店的用药咨询助手答错率偏高。团队抽查两百条错误回答，发现六成是引用了旧版说明书，另有两成是问题超出范围仍强行作答；补上版本过滤与来源标注，并把评测集扩到八十条边界问题后，错误才明显收敛。
可执行步骤
- 抽查一批错误回答，逐条标注是缺材料、旧材料还是指令问题，并统计占比
- 盘点知识底稿，确认是否有版本、责任人与适用范围，缺的先补齐，避免一次铺开。
- 统计一周内的问题类型分布，挑出占比最高的两类先做试点，其余暂缓上线
- 建一份几十条问题的评测集，包含边界、空输入与拒答样本，并按月更新，并保留更新记录。
常见坑
- 把指令问题误判成材料问题，不断加文档却不见好转，团队开始怀疑模型，真正的原因被掩盖，时间也耗掉了。
- 知识底稿没有版本，新旧内容混在一起，上下文再精巧也挡不住引用作废条款，排查也很慢，维护成本更高。
- 问题类型过于分散，骨架刚上线就遇到大量例外，维护成本迅速超过收益，最后不了之，只能停用重做。
- 没有评测集就上线，改完说不清好坏，只能凭印象决定保留哪版，争论无法收敛，很可惜，团队也会疲惫。
自检与验收清单
- 错误回答是否做过材料与指令的归因统计，并留档
- 知识是否有版本、责任人与适用范围，且可追溯，且可逐条核验。
- 是否有答案可核对、判定标准一致的评测集，并定期更新
- 是否指定了上下文规则的维护人，并列入岗位职责
常见问题
上下文工程投入大吗？
主要成本在知识与规则整理，不在工具采购。若文档已有版本与责任人，改造周期通常以周计；若要从零整理，先算清这部分人力，再决定是否立项，别把整理成本当成技术成本，否则预算会低估。
没有评测集能先上线吗？
可以小范围试，但很难判断改动是否有效。建议至少准备几十条带标准答案的问题，覆盖常见与边界情况；边用边补也可以，但要有人负责更新，否则评测集会迅速过期，失去对照作用。
这套做法和换模型冲突吗？
不冲突。上下文骨架稳定后，换模型只需重跑评测，不必重写全部材料。反过来说，若每次换模型都要重构上下文，说明骨架与模型耦合过深，应先把材料与指令分离，再做迁移和对比。