帮助中心如何衡量「知识健康」：覆盖、新鲜度与 AI 可读性
摘要：「知识健康」是一组用覆盖、新鲜度和 AI 可读性来衡量帮助中心内容是否足以支撑自助检索与下游 AI 作答的运营指标。本文以 Zendesk 于 2026 年 11 月 10 日宣布、并在 11 月 10 日至 24 日向 Suite Professional 及以上账户滚动开放的 Admin Copilot 知识能力全面可用为新证据，说明这三项指标如何从近期工单与现有文章中计算出来，以及改稿建议如何进入编辑器、又为什么必须停在草稿。读完可以用这三项指标对照自有知识库：缺的是新文章、过时改稿，还是结构根本不适合被生成式 AI 引用。
浏览 10
巴克励步
导语：帮助中心开始被问「健不健康」，而不只是「写了多少篇」
知识健康（knowledge health），是用一组可对照的运营指标，衡量帮助中心现有文章是否足以覆盖客户正在问的问题、内容是否仍然现行，以及这些文章在结构上是否适合被生成式 AI 引用。它要回答的不是「知识库里有没有几百篇文章」，而是：常见工单有没有对应说明、过时或互相打架的段落有没有被改掉、写给用户看的页面能不能同时被搜索和 AI Agent 正确使用。
支柱文 帮助中心如何支撑 AI Agent 已经把「工单反哺文章、发布评测与灰度上线」这条发布框架讲清楚。本文不重写那套框架，而是把镜头对准知识运营工作台本身：2026 年 11 月 10 日，Zendesk 宣布 Admin Copilot 的知识能力全面可用，并在 11 月 10 日至 24 日向 Suite Professional 及以上账户滚动开放。
能力从早期的 Knowledge copilot 试验计划走出之后，Knowledge admin Home 会把内容覆盖、新鲜度、AI 可读性放在同一屏，并基于近期工单给出创建、更新、翻译文章（以及在附加组件下创建流程）的建议。
这对帮助中心团队的意义很具体。智能体上线之后，文章一改，对客对话就会变；但如果日常运营仍然只看浏览量和点踩，团队很难知道下一步该写新文、改旧文，还是先把结构改到「机器也读得懂」。知识健康把这件事从感觉，变成可以每周对着看的指标和建议队列。
三项指标分别量什么
Zendesk 在 《Optimizing knowledge with admin copilot insights and recommendations》 里，把 Admin Copilot 对知识内容的监测写成三个百分比。洞察按账户个性化，基于当前运营表现，并且只在有需要时生成，所以不一定每周都出现。入口在 Knowledge admin Home。
指标 | 官方定义（百分比） | 它实际在比较什么 | 常见后续动作 |
|---|---|---|---|
覆盖（Coverage） | 知识库文章覆盖了多少「常见问题」 | 把现有文章与近期工单数据对照，找出缺口 | 可能建议新建文章 |
新鲜度（Freshness） | 近期更新过的文章占比 | 久未更新会拉低分数；若旧文只部分回答了近期工单里的问题 | 可能建议更新该文 |
AI 可读性（AI readability） | 格式与结构便于 AI 处理的文章占比 | 过长、结构不清或媒体过重的文章，更难被当作内容源 | 通常导向结构调整，而不是再堆一篇同题新文 |
这三项不要混成一个「内容质量分」：
- 覆盖低：说明客户正在问的事在库里找不到对应文，优先补缺，而不是先润色已有长文。
- 新鲜度低：说明库里可能还有一篇「看起来相关、口径已经过时」的文章，继续追加新文只会制造冲突。簇内文「帮助中心进工单台」 已经强调：点踩和未回答问句如果回不到改稿队列，内容不会自己变好。知识健康把另一头补上——在有人点踩之前，系统也可以用工单分布主动提出「该更新了」。
- AI 可读性：则是这几年才被单独拎出来的一项。它不是在问「用户读起来累不累」，而是在问：这篇文被切成语料块之后，生成式模型还能不能准确引用。覆盖和新鲜度都合格，但文章全是无说明的截图、嵌套步骤或复杂表格，下游的生成式搜索和 AI Agent 仍然可能答错。这一点与支柱文 帮助中心语义搜索 是同一条链路上的不同环节：语义检索先要能命中，命中之后还要「块」里有完整、可核验的句子。
建议如何进编辑器，又为什么必须停在草稿
指标只指出方向；真正改变内容的，是建议（recommendation）能不能被审、被改、被留下证据。按 同一份操作说明 和 GA 公告，Admin Copilot 会用近期工单和现有知识内容，给出几类建议：
- 创建文章：近期工单里的常见问题，现有内容没有覆盖。生成前会先检查是否已有相近文章；若找到接近的匹配，你可以选择审阅或更新旧文，也可以另写一篇有区分的新文。
- 更新文章：现有文章只部分回答了工单里的问题、信息可能过时，或不同文章之间存在冲突。
- 翻译文章：某些语言的工单量已经很高，但对应文章还没有该语言版本；创建或更新一篇文章之后，如果发现其他语言也有需求，系统还可以继续建议翻译。这与 出海多语言帮助中心 要解决的「按需求补语言，而不是先把全库翻一遍」是同一方向。
- 创建 / 更新流程（procedure）：面向 auto assist，需 Copilot 附加组件。更新类建议会参考流程采纳率偏低、坐席频繁改写，以及相关工单里暴露出的缺失指引，并准备一份待审草稿。
建议卡片里的核验字段
更重要的是建议被点开之后能看到什么。官方把每条建议拆成几块可核对的信息：
- 理由（rationale）
- 支持性洞察（相关工单、受影响文章、冲突内容或语言需求）
- 建议修改（若有）
- 潜在影响（可能改善的覆盖、新鲜度、解决时长或流程采纳率，有定量估计时会给出）
- 可执行的动作
部分建议还会附上相关内容或工单的链接，以及所用工单样本的规模和日期范围。没有这些字段，一条「建议你改这篇文章」就只是提示，很难判断该不该采纳。
编辑器内的审核与流转机制
进入编辑器之后，更新类建议变成行内修改：你可以逐条接受或拒绝，也可以一次处理全部；全部接受或全部拒绝后，这条建议会从列表中移除。新文章则继续通过对话式协助生成，并保存为草稿，供人审阅、编辑后再发布。
GA 公告写明：Admin Copilot 使用你当前角色的权限，并在应用变更前征求确认。对话式协助还可以按标题、作者、负责人、标签等属性跨品牌查找文章（包括草稿），做查找替换，调整作者、权限、验证状态、板块归属，以及归档、恢复或删除——这些都是知识运营动作，不是对客聊天。
建议本身也可以被管理：稍后处理、标记完成，或驳回（可选填写原因）。已保存的建议 会出现在独立标签页里，避免打断手头工作；它们会按周更新，若不再适用也可能被移出。完成和驳回的条目进入归档。换言之，Copilot 提高的是「从工单信号到改稿任务」的效率，并没有把发布闸门拆掉。计费规则、退款条件和权限说明，仍然应该经过人核对再上线。
选型排查提示：使用前还有两个开关需要核对。其一，对话式协助默认开启，但可以按账户关闭，GA 公告也提醒必须先打开才能用这些知识操作。其二，流程类建议与文章类建议不是同一许可范围：没有 Copilot 附加组件，就看不到创建或更新 procedure 的建议。选型时把「有一个叫 Copilot 的入口」和「三项健康指标、行内改稿、流程建议是否都在计划内」分开看，才不会在演示里误判能力边界。
AI 可读性：文章被切成块之后，还能不能被正确引用
如果只把 AI 可读性理解成「少用术语、句子短一点」，会低估它要解决的问题。Zendesk 在 《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 可读性的定义和计算窗口；
- 抽几条建议，看是否附带工单样本、冲突说明和潜在影响；
- 确认生成结果默认停在草稿，并按角色权限发布。
做完这三步，再决定下一篇该新建、该修订，还是该先补上图片和视频所缺少的文字，会比只看「本周又写了几篇」更接近客户真正遇到的问题。
想要了解更多?
数字内容新基建白皮书
常见问题
Q1：「知识健康」具体指哪三项指标？
按 Zendesk Admin Copilot 的官方定义，是覆盖（常见问题有没有对应文章）、新鲜度（文章是否近期更新过）和 AI 可读性（格式与结构是否便于生成式 AI 作为语料）。这三项会出现在 Knowledge admin Home 的每周洞察里，且只在有需要时生成，不一定每周都出现。
Q2：Admin Copilot 的知识能力什么时候全面开放？面向哪些计划？
Zendesk 于 2026 年 11 月 10 日宣布全面可用（GA），滚动发布从当天持续到 11 月 24 日，面向 Suite Professional 及以上账户。对话式协助需要在账户中开启。创建或更新 auto assist 流程（procedure）的建议，还需要 Copilot 附加组件。
Q3：接受改稿建议，文章会立刻对客发布吗？
不会。官方写明：Admin Copilot 生成的内容会先存为草稿，供人审阅后再发布；它会遵守当前角色的权限，并在应用变更前征求确认。更新类建议可以在编辑器里逐条或一次性接受/拒绝行内修改，这与「点一下就全站生效」不是一回事。
Q4：AI 可读性和写给用户看的可读性是一回事吗？
不完全是。面向用户的可读性看的是人能不能顺利读完；AI 可读性看的是文章被切成语料块之后，生成式模型能不能准确引用。Zendesk 指出：过长、结构不清或媒体过重的文章更难被用作内容源；图片和视频需要配套文字说明，复杂表格也不如完整句子容易被模型理解。
