前言

这篇文章并不是以教程目的存在，其实是在本人实践GTD方式半年多的时间里，总结的文档。其中肯定有不确切或者错误之处，但是理解的方式因人而异，希望此文能够为学习GTD以及想高效组织和管理自身生活的朋友们带来一些提示。

文中全部基于文本方式实现并无配图，配图可能会让理解更为直观，但是目前看来更多只能做为点缀，细读本文的读者应该不用借助配图便能获取其中的思想，配图可能会在将来更新之时给出。

文本原始格式是Orgmode文本，如果看到网页本版或者其它更多格式的本文，应该都是基于该语法导出的文章。采用git方式进行版本管理，所以可能会在完善更新过程中不断发布新的版本。

概述

GTD是一种思路和方法，它可以渗透在我们生活的方方面面，而不仅仅做为任务管理的手段而存在。这里给出的只是是众多GTD管理方式的一种，是基于个人目前应用与实践情况而采用的GTD管理方式；GTD管理并不依赖特定工具，它可以在个人实践过程中，根据情况逐渐完善与改进；不同场景和环境下可能会借助不同的方式或工具来使用GTD，但是这些方式或者工具等都具有一种共性，这个共性就是GTD的思想。

执行平台

本文中叙述的GTD方法是基于一些常见的可分类、可贴标签、具有内部引用链接等功能的笔记进行，如为知笔记；但是讲述的方法会尽量避免依赖外部环境的特性（比如标签和引用的功能不一定在所有的工具中都有，Windows下的记事本就只能支持文本编辑）而强调方法的通用。

良好GTD系统应该具备的特性

添加对特定环境的特性依赖能使得在该环境下的GTD管理更有效率，但是对于一个良好的GTD方式，个人认为应该具有如下特性：

• 在现有环境中，应该能够方便地添加适合当前环境的特性依赖以提高GTD系统的效率。
• 更换环境之时，原有的GTD系统应该能方便地迁移到新的环境下继续运行。
• 切换到新环境之后，应该能方便地去掉对原有环境特性的依赖。

其实，这几点分别是对GTD系统扩展性、通用型、灵活性方面的要求，具有这些特性，有助于增强其健壮与稳定。任何系统在完善之前，首先要保证它有足够强的生存能力，最简单情况下，可以只凭借分类的文件系统、或纸质笔记、甚至只凭借自身的记忆（如果能够保证不会遗忘的话），实现GTD的管理。^_

主要内容

• 任务和项目
• 管理思路
• 执行方式
• 建议
• 其他

任务和项目

项目

这里的项目，是一个需要处理的事情、计划、或过程。它是日常生活、工作、学习中，我们所有要处理的、一系列相关的事务的统称，不同的项目代表不同类的事务。项目使得我们日常凌乱的处理事务，有了一个明确的归类。

任务

这里的任务不像项目那样笼统，而一定是可以明确执行的一个步骤，它可能属于某个项目。确定的任务可以让我们平时行动之时，目标明确，精力集中，无需被更多琐碎的处理判断归纳分类等而分心。

举例说明

例如：

“学习英语”，这就不是一个任务，它是包含许多步骤的过程，对应这里所讲述的项目；  
而“背诵5个单词”，就是一个具体的任务，它属于“学习英语”这个项目的一个子步骤；  
我们每完成“学习英语”中的一个任务，就距离“学习英语”这个项目的目标更近一步了。  

我们在真正学习英语的时候，每一个时刻其实都是在集中精力做其中的一个任务，期间不可能还做其它的事情；
比如“背诵5个单词”的时候，我们不应该还要分出心来思考：“学习英语需要先背诵一定的单词，然后尝试阅读，学习祈使句语法……”；
我们只需要背诵完这5个单词，别的事情是规划的问题，会在完成当前“背诵5个单词”的任务之后，来专门集中决策一下下一步需要做的事情。

总之，项目是需要规划的，任务是需要执行的，而规划是确定任务的。在一个项目中，将规划和执行分开，可能会提高完成的效率，而能够高效的完成所有的项目，会提高我们的生活质量。另外，并不是所有的项目都一定要完成，GTD只是让完成的效率尽量高，尽量减少压力，而非一定要将其中的项目完成。

管理思路

这里的GTD系统，实际重点在于管理任务的方式，项目在GTD中主要是用来反映将其中相互关联的任务集中起来便于回顾，对于复杂项目的管理方式，可能需要额外考虑。目前大致采用如下方式管理项目和任务，今后有好的方式会逐渐改善。

任务管理

每条任务使用单独一条笔记来表示，所有的任务都有自己的状态，状态通过目录来管理，具体见后面。

使用本方式管理任务，目前比较弱势的方面是缺乏时间提和醒方面的内容(也许是为了增强其简洁并且可移植，而导致的缺陷)，无法让任务随时间而迁移状态，无法合适的指明任务的时间属性，以及无法合适的在恰当的时间进行提醒。所以日常经常进行的、并且对时间提醒方面依赖不大的任务可集中在这里进行（例如工作日志）。而需要依赖其他特性(如提醒)的任务内容，可考虑借助工具辅助完成，如DGT GTD、中华万年历、等等。

项目管理

每一个项目用一条回顾来表示，而每条回顾用一条笔记来表示，而所有项目类似任务，通过项目的状态目录来管理，具体见后面。

使用本方式管理项目，目前比较弱势的方面是暂时还无其它合适的方式管理，因为项目也是随时间动态变化的，随着时间的推移我们会遇到的新的项目和计划，所以用目录或标签来表示项目也不太合适（经常建立新标签或者目录会使得系统越来越复杂），这里暂时用回顾表示一个总体的项目，每个回顾用一条笔记表示，期间的产生的各个行动步骤变成特定状态的GTD任务进行管理。执行任务时的一些关键的步骤会纳入到这个回顾系统中，回顾作为总体索引，也用来表示一个计划，期间会引用到本GTD系统内的任意一个其它的任务或者回顾等，也有助于保持整个GTD系统的有序。

执行方式

任务状态

每种任务同一时间只可处于一种状态，所以可以考虑用目录方式实现任务状态。

支持的任务状态

• “收集”: 当遇到一个需要处理的任务之时，我们需要首先迅速把它记录下来，可以只简单给出一个标题以便提示等等，之后在空闲时会对其进行进一步处理。这个最初出现的任务，可以没有经过任何整理，此时它处于“收集”状态。它是任务出现的初始状态，是所有内容流入GTD系统的入口。
• “下一步”: 同一时段我们一般只能处理有限的任务，根据实际情况，我们可能会从所有任务中选出一部分进行处理，这些已经开始进行处理的的任务，便存在这里，处于“下一步”状态。它是推动GTD系统运作的动力，使我们更集中精力于应该做的事情上来，而不被其它还没有开始的任务扰乱心神。
• “稍后”: 这里的任务也是应该做的，但是由于日程或者其它原因，需要将一些相对不重要的任务暂停，推迟一段时间再做，这时任务便处于“稍后”状态，它在GTD中起到缓冲紧张度的作用。
• “等待委派”: 有些任务在自己这里已经没有什么可以做的了，需要等待其它方的处理之后才能继续确认下一步的进行状态，或者转交给其他人处理，这可以将任务转给别人，这样的任务就处于“等待委派”状态，它可减轻GTD系统的负担。
• “将来也许”: 类似推迟，不过这里的内容表示没有一个期限的“推迟”，这里的任务相对推迟的任务来说也更显得“不重要”一些，这些“以后用空再做”的任务都放在这里，处于“将来也许”的状态。这个分类可以允许我们大胆的将想做的列出，并且可以不用对列出的事情“负责”，想做就做，不做也不会消失，它能大大减少GTD系统的拥塞程度。
• “已完成”: 一个任务完成之后，可能以后也会引用，也可能不会，这些已经处理完毕的任务，便成为“已完成”状态，它是GTD系统的历史。
• “取消”: 有些任务开始可能在“下一步”，过后又变成“推迟”了，再过后又“将来也许”，再过后，可能都没有必要执行它了，不删除它们，是因为可能它们将来还会有用，这些任务便处于“取消”的状态，相当于GTD系统的回收站。

