一、什么是知识地图？
核心判断：知识地图的难点不是"建",是"维护"——人变动频繁,信息 1 个月内就可能过期。 治理的命脉是"从 HR/CODEOWNERS 自动同步",不是"让人手动更新"。
| 它是什么 | 它不是什么 |
|---|
| 团队成员 × 负责领域/技能的映射 | 花名册(那在 HR 系统) |
| 跨团队"找谁"的对齐层 | 组织架构图(那是上下级) |
| 当前能力 + 当前职责的"快照" | 简历集合(那是历史) |
| 强时效性 + 隐私敏感 | 1:1 关系图(那是 RACI) |
为什么知识库需要建设知识地图：知识地图对 Agent 来说,本质上是"通讯录 + 路由表 + 团队感知"——没有它,Agent 能做事但不知道"做给谁、卡住找谁、避免撞到谁"。整个知识库是 Agent 的"工作记忆",知识地图是 Agent 的"协作接口"——前者解决"怎么做事",后者解决"跟谁协作"。
二、知识地图的知识模板如何定义？
2.1 模板 1:服务 × 人(services-to-people.md)
| 字段 | 类型 | 必填 | 来源 | 可见性 |
|---|
| 服务 | string(link → 服务清单) | ✓ | 自动 | 全员 |
| 主 Owner | @user | ✓ | CODEOWNERS | 全员 |
| 副 Owner(≥1) | @user | ✓ | 人工 | 全员 |
| Backup(临时) | @user | × | 人工 | 全员 |
| 联系渠道 | enum(IM/邮件) | ✓ | 自动 | 全员 |
| 紧急联系电话 | string | × | 人工 | 仅主管 + oncall |
| 最近响应 SLA | duration | × | 人工 | 全员 |
| 离职风险 | enum(低/中/高) | × | 主管评估 | 仅主管 |
| 最后更新 | datetime | ✓ | 自动 | 全员 |
2.2 模板 2:角色 × 联系方式(roles-contacts.md)
| 字段 | 类型 | 必填 | 备注 |
|---|
| 角色 | enum | ✓ | 如"DBA oncall"/"安全 oncall" |
| 主联系人 | @user | ✓ |
| 副联系人 | @user | ✓ |
| 联系电话 | string | ✓ | 分级可见 |
| IM 群 | link | ✓ |
| 升级路径 | list[@user] | ✓ | 搞不定找谁 |
| 值班轮换表 | link | ✓ | 链接到排班系统 |
| 应急手册 | link | ✓ | 链接到 Runbook |
2.3 模板 3:业务域 × 人(domains-to-people.md)
| 字段 | 类型 | 必填 | 来源 |
|---|
| 业务域 | enum | ✓ | 业务域划分 |
| 业务负责人(BP) | @user | ✓ | 组织架构 |
| 技术负责人(TL) | @user | ✓ | 人工 |
| PM Owner | @user | ✓ | PMO |
| 关键 Stakeholders | list[@user] | × | 人工 |
2.4 模板 4:项目 × 人(projects-to-people.md)
| 字段 | 类型 | 必填 | 备注 |
|---|
| 项目名 | string | ✓ | 链接到项目文档 |
| 状态 | enum | ✓ | 规划/进行中/暂停/已完结 |
| Sponsor | @user | ✓ | 项目 sponsor |
| Project Manager | @user | ✓ |
| Tech Lead | @user | ✓ |
| 核心成员 | list[@user] | ✓ | ≥3 人 |
| 启动时间 | date | ✓ |
| 计划结束 | date | × | 已完结填实际结束 |
2.5 模板 5:人 × 技能(skills-to-people.md)
| 字段 | 类型 | 必填 | 来源 |
|---|
| 技能 | enum | ✓ | 技能分类(见下) |
| 熟练度 | enum | × | 自评(初/中/高/专家) |
| 持有项目 | list[link] | × | 自动 |
| 持有 ADR | list[link] | × | 自动(从 ADR author 推) |
| 是否可做培训 | bool | × | 自评 |
| 备注 | string(≤100字) | × | 自评 |
2.6 关键设计点(为什么这么设计)
| 设计点 | 原因 |
|---|
| 电话分级可见 | 防止全员公开,合规要求 |
| 离职风险仅主管可见 | 敏感信息,避免员工心理负担 |
| 服务 × 人的"服务"是 link | 避免重复维护,跟服务清单保持一致 |
| 技能熟练度是 enum,不是数字 | Agent 可消费,可机器聚合 |
| 个人档案只放当前 | 维护成本可控,避免变简历库 |
2.7 反模式
| 反模式 | 后果 |
|---|
| 个人档案含完整履历/项目经历 | 维护不动,变简历库 |
| 联系方式全员公开 | 隐私问题,合规风险 |
| 技能用"百分比"或"分数" | 不可机器解析 |
| 一个人一份"全面"档案 | 单点维护,过期没人负责 |
| 离职立刻删除档案 | 历史查不到"X 之前负责什么" |
三、知识地图的更新机制如何设计？
核心判断：HR 系统是个人信息的单一真相源,CODEOWNERS 是 Owner 的单一真相源,wiki 只做"视图渲染"。 任何"在 wiki 里改个人信息"都是污染。存在5个触发器：
| 触发器 | 触发条件 | 动作 | 责任方 |
|---|
| HR系统同步 | 入职/转岗/离职 | 同步个人信息、自动增删/归档 | HR 系统 |
| CODEOWNERS 变化 | PR 改 CODEOWNERS | LLM 检查,提议更新服务 Owner | 自动 |
| 服务清单变化 | 新服务/服务下线 | LLM 检查,提议补/移 Owner | 自动 |
| 季度 review | 每季度 | 全员确认自己负责的服务/项目 | 人工 |
| 事件触发 | "找不到负责人"事件 | 补 Owner + 反思 schema | 人工 |
四、知识地图的质量标准如何定义？
核心判断：知识地图的"质量"= 找人的速度和准确性,不是"信息多不多"。 一个 100% 完整但 1 个月前的快照,不如一个 80% 完整但 1 周前的快照。5 个核心指标：
| 指标 | 定义 | 健康值 | 测量方式 |
|---|
| 覆盖率 | 已部署服务都有主+副 Owner | 100% | 自动 |
| 新鲜度 | Owner 信息最后审阅时间中位数 | ≤ 90 天 | 自动 |
| 触达 SLA | 紧急联系人 1 跳可达比例 | 100% | 值班演练 |
| 冗余度 | 关键(P0)服务有 ≥2 个 Owner | ≥ 90% | 自动 |
| 反向事件率 | "找不到负责人"事件频率 | 月度环比下降 | 事件统计 |
4.1 3 个反向指标(出现就告警)
| 反向指标 | 告警触发 | 修复动作 |
|---|
| 孤儿服务 | 服务有部署但无 Owner | 立即告警,要求补 Owner |
| 幽灵 Owner | Owner 已离职但服务仍挂在名下 | 立即告警,要求重新分配 |
| 失效渠道 | 紧急联系渠道(IM/电话)不可用 | 告警,要求更新 |
4.2 准入 / 持续 / 淘汰门槛
| 门槛 | 触发 | 动作 |
|---|
| 新服务准入 | 服务注册新增服务 | 必须填主+副 Owner,否则不准合并 |
| Owner 变更持续 | 转岗/离职 | 24h 内自动同步,失效 Owner 7 天未补齐告警 |
| 服务下线淘汰 | 服务注册移除服务 | 30 天后 Owner 信息归档到90-archive/ |
| 离职归档 | 员工离职 | 档案移到90-archive/people/,保留"X 之前负责什么" |
