gap-grouping

知识缺口分组与分类

概述

此技能以缺口分析为基础，将已识别的知识缺口分组、聚类并分类为可执行的主题。孤立的单个缺口难以确定优先级，但按主题、服务领域或用户影响进行聚类后，便能发现一些模式，揭示需要协同处理的系统性文档缺陷。

此技能可帮助你：

• 收集并规范化来自多个来源的知识缺口数据（事件、搜索日志、反馈、提交内容）
• 按服务领域、类别、配置项和分配组聚类相关缺口
• 识别各服务领域中的系统性文档缺陷
• 根据总体影响、发生频率和业务重要性确定缺口群组的优先级
• 创建结构化行动计划，将缺口群组分配给知识作者并设定截止日期
• 跟踪缺口修复工作的进展

使用时机： 完成缺口分析后、季度知识规划期间、创建知识内容待办事项时，或安排知识编写冲刺时。

前提条件

• 角色： 完整工作流需要 knowledge_manager 或 knowledge_admin；只读分析需要 knowledge
• 访问权限： 对 incident、kb_knowledge、kb_submission、search_log、kb_feedback 表拥有读取权限；对 kb_submission 和 kb_knowledge 拥有写入权限
• 插件： 已激活 com.glideapp.knowledge（知识管理）
• 建议： 已完成缺口分析（参见 knowledge/gap-analysis 技能）并获得原始缺口数据
• 知识： 了解所在组织的服务目录分类体系和知识所有权模型

操作步骤

步骤 1：从事件中收集原始缺口数据

检索有限范围内的样本，仅包含已解决且未关联 KB 文章的事件，并在本地汇总，以识别基于数量的缺口。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: opened_at>=javascript:gs.daysAgoStart(90)^state=6^kb_knowledgeISEMPTY^close_notesISNOTEMPTY
  fields: sys_id,category,subcategory,assignment_group
  limit: 1000
  instance: dev

在本地按 (category, subcategory, assignment_group) 统计行数，按降序排序， 并保留前 50 条。如果达到样本上限且需要完整覆盖，请有计划地分页检索。

使用 REST API：

GET /api/now/stats/incident?sysparm_query=opened_at>=javascript:gs.daysAgoStart(90)^state=6^kb_knowledgeISEMPTY^close_notesISNOTEMPTY&sysparm_group_by=category,subcategory,assignment_group&sysparm_count=true&sysparm_orderby=COUNT&sysparm_limit=50

步骤 2：从失败的搜索中收集缺口数据

检索有限范围内的失败搜索行，并在本地统计规范化后的 search_term 值， 以发现用户需求未得到满足的群组。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: search_log
  query: sys_created_on>=javascript:gs.daysAgoStart(90)^results_count=0^search_application=knowledge
  fields: sys_id,search_term
  limit: 1000
  instance: dev

使用 REST API：

GET /api/now/stats/search_log?sysparm_query=sys_created_on>=javascript:gs.daysAgoStart(90)^results_count=0^search_application=knowledge&sysparm_group_by=search_term&sysparm_count=true&sysparm_orderby=COUNT&sysparm_limit=40

步骤 3：从知识提交中收集缺口数据

查看待处理的知识提交（新文章请求），以记录用户报告的缺口。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: kb_submission
  query: state=pending^ORstate=open^sys_created_on>=javascript:gs.daysAgoStart(180)
  fields: sys_id,number,short_description,description,kb_knowledge_base,category,assignment_group,priority,sys_created_on
  limit: 40

使用 REST API：

GET /api/now/table/kb_submission?sysparm_query=state=pending^ORstate=open^sys_created_on>=javascript:gs.daysAgoStart(180)&sysparm_fields=sys_id,number,short_description,description,kb_knowledge_base,category,assignment_group,priority,sys_created_on&sysparm_limit=40

步骤 4：从负面文章反馈中收集缺口数据

找出收到负面反馈的文章，这可能表明某个主题领域的内容覆盖不完整。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: kb_feedback
  query: sys_created_on>=javascript:gs.daysAgoStart(90)^rating=not_helpful^ORrating=1
  fields: sys_id,article,article.number,article.short_description,article.kb_category,comments,sys_created_on
  limit: 40

使用 REST API：

GET /api/now/table/kb_feedback?sysparm_query=sys_created_on>=javascript:gs.daysAgoStart(90)^rating=not_helpful^ORrating=1&sysparm_fields=sys_id,article,article.number,article.short_description,article.kb_category,comments,sys_created_on&sysparm_limit=40

步骤 5：定义分组维度

使用以下维度对收集到的缺口进行聚类：

分组分类体系：

维度	来源字段	用途
服务领域	category、cmdb_ci.sys_class_name	按 IT 服务领域分组
主题	subcategory、short_description 关键词	按具体主题分组
受众	assignment_group、事件呼叫者类型	区分内部 IT、最终用户和客户
知识库	kb_knowledge_base	与现有 KB 所有权保持一致
优先级层级	事件 priority、案例 priority	业务重要性排名
CI/应用	cmdb_ci、cmdb_ci.name	按受影响的系统分组

