等了几年的 Obsidian 官方看板终于来了，为什么评价却两极分化？

就在几天前，10 月 5 日，Obsidian 官方 1.14 版本 [1] 正式发布了。

这次更新里，最引人注目的变化，莫过于 Bases 核心插件终于迎来了期待已久的原生看板视图。

在此之前，如果你想在 Obsidian 里用看板，基本都要依靠社区插件，比如很多人用过的 mgmeyers 的 Obsidian Kanban[2] 或者 CardBoard[3]。

官方在路线图里规划这套底层框架已经好几年了，社区也是年年催更。

现在，原生的看板总算是端上来了。

但有意思的是，发布还不到一周，各大论坛并没有迎来预想中的狂欢，反而开始冒出各种密集的吐槽：

「为什么卡片不能自由拖动上下排优先级？」

「照着以前的习惯用了几天，库里全是只有一句话的空文件，找东西全乱了。。。」

知名效率作者 Mike Schmitz 甚至直接发了一条措辞犀利的评测，认为它既没有列内自由垂直排序，也没有每列卡片上限，严格来说还算不上真正的看板。

很多人踩坑，是因为下意识把它当成了另一个 Trello 或者轻量 Todo 软件。

要用好它，第一件事是认清它的「本质」。

所以这篇文章，我想跟你聊聊 Obsidian 这个原生看板到底是怎么运作的，怎样用才不会把你的知识库搞乱。

以及从这次更新背后，我看到的一些关于工具的克制思考。

原生看板的本质

要想用顺一个工具，得先知道它背后到底在干什么。

我们先看老牌社区插件 obsidian-kanban 的逻辑。

它的本质是：单文件纯文本。

整张看板就是一个普通的 .md 文档。

你在看板里看到的每一张卡片，底层其实就是一行待办列表语法：- [ ] 买牛奶。

你在界面上把一张卡片从「待办」拖到「已完成」，插件在背后做的事情非常单纯：找到这行字，剪切掉，然后粘贴到「已完成」这个二级标题下面。

它的好处很明显：非常轻量，完全不污染你的仓库，关掉插件它依然是一张清爽的 Markdown 待办清单。

但局限也很明显：卡片只是一行文本，你没法在卡片里展开写长文，更没办法跟全库的双链和属性生态无缝打通。

再来看这次 1.14 的官方 Bases 原生看板。

它的底层逻辑彻底变了：多文件属性视图。

你看板文件本身是一个 .base 查询器。

它的每一张卡片，物理上都必须是本地硬盘里的一篇独立  .md  实体笔记。

你在看板里看到的分列，不是基于文档里的标题，而是基于 Frontmatter 里的某个 YAML 属性，比如 status。

当你把一张卡片从「待办」拖到「进行中」时，Obsidian 在底层做的事情其实是：直接打开那篇对应的 Markdown 笔记，找到 Frontmatter 里的 status，把它的值从「待办」自动改成了「进行中」。

聊到这里，区别就很清楚了。

如果你还按照以前用 Trello 或者老看板插件的习惯，在列底下疯狂点加号，去记「下楼买酱油」、「晚上取快递」……

结果就是你的 Obsidian 会在背后不断生成只有标题、正文完全空白的极短笔记。

几周下来，不仅文件列表变得杂乱，更会直接干扰你的全局搜索和快捷切换，让你在查找真正重要的深度内容时，被大量琐碎待办事项所阻碍。

所以，我的第一个核心结论是：

官方看板根本不是用来管琐碎杂事的；它是用来管理有生命周期、需要持续沉淀正文的「实体交付物」的。

例如一个正在推进的项目、一篇公众号的选题草稿、一份客户的深度档案、或者一次完整的主题研究。

快速上手原生看板

搞清楚了底层逻辑，具体怎么用呢？

其实非常简单，按照我自己的配置习惯，三步就能搭好。这里以我自己的项目管理目录为例。

第一步：创建 Base 并划定「边界」

在指定文件夹右键新建数据库（Base），或者呼出命令面板直接创建。

这一步很关键，是配置过滤器（Filters）。

建议在过滤器里显式加上规则：file.folder == "目标目录" 且 file.ext == "md"。

不要在没有过滤条件的情况下直接在库根目录全局跑看板，否则全库成百上千篇文档一瞬间全挤进看板里，场面会比较壮观 🤣

第二步：添加 Kanban 视图并绑定分组属性

点击顶部标签页的 + 号。

选择看板视图。

在 Group 菜单里，选择你希望作为分列依据的属性，比如 status。

系统会自动按这个属性的值生成列。你可以根据自己的工作流设置列的顺序，比如我的设置：

