知识运营

知识库为什么会烂掉

一个运营组织三年后通常长成这样：600 个 Notion 页面、200 个 Confluence 流程手册、三个 Obsidian 仓库、一个 Drive/SOPs/ 目录，外加一个 Slack #ops-questions 频道——它存在的唯一原因是没人能找到那份本该是权威的文档。

失败模式高度可预测：

• 无主——40% 的 SOP 把负责人写成「团队」，文档烂掉时无人担责
• 无复审日期——一份两年前的供应商下线 SOP 仍在引用已下线的采购工具
• 成功信号含糊——手册第 4 步写着「确认服务正常」，新人无法判断什么叫正常
• 无回滚路径——告警升级手册教你如何发送，却不教你发现误报后如何撤回
• 孤立页面——半数文档没有任何入链，只能靠知道 URL 的人找到
• 术语漂移——「CSM」在三份文档里是客户成功经理，在五份里是客户方案经理
• 只写正常路径——文档覆盖了一切顺利的情况，却漏掉那 30% 会出问题的情况

这个技能回答的是运维人员真正问的问题：先修哪 20 份，每份具体错在哪——靠确定性逻辑，不靠直觉。

技能如何工作

四步流程，对应运营团队的真实工作方式：

1. 摄入知识库。对现有 wiki 导出运行 kb_ingester.py --input <path>，输出一份 Markdown 健康报告：孤立页面、陈旧页面（12 个月无编辑）、术语漂移、缺 owner 字段的页面、交叉链接图，以及按「陈旧度 × 入链数」排序的 Top-20 清理清单。
2. 校验现有手册。对清单中的每个 runbook 运行 runbook_validator.py --input <path>，按六项检查给每一步打分：具名 owner、预期耗时、可观测成功信号、可观测失败信号、回滚路径、升级联系人。输出每步红绿灯、总分 0–100 与 MUST-FIX 清单。
3. 生成新 SOP 骨架。运行 5w2h_scaffold.py --input <path> --profile <standard|regulated>，产出 5W2H 结构：Who（RACI）、What（步骤）、When（触发条件与频率）、Where（系统与工具）、Why（目的与法规依据）、How（逐步操作）、How-much（单次成本与耗时）。受监管 profile 额外追加版本控制、签署与审计追踪章节。
4. 闭环验证。清理 sprint 结束后重跑 kb_ingester.py，确认孤立页面数下降、术语漂移解决。

适用边界

知识库必须是 Markdown（或可导出为 Markdown）。纯 HTML 或纯 PDF 仓库需要先做转换，不在范围内。

owner 元数据必须写在 YAML frontmatter 的 owner: 字段或页面顶部的 Owner: 行里。「最后编辑过这个页面的人」不算 owner。

kb_ingester.py --sample 会生成一个仅含 8 页的合成仓库跑通全流程，仅依赖标准库。

runbook_validator.py 只能发现结构缺失，无法发现内容错误。一份手册可以拿满分却依然在教错的操作。

孤立页面不自动等于垃圾。有些参考页本来就只靠搜索触达，清理清单是优先级队列，不是删除清单。

若流程涉及 PHI、SOX 相关财务控制或 ISO 13485 器械质量体系，必须加 --profile regulated。跳过这一步，缺失版本控制的受监管 SOP 就是一项审计发现。

这个技能做的是过程文档（SOP、runbook、术语表），不是过程设计。BPMN 流程图、周期时间与瓶颈分析属于 process-mapper 的范畴。