Post

我们团队如何使用 Obsidian 管理知识库

Posted Updated
By Jakob He
20 min read
我们团队如何使用 Obsidian 管理知识库

为什么要用 Obsidian + Git + LLM

我们花了半个月，把团队里的小伙伴们都迁移到了 Obsidian 里。我们很笃定，当前比较好的解决方案就是 Obsidian + LLM + Git 管理团队知识库。我列举一些主要的原因：

  1. Obsidian 是一个很优秀的 C 端产品，有非常好的用户界面，对于非工程人员很友好
  2. 良好的插件生态：有许多优秀的现成的插件
  3. 可以高度定制化的插件系统：能够实现我们的定制化想法，通过简单的插件系统 vibe coding，就能很快实现，而且最近 Obsidian 改了自己的插件上线流程，绝大多数的功能都做到了自动化，发布一个插件只需要两小时，大大节约团队对于某个插件的改造流程。
  4. Obsidian CLI：CLI 工具用一个很轻量的文本检索方案，能够迅速的在你本地搜索到相关上下文
  5. 复用所有 Git 的能力：为什么同步方案要用 Git 呢？因为 Git 是最好的文本协作方案。比如：
    1. 支持对比
    2. 历史追踪
    3. 分支管理
    4. PR 及其 review comment 的能力
    5. token 权限

但是这个思路，我们也能在近未来看到一些很明确的一些缺点：

  1. 能够支撑的数据量很有限，因为并没有使用某些生产级别的数据库，随着上下文大小越来越大，肯定会面临很严峻的知识库治理的成本，但是我的判断是，就一个人十年左右的文本量，肯定是能够支撑的，而且 Obsidian 也会持续迭代，能力天花板也会上移
  2. 知识库上手门槛：上手一个软件并非易事，何况在我们的解决方案里，需要对知识库进行 LLM 的加工，这是一件跟过去我们所有管理知识库都方法都不一样的事情，这件事的门槛，其实比我们想象的要高
  3. Git 上手门槛：Git 的方案对工程人员可靠且容易上手，但是团队很多角色并没有任何使用 Git 的经验
  4. 无论如何简单易上手的知识库，当范围扩展到团队时，总会有一些协作约定需要遵守

两个Interface Level的插件

就着这个思路，我们想扬长避短，公司的几个小伙伴们，开发了两个能够让你的知识库丰富，让团队协作门槛降低的插件：

  1. Knowlery
  2. Agentic Git Sync

两个插件核心目的，都是为了让团队的所有成员，都能通过简单的设置，迅速享受到模型 + 知识库带来的便利。

Knowlery

Knowlery主要包含两大部分的内容：

  1. 帮忙配置本地 LLM Runtime Agent
    1. 它会帮忙你安装所有需要的环境，即便你是一个完全不懂技术的人，它也会引导你安装好 Claude Code
    2. 能够用各种模型的 key 使用 Claude Code，许多非技术人员，甚至是技术人员，都被这一步劝退了，因为单单是申请到 Claude Code 账号这件事，就要求我们具备各种非官方技能，比如 fanqiang + 外网付款 + 外网地址 等等等等。
  2. 知识库初始化和预装所有需要的 skills
  3. KV 知识库管理的可视化，通过简单的按钮点击，就能生成知识库的关系图和 index。

Agentic Git Sync

Agentic Git Sync 的核心目的是利用模型的能力，替我们管理所有有关 Git 方面的事情，让用户感受不到 Git 的存在。 比如当我 push 的时候遇到了冲突，或者我的操作导致某个文件没有 fast-forward 时，模型就会介入，解决这些问题。当然它能做的远比解决冲突要多，实际上是 Git 的 blocker，它都能解决。所以我命名这个插件为 Agentic Git Sync。

BTW: 发布的第二天，就被湾湾油管主挖掘出来，推荐到他的频道里了。

团队如何分工？

有人说，现在是一人公司的时代，我在半信半疑之中开启了这个思考，实际上，目前 Agent 的能力看来，一人公司实际上是把这一个人每天过的数据量和事件变得极其密集，虽然真正做的事情并不多，但是密集的信息量真的会让一个人很疲惫。唯一的一人公司的模式是，将稳定的业务自动化，并且长期维持稳定的运行，比如我有一个每天发小红书推广的 Agent，它能稳定运行 100 天，不用我管，前五天我会被这个 Agent 烦透，因为有一堆配置，一堆微调的工作要经过我的大脑。 但是实际情况是，当某个 Agent 稳定运行一周之后，要么市场变了，要么 token 过期了，总是有这样或者那样的事情变成你身上的猴子，你不得不寻找一个同事来配合你甩掉这个猴子。要么，你就得自己亲力亲为。 所以我不是一人公司的信徒，我更愿意相信，现在的每个人的角色，或者这个角色的定义，职责，边际，在团队里，都会逐渐的发生变化，达到某种平衡，最后，某些角色在 AI 时代就稳定的存在下来。 所以回到这个大点上的话题来说，团队该如何分工？

统一团队的工具和工作流

Above all，有一个前提，那就是我要求我们团队都要围绕知识库来工作的，那么我的第一个要求就是全团队统一工具和工作流，那么无论你是什么角色，

  1. 产品安装 Obsidian
  2. 安装两个插件，Knowlery 和 Agentic Git Sync 插件，配置它们 API Key 和路径 对于个人的本地知识库而言，我们把自由度留给个人，但是团队方面共同维护的文档，需要有一定的规则来约束，比如我是某个知识库的 owner，我就有直接提交 default 分支的权限，以下，当我说 own 某个知识库时，就是意味着这个团队要直接从 default 分支进行知识的更新。但如果我不是这个知识库的 owner，我就应该永远被禁止直接提交任何信息进 default 分支。 这些都是很粗略的一些约定，当我们进入具体的 Jira task 开发时，我们应该定义更为细节的 workflow，此时此刻，我们先不就此展开讨论。

