企业 AI 重复答错，通常不是“模型记性不好”，而是错误没有进入组织的修复流程。一次纠正只留在聊天窗口，下一个员工换个问法，Agent 还会再错。知识缺口必须像缺陷一样进入队列，有证据、有责任人、有版本、有复验。
先把缺口分成五类
| 类型 | 现场表现 | 正确处理 |
|---|---|---|
| 缺失 | 没有找到可信依据 | 指定 Owner 补充事实源 |
| 冲突 | 两份文件给出不同结论 | 裁定现行入口与替代关系 |
| 过期 | 找到的是旧价格、旧制度、旧版本 | 更新截止日并停用旧入口 |
| 越界 | 问题不属于该 Agent 范围 | 明确拒绝或转交其他入口 |
| 表达/检索 | 资料存在但没被正确召回 | 修标题、结构、关键词或检索规则 |
如果全部归类为“回答不准确”，运营人员只能反复改提示语，真正的事实问题不会消失。
缺口卡片要保留原始证据
每条缺口至少记录原问题、提问角色、Agent 版本、检索到的来源、实际答案、用户反馈、缺口类型、关联主题、责任人和截止时间。相似问题按主题聚合，但不能丢掉原始问法，因为它们是后续回归测试集。
涉及权限的缺口要特别谨慎：“没有搜到”可能是资料不存在，也可能是提问人无权访问。运营后台可以提示存在权限原因，但不能借缺口队列向无权人员泄露资料标题或内容。
补知识不等于上传文件
修复时要确认哪个系统或文档是权威源，写清状态、Owner、批准人、事实截止日和替代关系。新内容未经批准时只能处于草稿或待核验状态，不能立即进入所有员工的默认搜索。
企业知识治理的基础规则见企业知识库为何越用越乱；上下文如何选择当前事实见企业上下文工程怎么做。
用原问题回归后再关闭
发布修复版本后，至少重跑原问题、同义问法、容易混淆的相邻问题和无权用户用例。验证 Agent 引用了新依据、没有继续命中旧入口、答案没有越权，才算关闭。
队列还应持续统计高频主题、平均修复时间、重复出现率和知识 Owner 逾期情况。高频缺口说明该业务域值得优先治理；同一缺口反复打开，则说明修的是表面文案而不是事实源。
知识库真正的价值不是“存了多少文件”，而是组织能否把一次错误变成长期改进。需要建立从知识采集到持续运营的闭环，可继续了解企业知识中枢。
缺口优先级不只看出现次数
高频问题值得优先修，但低频高风险问题同样不能忽略。可以从业务影响、触发频率、受影响人数、是否存在替代路径和修复难度五个维度排序。涉及价格、合同、质量放行、权限和客户承诺的错误，即使只出现一次，也应进入高优先级。
同时区分“用户没得到想要的答案”和“系统做错了”。Agent 正确拒绝无权请求，不属于知识缺口；用户问法含糊导致追问，也不应直接算回答错误。分类准确，才能避免为了降低点踩率而放松边界。
从单题修复升级为主题治理
当同一产品、制度或项目连续出现多个缺口，不要继续逐题补丁。应建立该主题的现行入口，补齐结构化目录、常见别名、版本关系与 Owner，再用一组代表问题验收。主题治理完成后，原有缺口批量回归，但每条仍保留自己的关闭证据。
把一线纠错变得足够轻
反馈入口只要求员工标出“哪里不对”和可选的正确依据，不强迫其填写复杂工单。系统自动附带原问题、答案、来源与版本，运营人员再完成分类。纠错成本太高，一线人员会转回群里说一句，组织就再次失去可复用证据。
最终要形成“发现—分派—补证—批准—发布—回归—观察”的闭环，让知识质量随真实使用增长，而不是随着文档数量一起恶化。