任务状态与生命周期

在上述状态下，我们给出一个描述任务生命周期的例子。

a.阅读英文文档时，忽然发现需要背诵一些特定的英语单词，于是向“收集”状态目录中，添加一条“背诵英语单词”，然后继续工作。
b.空闲时，对“收集”状态的任务处理，这时发现“背诵英语单词”这条任务比较重要，于是把它纳入到“下一步”，准备之后就进行。
c.开始处理任务时，首先看“下一步”是否有任务，发现“背诵英语单词”这条任务， 于是开始进行学习，学习过程中不断的对该任务对应的笔记进行记录总结汇总更新等。
d.学习一定时间后单词还没有背完，但是在"下一步"又有其它的任务更为重要需要处理，于是开始处理其它的任务。
e.在处理“下一步”状态中的任务时，不断的有其它更多的重要任务需要处理，学习英语单词暂时还不能继续，于是把它从“下一步”移动到“稍后”状态，待处理完手头的任务之后再继续处理此任务。
f.处理“下一步”状态的任务时，不断的有新的比背诵英语单词更重要的任务，由于有重要的任务在先，被移动到“稍后”状态。
g.待“下一步”的任务处理完成后，再看"稍后"状态的任务，找到其中重要的任务，将它重新迁移到“下一步”中，准备进行处理。
h.处理完“下一步”的任务，再次从“稍后”状态的任务中， 选出重点的进行处理，这时发现“背诵英语单词”这条任务优先级很低，可能短期内不会再进行了，于是将它移动到“将来也许”中。
i.某日实在清闲，在“将来也许”中随便拿出一个叫做“背诵英语单词”的任务，放到“下一步”之前，发现它没有必要了，于是放到“取消”中，表示这个任务不执行了。
j.很久以后，浏览“取消”的任务，发现“背诵英语单词”，感觉最近要做，于是放到“下一步”。
k.到“下一步”中，取出一条“背诵英语单词”的任务，开始进行，直至完成后，将其移至“已完成”中。
至此，“背诵英语单词”这条任务结束。

项目与回顾

项目回顾是对GTD系统中任务的有机组织，每条回顾都包含相关的其它子项目或者计划、以及诸多任务处理状况的汇总。它可以使GTD系统更为有序，也便于将来跟踪相关的任务和情况。

由于项目是一系列相关任务的组合，所以每个项目借助一条回顾来表示；而我们遇到的项目的分类和数目经常随时间变化，所以用每条笔记而非目录表示一个回顾，进而表示一个新的项目。同时，类似于任务的管理，由于状态是所有项目相对通用和固定的属性，所以我们用不同的目录来表示项目状态，存放所有项目，为便于区分，表示项目的目录以“#”作为前缀。

项目状态

这里用来存放项目回顾的主要状态目录有：

• “#活跃”: 有些任务，如学习计划等可能需要反复执行，或者有些项目正处于活跃处理过程中，从中会不断衍生出新的任务到相应的任务状态。这样的项目便处于"#活跃中"状态，当项目进行到一定程度不再特别活跃的时候，可能会进入“#项目回顾”状态。
• “#回顾”: 是对相对不活跃的项目汇总，包含已经完成或者基本明朗的项目。在进行任务时，并不是所有任务都要建立回顾。当发现一些任务需要梳理其关系和追踪的时候，为这些相关的任务建立一个回顾，可起索引汇总的作用，在日后回顾这些复杂的任务之间相关的过程之时也可参考。

实际上有些项目，开始是做为任务进入到“收集”状态的，执行一段时间之后，知道了它可以做为一个项目回顾后，便将其放置到相应的项目回顾目录中。从这点上来讲也可看出，其实收集既是项目的初始状态，也是任务的初始状态，是任务进入整个GTD系统的入口。

项目生命周期

项目的生命周期一般是：收集、活跃、回顾；而需要重复执行的项目，其回顾放在"#活跃"目录中。

建议

原则

建议在实现GTD时，能遵循如下的原则：

不要将任务状态设置太多

过多的状态会导致GTD系统的复杂，处理任务时反而会因此分散精力。

任务不一定全部要处理完毕

GTD不是为了完成任务，而是为了减轻压力，使用GTD还能辅助记忆和梳理，减轻大脑记忆的负担。

任务从“收集”中拿出后，不应该再放回去

收集箱是暂存新流入和产生的任务，它是GTD内容的主要来源，而非为状态迁移而存在。

进行的任务要先移动至“下一步”状态，再进行处理。

这样能保证正在进行的任务集中在“下一步”状态，将精力只集中在“下一步”中的任务，而无需分散精力在其它状态中寻找需要处理的任务。

处于“下一步”状态的任务不宜过多

“下一步”是当前真正正在处理的任务，能够同时处理的任务是有限的，这里的任务不宜逗留过久，迟早会被处理成其它状态。过多的“下一步”任务，会为大脑和心里造成很大压力，同时。

处于“稍后”状态的任务，要么会回到“下一步”，要么会被放置其它状态

一些相对比较重要但是还来不及处理的任务，不放在“下一步”而是放在“稍后”中，可以起到缓冲压力的作用。这里的内容实质是被推迟的任务，如果不会被推迟很久，迟早会回到“下一步”状态；如果它可能会被推迟很久，那干脆将它放置“将来也许”甚至“取消”中。

大多数GTD管理不需要过于复杂的特性

执行GTD不应当过度依赖工具，只要可以创建内容（表示任务），并且能将内容归类（表示状态），完全可以手动完成绝大多数GTD管理。

多操作多整理多回顾有助获得正能量

经常回顾和整理自己的GTD系统，可以保持系统有序，还能给自己反馈正能量。GTD中表示待办任务，处理任务时便有一种做事情，也看到了效果的感觉。有一种说法是，这些“成就”会被大脑做为努力一段时间的“奖赏”，在手动处理GTD的同时会不断地有一种亲身获得“奖赏”的感觉。直观一点说，执行任务之前，会在心里不自觉地讨厌列在表上的任务条目，当完成任务之后，手动管理会亲身体会到将讨厌的那一条任务删除的成就感，尽管每次的成就很少，但是众多这样的反馈不断的激励着大脑，却能给自己带来意想不到的力量。

在特定环境下可借助特定工具扩展GTD来提高效率

除了基本的GTD功能，对于特定工作环境，一些高级属性借助工具扩展，可能会有助提升效率。如今日待办、或者提醒，场景或任务跟踪等等，在一些工具中有特定的表示和组织方式，设置好相关属性后，任务会自动迁移、或者提醒等等，避免了手动设置。尽管几乎不用进行手动设置了，但是想要保持自己GTD的有序和获取更多的执行动力，还是要经常回顾。可以借助相关的GTD管理工具，这里介绍几个：

DGT GTD：

是安卓系统下非常全面的GTD工具，操作便捷，记录迅速，自定制功能丰富，支持备份，自定义同步等，只是刚开始需要稍微熟悉一下其操作的方式。简单说，两个特点：“丑”（不是很丑）、“好用”（非常好用）。

Doit.im：

支持多平台，云同步，界面简洁便于初学者使用和理解GTD的工作流程，但是有些功能需要收费才能实现。

Omnifocus：

没有亲自用过，根据许多文章中的介绍，可以知道这是一款重量级的华丽版的IOS下的GTD管理工具，入门门槛高，但是功能极其强大。

2Do：

也是一款IOS下好用的GTD管理工具，功能强大，入门相对简单。

