我们量化了三家顶级开源组织的「制度腐化」：64–78% 的文档是孤儿

数据日期 2026-09-12 · 口径：引用图（入链） · 约 8 分钟读完 · 首发 2026/09/12 21:10

一、现象：几十万块钱，买到的是一堆没人愿意打开的页面

几乎所有上规模的组织都做过同一件事：建知识库、写 SOP、发流程文档。

行业里有一句被反复引用的话，精准描述了结果：「很多企业花了几十万元，最后得到一堆没人愿意用的文档页面。」

（这条是行业评测口径的二手引用，我们不把它当自己的一手数据。本文所有一手数字见第三、八节，全部可复现。）

这不难理解。写制度有收益（证明自己在管理），删制度有风险（万一以后要用？谁签字负责？）。于是制度只增不减，直到没人看。

而成本在别处悄悄累积。McKinsey Global Institute《The Social Economy》（2012） 的一手口径是：知识工作者每周约 19% 的工作时间（约 7.6 小时）花在「寻找与汇集信息」上，另有 28% 花在邮件上 —— 花掉的时间还不是最贵的，找到的东西可能已经过期才是最贵的。更麻烦的是，这一代开始，读这些文档的不只是人：AI agent 会按过时的假设规模化地做错事，比人错得更快、更多。

问题在于：所有人都说得出「制度没人看」这句话，但没人能把它变成一个数字。

没有数字，就没法排优先级，没法验收，没法反驳「我觉得文档还是有用的」。

二、方法：我们用「引用图」把「没人用」量化成一个比率

先说清楚我们量的是什么。

对象 = 一个文档库里的全部 Markdown 文档（不含代码、图片）。

被引用 = 至少被另一个文档用链接指向它（相对路径链接 / 仓库绝对路径链接 / wikilink / 站点式引用）。

孤儿文档 = 零入链：没有任何其他文档指向它。

孤儿率 = 孤儿文档数 ÷ 全部文档数。

三个必须写清楚的口径纪律：

1. 「孤儿」≠「没用」。 它只说明一件事：在这个库的链接结构里，没有任何文档把它当作入口。 一个被搜索引擎天天命中、却从不被任何文档引用的页面，在这个口径下仍然是孤儿。所以我们是低估而非高估它的使用价值 —— 这是一个保守指标。
2. 不同口径不得混算。 同一个目录，换一个口径会得到完全相反的结论。以我们自己的 docs/ 为例：运行时被读取口径下（117 份文件），只有 13% 从未被读过 —— 看起来相当健康；而引用图口径下（其中 65 份 markdown），98% 是孤儿 —— 看起来全烂了。两个数都对，但它们回答的是不同的问题（前者问「有没有人打开」，后者问「有没有文档指向它」），样本范围也不相同。谁把不同口径的数字放进同一张表里平均，谁就在制造假的确定性。
3. 口径必须匹配文档库的形态。 这是最容易出错、也是我们踩坑最多的一条：

文档库形态	引用图口径	运行时口径	说明
链接型（Confluence / Notion / 人手写链接）	✅ 推荐	需访问日志	门槛最低，本文主口径
站点型（Hugo / Docusaurus 等生成站点）	❌ 失效	✅	导航与索引页由系统生成，互链数字无意义（我们曾据此作废掉一个 8,215 份文档的大样本）
注入型（AGENTS.md / CLAUDE.md / MEMORY.md 等自动注入）	❌	❌	必须从样本里剔除，否则「100% 被引用」是假的
代码库型（可校验锚点）	—	—	改用锚点存在性口径，回答「引用是否还指向真实存在的目标」

我们踩过的三次口径事故，值得单独说，因为它们决定了上面的表长什么样：

• 事故 ①：用「子串匹配」识别豁免段落，结果「非 P0」「P0 issue」这类标题被误判成豁免段，整段该降的没降。
• 事故 ②：跨样本数据污染 —— 一份报告的图里混进了另一个样本的数字。
• 事故 ③：对一个 Hugo 生成站点套用引用图口径，算出一个非常唬人的数字 —— 其实是口径失效：站点的导航、聚合页全是系统生成的，文档之间本来就不需要互链。这个 8,215 份文档的样本被我们作废，不写进任何结论。

三、证据：三个组织，同一口径，全部超过 50%

采样对象都是公开仓库，规模从 598 到 4,717 份文档，全部用同一个引用图口径计算。

表 1｜三个组织的孤儿率（同口径，全库计算）

样本	文档数	孤儿率	死重体量占比
CNCF TOC（基金会官方治理文档）	598	68%	82%
Kubernetes community（社区制度与 SIG 文档）	964	64%	65%
GitLab Handbook（真实公司的对外制度库）	4,717	78%	73%

