01
runbook 已在 Wiki 更新，Agent 仍引用旧 ingestion 快照。
Doco 使用场景
人与 AI Agent 共同维护的团队 Wiki
当人需要完成度高的协作编辑器，而 Agent 需要针对同一文档做有 scope 的搜索、引用和保护维护时，用 Doco 构建 AI 团队 Wiki。目标是一份事实源，而不是 Wiki 加一份陈旧 RAG 副本。
真实失败模式
两套知识系统终会漂移
团队在一个应用写，Agent 从另一个索引或文件副本回答。第一次漏同步就产生两个互相冲突的真相。
02
用户只能看部分页面，但集成 Token 可能拥有更宽或不同的访问范围。
03
自动维护任务替换了队友的并发编辑，却仍报告成功。
操作循环
运行一份共享 Wiki
- 01
按真实团队所有权组织知识库、嵌套文件夹、文档、成员与权限。
- 02
让 Agent 浏览结构、带证据搜索，并只读取当前文档相关块。
- 03
强制版本保护块写入或批次写入；接受的变更通过人类正打开的同一 Yjs 文档广播。
- 04
审查评论、changes、versions、关系、摘要与概念，但不把派生材料当成权威。
乐观并发能阻止陈旧写入静默覆盖，但不会自动解决所有语义分歧；高风险政策变化仍需人审。
能力地图
系统必须提供什么
| 维度 | 真实需求 | Doco 如何处理 |
|---|---|---|
| 权威事实源 | 全团队可见的共享事实源 | 知识库、文件夹、文档、成员关系和文档分享 |
| 检索 | 跨文件夹和长文档快速发现 | 树/目录遍历和带上下文的结构化搜索 |
| 证据 | 答案指向精确当前文本 | 稳定块引用、版本、完整性与新鲜度 |
| 写入 | 日常维护的受控自动化 | 有 scope Token、读写工具、原子批次和幂等 |
| 并发 | 实时同编且无隐藏 last-write-wins | Yjs 处理实时文本，If-Match 保护快照 API 写入 |
| 可迁移性 | 可信的退出与自托管路径 | Markdown/ZIP/原生导出和 MIT 部署栈 |
适合
工程 runbook、产品规格、客服知识、入职文档、政策、架构决策、发布说明和持续维护的内部文档。
不适合
完整项目管理、CRM、数据仓库、工单系统，或要求成熟 SSO/审计而 Doco 尚未实现的企业治理平台。
01Doco 能替代所有团队的 Confluence 或 Notion 吗？
不能。成熟套件拥有更广的数据库、管理、集成和企业控制；Doco 更窄，聚焦人机文档。
02人正在输入时 Agent 能编辑吗？
能。Agent 写入同一 Yjs 文档，同时 API 版本门会拒绝陈旧快照，而不是覆盖新内容。
03搜索使用 RAG embedding 吗？
Doco 当前使用带块上下文、版本和完整性的结构化全文搜索，不宣称尚未实现的语义检索。