别再为笔记软件里的 AI 付第二次钱:一次从 Notion 到 Tolaria 的AI native重建

Tolaria 是一款 AI native 的笔记工具。它不是在传统笔记软件上接了个 AI 插件，而是从底层数据结构、双链语义、视图定义到 Agent 协议，全部按”人和 AI 同时使用”这件事重新设计了一遍。

我现在的选型是：flomo 负责”无感输入”，Tolaria 负责”结构化沉淀和 Agent 协作”。Notion 已经放弃，Obsidian 暂时不再使用。下面解释为什么。

先把 Tolaria 是什么讲清楚

理解 Tolaria 的关键，是先理解它的核心立场：它是一个 AI native 的笔记工具。

这听起来像营销词，但背后是一组很具体的设计选择。绝大多数我们今天熟悉的笔记软件——Notion、印象笔记、Logseq、思源、wolai——本质上都是把数据装在私有数据库或 JSON 结构里的笔记应用。它们后来或多或少都接了 AI，但 AI 是”插件”，不是”基座”。一旦你想让 AI 真的进来一起工作，会发现两件事：数据格式 AI 看不懂，结构语义 AI 拿不到。

Tolaria 的判断是反过来的：先把数据结构做成 AI 能直接读写的样子，再在这之上长出文档结构、双链、视图、编辑体验。具体长这样。

文档结构：每条笔记都是带类型的对象。 每条笔记都是一份带 YAML frontmatter 的 Markdown 文件，有一个 type 字段（Daily / Topic / Project / Entity / Source / Domain ……），类型本身也是一条笔记，可以自己定义图标、颜色、默认排序、列表里展示哪些字段。关键差别在数据格式：你的”数据模型”是一组人类可读、AI 可读、Git 可跟踪的 Markdown 文件，不是某个应用的私有数据库。这意味着任何一个 AI Agent 不需要 API，直接读文件就能理解你的整个知识结构。

双链:带语义,不是一根没标签的线。 Obsidian 的 [[]] 是一根没有语义的线——A 链到 B,但 A 和 B 是什么关系没人知道。Tolaria 把关系做成了 frontmatter 字段:related_to、belongs_to、或者你自定义的 mentor_of、derived_from,值是 wikilink 列表。带语义之后两件事立刻可用:反向查询有意义——belongs_to: 工作状态 的所有 Topic 自动归属到工作领域索引页;AI 能基于关系做编译——例如把所有 belongs_to: 健康状态 的 Daily 段拼起来,生成本周健康状态变化。

