知识库文章发布前怎么审核？把事实来源、版本和责任人放进同一流程

知识库文章发布前至少要回答四件事：事实依据来自哪里、规则适用于谁和什么条件、谁有权确认这个口径、旧版本何时停止被使用。文字通顺只是编辑检查，不能代替业务事实审核。把来源、待确认问题、版本和责任人写在同一张审核记录中，才能让客服和内容团队知道哪一版可以用于答复。

下面以客服退款政策条目更新为例。团队可以在 Boardmix 的在线白板上并排摆放旧条目、新来源和待确认问题，跟踪交接；最终规则仍应由权责部门在正式知识库或政策系统中确认与发布，白板不是审批权限的替代品。

先确定一篇条目要回答的用户问题

假设旧条目叫“退款怎么处理”，同时混写了适用条件、所需材料、超出权限的处理和客户话术。更新时先拆出读者任务：客服接到一笔订单，需要判断是否适用当前退款规则、哪些事实还需核实、何时转交负责人、如何向客户说明下一步。若一篇文章不能让员工完成这个判断，就算把措辞改得更顺也没有解决问题。

用一张问题卡约定范围：条目服务谁、对应哪类订单、引用哪份现行政策、有哪些例外、需要谁复核。不要直接从旧文章复制结论，因为旧口径可能早已变化；也不要把未经批准的讨论稿当作有效来源。

把事实来源和待确认处逐条对齐

审核者对每个关键句都应能指出来源。比如“可申请退款”的前提是什么、材料从哪里取得、超出范围时谁决定。来源可以是已生效的政策文件或系统规则说明；口头反馈可作为待核线索，不能自动升级为确定规则。对来源冲突的句子标“暂停发布”，并写出冲突涉及的版本和需要裁决的人。

审核流要有明确的退回和暂停分支

推荐按“编辑整理 → 来源核对 → 业务复核 → 发布校验 → 旧版回收”推进。编辑负责结构、链接和可读性；规则负责人确认适用口径；流程负责人确认员工能否执行；发布者检查实际入口和版本。任何环节发现来源冲突，都应回到对应负责人，而不是带着“待确认”字样直接上线给一线使用。

画布上的每张卡片可写“条目位置、来源链接或编号、目前结论、待决问题、负责人、截止日期”。看板表达交接，正式批准仍按组织的权限制度执行。尤其是价格、退款、隐私和合规信息，不能让“看过了”代替有责任人的确认。

发布时同时处理标题、入口与旧版本

新条目应在开头直接回答当前问题，并标出适用边界。发布者检查标题是否与正文匹配、内部链接是否指向现行规则、图片与示例有没有旧口径、搜索入口和推荐位是否仍把员工带到旧版。若必须保留旧链接供审计，应明确标注历史版本并阻止它继续作为日常答复依据；若采用跳转，也要确认不会把不同规则误并到一页。

版本记录至少包含生效日期、来源、变更点、批准人、下一次复查时间。政策发布和知识库发布可能不在同一时刻，过渡期间应写清客服按哪个口径工作，避免两个系统分别显示不同结论。

上线后抽查真实使用场景

选几类典型问题，让未参与编辑的客服从知识库入口找到条目，并说出适用条件和升级路径。若他们找不到文章，问题可能在标题与导航；若找到了却答错，检查结构、术语和例外说明。抽查要记录路径和错误位置，再决定改内容、改入口还是补培训，不要把所有问题都归为“员工没认真看”。

规则再次变化时，从来源编号反查受影响的条目、话术和培训材料。给每篇条目设置负责人和复查触发条件，例如政策版本变更或发现新例外；固定日期巡检可以补充，但不能代替变化发生时的同步。

常见问题

知识库审核一定要几级审批？

没有通用级数。按内容风险分配责任：普通操作说明可由内容与流程负责人确认，涉及退款承诺、隐私或法务的条目还需相应权责部门。关键是知道谁对事实和发布负责。

政策文件还没最终确认，能先发知识库吗？

不要把未定稿写成确定规则。可以内部记录待确认问题和临时处理联系人，但对一线可用的条目应等正式口径与生效安排明确后再发布。

旧文章要直接删除吗？

不一定。先查是否有审计或引用需要，再选择历史标记、更新入口或跳转。无论哪种做法，都要阻止旧口径继续被当作现行答案。