💡 想法 → 📥 待办 → ⏳ 进行中 → 🎯 已完成

第三步：定制卡片展示属性（优化信息密度）

如果每张卡片只显示一个标题，看板的信息密度就太低了。

在卡片显示配置里，你可以勾选你想在卡片上直接看到的字段。

比如在我的任务看板里，我额外勾选了 priority（优先级）、due（截止时间）和 category（分类）。

这样一眼扫过去，哪个任务最急、属于哪个业务板块、什么时候该交付，一清二楚。

原生看板的一些最佳实践

虽然官方看板搭建很简单，但结合这几天的实际体验和社区的反馈，我有三个使用原则想分享给你。

原则一：强制目录隔离

专门设立一个独立的收敛目录，比如 05 项目/Tasks/，所有需要进入看板的任务笔记只在这个目录里存放。

看板只扫描这个目录，不越界。

这样即使生成了任务笔记，也不会污染你的知识库核心区域。

原则二：通过属性设计，解决「无法上下排序」的遗憾

目前官方看板最大的槽点，就是列内卡片不能手动拖动上下调整顺序。

你没办法像在 Trello 里那样，把今天最重要的一张卡片手动拖到最顶上去置顶。

针对这个局限，目前有两个曲线救国方案：

方案 A：引入优先级属性。

在 YAML 属性里显式加入 priority: P1 / P2 / P3，然后在视图配置里指定列内按 priority 升序排列。

这样 P 1 的任务永远自动浮在最上面。

方案 B：按修改时间倒序排列。

在 Base 配置里把卡片排序设为按 updated（修改时间）倒序。

你在哪篇任务笔记里写了新进展，它就会自动浮到该列的最顶端。

原则三：输入端与检视端解耦（看板是仪表盘，绝非录入端）

不建议在看板界面狂点 + 增加卡片（每点一次就在后台生出一个只有标题的空文件）。

我的做法是：

1. 琐碎小事留在 Daily Notes 里随手 - [ ] 打钩；

2. 真正有沉淀价值的重要项目，在日常思考、写日记提到时，通过新建笔记并打上 YAML 属性（status: 进行中）；

3. 看板只在周复盘、推进项目等具体主体时打开，作为全局检视的面板。

在 Agent 狂飙的时代，Obsidian 的克制

聊完实操，我想回到文章开头提到的那场社区争论。

效率博主 Mike Schmitz 吐槽它功能残缺、算不上真正看板，而官方核心作者 kepano 在 Reddit 亲自出来回了一句话：

「我们未来确实希望能加上这些功能。但一如既往，请大家保持耐心，我们团队只有四名全职开发者 🙏」

这就让我不得不产生一些思考：在 Coding Agent 编码快如闪电的今天，想要实现一个什么功能，那不是言出法随、信手拈来吗？

但拥有数百万活跃用户的 Obsidian，为什么在功能推进上依然保持着这种近乎不能理解的节奏？

这背后其实是他们一直在坚守的底线：File-over-app（文件大于应用）。

你想想看 Notion。

Notion 拥有功能极其强大、丝滑的数据库和看板，各种花哨的联动与视图应有尽有。

但全能的代价是什么呢？

代价是黑盒存储、云端强绑定，以及离开它的软件环境后数据导出可能面临的格式错乱。

一旦断网，或者平台遇到意外，你的数据并不完全属于你。

而 Obsidian 选择了一条完全不同的路。

如果要在看板里实现完全自由的无序拖拽与垂直排序，软件就必须在底层引入一套私有的、中心化的位置配置文件，或者引入侵入式的私有数据库结构。

一旦这样做，Markdown 的纯粹性就被打破了。

Obsidian 宁可让功能在现阶段显得笨拙一点，宁可用最朴素的 YAML 属性来驱动分列，也绝不破坏纯文本的独立性。

所有的看板卡片，打开看依然是一篇干干净净的纯文本 Markdown 文件。

即便是 20 年后在任何纯文本编辑器里也都能完整打开，用户拥有数据的绝对主权。

到处都在疯狂堆砌功能、拼命追逐 All-in-One，这种对产品边界的克制，显得有些不合时宜，但也格外珍贵。

写在最后

很多时候，我们总希望找到一个完美的全能工具，希望一个软件能把笔记、待办、项目管理、甘特图全部能实现，变成一个一劳永逸的系统。

但折腾了这么多年工具，我越来越意识到：

真正能陪你度过漫长岁月的🚶 往往不是功能最繁复的工具，是那些边界极其清晰、绝不喧宾夺主的工具。

认清它的本质，也守住自己的节奏。

剩下的，交给时间，也交给自己的思考。