惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园 - Franky
WordPress大学
WordPress大学
Hugging Face - Blog
Hugging Face - Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
小众软件
小众软件
人人都是产品经理
人人都是产品经理
罗磊的独立博客
博客园 - 聂微东
雷峰网
雷峰网
量子位
美团技术团队
V
V2EX
The GitHub Blog
The GitHub Blog
大猫的无限游戏
大猫的无限游戏
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
IT之家
IT之家
The Cloudflare Blog
爱范儿
爱范儿
T
Tailwind CSS Blog
博客园 - 三生石上(FineUI控件)
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
宝玉的分享
宝玉的分享
Last Week in AI
Last Week in AI
Jina AI
Jina AI

少数派

派早报:Google 发布 Fitbit Air 等 - 少数派 「新人报到」確認需求,再開始 - 少数派 从 SOLO 独立开发者社区,我看到了越来越多开发者开始做自己的产品 - 少数派 我怎么管理那些"不常做,但总会忘"的生活事项 - 少数派 人形机器人量产元年,数据才是具身智能的“生死线” - 少数派 BuhoLaunchpad 高度还原 Mac 启动台:开发历程与思考 - 少数派 五年陪伴依然不舍,DIY 换壳后让罗技 MX Master 3 继续服役 - 少数派 新玩意 240|少数派的编辑们最近买了啥? - 少数派 一日一技|为什么你应该关闭 iOS 的键盘声音 - 少数派 我做了个插件和 Skills,一键提取任何网站的设计规范 Design.md - 少数派 住在三四线城市的你,该开始录播客了 - 少数派 甘南秘境,大白高国 - 少数派 AI的审美:谁让把我变成川内倫子 - 少数派 返工怎能不烦恼,打工人片单总有一部是你的「嘴替」 - 少数派 为了让「上厕所」更健康,我做了一个小工具 - 少数派 AI + Skill,能够让生成的文章去除 AI 味吗? - 少数派 新玩意|韶音OpenDots ONE 耳夹式耳机 - 少数派 《美满》| 在每一个春天的晚上相爱(362) - 少数派 新玩意|优篮子 PS01 MagSnap 磁吸支架 - 少数派 自我整合手记 | 我开始早睡了:用稳定规则,为自由托底 - 少数派 用龙虾(OpenClaw)两个多月,我最深的12个体会 - 少数派 听歌时间到,12 张你可能错过的 2025 华语乐坛好专辑 - 少数派 承诺能追吗 - 少数派 macOS 26启动台没了? 我做了个不一样的App启动器 - Keboard - 少数派 《四海为家的人》| INTJ对话INTJ(361) - 少数派 你发过的那些黑历史,是时候一次清干净了 - 少数派 新玩意:安安静静玩,越玩越专注:计客密码机 - 少数派 iPad 用户首次体验 Android 平板:vivo Pad6 Pro - 少数派 数据逻辑强 - 少数派 极北行+ | 一路向北,探访日本至北之地 | 001 - 少数派
我的 GTD 进化史:从清单失控,到用 Obsidian 双链构建真正的...
2025-06-26 · via 少数派

本文适合对 GTD 有一定了解,但在实践中感到困难或有阻力的效率工具爱好者。

我实践 GTD 有一段时间了。和许多人一样,我被它承诺的“心如止水”所吸引,一头扎进了这个充满清单、上下文和每周回顾的世界。然而,理论的完美,在现实的高压下往往会露出裂痕。

我的 GTD 系统,就经历了两次濒临崩溃的危机,和两次脱胎换骨的进化。这趟旅程的核心,是从一个“以清单为中心”的僵化系统,转向一个以 Obsidian 双链为核心的、流动的、真正为我服务的「项目引擎」。

刚上手时,我严格遵循着 GTD 的教条。

我设置了三个 md 文件,一个是 inbox 收件箱,一个是项目清单,一个是执行清单,并在执行清单里面设置了 @电脑, @家, @杂事 等上下文。我很认真地处理收件箱,拆分项目和下一步行动。但很快,第一个问题出现了:

我发现随着时间的流逝,我开始逐渐放松对 GTD 流程的执行。这导致了任务和信息的堆积。

而且,我感觉自己的各个项目推动进度也比较慢。

任务越来越多,我却越来越不想去看它们。我曾在 gtd 论坛上发帖求助,社区给了我很多帮助。通过社区的指点和自己的反思,我迎来了第一次突破:

  1. 回归处理收件箱的基本功;
  2. 确保项目清单中的项目和执行清单中的行动有一一对应的关系

我认识到,我首先需要认真地清空收件箱:严格地、逐一地,用“这是什么?”“它可执行吗?”“2分钟内可完成吗?”“是不是需要多个步骤才能完成?”等等问题,依次处理收件箱里面的内容,把它们纳入参考资料,或者项目清单、执行清单、未来/也许清单,亦或是直接删掉。

然后,除了收件箱里面整理出来的任务之外,最终那些要执行的系列任务,都是从项目清单生发出来的。这意味着,我需要盯着项目清单,逐个项目,想出每一个的项目下一步该怎么做,再到执行清单里面去做记录,确保每一个项目都有一个明确、可执行的“下一步行动”。这样一来,每个项目和执行清单的下一步行动之间会产生一条无形的连接线。

当我在完成了某一项目在执行清单中的“下一步行动”后,我会在执行清单里动态更新这个项目对应的再下一步的行动。直到我完成这个项目,我又会去项目清单里面把这个项目归档到已完成的项目中去。

这让我第一次尝到了完全掌控感的甜头,系统也顺畅地运行了一段时间。

但好景不长,当工作强度真正上来时,第二次、也是更深层次的危机爆发了。

第二次危机:系统在高压下崩溃

