要点
1. 项目可以按照时间段来拆分；
2. 上下文可以通过我们会处在的情境或场景来划分；
3. 项目里可以通过创建文件夹的方式来管理子项目；
4. 定期将收件箱里的待办事项分类到适当的项目和上下文里
上回说了一句，点开收件箱，会看到自己记录下来所有的待办事项。严格来说并不准确，收件箱里看到的，是那些我们快速记录的，尚未分类的事项。所以这回，就来总结一下对清单事项的分类。
理念
OF之所以强大，是因为我们可以给一条待办事项设置项目和上下文。这么说可能比较抽象，那换种说法，就是我们可以从时间和空间两个角度给一个事项分类。
项目是一条事项的时间属性，上下文是一条项目的空间属性。
需要说明的，时间和空间的说法，是我学习参考了很多时间管理达人在使用OF时设定的一种形象的描述，不是在这里下定义或是硬性的规定。通过一段时间的使用发现，这样的分类设定，很是合理。所以接下来对项目和上下文的说明，也是基于此。
项目（Project）
项目是待办事项的时间属性。我们可以这样理解，一条事项，我们期待它在哪个时间段完成，比如最近一两周，或是一两个月，亦或是半年、一年……
这里用的是时间段，而不是时间点，因为前一篇文章也说了，清单是用来管理那些对时间要求不严格的事项的。
所以拆分项目，也就有思路了，比如：
· 2周内
· 3个月内
· 1年内
· 1~2年
· 将来
项目还可以继续拆分子项目。很多事情并不急于（两周内）去办，所以它们可能会集中出现在“3个月内”的项目里，我们可以再细化一下分类，比如“3个月内”的子项目，我是这样设计的：
· 公司项目
· 非公司项目
· 个人成长
· 学习：个人成长
· 学习：技术提升
· 学习：阅读
可以按照自身实际需求设计和取舍。
上下文 / 情境（Context）
这个词，我更喜欢翻译为情境。事实上，如果听过叶武滨老师讲座的童鞋，对情境也应该更为亲切吧。情境的叫法，也赋予了一些空间感。不过既然app上叫上下文，我们也姑且如此称呼它。
怎么定义上下文呢？
就是我们在如此的情况、境遇或场景下，可以去处理的那些待办事项。
比如我在公司，那我可以检查一下“公司”这个上下文里的待办事项，有哪些可以着手去做；如果我要去打电话，那我就看一下“电话”这个上下文里，还有哪些电话可以顺便打了。
上下文（情境）通常可以这样设计：
· 电脑——那些需要在电脑上处理的事情
· 智能设备——在手机、平板上处理的事情
· 办公室——在公司处理的事情
· 在家——在家处理的事情
· 电话——需要打的电话
· 授权/委托——还记得4D原则里的delegate吗？可以交给别人办的事情
· 碎片时间——没有什么特定的情境，随时可以办的
当然我是按照我的工作生活设计的，还是要从简，不要设计过多的情境。比如不是特别依赖电脑的工作，可以把电脑和智能设备合而为一。
总之，项目和上下文，都不要过度设计，依照自身，刚好最好。
一条事项的两个属性，基本上介绍完了，下面看看怎么操作。
具体操作
打开app，这次让我们关注项目和上下文。
创建一个项目
点击项目，进入项目列表。
如果是第一次使用，这里面会有OF内置的一些项目，我们可以删掉它们：按住一个项目，向左滑，之后点击删除。
删除掉那些没用的项目，上下文也如是
上边有个加号，点一下会出来三个选项，我们先从“新建项目”开始。
新建项目的界面，看着有些复杂，但是我们只要操作三步：输入项目名 - 选择单个动作 - 存储，其它内容，依旧保持无或原状。保存后会返回列表，并多出了刚刚创建的项目，比如我列表中的“紧急事件（2周内）”。
可能有朋友会问，类型是什么？为什么要选单个动作？这个问题最后解释。
创建一个文件夹和子项目
前面说了，一个项目还可以创建子项目，那前文中的“3个月内”就是一个文件夹，我们看看如何创建。
还是项目列表，还是那个加号，这次我们选“新建文件夹”。这个简单，输入文件夹名，点存储就可以了。之后会返回项目列表，并多出了刚刚创建的文件夹，比如我列表中的“着手（3个月内）”。
点击进入刚刚新建的文件夹，便可以在这个文件夹下创建子项目了。创建方式和创建一个项目一样。
文件夹可以很好的帮我们管理中短期的项目
按照前文中项目的拆分思路，重复这几个操作，就可以创建出我们想要的项目、文件夹和子项目了。
创建一个上下文（情境）
回到app主页，点上下文，进入上下文列表。
点击右上那个形状奇怪的按钮（编辑左侧），开始创建上下文。步骤也很简单：输入上下文名字 - 存储。之后会返回上下文列表，并多处了刚刚创建的上下文（情境）。
前文介绍了上下文的设计思路，如此重复操作，便可以创建出我们所需的情境了。
接下来做什么
当然是给待办事项分类了。
回到app主页，进入收件箱，现在可以清理一下收件箱里的事项了。
点击一条事项，会打开这个事项的详细信息，界面和我们收集时创建一条事项的一致。这次我们操作项目和上下文。很简单，分别点击项目和上下文，然后选择合适的内容，就可以了。编辑完，点击左上角的收件箱，返回。
这时我们会发现，收件箱少了刚刚编辑的事项，可以去它所属的项目或者上下文中找到它。重复这样的操作，直到收件箱被清空。
到现在可能会发现，在我们新建一条事项的时候，可以直接选好项目和上下文，岂不更方便？我的理解是，如果当下无事可做，当然可以这样；如果收集打断了当下做的事儿，那就应该越快回到主线越好。这时只需要让它进入收件箱。
OF是让我们focus在当下进行的事情上，所以每次不应该花费太多的时间去维护它
这次就到这里了，下一篇会总结一些高级的玩法，比如设定到期时间、打标记等等。
差点忘了
上面创建项目时提了个问题，类型是什么？为什么要选单个动作？
类型是一个项目中的待办事项的关系是什么。我们发现，类型分三种，从左往右：顺序、平行、单个动作。
顺序比较好理解，举个例子，如果这个项目是读某一本书，每一条事项就是一个章节，那事项之间的关系必然是顺序的，即读完一章再读一章。如下图，《深度工作》是书名，也是项目，从第一章到准则四，是章节，是待办事项。
可以看到第一章我读完了，第二章才被激活，所以是黑色的。后面的章节是灰的，直到它的前一个事项被完成。
比较难理解的是平行和单个动作，请教了Google，在omnigroup上，找到了这样的回答：
Curt has mentioned the differences between the two in how OmniFocus treats them differently, and there is also a workflow consideration. Projects, parallel or sequential, should be completed at some point and because of this, they may get stalled, need revision, or dropped altogether. Single action lists are nothing more than a bucket to hold unrelated tasks and while one may, at any given time, complete all the tasks on the list, the list itself stays in the database.
大意是，如果一个项目需要有个时间的检视点，那么就把它定义为一个平行类型的项目；单个动作类型的项目是指里面的事项彼此毫无关系，并且就算这个项目里的所有事项都完成了，这个项目仍然会存在。
如果按照这样的理解，我们之前拆分项目的逻辑更符合单个动作。毕竟不能说“两周内”的所有事项都做完了，“两周内”这个项目就算完成了，因为随时可能产生新的属于“两周内”的事项。
继续阅读
To Be Continue...
