写在前面
在 GTD 风潮兴起的时期，OmniFocus 曾经是任务管理 App 中的一代经典。
直到今天，OmniFocus 仍有大量粉丝。毫不夸张地讲，它影响了后来很多 todo 类工具，甚至在苹果自带的「提醒事项」里，也能看到 OmniFocus 的影子，比如后文会讲到的「透视图」。
我个人从 OmniFocus 2 开始入坑，但现在已经退烧很久了。我很想讲讲自己为什么退烧，但又很难归纳。最近，我看到一篇文章，讲述作者如何从 OmniFocus 切换到纯文本任务管理，我觉得和自己的经历有不少相似之处。因此，特别想分享给大家。
在分享之前，我要提醒一下：下面的文章对于一些读者来说，可能比较生涩。我已经尽力简化和注释了。我觉得文章的理念比较重要，大家不要纠结于里面的具体代码。即使完全不会代码，也有大量第三方工具可以实现类似的功能。
大家会看到 Obsidian、Logseq 的影子。如果看到 Denote 那部分，是不是也会对「文件名标签」唤起一丝熟悉感？而纯文本对同步的友好性，以及对 AI 工具的加成，例如 Claude Code、Codex，也会是未来的重要方向。这一切，都是效率火箭这些年来反复提到的东西。
最后再啰嗦一句，每个人的情况都不太一样。OmniFocus 之类的 todo 工具仍旧有用武之地，只是一部分作用被分流出去了。原作者恰好是一名后端工程师，那么绝大多数工作任务都可以被更「接地气」的方式分流出去，并不是说每个人都要做相同的实践。
我个人也仍旧保留了 todo 工具，但显然也注意到，大量具体工作任务已经被分流到了具体的项目文件夹里，并且开始和 AI 进行协作。可能这也是 OmniFocus 这类重度 todo 工具逐渐退出我视线的原因之一。
原作者：Max Holovanov
原文链接：https://medium.com/@maxclax/i-spent-9-years-in-omnifocus-then-i-switched-to-a-text-file-4190628ed11f
火箭君整理、编辑、翻译。以下正文。
正文
我觉得，OmniFocus 是花钱能买到的最好任务管理器。我用了九年，然而现在我转向了「纯文本」。
与 OmniFocus 共事的九年
我大约在 2011 年开始使用 OmniFocus。
九年来，它管理着我的生活，直到 2020 年，我把一切迁到了 org-mode。我想一开始就说清楚：它是一款出色的软件。如果今天有人问我「花钱能买到的最佳任务管理器是什么」，我仍会毫不犹豫地说是 OmniFocus。
它把重要的东西做得恰到好处。收件箱捕捉是瞬时的。项目模型可靠。推迟日期、回顾周期、视角，整个 GTD 机制都在，而且打磨得光亮如新。移动端应用也确实出色：可以随时随地捕捉想法，也可以在火车上回顾任务，或站在商店里查看某个情境。多年来，那恰恰是我生活所需的视图，它实现了这一点。我通过它推进的每一个项目都达成了结果，没有任何事情被遗漏。
这是一个故事：一个曾经非常有用的工具，如何因为「用户摩擦」而逐渐退出我的工作流。
没人提起的「摩擦」
以下是我在日复一日使用 OmniFocus 时开始感受到的问题：我花在视图切换上的时间出乎意料地多。
OmniFocus 是围绕透视视图构建的。透视视图本质上是保存好的筛选器，可以按情境、项目、标签、可用性来划分任务。透视视图很强大。但功能强大，也意味着透视视图很容易越建越多。
我会打开应用，然后开始来回切换：收件箱，然后是预测视图，然后是一个自定义透视视图，然后是项目，再切回。每次切换都很微小。它们都不是实际工作，而是工作的管理，是运行一个复杂到需要导航的系统所付出的代价。
把每天一个微小的代价乘以多年，它就不再微小。
我一直在反复思考一个挥之不去的问题：如果系统可以变得更简单会怎样？不是能力降低，而是更简单。如果我的任务更贴近实际工作所在，而我不必特意去「导航」到它们那里，会怎样？
为什么选择 Org-mode
我在其他一切事情上已经生活在 Emacs 里。Org-mode 就在那里，优势显而易见：任务就是 .org 文件中的纯文本。没有数据库，没有同步引擎，没有专有格式。任务就是一行。项目就是一个文件。议程是对那些文件的一次查询。
诚实地说，Org-mode 真正阻碍我的问题是「移动端」。OmniFocus 的手机应用是我九年来一直依赖的东西，我不想放弃人在办公桌以外的任务捕捉和回顾能力。
现在，BeOrg 这款 App 完全解决了这个问题。这是一个 iOS 应用，可以直接从 iCloud 或 Dropbox 读取和写入纯 Org 文件。在手机上捕捉到收件箱、勾掉 TODO、浏览议程，离线也可用，并且会以纯文本同步回去。只要我确认移动端捕捉仍然可行，留下来的最后一个理由就消失了。
桌面端的捕捉保持刻意简单，甚至有些无趣。一个收件箱文件，一个模板：
(setq org-default-notes-file (expand-file-name "inbox.org" org-directory))(setq org-capture-templates '(("t" "Quick todo → inbox" entry (file org-default-notes-file) "* TODO %?")))
用快捷键输入想法，完成。从手机上的 BeOrg 应用也会追加到同一个 inbox.org。一个收件箱，两台设备，零转换。
真正的原因：任务就在工作发生的地方
移动端曾是阻碍。但那并不是根本原因。真正的原因是：
当我在处理一个项目时，我已经在它的目录和文件中。使用 Org-mode，我可以直接在上下文中写下任务，不需要切换应用，也不需要在一个单独的工具中重新查找项目。每个项目都有自己的路线图文件 ROADMAP.org，所谓的 Agenda（议程视图）则简单地将它们全部收集起来。
这是 OmniFocus 透视视图从未给过我的东西。任务不再驻留在一个我必须专门去访问的工具里。它就位于我正在执行的工作旁边，议程只是负责把它们汇总出来。
这一单一改变，几乎一次性消除了所有视图切换的摩擦。再也没有「打开任务管理器」这一步了。任务管理器就是我已经在编辑的那些文件。
我重新调整了流程，因为议程扫描会蔓延
我的第一个本能，是把 ROADMAP.org 文件直接散布在每个代码仓库里。感觉很纯粹：路线图就和工作文件、源码并排而居。
后来事实证明，这是个错误，Emacs 很快就让我意识到了这一点。每次启动都变得更慢。
一旦你看到原因，它其实很简单。Org 的议程通过扫描目录来构建文件列表。如果你把它指向包含代码项目的目录树，它会递归进入 node_modules、.git、build/、vendor/，成千上万的文件在每次议程构建时都要走一遍。要么你永远维护一份小心翼翼的排除列表，要么你接受慢启动。这两者都意味着系统开始要求你管理系统本身，而这正是我想要逃离的东西。
于是结构演进了。我没有再把路线图文件散落在各个代码仓库里，而是迁移到一个单一、专用的笔记目录，并为每个项目创建一条自己的 Denote 注记。
Denote 是一个极简的笔记包：每个文件都有一个带时间戳和关键词标签的名称，基本上这就是全部理念。设置很简单：
(use-package! denote :config (setq denote-directory "~/org") (setq denote-file-type 'org) ;; Lifecycle keywords — project / area / resource / archive (setq denote-known-keywords '("project" "area" "resource" "archive" "reference" "meeting" "idea" "someday")))
火箭君注：Denote 是一个文本笔记，但是 文件名上包含标签和时间戳之类的「元信息」，这样系统就可以根据预定义规则，按照标签等条件筛选内容展示。
每个项目就是一条 Denote 笔记，标记为 project，并具有一个可预测的内部结构：目标、下一步动作、未来某天。议程只扫描这一目录，而这个目录也只包含笔记。没有需要排除的东西，因为这个目录附近根本没有 node_modules：
;; Skip dotfiles; only ever scan the notes directory — never code repos(setq org-agenda-file-regexp "\\`[^.].*\\.org\\'")(setq org-agenda-files (seq-filter (lambda (f) (not (string-match-p "/templates/" f))) (directory-files-recursively "~/org" "\\.org$")))
是的，我放弃了「任务就在源文件旁边」那种纯粹性。换来的回报是，一个启动即用、永远不需要调校的系统。这个权衡显然是正确的。Denote 最终让整件事呈现出来的是简单，而不只是纯文本。
关于同步：别想太多
有一段时间，我用 Syncthing 来同步一切。它能用，而且如果设备从不接触商业云服务，它仍然是个相当不错的选择。
但对于纯粹的 Org 文件来说，说实话，这有点大材小用。Org 模式下，信息只是一些小小的纯文本文件而已。没有什么数据库会损坏，没有复杂的数据结构，也不需要合并引擎。所以我让显而易见的工具做显而易见的事情：笔记目录放在 iCloud Drive 上。BeOrg 在我手机上读取同一个 iCloud 文件夹。当然，Google Drive 同样可以胜任。
纯文本才是这里的特点。任何同步方式都行，因为没有什么需要智能同步。它只是单纯的文件而已。
我没料到的回报：AI 时代的纯文本优势
当我在 2020 年切换时，我根本没在考虑人工智能。事实证明，它比这份清单上的其他任何东西都更重要。
Org-mode 不会删除已完成的工作，它会把它归档。在一个已完成的任务上按下一组快捷键，整个子树就会移动到一个归档文件：标题、CLOSED 时间戳、优先级、标签，以及你一路上添加的所有笔记。
;; Completed tasks move to a dated archive, not the void(setq org-archive-location "~/org/archive/%s_archive::")
想想那个归档实际上是什么。Git 历史记录告诉你代码发生了什么变化。你的 Org 归档告诉你，你决定做什么、为什么要做，以及它已经完成。这些都用你自己的话记录了意图和结果。这是一种不同的、在某些方面更丰富的日志：项目的记忆，而不仅仅是差异。
而且因为它是纯文本，人工智能可以读取所有内容。我可以把六个月的归档任务交给模型，并提出真实的问题：是什么一直阻碍了这个项目？时间到底都花在哪儿了？我上次接触这个东西时都说了什么？归档不再是坟场，而是一个输入。项目的每一个新阶段，都可以以它自身的历史作为上下文，既为我提供参考，也为模型提供参考。
专有的任务数据库做不到这一点。它的历史被锁在只有供应商应用才能理解的格式里。纯文本对所有工具都保持可读，包括那些在你写下这些内容时还不存在的工具。这就是纯文本在长期里悄然胜出的理由：你不是在为当下的应用选择格式，而是在为明年的工具仍能读取的格式做选择。
Org-mode 负责运行任务，我仍然手工规划结果
到这里，如果用「现在一切都在 Org-mode 里」来给本文作结，会显得优雅整洁。但那并不真实。
Org-mode 运行我所有的任务和整个日程，包括捕获、项目、截止日期、每日回顾。那是执行层，而且完全数字化。但高于任务的那一层，也就是决定一个季度走向的少数几件事，我仍然手工规划。
为此，我为 Kindle Scribe 自己制作的一个计划本，因为在四月之前，市面上的七个现成计划本都没能满足我。
每天三件成果，每周三件，每月三件，每年三件。这个限制「三」就是重点。
「三」会迫使我做出真正的选择，而不是列一张愿望清单。并且成果要写成已经完成后的状态：不是「完成报告」，而是「我完成了报告，现在我可以……」。这会把注意力拉到影响上，而不是动作本身。
为什么把那部分保留为纸质？因为任务和成果需要不同的仪式。任务需要快速、可查询、可自动化，这正好是 Org-mode 的风格。成果则需要慢下来。我用电子墨水手写，没有通知，也没有可点按的东西。这种摩擦反而是有益的：它让我在 Org-mode 把一周填满动作之前，先静下来思考什么是真正重要的。
所以真正的系统是两层的。决策目标用手写，决定三项成果。Org-mode 以数字形式，执行所有属于这些成果的任务。纯文本并没有取代纸张，它解放了纸张，让纸张去做它仍然最擅长的那一件事。
这一切值得吗？
诚实地说，总有取舍。
OmniFocus 更加精致。它的移动端、复习模式、推迟和预览体验，所有这些都确实比我搭建的任何东西好。如果你想要一个安装当天就能完美运行的系统，就买 OmniFocus，别再往下看了。
Org-mode 是一个项目，而不是一次购买。我花了真金白银的时间去让捕捉、议程和 Denote 协同工作。你在读这篇文章，是为了跳过其中的一些步骤，但不可能全部跳过。
前提是，工作流里本来就需要 Emacs。我并不是为了任务采用 Emacs；我本来就长期生活在 Emacs 里。如果各位没有这种需求，情况就完全不同。
火箭君注：即使大家不是代码开发者，比如作者，比如分析师，比如咨询业，只要工作围绕着数字文件展开，其实仍旧可以基于项目文件夹工作，就像我一样，因此这个思路一样成立。这也是 Obsidian 之类工具兴起的原因之一。
我获得的是：我的任务不再是我偶尔访问的地方。它们和我的工作并列，以纯文本文件存在，由议程统一查询，再通过一个文件夹完成同步。那种视图切换的成本，每天一点点，持续九年，终于消失了。
OmniFocus 并没有输。我只是想要更少的系统，而纯文本是唯一能给我这种感觉的方式。
补充
原作者的完整 Org 和 Denote 配置：
https://github.com/maxclax/dotfiles
BeOrg 官网：
效率火箭，火箭君的新博客 