1. 一个名字很直白的项目背后藏着一套完整的注意力管理思路第一次看到i-have-adhd这个项目名的时候我下意识觉得它可能又是一个自嘲式的玩具仓库——毕竟在开发者圈子里用自身状态给项目命名早就不是什么新鲜事。但真正把它拉下来跑了一遍、又翻了几轮源码之后我发现这东西远比名字严肃得多。它本质上是一套围绕“注意力容易涣散的人如何高效工作和生活”构建的工具集合与规则体系核心解决的是任务启动困难、上下文频繁丢失、时间感知失真这三个老大难问题。说得再直白一点如果你经常打开电脑准备干活结果两个小时后发现自己还在整理桌面图标或者明明列了待办清单却总是从最不重要的事情开始做又或者一坐下就忘了自己刚才想干嘛——那这个项目就是冲着你来的。它不依赖任何复杂的第三方服务核心逻辑全部用脚本和配置文件实现适合愿意折腾、喜欢把工作流掌握在自己手里的人。哪怕你只是轻度拖延也能从里面挑几个模块单独用没必要全盘照搬。我之所以愿意花时间拆解它是因为市面上大多数效率工具都在做加法——加功能、加面板、加提醒而i-have-adhd的思路是做减法和短路把决策成本压到最低把启动阻力降到几乎为零。这个反向思路本身就值得聊一聊。2. 整体设计思路拆解为什么是“短路”而不是“管理”2.1 核心痛点定位注意力涣散的人到底卡在哪要理解这个项目的设计得先搞清楚目标用户真正的卡点。很多人以为注意力问题就是“容易分心”于是拼命找专注力训练工具。但实际体验下来真正的瓶颈往往出现在三个更靠前的环节。第一个是任务启动。普通人看到“写周报”这个任务大脑会自动拆解成“打开文档、回忆本周工作、组织语言”几个步骤然后自然执行。但注意力容易涣散的人会在“打开文档”这一步就卡住——因为大脑同时涌入了太多关联念头比如“上周那个数据好像不对”“要不要先问一下同事”“文档模板放哪了”结果还没开始写就切去干别的了。第二个是上下文切换后的回归成本。被打断一次之后重新回到原来的任务上需要消耗大量认知资源。普通人可能几十秒就回来了但这类用户可能直接回不来了或者回来之后完全忘了刚才做到哪。第三个是时间感知失真。对时间的估计要么过于乐观“这个任务半小时搞定”要么完全失去参照“现在几点了我干了多久”。这直接导致排期失效和拖延加剧。i-have-adhd的所有模块基本都围绕这三个卡点设计而不是去解决“如何保持专注”这种更靠后的问题。这个优先级排序非常关键也是它和普通效率工具最大的区别。2.2 方案选型为什么用脚本而不是现成App项目作者在文档里明确说过他试过市面上几乎所有主流的任务管理和时间管理应用但最后都放弃了。原因很一致这些应用要么需要频繁的鼠标点击和界面切换要么会在你干活的时候弹出通知打断你要么把任务管理本身变成了一个需要维护的复杂系统。所以i-have-adhd选择了最“笨”但也最直接的方式用命令行脚本和纯文本文件。任务列表就是一个 Markdown 文件启动任务就是执行一条命令记录时间就是往一个日志文件里追加一行。没有GUI没有云同步没有花哨的统计图表。听起来很原始但恰恰是这种原始带来了两个核心优势。一是零决策成本。你不需要想“这个任务应该放到哪个项目里”“标签怎么打”“优先级怎么设”只需要把任务写下来然后执行。二是极低的打断成本。所有操作都在终端里完成不需要切换窗口不需要等界面加载敲几个字符就完事。当然这个选型也有明显的代价没有可视化界面没有移动端没有团队协作功能。但对于目标用户来说这些“缺失”反而减少了干扰源。我个人觉得这个取舍非常清醒——与其做一个什么都能干的半成品不如做一个只解决核心问题的锋利工具。2.3 模块划分与协作关系整个项目大致可以分成四个模块彼此之间通过纯文本文件解耦你可以只用其中一个也可以全部串起来。模块核心功能解决什么问题依赖关系任务捕获快速记录待办事项想法太多导致遗忘无任务启动一键进入工作状态启动困难、拖延依赖任务列表时间锚定定时提醒和时长记录时间感知失真独立运行上下文快照保存和恢复工作现场切换后回不来依赖编辑器/终端状态这种模块化设计的好处是你不需要一次性接受整套方法论。比如你觉得自己时间感知还行只是启动困难那就只用任务启动模块。等你觉得需要了再慢慢把其他模块加进来。这种渐进式的采纳路径比那些要求你“先花三天配置好整个系统”的工具友好太多了。3. 核心细节解析与实操要点每个模块到底怎么用3.1 任务捕获把想法从脑子里倒出来任务捕获模块的核心就一个命令功能是把你在终端里输入的一行文字追加到一个指定的 Markdown 文件里。听起来简单到不值一提但细节设计很有意思。首先它默认把任务写到一个叫inbox.md的文件里而不是让你选择分类。这个设计背后的逻辑是捕获阶段不应该做任何分类决策否则又会触发“这个放哪”的思考打断捕获流程。所有任务先统一进收件箱等后续有空了再整理。其次它支持在任务文本里用特定符号标记紧急程度和预估时长。比如你在任务后面加!表示紧急加~30m表示预估半小时。这些标记不会在捕获时做任何处理只是原样写进文件后续的任务启动模块会解析这些标记并据此调整行为。实操的时候我建议把这个命令绑定一个极短的别名比如t。这样你只需要在终端里敲t 写周报 ~45m就完成了一次捕获整个过程不超过三秒。我自己的习惯是在桌面放一个终端窗口常年开着想到什么就敲一行完全不打断当前思路。注意不要试图在捕获阶段就把任务整理得井井有条。这个模块的唯一目标是“不漏掉任何想法”整理是后面的事。我见过太多人因为纠结分类而放弃了整个系统。3.2 任务启动把“开始”这个动作压缩到极致这是整个项目里我最喜欢的模块也是最能体现设计功力的地方。它的核心逻辑是当你决定开始工作时不应该面对一个长长的任务列表然后陷入选择困难而应该让系统直接推给你一个任务你只需要回答“做”还是“不做”。具体实现是这样的执行启动命令后脚本会读取任务列表根据紧急标记、预估时长和当前时间选出一个最合适的任务然后在终端里显示出来并问你“开始吗”。你按回车就开始计时按其他键就跳过这个任务换下一个。这个设计巧妙地绕过了两个常见障碍。一是选择瘫痪你不需要从十个任务里挑一个系统帮你挑好了。二是启动仪式感按下回车这个动作本身就是一个明确的心理锚点告诉你“现在正式开始了”。脚本选择任务的算法并不复杂大致是这样一个优先级排序有紧急标记且预估时长小于当前可用时间的任务优先没有紧急标记但预估时长很短小于15分钟的任务次优先其余任务按添加时间倒序排列这个排序逻辑的意图很明显先处理那些“现在不做就会出问题”的再处理那些“很快就能做完”的最后才轮到那些大块头的长期任务。对于注意力容易涣散的人来说快速完成小任务带来的成就感是维持动力的重要燃料。3.3 时间锚定让时间变得“看得见”时间感知失真是很多人的通病而这个模块用了一种非常朴素但有效的方式来对抗它定时播报和时长记录。定时播报就是一个后台脚本每隔固定时间默认是15分钟在终端里打印一行当前时间和已经过去的时间。比如“14:30已工作45分钟”。这行字不会弹窗不会响铃只是安静地出现在终端里。但就是这种低干扰的提醒能让你在埋头干活的时候偶尔瞥一眼重新校准对时间的感知。时长记录则是每次任务启动和结束时往一个日志文件里追加一行记录格式是“开始时间 | 结束时间 | 任务描述 | 实际用时”。这个日志文件积累一段时间后你就可以用它来校准自己的预估能力。比如你发现自己预估30分钟的任务实际平均要花50分钟那下次做计划的时候就可以把系数调到1.7左右。我自己的经验是刚开始用的时候不要急着分析这些数据先老老实实记录两周。两周之后你回头看会发现自己对时间的估计偏差有多大这个冲击本身就能带来改变。3.4 上下文快照给工作现场拍一张“照片”这个模块解决的是切换后回不来的问题。它的思路很简单在你准备离开当前任务之前执行一个快照命令脚本会自动记录当前打开的编辑器文件、光标位置、终端工作目录、以及你手动输入的一段备注。等你回来的时候执行恢复命令所有状态一键还原。实现上它依赖编辑器提供的会话保存功能。比如在 Vim 里可以通过:mksession保存会话在 VS Code 里可以通过命令行参数恢复上次打开的文件夹。脚本做的事情就是把这些零散的状态收集起来存成一个 JSON 文件恢复时再逐项还原。这个模块的实操要点是养成离开前拍快照的习惯。刚开始可能会忘但只要你经历过一次“回来之后完全忘了刚才在干嘛”的痛苦就会自然记住这个动作。我建议把快照命令绑定一个顺手的快捷键比如在终端里按CtrlS就触发这样肌肉记忆更容易建立。提示快照文件建议按日期分目录存放比如snapshots/2025-01-15/1430.json。这样既方便查找也避免了单个目录下文件过多导致的性能问题。4. 实操过程与核心环节实现从零搭建一套可用的系统4.1 环境准备与依赖安装这套系统对环境的依赖非常轻基本上任何类 Unix 系统Linux、macOS都能跑。Windows 用户可以通过 WSL 或者 Git Bash 来使用但体验会稍微打点折扣因为部分脚本用到了 Unix 特有的信号处理机制。需要提前准备好的东西不多一个终端模拟器系统自带的就行Bash 4.0 以上版本macOS 自带的 Bash 是 3.2建议用 Homebrew 装一个新版一个文本编辑器Vim、Neovim、VS Code 都可以只要支持会话保存Git用来克隆项目也用来做版本管理安装过程就是标准的克隆加软链接git clone https://github.com/example/i-have-adhd.git ~/.local/share/i-have-adhd cd ~/.local/share/i-have-adhd ./install.shinstall.sh做的事情主要是把bin/目录下的脚本软链接到~/.local/bin/然后在你的 shell 配置文件里追加几行环境变量。安装完成后重新加载 shell 配置或者开一个新终端就能用了。这里有个小坑要注意如果你的~/.local/bin不在PATH里脚本会提示你手动添加。别跳过这一步否则后面所有命令都会报“command not found”。4.2 任务列表的格式规范与解析逻辑任务列表就是一个普通的 Markdown 文件默认路径是~/.i-have-adhd/tasks.md。每一行代表一个任务格式如下- [ ] 写周报 ~45m ! - [ ] 回复邮件 ~10m - [ ] 整理会议纪要 ~30m - [x] 修复登录bug ~60m解析逻辑会逐行读取用正则表达式提取几个关键字段[ ]或[x]表示未完成或已完成~XXm表示预估时长支持m分钟和h小时两种单位!表示紧急标记剩余文本就是任务描述这个格式的设计原则是“人类可读优先”。即使你哪天不想用脚本了直接打开这个文件也能看懂。而且因为是纯文本你可以用任何工具来编辑它包括手机上的笔记应用通过同步盘同步。我自己的做法是在任务描述里加一些自定义标记比如电脑表示需要电脑才能做电话表示需要打电话。这些标记脚本不解析但我在手动筛选的时候会用 grep 来过滤。这种“脚本不解析但人类可读”的扩展方式既保持了兼容性又增加了灵活性。4.3 启动脚本的完整执行流程启动脚本是整个系统里逻辑最复杂的一个值得把它的执行流程完整走一遍。第一步读取任务文件解析出所有未完成的任务。如果文件不存在或者没有未完成任务脚本会提示“没有待办事项”并退出。第二步获取当前时间并计算今天剩余的可工作时间。这个计算基于一个配置文件里的“工作日开始时间”和“工作日结束时间”默认是 9:00 到 18:00。如果你在非工作时间运行脚本会提示“现在不是工作时间确定要继续吗”。第三步根据前面说的优先级算法从任务列表里选出一个任务。如果选出的任务预估时长超过了今天剩余时间脚本会给出警告但仍然允许你开始。第四步显示任务详情等待用户确认。用户按回车确认开始按s跳过按q退出。第五步用户确认后脚本记录开始时间启动一个后台计时器然后进入“工作模式”。在工作模式下脚本会每隔一段时间检查一次是否到了预设的提醒间隔到了就打印一行时间提示。第六步用户完成任务后按CtrlC结束工作模式。脚本记录结束时间计算实际用时把任务标记为已完成并往日志文件里追加一条记录。整个流程里我觉得最巧妙的是第五步的“工作模式”。它本质上就是一个前台进程在循环但这个循环的存在本身就是一个提醒“你现在处于工作状态”。这种状态感对于注意力容易涣散的人来说非常重要因为它把“工作”从一个抽象概念变成了一个具体的、正在运行的东西。4.4 时间日志的分析与校准日志文件积累到一定量之后就可以做分析了。项目自带了一个简单的分析脚本功能是读取日志文件计算每个任务的预估时长和实际用时的偏差然后输出一个校准系数。比如你记录了20条数据发现预估30分钟的任务实际平均用了48分钟那校准系数就是1.6。下次你做计划的时候就可以把所有预估时长乘以1.6得到更现实的排期。这个分析脚本的输出格式是这样的任务类型 样本数 平均预估 平均实际 偏差系数 短任务(15m) 8 10m 18m 1.80 中任务(15-60m) 9 35m 52m 1.49 长任务(60m) 3 90m 145m 1.61看到这个表格的时候我的第一反应是“原来我这么不靠谱”。但第二反应是“至少现在我知道自己有多不靠谱了”。这种量化的自我认知比任何鸡汤都管用。注意校准系数不是一成不变的。随着你对任务越来越熟悉偏差会逐渐缩小。建议每个月重新跑一次分析更新系数。5. 常见问题与排查技巧实录5.1 脚本报错“command not found”怎么办这是新手最常见的问题九成以上的原因是~/.local/bin没有加到PATH里。排查步骤很简单echo $PATH | tr : \n | grep local如果没有输出说明确实没加。解决方法是在~/.bashrc或~/.zshrc里追加一行export PATH$HOME/.local/bin:$PATH然后执行source ~/.bashrc或者开一个新终端。如果还是不行检查一下软链接是否创建成功ls -la ~/.local/bin/ | grep i-have-adhd如果没有输出说明install.sh没跑成功重新跑一遍注意看有没有报错信息。5.2 任务启动后计时器不工作计时器不工作通常有两个原因。一是后台进程被系统杀掉了这在 macOS 上比较常见因为系统会限制后台进程的资源占用。解决方法是在脚本里加一个nohup或者用disown把进程从当前 shell 分离出去。二是终端模拟器的问题。有些终端在失去焦点后会暂停后台进程的输出导致计时器看起来“卡住了”。解决方法是换一个终端或者在终端设置里关闭“失去焦点时暂停”的选项。我自己的经验是用tmux或者screen来跑计时器最稳。开一个专门的窗口跑计时器其他窗口该干嘛干嘛互不干扰。5.3 快照恢复后编辑器状态不对这个问题的根源通常是编辑器版本不一致或者插件配置不同。比如你在 Vim 里保存的会话换到 Neovim 里恢复就可能出问题。解决方法是在配置文件里明确指定编辑器的可执行文件路径不要依赖$EDITOR环境变量。另一个常见原因是文件路径变了。比如你昨天在~/projects/foo下工作今天把项目移到了~/work/foo快照恢复的时候就会找不到文件。解决方法是尽量保持项目路径稳定或者在快照文件里记录相对路径而不是绝对路径。5.4 常见问题速查表问题现象可能原因排查方法解决方案命令找不到PATH未配置echo $PATH追加~/.local/bin到 PATH计时器不输出后台进程被挂起ps aux | grep timer用 tmux 跑计时器快照恢复失败编辑器路径不一致检查$EDITOR在配置里写死编辑器路径任务列表不更新文件权限问题ls -la tasks.mdchmod 644 tasks.md日志文件过大长期未清理wc -l log.txt按月分割日志文件5.5 几个我踩过的坑和对应的技巧第一个坑是过度配置。刚开始用的时候我花了一整天时间调整各种参数把提醒间隔从15分钟改成10分钟又改成20分钟把优先级算法改了又改。结果一天下来一个任务都没完成。后来我学乖了先用默认配置跑一周等真正遇到问题了再调。这个原则适用于所有效率工具先跑起来再优化。第二个坑是任务描述太模糊。我一开始写任务就是“写文档”“改bug”这种结果启动的时候完全不知道从哪下手。后来改成“写XX功能的接口文档先列大纲”“修复登录页面的表单验证bug先复现”启动阻力明显小了很多。任务描述应该具体到“下一步动作”的粒度而不是一个笼统的目标。第三个坑是忘记拍快照。这个只能靠习惯养成。我的做法是在终端提示符里加了一个小标记如果当前目录有未保存的快照提示符会显示一个特殊符号。这样每次看到提示符就能想起来。第四个坑是日志文件无限增长。跑了三个月之后日志文件已经几千行了分析脚本跑一次要好几秒。后来我加了一个按月分割的逻辑每个月一个文件分析的时候只读最近三个月的。这个改动很小但体验提升很明显。6. 进阶玩法把这套系统和其他工具串起来6.1 和版本控制结合做任务回顾任务列表和日志文件都是纯文本天然适合用 Git 管理。我自己的做法是每天下班前 commit 一次commit message 就写当天完成的任务数量。这样时间长了之后用git log就能看到自己每天的工作量变化。更进一步你可以用 Git 的 diff 功能来做周回顾。比如git diff HEAD~7 HEAD -- tasks.md就能看到过去一周任务列表的变化哪些任务完成了哪些任务一直挂着没动。那些挂了好几周都没动的任务要么拆解成更小的步骤要么直接删掉——它们大概率不是真正重要的事。6.2 和日历结合做时间块规划时间锚定模块记录的实际用时数据可以用来做更准确的时间块规划。比如你发现自己写文档平均要90分钟那在日历上就不要只留30分钟直接留两个小时。这样既避免了排期过紧导致的焦虑也减少了任务切换的次数。具体操作上你可以每周日晚上花15分钟把下周要做的任务按预估时长排进日历。排的时候记得乘以校准系数给自己留出缓冲。我自己的经验是一天排满6小时的实际工作量就差不多了剩下的时间要留给突发情况和休息。6.3 和笔记系统结合做知识沉淀上下文快照模块保存的备注信息其实是一种轻量的工作日志。如果你有使用笔记系统的习惯可以定期把这些备注导出到笔记里作为项目进展的记录。这样既不会增加额外负担又能积累有价值的项目历史。我自己的做法是每周五下午花20分钟把这一周的快照备注过一遍把其中有价值的信息摘出来整理成周报的素材。这样写周报的时候就不用回忆了直接翻笔记就行。7. 我对这套系统的一些个人看法用到现在差不多半年了我觉得i-have-adhd最大的价值不在于它提供了什么功能而在于它传递了一种态度承认自己的局限然后围绕这个局限来设计系统而不是试图克服它。市面上大多数效率工具都在暗示“你只要用了它就能变得高效”但这套系统从一开始就假设“你就是会分心、会拖延、会忘记”然后在这个前提下想办法让你还能把事做成。这种务实的态度比任何花哨的功能都更打动我。当然它也不是没有缺点。纯命令行的交互方式对不熟悉终端的人来说门槛不低而且没有移动端意味着你离开电脑就没法用。但话说回来如果你真的想用这些都不是不可逾越的障碍。终端可以学移动端可以用手机上的文本编辑器加同步盘来凑合。最后分享一个我自己的小技巧我在任务列表文件的开头加了一行注释写着“今天只做三件事”。每次打开文件的时候第一眼看到这行字就会提醒自己不要贪多。这个习惯帮我减少了很多“列了一堆任务结果一个都没完成”的挫败感。