Wunderlist(奇妙清单)：

简洁的界面，不过在国内同步功能比较慢。

toodledo

IOS下一个比较流行的GTD工具。

Orgmode：

这个其实是基于文本的标记语言，是Emacs的一款著名的编辑模式插件，但是功能非常强大，目前已经在许多地方支持（如vim、github、IOS、Android应用上等）。它的初衷是项目管理相关的目的，其中就包括能够实现GTD管理的相关内容，但是功能不仅限此，它也可以用来记录笔记，记录的笔记基于大纲模式，有一定的所见即所得功能，但是更强大的是“所想即所得”的特性，是word远不能及的。这个工具/语言不限于平台，只需遵循orgmode语法即可，配合Emacs进行使用会使得效率极高、扩展性几近无限。Orgmode能够完成的功能也会随掌握程度的提升而丰富：如果简单掌握，那么Orgmode属于轻量级标记语言中的一种；但是如果需要更多的功能（如导出发布为各种格式），则需要进一步的学习。关键的是，Orgmode文件是纯文本格式，只需纯文本格式的内容便能实现它的全部功能。

推荐

这里算是给本文以及实际中习惯的工具做一个“广告”吧。具体如何理解和接受，还要看各位读者的喜好。结合实际经验，这里给出用于GTD管理的工具或方法选取的建议。

如果一个工具或方法它存放数据的形式越原始，越开放，记录越便捷，其适用度越高，也越容易被人接受（我想相对于直观的文本格式内容，哪些数据库格式、或压缩格式、或版本控制数据格式、以及更多其他特定格式的数据文件，更容易让人接收应当是文本格式的内容吧）。毕竟数据是自己的，工具只是外壳；访问数据的便捷可能需要借助特定的工具或方法，但是如果脱离了特定的工具方法，数据仍然不受影响才是多数人关心的。

对于GTD管理的工具和方法，做如下推荐：

Orgmode

它其实已经超出了工具的范围，它实际属于一种语言或者规则、方法，功能比较全面，不仅可以GTD管理，还能做项目管理、内容管理等等。Orgmode可以让我们记录的数据以最原始的方式（直观的文本方式）来展示出来，而访问数据的方式一方面可以通过Emacs的orgmode高效进行，另一方面也可脱离相关工具，只要掌握Orgmode的一些约定语法我们仍可以用最原始的方式（如记事本）访问我们的数据，更能结合使用各种版本控制工具来管理我们的数据等。另外，我们还能将Orgmode的数据导出为当前流行的各种格式（如Html、pdf等），当然，越复杂的功能，就越需要更长时间的学习，如果我们没有足够的时间，Orgmode的简单功能也是够用的。因为期间会涉及到Emacs的使用以及Orgmode的配置等，篇幅关系会有专门的文档对Orgmode进行介绍，这里不详细说了。

DGT GTD

在安卓系统上，它也将其工具的特性发挥到了极致。几乎支持所有你能想得到的GTD管理信息，也支持数据导出、共享、备份等等，最重要的是，记录非常方便，非常适合记录一些瞬间涌现的灵感等等，当然，为避免日后可能会迁移数据引起的问题，重要的数据还是尽早导出到一种通用的存储方式组织好（例如OrgMode）。

任意一个带有分类功能的便签

毕竟不是所有人都使用Android系统，如果找不到或者没有或者不想学像DGT GTD那样的工具，可能会有些不方便，即便如此我们仍然可以进行GTD管理。我们各自的系统中一般也都能找到一个类似“便签”、“记事本”的工具，如果没有，一般也都能够找到对应系统的一款相关软件。最后一个方法，也就是：结合本文中介绍的方法以及你当前系统上已有的某个相对便捷的、带有“分类”特性的记事软件，也能实现基础的GTD管理。方法很简单，就是将本文中提到的几个GTD状态做为分类，每一篇的笔记内容做为GTD任务（例如，可以使用比较常用的云笔记、中华万年历、为知笔记、evernote、甚至系统自带便签来进行）。
如果以上提到的环境都不具备，也并不代表不能进行GTD的管理了。毕竟GTD只是一种方法，如何使用它，还是要看使用这个方法的人。正如前面已经提到的，每个人都有自己的方法来实现GTD，只有一个纸和一支笔，甚至只有一个好的记忆方式，也一样能实现GTD的管理。因为实现GTD最本质的东西只需两个条件：记录和分类。

其他

本文介绍的只是一个实现GTD的核心思想，但是并不包括全部。还有许多基于此的应用场景、和变通的方法（如邮件管理、内容管理、工作项目等等），本文不做过多介绍，会在日后相应的机会下可能有所介绍。

使用GTD后一段时间的感受：好的工具能够提高你的效率，但是世界上没有最好的工具，因为总会有新的思想来创造出更好的工具，摆脱工具控的限制，用知识来充实自己的思想。

这里给出几个利用GTD思想进行管理的实例：

使用GTD思想进行内容管理

这里所说的内容管理是对知识体系的一种组织形式，是日常存放积累知识的体系，实现完整的内容管理和GTD管理类似，也需要一些特定的方法（比如通过云存储、云笔记、版本控制、文件管理等等）。这里不对内容管理的方面做过多介绍，虽然内容管理与任务管理是两个方面的内容，但是它们之间也并非没有联系，这里着重讲述如何将GTD思想应用到内容管理上。

在没有一个比较系统的方式管理我们积累的内容之前，这些内容可能会显得杂乱、无章，虽然也经常会进行定期的清理和组织（比如，对分类系统的重构、重新定义，将某些分类中的内容进行修改、或迁移等等），但是整理的过程比较耗时耗力，并且不同时刻整理之时采用的思路和策略（很多都是临时想到的方法）也可能有所不同，尤其是对于“非专业”的内容管理，每次整理后，之前整理的策略也很快会忘记，新的内容又会导致内容系统逐渐重新归于混乱，甚至整个知识体系的结构都会发生翻天覆地的变化。随着时间的推移，和越来越多的内容“堆积”，很容易让人产生疲劳和沮丧。

其实我们可以将这些问题归结为两点：

• 需要不断地完善更新这些内容的组织方式
• 需要一个好的方法来完善更新相应的内容组织方式

前者属于知识本身的结构化（成长）问题，它可能会随时间、以及我们每个人知识系统的不断扩充而变化，管理策略可以采用内容管理方面涉及的各类方法和手段；而后者属于任务管理的方面，对应的任务便是对内容的管理。内容管理和任务管理之间没有明确界限，其中又有许多相互交叉的方面，所以我们可以将任务管理和内容管理结合起来（任务管理为辅，内容管理为主）管理我们的内容。

随着我们知识内容结构的变化，可能不同阶段会需要不同的方法来管理内容，所以可以考虑选择一种相对固定的、不变的方法或思路进行“任务管理”，管理的任务便是“内容”，而管理的方式采用不同阶段涉及到的“内容管理”相关技术。这样，无论内容结构如何变化如何需要调整，由于更新内容所采用的“任务管理”手段相对固定，便能在已有体系基础上让一切有序的进行了。

随着对管理技术的深入实践理解，采用的管理策略也会更趋向合理。这里抛砖引玉，给出目前我采用的一种方式^_：

如果GTD管理体系本身就做为内容管理体系的一部分存于其中，例如为知笔记用来管理内容，GTD与其中内容管理共存，此时可将用于GTD的内容 分类冠以"GTD_xxx"，所有GTD相关操作都在该分类中进行。关键是要将内容管理和GTD管理区分开来，分类的作用也可以是区分功能，不再局限于内容属性（这里是普通分类名称上加上特殊前缀等等，用以该分类用于功能属性）。

“任务管理”方面

使用GTD方法将“内容管理”做为任务进行管理:

