一个正在被换掉的入口
用户从哪里找到你的文档？两年前这个问题很好回答：搜索引擎。你把 SEO 做好，把人从 Google 引到文档站，事情就算完了。
但这两年，我越来越多地看到另一种路径：用户根本不打开你的文档站——他直接去问 AI，让 AI 替他把你的文档读一遍，再把答案转述给他。报告的数据把这个趋势量化了：直接导航（66%）和产品内链接（54%）仍然领先，但 AI 驱动的搜索（ChatGPT、Perplexity、Google AI Overviews）已经占到文档发现的 35%，离传统搜索引擎的 45% 只差一步。
而且公司越大，这个趋势越明显：AI 驱动的发现从微型公司的 25%，一路升到企业的 46%。换句话说，越是大公司，越可能发现自己的文档早就经 AI 的手被消费了——而自己却未必知道。
文档真的在“越出”站点
更让我在意的是，用户“在哪里”读文档，也在变。
40% 的组织已经把文档嵌进了产品内（嵌入式帮助、工具提示）；而与 AI 相邻的渠道正在快速冒头：18% 的用户通过编程 AI 助手（Copilot、Cursor）访问文档，16% 通过 MCP 服务器。这两个数字放在两年前，几乎是零。
团队显然也感觉到了。报告里，AI 助手（+9 个百分点）和 MCP 服务器（+8 个百分点）是计划投入扩张最大的两个渠道，远超传统渠道。我的判断很直接：内容反正会经由 AI 被消费，问题只在于，是不是在你的控制之下。
我们 Baklib 是怎么应对的
既然文档注定要“越出”站点，那它就得先“经得起”被 AI 读。这是我们做 Baklib 时反复提醒自己的一句话：不是再买一个聊天机器人，而是把内容当成 AI 就绪的资产。
我们把这件事拆成了几层。
第一层，平台内置的 AI 能力，开箱即用。 站内 AI Chat 以对话为首要入口，回答带来源引用，还能一键跳回完整文档；智能搜索把读者“搜不到”的成本降下来；AI 翻译支撑多语言帮助中心；AI 打标让资源库里的图片和附件也能被检索、被治理。
第二层，开放集成，让 Agent 直接读写你的内容。 通过 MCP、SKILLS、CLI 和 Open API，Cursor、Claude 或自研 Agent 可以直接在你的线上知识库上工作——查文章、辅助改写、批量整理、自动化发布。写入线上仍需人工确认，这条红线我们一直留着。
第三层，内容形态本身就要“AI Ready”。 我们坚持“结构化目录 + Markdown 正文”，因为内容质量直接决定 AI 回答的上限。这也是为什么上线 AI Chat 之前，我们总会建议客户先梳理 FAQ 和核心文档。
具体到日常，客户最常跑的是这样两条工作流：一条是开发者用 Cursor + MCP 管理线上内容——AI 助手直接读写组织的真实数据，省掉复制粘贴；另一条是面向客户的 AI 问答门户——装一个 Chat 模板、绑定知识库，读者就得到带引用来源的回答。
它和“拿 ChatGPT 外挂一个 PDF”最大的区别也在这里：问答锚定在你自己维护的私有知识库上，版本、权限、发布是一体的，回答可以追溯到具体页面，而不是通用大模型里的公开训练数据。 来源
所以呢：让内容“为 AI 而结构化”
回到那个判断——文档正在越出站点。既然拦不住，不如主动让它“适合被 AI 消费”。三条我们自己在做的事：
-
自包含的页面。 每一页都能独立回答一个问题，而不是依赖上下文。
-
显式的上下文。 把背景写清楚，让机器不必猜。
-
结构化的元数据。 用机器可读的方式标注内容，方便检索与引用。
报告的那句判断我一直记着：内容反正会经由 AI 被消费，只是可能不在你的控制之下。 与其被动等待，不如主动规划一条“基于 AI 的文档交付”路径——这也是我们做 MCP、做 llms.txt、做 AI Chat 的初衷。