产品团队

变成业务知识库的主要维护者，负责维护业务知识库，更新，整理，归档各种文档。这是团队后续所有工作的根本。那么具体上，他们需要做什么呢？

  1. 设置一些工作所需要的 MCP，比如 BigQuery、Confluence（迁移过程中，依赖旧有的数据，或者建 Jira task）和 Figma MCP
  2. 开始利用现有 Confluence 页面来维护业务知识库，逐渐完善
  3. review 他人出于各种原因而对知识库的更改 产品作为业务最上游，可以直接以 main 分支 checkout 这份知识库的 repo，并且时刻保持同步。

测试团队

测试团队作为知识的消费者，需要 checkout 业务知识库，并且以个人的分支来 checkout，对于业务知识库，测试团队有必要：

  1. 检查业务合理性
  2. 依据业务知识生成 test case，并且为此负责
  3. 若遇到逻辑漏洞，或者业务漏洞，需要与产品团队同步，要么自己修改，提交 PR，再由产品团队 review PR 是否合理，最终由产品 merge PR
  4. 将来：定义测试验收 Agent 的执行步骤，过程和验收依据。这个测试验收 Agent 很重要的一部分知识来源就是 test case
  5. 当然，定义验收 Agent 的维度非常多，有的 Agent 需要赋予丰富的知识，有的 Agent 反而不应该给太多的上下文，而是应该像一只猴子一样去测试

开发团队

开发团队需要参考的信息最多，有一份当前产品大而全的知识，有每个 Jira task 所提交的 change request 描述，有代码，有开发规范，各种 coding 过程可能产生的 skills，有时候也要参考 test case，甚至很多时候还要参考数据和线上运行情况，比如日志和性能指标。 但是就知识库而言，开发团队是一个主要消费者，即便有改动到原始知识库的场景，也是很少的，而且是必须与产品团队确认的一个过程。所以开发团队围绕这个最根本的知识库所需要做的事情，与测试团队类似，比如：

  1. own 开发规范
  2. own Gitflow skills 等各种开发过程中需要维护的流程
  3. 对接各式各样的 MCP，Datadog、BigQuery，各种开发工具的 MCP

同一知识库，多人的维护

这就是利用 Git 做这类知识维护的好处，如何解决冲突，如何快速共享，只要延续 Git 的这一套工作流程即可。 但是非工程团队，假设我们的测试团队和产品团队都是一个多人团队，这种情况下，我们要如何很好的利用 Git 呢？ 这句要求我们要有一个好用的 interface（比如 Agentic Git Sync） + 一些划分任务的工程 practice，就能做到。

项目

项目也有需要维护的知识库，那他 own 好这个项目知识库，不做赘述。

个体的角色的职责正在发生变化

整体感觉上，大方向上，每个环节的每个个体，都在不久的将来，可预见的要开始做与自己目前所做的事情不一样的事。那具体是什么改变呢？我想到了以下较为确定的点：

定义 Agent，是必然要发生在每个人身上的。

开发必须要有能力来定义 Agent，如何开始工作，如何寻找所依赖的仓库，比如代码，比如知识，如何验收的 Agent，如何自测的 Agent。 测试工程师也是一样，要开始具备定义 Agent 的能力，他们要有能力从各种维度开始验收一个产品。比如从生成的数据进行验收，从页面交互的现象上来进行验收，比如从无数 AI 生成的 test case 和经过 test case 运行之后的报告里来寻找 bug 的蛛丝马迹。

AI native 的产品一定要用 AI 来测试

为什么这么说呢？因为 AI 本身给软件带来了很不确定的因素。一个代码的执行结果本身，也从一个确定的数字，变成了一个带有情绪的文字了。对于这类产品，我们无法穷举所有的可能性，只能在一定次数的运行之后，分析某些概率，来定义其验收的标准。 所以肉眼可见的，测试还会存在，必须存在，但是测试的工作大不同于从前！

产品在人前的工作与当下的一样重要

产品有两部分的工作，一是用户面前的沟通和理解，这类工作需要非常软的技能，比如开会，preach，用户洞悉，这类技能只能借助一些工具做到更好，但是完全无法被 AI 替代，至少目前 2026 年 5 月的时候，我给出的结论是，这类工作会持续甚至变得更为重要。

产品在人后的工作，主要围绕知识库

产品在与客户沟通完之后，剩下的对内，对开发团队的工作，主要就是围绕知识库的维护工作，知识库作为从用户到工程的前后主要接口，其质量将直接影响工程团队的工作质量。

下一块拼图：云端知识库 Agent

维护知识库从来就是一个 pain in ass 的难题，这该交给谁呢？我的答案还是 Agent。 照着我们这篇文章 个人/企业知识库管理框架 的设想，我们利用 Obsidian 插件搞定 interface 层，拉平大家的上手门槛，利用 Obsidian CLI 搞定本地知识库索引问题，那么下一块拼图就是，知识的抽象和提炼。当我把有用的知识抽象提炼出来之后，团队成员能够很迅速的拣选自己所需要的知识开始在工作中应用。 比如我是一个项目，我就只需要在某些任务里，挑选出项目相关的知识，并且开始工作。 知识库随着团队的发展，必定会变得越来越庞大，变得难以管理，但是并不影响某个任务的准确执行，因为只有少数任务需要具备完全且大量的知识。换句话说，要完成绝大多数的任务，都只需要具备某几个领域知识就能完成的。我们很有信心用一些简单的方式，解决 70% 左右的工作场景问题。

tech workflow
This post is licensed under CC BY 4.0 by the author.