• 收集: 如果日常生活中，遇见有些内容值得记录至内容系统，那么及时迅速地将这些内容记录在某些固定的位置，先不用做更多处理。 记录的位置可以是事先设置好的一个内容管理默认分类，或者GTD中的收集箱，总之这样的地方根据自身情况只有几个，例如：手机中的便签、笔记中的“默认分类”或者“未分类”目录、收藏网页网址的工具、甚至是手动人为创建的“收集”目录等等，只要能方便、快速地将相关内容进行分享记录（例如通过手机中的“分享”菜单，电脑中的鼠标右键）即可。
• 整理: 闲暇之时（如公交车上、排队等待等空余场合），到之前“收集”对应的那些地方，将曾经收集到的来不及整理的东西一一整理到对应的合适位置上去。具体整理的策略可能根据内容管理的方式而有所变化，但是既然采用GTD方式进行整理，那么整理过程中也必然会在每个整理的子任务中包含“收集”、“下一步”、“稍后”、“将来也许”、“等待委派”、“取消”、“完成”这些类似的状态，将每个整理任务都走完这样的状态，便能有条不紊地让内容越来越趋于有序。具体方式需要在内容管理中才能解释的更清晰，这里不做过多介绍。

“内容管理”方面

采用多种方式结合，内容保证集中存放、便于访问、灵活通用、可移植，有一个或者两个主要的知识系统，其它做为分支和辅助。

内容管理应该属于和GTD时间管理“并行”的另一方面管理内容，比如“云笔记”（如为知笔记，麦库记事，有道，evernote，onenote，mynoteskeeper等）、“云存储”（如百度云，微云，Megalink等）、“本地存储”（存放一些私有数据资料）、“分布式版本控制”（如git本地存放私有内容，）、“版本控制系统托管服务”（github，bitbucket托管不敏感内容的git库）、“发布系统”（博客、Jekyll建站、Orgmode或Markdown便于分享的内容等）、以及其它（如便签、笔记、记事本、Pocket网页收集）等等。这里不过多介绍。

将GTD管理中产生的数据进行内容管理

这里介绍的是基于本文中提到的GTD方法，如何将其中的数据与内容管理系统衔接。

管理思路

在使用GTD方式处理日常任务时，一些的“已处理”状态中的任务，有些值得记录至自己的知识体系系统中，那么可以尝试一下这个方式：

• 如果该任务没有对应的回顾引用到它: 那么直接将它从GTD系统中移动（或复制）到知识管理体系当中，根据自己的情况选择移动还是复制。
• 如果该任务有对应的回顾引用到它: 那么不是将该任务内容简单移动或复制到相应笔记位置，而是将其复制到相应笔记处并添加一些引用信息，这样可以防止破坏原有GTD中回顾项目的链接。另外，最好也在GTD中记录一下复制到了哪里，下次更新之时，可以同时更新跟踪；同时内容记录之处，保留到回顾项目的反向引用链接。

操作的时候，最好不要让GTD系统的回顾引用到GTD以外的内容。

举例

例如GTD中，有一条已经完成的任务（单词任务），该任务有对应的项目回顾（单词任务），并且这条任务已经整理到内容管理系统中的某个位置，则可采用类似如下方式处理（实际只需在相应的“已处理”任务中添加整理至何处的信息）。

GTD系统项目回顾中对应的条目

1. 路径

   回顾条目路径为： 我的任务/GTD/#回顾/英语学习回顾

2. 内容：

   回顾条目内容如下:

   xxxxxxx
   阅读任务
   单词任务
   语法积累任务
   xxxxxxx
   

3. 注意：

   列出的任务可以是链接，但是显示的名字要与对应的任务名一致，便于在不支持链接的笔记系统中查找

GTD系统“已处理”状态中对应的任务：

1. 路径：

   任务条目路径为： 我的任务/GTD/已处理/单词任务

2. 内容：

   任务条目内容如下：

   已整理至：学习/英语/单词任务
   英语学习回顾
   XXXXXX
   

3. 注意：

   被整理至内容管理系统中的任务，整理之时，也在任务顶部追加“已整理至xxxx位置”之类的字样，最好名字也和实际笔记的名字一致，便于日后查找。

内容管理系统中对应的内容：

1. 路径：

   笔记路径为： 学习/英语/单词任务

2. 内容：

   笔记内容如下：

   英语学习回顾
   XXXXXX
   

3. 注意：

   在内容管理系统中，保留回顾链接，可以链接至GTD系统中的对应回顾条目。

使用GTD标签管理信息

对于有标签功能的系统、软件、工具，其中的信息可以通过这个方式来整理，整理只能使相应的信息趋于有序，而每次的整理不会受上次整理的影响也不会对下次整理产生影响，简而言之，如果想用这个方式整理，那么内容会更有序，如果过段时间不用这个方式了，整理了一部分的内容，也不会因为半途而废而导致信息更混乱。

GTD标签

首先理解这个概念，GTD标签，可以用来辅助整理信息，如果某条信息没贴GTD标签则表示没有被整理过，也即“收集”状态，贴标签的的表示内容已由GTD标签辅助处理过，状态就是标签对应指示的状态。

采用这个方法，需要信息所处环境支持标签功能，并且将信息所处的环境的标签看做有两类:GTD标签,以及普通标签。普通标签就是平时我们使用的标签;而GTD标签是从普通标签中预留一些特殊标签（如标题前加GTD_），用做该方法的GTD整理。只有普通标签不代表已由GTD法处理过，并且不能同时贴两个同一体系的GTD标签，只有GTD标签表示暂不关注整理的分类。

实现方式

这种方法的原则是：采用此法整理过的内容，一定存在GTD标签，没有GTD标签的，视为没整理过（即收集状态）。即没贴GTD标签的，就是没整理的，整理好后，若不用借助GTD标签可保持有序，则可以不再贴GTD标签，过段时间又乱了可以重拾GTD标签辅助整理。

GTD标签举例

• gtd_下一步
• gtd_稍后
• gtd_将来也许
• gtd_取消
• gtd_已处理

当信息已处理后（例如借助GTD整理好分类），可以只有已处理，或者同时有GTD标签和普通标签。这种方式适合无分类的信息管理，或者分类及标签混乱，但是还没应用GTD标签，借助GTD标签来管理内容。（例如pocket）

扩展

若分类大变，或者再次细化整理，则换一套管理思路，管理方式仍旧采用gtd方式管理.

例如丢弃之前的gtd标签，采用新的gtd标签：

• gtd方式2_下一步
• gtd方式2_稍后
• gtd方式2_将来也许
• gtd方式2_取消
• gtd方式2_已处理

这样扩展之后，就算之前应用过GTD标签，如果想换一条整理思路，那么重新换一套标签就行了，之前的标签忽略即可。

建议软件能显示所有未贴标签的内容。
建议能修改标签名。
建议能批量加标签。
标签和分类的区别是先有文章后有标签，但先有分类后有文章

关键

使用该方式，最好相应的环境能支持如下功能：

• 能显示所有未贴标签的内容。
• 能过滤显示出没贴特定标签的内容（如没贴GTD标签，却贴了普通标签的分类）。
• 能修改标签名。
• 能批量增、删改标签。

使用GTD方式管理邮件

如果是采取GTD方式管理自己的工作方式，其中邮件中的内容处理之后，可过滤到GTD系统中。而对邮件，也可采用GTD类似的方式来进行过滤，这样自己的GTD管理系统像是分层的一样，但是不宜过于复杂。

实现思路

大多数邮件客户端都有标签显示的功能，基于此，我们可以先定下如下规则：

未贴标签的邮件，就是杂乱的不重要的邮件，而贴了标签的邮件，是需要关注的。

实现举例

设置如下类似GTD的系统标签：

