产品手册与 Docs AI 可见性：协作 Wiki 到可发布文档站的 llms.txt / GEO 清单
产品手册与 Docs 的 AI 可见性，指公开文档站能否被大模型与 AI 助手发现、正确引用并给出可溯源答案；常用信号包括 llms.txt、Markdown 导出与 GEO（生成式引擎优化）写作结构。协作 Wiki（Confluence / 语雀 / 飞书知识库等）擅长对内共创，但匿名公开、品牌化站点与机器可读导出往往不是主路径；GitBook、Document360 等发布型 Docs 已把 llms.txt / GEO 做成平台能力。本文给出从协作文档迁到可发布文档站的对照清单，并说明 Baklib Wiki 在知识资产发布、权限交付与一源多站上的适用边界。
浏览 1
巴克励步
导语：Docs AI 可见性不是「再挂一个聊天机器人」
产品手册与 Docs 的 AI 可见性，指公开文档站能否被大模型与 AI 助手发现、正确引用并给出可溯源答案；常用信号包括
llms.txt、Markdown 导出，以及面向生成式引擎的写作结构（GEO，Generative Engine Optimization）。它首先是发布面与机器可读信号的问题，其次才是站内 AI 问答能力的问题。协作 Wiki（Confluence、语雀、飞书知识库等）擅长对内共创、评审与版本讨论，但匿名公开、品牌化站点与面向爬虫的结构化导出往往不是主路径。GitBook、Document360 等发布型 Docs 已把
llms.txt / GEO 做成平台能力：自动生成索引、提供 .md 导出、用描述字段同时服务 SEO 与 AI 发现。见 GitBook：What is llms.txt、Document360：LLMs.txt。把话说死一点：很多团队以为「Wiki 里写完 + 开个公开链接」就等于产品手册站。对人类读者，这也许勉强可读；对 AI 助手，缺少权威导览、缺少干净 Markdown、缺少可 chunk 的原子页时，模型更容易去引用论坛旧帖、过期镜像或第三方转述。GitBook 把
llms.txt 描述为告诉爬虫「哪些内容最适合被 LLM 摄取」的轻量约定——它不是访问控制，也不替代 robots.txt，而是补上 sitemap「只列 URL、不解释页面意图」的缺口。见 What is llms.txt、Document360 LLMs.txt。本文给出从协作文档迁到可发布文档站的对照清单，并说明 Baklib Wiki 在知识资产发布、权限交付与一源多站上的适用边界——与昨日讨论的 Wiki-first / Search-first 路径分流互补：今天只谈对外产品手册站 + GEO / llms.txt，不重复 Rovo credits 或企业搜索选型。
为什么现在要谈：用户先问 AI，再决定是否进站
文档消费路径已经变了。GitBook 在介绍
llms.txt 时写得很直白：很多人不再先点侧栏，而是先问 ChatGPT、Claude 或 Perplexity，期望快速答案、准确引用与最新步骤。文档站仍需要传统 SEO，但也需要给 AI 爬虫一条通往「权威、现行」页面的清晰路径。见 What is llms.txt。同一篇文章中，GitBook 提出一个值得采购侧单独标注来源的主张：AI agents 已占 docs readers 的很大比例（超过 40%）。这是 GitBook 的产品主张与观察，不是本文另行调查的行业普查数据；引用时请标明出处，并与自身站点分析对照。见 What is llms.txt。
对产品手册团队，这意味着三件事同时成立：
- 公开真相源必须可被机器抓取：门禁、脚本墙、仅登录可见的「假公开」会削弱引用；
- 结构要比营销文案更重要：原子页、清晰标题与描述、可 chunk 的段落，直接影响答案质量；
- 协作草稿 ≠ 对外 Docs：内网 Wiki 里写得好，不等于对外站具备
llms.txt/.md/ 品牌化交付。
GEO（生成式引擎优化）正是围绕后两点展开的实践：按 GitBook GEO 指南，GEO 是让文档易于被 LLM 可靠摄取并准确引用的结构化写法；与 SEO 相比，它更强调机器可读性、来源归因与可答性。指南同时说明 GEO 与 AEO（答案引擎优化）目前常被互换使用，尚无统一行业标准名。见 GitBook GEO guide。
Document360 则从知识库运营侧补充动机：用户越来越先问 AI 助手再访站；没有结构化内容索引时，答案可能引用过时或第三方来源；有了
llms.txt，文章描述同时贡献 SEO 摘要与 AI 可发现性，并可用单一文件审计爬虫可见范围。见 Document360 LLMs.txt。GitBook 还提醒：文档不只答技术问题，也会影响潜在买家问「产品是否支持某工作流」时的答案素材——因此 AI 友好文档工作流关乎增长，而不只是支持工单。见 What is llms.txt。对照表：协作 Wiki vs 发布型 Docs
选型时先分清「一起写」与「写完后正式发布给人与 AI」。下表把常见协作 Wiki 与发布型 Docs（含 Baklib）放在同一维度上对照——定性为主，不发明未经验证的份额或性能数字。
| 维度 | 协作 Wiki（Confluence / 语雀 / 飞书知识库等） | 发布型 Docs（GitBook / Document360 / Baklib 等） |
|---|---|---|
| 对外品牌站 | 多为套件内空间；品牌化独立站与主题能力通常不是主打 | 面向公开/半公开文档站、帮助中心、产品手册站点建设 |
| 匿名 / 公开访问 | Confluence 可通过站点与空间级匿名访问「做成」公开（需管理员显式开启，非默认 Docs CMS） | 公开知识库 / 发布站点是一等公民；公私内容边界更清晰 |
| SEO | 匿名开启后可被搜索引擎索引，但信息架构与 meta 工作流因产品而异 | 常见标题、描述、sitemap、稳定 URL 等站点级 SEO 能力 |
llms.txt / .md 导出 |
一般不是开箱平台能力；需自建导出与维护 | GitBook / Document360 可自动生成 llms.txt（及 Markdown / full 导出等） |
| 站点级权限 | 强在空间/页面协作 ACL；对外交付需额外配置与治理 | 站点 / 栏目 / 页面级公开、登录可见、授权可见更贴近「交付」 |
| 多站点 / 多语言 | 视套件与空间拆分而定 | 发布型产品更常强调多站、多语言与内容复用 |
| AI 问答边界 | 偏组织内助手 / 连接器（权限随账号） | 站内 AI 搜索 / Assistant + 对外 LLM 可发现信号（llms.txt、MCP 等）可并存 |
Confluence 侧：Atlassian 支持文档说明，向匿名用户开放空间可把内容分享给组织内外；一旦站点允许匿名访问，内容可被搜索引擎索引。适用例子包括公开路线图、开放知识库与支持文档——但这是配置路径，不是「为产品 Docs SEO / GEO 原生设计」的发布型 CMS。匿名访问是「全有或全无」：不能只对部分匿名访客开放。站点级、空间级、内容级可分层控制；新站点默认强化站点级管控。见 Make a space public with anonymous access。
产品文档方法论上，Atlassian 强调用户文档、技术文档、流程文档与参考文档的分类，以及清晰、完整、以用户为中心、含视觉辅助、保持更新与一致性等要件；并建议用集中平台协作与版本追踪。这些是「写好产品文档」的通用要求，与「平台是否自动产出 llms.txt」是不同层的能力。见 How to create effective product documentation。
发布型一侧：GitBook 强调自动生成
llms.txt / llms-full.txt、每页 Markdown、「Open in ChatGPT / Claude」、以及 Assistant / Agent / MCP 等 AI 能力，并提供权限层级、SSO/SAML、以及可按组织或站点关闭 AI。见 GitBook AI features、What is llms.txt。Document360 对公开知识库自动生成 llms.txt，条目指向 .md URL，并依赖 GEO/SEO 描述字段；站内 Eddy AI Search 提供带引用的直接答案，另有 Chatbot、MCP Server、以及按项目开关 AI 能力等控制面。见 Document360 LLMs.txt、Document360 AI。Baklib 定位于知识资产发布与站点交付：品牌化 Wiki/手册/帮助中心、树形结构、站点/栏目/页面授权，以及内容作为 AI 检索上下文；知识库需绑定应用站点才形成对外 URL，强调分发引用而非临时公开链接。见 Baklib Wiki、kb-publish。
一句话对照：协作 Wiki 优化的是「组织内把知识写出来」；发布型 Docs 优化的是「把已治理知识交到人与 AI 都能正确消费的公开/半公开界面」。 两者可以并存，但不要用同一套空间配置同时假装完成两件事。
llms.txt 实操清单（基于 GitBook + Document360 官方）
llms.txt 不是访问控制文件，也不替代 robots.txt：它是给 AI 爬虫的轻量导览，指向权威页、结构化导出与高信号来源。GitBook 与 Document360 都强调：有 sitemap 仍不够——sitemap 列 URL，但缺少「每页在说什么」的上下文；llms.txt 用标题、链接与短描述补上这一层。见 What is llms.txt、Document360 LLMs.txt。可直接照着做的清单：
-
只把公开、现行内容纳入信号面
Document360 写明：llms.txt仅为公开知识库、以及混合库中的公开内容生成。GitBook 则对已发布文档自动生成并保持同步。草稿、归档、实验页不应抢占权威入口。GitBook 手工流程同样建议：先识别权威内容（现行指南、参考、快速开始、changelog 与 Markdown 导出），排除单薄页、重复页、草稿与归档。见 Document360 LLMs.txt、What is llms.txt。 -
补齐描述字段（GEO/SEO description）
Document360：无描述时条目可能只剩标题；应在 AI & search descriptions (GEO/SEO) 中写摘要式描述（官方建议约 150–160 字符，且适合 SEO 摘要与 AI 决策共用）。忌「了解 SSO」式悬念句，宜「说明如何用 SAML 2.0 配置 SSO」式可检索摘要。优先补高流量与基石文章；Step by step guide 也应写描述，否则在llms.txt中偏弱。见 Document360 LLMs.txt。GitBook 同样建议用清晰描述说明页面回答什么问题，可复用 meta description。见 What is llms.txt。 -
优先链到 Markdown / 机器友好格式
Document360 的llms.txt条目故意指向每页的.md版本，而非带导航 chrome 的 HTML；.md页顶部还可回指文档索引，便于 agent 发现全量目录。GitBook 也自动提供每页 Markdown，并生成llms-full.txt作为更完整的单文件导出（大站需注意体积可能过大）。见 Document360 LLMs.txt、What is llms.txt。 -
排除规则与 sitemap 对齐
Document360 FAQ 明确：开启「Exclude from external search engine results」会同时从sitemap.xml与llms.txt移除该文——两套文件遵循同一套外部索引规则。选型与运营时要把「不想被 Google 抓」与「不想被 LLM 索引」当成同一治理开关理解。重复 meta 描述虽仍会出现在文件中，但会降低检索质量，应避免。见 Document360 LLMs.txt。 -
Canonical 与版本清晰
GitBook 最佳实践：优先权威页、版本意图明确（现行版可辨识，或拿掉旧版入口）、信息架构大改后复审llms.txt。见 What is llms.txt。GEO 指南亦强调稳定、可读的 URL，避免随意改 slug 打断历史引用与 embedding。见 GEO guide。 -
发布后审计
用公开可达性检查文件是否存在，例如：curl -I https://docs.example.com/llms.txt（路径按你的文档根调整；子路径如/docs/llms.txt也可行，关键是公开、稳定、易发现）。新发布文章在 Document360 侧可能有短延迟，缺失时稍等再刷新。见 What is llms.txt、Document360 LLMs.txt。 -
分清「对外 llms.txt」与「站内 AI」
Document360 说明：llms.txt只服务外部 AI 爬虫；站内 Eddy AI 使用另一套索引，不受llms.txt影响。GitBook 则把 Agent（改进内容）、LLM-ready 格式 / MCP（连接）、Assistant（对用户作答）串成闭环，并强调权限、SSO、以及可关闭 AI 能力。见 Document360 LLMs.txt、GitBook AI features。 -
手工兜底时保持简单
若平台不自动生成：在文档域根放置纯文本llms.txt，用 H1 标题、分组小标题、带短描述的链接组织权威页；有 Markdown 版本就优先链.md。GitBook 提醒格式仍在演进，重点是「让最重要来源显而易见、结构化、可抓取」，而不是追求某一种尚未定稿的完美 schema。见 What is llms.txt。
GEO 写作清单（对照 GitBook GEO guide）
按 GitBook GEO guide，可把写作与站点设置收成下列可验收项：
内容
- 原子页：一页一个清晰意图（单一概念、任务或 API 区域），便于 chunk。
- 描述性标题层级：H1/H2/H3 可预期，利于答案内深链。
- 直白语义，少营销修辞：LLM 与技术读者都更依赖精确表述。
- 示例贴近概念：短代码与请求/响应靠近说明；代码块带语言标签与标题，并尽量给出已知输入输出。
- 术语一次定义、稳定内链：帮助模型建立概念关系。
- 段落可 chunk：指南建议单节控制在约 200–400 词。
- 问题型标题：如 “How to rotate an API key”，对齐用户提问方式（对 SEO 也有帮助）。
- 图片写 alt / 简洁说明：描述意图而非只描述外观；能用文本/Markdown/JSON 就少依赖纯截图。
- 直接回答高频问题：识别用户常问 AI 的产品问题，为每个问题准备带清晰步骤的页面。
站点与元数据
- 审计每页是否具备 title 与 description——指南把这视为帮助 LLM 与搜索引擎理解页面的极重要信号；
- 启用全站 sitemap 与
llms.txt/llms-full.txt； - 使用结构化元数据（title、description、
robots、Open Graph 等）； - 公开文档避免插页门禁与脚本墙——爬虫难以穿过 paywall；要被引用，就让公开内容易于访问；
- 保持品牌与产品名拼写一致；补充作者 / 最后更新等 provenance 信号。
如何自测 GEO（官方建议，定性）
- 向多个 AI 工具提出针对产品功能与工作流的具体问题，检查是否出现对特定页面与锚点的直接引用；
- 跟踪来自 AI 工具的引荐流量，观察哪些页被引用最多，并改进未被引用的内容；
- 记住模型与搜索引擎需要重新抓取，GEO 改动不会瞬时反映在答案里。见 GEO guide。
GEO 指南的三条底层提醒也很适合写进文档规范：LLM 奖励写得好、结构好的文档；不要「为 AI 而写」而牺牲用户可读性；有帮助、准确、及时更新的内容会被答案引擎与搜索引擎一起奖励。 见 GEO guide。
权限与对外边界：公开 Docs ≠ 登录手册 ≠ 内网 Wiki
把交付面拆成三层，采购与架构会清晰很多：
| 交付面 | 典型读者 | AI / 爬虫预期 | 常见工具形态 |
|---|---|---|---|
| 公开产品 Docs / 手册站 | 匿名访客、潜在客户、集成方 | 可抓取、可引用、llms.txt 有意义 |
GitBook、Document360 公开库、Baklib 对外站点 |
| 登录后客户手册 | 已签约客户、合作伙伴 | 通常不应进公共 llms.txt；站内 AI 按账号权限 |
带认证的 Docs / 客户门户 |
| 内网协作 Wiki | 员工 | 企业助手按 ACL；不是对外 GEO 主战场 | Confluence、语雀、飞书等 |
Confluence 匿名空间证明「协作 Wiki 能公开」，但官方叙事仍是空间权限配置：站点级是否允许匿名、空间级是否授予、内容级是否再限制。新站点默认强化站点级管控；匿名一旦打开即面向全网，且可被搜索引擎索引。空间内默认对匿名开放的内容会全部可见，除非在内容项上改为「仅限特定人员」或父项限制向下继承。见 Make a space public。把它当成产品 Docs SEO / GEO 平台，通常还要自建导出、描述治理、品牌主题与多站分发——成本会从「开个开关」变成「自建发布链路」。
Baklib 一侧强调的是可交付的边界：单页或栏目可设公开、仅登录可见或特定权限可见，粒度到站点、栏目、页面；对外 URL 来自绑定应用站点后的发布，而不是临时分享链接。适合把「正式真相源」与协作草稿分开，并在多站点矩阵中复用同一知识资产。见 Baklib Wiki、kb-publish。
GitBook 与 Document360 则明示 AI 侧的控制面：权限层级、SSO/SAML、按组织或站点（或项目）关闭 AI、答案 grounded 在自有知识库、以及「内容不用于训练公有模型」等承诺（以厂商现行政策为准）。Document360 还强调人工审核 AI 产出后再发布；GitBook 区分 Agent 改进内容、格式/MCP 对外连接、Assistant 对用户作答三步。见 GitBook AI features、Document360 AI。
公开 Docs 的 GEO 与权限并不冲突：冲突通常来自「把不该公开的内容放进了公开库」，或「想被 AI 引用却把门禁挡在爬虫前面」。正确做法是拆库 / 拆站，而不是指望一个空间同时满足内网密级与全网可引用。
选型决策树：仅对内 / 对外手册 / 两者并存
按主诉求走三条路径：
-
仅对内协作
目标是共创、评审、会议纪要与内部 SOP。优先协作 Wiki（飞书 / 语雀 / Confluence / Notion 等）。AI 重点在组织内助手与权限穿透，而不是公共llms.txt。Atlassian 对产品文档的「集中平台、持续更新、协作」建议仍适用，但验收标准应是内网可发现与 ACL 正确，而非 GEO 引用率。见 product documentation guidance。 -
对外产品手册 / 开发者 Docs / 帮助中心
目标是品牌化站点、匿名可达、SEO + GEO、可审计的发布。优先发布型 Docs（GitBook、Document360、Baklib 等）。上线验收应包含：公开 URL、sitemap、llms.txt（或等价机器索引）、描述字段覆盖率、站内 AI 引用可点开、以及公开页无门禁。GitBook / Document360 的平台能力可显著降低「自建导出脚本」的维护成本。见 What is llms.txt、Document360 LLMs.txt。 -
两者并存（多数成长期 B2B 的稳态）
内网 Wiki 管草稿与跨部门协作；发布型站点管客户可见真相源。同步机制可以是人工发布、Git sync、或 CMS/知识库「一源多站」引用——关键是：对外 AI 只能引用已发布面。把发布当成变更管理的一环：功能上线日，对外 Docs 与内网说明同步达到「可引用」状态，而不是事后补文档。
分流口诀：
- 要「一起改」→ 协作 Wiki；
- 要「被 Google 与 LLM 正确引用」→ 发布型 Docs + GEO /
llms.txt； - 要「同一知识资产按站点权限交付」→ 关注一源多站与站点/栏目/页面 ACL（Baklib 的主场叙事）。见 Baklib Wiki、kb-publish。
PoC 两周可执行最小集：
- 列出 Top 20 对外问题，映射到是否已有公开原子页；
- 检查文档根是否存在可
curl的llms.txt，并抽查描述是否摘要而非悬念； - 用低权限/匿名与登录账号各测一轮，确认密级内容未进入公开索引；
- 向 2–3 个 AI 助手提问同一组 How-to，记录是否引用你的现行页；
- 若短名单含 Baklib，验证「知识库 → 应用站点 → 对外 URL / 多站引用」链路是否可审计。见 kb-publish。
补充一条采购侧常见误判：把「站内 AI 搜索很好用」直接等同于「对外 Docs AI 可见性已经做好」。前者解决的是登录用户在你站点里的检索体验；后者解决的是 ChatGPT / Claude / Perplexity 等外部助手能否发现并正确引用你的公开手册。GitBook 与 Document360 都同时提供两类能力，但运营指标应分开看——站内无结果词、引用可点开，是一套；
llms.txt 覆盖率、公开 How-to 是否被外部助手引用，是另一套。见 GitBook AI features、Document360 AI、Document360 LLMs.txt。收束：把手册当成可被引用的知识资产
产品手册的下一阶段竞争力，不只是「目录好不好看」，而是：公开面是否对 AI 可见、可解析、可溯源。GitBook 用自动
llms.txt / Markdown / Assistant·Agent·MCP 把「给人看」与「给模型读」绑在同一发布流；Document360 用公开库自动 llms.txt、.md URL、GEO/SEO 描述与 Eddy 引用回答把同一逻辑产品化；Confluence 证明协作空间可以公开，但公开配置 ≠ 原生 Docs GEO 平台。见 What is llms.txt、Document360 LLMs.txt、Make a space public。若你的主诉求是把已治理知识做成品牌化 Wiki/Docs/帮助中心，按站点与栏目交付权限，并在已发布知识上做 AI 检索与多站分发，可以从 Baklib Wiki 与 知识库发布（kb-publish） 验证「知识资产发布 + 权限交付 + AI 检索 / 一源多站」是否覆盖你的站点矩阵——与协作套件、企业搜索形成互补，而不是互相冒充。
下一步建议：抽 20 篇对外核心手册，检查描述字段、公开可达性与
llms.txt（或平台等价物）；再用本文 GEO 清单改 5 个高频「How to」页，观察 AI 助手是否开始引用你的现行文档而非第三方转述。
### 把产品手册做成可被 AI 正确引用的发布面
若你要的是品牌化 Docs/Wiki/帮助中心、站点级权限交付，以及在已发布知识上做 AI 检索与一源多站分发，可以从 Baklib Wiki 开始验证发布链路与公开/登录边界。
[了解 Baklib Wiki](/app/wiki) · [查看知识库发布能力](/features/kb-publish)
常见问题
llms.txt 和 robots.txt / sitemap 有什么区别？
robots.txt 管爬虫能不能抓；sitemap 列 URL 但缺少页面意图上下文；llms.txt 用标题、链接与短描述给 AI 爬虫导览权威内容，不替代前两者。GitBook 与 Document360 都强调三者互补。Document360 还说明：排除外部搜索会同时从 sitemap 与 llms.txt 移除该文。Confluence 能不能当对外产品 Docs 站？
能「做成」公开：通过站点与空间级匿名访问分享支持文档等，且可被搜索引擎索引——但这是权限配置路径，不是原生 Docs SEO/GEO CMS。通常仍需自建导出、描述治理与品牌化发布链路；GitBook / Document360 / Baklib 等发布型产品把 llms.txt、公开站与交付权限做成一等能力。
GEO 和 SEO 是什么关系？
按 GitBook GEO 指南，GEO 是让文档易于被 LLM 摄取并准确引用的结构化实践，更强调机器可读性、来源归因与可答性；SEO 仍重要。GEO 与 AEO 目前常被互换使用。同一套清晰标题、描述、原子页与稳定 URL，通常同时利于两者。
公开 Docs 和权限要求冲突时怎么处理？
按交付面拆库/拆站：公开手册进可抓取站点并进 llms.txt；客户登录手册与内网 Wiki 保持认证与 ACL，不进入公共索引。不要把门禁挡在想被引用的公开页前面，也不要把密级内容放进公开库。Baklib 可用站点/栏目/页面级公开、登录可见或授权可见来划界。
