用了 3 年 Obsidian，我第一次真想换了：这个 1.9 万 Star 的开源笔记工具太懂程序员

我最初选择 Obsidian，最大的原因其实很简单：

数据存在本地。

对于一个开发者来说，这一点太重要了。

我的笔记应该是我的。

它们不应该被困在某个 SaaS 服务里，也不应该因为哪天产品关站，我就突然失去访问自己知识库的能力。

Obsidian 在这一点上做得很好。

Markdown 文件直接躺在本地目录里，你甚至不需要 Obsidian，也可以用任何编辑器打开。

但它一直有一个让我非常没有安全感的问题：

版本管理。

准确地说，是它没有把 Version Control 做成一等公民。

这意味着我每次修改一篇重要笔记的时候，脑子里都会有一点隐隐的不安：

万一改错了怎么办？

更烦的是，如果你还开着 Cloud Sync：

错误修改
  ↓
自动同步
  ↓
所有设备同步成错误版本

恭喜。

错误也被高效地同步了。

作为一个天天和 Git 打交道的开发者，这种体验真的很奇怪。

代码我敢随便改，是因为我知道：

git diff
git log
git restore
git revert

都在那里。

笔记反而不敢随便改。

这就有点本末倒置了。

于是，我还是用了 Obsidian 整整 3 年。

Backlinks、Plugin Ecosystem、活跃社区……

它几乎定义了过去几年大家对：

“现代笔记软件应该长什么样”

的想象。

但用了 3 年之后，我越来越觉得哪里不对。

而且那些一开始觉得“小问题”的东西，慢慢全冒出来了。

Obsidian 最大的问题，可能恰恰是“太能折腾”

我装过几十个插件。

但后来仔细想想：

真正长期高频使用的，不到 5 个。

其他插件基本都经历了这样一个生命周期：

发现神器
  ↓
安装
  ↓
配置半小时
  ↓
觉得知识管理系统马上起飞
  ↓
用了两天
  ↓
忘了

更麻烦的是，你不仅要决定：

这个插件好不好用。

你还要考虑：

它明年还活着吗？

毕竟 Obsidian 本身就已经算比较垂直的软件。

大量 Community Plugins 都是个人开发者维护的。

某天作者忙了。

换工作了。

没兴趣了。

插件就可能停在那里。

而你的 Workflow，可能已经绑在上面了。

这才是插件生态真正隐藏的成本：

你安装的不是功能，而是一堆未来需要持续维护的依赖。

这和 package.json 其实没本质区别。

区别只是 npm 至少还会提醒你 dependency deprecated。

你的笔记系统坏了，往往只能靠自己慢慢排查。

三年里，我换了三套同步方案

Sync 也是一样。

三年时间里，我一共换过 3 套同步方案。

每一种都有自己的坑。

有的冲突处理让人头大。

有的跨平台体验不稳定。

有的要额外付费。

有的则需要自己维护基础设施。

Git Backup 我也试过。

但因为不是整个产品的原生工作流，最后经常变成：

今天记得 commit
明天忘了
后天也忘了
一个月之后突然想起来

Git Backup 这种事情，如果依赖人类自律，基本就已经输了一半。

AI Integration 更麻烦。

到了 2026 年，我当然希望 Claude Code、Codex 或 Gemini 能直接理解我的 Knowledge Base。

但在 Obsidian 里，这往往意味着：

自己配 MCP。

自己找插件。

自己研究权限。

自己解决路径和协议问题。

对开发者来说不是做不到。

但问题是：

我为什么需要为了让 AI 读几篇 Markdown，先当半天基础设施工程师？

然后，我发现了 Tolaria。

1.9 万 Star、开源、TypeScript、Tauri

Tolaria 在 GitHub 上已经有大约 19,000 Stars。

完全开源。

主要使用 TypeScript 开发。

桌面端基于 Tauri。

它的作者 Luca，也是 Refactoring.fm 的创始人。

他自己每天重度使用 Tolaria，里面管理着：

10,000+ 篇笔记。

我实际试了一周。

目前我还没有彻底迁移。

但是说实话：

已经开始动摇了。

为什么？