视图：是 YAML 文件，不是按钮配置。 Tolaria 的”视图”是 views/*.yml，长这样：

name:活跃项目
sort:"property:onboarding:asc"
filters:
all:
-field:type
op:equals
value:Project
-field:status
op:equals
value:Active

Notion 的视图是配置在数据库里、点出来的；Tolaria 的视图是文件，可以被 AI 写、被 Git 跟踪、被人读懂。意义不是更”极客”，而是 AI 可以基于你的真实使用情况，主动新建一个视图，而不是只能在已有视图里筛。

Agent 是一等公民。 Tolaria 默认就预留了 Agent 通道：仓库里放一份 AGENTS.md，描述这个 vault 的约定、命名规则、关系字段、什么该做什么不该做。人和 AI 看的是同一份说明。我现在的工作流大致是：每日 ingest，让 Agent 把 flomo 同步过来的随手记，按内容分到 Daily / Source / Entity；每周/每月 review，让 Agent 把零散 Daily 编译进 6 个 Domain 的 state.md，更新长期判断；不定期 refactor，让 Agent 检查碎片化的 Topic、错位的类型、过期的索引，做一次治理。这三件事在 Notion 里基本做不动（API 受限、数据云端锁死），在 Obsidian 里要靠插件 + MCP 拼凑，在 Tolaria 里是默认形态。

重要的是：Tolaria 本身不重。 上面这套设计的核心是规范，不是软件本身。你完全可以把这套规范搬到任何一个支持 Markdown + YAML 的编辑器里——VS Code、Obsidian、Typora 都能用。Tolaria 真正提供的价值是：基于这套规范做了一个开箱即用、编辑体验优秀、AI 集成顺畅的客户端。它不需要做得很重，把心思花在”让这套规范跑得舒服”上，而不是”在编辑器里堆功能”。

更进一步说，编辑器本身在 AI 时代也没必要做那么重。传统笔记软件要靠堆插件市场来覆盖长尾需求——闪卡、看板、白板、思维导图、各种学习模板——每一个都要插件作者去开发、维护、和主程序版本对齐。但在 Codex / Claude Code 这类工具进来之后，这套逻辑变了：你想要一个闪卡功能，不需要等谁开发插件，直接让 Agent 基于你 vault 里的 Markdown + frontmatter，vibe 出一个脚本就能跑。同理还有：基于 tag 自动生成周报、把某类 Entity 导出成 Anki 牌组、根据关系字段画关系图、给特定类型笔记加一组验证规则——这些过去需要”插件生态”的事情，现在是一段几十行的脚本 + 一份 prompt 就能解决。

所以 Tolaria 不需要做插件市场，也不需要把功能堆到编辑器里。它只要保证数据是开放的、结构是 AI 能读懂的、文件系统是 Agent 能直接操作的，长尾需求就交给 Agent 去 vibe。这是它和绝大多数笔记软件的另一个根本差别——大部分软件是先做编辑器，再补结构，再硬塞 AI；Tolaria 是先有结构，再长出编辑器和 AI 集成，长尾功能由用户和 Agent 现场生成。

AI 能力来自你已经付费的 Agent，不是笔记软件本身

这是我体验下来感受最深、也最容易被忽略的一条差别。

过去一年所谓的”AI 笔记”——Notion AI、印象笔记的 AI、Notegen、各种 AI native 笔记新秀——本质上都是把 AI 能力打包成笔记软件的内置付费功能向你二次收费。你订阅笔记软件 → 笔记软件订阅 OpenAI / Anthropic → 笔记软件加价卖给你。每多一个 AI 笔记工具，就多一份 AI 订阅。

但今天真正在做正经事的人，账上已经有一份 Claude Code、一份 Codex、一份 ChatGPT Plus、可能还有本地模型。这些订阅的 token 配额我已经付过钱，能力已经在我手上。我不需要再为一个笔记工具里”长得不太聪明的小模型”另外付一次 AI 钱。

Tolaria 的逻辑是反过来的：它不卖 AI 能力，它把 vault 暴露成 Agent 可读写的文件系统，让你已经付费的 Agent 直接进来工作。想做内容分析？打开 Claude Code，让它读 vault。想批量重构？打开 Codex，让它按规范改文件。想长期跑 ingest / review / refactor？挂一个本地脚本调你自己的模型。

笔记软件回到笔记软件该干的事——做编辑体验、做结构、做视图；AI 能力回到 Agent 该干的事——理解、推理、执行。两件事解耦，价格和能力都不被笔记厂商绑架。

这件事的副作用是：笔记工具天然变轻了。不需要内置一个永远赶不上前沿的 AI 助手，不需要为了 AI feature 不停加版本号。你换一个更强的 Agent，整套笔记系统的 AI 能力立刻升级——因为 Agent 在外面，不在笔记里。

为什么我放弃了 Notion

我在 Notion 上待了好几年。今天必须诚实承认：我已经把它放弃了，连查阅档案的位置都没留。

这不是说 Notion 不好。Notion 教会我用 database 思维做笔记——把一条记录当成有字段的对象，而不是一篇页面。这件事真正改变了我用笔记工具的方式，今天我在 Tolaria 里用 type + frontmatter + view 的整套范式，本质上是这个思路的延续。

但放弃它有两个根因，一个比一个重。

第一，国内访问稳定性始终是悬在头上的一刀。 任何长期承载个人知识的工具，不能依赖 VPN。今天能开，不代表下个月还能开。这一条单独就足以让我不再把任何重要内容写进去。

第二，数据被锁死，无法本地 AI 化。 这条才是真正的死刑判决。AI Agent 进来之后，笔记系统的瓶颈从”我能不能记进去”变成了”AI 能不能进来一起加工”。Notion 的 API 是只读为主，写回受限，结构性操作几乎做不了——你想让 AI 帮你重组数据库、合并属性、生成新视图，会直接撞墙。更要命的是数据在云端，本地 AI 工具链（Claude Code、本地模型、MCP）根本进不去。

当一个工具既不能稳定访问，又不能让 AI 进来一起工作时，它就不再是 AI 时代笔记系统的合理选项了——不管它的 database 思维多么经典。Notion 教会我的东西没有白学，但它本身已经走完了对我这一段路的使命。

为什么我没有停在 Obsidian

我中间在 Obsidian 上停了一年左右。Obsidian 解决了 Notion 的两个问题——本地 Markdown、可迁移、不会因为公司倒闭就消失。但它有自己的两个根本问题。

开箱即用的编辑体验太差。 这件事我必须先讲，因为它是最直接的劝退原因：Obsidian 的基础编辑器，在 2026 年还做不到好用。实时预览模式下行为奇怪、表格编辑反人类、嵌入式视图依赖一堆插件、移动端体验拼凑感强、字体和排版要自己折腾主题——一个长期承载思考的工具，光是把”打字、写表格、加链接”这件事做顺，就要耗掉用户大量时间。它的设计哲学是”给你一个地基，你自己拼一栋房子”。这件事在 2018 年的双链笔记浪潮里是优势，在 2026 年的 AI 时代是负担。用户的时间应该花在思考和写作上，不是花在拼工具上。

它不是为 AI 设计的。 更深一层的问题：Obsidian 是为”人”设计的双链笔记，不是为 AI 设计的知识库。关系没有类型——所有 [[]] 都是同一种线，AI 看到一个链接不知道这是”引用”、”归属”、”反对”还是”派生”；结构靠插件拼凑——Dataview 是只读视图，不能写回；让 AI 改结构基本只能直接写文件，绕开 Obsidian 自己的索引；类型是”约定”不是”机制”——你写 type: Project 没问题，但工具不会因此给你一个 Project 的列表页、字段约束、默认视图，你得自己在 Dataview 里写查询。

我在 Obsidian 上跑了大半年，发现一件事：我花在”配置插件、写 Dataview 查询、维护模板、调主题”上的时间，比花在写笔记上的时间还多。这是工具不对的信号。

Tolaria 的设计选择和 Obsidian 是反向的：Obsidian 给你最大的可扩展性，让你自己拼一套结构；Tolaria 给你一套约束更窄但自洽的结构，让你和 AI 都能直接用，开箱即用。

一句话：Obsidian 给人开了一扇门；Tolaria 给人和 AI 各开了一扇门，而且两扇门都能直接走进去。

为什么是 flomo + Tolaria，不是 Tolaria 一个搞定

我现在的工作流是 flomo 负责输入端，Tolaria 负责沉淀端。这个分工不是凑出来的，是反复试错之后的根因结论。

输入端的核心问题：摩擦要无限接近 0。 任何一条记录，从”我想到”到”它进入系统”，中间每一秒摩擦都会让一部分记录消失。flomo 在这件事上做到了极致：打开就写、写完就走、不用想标签、不用想字段、不用想分类。Tolaria 在这件事上不可能比 flomo 更好——它是文件系统，文件系统天然就比”打开 App 直接写”多几步。这是设计取舍，不是缺陷。

沉淀端的核心问题：结构要可被 AI 操作。 但 flomo 也有一个根本短板：它不是为长期知识沉淀设计的。一条 flomo 写出去之后，它就静静躺在那里，没有类型、没有关系、没有视图、没有领域归属。三个月后想找，只能靠搜索。Tolaria 接的就是这一段：flomo 是流，Tolaria 是池。每天/每周让 Agent 把 flomo 的流编译进 Tolaria 的池，按 Daily / Source / Entity / Topic 分流，加关系，挂到 Domain。

把”输入”和”沉淀”分到两个工具，本质上是承认了一件事：

一个笔记工具不可能同时把”输入摩擦最小”和”结构化最强”两件事都做到极致——它们是矛盾的。

Notion 选了”结构化最强”，输入摩擦就大。flomo 选了”输入摩擦最小”，结构就弱。Obsidian 试图两者兼顾，最后两边都不极致。flomo + Tolaria 的组合是把这个矛盾外化到了工具边界上：flomo 这一端坚决不要结构，只保证速度；Tolaria 这一端坚决要结构，但允许 AI 来补结构，而不是要求人补。AI 在中间扮演的角色是”把无结构的流，编译成有结构的池”。这件事人来做太累，AI 来做正好。

这两天我在 Tolaria 上做了什么

为了让上面这套不只是空想，讲两件具体的事。我这两天做的核心其实只有两件：先在 AI 辅助下定义一套框架，再让 AI 按这套框架把旧数据导入整理一遍。

基于 LLM Wiki 思路，定义一套框架。 参考 Karpathy 写的 LLM Wiki 思路，我在 AI 辅助下，把”个人知识系统应该长什么样”想清楚了：5 个一等类型（Daily / Topic / Project / Entity / Source）+ 1 个领域层（Domain）+ 一组带语义的关系字段（belongs_to / related_to 等）。这套规范不是软件强加给我的，是我和 AI 反复对齐之后写进 AGENTS.md 的——它是一份人和 AI 共享的说明书。这件事在 Notion 里做不到，你没法定义”我希望 AI 怎么理解我的数据库”；在 Obsidian 里能做，但要写一堆约定散落在脑子和模板里，AI 拿不到。

把旧数据导入，让 AI 按最新标准整理一遍。 框架定好之后，我把原先 Notion 里的数据库和笔记直接导出成 Markdown，丢给 Tolaria。然后让 AI Agent 按这套最新框架自动整理一遍：该是 Daily 的归 Daily，该是 Topic 的归 Topic；长期主题没有结束态的从 Project 降为 Topic；单份外部材料从 Topic 迁到 Source；具体的书、影视、设备从 Source 迁到 Entity；给每个 Topic 自动补 belongs_to，挂到对应的 Domain；6 个 Domain 索引页自动生成。

最终拿到的是一份带关联的、结构一致的知识库——不是一堆散乱的 Markdown，是一张可点开、可被 AI 持续编译的知识图。整件事是 AI 在 Tolaria 内执行的，不是我手动一条一条改的。前提是有那份框架，并且框架本身是 AI 能直接读懂的。没有这两件事，这种”导入即整理”做不到。

紧接着我又让 AI 做了一次内容层面的分析——基于全部笔记的内容，分析我真实的精力分布、思考模式和盲点。它指出几条我自己之前没意识到的事：笔记系统这个主题碎片化成了 7 个并列 Topic、结论早就收敛了但没人去合成一篇规范、一些长期主题缺一篇收敛页。这种分析的前提是 AI 能读到所有笔记的结构、关系、时间序列——只在”笔记是结构化对象”的前提下才成立。

写在最后

写到这里得诚实说几件事，避免变成种草文。

Tolaria 还很新，生态、插件、社区都是早期，需要”今天就能用、明天就有插件解决任何问题”的工具，它不是。多 Agent 并发还不顺，目前一次只能让一个 Agent 在 vault 里干活。本地全文/语义检索也在早期，这不是 Tolaria 一家的问题，是整个本地 AI 工具链的问题。节奏问题工具解决不了——压力大时记得多，松弛时反而消失，换什么工具都不会改变这一点。

如果你在考虑换工具：已经在用 database 思维但被云端锁住，可以试 Tolaria；还在 Obsidian 但开始问”AI 能不能进来”，可以试 Tolaria；完全不打算让 AI 进来，Obsidian 仍然是更成熟的选择。工具不是越新越好。真正复利的不是”我用了什么工具”，而是”我有没有一个可以被持续编译的中间层”——Tolaria 是我目前找到的最接近的那个，但它不是唯一的答案。

过去六年我换了五套笔记系统，每一次都以为是工具的问题。直到 2026 年才想明白：每次想解决的，其实是不同层的问题——容器、结构、中间层。Tolaria 是这条路上目前最像答案的那个工具，但更重要的是它背后那个判断：笔记不再只是被记录的，它要能被持续编译。