第 6 步：按服务领域对缺口进行聚类

将每个缺口映射到一个服务领域集群。查询现有知识库类别，使集群与知识库分类体系保持一致。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: kb_category
  query: kb_knowledge_base=[primary_kb_sys_id]^active=true^parent_id=NULL
  fields: sys_id,label,full_category,kb_knowledge_base
  limit: 30

使用 REST API：

GET /api/now/table/kb_category?sysparm_query=kb_knowledge_base=[primary_kb_sys_id]^active=true^parent_idISEMPTY&sysparm_fields=sys_id,label,full_category,kb_knowledge_base&sysparm_limit=30

将事件类别映射到知识库类别：

事件类别	知识库类别	缺口数量	服务领域集群
网络	网络与连接	47	基础设施
软件	应用程序	35	终端用户计算
硬件	设备与外设	28	终端用户计算
电子邮件	电子邮件与协作	22	通信
数据库	数据服务	18	基础设施
安全	安全与访问	15	安全

第 7 步：为缺口集群评分并确定优先级

应用综合评分模型，按紧迫性和影响对缺口集群进行排名。

集群评分公式：

因素	权重	衡量方式
事件总量	30%	集群内所有缺口的事件总数
平均事件优先级	20%	加权平均值（P1=5、P2=4、P3=3、P4=2、P5=1）
搜索失败频率	20%	与集群主题匹配的失败搜索查询总数
负面反馈数量	15%	相关文章收到的负面评分数
知识提交数量	15%	此主题下待处理的文章请求数

优先级层级：

• 严重（得分 4.0-5.0）： 需要立即处理；安排到下一个冲刺
• 高（得分 3.0-3.9）： 计划在本季度处理
• 中（得分 2.0-2.9）： 安排在下季度处理
• 低（得分 1.0-1.9）： 加入待办列表，视情况处理

第 8 步：确定知识内容编写负责人

根据分配组模式，确定每个缺口集群应由哪个团队或个人负责。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: opened_at>=javascript:gs.daysAgoStart(90)^state=6^category=network^kb_knowledgeISEMPTY
  fields: sys_id,assignment_group
  limit: 1000
  instance: dev

在本地按 assignment_group 统计有界结果行，然后保留前 10 项。

使用 REST API：

GET /api/now/stats/incident?sysparm_query=opened_at>=javascript:gs.daysAgoStart(90)^state=6^category=network^kb_knowledgeISEMPTY&sysparm_group_by=assignment_group&sysparm_count=true&sysparm_limit=10

为某个缺口集群解决事件最多的分配组，是编写知识文章的最佳人选。

第 9 步：创建行动计划记录

为每个缺口集群创建知识提交记录，并明确范围和截止日期。

使用 MCP：

Tool: SN-Create-Record
Parameters:
  table_name: kb_submission
  data:
    short_description: "Gap Cluster: Network Connectivity Troubleshooting (5 articles needed)"
    description: |
      === KNOWLEDGE GAP CLUSTER ACTION PLAN ===
      Cluster: Infrastructure - Network & Connectivity
      Priority: Critical (Score: 4.3/5)

      Gap Items:
      1. DNS configuration troubleshooting (47 incidents, 23 failed searches)
      2. VPN split tunnel configuration (31 incidents, 15 failed searches)
      3. Wireless network authentication errors (28 incidents, 12 failed searches)
      4. Network printer connectivity (22 incidents, 8 failed searches)
      5. Proxy configuration for remote users (18 incidents, 10 failed searches)

      Total Incident Impact: 146 incidents in 90 days
      Estimated Articles: 5 new, 2 updates to existing
      Target Completion: 2026-04-30
      Assigned Team: Network Operations

      Success Criteria:
      - All 5 articles published and indexed
      - Failed search rate for cluster topics reduced by 50%
      - Incident-to-KB attachment rate >60% for network category
    kb_knowledge_base: [target_kb_sys_id]
    category: Network
    assignment_group: Network Operations
    priority: 1

使用 REST API：

POST /api/now/table/kb_submission
Content-Type: application/json

{
  "short_description": "Gap Cluster: Network Connectivity Troubleshooting (5 articles needed)",
  "description": "=== KNOWLEDGE GAP CLUSTER ACTION PLAN ===\nCluster: Infrastructure...",
  "kb_knowledge_base": "[target_kb_sys_id]",
  "category": "Network",
  "assignment_group": "[group_sys_id]",
  "priority": "1"
}

第 10 步：跟踪缺口修复进度

定期查询新创建的文章，检查每个集群中已解决的缺口数量。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: kb_knowledge
  query: sys_created_on>=javascript:gs.daysAgoStart(30)^kb_category.label=Network^workflow_stateINdraft,review,published
  fields: sys_id,number,short_description,workflow_state,kb_category,author,sys_created_on
  limit: 20

使用 REST API：

GET /api/now/table/kb_knowledge?sysparm_query=sys_created_on>=javascript:gs.daysAgoStart(30)^kb_category.label=Network^workflow_stateINdraft,review,published&sysparm_fields=sys_id,number,short_description,workflow_state,kb_category,author,sys_created_on&sysparm_limit=20