因为 Tolaria 给我的第一感觉不是：

又一个 Obsidian Clone。

而是：

终于有人把“程序员真正希望笔记软件原生拥有的东西”直接做进去了。

一句话解释两者区别

如果一定要用一句话总结：

Obsidian 是“自己搭积木”。

而 Tolaria 更像：

“精装房，拎包入住。”

Obsidian 的哲学是：

Core
+
Plugins
+
Sync
+
Git Plugin
+
AI Plugin
+
你自己的配置
=
你的工作流

Tolaria 更像：

Git
AI
Markdown
Versioning
Knowledge Management
=
Core

而且，它终于不是 Electron 了。

最近几年我越来越明显地感觉到一个趋势：

软件行业好像突然开始集体嫌弃 Electron，然后什么都想用 Rust 重写一遍。

Tolaria 也加入了这个阵营。

杀手级优势 1：Git-first，版本管理零配置

这是 Tolaria 最核心的设计理念。

每一个 Vault，天然就是一个 Git Repository。

不是：

支持 Git。

而是：

Git 就是工作方式的一部分。

不用装插件。

不用配置 .gitignore。

不用手动 Commit。

也不用天天担心：

我是不是又忘记备份了？

Tolaria 全帮你处理。

对比一下 Obsidian。

如果你希望 Obsidian 使用 Git 备份，一般需要：

1. 1. 安装 obsidian-git；
2. 2. 配置 Auto Commit Interval；
3. 3. 处理冲突；
4. 4. 注意 .obsidian 配置目录；
5. 5. 确保不同设备上的状态不会互相打架。

我自己就曾经因为插件冲突把笔记搞坏过。

最后花了一整个晚上，从 Git History 里面把内容一点一点救回来。

那次经历之后我更加确定：

Version Control 不应该是笔记软件的插件。

它应该是底层能力。

Tolaria 怎么做？

流程基本是：

打开 Vault
  ↓
自动初始化 Git
  ↓
每次保存自动 Commit
  ↓
自动 Push 到你指定的 Remote

整个过程：

Zero Config。

你甚至不用关心 Git 在背后做了什么。

但当你真正需要历史版本的时候，它又在那里。

更重要的是，Tolaria 不会把你绑定在自己的 Cloud 上。

你可以使用任意 Git Remote：

GitHub
Gitea
自建 Git Server
其他兼容 Remote

这点我非常喜欢。

因为所谓“Local-first”，如果最后同步还是必须绑定厂商自己的云：

那也只能算半个 Local-first。

真正的数据主权应该是：

本地文件属于我，远端存到哪也由我决定。

杀手级优势 2：MCP Server 内置，AI 真正开箱即用

都 2026 年了。

如果一款笔记软件完全不考虑 AI Integration，我觉得已经有点像：

手机不能联网。

Tolaria 直接内置了一个 MCP Server。

也就是 Model Context Protocol Server。

最重要的是：

不用你自己搭。

Tolaria 已经准备好了。

目前可以接入的 AI 工具包括：

• • Claude Code；
• • OpenAI Codex CLI；
• • Gemini CLI。

你只需要在 AI 工具里把 Tolaria 的 MCP Server 配进去。

然后 Agent 就可以直接：

读取笔记
搜索知识库
总结内容
生成笔记
修改笔记
建立连接

这和传统所谓：

我们给笔记软件加了一个 AI Chat Sidebar。

完全不是一回事。

Sidebar AI 仍然是：

AI 被塞进笔记软件里。

MCP 的思路则是：

你的知识库成为整个 Agent 工具链可以访问的能力。

这是架构层面的不同。

更妙的是，它直接提供 AGENTS.md

Tolaria 还提供了：

AGENTS.md

这点非常戳程序员。

它允许 AI Agent 自动理解你的 Vault：

目录怎么组织
笔记格式是什么
有哪些约定
内容应该放在哪里
有哪些规则

你不用每次对 Claude Code 说：

我的笔记都放在这里。

项目笔记用这种格式。

Meeting Notes 放到那个目录。

Frontmatter 要这么写。

Agent 只需要先读：

AGENTS.md

基本就知道怎么干活了。