「死重体量占比」= 孤儿文档占用的字节数 ÷ 全库字节数。它比条数更能说明问题：孤儿往往是大文件（评审报告、评估书、会议记录归档），删掉它们释放的空间远大于条数比例。

表 2｜Kubernetes KEP：状态不会死

Kubernetes Enhancement Proposal（KEP）是这类样本里最好的一种，因为它自带机器可读的状态字段（provisional / implementable / implemented / withdrawn / replaced / superseded …）。全量 652 个：

指标	值
僵尸草案（状态「在议」但 > 2 年未动）	26%（87/333）
化石制度（状态「已实现」但 > 5 年未动）	30%（87/294）
1 年内动过的	1%（9/652）
最后更新距今（中位）	6.5 年
明确标注废弃 / 被替代	3%（21/652）
→ 其余	97% 永停「在用 / 在议」

（这里还有一个我们主动否掉的结论：原本假设「被废弃的提案引用率更低」，实测废弃状态零引用率 81% vs 在役状态 77% —— 只差 4 个百分点，属于噪音范围，不足以支撑因果结论，所以我们不写。真正有信息量的是上面这张状态×时间的表。）

表 3｜同一组织内部，差异可以有 76 个百分点

只看平均值会误导。把 Kubernetes community 的 964 份文档先在全库图上算链接图，再按目录分组：

分组	文档数	孤儿率
mentoring / contributors / sig-node	41 / 98 / 29	20% / 28% / 28%（活制度层）
communication	45	47%（但死重体量 82%）
elections / archive / events	180 / 66 / 99	71% / 86% / 96%（档案记录层）

结论不是「这个库腐化到了 75%」，而是：引用率必须先按目录类型分层。

档案 / 记录层（events、archive、会议记录归档）天生就是高孤儿率 —— 它们的存在价值是留痕，不是被引用。把这类目录和活制度层混在一张平均数里，得出的任何结论都没有意义：该整层归档的，不该按「腐化」逐条处理。

四、机制：状态字段靠人更新，而时间不会撒谎

到这里，一个自然的问题是：为什么会这样？

KEP 这类文档其实已经做得很好了 —— 它有状态字段，有替代关系，有流程。但状态字段有一个致命前提：它靠人更新。

一个提案落地了，作者会去把状态改成 implemented（这是荣誉）。一个提案被放弃了，谁会专门去把它改成 withdrawn（这是承认失败、走流程、还需要别人评审）？没有人。

于是状态字段永远停留在乐观的那一侧：73% 的文档停在「在用 / 在议」，只有 3% 被正式宣告死亡。

所以「状态」不是可信信号，但「时间」是。 我们把两者交叉，得到一个比孤儿率更锋利的指标：

在 KEP 样本上，它是 26% + 30%（僵尸草案 + 化石制度）。这个指标的意义在于：它不需要判断文档的内容是否正确，只需要判断它的状态声明是否还成立 —— 而后者是可自动计算的。

同一逻辑放到企业里：制度库里最常见的不是「错的规定」，而是「早就没人执行的、仍然标着『现行』的规定」。

五、怎么治：把「只增不减」改成「主区 + 归档区 + 自动衰减」

我们不打算在这里推销工具，只公开规范与洞察 —— 因为这套东西的难点从来不是代码，是敢让制度退场。

1. 双区结构：主区只留当前有效，归档区保留原文

• 主区（默认只读的那一份）：只放当前有效、当前在用的内容。
• 归档区（*.archive.md）：被降级的条目原文整块搬过来，不删一个字，附原始位置行号。
• 找回：一次 grep 就能找到 —— 归档不是删除，是降低默认可见度。

这是整套规范里最重要的一条设计：降级的动作必须是可逆、可追溯、零信息损失的，否则没人敢执行它。

2. 稳定 ID + 状态字段：让制度可被引用、可被批判

每个条目一个稳定 ID（用于跨区引用与去重），加上时间与状态字段。没有 ID 的条目无法跨区引用，也就无法自动衰减。

3. 衰减判据（我们的现行值，可调）

判据	规则
保护窗口	建档 ≤ 14 天 → 不降级（新东西永远先保护）
存疑窗口	未完成且 > 45 天未动 → 存疑（搬归档，可找回）
已完成	→ 候选归档
P0 / 骨架 / 机构记忆	永不降级（文件头、契约、设计理念）
规划时域保护	段名含「（a–b 个月）」→ 未触碰 ≤ b×30 天不降级，到点自动失效
无建档日期	视为缺元数据，保持主区，等时间戳回填（不猜）

判据里有两条特别值得抄走，都是踩坑换来的：

判据值不是普适标准。 14 / 45 天是我们在自己库上标定出来的观测值，换一个库必须重新标定 —— 我们标定过一次：同样是「待办型」文档，一份 bug 归档文档用 90 天更合适（它的条目天然存活更久）。照抄别人的阈值，等于把别人的经验当成自己的事实。