• 未读邮件: 类似GTD中的收集，这个状态在一般邮件客户端中都默认存在，所以并不对应什么标签名称，需要特别注意的是，收集是未读状态的无GTD标签邮件，而非无GTD标签邮件，这样保证收集的邮件不至于堆积。
• 下一步: 该标签表示还来不及读取，只是通过标题等能确认是重点邮件，读取之后会变成后面的对应分类。类似GTD的“下一步”，需要过后进一步处理的邮件，这个分类的内容在整体中应该不多，处理后去掉标签或迁移到其它标签中，或重要邮件放到合适的位置、或者标签已办事项中。
• 稍后: 相对下一步，可以稍后延缓处理的邮件。该标签邮件的处理方式类似前面，对应于GTD的“稍后”状态。
• 将来也许: 不确定是否会用到，看起来像是重点，先堆积到这里。该标签邮件处理方式类似前面，对应于GTD中的“将来也许”状态。
• 等待委派: 委派给别人处理或等待回复。该标签邮件处理方式类似前面，对应于GTD中的“等待委派”状态。
• 已经处理的相关标签: 已处理邮件，不用贴上“已处理”标签，将其相应的GTD状态标签去掉即可，一般是已读的、未贴GTD标签的邮件，如果邮件比较重要，则建立一些根据自己情况的分类来重点存放。例如
  • 开发注意: 本项目发布，开发过程中的一些注意事项。该标签邮件处理方式类似前面，对应于GTD中的“将来也许”状态。
  • 项目文档: 项目开发、管理、会议、讨论等中发布的一些文档
  • 开发技巧: 日常开发的一些小技巧、说明等。
  • 通用技术: 一些比较通用的，不仅限于当前项目的技术内容，可以日后进一步学习或者有长远的作用的内容。
  • 公司事务: 一些公司事务信息，如人力资源相关、薪资、一些注意事项说明、出差、报销、福利等。
  • 重要信息: 暂时没有办法分类，但是感觉需要终点关注的邮件，比如阶段性的进展或者计划等。

另外，有些系统中可用添加星标的方式标注邮件，这时候，一些临时性有期限的阶段重点可以用星标标注（比如上次release到了哪个版本，这次应该从上次的开始，那么每次release的时候为其添加星标，下次的时候就不会为了一个上次版本号，海量搜索所有邮件了），便于近期跟踪，相对重要信息，这类邮件的生命周期较短。

这样处理邮件后，处理好的内容（转移至其它系统如GTD系统中继续也表示邮件处理完了）‍，要么就是添加上合适的标签，要么就是去掉标签表示不用关注。但是如前所述，如果感觉处理后还是很重要，那就加上星标。或者放到一个“重要邮件”的标签中。

不同的客户端可能显示标签的方式不同，例如对于outlook，为了便于分类显示邮件，我们可以建立一个基于标签的搜索目录；而对于thunderbird，我们可以直接通过将标签添加到快速访问栏过滤显示；等等。
其实添加标签后，标签基本上就可以预示分类了，但是如果标签感觉不是十分牢靠（可能一不小心点一下，就没有标签了）所以一些重要的没有过时的东西，可以按照意愿自建目录，转移到特定目录中。

使用GTD方式管理工作文件

有时候我们处理问题不一定全部在某一个GTD系统中进行，期间可能会涉及到访问电脑文件系统的相关操作。对文件系统采用GTD的方式管理，能避免文件系统的内容因文件杂乱导致的混乱。

思路

类似前面讲述的GTD标签的方式，我们可以创建一些GTD分类，将需要处理的资料流经这些分类最终归并到其他的合适的普通分类中。

比如，查看邮件时，发现一个待处理的问题。这封邮件中包含一些附件，比如处理问题时参考的文档、处理时的日志、以及测试报告、测试程序；处理问题之时，又可能会查阅其它地方，将其它相关参考资料整理至本地（比如上网下载一个处理该问题的软件或者数据文件）；甚至会自己写一些文档记录当前处理的内容，比如设计文档、流程图、设计图等等。这些内容如果很多，那么可能会将自己的文件系统搞的乱七八糟。

显然目前似乎也很难将这些内容的管理集成到现有的GTD系统中，或者也可以集成，但是需要再为现有的GTD系统添加一些额外的处理方式（这个方式可以因人而异，这里也不做介绍，可能将来会给出一套方案来解决这个问题）。如果我们不愿意花费精力将自己的这个GTD系统弄得很庞大复杂，为简便起见，我们可以给出一个折衷方案，自己习惯的方式，直接将相关的内容在本地文件系统中进行操作，但是操作之时，对文件系统采用GTD的思路划分。

实现举例

比如，我们给自己的文件系统划分为如下GTD分类目录：

$ls -p
1_inbox/  3_later/  5_maybe_future/  7_cancel/ 
2_next/   4_wait/   6_done/  readme  ...

目录内容如下：

• 1_inbox/: 用于将所有处理问题过程中临时下载、获取的资料集中在这里存放，内容不能堆积要及时整理到其他目录。
• 2_next/: 在整理文件系统时，将正在进行工作所需的资料汇集至此，不同内容可处于不同子目录中。
• 3_later/: 在整理文件系统时，需要被推迟的事情所涉及的资料汇集至此，不同内容可处于不同子目录中。
• 4_wait/: 在整理文件系统时，由于等待而被阻塞的事情汇集至此，不同内容可处于不同子目录中。
• 5_maybe_future/: 在整理文件时，将不重要的以后可能会用到的资料堆积在这里，不同内容可处于不同子目录中。
• 6_done/: 在整理文件系统时，已完成工作相关资料暂积于此，这里包含各种完成任务所涉及资料，将来可能进一步整理。
• 7_cancel/: 在整理文件系统时，将取消的任务涉及的资料都汇集到这里，将来可能会被清理。
• readme: 对当前处理的目录结构的进一步说明。
• 其它目录: 任何自己定义的目录。与以上GTD分类不冲突，GTD分类做为过滤，采用GTD方法，经过前面几个GTD分类的过滤（状态切换后）后，最终整理好的资料可以汇集于其他自己习惯的目录中。

使用GTD方式管理网址收藏

有时我们需要有一个类似稍后阅读的需求，比如，看到某一个网址，把它添加到收藏夹中，将来再浏览。这个和稍后阅读有些类似，但是同时也具有收藏网址的目的。

思路

类似前面讲述的GTD标签的方式，我们可以创建一些GTD分类，将需要处理（稍后阅读、或者收藏到指定目录）的网址流经这些分类最终归并到其他的合适的普通分类中。

实现方式

在你常见的收藏夹中，这里以firefox的书签为例。firefox书签支持层级目录。

首先创建好你的普通书签分类（因人而异），以及一个 gtd 的书签分类。

在gtd分类中建立各种gtd分类，例如： 1_inbox, 2_next, 3_later, 4_wait, 5_maybe_fure, 6_done, 7_cancel.

然后，在想要系统性浏览阅读网站的时候，把它添加到合适的 gtd 目录中.

阅读完毕后，如需收藏网址，则在 6_done 的gtd分类中将其转移到普通书签分类，完成网址收藏。

杂乱

任何经验知识等叙述到一定程度，总有一些无法具体归类的杂项内容，哪怕是某方面知识体系中的一小部分，也很难一下子把所知以及真正的内容全部完美的表达出来。本文也是如此，所以在这里列出暂时堆积一些无法放置的，可能有待进一步整理也可能不会再整理的内容。

任务状态

GTD系统不是一成不变的，但是大多数GTD系统，应当具有如下几个类似的状态：收集、下一步、将来也许、已完成。

• 收集箱: 用于快速存放所有临时想到的任务，有时间再将其进一步整理，细化任务属性，但是其中内容不要堆积。
• 下一步: 便于集中精力，只存放当前处理的任务，其中内容不要过多。
• 将来也许: 任务堆积的地方，可能做可能不做又不想遗忘的、没处理的任务，都可以先堆积在这里。
• 已完成: 已完成的任务，做为备份或归档，可能将来回顾或进一步组织整理。

