💡Summary
🧩Cues
🪞Notes
Inbox 在 Odyssey 里的位置
Odyssey 的信息流是:Capture → Project → System → Share → Review。滴答清单的 Inbox 只负责第一步 Capture,而不承担后面所有事情。
| 阶段 | 要回答的问题 | 我的主要落点 |
|---|---|---|
| Capture | 我刚刚捕捉到了什么? | 滴答清单 Inbox |
| Project | 我要交付什么结果? | 项目与下一步行动 |
| System | 以后还会复用什么? | Odyssey 知识系统 |
| Share | 什么值得对外表达? | 文章、视频或分享 |
| Review | 系统是否仍然有效? | 周期复盘与清理 |
| 这里最重要的边界是:万事万物可以先成为“待处理项”,但最终并不都应该成为任务。 |

inbox的三个约束
Inbox 不是任务列表,也不是资料仓库。它是一层短暂停留的缓冲区:先替大脑接住信息,再在合适的时间完成判断。
这套方法只有三个约束:
- 入口足够低摩擦,任何念头都能在几秒内进入同一个收集箱
- 收集与处理分开,捕捉时不分类、不排期、不展开
- 流出速度不低于流入速度,Inbox 不能成为第二个“稍后再看”
三个约束详细解释
- 收件箱一定要触手可及且一元化,尽可能降低我们收集这个动作的摩擦力。不应该设置多处收件箱。
- 不能让各种事情纯靠大脑记忆,所以将待办进行收集 - 待处理很重要。而万事万物皆是待办,如任务管理、信息管理、写作、阅读、聊天; 收件箱充当缓冲区,将处理步骤推迟到之后的某个时间点,防止当下的 focus 状态被打断。
- 收件箱一定要定期整理和回顾,让其吞吐能力维持稳定。不然爆掉以后,可能将来就再也不愿继续收集了。收件箱需要可靠的清空流程才有效。
核心指标
流出率>=流入率
收件箱需要可靠的清空流程才有效,但做到这点很难。如果对应单一概念的收件箱(如「要读的东西」),在实体上却分散在许多不同的地方,可靠地清空收件箱更是难上加难。
可靠的收件箱要求流出率>=流入率,但如果一个收件箱分布在许多地方,就很难看到和管理这些速率(例如,通过放弃或推迟项目)。
一个解决方案可能是创建虚拟收件箱,为该概念收件箱的项目所在的几个「地方」提供一个统一的界面;见 我的阅读收件箱实现。
收集:统一入口,只写最小信息
把常用入口都汇入滴答清单 Inbox:
- iPhone 操作按钮触发快捷指令,把剪贴板内容直接新增为任务;(android不行)
- 突然想到一件事时,在滴答清单里快速输入或语音输入;
- 浏览网页、微信消息或其他 App 时,通过分享或剪藏先送进 Inbox。
滴答清单官方提供了“从剪贴板添加任务”“全局快速添加任务”等 iOS 快捷指令,也支持语音输入、邮件转发、浏览器扩展和微信消息保存。工具层已经足够完整,真正需要设计的是入口是否统一。

查看官方说明:多种方式创建任务
收集阶段只保留能够重新唤起上下文的最小信息。例如“周五前确认课程退费规则”,而不是在路上顺手设计分类、优先级、项目结构和完整执行方案。写入越重,越容易重新依赖大脑记忆。
实践
-
常用软件的信息和任务收集
-
微信:滴答清单公众号
-
edge:内置分享至滴答
-
知乎:内置分享功能至滴答
-
掘金:内置分享功能至滴答
-
-
书籍的书摘和笔记收集
- 全部导入 微信读书,用微信读书的 api 导出标注和想法的数据,和 obsidian 产生联动。
澄清:把每一条 Inbox 变成一个明确决定
我在固定的处理时段逐条判断,而不是边收集边判断:
| 判断 | 去向 | 处理方式 |
|---|---|---|
| 没有价值 | 删除 | 不为沉没成本保留入口 |
| 只是参考资料 | Odyssey | 提炼后进入知识系统,不留在任务箱 |
| 一步能完成 | 滴答清单任务 | 改写成动词开头的下一步行动 |
| 需要多个步骤 | 项目 | 定义结果,并生成一个可立即执行的下一步 |
| 暂时不做但值得保留 | 将来/也许 | 从当前行动视野移开,等待复盘 |
| 注意: |
- 这里其实不牵扯太多的价值优先级判断,只排除非常没有价值的选项
- 对当前在做的任务没有立刻起到作用的就是参考资料,否则就是一步能完成
- 第二笔记的信息来源有三:项目、一步能完成以及只是参考资料(一般除了没有价值以及暂时不做但值得保留之外的其他选项,往往已经从DIKW不是没有任何关联的D了,而是一个个I,但是需要进行总结)
- 当完成project的一个个KR、一步能完成、只是参考资料时,会携带提炼后进入知识系统的需求,这个时候需要列到四象限中(obsidian+xxx),比较重要的紧急的还需要番茄钟
时间只表达真实约束
滴答清单支持自然语言日期识别,例如在任务文本中直接写出时间,系统会识别日期和提醒。这很适合真实截止时间;但如果一件事没有时间约束,我不会为了“看起来有计划”而伪造日期。


