工作空间使用手册¶
这一部分回答一个具体问题：
团队成员 clone 这个 repo 后，如何使用 repo、Obsidian、GitHub、Agent、MkDocs/Cloudflare 和后续企业微信入口一起协作？
它是方法层，不是方案层。方案层在“产品逻辑 / 核心模型 / 平台能力”，实验和 benchmark 在“研发验证”，质量控制在“工程治理”。
当前协作闭环¶
讨论 / 资料 / 实验
-> workspaces/variai/evidence/inbox 或 workspaces/variai/evidence/raw
-> Agent ingest / compile
-> workspaces/variai/knowledge/wiki / workspaces/variai/knowledge/projects / workspaces/variai/knowledge/decisions
-> PR review
-> workspaces/variai/site
-> MkDocs / Cloudflare
-> 团队继续讨论和验证
这个 repo 同时承担三件事：
- 团队当前项目的真实工作空间。
- 未来产品形态的最小 Demo。
- Framework / Workspace 解耦和研用测一体的验证场。
新成员怎么读¶
第一步：跑通本地工作空间
先读 快速上手。目标是确认本地能打开 repo、理解目录、运行基础检查，并知道哪些文件可以改、哪些生成页不能手改。
第二步：理解空间边界
读 Repo、Evidence、Knowledge、Site 与企微的分工。重点是：
workspaces/variai/evidence/是原始证据层。workspaces/variai/knowledge/是知识生产和决策层。workspaces/variai/registry/是机器可读的本体、路由、权限和状态层。workspaces/variai/site/是发布阅读层。framework/是未来可打包的通用能力。workspaces/variai/connectors/wecom/是企业微信入口开发边界。
第三步：按标准 Git 流程协作
读 GitHub 与 Cloudflare。开发默认走个人分支、PR、本地解决冲突、合并到 main，再把 main 推到 ALPC91 Cloudflare 镜像。
第四步：让 Agent 按同一套规则工作
读 Agent 原生团队工作台 和 讨论-记录-开发-测试循环。Codex / Claude Code 打开项目时，应先读 AGENTS.md / CLAUDE.md，并按 repo 的知识沉淀流程工作。
第五步：理解长期 ChatOps 入口
当前还没有真实企微 bot，因此短期仍由人工把关键讨论沉淀进 repo。长期入口见 ChatOps 自动沉淀，Obsidian 使用方式见 Obsidian Vault 使用方式。
工具分工¶
| 工具 | 当前定位 | 不承担什么 |
|---|---|---|
| GitHub | 版本管理、PR、review、CI、协作分支 | 不是普通阅读入口 |
| Obsidian | 浏览和维护 workspaces/variai/knowledge/ 的知识生产区 |
不是发布网站 |
| MkDocs / Cloudflare | 团队阅读和对外分享的发布层 | 不是原始讨论入口 |
| Codex / Claude Code | 代码、文档、实验、整理、验证和发布助手 | 不绕过 repo 规则直接改生成页 |
| 企业微信 | 未来主要输入输出入口和主动询问通道 | 目前还不是已接入能力 |
当前原则¶
- 不把项目讨论只当聊天上下文；有价值资料、观点、质疑和实验结论都要进入知识沉淀闭环。
- 不把流程摩擦当一次性麻烦；高频问题要转化成产品迭代输入、demo case 或 CI gate。
- 不围绕短期外部链接死循环；要记录标题、来源线索、关键词和 source status。
- 不把 Site 当唯一事实源；生成页和实验页要追溯到
registry/、outputs/、Evidence 或 framework 模块。 - 不一开始就追求完整权限系统；当前 P0 先验证上下文管理、Agentic Search、主动询问和知识外挂闭环。
先把协作闭环跑顺，再把高频动作产品化。