这套思路其实非常漂亮。

因为你完全可以把一个 Knowledge Vault 看成：

不是代码的 Repository。

代码项目里有：

README.md
AGENTS.md
Git
Source Files

知识项目里则有：

AGENTS.md
Git
Markdown
YAML
Assets

仔细想想，两者根本没有本质区别。

它们都是：

需要长期维护、版本化、协作，并且需要让 Agent 理解规则的信息系统。

杀手级优势 3：Tauri，终于不用再带一个浏览器跑笔记了

Obsidian 基于 Electron。

这是它最大的技术包袱之一。

Electron 本质上是什么？

说得简单点：

给每个桌面 App 随身带一个浏览器。

它的优势当然很多：

跨平台开发成本低。

Web 技术栈成熟。

生态强。

但代价也很现实：

内存占用高
启动慢
应用体积大
低配置设备压力明显

一个笔记软件动不动吃几百 MB 内存，总有种：

我只是想写两行 Markdown，你为什么像要编译 Chromium？

的感觉。

Tolaria 使用的是 Tauri：

Rust Backend
+
System WebView Frontend

同样一套功能下，它不需要自己完整打包 Chromium。

实际体验上，内存占用大约只有 Electron 应用的：

1/3 到 1/2。

启动速度则可以快：

2～3 倍。

我自己在 M1 MacBook Air 上测下来，差距非常明显。

而且这个指标对于笔记软件特别重要。

因为笔记工具不是 Photoshop。

不是你早上打开一次，晚上关闭一次。

你可能一天打开：

几十次。

每次慢 0.5 秒，好像没什么。

但几十次累积下来，就是几十秒。

更关键的是体感：

工具打开得越快，你越愿意随手记。

而笔记软件真正最大的性能指标，从来不只是 CPU 或 RAM。

而是：

一个念头出现后，到你开始写，中间有多少摩擦。

杀手级优势 4：完全开源，真正做到 Zero Lock-in

Obsidian 的数据格式是开放的。

但它的核心应用本身并不开源。

这导致一个很微妙的问题。

你的 Markdown 是自由的。

但你的 Workflow 不一定自由。

比如：

Dataview
某个 Calendar Plugin
某个 Task Plugin
某个特殊查询语法
某套 Theme
某种 Automation

一旦你的工作方式高度依赖这些生态组件，那么表面上：

我的数据是 Markdown

实际上：

我的工作流已经绑定 Obsidian

Tolaria 则是完全开源的。

MIT License。

代码就在 GitHub。

任何人都可以：

审查
修改
贡献
Fork

即使有一天 Tolaria 停止更新：

你仍然可以 Fork。

继续维护。

甚至直接不用 Tolaria。

因为底层仍然只是：

Markdown
+
YAML
+
Git

没有私有格式。

什么叫真正的 Zero Lock-in？

Tolaria 的思路基本可以拆成四层：

没有 Cloud Lock-in：

Git Remote 随便换。

没有 Format Lock-in：

纯 Markdown + YAML。

没有 Account Lock-in：

不注册。

不登录。

没有 Plugin Lock-in：

核心能力都尽量直接做进产品。

这让我重新想了一下 Obsidian 一直强调的：

Data Ownership。

Obsidian 已经做得很好。

但 Tolaria 更进一步：

数据自由只是第一层，工作流自由才是更彻底的数据主权。

杀手级优势 5：Types 是 Lens，而不是 Schema

这个设计很特别，我觉得值得单独讲。

Obsidian 里很多人会使用 Dataview 做结构化知识管理。

比如给笔记加各种字段：

type: meeting
date: 2026-08-16
project: alpha
status: active
owner: luca

然后通过 Schema 和 Query 来筛选。

这套玩法能力很强。

但它也很容易走向另一个极端：

为了管理笔记，开始给笔记填表。

字段名必须统一。

格式必须统一。

某个 Property 漏了：

Query 可能就不对了。

最后写一篇笔记之前，先花两分钟考虑：

它属于什么 type？
应该有哪些字段？
字段值应该是什么？
这个 Schema 合规吗？

知识管理慢慢变成：

个人 ERP。

