上下文（Context）是任务管理系统中的一个概念，它定义了执行一个任务时需要具备的条件，使用者可以根据它在众多任务中找到符合执行条件的任务。这篇文章想要分享一下我是如何实践「上下文」的。

挑战

首先来看一下在不使用「上下文」这个概念的情况下，我某一天任务列表的样子：

因为没有使用「上下文」，只要我打开任务管理工具，所有这些待办事项都会呈现在我的面前。但基于我所处的时间和环境，我实际可以完成的任务却只是这个列表中的一小部分：我在公司的时候必然没办法和家人刷剧，或者我在开会的时候必然没办法审核技术文档。这个列表给了我进行整体规划的能力，但仅仅依赖于这个列表却又是一种干扰，让我难以专注于当前时间和环境下我需要（或者可以）完成的任务。

我的「上下文」设计方案

下面就来介绍一下我是如何使用「上下文」来解决这个问题的。我设计「上下文」的理念是基于日常生活中重复出现的行为模式。以上面的任务为例：

• 我一般会在吃完早餐之后检查私人的即时消息和邮箱
• 我每天到公司之后的第一件事情就是查看工作相关的即时消息
• 我一般会在午休的时间段清理 RSS 里的消息
• 我一般会在下午下班之前处理一些零散的任务，比如安排会议和申请休假等等

也就是说，这些任务看似零碎，但我其实已经拥有了处理它们的模式，并且这些模式会在日常生活中反复出现。在这个基础上继续探索，我总结出了以下工作日的行为模式：

• 早晨日常
• 上班通勤
• 工作日常（上午）
• 会议（上午）
• 工作专注时段（上午）
• 午休
• 工作日常（午后）
• 会议（下午）
• 工作专注时段（下午）
• 工作日常（下班前）
• 下班通勤
• 家人时间
• 个人兴趣
• 睡前日常

这里的每一个行为模式就是任务管理系统中的一个「上下文」，前文的任务可以依此归类到一个或多个「上下文」中：

• 早晨日常
  • 查看私人即时消息
  • 查看私人邮箱
• 上班通勤
  • 阅读稍后阅读中的文章
• 午休
  • 清理 RSS 中的推送消息
  • 阅读稍后阅读中的文章
• 工作日常（下班前）
  • 到 OA 系统审批请假申请
  • 安排一个和 Kris 的会议

有了这样的设计之后，我就可以通过「上下文」的列表来对工作日进行规划。比如有些工作日的上午没有任何会议，那么我会把「会议（上午）」移出列表；有些工作日在家里远程办公，那么我会把「上班通勤」和「下班通勤」移出列表。规划完成了之后，我就可以通过这个列表方便的访问和我当前所处「上下文」相关联的任务且不会被不相关的任务干扰。比如中午12点进入午休时段，那么我就可以通过「午休」找到对应的任务，而和「午休」不相关的任务都不会出现。这就让我既拥有了整体规划的能力，同时又可以专注于和当前时间和环境相关的任务。

在 OmniFocus 中的实现

接下来介绍一下我是如何用 OmniFocus 来实现这个设计的。

假设任务管理系统中有下面四个项目，前面的三个项目包含了日常需要完成的任务：

最后一个项目作为「上下文」列表，里面包含了几个前文中提到的「上下文」：

接下来可以利用 OmniFocus 的「透视」功能从三个项目中过滤出适合于每个「上下文」的任务：

有了这些「透视」之后，就可以利用 OmniFocus 的 URL Scheme 来关联「上下文」和「透视」。在 OmniFocus 中，任意的一个透视都可以通过如下的 URL Scheme 来进行访问，其中的 {name} 需要替换成对应的透视的名称：

omnifocus:///perspective/{name}

因此，上述三个透视对应的 URL Scheme 如下：

omnifocus:///perspective/ReadItLater
omnifocus:///perspective/Routine
omnifocus:///perspective/Focus

把这三个链接放到对应的「上下文」的备注中就可以方便的查看相关联的任务了，效果如下：

以上就是我对于任务管理系统中「上下文」这个概念的实践。