任务属性

除了前面的任务状态，根据所处环境、工具与方法的不同，GTD任务还可能具有的属性也有所不同。比较基本的有任务所属的“任务名称”、“项目分类”；有时候根据情况还需要其他扩展的属性如：“场景”、“开始/结束时间”、“是否重复”、“提醒”、“备注”、“优先级”等等。

不同属性具有不同用途，实现方式也不同。

比如：“项目分类”和“场景”可能用分类目录或者标签的方式来实现，如果采用分类目录，需要注意此时与状态分类并不冲突，因为分类不仅是对内容状态、属性的分类，也是对任务场景的分类。任务的“项目分类”一般在回顾的时候会经常用到；任务的“情景”一般在处于不同场合的时候用到（如@家里、@办公室、@外出等）；这些一般都可根据个人习惯进行设置，只要便于快速过滤到适合该情况下需要关注的任务即可。

又如：“开始/结束时间”、“是否重复”、“提醒”……这类时间相关的信息，可能根据软件场合的不同也有不同的实现。比如Orgmode可以用时间戳和SCHEDULE属性等来标记这些信息等等。而有些工具在特定的时候，又可能会根据时间信息，对任务进行自动的处理，比如将任务贴上标签，设置好起始结束日后，过期或者特定时间，自动将任务移动到特定的状态或项目等分类中（有许多GTD管理工具中都有一项”今日待办“之类的分类就类似如此)，或者反复提醒。对于简单的GTD管理，如记事本方式，可能就很难直接实现这类根据时间有所动作的任务管理。

任务性质

如果对任务，需要时间方面的属性进行辅助管理，这里给出一些经验性的建议：

• 提醒: 不用什么都设提醒，必须在指定时间做的事情，或重要的事情才值得提醒；提醒的功能可以任找类似闹钟功能的方便软件辅助即可（如中华万年历），不用必须集成到GTD中实现。
• 日程: 有些任务虽然不需提醒，但是也对时间比较敏感，比如今日待办，明日待办，指定日期代办，将来待办等，虽然有些并不一定是要执行，但是都有一个期限，有些工具在日历中会将其标记出来。
• 待办: 对时间不敏感的任务。有些任务对时间信息不是很敏感，或无法指定究竟什么时候需要做、需要完成，但是能确定的是它应该被做，这类任务可以称为待办。

前面所述的，是对任务性质方面的划分，并不是必须的分类方式，这里真正做了划分的，我们在GTD中看到的各个任务的状态，大多状态的任务都具有以上之一的性质。对任务性质进行这样的划分之后，一些比较让人迷惑的概念应该比较容易澄清了。

例如：日历、提醒、备忘、日程、待办……这几个概念经常在叙述的时候出现，如果不对其专门规定和提取，有时候连自己都会对其比较迷惑。经过上面的性质划分之后，我们可以这样理解：“日程”就是有时间安排的任务，它可以在“日历”中被标记出来。“备忘”有些是需要提醒的，有些不用“提醒”只要做为“待办”即可。

优先级划分

任务都有一个优先级的问题，有一个为任务优先级分类的方式：四象限法则。该方法不具体介绍，大致是将任务按照“紧急度”与“重要度”划分为四个象限：

• 第一象限: 重要不紧急

  需要制定计划，按时完成的内容，是最重要的事情，它可以帮助我们进入良性循环。建议占用约65%-80%的精力。

• 第二象限: 重要且紧急

  需要优先解决，这也是没有经过适当计划的内容，可能因为之前的安排不合理，导致一些任务从第一象限随着时间的推移被迁移到第二象限，可能导致我们无休止地一直在“瞎忙”。建议占用约20%-25%的精力。

• 第三象限: 紧急不重要

  会让我们产生“这事很重要”的错觉的事件，实际上其实事件只是对别人而言很重要。建议占用约15%的精力。

• 第四象限: 不重要不紧急

  浪费时间的事情，如果可能，交给别人去做。建议占用<1%的精力。

劳逸结合

划分任务状态很大一部分也是为了集中我们的精力，将处理任务时精力集中在下一步，回顾时精力集中在任务的划分等等。而真正在处理任务之时，精力不一定能保证一直集中；集中过久又可能会导致之后的处理效率低下。所以可以考虑番茄工作法来改善这样的状况。

番茄工作法是一种相对于GTD更微观的时间管理方法。大致如下：
将每次做事情，比喻成番茄，休息和番茄交替进行。大致如下原则：

1. 一个番茄时间（25分钟）不可分割，不存在半个或一个半番茄时间。
2. 一个番茄时间内如果做与任务无关的事情，则该番茄时间作废。
3. 永远不要在非工作时间内使用《番茄工作法》。（例如：用3个番茄时间陪儿子下的棋、用5个番茄时间钓鱼，等等。）
4. 不要拿自己的番茄数据与他人的番茄数据比较。
5. 番茄的数量不可能决定任务最终的成败。
6. 必须有一份适合自己的作息时间表。

通用的方式是：每个番茄25分钟，休息5分钟，但是也可根据自身情况而定。工作时准备好一个定时器，每次过一个番茄，一定休息，休息完毕，就下一个番茄，每次休息和番茄之间，通过定时器来提醒，防止“越界”。

回顾的解释

如果某项任务比较复杂，处理完毕后，最好能有一个汇总的文档，整理期间处理的情况，类似索引。便于以后参考引用，以及追加索引处理更新情况，也可能没有用处，这就是一条回顾，也是项目。

回顾最初可能是以任务的形式出现的，将任务处理到一定程度后，发现其中可以划分为许多子部分，而最初的“任务”可以用来做为一个回顾索引，来引用到处理任务时涉及的的各个子部分。这个时候，“任务”就变成了“回顾”，将新建立的回顾放在相应的“回顾”分类中（如“活跃的回顾”、“普通的回顾”等），之后的处理全在“回顾”以及其引用的相应的任务中记录和复习，并不是说进入到“回顾”中了，就相应的条目就不能更新了，回顾是对项目的划分，这里存在的是项目而非任务，回顾并非任务的终结状态，它是一系列相关任务的处理情况记录和索引，便于今后理解和参考。

管理回顾的经验

这里有些，可以借鉴，不是必须的：

• 回顾可能没有结尾，但是一定条理清晰，便于追加编辑，和索引。
• 每条回顾中可能包含多条对任务的索引，索引内容不能太多，更多相关的内容可以在该索引对应的链接内容中体现。
• 每条回顾对应一个项目，不同的回顾代表不同项目，每个项目是对相关任务的汇集。
• 并不是所有的任务都需要回顾和汇总，一些单一简单的任务，其本身处理完放入到已处理中，本身就可当作回顾。
• 回顾中索引引用的任务或者内容，最好和相应的任务或内容对应的笔记的题目一致，以便于在无支持链接的情况下移植。
• 回顾和所引用的任务之间最好能够交叉引用。创建相关任务的时候，首先将回顾的链接附上。等待任务处理到一定程度之时，可以重新命名一个好的标题，然后再将任务链接贴在回顾中。
• 理想情况下，回顾中只包含相关的任务标题链接，有时候实在需要进一步说明，也可在回顾相应的索引链接处中给出一些提示性的内容表征任务的大致情况。
• 如果回顾对应的项目仍需继续，那么就不要将相关的所有任务清除为已处理，以免丢失对任务的跟踪。也就是说，没有完成，或达到一定阶段的项目，要保持其中有一项未完成状态的任务(例如长时间不做了，可以将其设置为推迟、将来也许、甚至不了了之的任务确认后放入取消)。
• 活跃的回顾是指当前进行的项目，随着项目的进行可能会在其中不断衍生出新的任务，例如一些重复性的任务，如“周报”，一般每周都要写，短期内不会终止，所以它可被看作一个活跃的项目。
• 回顾所引用的一般是处于各个状态的任务，不一定只有任务，也可能是其他的回顾，但是一定是GTD系统中的内容。
• 回顾的内容与回顾所引用的内容应该能相互引用，便于参考时的跳转。

