Repo、Vault、Docs 与企微的分工¶
核心口径¶
这个 repo 本身就是 OrgReOrg 的实验场和 benchmark。
所有 Demo、配置、测试、benchmark、知识库和发布文档都先在这个 repo 里建立、演化和验证。这样团队可以用同一套材料测试：
- Agentic Search 能否找到正确证据。
- Context Router 能否选对上下文库。
- 知识卡片能否从讨论沉淀到 vault。
- 成熟内容能否发布到 docs。
- 每次改动能否被 Git、测试和 CI 追踪。
四层分工¶
| 层 | 角色 | 里面放什么 | 不适合放什么 |
|---|---|---|---|
| Repo | 实验和版本底座 | 代码、Demo、测试、配置、vault、docs、benchmark | 临时口头结论但不落地 |
| Vault | 知识生产区 | inbox、raw、wiki、projects、decisions、outputs、system | 未审查就对外发布的内容 |
| Docs | 发布阅读层 | 稳定、结构化、团队可读、客户安全的页面 | 原始聊天、粗糙草稿、敏感材料 |
| 企微 | 未来交互入口 | 提问、通知、主动询问、确认、轻量阅读链接 | 长文档编辑和版本管理 |
docs 和 vault 有什么区别¶
vault/ 是知识生产系统，docs/ 是发布系统。
vault 是知识如何形成¶
vault/ 记录的是知识从原始输入到稳定判断的过程：
text
00-inbox 临时想法、群聊摘要、待处理材料
10-raw 原始资料，尽量保持接近原文
20-wiki Agent 编译后的知识页
30-projects 项目、场景、开发计划
40-decisions ADR、关键判断、取舍记录
50-outputs 分析报告、可发布草案、实验输出
90-system 规则、模板、registry、benchmark、维护日志
它可以包含半成品、内部讨论、待确认知识卡片、benchmark 配置和实验报告。Agent 应优先把讨论材料沉淀到 vault，再从中抽取成熟内容发布。
docs 是知识如何被阅读¶
docs/ 是 MkDocs/Cloudflare 发布网站的来源：
text
docs/
面向团队或外部读者的稳定页面
mkdocs.yml
网站导航和发布配置
它应该更清晰、更稳定、更少内部过程细节。读者不需要理解所有 inbox/raw 的演化过程，只需要看到当前可执行的结论、方案和开发计划。
为什么现在还需要 docs¶
当前 Cloudflare Pages 绑定 docs/，所以 docs 是最方便的团队阅读面。
以后企微接入后，企微会成为主要出入口：
- 用户在企微提问或发起任务。
- Agent 在企微里主动询问、通知和请求确认。
- 简短答案直接回到企微。
- 复杂内容可以跳转到 Web/docs 页面。
- 成熟内容仍然需要一个可引用、可链接、可审查的发布层。
所以 docs 未来不一定是唯一入口，但它仍然可以作为“稳定知识的网页渲染层”。企微更像入口和交互层，不替代 Git 版本管理，也不替代 vault 的知识生产过程。
作为搜索 benchmark 的意义¶
这个 repo 天然适合当第一批搜索 benchmark，因为它同时包含：
- 原始讨论和调研记录。
- Agent 编译后的 wiki。
- 项目计划和决策记录。
- 已发布网站页面。
- Demo 脚本、配置和测试。
好的搜索系统应该能区分：
- 用户要看正式结论时，优先引用
docs/或稳定 wiki。 - 用户要追溯来源时，能回到
vault/10-raw/。 - 用户要看开发进度时，能查
vault/30-projects/、脚本和测试。 - 用户问“为什么这样决策”时，能查
vault/40-decisions/。 - 用户问“系统怎么配置”时，能查
vault/90-system/。
这也是 Context Router Demo 先拿本 repo 做实验的原因。