留在脑子里的任务不是「还没忘」，而是「一直在被追踪」：David Allen 的 GTD（Getting Things Done）从这个观察出发，把所有承诺移出大脑、装入可信的外部系统，用五步流程逐一封口，换回无压力的执行。

GTD

大脑不是合格的任务存储器

为什么一件明确要做的事，越是不写下来越是让人焦虑？蔡格尼克效应（Zeigarnik effect） 表明：未完成的任务会持续占据工作记忆，不断自行冒头，直到被「完成或被安置」。大脑擅长联想与判断，唯独不擅长存储——每一条悬而未决的承诺都是一个开放回路（open loop），像后台进程一样消耗注意力；回路一多，焦虑从「某件事没做」恶化为「我可能有事没做」，后者才真正侵蚀专注。

Allen 的核心命题正是对此的反转：大脑用来产生想法，而不是保存想法。所有回路必须被一个可信的系统接住，问题于是从「如何记住」变成「系统如何运转」——五步流程回答的就是这一个问题。

五步流程：回路如何被逐一封口

五步不是并列要点，而是一条流水线：每一步把上一步的产出封存进系统，直到执行时刻无需再思考任何事。

• 收集（Capture）：任何任务、想法、承诺出现时立即进入收集箱，不分类、不判断，只求快——记录成本低到不会想说「待会儿再记」。
• 理清（Clarify）：对收集箱里每一条问同一个问题：下一步具体行动是什么？ 一步能做的进执行清单，多步才能完成的升格为项目，交给别人的进等待清单，没价值的删掉，仅作参考的归档。
• 组织（Organize）：把理清的结果路由进固定清单（即下一节的七清单），让一次性的判断沉淀为可反复使用的结构。
• 回顾（Reflect）：定期——尤其是每周回顾（Weekly Review）——清空收集箱、更新项目进度、核查等待事项。系统一旦失去回顾就失去可信度，收集也会随之瓦解。
• 执行（Engage）：清单可信之后，此刻做什么只需看三个约束：情境、可用时间、精力，不必重新枚举全部承诺。

第五步藏着 GTD 最容易被忽略的一点：当收集到回顾全链路成立，大脑才终于相信「系统没漏」，从而真正放下任务、投入当下——深度工作 Deep Work 描述的状态，正需要这种零后台进程作为前提。

七清单体系：组织的落地容器

组织步骤要成立，需要一套固定的容器。经典配置是七张清单，各自回答一个性质不同的问题：

清单	回答的问题	典型条目
收集箱（Inbox）	什么被抓取了但尚未理清？	灵感、待读、口头拜托
执行清单（Next Actions）	我现在可以动手做什么？	一步可完成的物理行动
项目清单（Projects）	哪些承诺需要多步兑现？	备考、系统重构、办签证
等待清单（Waiting For）	我在等谁交付什么？	委派出去的任务、待回复
可能清单（Someday/Maybe）	有价值但现在不做的是什么？	遥远的想法与计划
参考资料（Reference）	哪些信息值得留存但不行动？	文档、链接、笔记
回收箱（Trash）	什么已被判定无价值？	处理后删除的条目

除收集箱（理清前的中转）外，其余六张清单按一条分界线切开：可行动——执行、项目、等待，前两者以单步/多步相区别，等待清单单列则是让「行动权在他人手里」的事项不丢失跟进责任；不可行动——可能、参考、回收。表里刻意没有「优先级」容器：GTD 主张时间特定的事件交给日历，优先级在执行当口用 艾森豪威尔矩阵 现场判断，而不是预先排进清单。

我的 GTD 流程

五步流程落到日常，可以压缩成一套可操作的节奏，容器正是上面的七清单：

• 收集零门槛：只要有想法就进收集箱，无条件、不挑场合——这一条成立，「不依赖大脑记忆」才成立。
• 每天两轮理清：工作日上班打开电脑后、下班前各处理一次收集箱至空；休息日时间自由，但保证两轮。
• 项目即 TODO List：需要多步骤完成的任务，进项目清单时就规划好步骤——一个项目就是一个 TODO List；单步可执行的直接进执行清单。
• 执行清单只有三个来源：直接可做的单步事项、新项目拆出的下一步行动、项目当前步骤完成时立刻补进的新下一步。第三条让项目的「传送带」不间断——完成一步的瞬间就定义下一步，回路永不在人脑中过夜。
• 每周回顾固定在当周第一个工作日开始时：过一遍项目进度、核查等待清单、为项目补齐下一步。回顾的仪式感与 PDCA循环 同构，区别在于 GTD 回顾的对象是任务系统本身，而非工作产出。

边界：GTD 不管什么

GTD 回答「承诺如何被可靠地执行」，不回答两个同样重要的问题：

• 方向——哪些任务值得存在。这是目标管理的领地：SMART原则 把单个目标塑造成可衡量的形式，OKR 在更长周期内对齐目标与关键结果；GTD 只在目标分解为行动之后接管。
• 行为的持续——GTD 本身是一套习惯，「每天两轮清收集箱」这样的节点要真正跑起来，恰恰要靠 福格行为模型 Fogg Behavior Model 的处方：把单次处理做得足够简单，并绑定固定触发（例如「打开电脑之后」）。

实践中系统崩坏，多数不是方法错了，而是边界放错了：指望 GTD 提供方向感或解决当下的拖延，都不是它能给的。方向、优先级、启动、专注各归其位，GTD 负责的那一层——让所有承诺各安其位——才能真正运转。