Tolaria 的设计理念不一样。

它把 Types 当成：

Lens。

也就是：

观察知识的一种视角，而不是强制知识服从的一套数据库 Schema。

比如你可以写：

type: meeting

或者：

type: project

但不会因此要求：

meeting 必须有 attendees
meeting 必须有 date
meeting 必须有 location
project 必须有 deadline

没有 Required Fields。

没有 Validation Rules。

Type 主要用于：

过滤
分类
导航

而不是：

约束你怎么写。

我很喜欢这种哲学。

因为笔记库最容易犯的错误之一就是：

还没积累多少知识，先设计了一个堪比 Salesforce 的 Schema。

最后不是系统帮助你写东西。

而是你每天伺候系统。

Tolaria 的思路则更接近：

你先写。

结构以后再帮你看。

这个顺序，我觉得更符合真实的人类思维。

那 Obsidian 已经输了吗？

当然没有。

Obsidian 本身已经是一款非常优秀的软件。

而且今天市场上“类 Obsidian”工具多得离谱。

真正想替代它，没有想象中那么简单。

Obsidian 至少还有几个非常明显的护城河。

第一：Plugin Ecosystem 还是太强

Obsidian 有超过 1000 个 Community Plugins。

这是它最大的 Moat。

Calendar。

Kanban。

Database。

Mind Map。

PDF Annotation。

Excalidraw。

各种自动化。

基本可以说：

只要你能想到一个需求，大概率有人已经写过插件。

Tolaria 现在还没有成熟的 Plugin System。

所以如果你的 Obsidian Workflow 已经高度依赖：

Dataview
Kanban
Excalidraw

这些插件，迁移成本会明显提高。

这也是我目前还没有完全切过去的重要原因。

我反而很好奇一件事：

Tolaria 未来会怎么设计自己的插件系统？

如果它完全从零重造生态，成本会非常高。

如果能复用某种成熟生态，那可能会很有意思。

否则：

核心功能再漂亮，一旦碰到个性化需求，还是会觉得不方便。

第二：社区规模，Obsidian 仍然碾压

Obsidian 的 Community 已经非常大。

Discord 有大量用户。

中文社区也相当活跃。

基本遇到任何问题：

搜索一下

通常就已经有人踩过坑了。

这其实是一款工具成熟度非常重要的部分。

软件本身只是产品的一半。

另外一半叫：

“我遇到问题之后，能不能快速找到答案。”

Tolaria 的 Community 目前还在成长。

尤其中文资料明显更少。

不过生态这件事也很现实：

如果产品真的足够好，用户和内容都会慢慢长出来。

只是现在，它还需要时间。

第三：Mobile 还是 Obsidian 明显领先

Obsidian 已经有成熟的：

iOS
Android

客户端。

Tolaria 目前还是以：

macOS
Windows
Linux

桌面端为主。

Mobile 还在开发。

这对很多人来说可能直接就是：

一票否决。

因为如果你习惯：

电脑写
手机看
路上记
iPad 整理

那桌面端再好也不够。

不过对我个人影响不大。

因为我几乎不用手机记笔记。

怎么开始使用？

macOS 安装很简单。

一行：

brew install --cask tolaria

Windows 和 Linux 则可以直接下载对应 Installer。

从 Obsidian 迁移麻烦吗？

反而很简单。

因为两者本质上都围绕：

Markdown
+
YAML Frontmatter

工作。

所以迁移流程大概是：

1. 1. 直接用 Tolaria 打开原来的 Obsidian Vault；
2. 2. Tolaria 自动识别其中的 Markdown；
3. 3. 不再需要的话，可以删除 .obsidian 配置目录；
4. 4. 开始使用。

这也是开放格式最舒服的地方：

迁移不是“导出数据”，而只是“换一个程序打开同一批文件”。

这才叫真正的 Portable Data。

不过有一个地方需要特别注意。

如果你大量使用 Obsidian 特有的：

[[wikilink]]

语法，那么这些内容在 Tolaria 里会保留下来。

但可能只会被当作普通文本，而不会自动解析成链接。

所以 Wikilink 重度用户最好提前评估一下。

例如你的 Vault 里到处都是：

