这些情况选择 Doco
- Agent 必须修改内部维护文档，而不只是检索公开文档。
- 必须自托管并采用 MIT 许可。
- 实时人机协作和块级并发是核心。
诚实对比 · Doco 与 GitBook
Doco vs GitBook
需要精致的公开产品文档、Git Sync、内置 AI 发现能力，以及每个发布站点自动生成的只读 MCP 时选择 GitBook；需要人与外部 Agent 通过保护写入 API 共同维护内部文档时选择 Doco。
直接答案按工作选择，
按工作选择，
别按功能数量
这些产品有重叠，但重心不同。先确定事实源是什么，以及哪些人和 Agent 必须共同维护它。
这些情况选择 GitBook
- 主要交付物是完整的公开产品文档站。
- Docs-as-code Git Sync 和自动 LLM/MCP 发布最重要。
- 托管发布平台和内置 AI Assistant 符合流程。
一眼对比
实际运行差异
| 维度 | Doco | GitBook |
|---|---|---|
| 核心工作 | 由人与 Agent 维护的内部/共享文档 | 公开产品指南、API 参考与文档站 |
| 数据所有权 | MIT 源码与自托管部署 | GitBook 托管平台与 Git 仓库同步 |
| 人类协作 | 工作区内实时 Yjs 编辑 | 块编辑器与文档发布流程 |
| Agent 接入 | 带版本检查的读写 MCP、CLI 与 REST | 每个发布站点自动生成只读 MCP |
| 内容模型 | 富文本块与 Markdown 导入导出 | Git 同步 Markdown 与 GitBook 块 |
| 最适场景 | Agent 必须更新的运行知识和 runbook | 公开产品文档和开发者门户 |
GitBook 更强的地方
GitBook 的发布能力更强：品牌文档站、Git Sync、API 参考、AI Assistant、自动 Markdown 页面、llms 文件，以及每个发布空间自带只读 MCP。
Doco 更强的地方
Doco 更适合作为文档背后的可编辑事实源。外部 Agent 可以搜索、引用、修改稳定块、发现冲突，并让变更出现在人类正打开的同一编辑器。
迁移
从 GitBook 迁移
若 Git Sync 已保存标准 Markdown，迁移成本低到中等。GitBook 专用块、站点定制、重定向、认证发布和 Assistant 配置仍属于文档导入之外的发布问题。
- 01
拉取 Git Sync 仓库，或导出一个真实空间及其 Markdown/资源。
- 02
将 Markdown 树导入 Doco 知识库，并保留仓库作为回滚源。
- 03
审查 GitBook 专用块、redirect、页面元数据和生成的 API 参考内容。
- 04
决定是否保留 GitBook 作为发布层，让 Doco 成为内部人机协作事实源。
先用真实数据做小范围演练。在链接、附件、权限、表格和恢复流程都验收前，保留原始导出。
Bottom line
选择更小的事实源
GitBook 是更好的发布平台；Agent 需要保护写入时 Doco 是更好的共享创作系统。部分团队可以组合使用：Doco 维护知识，GitBook 公开交付。
01每个 GitBook 站点都有 MCP 吗？
每个已发布 GitBook 站点都会在 /~gitbook/mcp 暴露只读 HTTP MCP，并遵守站点可见性设置。
02Doco 能像 GitBook 一样发布完整文档站吗？
Doco 可发布公开文章页和 Markdown，但 GitBook 在完整产品文档站、导航、品牌和 Git Sync 上成熟得多。
03两个产品能一起用吗？
原则上可以。团队可在 Doco 维护源知识，导出 Markdown，再通过仓库/GitBook 发布；但同步桥必须明确设计和验收。