组织:四象限是决策视图,不是四个仓库
我用“优先级 + 日期”生成四象限视图,而不是把任务搬进四个彼此割裂的物理清单。这样,任务仍然保留原来的项目语境,四象限只负责在当下提供决策视角。
| 象限 | 识别方式 | 我的动作 |
|---|---|---|
| 重要且紧急 | 高优先级 + 临近真实期限 | 立即处理,避免反复救火 |
| 重要不紧急 | 高优先级 + 暂无临近期限 | 主动保护时间,是系统真正要管理的区域 |
| 紧急不重要 | 低优先级 + 临近期限 | 能委托就委托,不能委托再处理 |
| 不重要不紧急 | 低/无优先级 + 无期限 | 删除,或移入“将来/也许” |
滴答清单官方也提供了两种搭建方式:用实体清单/文件夹,或用自定义智能清单按优先级与日期筛选。对我的系统而言,后一种成本更低,因为它不会破坏项目本身的分类。

执行:任务定义“做什么”,番茄定义“做多久”
完成组织后,我不会继续在 Inbox 中工作,而是只从已经明确的下一步行动里选择任务。复杂任务先拆成可以启动的一步,再给它一个专注时段。
滴答清单官方把番茄工作法拆成计划、执行、追踪、记录和优化,并明确强调:25 分钟工作 + 5 分钟休息只是推荐值,可以调整;真正重要的是完成结果,而不是累计多少个番茄。

这形成了一个简单分工:
- Inbox 负责“不丢”;
- 澄清负责“决定”;
- 项目与四象限负责“选择”;
- 番茄负责“启动和专注”;
- Odyssey 负责“沉淀可复用知识”。
维护:Inbox Zero 不是全部做完,而是全部决定
Inbox Zero 的真正含义
不是“所有事情都做完”,而是“每一条都已经得到明确决定”。删除、转为资料、放入项目或移到将来/也许,都算完成处理。
我的核心指标不是 Inbox 永远为空,而是流出速度 ≥ 流入速度。可执行的节奏是每天安排短时清理,并在每周复盘中检查:
- 是否出现了新的旁路入口;
- 是否有任务因为描述模糊而反复跳过;
- 是否把资料误留在任务系统;
- 是否给没有真实期限的任务堆了假日期;
- 重要不紧急的任务是否真正获得了专注时间。
注意:inbox真正结束就是在进行组织处理的时候,后续的执行已经不属于其范围了。
最小可用配置
如果从零开始,我只配置下面五件事
- 保留一个唯一 Inbox;
- 把 iPhone 操作按钮连接到“从剪贴板添加任务”;
- 打开智能日期识别,但只给真实期限设置日期;
- 用优先级与日期创建四象限智能视图;
- 为每天清理和每周复盘留出固定时间。
先让捕捉、处理、执行形成闭环,再增加标签、过滤器和自动化。一个入口能否长期工作,取决于它能否稳定流出,而不是它能装下多少东西。
最佳实践
- 一天中的任何时候收集对应的闪念
- 每天的结束阶段(21-22这个区间)去进行澄清组织
- 注意:如果是当天突然想去做或者紧急去做可以快速对指定几个inbox进行澄清组织
- 每周的周日晚间阶段(19-21这个区间)去进行复盘
官方资料与图片说明
文中的产品视觉图来自滴答清单官网功能介绍页、官网下载页与App Store 官方页面;功能细节参考滴答清单官方帮助中心。
知识网络
上级目录:信息系统
反向链接:
- 暂无
返回:信息系统