知识库改了提示词后，怎样确认旧问题没有答坏

知识库改提示词后，应对同一套固定题集运行前后两个版本，并逐题记录改善、退步和不确定项。只验证刚修好的问题，会遗漏新提示对其他问题的影响。本文讨论日常配置迭代的回归测试，适合业务与技术共同维护知识库的团队；不涉及模型大版本迁移，也不假设平台自带完整回归系统。

为什么一个补丁会损坏旧题

合成售后助手原来回答过长，维护人员加入“所有回答不超过两句”。新的保修期限题变得简洁，但涉及耗材例外的题漏了限制，涉及两份冲突文件的题也不再解释版本。短答案改善了阅读体验，却可能让关键条件消失。

因此本轮回归的变更项必须写得具体：从提示版本P7到P8，仅新增长度约束，其他配置不变。若同时更新了资料、检索数量和回答模型，就无法用结果解释提示本身的影响，应另拆变更或按完整方案验收。

保存原提示、知识快照、应用配置、文档清单和题集版本，并记录负责人及测试日期。模型名称相同也可能存在提供方更新，应记录可获得的精确版本信息；无法锁定时，把它列为实验限制。保留旧答案的原始响应，避免只保存人工整理后的摘要。

固定题集由已通过的常见任务、曾经修复的故障和重要边界题组成。正常题检查可用性，无答案题检查有没有编造，冲突题检查有没有省略限定，权限题检查有没有泄露。新发现的问题可以加入下一版题集，但不要在看完本轮结果后偷偷改当前评分条件。

先运行P7再运行P8，或者使用隔离环境交替执行；始终使用相同输入与账号角色。需要会话历史的题保留完整轮次，其余题从新会话开始。每条记录关联应用配置、题集与原始请求，出现争议时才能复查。

附件提供固定题、预期、前后结果与处理决定字段，实际答案留空。这里没有目标平台实测，所以不会把模拟变化写成通过率。正式报告可分别统计原通过变失败、原失败变通过、双方均通过及双方均失败，后两类也要抽看是否出现新的错误表达。

评审时先隐藏版本标签，减少维护人员对新版本的偏好。对于“更简洁”“更友好”这样的体验项，单列主观评分；事实、依据和边界条件应依据事先规定的行为标准判断。不能让语气更自然抵消政策答错。

权限泄露、无依据承诺或执行错误动作，可以按项目约定设为阻断项。普通措辞变化则无需每个字一致。对于输出给业务系统的结构化字段，还要检查字段类型、必填项与错误分支，文本读起来合理不代表接口兼容。

若一条旧题退步，应先确认是否因标准答案过时。资料更新导致正确结论变化，不属于系统质量下降，但必须有业务负责人确认和版本依据。不能为了让测试变绿，把新答案直接抄成标准答案；这会让回归失去独立判断。

对于不稳定题，可在两版本上各执行同样次数，记录每次结果和生成配置。一次成功不能代表稳定修复；重复失败也不一定说明提示是唯一原因。应检查检索上下文是否相同，再确定下一步修改。

报告应说明本轮想修什么、实际修好了哪些、引入了什么退步以及谁接受剩余问题。若“最多两句”损坏例外条款，可以改为“优先简洁，必要条件不得省略”，然后重跑受影响子集与关键全量题。

发布后保留旧配置的恢复路径，观察真实问题并补进后续回归。回退不是删除新提示文件，而是恢复应用实际调用的配置，并用探针确认旧行为已恢复。配置、题集和结论应能一一对应，不能只给新版本起一个好记的名字。

当日常迭代频繁到人工对照无法跟上，可把执行和差异汇总自动化；评分规则、资料归属和上线决定仍需明确责任人。回归的目标不是禁止改动，而是让每次改动的收益与代价都能看见。

题集维护本身也需要版本。新增一题时注明来源工单和预期依据，删除一题时注明重复、失效或超出范围的理由。报告同时保存当轮题目清单，防止下次运行时因题量变化导致通过率不可比。对重要业务动作，应加一条确认没有产生真实写入的检查，让回归环境与生产操作明确分离。

签署结果前，双方还应核对附件中的实际记录与报告一致，并明确没有执行的验证项，避免把演示预期误作真实成绩。

技术边界参考Dify 官方知识检索节点说明：检索结果作为下游节点的上下文。本文的题集、评分规则和样例是项目工程方法，并非平台自动提供的验收保证。文档核对日期为2026年10月23日，目标部署应另记版本。

可下载本文合成样例与记录表，附件里的数据只用于演示核对方法，请在副本中填写目标环境结果。更多背景可看专题与相关原理及交付说明。需要把这套核对接进已有业务系统，可带上脱敏材料、当前版本与失败记录，通过定制咨询讨论范围；集成商可查看系统集成协作。