导读
先说清楚参考来源，免得正文里突然冒出一串品牌名显得突兀。
本文主要参考了四份公开材料：Contentful 的《Ultimate Guide to Headless CMS》、Kontent.ai 关于 Headless 与知识管理的说明、Human Made 的《Headless WordPress》白皮书，以及 Baklib 自己的无头内容文档。下面提到这些名字，是在注明出处，不是在做广告。
Contentful 那份指南里有一段很刺眼的行业速写：数字渠道一多，企业可能堆出 dozens or even hundreds 个 CMS 实例，然后在网站 CMS、App CMS、数字屏 CMS 之间 copy and paste。Human Made 从另一侧写解药——让 CMS 成为 central hub，经 API 喂多个前端。Kontent.ai 则把知识管理写成 single source of truth。
Baklib 的回答，不是再发明一个英文缩写，而是把枢纽拆成可运营的三库：资源库、知识库、应用库。下面把证据、落点，以及反面情况，尽量说开。
一、场景：同一句话，四个地方对不上
某硬件公司发布固件说明。官网营销页写了「支持 OTA」；帮助中心还是旧版「仅 USB 升级」；销售 PDF 停在网盘三个月前；App 推送又用了第三种表述。客服工单上升，老板骂协同慢。
你有没有这种感觉：慢是表象，不确定才是内核。大家不知道事实源在哪里。不确定比延迟更伤信任。
Contentful 把这种病归因于渠道中心技术：每出现一个新数字产品，就再装一套 CMS，最终只能靠复制粘贴维持表面上的一致。
把「几百个 CMS」翻译成中国团队语境，你未必真有一百套系统。但影子实例同样要命：官网与海外站双语不同步；飞书文档与站点两套目录；代理商活动页私服战役后无人回收；销售擅自改 PDF，直到价格冲突。渠道私有内容库，才是泛滥的本质。
二、素材证据：统一枢纽与中枢叙事
2.1 Contentful：Unified / Modular / Organized / Extensible
Contentful 试图给业务与开发找一种共同语言，那就是内容结构。它认为好基础设施大致要具备四点：统一（单一枢纽，一处改处处生效）；模块化（逻辑块，而不是整页捆死）；有组织（分类清晰，支持并行）；可扩展（模型可演进、工具可接）。
驱动变革的力量，它写了两个。一对太多 CMS 的挫败；二是数字化转型要求更快构建与交付。文中还引过 Forrester 分析师 Mark Grannan（2018）谈 Web CMS 终结、指向 Agile CMS——协作策展，并跨渠道迭代交付。我不是分析师，不能替那篇文章背书；但「太多 CMS」这件事，听上去确实有道理。你可以对照自己公司：真正在用的内容入口，是不是已经超过三套。
2.2 Human Made：31% 与 TechCrunch
Human Made 白皮书称，WordPress 覆盖顶尖一千万网站超过百分之三十一，并主张从 monolithic 走向枢纽。TechCrunch 案例是旁证：WordPress 作 CMS，无头 React 作前端，全站重建，编辑与技术团队更独立。Fairfax Media、ustwo、NPM 同样走「后台创作 + 可替换前端」路径。
这些是行业旁证，不是 Baklib 客户故事。它们证明一件事：中枢加多前端，可以上生产。也暗示另一件事：若每个项目都自建 React，会把中小团队挡在门外。枢纽解决「内容从哪来」；「头怎么长」仍是成本问题。
2.3 Kontent：知识管理与多品牌预览
Kontent 的用例里，企业常为多品牌运营多站，却希望共享内容：同一界面创建、复用、预览、发布。知识管理则强调单一事实源，以及门户化体验。它的 Content hub 图把输出画到 Web、Chatbot、Mobile、PDF、Social、VR/AR——触点会生长，枢纽应尽量稳定。
从上面几份材料可以看出一个交集：大家吵的不是「要不要网站」，而是「事实源能不能只有一份」。
三、Baklib 三库如何接住这些原则
库 | 职责 | 对位原则 | 没有它时的反面 |
|---|---|---|---|
知识库 | 结构化文档车间：目录、协作、版本 | Organized，部分 Modular | 正文在 Word 与邮件，AI 无可靠语料 |
资源库 | 图视频 PDF 与知识片段，dam-id 引用 | Unified 的资产面 | 旧海报、失效外链、不稳定 CDN |
应用库 | 模板站点：绑内容、域名、权限、发布 | Extensible 的体验面 | 每新产品再立一套站或再买一套 CMS |
无头三种用法，可以这么理解：知识片段作短文本原子；知识库承载体系化长文；模板站点作外衣，并可经 API 出站。价值链口诀是：写、管、找、发。
典型 Wiki 路径是：知识库撰写后，发布到 Wiki 应用，再在应用库运营。CMS 也可以把内容留在知识库，站点只做体验层。名字很土，但好记——图走资源库，文走知识库，皮走应用库。
四、思辨：三库会不会变成三个新孤岛？
会。如果只开账号、不开引用纪律，枢纽就退化成更大的网盘。拼盘失败，常败在权限与引用链，而不是工具数量。
三库的意义是契约：图走资源库，文走知识库，皮走应用；改资产可以对齐，而不是再复制一份。另一个思辨，其实也来自 Contentful 那条线：统一枢纽解决内容如何流出，还要问内容如何组织。若应用库里仍整页粘贴 HTML、从不引用知识库与片段，你只是买了三个菜单的传统 CMS。
更现实的顺序，也许是：先证明统一，再谈全渠道；先用模板替换最贵的头（帮助中心与文档站），再把个性化的头留给自研。
五、可执行建议
第一，选一个高投诉主题，例如安装与升级，只迁这一枝到知识库。
第二，相关截图与安装包进资源库，页面用选择器引用，尽量禁止作者私传网盘链。
第三，用 Help 或 Docs 模板发一版，与官网旧描述对照一周。
第四，再决定是否横向铺官网或 Chat。用数据证明影子实例在减少，再谈扩展。影子实例是否变少，比架构图是否好看更重要。
深读：复制粘贴经济的隐性成本
复制粘贴看起来便宜，其实把成本藏进了四处。
第一处是校准成本：每次战役前，市场、产品、支持要开会对齐口径。第二处是纠错成本：用户截图发来旧说明，客服无法判断哪份有效，只能升级工单。第三处是机会成本：本可用于改进产品的工程师，在不同系统里来回改同一句话。第四处是人工智能成本：你若用错误或过期文本喂模型，会以更自信的语气输出错误答案。
Contentful 描述的几十上百个 CMS 实例，在组织里往往以更隐蔽的形式存在：每个部门的「正式文档」，其实是各自收藏夹。统一枢纽不是要消灭部门站点，而是要消灭部门私有的事实源。帮助中心和官网可以长得不一样，但「如何升级固件」这句话，最好只有一个正文源头。
Baklib 三库提供的是技术前提；组织仍需指定每条关键内容的 Owner。没有 Owner 的枢纽，只是更大的网盘。
再看 TechCrunch 那类路径：无头前端让呈现技术创新，但不自动产生治理。若只把应用库当建站工具，从不把规格放进知识库，那就重复了「有头无身」的错误——与「有身无头」的纯仓库错误刚好对称。混合架构要求两边都用起来：身子要进库，头要能换。
小结
结束 CMS 泛滥，靠的不是更多插件，而是枢纽。Baklib 把行业里的 Unified hub 落成三库：资产可引用、知识可复用、体验可发布。这是混合无头的第一块砖。
可能是银弹，但也未必。更现实的是：先把一句高投诉内容迁进单一事实源，看看复制粘贴还剩多少理由。
延伸阅读
- Human Made（Headless WordPress 相关讨论可从其公开材料入手）
