在 2025 年 2 月的时候，Obsidian 官方正式宣布 Obsidian 用作商业用途免费。作为一个重度 Obsidian 用户，我当时写了一篇文章探讨了应该如何用 Obsidian 搭建团队知识库：Obsidian 商用免费，我是如何用它搭建团队知识库的？。
最近由于一些变动和调整，我们实验室使用腾讯文档管理共享文档的弊端逐渐显现出来。我借此机会尝试了一下推动实验室从腾讯文档转向 Obsidian 知识库。这篇文章是我在这个过程中获得的一些经验和思考。
缘起
我们的研究组是一个由 20+人组成的团队，拥有一些共用的基础设施，比如实验室 WiFi、打印机、冰箱、计算集群等等。在之前，我们的共享文档记录的基本上都是这些设施的使用方法和注意事项。这些文档的数量不多，能很好地利用腾讯文档方便用 QQ/微信查看、分享、编辑的优点。因此一直以来我们并没有考虑过迁移文档的问题。
后来，随着我们的工作越来越专业化，我们对硬件的要求（尤其是 GPU）也越来越高。然而，为所有人的工位电脑都配备 Nvidia 显卡成本太高，而且也很浪费。于是我们购置了几台配备了显卡的 Linux 计算服务器给大家共用。从此我们的大多数工作就从自己工位上的 Windows PC 转移到了 Linux 服务器上。
然而各个同学的工作毕竟不同，对 Python 版本、相关库等环境的需求都不一样。为了避免多个用户在同一台机器上配环境造成的环境冲突问题，我们收回了管理员权限，要求所有同学必须建立自己的 Docker 容器，在容器中配环境以及编程。这样做的好处是各个同学的编程环境就被容器隔离了开来，不会互相干扰；坏处则是学习成本节节高升，大家需要付出不少的时间来学习如何进行 Linux 远程开发以及在容器内编程。作为运维组成员之一，发微信来问我相关问题的同学越来越多，我开始忙不过来。
为了让大家的学习曲线更加平缓，我和其他几个运维组的同学编写了几篇教程并且组织了几次培训来教大家如何进行远程开发；后来，我们将一些常见问题的解决方案也写成文档供查阅。随着时间的推移，这些知识文档的数量越来越多。腾讯文档的问题就显现了出来：
- 腾讯文档没有「知识库」的概念，除非自己特意保存，否则腾讯文档是不支持搜索文档的；
- 腾讯文档的全文搜索功能需要付费；
- 没有标签功能，过期的信息散落在各个文档中，难以及时找到并且更新；
- 体验上来说，腾讯文档真的很卡很不流畅……编辑排版体验大打折扣。
面对这种情况，市面上成熟的解决方案是使用飞书、语雀这样的团队知识库产品。对于我们这种团队来说，这类产品的要价有些高（飞书估计在 3 万元/年以上）。而且知识库产生的价值几乎量化不了，我也很难找到好理由说服老师花钱购买。
在这一背景下，我的主意就打到了宣传「商用免费」的 Obsidian 上面。
推进
我在 Obsidian 商用免费，我是如何用它搭建团队知识库的？一文中提出了一套很复杂的 Obsidian 团队知识库方案，包含三个部分：
- 共享文档
- 团队项目看板
- 团队知识库
其中还包含一套定期合并分支的流程，可以保证大家设备中分布的知识库版本能够同步。这个模型看起来很完美，可是一推进起来就有很多问题。其中首要的问题就是 Obsidian 在「方便查看」这一指标上远不如腾讯文档。
这意味着什么呢？这意味着：
- 忘记了实验室大门密码的同学无法快速在手机上打开那个文档，找到开门密码（移动端 Obsidian 同步起来很麻烦，参见适合普通用户的简明Obsidian Git同步教程 - 少数派）
- 新文档无法再像之前那样直接通过发链接到群里
- ……
如果说这一点还能忍受，那么更大的问题是：即使是对于我们这样全员都具有计算机背景的团队来说，Obsidian+Git 的学习成本也太高了。以我自己的知识库来说，其日常运行就需要超过 10 个插件。此外，这套流程还要求定期聚会解决文件冲突，和组会一样，这显然是一件不受欢迎的事情。
如果说「腾讯文档不方便搜索、编辑卡顿……」属于熟悉的困难；那么「学习一套新的知识库方案」属于陌生的困难。依据人脑一贯的特点，我们总是会倾向于低估前者，同时高估后者。何况解决文件冲突还需要额外占用所有人的时间。
所以结果显而易见：大家对这套方案并不感冒，方案仍需改革。
改变
前面提到的 Obsidian 团队知识库方案太复杂了，光是介绍这个方案就需要一篇数千字的文章。关注知识管理的读者群体基本上都保持了严肃阅读的传统以及一颗谋求进步的心，因此才能够有耐心去了解并且应用这样一个复杂的方案。然而现实情况是，大多数人其实并没有那么多耐心，也不那么在乎效率。人们对待工作的普遍的心态其实是「我不关心长期问题，也不认可你说的那些虚头巴脑的价值，我只想快点解决手头的工作然后下班」。
所以我决定顺应这种心态：
- 不想学习新东西：和 Obsidian 解绑，不引入新工具，但是使用 Obsidian 仍然是最佳实践
- 太复杂：简化流程，不再考虑追踪项目；除了腾讯文档不方便管的教程，其他内容仍然留给腾讯文档
- 不想花时间：不再统一要求所有人参与，取消合并冲突所需要开的会，最好只需要提交即可
具体需要做的事情很简单：在团队的 Github Orgnization 上建了一个存 markdown 文件的仓库，将腾讯文档中的知识内容移动到这里。这样的话懒人就可以不需要做任何事，也可以在 Github 在线查看并且搜索所有的文档。
此外，这个仓库是用 Obsidian 制作的。像我这样愿意折腾的人仍然可以用 Obsidian 在 Github 和本地同步仓库，获得更好的搜索、编辑、个性化体验。
对于不愿意使用 Obsidian 的同学，也可以把仓库下载到本地，用 VSCode、Typora 等软件打开编辑。这样的话这部分同学也不需要付出更多学习成本，可以进一步扩大潜在用户基数。
对于想要参加到编写中的同学，其只需要熟悉提交 Github Pull Request 或者 Merge Request 即可很方便地加入到贡献者行列中。虽然这对于没有计算机背景的人来说仍然有不低的学习成本，但我们作为一个人工智能实验室，这是所有人早就掌握的技能，不需要额外的学习成本，体现了因地制宜的特点。
最后，稍微学习一下微软的特色：不再花时间维护腾讯文档中的那些教程，这不仅方便我自己，也为促进大家的转向增添一点推力。
最后
我关注效率话题已经有几年了，我读过的知识管理相关文章已经不少。我发现在这个话题下，人们往往总是处于两个极端之中：
- 完全不关心知识管理，信奉「大力出奇迹」，对「低效」缺乏感知
- 完全沉迷于形而上的讨论，永远在「做笔记学习怎么做笔记」，以至于输出的结论大多数是空谈
我认为，正确的做法应该介于二者之间：永远以解决现实问题为最终目的，并在此前提下探寻解决问题的最佳方式。
我决心践行这一理念。因此我真的去尝试了一下推行我提出的用 Obsidian 打造团队知识库的理论，看看是不是经得起推敲，结果我果然遇到了许多问题。最后总结下来就写成了这篇文章。
Obsidian 团队知识库的探索仍在继续，这不会是这个系列的最后一篇文章。如果你对这个话题感兴趣，或是认同我的想法，想知道后来会怎么样的话，欢迎关注我，持续获得最新的资讯。
