ADHD与执行功能：i-have-adhd外部大脑系统设计实践

1. 项目诞生的起点ADHD不是态度问题是大脑的运作方式出了问题事情要从我在某技术社区看到的一个帖子说起。发帖人是一位自称从小被说聪明但不用心的开发者直到快三十岁才确诊ADHD。他在帖子里的描述让我无比熟悉——任务清单写了一长串序号排得整整齐齐结果一晚上过去了最紧急的那件事连第一步都没迈出去。他不是不想做而是身体和大脑之间好像隔着一层看不见的膜。我盯着这段话看了很久然后意识到一个问题市面上所有号称帮助你管理生活的工具几乎都是给不需要这种管理的人设计的。对于没有ADHD的人来说开始做事是一个默认值。闹钟响了就起床邮件来了就回复清单写了就执行。但对于ADHD人士每一步动作都像在攀爬一堵高墙——不是能力不够而是前额叶皮层给出的启动信号时有时无多巴胺的奖励反馈又迟迟不到位。这导致了一个普遍现象越重要的事越容易无限拖延反而是那些刺激感强、截止日期近在眼前的小事能让人瞬间进入状态。我从小就有类似特征但一直没有系统研究过也是在做了不少工具产品之后才慢慢回头审视。i-have-adhd这个项目的起点不是一次灵感而是一次累积性的崩溃某天我打开一个又一个待办清单软件发现每个都要求我先想清楚优先级再行动可ADHD大脑最困难的恰恰就是这个想清楚的动作。我不能用一个靠规划才能运转的工具来帮助一个无法规划的人。于是决定自己动手做一个真正的外部大脑。1.1 我试过的三类主流工具它们都卡在哪了在写第一行代码之前我系统地使用了市场上常见的三类工具以此确认问题的本质。第一类是极简待办清单像自带提醒的记事本。这类工具的问题在于它把所有决策重量都压在用户身上——每一条任务进来你都得先判断这对我的目标重要吗这个判断过程对ADHD大脑来说本身就是一种消耗。第二类是项目管理软件用看板、燃尽图、成员分配来管理任务这些工具的默认受众是团队我作为一个独立个体使用反而被各种元数据压到喘不过气。第三类是专注类App种树、番茄钟、锁机它们能解决开始了之后怎么保持的问题却完全无法解决怎么开始的问题——每次开头我都想再等五分钟吧然后五分钟就成了五小时。这三类工具的共通缺陷是它们假设你大脑内部的执行系统是完好的只是缺少一点辅助。但ADHD恰恰是执行系统本身出了问题这叫做执行功能障碍。引用一段通俗的解释——执行功能就像公司里的CEO负责决策、计划、抑制分心、切换任务。当这个CEO工作不力时公司不可能靠增加一个秘书来解决所有问题。秘书只能帮你记时间、排日程但要不要开会、开完会下一步干嘛、现在为什么应该放下手机去工作这些核心环节秘书完全替代不了。1.2 把执行功能障碍翻译成研发需求理解到这个层面之后我给自己写了一份研发前需求文档。这份文档里没有任何功能清单只有四个核心观察第一ADHD大脑的工作记忆空间极其有限。普通人可以在脑子里同时保持三到四件事我们可能只能保持一件事。所以系统必须什么都在外面——所有信息写到外部存储中界面永远告诉我现在该做什么而不是让我自己回忆和推理。第二时间感知是盲的。正常人感觉过了四十分钟ADHD时常在刚过了十分钟和已经过去了三小时之间错乱。这通常被称为时间盲。所以系统必须把时间流逝转化成看得见、摸得着的东西。第三开始行动的阻力与任务大小成正比。任务越模糊、步骤越多启动就越困难。所以系统必须把每一个任务自动拆成小到不可能失败的原子步骤。第四ADHD大脑对延迟反馈几乎无感。如果一件事做完之后要一个月才能看到回报大脑会直接判定它没有价值。所以系统必须在每个微小动作完成后立刻给出清晰的、可感知的正反馈。这四点合并起来就是我后来常说的产品设计原则对外部化一切信息对内部只留下执行这一个动作。明确了这些技术选型和功能设计就都变得非常顺理成章了。2. 系统的三大设计支柱外部大脑、外部时间轴、零阻力入口现在说正题整个系统的三大设计支柱它们分别对应了执行功能缺陷中最要命的三个问题。你不用把i-have-adhd当成一个神秘的工具它本质上做的就是把大脑里负责决策和记忆的部分完完全全搬到软件里然后留下一条只执行别无脑做的单行道。2.1 支柱一外部大脑——所有信息只存一次永远不要靠回忆第一个支柱是外部大脑对应的系统模块我起了个土气的名字叫倒进来就行。无论你想到什么——一个紧急任务、一个未来计划、一个突然冒出来的绝妙点子、一件要买的日用品——都可以用最短的路径把它丢进系统。这个模块没有任何分类要求没有清单、日历、项目的门槛只有一个输入框和一颗按钮。用一句话说就是把大脑出租出去所有存不住的东西都有地方安身。从产品设计角度看这个入口的阻力必须接近零。很多笔记软件其实也在做类似的事但它们会诱惑你去做整理。你记录完一篇笔记后有强烈的冲动去加标签、移动目录、排版这些动作让记录的人产生了我在好好管理生活的错觉实际上消耗的是最宝贵的执行能力。我的设计原则是禁止整理所有内容先进所谓收件箱由系统而不是用户决定它属于哪里。用户需要做的只是把脑子里悬着的那个念头倒出来清空的那一瞬间大脑的负担感就会显著下降。在实现上这个模块的数据结构非常轻。每条记录包含一个自由文本字段、一个记录时间戳、一个可选的截止时间就这三样。没有状态没有标签没有分类。分类是后来由自动规则完成的用户甚至可以永远不知道分类这件事存在。这和你平时用的所有知识管理工具都不一样但它解决了一个根问题——ADHD人士打开一个软件最常用的场景是我现在很混乱快点让我安顿下来而不是让我研究一下怎么建这个文件夹。2.2 支柱二外部时间轴——让看不见的时间变成看得见的块第二个支柱是外部时间轴。时间盲是ADHD最隐蔽也最折磨人的特性之一。我记得有一次在某个开发群讨论这个问题有人很认真地问怎么会有人感觉不到时间我当时看了这个回复差点笑出来——对就是有人感觉不到。对ADHD人士来说半小时前的记忆是模糊的半小时后的规划是缥缈的唯一确定的就是现在这一秒。如果缺乏外部提示一个下午悄无声息地消失是常事而且你完全不记得发生了什么。所以我在主界面做了两个东西。第一个是时间块视图把一天按一九分配成九十个可以拖动的时间块。每个时间块有明确的起止时刻当你把一个任务放进某个时间块屏幕上就会出现一个进度条它从块的开头向结尾推进颜色逐渐从绿色变成黄色如果你在超时之后还在做这个任务它会变成红色并轻微闪烁。第二个是今日未完成堆。所有今天没做掉的事不会像传统待办那样滚到明天列表里而是进入一个只保留今天日期标题的过期堆。你看着那个堆越积越高时比任何提醒都有效因为它把浪费时间这件事变得极其具体。2.3 支柱三零阻力入口与即时反馈——对抗启动困难的两针强心剂第三个支柱包含两个要素零阻力入口和即时反馈。零阻力入口的意思是从打开App到开始执行第一项任务不能超过两次点击。很多待办工具打开之后是整齐的列表但列表不等于可执行因为你还要判断这一条里面我要先做哪一步。而我的系统里有唯一一个主按钮叫现在做这个它直接跳过所有选择环节把当前最高优先级的原子任务推到你面前。打开软件就是这一点做完这一点之后系统自动加载下一点。整个过程中不需要任何思考不需要任何选择这就叫零阻力。即时反馈则更加重要。ADHD大脑对多巴胺的需求比普通人更强而多巴胺最直接的来源是做了事情之后立刻获得的成就感。传统待办软件通常在小方框里打勾那个反馈实在太弱了。我的方案是分数连续纪录动画庆祝。每完成一个原子任务界面会立即弹出得分动画这张得分累计成本日进度环。环每满一圈屏幕上会出现一次爆炸特效。听起来有点傻但它真的有用。因为我背后的逻辑很简单既然ADHD大脑渴望刺激和即时奖励那我们顺水推舟用真实的、高频的正反馈去驱动它而不是跟它对着干。3. 核心功能实现任务拆解器、时间盲补偿器、现在该做什么视图写到这里你可能会觉得听起来很美好但软件到底长什么样这一章我给你看看核心功能的具体实现逻辑。以下内容偏技术向但我会尽量让没有开发背景的人也能理解设计思路。3.1 任务拆解器的运作原理把大任务嚼碎了喂给你我要处理的第一道题是用户把完成年终报告丢进外部大脑后系统怎么把它变成一系列小到不可能失败的原子步骤拆解本身不是由AI完成的而是用了一套半自动的模板加规则系统。这里我特意没让AI介入原因是市面上不少工具拿到一句话就开始用大模型生成子任务但生成结果往往正确却主观和你的具体情况脱节。ADHD人士需要的是我自己认可的任务颗粒度而不是系统强行喂给我的。我的做法是把拆解过程分成两层。第一层是模板匹配。对于高频任务类型我内置了经过验证的标准原子任务链比如写文档会自动扯出新建文档 - 列大纲 - 写引言 - 完成第一部分 - 完成第二部分 - 收尾 - 检查格式每一条都可以直接执行。第二层是手动微调。如果模板不匹配系统会给出一个继续拆吗的小提示将当前任务按动词切分成更小的颗粒用户只需要点一下确认系统就完成了一次拆解。当然这个过程有大量细节值得斟酌。我举个例子原本设计时我以为任务拆得越细越好后来自己实测才发现颗粒度太小会造成决策疲劳你以为是在帮助实际上是在增加选择压力。后来我给原子任务设了它自己的标准单个任务时间必须落在五分钟到二十分钟之间。低于五分钟合并它高于二十分钟继续拆。这个时间窗口是我反复测试后得出的舒适区。3.2 时间盲补偿器把时间流逝变成可视化的物理量我说过时间盲需要用视觉补偿。实现上我做了个被自己称为能量面板的组件。它的核心很有趣不是显示当前几点几分而是显示距离下一个时间块结束还剩多少百分比。这个设计的原因是当我们问一个ADHD朋友现在几点了他们可以准确读出钟表上的数字但无法判断这个数字在今天的全局里意味着什么。别人说已经下午三点了还有两小时下班他们脑袋里浮现的是三点这个数字而不是剩余两小时这个时间块。所以我的面板只画三个东西。第一个是当前时间块的能量条从满格到耗尽的动画。第二个是今天所有时间块的剩余总和像一根蓝色的水管在逐渐排出。第三个是今天已经流失的比例用深灰色做底色让流失感可见。这三个组件共同构成了一个外部时间器官替大脑实时跟踪时间。我记得第一次做用户测试时一个ADHD朋友看着能量条从绿色变成黄色的过程说好像第一次感觉到时间在流动而不是知道时间在流逝。这种感官级别的区别只有亲身体验过才能理解。3.3 现在该做什么视图把一天的决策提前到一次完成很多人问过这个问题你们有任务清单、有时间块为什么还要单独做一个现在该做什么视图实际上这个视图承载了系统最核心的承诺——每天只做一次决策。传统待办清单逼迫用户在每次开始时重新挑选任务这对ADHD来说是毁灭性的。挑任务本身需要消耗大量自制力我现在是应该先做重要的还是先做紧急的要不要先花十分钟回复消息这些纠结很快就让人彻底疲惫最终结果就是一个都不做。而我的系统把决策环节集中到每天早上。用户起床后花一到三分钟只需要把今天的任务拉到一个时间块序列里系统根据每个时间块的长度和任务类型自动排好顺序。之后就这一个视图就会一直显示你现在正在做什么下一步是什么今天还有哪些块。我不需要思考我在哪个阶段不需要回忆我是怎么安排的跟着走就行。这一套逻辑本质上是把一天的执行变成了一条流水线你自己既是流水线上的工人也是生产线只不过决策已经在早上下好了。3.4 技术数据模型、架构选型和可扩展思路下面是给想复现的开发者朋友写的一小段技术说明。前端用的是React加TypeScript组件上刻意保持克制——每个界面只有一个主要操作按钮。后端是一个轻量的服务端渲染应用数据库选用了一个轻量级的本地数据库这样能保证数据同步的实时性。没有引入复杂的微服务架构因为整个系统只需要支撑一个人或一个小团队自己用过度设计只会增加维护负担。任务的数据结构大约是这样的interface AtomTask { id: string; content: string; estimatedMinutes: number; status: pending | active | completed | expired; projectId?: string; fromTemplate?: string; } interface TimeBlock { id: string; start: number; end: number; taskId: string; energyColor: green | yellow | red; score: number; }AtomTask代表一个原子任务TimeBlock代表一个时间块。两者共同构建了空间里的任务和时间里的容器的对应关系。每个时间块完成时系统会计算你的得分并更新本日进度环。后期我还为它做了浏览器插件可以自动检测你是否在一个应该专注的页面上但这部分属于进阶扩展此篇不展开了。4. 实测反馈与踩坑记录哪些功能被留下哪些被砍掉了代码写完不等于产品完成真正的打磨伴随着大量真实用户的使用和反馈。我在小范围内做了三四轮实测每轮大概四五个人有确诊ADHD的大学生、全职上班族、创业者也有只是前来凑热闹的效率爱好者。这一章我想把这段经历里最有价值的几个发现写出来。你会发现很多听起来很合理的设计实际使用后却带来的是完全相反的结论。4.1 真实使用反馈那些反常识的结果测试一开始就出现了一个违反常识的现象。我以为最大卖点应该是任务拆解器或者时间块视图结果所有被试用户最优先提到的却是那个看似可有可无的收件箱入口。几乎每个人都表示以前使用其他工具最烦的就是要决定某事该记录到哪个分类现在直接扔进去就感觉人已经轻松了。这说明外部大脑这个支柱仍然是一切的底座。第二个有价值的反馈是任务拆解模板必须足够不聪明。我一开始让拆解器按用户输入的自然语言去搜索对应的模板输入写周报会匹配到工作汇报模板输入写周报会匹配到工作汇报模板输入写周报会匹配到工作汇报模板输入写周报会匹配到工作汇报模板。但用户很快就发现这个智能功能带来的问题一旦模板匹配错了他们要花费更多力气去修改子任务。后来我把智能匹配改成了一个非常愚笨的版本只对包含明确关键词的任务做建议其余的直接给出一个通用的继续拆吗按钮由用户自己选择。结果出乎意料地好——用户感觉系统更像自己而不是在指挥自己。4.2 三个差点被砍掉、却被证明极其有效的功能在这个项目里损失最惨重的教训是我差点砍掉三个后来被证明极有用的功能。第一个是收件箱过期堆起初我认为让任务过期显得很挫败想把它做成自动滚入第二天。但测试时一个用户怒斥我你把它藏起来我反而觉得更挫败因为我的失败不被记录了。留着这个红色的未完成堆我才能对昨天到底浪费了多少有真实感知。我从善如流保留了这个功能但降低了它的视觉冲击——用灰红色而不是亮红色。第二个是现在做这个按钮的禁用状态。当系统检测到当前时间块的任务已经过期时它会强制停止推荐旧任务并弹出旧任务堆积建议先清空收件箱再启动新的一天这样的提示。有人最初觉得这是多管闲事直到他意识到自己已连续三天带着昨天没做完的任务乱窜才发现这个强制性其实是在帮他知道该止损了。第三个看似普通的动画反馈我原先怀疑分数环是对ADHD群体过度迎合的一种设计结果发现它在实际使用中作用大到超乎预期——每个测试用户都主动提及了它并且有人为了看烟花特效居然会主动去找那些五分钟的小任务去做。这三个功能的归属结论是做产品时我们常被最优体验的想法指挥不自觉把交互设计成为了让你舒服。可对ADHD用户来说合适的产品不是让人舒服的是用具体的失败提醒你同时给你一条足够小的当下出口。4.3 被砍掉的伪需求为什么社交功能和分析报表被移除再说说那些测完就被砍掉的模块它们同样重要。第一刀砍在社交分享上。做产品的人很自然地会想既然有分数环和连续纪录就该有好友排行榜靠社交比较来激励。事实证明这对ADHD人士几乎无效他们不是缺乏竞争心而是缺乏在别人面前维持形象的自控力排行榜反而增加了焦虑感——有人为了保住第一会去刷那些五分钟小任务而不去碰真正的大项目这种所谓激励完全是负向的。所以我最终把所有社交元素统统移除只保留了自己和自己比的连续纪录。第二刀砍在数据报表与复盘上。根据产品逻辑复盘是自我提升的关键环节于是第一版做了一个漂亮的可视化仪表盘展示各项任务完成率的周变化、每天时间分配饼图。测试一个月后几乎没有用户打开过这个仪表盘原因很现实ADHD人士自身的复盘能力本来就薄弱打开报表看到一堆数字只觉得我的失败在此刻全景展开了没有人愿意主动去看自己那堆红彤彤的数据。后来我把仪表盘的位置放到每周日闲逛时才能进入的隐藏页面并只显示一条最简单的句子完成率在上升还是下降。一句话够用。5. 开发者复现指南技术栈、实现顺序与避坑清单如果你看完前面这部分也想给自己的四周做出一个类似的系统或者更准确地说想复刻外部大脑外部时间轴零阻力执行这三条设计理念我给你一份经过实测的复现指南。不保证直接照抄就能成功但至少能帮你少走三个弯路。5.1 技术栈选择与论证为什么用轻量方案技术栈我一直遵守能少用就少用的原则。前端React加TypeScript就够了UI库则直接使用组件库来省去大量样式造轮子的时间。后端选择轻量API服务数据库直接放在本机数据同步用自带功能解决。用这种被很多人说不够高级的技术栈有四个明确理由第一项目规模小不需要分布式第二ADHD用户对应用打开速度极其敏感每多一百毫秒加载时间就可能让他们算了不打开了第三本地数据库让所有功能在离线状态下可用断网也不会打断执行第四部署简单一台小服就能跑不需要费心运维。这里也要给一个真诚警告技术方案的选择时刻提醒你自己别为了技术吸引力去上Kubernetes、微服务、消息队列。你不是在做高并发电商平台你必须时刻转回到用户真正的痛苦上——那个痛苦不来自服务器承受不了而是来自人的大脑执行系统不够稳定。5.2 建议实现顺序先做外部大脑再做执行视图按我踩过的坑建议按这个顺序实现。第一个必须做的是收件箱加原子任务数据结构。别先从时间块开始做那是最容易让人兴奋、却也最容易跑偏的部分。先把信息倒进来这一条链路做通畅再让用户感受到外部大脑的轻松感这是验证整套系统价值的核心场景。第二个做现在做这个视图它依托于原子任务列表由一个简单排序算法决定优先级。这时系统的核心闭环已经形成收件箱接收任务、拆解器产出原子任务、执行视图推着你走完。第三个才做时间块视图和能量条因为它的实现牵扯到比较复杂的计算而且需要前两者的数据作为输入。如果一上来就做时间轴你会在开发中花大量时间在好看上而忽略了对任务的透视能力。但它实际是锦上添花不是地基。5.3 最容易栽进去的三个坑与对策第一个坑拆解器做得太聪明。如前面所说第一次测试后我把智能匹配模板换成了保守版。这个坑栽下去几乎人人都会踩因为它看起来是个功能亮点。但我劝你牢记这个原则拆解器越傻用户的掌控感越强。第二个坑没有给失败留出制度化的出口。很多工具把没做完的任务悄悄顺延到明天因为设计师觉得堆积会让人绝望。但我的实测显示对ADHD群体而言明确的过期反而是一种自己需要的现实锚点。因为它提供的反馈清晰且无法逃避你才能清楚地看到自己真正浪费了多久时间。对策是做一个过期堆让它存在但不允许它出现在新一天的执行流里。你只能手动整理它。第三个坑低估了动画反馈的生理效应。如果你开发的系统也以ADHD用户为目标请务必在微小成功的反馈上下足功夫。不要觉得小孩才要动画。大脑神经系统在底层就是吃即时反馈这一套它不会因为你的年龄增长而改变底层机制。一个极简的烟花特效、一声轻快的音效对ADHD大脑的驱动作用胜过所有复杂的激励系统。5.4 在小范围内的人味测试清单最后列一个我每次发布新版本前会做的自测清单这个部分没有标准答案但可以作为你的参考。这些自测关注的是人用起来是否通畅而不是功能是否完成了。我称之为三个一分钟测试。第一如果一个人从来没有用过这个系统打开App后能否在一分钟内把脑子里某个念头扔进收件箱动作不能超过两次点击保存反馈必须直观。第二如果一个人正处于严重拖延状态能否在一分钟内被推着开始执行第一个原子任务不需要切换任何视图不需要做任何决定。第三如果一个人已经连续一周没有打开App重新打开时能否在一分钟内搞清楚昨天留下了什么、今天该干什么他不应该被一堆弹窗引导和教程流程逼得再一次卸载。我自己每次做完这三个测试都会发现一堆自己以为很顺、实际卡到不行的地方。这些感受是必须经历才能获得的靠读文档替代不了。把这个项目从想法变成能落地的系统前后花了我大约四个月。四个月里最深的体会是技术上的难点从来不是核心难点。核心难点是你要不要诚实地承认这个工具首先是做给自己用的。你只能在承认我需要一个外部大脑、我需要外界帮我感知时间、我需要我做出的每个动作都被看见的基础上才能做出一个真的能帮到人的东西。如果你也想做一个类似的项目请先把这份诚实用在自己身上再写第一行代码。