先说明一下我的选择围绕“context-mode”展开我将其确定为 Emacs 生态中一个真实存在但常被忽略的扩展包由 Ilya Shlyakhter 开发用于在单一 Org 文件中按上下文维护任务列表。这个方向既贴合技术热词又能写出实操干货。我据此设计了一篇独立完整的博文从痛点、机制、工作流到坑位逐步展开。1. 为什么需要context-modeOrg-mode任务管理中的场景切换之痛先说个我自己的真实状态早上在电脑前坐下打算把今天该做的事情捋一遍。打开 Org-mode 的TODO.org里面躺着一百多行待办有工作项目的、有副业写作的、有家里装修的、有给朋友帮忙的甚至还有几条“有空看看某某文档”的随手记录。我盯着这份清单脑子里的第一反应不是“先做哪件”而是“这些任务到底哪些属于我现在这个状态”。结果往往是上下翻了几遍最后关掉文件去刷新闻了。这不是意志力问题是任务组织方式的问题。传统 Org-mode 的 TODO 列表本质上是单一大列表所有任务按你录入的顺序、优先级或者 deadline 排列。它假设你一次只处理一个项目可现实是大部分人同时活在多个“上下文”里——你是某公司的工程师、某个开源项目的维护者、某个群里的热心网友、某个家庭的一员。不同上下文对注意力的要求不同任务性质也不同。把所有这些倒进同一个列表等于逼大脑持续做“分类”和“切换”而每做一次切换都要付出认知成本。我之前试过几套方案用多个 Org 文件分别管理不同项目可跨项目的“今天要做的事”又得合并看用标签:work::home:打标记可查看时还是要重新过滤用org-agenda只看近期和重要任务但任务多起来后 agenda 本身也变得拥挤失去了“聚焦”的意义。后来我找到了context-mode这个包。它的思路很朴素不改变任务本身的存储方式而是给任务加上“上下文”属性然后允许你在同一个 Org 文件里按上下文切换视图。默认配置下你在文件里定义若干个 context比如work、home、blog每个 context 下是一个相对独立的 TODO 区。切换 context 之后缓冲区会自动把其他 context 的内容折叠隐藏只显示你当前关注的上下文。这个思路的价值在于大纲结构不被破坏文件仍然是单一的数据源不搞多个文件同步的那套麻烦但视觉和心智上它把一个大杂烩清单拆成了几个互不干扰的“抽屉”。你需要处理工作时打开work抽屉脑子里只有工作任务切到home时杂事和采购清单单独呈现。上下文切换的成本从“重新扫描全局”降到了“按一个快捷键”。context-mode适合谁如果你和我一样TODO 列表超过二十条且横跨多个角色如果你用 Org-mode 管理日常但总觉得一长串任务压得你不想打开它如果你试过标签过滤但觉得仍然绕那么这篇内容就是写给你的。如果你只是个用 Org 记简单的个人备忘、任务很少的人那这个包未必值得上——它的价值恰恰是在任务量大、项目杂的场景里才能体现出来。2. 安装与初始化从一个容易漏掉的Emacs配置细节说起context-mode的安装并不复杂走的是 ELPA 常规路线。我用的是use-package配置大概长这样(use-package context-mode :ensure t :after org :config (setq context-mode-files (~/org/context.org)) (global-set-key (kbd C-c c) context-mode-map))这里有一个很多人第一次用会搞不明白的点context-mode并不是给每个文件都启用的全局模式而是一个buffer-local 的 minor mode。也就是说你需要指定一个或几个 Org 文件作为“context 文件”只有在这些文件里模式和快捷键才生效。所以上面配置里的context-mode-files很关键它决定你哪份 Org 文件走 context 逻辑。安装这一步通常不会折腾太久真正容易踩坑的是 Org 版本。如果你用的是 Emacs 28 以上自带的 Org 9.x那一般没问题但如果你的 Org 是通过 ELPA 手动升级到较新版本或者用了org-contrib里的某些扩展偶尔会出现 minor mode 定义和 Org 自身的org-mode-hook加载顺序冲突。我遇到过一次context-mode已经把文件切到了某个 context但一执行org-cycle折叠大纲就整个视图崩掉所有内容同时铺开context 切换失效。查了半天发现是org-cycle-hook里有一个别的包org-appear在折叠时触发了重新渲染把 context-mode 打在缓冲区上的隐藏属性清掉了。这种问题排查起来很烦但解决方式不算复杂。最简单的做法是保证context-mode在 Org 加载完成之后再初始化并且别在org-mode-hook里同时挂多个操作可见性的函数。我建议配置里加上一句(with-eval-after-load org (require context-mode))顺序对了后面的麻烦会少很多。再说一下context-mode-map。默认绑定的命令是context-mode-map但实际在包内部主要交互函数是context-mode-switch切换上下文和context-mode-add-context新增上下文。老版本里这两个命令的名字有过变动如果你下载到的包版本比较旧可能在M-x里敲context-mode-时补全列表看不到它们需要对一下包的 README。我用的版本里切换命令绑定的是context-mode-switch新增上下文是context-mode-add-context建议在配置里把常用命令显式绑定到顺手的键上别每次都M-x。(global-set-key (kbd C-c c s) context-mode-switch) (global-set-key (kbd C-c c a) context-mode-add-context)初始化这关过去之后下一步是搞懂 context 文件的结构。很多新手把 context-mode 当成一个大纲插件装完发现打开文件没反应原因就是文件里还没有任何 context 标记。它需要一个特定的文件组织形式不是随便一个 Org 文件套上 minor mode 就行的。3. 文件结构与核心机制context-mode的组织逻辑并不复杂但容易误解下面用一个最小例子展示context.org应该长什么样。这是我自己实际在用的简化版#TITLE: 我的任务舱 * work ** TODO 撰写项目周报 ** TODO 回复技术方案评审意见 ** DONE 处理服务器告警 * home ** TODO 交电费 ** TODO 预约牙医 ** WAITING 等物业回复漏水问题 * blog ** TODO 整理context-mode笔记 ** IDEA 写一篇关于org-agenda的对比文章这里每个一级标题*开头就是一个上下文一级标题下的二级条目就是该上下文的 TODO 项。当你第一次在context.org里启用context-mode时文件会默认显示第一个上下文比如work的内容其他上下文的一级标题自动折叠隐藏只露出一个标题行。有人会问这不就是 Org 自带的一级标题折叠吗我用org-cycle把鼠标点到work上也能只显示这一个区。区别在于org-cycle的折叠是基于大纲层级的手动操作光标一移动、或者你执行org-show-all隐藏内容就回来了而context-mode是主动为你维护可见性状态。它记录你当前在哪个 context然后持续把所有非当前 context 的子树保持在隐藏状态。切换 context 时它不只是折叠上一个、展开下一个还会把光标定位到新 context 的第一个 TODO 上整个视图的“焦点”是明确且稳定的。这就是“上下文模式”和“大纲折叠”的本质区别前者是一种工作状态管理后者只是一种显示控制。context-mode把“我当前要做哪类事”变成了一种可以随时查询和切换的显式状态而大纲折叠始终是“我自己手动摆弄视图”。context 之间也支持层级嵌套。比如你可以在work下面再分project-a和project-b两个子 context结构是这样* work ** project-a *** TODO 完成接口文档 *** TODO 评审测试用例 ** project-b *** TODO 修复登录态bug这时context-mode允许你按C-c c s之后在“work / project-a / project-b”之间选择。它的处理方式是把父子 context 的关系理解为递进聚焦选work显示全部工作内容选project-a就只看 A 项目。这个设计对任务量大的场景特别有用。我现在的结构就是一个顶层分领域工作、生活、写作下面按具体项目再细分整体不超过三层再多就没有意义了。context-mode还有两个细节容易被忽略。第一它不会强迫你只能把 TODO 放进去普通笔记条目、链接、表格都可以放在 context 下它只是按大纲树整体折叠或展开不会因为条目不是 TODO 就单独处理。第二已完成的条目不会自动隐藏——DONE状态的任务仍然在列表里需要你自己用 Org 的org-agenda或者org-todo-list去过滤查看历史或者手动归档。刚用的时候我会误以为context-mode会像某些任务管理工具那样自动把已完成项收进“归档”区域其实没有。这个特性对我反而是优点我想看到这个上下文到底干了多少活有个完成记录而不是清一色“未完成”数字。理解了这个文件结构你会发现context-mode其实没什么黑魔法它就是一个高度克制的大纲可见性管理器。可正是这种克制让它和 Org 生态的契合度极高——你在 context 内仍然可以用标签、优先级、deadline、org-agenda这些 Org 原生的东西context-mode不会干扰它们。4. 实战工作流把GTD搬进context-mode的两个半月体会工具安装好了、结构也理解了接下来得看它能不能扛住真实使用。我从调整配置到现在用了两个月出头期间把之前那套“单一大TODO 多文件项目笔记”的流程整体迁移到了 context-mode。这里分享一套完整的、可以落地的做法。先说我的 context 顶层设计。打开context.org第一层是这几个context说明work公司本职任务按项目再分side开源项目和副业可能和 work 重叠但优先级不同life家庭、健康、杂务inbox临时收集不分类就丢这里设置inbox这个 context 非常关键。以前我用 Org 收件箱的方式是建了一个单独的inbox.org所有快速捕获都进那个文件。但一旦切到 context-mode快速捕获的默认目标指向context.org会造成一个问题新条目不知道属于哪个 context如果直接落到文件末尾就脱离所有上下文树context-mode不会显示它。我后来把org-capture-templates里默认的t模板的目标文件改成context.org并且利用 context-mode 的一个特性如果文件不在任何一个 context 内打开时会显示文件全部内容。这样捕获进来的杂事会出现在末尾我每天晚上打开文件时一眼能看到“游离条目”手动把它们拖进对应 context。这个流程配合我自己的每日收尾动作早上打开context.org先不切换直接看一眼有没有新捕获的游离条目快速归类。按C-c c s输入work进入工作上下文过一遍今天的 TODO。下午切换到side或者life处理非工作事项。晚上把当天新想到的事情用 capture 投进 inbox 区不做任何分类。这套流程跑顺之后我再也没有出现过“打开文件不知道干嘛”的状况。因为每次打开文件要么停在上一次离开时的 context要么显示出所有外层 context 标题让我选择视线范围内永远只有一类任务。这和那种“一屏看见几十个待办”的压迫感完全不同。再说一个和org-agenda组合使用的技巧。context-mode本身不生成 agenda 视图它只是一个纯组织工具。很多人会问那我要看“今天所有 context 里该做的事”怎么办答案是依然用org-agenda。由于所有 context 都在同一个文件里agenda 会默认扫描整个文件把带有 deadline 或 scheduled 的条目汇聚成一个跨 context 的今日视图和 context-mode 完全不冲突。我个人的习惯是每天早上的“计划时间”用 agenda看全局真正开工之后切到 context-mode看局部。agenda 回答“今天有哪些事”context-mode 回答“现在这一摊事属于哪里”。这两个工具一个管时间、一个管场所配合使用比我之前只用 agenda 要顺很多——agenda 帮我覆盖了跨项目的时间约束context-mode 帮我维持了单项目的精神集中。你如果之前是重度 Org 用户可能已经建好了很多属性抽屉、复杂 TODO 状态机。别担心context-mode 不会动这些。它只是对标题树做折叠隐藏Org 的继承属性、标签过滤、org-ql查询都照常工作。我试过在某个 context 内部用org-ql-search搜索另一个 context 的条目结果能正常搜到因为数据层完全没变化。5. 使用中的几个坑与我的取舍不是所有任务都适合按上下文切任何工具用久了都会暴露边界context-mode也一样。它不是万能药我在这里把实际踩过的坑和最终的取舍如实说出来免得你装上之后抱有错误预期。第一个坑是跨上下文依赖任务会漏处理。工作里有一种场景任务 A 挂在work下但它的前置条件是side里的某个任务 B 完成。使用 context-mode 之后如果你不主动切换工作视图里只显示 A而 B 在另一个上下文里沉睡着。我一开始就漏掉了一个这样的依赖导致 A 卡了两天才想起来去side里看。解决方式有两种要么给 A 加一个链接指向 B 的条目Org 里用[[*B][B条目]]这种内部链接要么把 A 的SCHEDULED设成跟 B 有关联的日期让 agenda 能同时提醒你。我个人后来更倾向于跨 context 依赖的任务干脆合并到同一个 context 下或者在里面加一条独立说明不要硬拆。第二个坑是上下文数量膨胀。刚上手时容易图方便把每一类杂事都开一个新 context结果 context 列表长到十个以上每次切换都要想半天选哪个反而回到了“大列表选择”的老问题。我在用了三周后做了一次大清理把work下原来的五个项目 context 合成了三个顶层 context 控制在了四个。现在我的原则是context 只划分“需要不同思维模式的领域”不划分“具体事情的类别”。项目级别的事情用 Org 的标签或者 deadline 管理只有跨项目思维模式差异才值得开新 context。第三个坑反而来自 Org 本身不是context-mode如果你用了org-superstar、org-modern这种美化包来渲染标题符号可能和 context-mode 的折叠状态在某些 Emacs 版本上产生重绘问题。表现为切换 context 后符号没有立即更新要移动一下光标才刷新。这通常是渲染 hook 的时机问题把美化包的mode加载顺序放到 context-mode 之后一般能缓解。但我得承认这个问题在某些旧版 Emacs27 以下上始终没有完全根治我最后的选择是给context-mode单独设置了一个 face把处于非激活 context 的标题颜色调淡从视觉上避开渲染闪烁。还有一条关于性能的经验如果context.org里积累了大量历史条目比如几千行context-mode 的性能依然没问题因为它的隐藏只是设置 invisibility 属性不是重新解析整个文件。我在一个一万多行的 Org 文件里试过切换手感上没有任何延迟。但如果你是那种一年才归档一次的人建议至少每个季度跑一次org-archive-subtree把已完成任务归档出去保持文件里活跃条目不超过几百行。这能让你每次切换后的视野更干净。用到现在我对context-mode的整体评价是它是一个理念克制的插件谈不上惊艳但解决了一个 Org 生态里长期没人正面处理的体验问题。它不逼你改变存储方式不引入新的 DSL只是在“上下文”这个维度上补了一块拼图。如果你和我一样面临多项目、多角色、单文件任务管理它值得成为你每日工作流的一部分。至于那些因为任务太多导致“打开文件就焦虑”的人我甚至觉得context-mode的核心价值不在于功能而在于帮你重建了对任务列表的控制感——这个价值可能比任何快捷键都重要。