444 万下载的 Tasks,第一个开关我配反了

这篇笔记的文件名，尾巴上写着 2026-10-15。

属性里的「创建日期」是 2026-10-15T23:47:58。

属性里的「发布日期」是 2026-10-13T12:20:40。

差两天。我是装完 Tasks 之后才看出来的。

444 万下载的插件，我在第一个设置项上就配反了。这篇写怎么发现的，以及一个功能到底配不配你的库，该怎么判断。

一、我库里的待办，一直是笔烂账

先说清楚我管的是什么。我 Obsidian 库里的待办，几乎全是维护类的。

收件箱进来的文章要分类，摘要要补，标签要清，死链接要查。

这些事零碎，写在哪篇笔记里就沉在哪篇。勾完沉底，过两周谁也找不到。

Tasks 就干一件事：把全库的 - [ ] 收拢到一页，还能查询和排序。

二、它在 checkbox 上加了两层

原生 checkbox 是死文本。Tasks 加了两层东西。

第一层是日期语法，直接写在任务后面。📅 截止日，⏳ 计划开始日，🔁 重复规则。

第二层是查询块。一个 ```tasks 代码块里写条件，全库符合条件的任务列进来。

图1：左边源码，右边渲染结果，四组查询各自带任务数

四组查询，每组都标着数字。最后一组写着 No match，0 tasks。

这就是它比原生 checkbox 多的东西：原生只会堆，它会筛。

查询条件写起来很直白，not done 只留没做完的，due before tomorrow 只留明天之前到期的。

group by filename 按笔记归堆，sort by due reverse 按截止日倒排。

写错的条件不会报错，它只是给你一个空列表。所以第一组查询建议先不加条件，看总数对不对。

三、装之前我先查了它活得怎么样

这一查，查出个反差。

下载量前三里，只有 Tasks 还在跑。

Advanced Tables 差 115 万下载，但五个月没提交。

Calendar 319 万下载，两千多天没动过。Kanban 275 万，直接交回社区归档了。

Tasks 最近 100 次提交，84 次在 7 天内，47 次在 3 天内。

下载量说明有多少人装过。提交频率说明现在还有没有人管。这两件事经常不是一回事。

图2：编辑任务弹窗，六档优先级，三个日期，还有依赖

弹窗里除了 Due、Scheduled、Start 三个日期，还有 Before this 和 After this。

那是任务依赖。很多装了两三年的人不知道它有这个。

四、我按文档配了第一个开关

设置页很长。我在「从文件名中提取日期」这一节停下来了。

第一项叫「将文件名用作未注明日期的任务的计划日期」。

官方说明：任何未注明日期的任务，都会被赋予从文件名里提取出来的默认计划日期。

我看了一眼收件箱，文件名确实都带日期。

图3：开关开着，生效范围填了 A-收件箱

我的流程是网页剪藏往 A-收件箱灌文章，文件名格式是「标题 空格 YYYY-MM-DD」。

剪藏工具里那行配置写的是 {{title}} {{date|date:"YYYY-MM-DD"}}，保存路径固定指向 A-收件箱。

Tasks 默认认 YYYY-MM-DD 和 YYYYMMDD，格式正好对得上。

所以我把这项开了，把生效范围限定在 A-收件箱，没留空。

留空就是全库生效。限定范围这一个框，是我唯一多看两眼的地方。

配置逻辑听起来很顺：文章抓进来带日期，任务从文件名拿到日期，省掉手写。

我当时还觉得这设计挺聪明。

五、语法先验了一遍，是通的

配完没直接上手，先写了个测试笔记验语法。

• 库重构验收 📅 2026-10-20

• 每周复核清单 🔁 every week

• 明天的会 ⏳ 2026-10-19

图4：三个 emoji 全渲染成图标

日历、循环、沙漏，全渲染出来了。

这一步通了，说明装好了，日期语法也没问题。我心里挺稳。

六、翻回一篇真笔记，撞了

然后我打开收件箱里一篇真抓进来的笔记，看属性。三个日期摆在同一个屏幕上。

图5：三个日期在同一屏里

差两天。

如果我只是想知道这篇东西什么时候到我手上的，这个日期没错。

但 Tasks 拿它当计划日期。计划日期问的是我什么时候处理它，这跟它什么时候进我库有什么关系？

我这才想明白：剪藏工具的日期变量取的是我按下抓取那一刻，不是原作者发布的时间。

可任务日期该是什么？是我打算动手那天。这个功能给它的，是我抓到资料那天。

这三样东西被我当成一回事很多年了：资料发布的时间、资料进我库的时间、我打算处理它的时间。

剪藏把它们压成了一个字段。Tasks 又把这个字段读出来当计划日期。

一层压一层，最后那个日期跟我真正关心的事已经没关系了。

七、它没错，是我把模型套错了

复盘一下。

做对的是先验语法再配功能。语法是硬规则，emoji 认不认一眼看得出，这层没出事。

做错的是把默认值当成了推荐值。

这一项的前提是「文件名带日期等于那天的任务清单」。这是日记类笔记的模型。

2026-10-18.md 里写的待办，挂 10-18 完全合理。那天的笔记就代表那天。

我的收件箱不是日记，是资料进料区。文件名里那个日期是入库时间戳。

两个模型不一样。硬套就是错位。

要说这个功能对谁是对的：每天开一篇日期笔记、当天的事当天写完的人，配上很顺。

对拿文件名当时间戳、库里大部分内容不是待办的人，配它就是给自己埋坑。

八、它不会立刻炸，但会埋雷

说实话，配上之后没报错，也没当场乱。

因为那篇笔记里压根没有任务。正文只有一句摘要和待 AI 生成。

所以这次是我自己翻属性翻出来的，不是它提醒我的。

但雷在那儿。哪天我在收件箱笔记里写一条待办，它就会被挂上抓取日当计划日期。

然后按计划日期排序时，所有收件箱来的任务按抓取顺序排，不是按紧急程度排。

这个错的隐蔽性在于，它不会报错。查询块照样列出来，日期照样显示，看起来一切正常。

你不主动去核那个日期是从哪来的，就永远发现不了。

九、还有个开关，你最好也看一眼

设置里有一栏叫全局任务筛选器。我这里是空的。

空的意味着，库里所有 checkbox 都算任务。

图6：官方演示，没带 #task 的那行就不被当任务

演示图底部那条 Model test，因为没带标记，就不算任务。

你库里要是有「长得像任务但其实不是」的 checkbox，比如草案勾选项、清单里的打勾，都会被算进去。

判断方法很简单：先查一次全库未完成任务的总数。数字要是比你预想的多，就是混进来了。

十、现在什么样

生效范围锁在 A-收件箱，开关还开着，范围外一根汗毛不动。

下一步我想试的是：真往收件箱笔记里放一条不带日期的待办，看它实际被塞什么日期。验完再决定这功能留不留。

如果你也想试，顺序建议是这样：先只写三行带日期的任务验语法，通了再动那个从文件名提取日期的开关。

而且动之前先翻一篇真笔记，看它的文件名日期到底是发布日还是入库日。这一步花不了一分钟。

成本就这些：一个人半小时，插件免费，配错的代价是回头把文档读一遍。

顺带一句，官方 README 四张演示图里三张是 2021 年的截图，界面还是 v0.14。插件六天发三个版本，图三年没换。

文档滞后是常态，别把它当说明书看。

444 万下载的插件，第一个开关我配反了。反的不是设置本身。

是我没先问一句：这个功能的设计假设，跟我库里那份数据的真实含义，对不对得上。

你库文件名上的日期，是任务日期还是入库日期？