Obsidian 团队知识库方案¶

调研结论¶

Obsidian 很适合作为小型 AI 原生团队的知识库工作台，尤其适合采用 Karpathy 的 LLM Wiki 方法：把知识库当成一组 Markdown 文件，由 Agent 负责持续整理、交叉链接、更新索引、维护日志和检查矛盾。

它不一定替代 GitHub 和 MkDocs，而是承担不同角色：

Obsidian
  - 团队知识库 IDE
  - 原始材料收集
  - 知识编译和双链浏览
  - 图谱、Canvas、Dataview、Web Clipper

GitHub
  - 正式版本管理
  - PR / Review / 历史追踪
  - Agent 原生协作

MkDocs + Cloudflare Pages
  - 正式教程网站
  - 对团队或外部展示

Karpathy LLM Wiki 的核心¶

Karpathy 的 LLM Wiki 不是传统 RAG。核心差异是：

传统 RAG：每次问问题时临时检索 raw documents。
LLM Wiki：Agent 预先把原始材料编译成持续演化的 Markdown Wiki。

它通常有三层：

raw/
  原始资料，尽量不可变

wiki/
  Agent 生成和维护的知识页、概念页、索引和综述

schema/
  AGENTS.md / CLAUDE.md / 维护规则 / 页面模板 / 编译流程

关键文件：

index.md
  内容目录，帮助人和 Agent 快速找到相关页面

log.md
  编译日志，记录 ingest、query、lint、修改原因

核心原则：

人负责输入资料、提出问题和审查方向。
Agent 负责整理、摘要、归档、建链接和维护一致性。
Obsidian 是 IDE。
Markdown 文件是知识资产本体。
Git 是版本和协作底座。

官方能力现状¶

Obsidian 官方 Sync 支持团队共享 vault，官方页面说明可以邀请团队进入共享 vault，并让笔记在团队设备之间同步。Sync 也提供端到端加密、版本历史、跨平台同步和离线工作能力。

官方定价页显示：

Obsidian 核心应用免费。
Sync 按用户收费，年付约 4 美元/用户/月，月付约 5 美元/用户/月。
Publish 按站点收费，年付约 8 美元/站点/月，月付约 10 美元/站点/月。
商业使用不强制购买 Commercial License，但官方鼓励组织购买以支持开发。

对我们团队是否合适¶

适合。

原因：

团队只有五六个人，沟通成本低，适合先用轻量工具。
成员都是 AI 原生工程师，能理解 Markdown、Git、Agent、目录结构。
Obsidian 的本地文件模型和 GitHub/MkDocs 天然兼容。
Agent 可以直接读写 vault 中的 Markdown 文件。
后续可以把团队知识库方法本身产品化，变成客户交付方法论的一部分。

与当前 MkDocs 仓库的关系¶

当前 repo 不只是发布管道，也是团队 Demo、测试、benchmark 和知识库实验场。

workspaces/variai/evidence/ 是原始证据层， workspaces/variai/knowledge/ 是知识生产层， workspaces/variai/site/ 是从 reviewed Knowledge 中抽取成熟内容后的发布阅读层：

微信群讨论 / 网页 / 会议 / Agent 输出
        ↓
Evidence inbox/raw
        ↓
Agent 编译为 Knowledge wiki/project/decision
        ↓
人工 review
        ↓
同步到 Site / GitHub / MkDocs
        ↓
Cloudflare Pages 发布

未来企业微信接入后，企微会承担主要的提问、通知、主动询问和确认；Site 仍然作为稳定知识的网页渲染层，但不再是唯一入口。

两种协作路线¶

路线 A：Obsidian Sync 共享 vault¶

适合想要低摩擦同步、多设备、少配置。

优点：

官方同步。
跨设备体验好。
可共享 vault。
对非 Git 用户友好。

缺点：

每个协作者需要 Sync 订阅。
不等同于 Git review。
对复杂分支、PR、代码式协作支持弱。

路线 B：GitHub 作为 vault 同步方式¶

适合 AI 原生工程师小团队。

优点：

免费。
PR / Review / 历史版本强。
Agent 很容易操作。
与当前 MkDocs 仓库一致。

缺点：

不适合多人同时编辑同一文件。
手机端和非技术成员体验弱。
需要建立分支和提交纪律。

当前建议¶

对我们现在的团队，建议先用路线 B：

Obsidian 本地打开 `workspaces/variai/knowledge/`
GitHub 管版本和协作
Agent 通过 PR 修改知识库
MkDocs 发布正式教程
微信群做轻量讨论入口

如果后续需要更强的多设备和实时共享，再购买 Obsidian Sync 或评估 Relay 这类多人协作插件。

Agent 工作流¶

建议定义几个固定任务：

ingest¶

把 00-inbox/ 或 10-raw/ 中的新资料编译进知识库。

输出：

source summary。
concept pages。
backlinks。
index update。
log entry。

query¶

基于 20-wiki/ 回答问题，并引用来源页面。

输出可以是：

回答。
新页面。
对比表。
方案草案。
MkDocs 页面草稿。

lint¶

周期性检查知识库健康度：

孤立页面。
重复页面。
过期判断。
矛盾判断。
缺少来源。
缺少反向链接。
可以产品化的内容。

publish¶

把成熟内容同步到 MkDocs：

产品底层逻辑。
架构设计。
ADR。
路线图。
部门方案。
培训材料。

风险和边界¶

不要让 Agent 无审查地覆盖核心判断。
raw source 尽量不可变，wiki 才是可编译产物。
每次 ingest 都要写 log。
重要判断写 ADR。
外部事实要保留来源链接。
避免多人同时改同一文件。
不要把 API key、客户敏感信息、合同和账号密码放进 vault。

结论¶

Obsidian 可以成为团队知识库的核心工作台，但 GitHub 仍然应该保留为版本协作和正式发布底座。

最适合当前阶段的组合是：

微信群：即时讨论
Obsidian：知识生产和浏览
GitHub：版本化与多人 Agent 协作
MkDocs/Cloudflare：正式发布网站

这条路线也可以反过来成为我们未来交付客户的方法论：帮助小组织把散落在群聊、会议、文档和项目中的知识，编译成持续演化的组织知识库。