关于参考

参考既不是任务，也不是回顾，但是它又处于GTD系统当中。它主要是在回顾，或者处理时不是中间任务性质的半参考文档性质的内容。例如导致接收任务的邮件片段、期间的交互证据、网址文献等等。按理说应该有相关的时间、地点（可以是email地址）、人物、事件（起因/经过/结果）。在目前看来，参考在本文所述的GTD中可以被去掉，归并到已处理分类中，但是也可根据个人需要与喜好单独列出来一个分类用来管理这些内容。

如何处理“回顾”、“任务”、“参考”的关系？

• 任务是可以执行事情的分割单位，其中包含处理该任务是的一些总结性质的东西，是深入处理相关任务时做的杂乱记录。
• 回顾是对一系列相关任务的汇集整理，本事就是一个项目，整理任务处理期间的关系以及处理的大致情况和索引，便于今后跟踪和参考。
• 参考可能是回顾会引用的，或者是任务中会引用到的一些资料，例如导致接收任务的邮件、期间的交互证据，网址文献等等。

如何处理“项目分类”与“状态分类”实现的冲突

先给出问题，在列出思考实现的过程，最后给出采用当前的方案的原因。

正常收集过来的任务直接放在收集箱，进行进一步处理之后放在相应的项目分类中，随着时间的推移再进入到下一步状态，但是该任务仍然属于之前所设置的项目分类。也就是说，任务的项目分类是不变的，状态却可能随着处理改变成其它状态（如下一步）。任务的状态是以目录形式存在，所以对于项目分类的管理方式如果也以目录的方式管理可能就导致目录混乱。

考虑到项目分类是随时间动态增长的，而目录分类不宜过多；相对的，标签是文章之后动态创建的，将项目用标签表示可能更灵活好用一些；或者在每一个状态目录中建立子目录表示项目，或者使用标签来实现对任务即可用状态的角度来分类，又可用项目角度来分类……然而，这些方式都会到至笔记的分类复杂，并且并不是所有的工具都支持标签。

前面的局限在于，认为分类只能是对同一角度内容的分类，所以将项目和状态同时用分类来表示的时候，会混淆。当前采用的方式将状态和项目全都用分类来表示，但是分类不是在一个角度上进行分类，可以是管理状态的分类，或者管理项目的分类……不同方面，有各自的分类方式，可以用分类名前缀，或者自己的习惯来理解不同的分类方式就行。这样，将“分类”进行分类之后，不同方面的分类可以存在于同一个笔记系统中，就不会引起混乱。它是，对于项目这类变化比较大的（基本是只增不减）内容，采用分类又有些不妥，所以项目干脆用笔记来表示，每个项目分类只是一个笔记，然后将所有项目归结到项目状态中。

自我管理的演化过程

随着时间的过去，我们从学校进入到职场，从个人变成了组建的家庭，所处理和面对的事务也变得越来越复杂。如果不做合理规划，工作、生活、学习各个方面会变得越来越糟糕。
希望能有一个高效的生活方式的我们，可能会经历如下的管理过程阶段，希望能给大家一个参考。

记事本阶段(笔记本子，或者Windows上的记事本，博客等)

将平时涉及的一切写到一个记事本中，可以是电子版的，或者纸质的，也有时候为分享和方便记录到博客等网络平台中。在随后的讲述中我们会发现，这些内容渐渐变得越来越复杂分散，简单的记录已不再适应。

待办清单与文档（任何设备、系统上自带的工具）

记事本，可能包含了能够记录的一切，但是其中记录的内容各不相同，而且数据量越来越大，我们真正所需的，其实是在适当的时候将其提取出来，总结起来发现大致有两类事情：

• 一类是平时记录的技巧、经验、资料、文档等等
• 另一类是影响自己行动的计划、待办事项、约会、提醒等等。

于是产生了两种方式的记录：待办清单和文档。

• 待办清单: 其实是行动管理的雏形。罗列了需要处理的事情，需要进行某些事情的时候，浏览一下这个清单，处理完将其划掉，日常的生活在清单不断地增减中度过。
• 文档: 其实是内容管理的雏形。那些经验、技巧、文档类的内容，被整理至某个笔记系统或目录结构中，为不同的内容建立相应的分类，分门别类存放，需要之时直接到对应地方查阅即可。

在任何我们手中的系统和设备中（比如手机的Android和IOS、PC的Window和Linux等等），总有一款待办清单方面的工具，以及笔记记录方面的工具，供我们这时所需。

丰富的待办清单与文档系统(中华万年历与为知笔记)

随着时间迁移，在待办清单和文档，终于有一个像样的名称，内容管理和行动管理。

• 行动管理方面

  待办清单变得越来越长，往往想确定下一步做什么的时候，需要先浏览一遍长长的清单，然后找到需要的内容，于是产生了对待办清单改善的需要：需要一些新的工具，或者在原来的待办清单上改善和扩展。一是添加提醒，一些事情到特定时间后自动通过闹钟或者其他方式提醒我们去看，手机、电脑上有许多类似的工具；二是划分优先级，那些待办事项中，总有一些是重要的、一些是不重要的、一些是过时的等等，四象限法则就是一个划分优先级的好方法，在我所用过的工具里，中华万年历是这个时候不错的选择，它还附带了一个简单的云笔记功能。

• 内容管理方面

  总是觉得之前的分类变得越来越复杂，文件系统越来越乱，内容越来越多，并且分散在各处（手机、电脑等），都有不不同的文档系统，而且有时候想要记录的时候，东西不在身边，当有现成的环境之时，却又想不起该记录什么了。这需要对内容管理方式有一个改善，改善分类的方式，让分类简单；增加记录与访问的便携与集中性，比如各类云笔记（麦库、有道、为知、evernote）等等可以随时记录访问，也可根据需要的内容，搜索检索相应的笔记，根据我的经验，为知笔记在这个方面做的非常不错。

轻重结合(轻量级的系统便签或笔记工具、与为知、中华万年历)

在管理内容和行动方面的信息的同时，不断寻求新的更强大的工具，最终会感觉到，自己的手机、电脑、越来越慢，访问所需的等待时间往往超过了我们的忍耐限度，为了临时记录一点东西，我们可能会花费1、2分钟的时间启动我们的系统和软件，启动的时间内，我们往往可能已经能够把相应的事务处理完毕了。

这要求我们对所管理的信息有一种便捷的访问方式。各类系统平台上一般都会有那么几款轻量级别的记录工具，记事便签、记事本等等，再添加上分类的功能使之不要过于弱。重量级和轻量级工具同时使用，我们经常访问的信息就存于轻量级别的工具中，空闲之时在重量级工具与轻量级工具之间同步数据。

需有体系的信息管理组织方式（GTD与Git）

便携性意味着功能的减弱，功能强则会减弱便携性。两者综合起来应用，又会涉及到同步和数据移植行的问题。这时候管理信息已经不是工具方面的问题了，而是方法和存储。

1. 采用的方式：

   • 行动管理方面: 方法是GTD方法，为所有任务定义好状态。工具则任意款便携、可移植的工具即可。
   • 内容管理方面: 原生文本格式方式增强数据移植性；Git分布式管理增强便携安全与版本控制；用现有大型网站托管资料（如github、bitbucket等等）增强集中与同步性。

