企业SOP标准流程编写

问题：SOP 库不会突然烂掉，它只会慢慢失效

一个运营组织跑满三年，知识库通常长成这样：600 个 Notion 页面、200 个 Confluence runbook、三个 Obsidian vault，外加一个 Drive/SOPs/ 目录。于是有人建了 #ops-questions 频道——因为没人能说清哪份才是正式版。真正昂贵的不是文档数量，而是下面这些反复出现的失败模式：

• 没有负责人：约 40% 的 SOP 把 owner 写成「团队」。文档腐化时没有人需要负责。
• 没有复审日期：一份供应商离场 SOP 仍在引用某个已下线一年的采购工具。
• 成功信号含糊：runbook 第 4 步写着「确认服务正常」，新值班的人无法判断这到底指什么。
• 没有回滚路径：告警升级流程教你怎么发通知，却不说告警发错了该怎么撤回。
• 孤儿页面与术语漂移：半个知识库没有入链；CSM 在八个文档里表示两种不同的岗位。
• 只写 happy path：文档覆盖一切顺利的情形，没覆盖那 30% 不顺利的。

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

它如何工作

• kb_ingester.py：扫描现有 wiki 导出（Notion zip、Confluence 空间导出、Obsidian vault、Drive/SOPs/ 目录），检出孤儿页面、超过 12 个月未修改的过期页面、术语漂移、缺少 owner: 字段的页面，并输出跨链图谱和按「过期程度 × 入链数」排序的 top-20 清理清单。仅依赖标准库，--sample 可在临时目录用合成 vault 跑通全链路。
• runbook_validator.py：对每份 runbook 的每一步打分，检查六项——具名负责人、预期耗时、可观测成功信号、可观测失败信号、回滚路径、升级联系人。输出逐步红绿灯、0-100 总分和 MUST-FIX 清单。
• SOP 生成器：按 5W2H（Who / What / When / Where / Why / How / How-much）产出结构化骨架；--profile regulated 追加版本控制、签核与审计轨迹章节，对应 ISO 9001、FDA 21 CFR Part 211、SOC 2、HIPAA。
• 闭环校验：清理 sprint 之后重跑 kb_ingester.py，确认孤儿页面数下降、术语漂移解决。真正该盯的指标是「找不到的文档」和「不安全的 runbook」。

边界与注意点

• 只处理 markdown（或可导出为 markdown）的知识库；纯 HTML / PDF 需要先做一次转换，不在范围内。
• 清理清单是优先级队列，不是删除清单。部分孤儿页面是仅靠搜索命中的参考页，应当保留。
• runbook_validator.py 只能抓结构缺失，抓不到内容错误。一份满分 runbook 仍可能把步骤写错。
• 生成 SOP 时必须为每份文档指派具名个人，不要批量产出没有 owner 的文档——没有 owner 的文档半衰期大约六个月。
• 涉及 PHI、SOX 财务控制或 ISO 13485 设备 QMS 的流程必须使用 --profile regulated，否则缺失版本控制本身就是一条审计发现。
• 它治理的是运营者实际消费的文档产物（SOP、runbook、术语表），不是 BPMN 流程图，也不是个人第二大脑。