[[Project Alpha]]
[[Meeting 2026-08-16]]
[[Architecture]]

那这件事绝对不能忽略。

真正的迁移成本，从来不是：

Markdown 能不能打开。

而是：

你的知识关系还能不能正常工作。

Claude Code 怎么接 Tolaria？

Tolaria 已经自带 MCP Server。

所以你只需要把它配置到 Claude Code 的 MCP 配置中。

原始示例里有一个容易踩坑的小问题：

"command "

后面多了一个空格。

正确写法应该是：

{
  "mcpServers": {
    "tolaria": {
      "command": "path-to-tolaria-mcp-server",
      "args": []
    }
  }
}

如果实际 MCP Server 需要通过某个可执行文件和子命令启动，也更建议明确写成类似：

{
  "mcpServers": {
    "tolaria": {
      "command": "/absolute/path/to/tolaria-mcp-server",
      "args": []
    }
  }
}

对于开发工具配置，我一般不太建议依赖模糊的相对路径。

能写绝对路径，就减少一类环境问题。

配置好之后，Claude Code 就可以直接访问你的 Vault。

比如：

搜索我过去关于 RAG 的所有笔记

或者：

总结最近三个月关于 Agent Memory 的观点

甚至：

把今天的讨论整理成一篇新笔记，
并和已有的 MCP、RAG、Knowledge Graph 相关笔记建立关联

这时候笔记软件终于不只是：

人类自己打开搜索框查资料。

而变成：

Agent 可以调用的个人 Knowledge Infrastructure。

这可能才是我真正想要的“开发者笔记工具”

用了三年 Obsidian，我并不觉得它不好。

恰恰相反。

很多设计直到今天仍然非常优秀。

但我的需求变了。

以前我最在意的是：

Local Markdown
Backlinks
Plugins
Graph View

现在我越来越在意的是：

Git-native
AI-native
Local-first
Open Source
No Lock-in
Fast
Agent-readable

尤其是 AI Coding Agent 成为日常工具以后，我越来越不想把：

代码仓库

和：

知识仓库

当成两个完全不同的东西。

一个成熟的 Knowledge Vault，本质上也应该拥有：

版本历史
提交记录
明确约定
机器可读规则
Agent Interface
开放格式
可迁移存储

换句话说：

我的笔记库，也应该像一个优秀的软件项目一样被管理。

这可能才是 Tolaria 最打动我的地方。

它不是单纯给 Obsidian 换了一个 Tauri 壳。

它换的是一个底层假设：

笔记不是一堆需要同步的文档。

笔记库本身就是一个长期演化、需要版本控制、可以被 Agent 理解的知识 Repository。

最后的结论

我现在还没有彻底从 Obsidian 迁移到 Tolaria。

原因也很现实：

Obsidian 的插件生态更成熟。

社区更大。

Mobile 更完整。

一些重度 Workflow 的迁移成本也不能假装不存在。

但是用了一周以后，我第一次产生了非常强烈的感觉：

这可能不是又一个 Obsidian 替代品。

它更像是在回答一个新的问题：

2026 年，一个给开发者使用的 Local-first 笔记工具，到底应该原生具备什么？

我的答案正在越来越接近：

Markdown
+
Git
+
Tauri
+
MCP
+
AGENTS.md

而不是：

Markdown
+
50 个插件
+
3 套同步方案
+
手动 Git Backup
+
自己折腾 AI Integration

Obsidian 最大的优势，是你可以把它组装成几乎任何东西。

Tolaria 最大的诱惑，则是：

很多我真正想要的东西，它一开始就已经在那里了。

对于普通用户来说，这未必足以成为迁移理由。

但对于开发者来说：

一个自动 Commit、能接任意 Git Remote、内置 MCP、Agent 能直接理解、底层还是纯 Markdown 的笔记工具——确实很难让人完全不动心。

Obsidian 当然还没有输。

但可以确定的是：

Local-first 笔记工具的下一场竞争，已经不只是 Backlink 和 Plugin 数量了。

真正的新战场，是：

谁能把你的知识库变成一个既属于你，又能被 AI 持续理解和使用的 Repository。