2. 数据格式、访问、存储与管理方式

   工具可以尽量简单，方法选择适合自己的方法，而数据的格式也是一个问题。如果做过软件开发的人，可能会觉得，这有点类似软件中的MVC方法问题（M是数据模型、V是数据访问视图、C是数据控制方式）。

   1. 数据格式-Orgmode

      为了便于将来环境的切换，数据存储的格式是一个比较重要的内容。

      • 文本格式: 实践发现，最通用的数据格式不是.doc、音视频、图片、pdf、或者各类笔记专有数据格式等等，而是文本，文本格式也便于版本控制管理。

      • 标记语言: 对于文本格式，xml、html就是文本标记语言，latex也是，但是通用性强了、可阅读性也必不可少，这些文本格式对于非专业人员，几乎是天书般的存在。

      • 轻量级标记语言: 各类轻量级的标记语言如markdown、orgmode等等，可以做为数据存储的格式，学习成本也低、而且文本的数据格式也便于直接阅读。

      • Markdown与Orgmode: 学习成本太低，便意味着功能的有限，反之亦然。

        markdown的学习成本很低，相对orgmode更流行，但是若用它写复杂的文档，还是有些勉强只能写一些简单的博客性文章；orgmode是这里极力推荐的方式，它可以变得很轻量级，但是如果你多学习，它又能变得非常强大，既能内容管理，又能行动管理，还能导出为其他各种格式远不止于此。

   2. 访问方式-工具控

      总结起来，这个阶段，工具不是重点，Emacs、Vim、记事本、任意一款可以编辑的工具都可做为数据访问的方式。

      如果只考虑工具，又不想自己主动耗费精力思考方法，降低学习成本，这个阶段有两个工具建议可用：

      • 行动管理: 采用dgt gtd，安卓下的工具，可以导出数据，并且便携记录。
      • 内容管理: 仍然采用为知笔记。
      • 做为辅助: 对访问速度要求高时，可以用系统上的任意便签工具做为中转。

   3. 管理方式-GTD与分布式版本控制

      方法才是核心，管理方法往往说起来很简单：GTD管理任务，Git分布式管理内容并版本控制，当然肯定也会有其它的方法或者分布式管理。

3. 总结

   总之，如果用最直接的方式来描述一个特定的管理方式，目前而言，我采用的方式是：

   • emacs的扩展性满足了工具控的需要，可以当作任何想到的工具访问数据；
   • markdown和orgmode这类文本标记语言相结合，表示数据，使之符合人阅读的原生文本格式，orgmode还能方便转换为各种其它格式；
   • 任意款分布式版本控制工具（比较流行的是git）可以当作云存储与管理内容的方式;
   • gtd方法做为灵魂，做为管理行动的方式（管理数据的组织方式也是诸多行动的一种），

   其它一切都是浮云。

其它

前面的过程，其实总结起来，可能是这个样子的：杂乱的信息-任务管理/内容管理。

当管理达到一定阶段，满足现状的时候，还可能会发生其他的事情，比如，数据、工具、方法都有了，我们要做什么？

也许，下一步就是目标管理了吧？因为我也听说过SWOT方法、5w1h方法等等，又或许，还需更好的方式在组织这些。

留给未来的自己

• <span class="timestamp-wrapper"><span class="timestamp">[2019-04-23 二 17:30] </span></span>

  这个文章写完至今，已经将近4年了，期间学了不少相关的知识。
  当时觉得自己学了很多，会了很多（毕竟使用GTD的人，还不多），现在一看不过入门的程度。而且还有很多有待完善之处。不过这个文章还是对走在GTD之路上，有价值的。
  
  一言难尽，简单总结几句。
  1. 它会帮你从直观上了解，什么是GTD，以及使用GTD的大致方式。
  2. GTD五大流程：收集、处理、组织整理、回顾、执行。它基本上解决了其中的收集、部分解决了处理（状态方面）
  3. GTD的特点是，你学了一部分，就能开始实践它，在实践中一边完善，要走的路还很长……
  

参考资料

一些值得参考的一些文章：

褪墨・时间管理

http://blog.sina.com.cn/s/blog_6495e9c90101evo7.html

http://www.mifengtd.cn/articles/gtd-grab-the-destiny.html

WAIT/FORWARD FAQ <code>[0%]</code> <code>[0/4]</code>

• State "WAIT/FORWARD" from <span class="timestamp-wrapper"><span class="timestamp">[2016-06-12 日 17:16] </span></span>
  wait for all done.

NEXT 如何通过orgMobile进行管理？

• State "NEXT" from "INBOX" <span class="timestamp-wrapper"><span class="timestamp">[2015-12-30 三 09:40]</span></span>

INBOX 回顾与完成/没完成任务之间的引用

Capture Time:<span class="timestamp-wrapper"><span class="timestamp">[2016-05-25 三 10:30]</span></span>

回顾的内容，没有完成的可以用链接的方式将任务与回顾相互引用，任务完成之后，可以考虑将其直接集成到回顾中，不用链接，防止过于分散。

如果过大过复杂的内容，或者没有办法很好的组织的内容，可以用链接的方式对其进行关联。否则就尽量不要使用链接，使用链接的内容，都是没有弄完的内容，弄完之后把链接去掉。

NEXT 六个高度、5w1h=时间地点任务，起因经过结果

• State "NEXT" from <span class="timestamp-wrapper"><span class="timestamp">[2017-10-13 五 09:38]</span></span>

NEXT 任务的状态、场景、和分类、参考资料等。

• State "NEXT" from <span class="timestamp-wrapper"><span class="timestamp">[2018-02-01 四 14:19]</span></span>

分类、场景、标签、状态；待办、提醒、日程、任务、记事

分类

任务的分类，确切的说是标签，用来描述任务的属性，因人而异，标签比分类更灵活，因为标签不是层级的而是图形的，而且随时添加，一个任务可以属于多个标签，却只能属于一个分类。而场景，是另外一种根据现状的分类，尤其是下一步任务，不象日程提醒这样有时间闹钟的辅助，下一步的任务对时间要求是尽快而非精确，积累多了，提示下一步任务的信息就是相应任务的执行场景，比如“在家”就关注只能在家里执行的下一步内容。

简而言之，分类因人而异。可以用两极分化的思想归结为两个方面：现实和思想。场景是当下状况的现实分类，是亲临实境的现实；标签是根据每个人经历的印象分类，是思想内容的组织结构。而这两者通过任务的状态相互关联，每个任务的状态转换，是将任务从思想变为现实的过程。

待办

我们可以将待办事项看作包含：“提醒”（精确时间做）、“日程”（精确日期做）、“任务”（尽快去做）、“记事”（前面的参考资料，不用做是提示信息或文档）。

“提醒”和“日程”，

可以用闹钟来提醒，防止遗忘。

“任务”

又包括各个任务状态。

1. 分类

2. 其中“下一步”状态需要通过场景提醒

   我们可以将场景看作执行“下一步”任务时的提示信息，以防遗忘。因为“下一步”的任务，没有像 “提醒”、“日程”这样的时间闹钟辅助，所以我们将任务转化为下一步的时候，一定要确认好它的场景，没有场景的，就只能在每次各个场景回顾的时候同时都回顾了。

3. 其他状态

   其他状态的内容，是通过周期性的回顾结合标签来组织，以防遗忘。因为它们没有闹钟，也不一定用“场景”来辅助。但是我们可将标签抽象为项目，里面包含多个任务。实在关联性太强的各个任务，可以考虑用层级的方式归集到一个清单中。

记事

记事是捕获到的，不是可以执行的内容，一般归结到“参考”状态中，只起到提示、参考和文档的作用。将来会转存到其他文档系统。

任务的状态中，如果记录的不是任务，而是提示性的内容，应当放到参考里面，而非将来/也许。

简而言之，任务的gtd系统，通过"参考"和文档系统关联上。