Docsbook 使用场景：团队聘请文档来完成的工作
团队带着六种情况而来，以及 Docsbook 如何分别应对。每种情况最终都会对应一份执行该工作的指南，因此你可以从实际情况出发，而不是从功能列表开始。
“我希望客户提问时，ChatGPT 能推荐我们”#
情境。 你拥有一款产品、客户和广告预算。有人询问 AI 助手哪个工具可以实现你所做的事情，而你的公司并未出现在答案中。
阻碍因素。 助手会推荐它能够低成本读取和核查的信息：产品的功能、价格、限制，以及背后的团队。如果这些信息没有写在它能够抓取的地方，它就会引用那些确实写明这些信息的竞争对手。
Docsbook 的作用。 Docsbook 将你的页面发布为服务端渲染的 HTML，因此爬虫无需运行 JavaScript 就能看到文本，并添加助手所关注的内容：sitemap.xml、规范 URL、JSON-LD、可见的最后修改日期，以及网站根目录下的 llms.txt。每个页面都有自己的 URL 和标题，因此围绕某个狭窄问题的页面可以在该问题上参与竞争。
从这里开始： GEO — 生成式引擎优化，然后查看 llms.txt。
“我们的文档有流量，但我不知道它是否带来了销售”#
现状。 分析数据显示有人阅读文档，但没人能说清阅读是否促成了注册，也不知道哪些页面浪费了访问机会。
阻碍因素。 页面浏览量无法描述访问路径。没有事件和明确的目标，文档站点报告的只是受欢迎程度，而不是进展。
Docsbook 的作用。 Docsbook 会在每个页面记录页面浏览量、搜索、阅读时长、反馈投票和跟踪事件，然后将其以路径的形式进行报告：哪些页面无人到达，哪些搜索没有返回结果，读者在离开前阅读了多远，以及他们来自哪些国家和使用哪些语言。将页面标记为漏斗步骤，并统计完成该步骤的读者人数。
"我们的文档比产品落后三个月"#
现状。 产品发布了变更。文档仍在描述旧行为，而所有人都知道这一点。
阻碍因素。 存放在代码仓库之外的文档需要额外的记忆步骤。在编写和发布之间加入构建与部署步骤，会把五分钟的修正变成一项无人愿意开始的任务。
Docsbook 的做法。 Docsbook 提供代码仓库中的 Markdown。用户访问网站时，它会重新检查 GitHub 并重新索引发生变化的内容，因此推送就是发布——无需构建步骤、无需 CI 流水线，也无需等待部署。编辑也可以来自网页编辑器或通过 MCP 由代理完成，并且这三种方式最终都会作为提交写入同一个代码仓库。
从这里开始： 连接 GitHub 代码仓库，然后管理您的文档。
“我们的客户不读英语”#
情况。 您在文档语言不是客户搜索所用语言的市场销售产品。手动翻译意味着英文一有变化，翻译内容就会过时。
阻碍因素。 只有当翻译内容与原文保持同步，并作为独立页面建立索引时，发布翻译才有价值。复制到文件夹中的内容两者都做不到。
Docsbook 的作用。 Docsbook 可将您的页面翻译成 15 种语言——英语、西班牙语、法语、德语、葡萄牙语、意大利语、俄语、中文、日语、韩语、阿拉伯语、印地语、土耳其语、波兰语和荷兰语。每种语言都有独立的路由，并带有正确的 hreflang 标签，因此搜索引擎会分别为其建立索引，读者也会进入与其浏览器语言匹配的页面。翻译由 AI 完成，因此会消耗项目余额。
“支持团队每周都在回答同样的五个问题”#
情况。答案已经存在于文档中。读者仍然会提交工单，因为他们没有找到对应页面。
阻碍因素。只匹配字面关键词的搜索无法适应人们实际提问的方式。读者使用了与标题不同的措辞提问时，什么也找不到，只能转而向人工寻求帮助。
Docsbook 的作用。Docsbook 的 AI 助手会根据已编入索引的页面回答问题，并引用提供答案的页面，因此原本会提交工单的读者可以直接在当前页面获得答案。对于它无法回答的问题，系统也会记录下来：未回答的问题和无结果的搜索都会列出，帮助你了解下一步应该编写哪个页面。助手回答由 AI 生成，会消耗项目余额。
“我们有一个 README，但没人有时间搭建文档网站”#
现状。该项目的文档是一份很长的 README.md，外加一个没人渲染的 docs/ 文件夹。配置静态网站生成器需要一周时间，而你根本抽不出这段时间。
阻碍因素。生成器需要配置、主题、构建流程和托管方案，才能渲染出第一个页面——之后还必须有人维护这四项内容。
Docsbook 的作用。Docsbook 按仓库的现状读取内容。文件夹结构会变成导航树，标题会变成大纲，相对的 .md 链接会解析为真实 URL，网站会在 docsbook.io/{owner}/{repo} 上线，并提供全文搜索和公开 URL。无需编写配置文件。你的 Markdown 从不会离开 GitHub 仓库，因此日后让其他工具使用同一个仓库不需要付出任何成本。