工具用法

MCP 工具参考

工具	使用场景
SN-Query-Table	查询缺口、提交、反馈和文章；检索有界字段以便在本地汇总
SN-Natural-Language-Search	按主题搜索现有内容覆盖情况
SN-Create-Record	将行动计划记录创建为知识提交
SN-Update-Record	更新提交状态和进度备注
SN-Add-Work-Notes	记录聚类决策及其理由

REST API 参考

端点	方法	用途
/api/now/stats/incident	GET	按类别汇总事件数量
/api/now/stats/search_log	GET	汇总搜索失败频率
/api/now/table/kb_submission	GET/POST	管理知识提交和行动计划
/api/now/table/kb_feedback	GET	获取负面反馈数据
/api/now/table/kb_category	GET	将缺口映射到知识库分类体系
/api/now/table/kb_knowledge	GET	跟踪修复进度

最佳实践

• 先分组，再确定优先级： 单个知识缺口的信号较杂；聚类能揭示真正的优先事项，并避免工作分散
• 与知识库分类体系对齐： 将知识缺口簇映射到现有知识库类别，确保文章归入正确的位置
• 按专业知识分配负责人： 负责解决事件的团队最适合撰写文章；使用分配组数据来确定作者
• 设定切实可行的时间安排： 知识作者通常每周可撰写 2-3 篇高质量文章；据此规划各知识缺口簇的时间安排
• 定义成功指标： 每项行动计划都应包含可衡量的标准（搜索命中率提升、事件转移率、反馈评分）
• 每季度审查： 随着组织发展，知识缺口簇会发生变化；每季度重新运行分析并调整优先级
• 从快速见效的工作着手： 在每个知识缺口簇中，找出可通过改用现有结案备注或问题解决方法来填补的知识缺口

故障排查

“知识缺口簇范围太广——所有知识缺口都归到同一类别”

原因： 事件分类过于粗略（例如，所有事件都归为“软件”） 解决方案： 使用子类别、CI 或分配组作为额外维度。如果子类别数据稀疏，可根据简短描述中的关键词模式进行聚类

“无法确定知识撰写工作的负责人”

原因： 没有明确的分配组模式；事件分散在多个团队 解决方案： 将工作分配给知识管理团队，作为集中撰写职能；或者通过最常负责解决问题的人员确定主题专家

“待处理的知识提交已过时”

原因： 已创建提交，但从未进行分类或分配 解决方案： 按提交时间筛选，并关闭超过 12 个月且已不再相关的提交。重点处理过去 6 个月的提交

“知识缺口簇的优先级频繁变化”

原因： 新的事件高峰或组织变动导致优先级发生变化 解决方案： 使用滚动 90 天窗口评分，以反映当前趋势。每月重新评分，并向利益相关方传达变化

“行动计划记录未得到跟踪”

原因： 没有针对知识提交记录的工作流或报告 解决方案： 创建简单的仪表板或定期报告，按状态、分配组和提交时间跟踪 kb_submission 记录

示例

示例 1：基础设施知识缺口簇

知识缺口簇： 基础设施 - 网络与连接 评分： 4.3/5（严重）

识别出的知识缺口：

知识缺口主题	事件数	搜索失败次数	提交数
DNS 故障排查	47	23	1
VPN 分割隧道	31	15	2
无线身份验证错误	28	12	0
网络打印机设置	22	8	1
远程用户代理设置	18	10	0

行动计划： 撰写 5 篇新文章，分配给网络运营团队，目标是在 4 周内完成。优先从 DNS 和 VPN 开始，因为这两类事件量最高。

示例 2：终端用户计算知识缺口簇

知识缺口簇： 终端用户计算 - 应用程序 评分： 3.5/5（高）

识别出的知识缺口：

知识缺口主题	事件数	搜索失败次数	负面反馈
Office 365 迁移常见问题	35	28	5
Adobe 许可证激活	22	11	2
Zoom 插件安装	19	9	0
浏览器兼容性	15	7	3

行动计划： 撰写 4 篇新文章并更新 2 篇文章，分配给桌面支持知识作者，目标是在 3 周内完成。由于 Office 365 正在持续推广，应优先处理相关迁移内容。

示例 3：面向客户的差距集群

集群： 客户服务 - 产品支持 评分： 4.1/5（关键）

已识别的差距：

差距主题	案例数	门户搜索失败次数	提交次数
产品退货流程	38	22	3
保修申请流程	25	18	2
订单跟踪状态	20	14	1

行动计划： 为外部知识库编写 3 篇面向客户的新文章，分配给客户服务知识团队。由于直接影响客户且有机会通过自助服务减少人工处理，优先级为关键。目标在 2 周内完成。

相关技能

• knowledge/gap-analysis - 识别单个知识差距（此技能的前置条件）
• knowledge/article-generation - 生成文章以填补各集群中的差距
• knowledge/duplicate-detection - 创建差距集群文章时防止重复
• knowledge/content-recommendation - 验证新文章是否会在相关事件中呈现