帮助中心如何衡量「知识健康」：覆盖、新鲜度与 AI 可读性

## 导语：帮助中心开始被问「健不健康」，而不只是「写了多少篇」 **知识健康（knowledge health）**，是用一组可对照的运营指标，衡量帮助中心现有文章是否足以覆盖客户正在问的问题、内容是否仍然现行，以及这些文章在结构上是否适合被生成式 AI 引用。它要回答的不是「知识库里有没有几百篇文章」，而是：常见工单有没有对应说明、过时或互相打架的段落有没有被改掉、写给用户看的页面能不能同时被搜索和 AI Agent 正确使用。 支柱文 [帮助中心如何支撑 AI Agent](/app/help-center/posts/540a) 已经把「工单反哺文章、发布评测与灰度上线」这条发布框架讲清楚。本文不重写那套框架，而是把镜头对准知识运营工作台本身：2026 年 11 月 10 日，[Zendesk 宣布 Admin Copilot 的知识能力全面可用](https://support.zendesk.com/hc/en-us/articles/11490277703834-Announcing-the-general-availability-of-knowledge-capabilities-in-admin-copilot)，并在 **11 月 10 日至 24 日**向 Suite Professional 及以上账户滚动开放。能力从早期的 Knowledge copilot 试验计划走出之后，Knowledge admin Home 会把内容**覆盖、新鲜度、AI 可读性**放在同一屏，并基于近期工单给出创建、更新、翻译文章（以及在附加组件下创建流程）的建议。 这对帮助中心团队的意义很具体。智能体上线之后，文章一改，对客对话就会变；但如果日常运营仍然只看浏览量和点踩，团队很难知道下一步该写新文、改旧文，还是先把结构改到「机器也读得懂」。知识健康把这件事从感觉，变成可以每周对着看的指标和建议队列。 ## 三项指标分别量什么 Zendesk 在 [《Optimizing knowledge with admin copilot insights and recommendations》](https://support.zendesk.com/hc/en-us/articles/10799529609498-Optimizing-knowledge-with-admin-copilot-insights-and-recommendations) 里，把 Admin Copilot 对知识内容的监测写成三个百分比。洞察按账户个性化，基于当前运营表现，并且**只在有需要时生成**，所以不一定每周都出现。入口在 Knowledge admin Home。 | 指标 | 官方定义（百分比） | 它实际在比较什么 | 常见后续动作 | | --- | --- | --- | --- | | 覆盖（Coverage） | 知识库文章覆盖了多少「常见问题」 | 把现有文章与近期工单数据对照，找出缺口 | 可能建议**新建文章** | | 新鲜度（Freshness） | 近期更新过的文章占比 | 久未更新会拉低分数；若旧文只部分回答了近期工单里的问题 | 可能建议**更新该文** | | AI 可读性（AI readability） | 格式与结构便于 AI 处理的文章占比 | 过长、结构不清或媒体过重的文章，更难被当作内容源 | 通常导向结构调整，而不是再堆一篇同题新文 | 这三项不要混成一个「内容质量分」。覆盖低，说明客户正在问的事在库里找不到对应文，优先补缺，而不是先润色已有长文。新鲜度低，说明库里可能还有一篇「看起来相关、口径已经过时」的文章，继续追加新文只会制造冲突。[簇内文「帮助中心进工单台」](/app/help-center/posts/17cc) 已经强调：点踩和未回答问句如果回不到改稿队列，内容不会自己变好。知识健康把另一头补上——在有人点踩之前，系统也可以用工单分布主动提出「该更新了」。 AI 可读性则是这几年才被单独拎出来的一项。它不是在问「用户读起来累不累」，而是在问：这篇文被切成语料块之后，生成式模型还能不能准确引用。覆盖和新鲜度都合格，但文章全是无说明的截图、嵌套步骤或复杂表格，下游的生成式搜索和 AI Agent 仍然可能答错。这一点与支柱文 [帮助中心语义搜索](/app/help-center/posts/e8cb) 是同一条链路上的不同环节：语义检索先要能命中，命中之后还要「块」里有完整、可核验的句子。 ## 建议如何进编辑器，又为什么必须停在草稿 指标只指出方向；真正改变内容的，是建议（recommendation）能不能被审、被改、被留下证据。按 [同一份操作说明](https://support.zendesk.com/hc/en-us/articles/10799529609498-Optimizing-knowledge-with-admin-copilot-insights-and-recommendations) 和 [GA 公告](https://support.zendesk.com/hc/en-us/articles/11490277703834-Announcing-the-general-availability-of-knowledge-capabilities-in-admin-copilot)，Admin Copilot 会用近期工单和现有知识内容，给出几类建议： - **创建文章**：近期工单里的常见问题，现有内容没有覆盖。生成前会先检查是否已有相近文章；若找到接近的匹配，你可以选择审阅或更新旧文，也可以另写一篇有区分的新文。 - **更新文章**：现有文章只部分回答了工单里的问题、信息可能过时，或不同文章之间存在冲突。 - **翻译文章**：某些语言的工单量已经很高，但对应文章还没有该语言版本；创建或更新一篇文章之后，如果发现其他语言也有需求，系统还可以继续建议翻译。这与 [出海多语言帮助中心](/app/help-center/posts/9ecc) 要解决的「按需求补语言，而不是先把全库翻一遍」是同一方向。 - **创建 / 更新流程（procedure）**：面向 auto assist，需 [Copilot 附加组件](https://support.zendesk.com/hc/en-us/articles/10799529609498-Optimizing-knowledge-with-admin-copilot-insights-and-recommendations)。更新类建议会参考流程采纳率偏低、坐席频繁改写，以及相关工单里暴露出的缺失指引，并准备一份待审草稿。 更重要的是建议被点开之后能看到什么。官方把每条建议拆成几块可核对的信息：**理由（rationale）**、**支持性洞察**（相关工单、受影响文章、冲突内容或语言需求）、**建议修改**（若有）、**潜在影响**（可能改善的覆盖、新鲜度、解决时长或流程采纳率，有定量估计时会给出），以及可执行的动作。部分建议还会附上相关内容或工单的链接，以及所用工单样本的规模和日期范围。没有这些字段，一条「建议你改这篇文章」就只是提示，很难判断该不该采纳。 进入编辑器之后，更新类建议变成行内修改：你可以逐条接受或拒绝，也可以一次处理全部；全部接受或全部拒绝后，这条建议会从列表中移除。新文章则继续通过对话式协助生成，并**保存为草稿**，供人审阅、编辑后再发布。GA 公告写明：Admin Copilot **使用你当前角色的权限，并在应用变更前征求确认**。对话式协助还可以按标题、作者、负责人、标签等属性跨品牌查找文章（包括草稿），做查找替换，调整作者、权限、验证状态、板块归属，以及归档、恢复或删除——这些都是知识运营动作，不是对客聊天。 建议本身也可以被管理：稍后处理、标记完成，或驳回（可选填写原因）。[已保存的建议](https://support.zendesk.com/hc/en-us/articles/11225651415578-Announcing-saved-recommendations-in-admin-copilot) 会出现在独立标签页里，避免打断手头工作；它们会按周更新，若不再适用也可能被移出。完成和驳回的条目进入归档。换言之，Copilot 提高的是「从工单信号到改稿任务」的效率，并没有把发布闸门拆掉。计费规则、退款条件和权限说明，仍然应该经过人核对再上线。 使用前还有两个开关需要核对。其一，[对话式协助默认开启，但可以按账户关闭](https://support.zendesk.com/hc/en-us/articles/10013995711386-About-admin-copilot)，GA 公告也提醒必须先打开才能用这些知识操作。其二，流程类建议与文章类建议不是同一许可范围：没有 Copilot 附加组件，就看不到创建或更新 procedure 的建议。选型时把「有一个叫 Copilot 的入口」和「三项健康指标、行内改稿、流程建议是否都在计划内」分开看，才不会在演示里误判能力边界。 ## AI 可读性：文章被切成块之后，还能不能被正确引用 如果只把 AI 可读性理解成「少用术语、句子短一点」，会低估它要解决的问题。Zendesk 在 [《Optimizing your knowledge content for generative AI》](https://support.zendesk.com/hc/en-us/articles/4408845739162-Optimizing-your-knowledge-content-for-generative-AI) 里，把生成式 AI 使用帮助中心和已连接知识源的过程写得很直接：内容先被摄入并切成更小的块（chunk），每个块带上表示语义的向量；用户提问时，系统比较问句与这些块的语义，再结合文章标题和最匹配的块生成答复。块里写得不清楚、不完整，生成结果就会跟着偏。 同一份指南给出的写法，对帮助中心编辑是一份很具体的清单，而不是风格建议： - 一篇文聚焦一个主题，把该主题写完整，避免把不相关的问题塞进同一页。 - 直接回答问题，把用户需要的上下文写在文内，尽量做成**自包含**，而不是把关键步骤只放在外链里。 - 段落短、句子直给；去掉重复或互相冲突的文章；术语首次出现时写全称。 - 使用用户和产品里已经在用的措辞，少用「它 / 他们」这类离开上文就失去所指的代词。 - 用标题和子标题切分逻辑，事实用项目符号，步骤用编号；若存在多种解法，把每种解法写成独立说明，而不是深嵌套的子步骤。 - **在标题里的问题或主题，在正文里再写一遍**，以免切块时把问题和答案拆到不同块。 - 为图片、视频和示意图补上文字说明——生成式 AI 在这里处理的是文本；尽量少用复杂表格，必须用时保持简单。 这也解释了为什么「媒体过重」会拉低 AI 可读性：视频和截图对用户往往更友好，但若没有同等信息量的文字，模型几乎拿不到可引用的句子。帮助中心若同时托管视频、更新日志和产品文档，更需要约定：画面解决「怎么看」，结构化正文解决「怎么被检索和引用」。Baklib 在线帮助中心把 FAQ、产品文档、更新日志和视频放在同一套内容里，再用 AI/LLM 语义搜索对外提供，价值不在「也能放视频」，而在同一主题下可以同时保留适合人看的媒体，和适合被搜索、被 Agent 引用的完整说明。 ## 对照：有了 Copilot，也不等于知识运营已经完成 把 GA 之后的工作台拆开看，可以帮助中心团队做一次选型或自检。下表用于清点能力边界，而不是给某一家产品打分。 | 检查项 | 只停留在「有 AI 写稿」 | 知识健康被真正运营起来的样子 | | --- | --- | --- | | 覆盖 | 按栏目或字数判断「库是否够大」 | 用近期工单中的常见问题对照现有文章，缺口会变成「创建文章」建议，且生成前先查重 | | 新鲜度 | 只在有人点踩或客服投诉后才改 | 久未更新、只部分回答新工单、或文与文冲突，会进入更新队列 | | AI 可读性 | 只优化给人看的排版 | 统计结构是否便于切块引用；过长、无结构或缺乏文字说明的媒体会被单独标出 | | 建议是否可审核 | 一条提示，说不清依据 | 能看到理由、相关工单、样本规模与日期范围、潜在影响，并可提问追问 | | 发布闸门 | 生成即对客可见，或坐席改完即全站生效 | 新文进草稿，行内修改可逐条接受或拒绝，系统按角色权限征求确认后再应用 | | 队列治理 | 建议刷过去就消失，无法分工 | 可稍后处理、标记完成、驳回并归档；保存项按周刷新，过期建议会被拿掉 | | 内容是否在同一套真相源里 | FAQ、文档、日志、视频和外部说明分散在不同工具，指标无法对同一批内容计算 | 对外说明集中托管，权限分级清楚，同一份内容再经搜索、Widget、API 或 Iframe 分发 | 对使用 Baklib Help Center 的团队，这份清单的落点不在「也做一个同名 Copilot」，而在先把可度量的内容放进同一套治理范围。FAQ、产品文档、更新日志和视频如果分开维护，覆盖和新鲜度很难在同一口径下计算，AI 引用时也容易拿到互相冲突的段落。Baklib 把这些内容统一托管，并提供权限分级、反馈与运营数据，以及面向官网、产品内路径的 Widget / API / Iframe 分发；出海场景还可以按多站点、多语言组织内容。这样，无论后续是人工排期改稿，还是借助模型从工单里提出建议，审阅的都是同一份可被搜索、可被引用、可被权限约束的真相源。语义检索能否给出可核验答案，仍然取决于文章本身是否把步骤写全、把过时口径收干净——工具可以缩短从信号到草稿的时间，不能代替发布前的核对。 ## 收束：先把三项指标看懂，再决定下一篇写什么 帮助中心支撑 AI 自助服务，并不只在「把文章交给 Agent」的那一步才开始。更早的运营问题是：你能不能每周看出库里缺的是覆盖、过时，还是结构不适配生成式引用；一条改稿建议能不能带着工单证据进入编辑器；接受之后，它是进草稿，还是直接改写了对客对话。Zendesk 把 Admin Copilot 的知识能力推到全面可用，等于把这套工作台从试验计划变成了 Suite Professional 及以上账户可以打开的默认路径。 可以先用三个很具体的动作做一次对照：打开（或向供应商要来）覆盖、新鲜度、AI 可读性的定义和计算窗口；抽几条建议，看是否附带工单样本、冲突说明和潜在影响；再确认生成结果默认停在草稿，并按角色权限发布。做完这三步，再决定下一篇该新建、该修订，还是该先补上图片和视频所缺少的文字，会比只看「本周又写了几篇」更接近客户真正遇到的问题。