对标 Mintlify：Baklib 为什么更像中国企业的 AI 内容基础设施
浏览：9
巴克励步
从 Mintlify 的融资、流量与「四层文档」谈起：当近半数请求来自 AI 代理，技术文档到底算什么；再落到本土企业更关心的治理与多站点。
围绕技术文档做产品的 Mintlify 近期完成约 4500 万美元的 B 轮融资，投后估值约 5 亿美元，其 2025 年 ARR 约 1000 万美元，较前一年增长约 10 倍；净收入留存率约 150%；企业年度合同价值同比约增长 15 倍。
这类数字当然会波动，但它们说明一件事：资本市场愿意为一个判断下注——当开发者越来越多在 Cursor、Claude、GitHub Copilot 里「让 AI 代查文档」时，文档不再只是排版好看的网页，而更像产品与模型之间的接口。
从「打开 App」到「先问 AI」
如果客人不再翻菜单，而是让助手按口味、预算和忌口推荐菜品，那菜单就必须以 AI 能理解的方式存在；否则在助手眼里，这道菜可能就等于不存在。软件行业正在发生类似迁移：人不再默认自己逐层点开站点，而是先表达需求，由 AI 在后台完成查找与衔接。
Mintlify 联合创始人 Han Wang 的判断被反复引用：文档不再只是人类的资源，它正在成为 AI 理解一款产品的主要界面。变化很具体——开发者仍会看文档，但更多时候是在 AI 工具里提问，由 AI 去检索、阅读，再把答案带回来。
一组流量数据，把「感觉」变成「比例」
Mintlify 自己公布过一份基于过去 30 天流量的统计：其托管的文档站点合计约收到 7.9 亿次请求，其中来自 AI 编程代理的请求约占 45.3%，几乎与传统浏览器流量持平。更细一点，仅 Claude Code 一个工具，就产生约 1.99 亿次请求。
这组数据的意义不在于「越大越好」，而在于它把争论从口号拉回机制：当接近一半的访问来自代理，文档的结构、时效与可引用性，就不再只是阅读体验问题，而会直接影响模型输出与后续动作。
人类可以跳读、容忍含糊，还能凭经验判断哪些信息可能过期；AI 更像「非常认真但不会举一反三的新员工」——你给什么，它就容易照单全收。结构乱，理解就偏；信息旧，它也可能把错误内容当事实说出去。Mintlify 的表述很直白：文档现在是产品与 AI 的接口，也是 Agent 执行所依赖的记录系统；不完整、不准确或结构混乱，产品就可能被 AI「忽略」。
Mintlify 在工程上做了什么：四层与一条链
按 Han Wang 的设想，一份面向 AI 时代设计良好的文档，至少叠四层：第一层是用 Markdown 呈现的结构化内容，让工具更快处理并减少 token；第二层是机器可读目录，让模型面对陌生站点时知道「这里有什么」；第三层是实时查询接口，让模型了解最新变化；第四层是类似 skill.md 的机制，用来描述能力边界——不仅告诉人类「是什么、怎么用」，还要让模型知道能调用哪些操作、输入输出与限制。
在托管站里，Mintlify 通常让每一页对应一个 Markdown 版本，剥离视觉噪音，只保留内容本体；并自动生成
llms.txt（给 AI 的精简目录）与 llms-full.txt（把整站内容拼成单一文件，供需要「一口气读完」的工具使用）。它还提供 MCP 服务器，让模型在回答问题时去查询当前最新文档，而不是依赖训练数据里可能已过时的记忆。文档里内置的 AI 助手也更克制：先检索当前文档体系，再基于命中的页面生成回答，并附上引用链接。维护侧则把更新尽量接回工程流程——提交代码差异后，系统判断功能变化，先生成文档修改草稿，再以 Pull Request 的方式进入人工审核。
开发者工具公司 Browserbase 的增长负责人也在报道里提到：他们会认真思考如何让 AI 推荐自家产品；通过 Mintlify 让文档「对 AI 可读且可解析」，确实带来帮助。把「写文档」从市场部门的边角料，拉回到与产品交付同一条链路上，这是另一层意义。
从对外 docs 到组织内部：同一套「知识层」逻辑
Mintlify 的客户场景也在外延：除了外部开发者查阅 API，越来越多公司把它用于内部知识库、工程手册、设计系统。原因很简单——企业内部的 Agent 要替公司做事，也得先读懂公司如何运转；知识分散在各类文档里，如果缺少结构化维护，上层应用就会集体失真。
一家公司调整了产品定价，帮助中心没同步，于是所有基于旧内容搭建的 AI 客服，持续向用户输出错误信息。结论并不新鲜，却值得反复说：问题常常不在模型，而在知识层是否可靠、是否持续进入发布与审计闭环。Mintlify 把自己的叙事也往上抬了一格：每家公司都需要可靠、结构化且持续更新的知识层，才能在人工智能时代保持竞争力。
把镜头转回中国：同样的接口问题，不同的默认约束
但落到中国企业的采购与建设语境，默认约束往往多一层：同一套内容要同时服务官网、帮助中心、伙伴门户、内网 Wiki 与素材库；权限要细分到「谁能看、谁能改、谁能用 AI 调」；审计与合规不是加分项，而是上线前提。换句话说，内容中台要先解决「可发布、可授权、可追溯」，再谈「对模型友好」；否则 AI 只会把错误与泄露放大。
这也是把 Baklib 放在「AI 内容基础设施」一侧讨论的原因：不是功能清单对打，而是默认问题集合不同——本土团队很少只为一个对外 docs 立项就结束，更常见的是多站点、多团队、多语言、内外网并存下的统一治理；文档站可以是子集，但内容底座必须是全集。
Baklib 的 AI 工作对接能力： 如何让网站对AI大模型可见：6种有效做法完整指南
机会与风险：入口未必唯一
传统文档工具会守住存量；AI 知识平台会扩展边界；更底层的 Agent 接口也可能尝试绕过「网页式文档」这条路径。Mintlify 的机会在成为 AI 理解产品的入口之一，风险也在于入口未必唯一。对读者而言，更现实的收获或许是另一句话——别只问 AI 能做什么，也问问它运转时需要什么：数据、算力、接口，以及一套可靠、可持续更新的「产品说明」。
把 AI 当作你的用户之一，为它准备它真的读得懂、查得到、引得起的内容，这类需求还会继续冒出来。至于最后长成的产品形态，更可能是多条路线并存：有人先把文档站做到极致，有人先把组织级知识底座铺稳。选型时不妨先问一句：你现在缺的是哪一段。