当任务像潮水般涌来,我那套看似“完美”的系统,暴露出致命的设计缺陷。

我的收件箱变成了摩擦和拖延地带。

看着收件箱不再是清爽的处理流程,而像是面对一堵由无数决策砌成的墙。仅仅是拿起一个条目,去思考“这是什么?是项目还是行动?属于哪个项目?我该把它放到哪个清单的哪个位置?”,这个过程所需的纯粹脑力是巨大的。它不是一个流畅的动作,而是一个我的大脑会本能抗拒的、生硬的上下文切换。

结果就是,我干脆就把事情都留在了收件箱里。然后它就自然而然地退化成了一个混乱的、事实上的执行清单,而任何参考资料都被留在了那里,未被归档,迷失在混乱之中。

总结下来,我的系统在高压下出现了三大问题:

  1. 项目与行动的“断连”:执行清单里的行动,和项目清单里的项目,只靠我的大脑去关联。我需要靠意志力去想:“哦,这个任务是属于那个项目的”,然后再去另一个地方找那个项目的参考资料。
  2. 高阻力的处理流程:从收件箱把信息归类到它该去的地方,以及动态更新我每个项目的“下一步行动”,这个过程太累了。
  3. 失效的上下文(@Context):我的绝大多数工作都在电脑前完成,@电脑 标签几乎覆盖了所有任务,失去了筛选意义。

我意识到,我需要一个全新的架构,一个能从根本上消除这种“断连”和“阻力”的系统。于是,我的第二次进化开始了。

第二次进化:用 Obsidian 构建以项目为中心的「控制塔」

这次进化的核心思想是:放弃以零散的“清单”为中心,转向以聚合的“项目”为中心。 我的工具是 Obsidian,我的武器是它的灵魂——双向链接。

1. 新的清单结构:行动跟随项目

我的「执行清单」(gtd-next-actions.md) 不再是一个扁平的列表,而是用“项目”作为标题进行分组。

这是一个执行清单的例子:

@[[项目:Q2 财报]]

  • [ ] @等待 各组更新数据
  • [ x ] 起草报告初稿

@[[项目:客户演示]]

  • [ ]  @电话 和客户确认会议时间
  • [ ] 制作 PPT 第一版

这里的 @ 符号只是一个视觉提示,关键在于 [[项目名]] 这个双链。它让每一个行动都天然地“挂靠”在了一个可点击的项目枢纽之下。

而且,我会把这个项目马上该做的几件任务直接写在底下(而不是仅仅写一个最新的、一直要更新的‘下一步行动’),要增加条目也可以直接增加。完成了任务后,想归档的时候也可以直接剪切进双链的项目文件中归档。

2. 项目笔记:真正的「任务控制塔」

点击任何一个 [[项目名]] 链接,我就会进入这个项目的专属页面。这个页面,才是真正的“任务控制塔”,它聚合了关于这个项目的一切。

脱胎换骨:新系统带来的三大改变

这个新系统,彻底解决了之前的所有痛点。

1. 启动阻力几乎为零

它从根本上简化了我处理收件箱时的步骤。虽然我还需要弄明白“这是什么”,但后续的操作变得非常丝滑。比如,如果这个信息属于 [[项目:Q2 财报]],剩下的动作就几乎是全自动的了。参考资料直接放进这个项目笔记,下一步行动直接写在执行清单中对应的@的标题下。那个让我抗拒的“生硬的上下文切换”被消除了。

2. 上下文唾手可得

这是最大的胜利。当我在执行清单里看到“起草报告初稿”这个任务时,我不再需要靠记忆力去想“数据在哪?要求是什么?”。我只需点击它上方的 @[[项目:Q2 财报]] 标题,所有相关的参考资料、邮件纪要、数据、对话中的摘要等瞬间就在眼前。那种“好了,现在我得去那个文件夹找那个文件了……”的摩擦感,完全消失了。

3. 重新掌控全局

我现在能同时清晰地看到“森林”和“树木”。执行清单让我专注于每个叶子(下一步该做什么)属于哪棵“树木”(项目),而项目页面让我随时能退后一步,看到整个“森林”(这个项目进行到哪了,全貌是怎样)。这种在宏观和微观之间自由切换的感觉,让我重新获得了对复杂工作的掌控感。

永不停止的进化:来自社区的灵感

我的这套系统远未到“最终形态”。GTD 的实践是一个持续迭代、永不停止的旅程。

在我分享了这个新方法后,一位论坛上的老朋友给我提了一个绝妙的建议。他仍然按上下文组织执行清单,但当需要项目信息时,他会直接用 Obsidian 的快捷键 ⌘O (Open file quickly) 来快速搜索项目笔记。

这对我来说是一个“灵光一闪”的时刻。我一直用 Ctrl + O 来找各种零散的笔记,但从没想过把它作为一种从任何地方直接跳转到项目页面的主要方式。

这让我意识到,即使我的系统解决了我的核心痛点,也总有值得借鉴和吸收的智慧。我现在的视觉分组方法对我来说是颠覆性的,但我也开始将 ⌘O /Ctrl + O 这个技巧融入我的日常,作为一种更快速的“主动导航”方式。

结语

如果你也像我一样,在 GTD 的实践中感到挣扎,感觉自己被工具和规则所束缚,我希望我的经历能给你一些启发。

工具是次要的,无论是 Obsidian, Notion, 还是 Todoist。核心在于,我们能否诚实地面对自己工作流中的“摩擦点”,并勇敢地打破规则,去构建一个真正能降低我们“启动阻力”的个人化系统。

GTD 不是一套需要被严格遵守的教条,而是一个可以被我们不断塑造、打磨,最终成为我们思维延伸的强大引擎。这条进化之路,仍在继续。