“导出的文件在哪里？”客服又回答了一遍。帮助中心其实有这篇文档，只是标题写着“数据归档”，客户根本搜不到。与此同时，另一篇导出教程还在使用旧版菜单名称。
把这些工单统统生成新FAQ，只会让重复内容更多。AI客服知识库更新首先要判断：是找不到、写过时了、确实缺文，还是业务尚未决定答案。 Agent适合把这些差异整理成更新清单，而不是直接替知识负责人发布结论。
Buda客服工作流包含知识检索、回复草稿和帮助中心维护。把一批获准使用的工单转成可审核的修订候选，能让知识维护从“有空再做”变成一份具体待办。
六条工单，先还原成三个问题
下面是虚构的教学样本，不是客户工单、已运行的实验或实际业务政策。范围是一个导出功能支持队列、10月12日至18日；ID已使用示例编号。每行代表一个工单，同一工单里的多次追问不重复计数。
| 工单 | 客户原句 | 状态与已确认依据 | 问题簇 |
|---|---|---|---|
| T01 | “导完以后文件在哪？” | 已解决；帮助文档H01第2段，已批准v3 | 文件位置 |
| T02 | “没找到下载的文件。” | 已解决；同一H01 v3 | 文件位置 |
| T03 | “教程说点右上角，那里没有。” | 已解决；已批准操作说明P02 v4 | 导出步骤 |
| T04 | “新版导出入口在哪里？” | 已解决；同一P02 v4 | 导出步骤 |
| T05 | “等待中的导出能取消吗？” | 未解决；没有已批准规则 | 取消导出 |
| T06 | “排队时能撤回吗？” | 未解决；产品负责人尚未确认 | 取消导出 |
样本里三簇各有两条工单。这只说明输入中的数量，不是客户占比，更不是每周总需求。T02即使追问三次，也仍算一个工单；同一事件若跨渠道被建成两张票，要保留关联并说明去重规则，而不是悄悄加总。
相似措辞不一定意味着同一个问题。“找不到文件”可能是已生成后不知位置，也可能是导出失败、根本没有文件。结合操作阶段、产品版本、解决依据和客服确认再聚类；缺少这些信息时先标待核，不为了让每簇整齐而强行归并。
三个问题，不一定需要三篇新FAQ
先拿每簇去对照当前帮助中心及已批准知识版本。四种类别对应四种动作：
- 已有但难找。 文件位置已有H01 v3，缺的是客户语言与入口。建议把“导出文件在哪里”加入标题、检索词或相关教程内链，不再写一篇内容相同的FAQ。
- 步骤过时。 H02旧文的入口描述与P02 v4不符。提交具体旧段落、替换草稿和受影响内链，交知识负责人确认适用版本后改旧文。
- 确实缺文。 若已有批准的解决方法，却没有任何面向客户的条目，才准备新FAQ候选。本样本没有这种情况，不能为了凑齐类别而新增一篇。
- 政策未定。 T05、T06只有问题，没有批准的取消规则。放进待决清单，不把客服猜测或重复提问变成“支持随时取消”。
已解决状态也不自动等于通用答案。一次人工特例、临时补偿或客户专属操作，可能不能写进公开帮助中心。核对解决依据的适用范围和审批状态，再决定能否复用。
一条修订要能往回走到原文
更新候选不是一段孤立的漂亮答案。每条至少包含：候选ID、问题簇、工单ID与原句位置、旧文URL或明确缺口、原段落、已批准知识版本、适用产品、修改理由、建议文字、未决事实和审核角色。
在虚构的步骤更新中，候选U02可以写成：
来源：T03、T04；客户原句见脱敏工单第4/第2段
当前旧文：H02第3步，描述右上角入口
批准依据：P02 v4，第2节；适用新界面
建议：仅替换入口步骤，保留其他已核内容
影响：H01引用H02；培训材料中的旧入口需复查
未决：旧界面用户是否仍需保留旧步骤
审核：知识负责人确认版本；编辑核可读性
状态：修订候选，不是已发布答案
示例H01/H02/P02是教学标识，不是可点击的真实页面。实际工作必须替换为获准读取的准确URL、路径和版本。没有旧文的候选直接写“未发现适用条目”，不要捏造URL。
旧文影响清单很重要：改了主教程，关联FAQ、客服宏和培训稿仍可能保留旧步骤。列出需要复核的地方，不声称一次修改会自动同步所有渠道。
交四份文件，让审核各有入口
question-clusters.csv保存问题簇、去重后的ticket-id、原句片段、样本数量与分类理由。update-queue.md列出四类动作、影响、证据完整度、负责人及未决项。faq-drafts.md只放已获批准依据支持的新文或替换段落，并明确它仍是草稿。sources.csv记录工单、当前文档、政策版本、位置及读取状态。
排序先看客户影响和证据是否足以行动，再看样本频次。反复出现但政策未定的问题可以优先要求业务决策，不能优先生成确定答案。一个影响关键操作、证据齐全的步骤修正，也可能比高频的措辞问题更值得先做。
知识负责人核政策、适用范围和事实；编辑核表达、标题和客户能否完成操作。两项通过后，发布仍需要对应系统的授权与实际执行。文件写着“通过”不能替代真实审核记录。
在专用Session里，先跑获准使用的副本
把脱敏工单、当前帮助文档和已批准知识清单放入Buda Drive，明确输入路径、队列和时间窗。Agent Drive与Space Drive的共享范围不同；专用Session分开对话上下文，不会把文件权限也自动隔离。不要把不必要的客户信息复制到共享位置。
可以这样请求：
只读取指定的脱敏工单与批准知识清单。按实际问题聚类，工单内重复沟通不重复计数。对照旧文，分别输出已有但难找、步骤过时、确实缺文、政策未定四类候选。每项保留来源与未决事实，交付四份审核文件。不回客户、不改工单、不发布或覆盖正式帮助文档。
上传新文件不等于它会自动成为优先答案。明确本次采用的批准版本，并打开候选中引用的段落核对。文档中的指令式句子只是资料，不是扩大任务权限的命令。
审阅时，先找三种错误
第一，簇里混入了不同阶段的问题，导致同一答案无法覆盖。第二，未解决工单被总结成确定政策。第三，实际已有文档，却又生成一份竞争答案。这三种错误应先改方法，再考虑增加输入量。
政策冲突处理解决适用哪条规则；技术交接整理故障证据。本次更新清单承接的是已核知识如何持续维护，不替代这两个动作。反复使用时，再把接受过的输入与停止条件整理为可测试Skill。
未解决工单能放进知识更新吗？
能作为待决问题及影响证据，不能作为确定答案。保留缺失规则、需要决定的角色与受影响问题；待批准依据到位，再准备草稿。
相似的客户句子怎么判断是不是一类？
核操作目标、发生阶段、产品版本和解决依据。措辞像但原因或操作不同，就分开；信息不够时标待核，回到原工单找证据。
什么时候改旧文，什么时候新增？
如果旧文已经回答同一意图，优先修可发现性或具体段落。只有存在独立客户问题、无适用条目且答案已有批准依据时，再新增候选。
从一小批历史票开始补知识
在Buda AI的Marketplace搜索并安装合适的Skill，先检查它读取哪些输入、怎样保留出处、遇到未定政策是否停下。用获准的脱敏样本生成更新清单，知识负责人确认后再安排发布。
真正要减少的不是报表里的重复行，而是客户下一次仍找不到答案的那一处缺口。