4. 只搬不删 + 幂等 + 索引是派生物

• 只搬不删：降级 = 原文进归档，永不丢失。
• 幂等：同一份输入重复执行，结果一致（我们靠「按 ID 去重」实现）。
• 索引由脚本从归档区生成，不允许手写 —— 手写台账是第一个会腐化的东西（它自己就是「制度」）。

5. 分层看：不是所有高孤儿率都需要治理

回到表 3：先给目录分类，再决定处理方式。

• 活制度层（高引用）：正常维护。
• 档案记录层（天生高孤儿）：整层归档，不进「腐化」统计。
• 中间地带：逐条看，用上面那张判据表。

六、边界：有五样东西不能外置

这套方法不是万能的。我们的结论是：记忆可以外置，但下面五样不行 —— 它们不是记忆问题。

不能外置	原因
权力	谁有权决定什么，是政治问题。系统可以执行规则，不能拥有规则制定权
责任	出事必须有人担责，不能是「系统自动决定的」
不可验证的判断	制度里大量「酌情 / 合理 / 必要时」—— 没有廉价验证器，自动聚合只会退化成平均值
系统性偏见	组织文化里的偏见会被机制放大 N 倍且无人察觉
审计要求	匿名的自动痕迹不可追溯 → 必须补稳定 ID 与人为签核

一句话：这套机制解决的是「注意力」问题，不是「权力」问题。 它能减少人花在维护制度上的注意力，但不能替人做决定。

七、我们对自己的库做了什么（自检）

同样的口径，也回头量了我们自己维护的文档体系（117 份 + 另一个 53 份的笔记库）：

样本	规模	零引用率	死重体量
工程文档库	117	12%	170 KB
笔记库	53	13%	26 KB

比三家公开样本好得多（因为库小、刚建立不久），但仍有 170 KB 是可以清退的 —— 而且这些孤儿文档正在被每一次 AI 会话重复读取。

这就是我们要说的第一件事：这件事每个组织都该做一次，而且一周内就能出数字。

你的第一个动作（一周内）

把现有制度 / 文档按「最后被引用时间」排一遍，算出：

若 > 50%，说明「制度只增不减」这个问题在你的组织里是真实的、且可量化的。

注意：这个动作不需要部署任何系统，也不需要改造任何流程 —— 一个只读脚本、一份导出的链接表就能做。先拿到数字，再决定要不要治理。

八、复现（数据全部来自公开仓库）

采集口径（写清楚，任何人可用 30 行脚本重算）

1. 遍历样本仓库全部 .md（跳过 .git / node_modules 等目录，跳过 > 500 KB 的巨型文件）。
2. 从每个文件里提取链接：Markdown ](target)、[[wikilink]]、站点式引用 {{< ref "path" >}}。
3. 把相对路径 / 仓库绝对路径解析成样本内的对象；自链不算。
4. 统计每个对象的入链数：入链 = 0 → 孤儿。
5. 孤儿率 = 孤儿数 ÷ 总数；死重体量占比 = 孤儿字节 ÷ 全库字节。
6. 分组统计时，先在整库上算链接图，再按目录分组（否则会系统性高估高孤儿率）。

数据源与样本规模

样本	来源	规模	形态
CNCF TOC	github.com/cncf/toc	598	链接型
Kubernetes community	github.com/kubernetes/community	964	链接型
GitLab Handbook	gitlab.com/gitlab-com/content-sites/handbook	4,717	链接型（87% 文件含链接）
Kubernetes KEP	github.com/kubernetes/enhancements	652	提案型（自带状态字段）
Kubernetes website	—	8,215	站点型，口径失效，已作废

数据日期：2026-09-12。 全部为公开仓库当日快照，结论只在当日数据上成立（这类库每天都在变）。

结语

我们用同一把尺子量了三个治理能力最强的组织，量到的不是「他们管得不好」，而是一个所有组织共有的结构性缺陷：

制度的生产是有主人的（谁写谁加），制度的死亡是没有主人的（没人敢删）。

蚁群的信息素会自动蒸发 —— 于是留下的，一定是还在被使用的那一部分。人类组织至今没有这一半机制：所有知识库、所有 SOP、所有流程文档，最终都走向同一个终点 —— 只增不减，直到没人看。

所以该做的不是再写一份《知识管理规范》，而是给制度装上死亡机制：

如果你的库算出来 > 50%，欢迎把数字（连同你的口径）发给我们 —— 我们想知道这个比率在真实企业里是什么分布，也想把有效的反驳写进下一版。

本文数据可复现，口径与判据全部公开。欢迎用同样的口径量你自己的库，也欢迎指出我们口径里的漏洞 —— 我们会把有效的反驳写进下一版。

交流 / 索取规范全文：[联系方式待定]