1. 从“i-have-adhd”这个标题说起：它到底在表达什么
第一次看到“i-have-adhd”这个标题，很多人会以为这是一份自我诊断声明，或者某个社交平台上的情绪化标签。但如果你把它当成一个项目代号来看，它其实指向的是一类非常具体的需求：用技术手段帮助注意力容易分散的人完成日常任务管理。ADHD（注意缺陷与多动障碍）的核心表现之一是执行功能障碍——不是不知道该做什么，而是很难启动、很难维持、很难在正确的时间切换到正确的事情上。这个标题背后隐藏的，是一套围绕“降低启动阻力、强化即时反馈、减少认知负担”构建的工具逻辑。
我接触过不少类似定位的项目，有的做成了极简待办清单，有的做成了番茄钟变体，还有的干脆就是一个会不断弹窗提醒你的桌面宠物。但“i-have-adhd”这个命名方式很有意思，它没有用“focus”“task”“flow”这类功能导向的词，而是直接用第一人称陈述句，把使用者的状态写进了项目名里。这意味着它的设计出发点不是“我要做一个多强大的工具”，而是“我承认我的大脑运作方式不同，所以我的工具也得不一样”。
这篇文章适合几类人看：一是自己或身边人有注意力管理困扰、想找一套真正能落地的数字工具方案的人；二是对行为设计、人机交互、轻量级应用开发感兴趣的技术从业者；三是做过类似工具但发现用户留存极低、想搞清楚问题出在哪里的开发者。我会从需求拆解、设计原则、技术选型、核心功能实现、实测中的坑这几个角度，把这个标题背后的完整项目逻辑讲清楚。文中涉及的具体代码和配置都是基于常见技术栈的合理推演，你可以根据自己的实际环境调整。
2. 为什么普通待办清单对ADHD人群几乎无效
2.1 执行功能缺陷不是“懒”，是启动门槛过高
很多人不理解为什么一个简单的“写待办、打勾”流程会对一部分人如此困难。这里需要先澄清一个底层机制：对于ADHD人群来说，从“知道要做”到“开始做”之间的神经传导路径比普通人更长、更不稳定。普通待办清单假设用户能够自主完成“打开应用→查看列表→选择任务→启动执行”这一串动作，但问题恰恰出在“选择任务”这一步——当列表上有超过三个未完成项时，决策瘫痪就会发生。
我实测过市面上十几款主流待办应用，发现它们有一个共同的设计盲区：把“管理任务”和“执行任务”混在同一个界面里。你打开应用，看到的是长长的列表、优先级标签、截止日期、项目分类，这些信息本身就在消耗注意力资源。对于一个执行功能已经吃紧的人来说，打开应用这个动作本身就变成了一个需要克服的障碍。
“i-have-adhd”这类项目要解决的第一件事，就是把“打开应用”到“开始做事”之间的步骤压缩到极致。理想状态下，用户打开界面应该只看到一个任务，或者一个极其明确的下一步动作，而不是一个需要浏览和决策的清单。
2.2 时间感知差异：为什么“还有三天”等于“还有三分钟”
ADHD人群普遍存在时间感知偏差，学术上叫“时间盲”。具体表现是：未来事件在主观感受上缺乏梯度，三天后和三小时后在情绪上的紧迫感差不多，直到截止时间逼近才会突然产生行动力。普通日历和提醒工具依赖用户对“未来时间点”的抽象理解，但这恰恰是薄弱环节。
所以有效的工具设计不能只靠“截止日期”来驱动，而要把时间变成可视化的、可感知的、不断变化的实体。比如用进度条代替日期数字，用颜色渐变代替文字提醒，用倒计时动画代替静态标签。这些设计在普通用户看来可能多余，但对目标人群来说是刚需。
2.3 即时反馈缺失导致任务链条断裂
还有一个容易被忽略的点：ADHD人群对延迟奖励的响应很弱。完成一个任务后，如果反馈不够即时、不够强烈，大脑就不会把“完成任务”和“愉悦感”关联起来，下一次启动就更难。普通待办清单打勾后的反馈通常只是一个勾号或一条删除线，刺激强度远远不够。
我在自己的项目里试过几种强化反馈的方案：完成任务后触发一段短音效、屏幕短暂闪烁、进度环填充动画、甚至是一个随机出现的小奖励图案。实测下来，视觉进度反馈加上轻微音效的组合效果最稳定，既不会过度干扰，又能提供足够的完成感。
3. 这个项目的核心设计原则：少即是多，但“少”要少得精准
3.1 单任务视图优先于列表视图
“i-have-adhd”类项目的第一条设计原则应该是：默认只显示一个任务。不是把列表折叠起来，而是从根本上不鼓励用户同时看到多个待办项。用户可以通过手势或快捷键切换到下一个任务，但界面上永远只有一个焦点。
这个设计决策背后的逻辑是：ADHD人群的工作记忆容量有限，同时看到多个任务会引发“认知过载”，导致直接放弃。单任务视图强制把决策成本降到最低——你不需要选，你只需要做眼前这一个。
实现上可以用一个简单的队列结构：任务按优先级或手动排序进入队列，界面只渲染队首元素。完成或跳过时，队首出队，下一个任务自动补位。代码逻辑不复杂，但交互效果差异巨大。
3.2 启动阻力要低到“不需要思考”
从用户产生“我要做点事”的念头，到实际开始执行任务，中间的每一步都会流失一部分用户。所以这个项目的启动路径必须短到离谱。理想情况下，用户解锁设备后，一次点击或一次快捷键就能直接进入当前任务界面，不需要经过首页、不需要登录、不需要选择项目。
我试过几种方案：桌面小组件直接显示当前任务、全局快捷键唤起悬浮窗、甚至用NFC标签贴在桌面上碰一下直接启动。实测下来，桌面小组件加全局快捷键的组合覆盖了大多数场景。小组件负责被动提醒，快捷键负责主动启动。
3.3 反馈必须即时且多通道
前面提到即时反馈的重要性，这里展开说具体实现。一个有效的反馈系统应该同时作用于视觉和听觉两个通道，但强度要可控。视觉上可以用进度环、颜色变化、粒子效果；听觉上可以用短促的提示音或白噪音片段。
关键参数是反馈延迟。从用户点击“完成”到反馈呈现，延迟必须控制在100毫秒以内，否则大脑不会把两者关联起来。这意味着反馈逻辑不能依赖网络请求或复杂计算，必须在本地即时触发。
3.4 容错设计：允许“跳过”和“重置”
ADHD人群的状态波动很大，有时候就是做不了某个任务。如果工具强迫用户必须完成或必须解释为什么没完成，用户就会直接卸载。所以“跳过”按钮必须和“完成”按钮一样显眼，而且跳过不需要填写任何理由。
同样重要的是“重置”功能。当用户因为中断而丢失进度时，应该能一键回到任务开始前的状态，而不是面对一个半途而废的烂摊子。这个设计看起来很小，但对维持长期使用意愿非常关键。
4. 技术选型与架构：为什么我最终选了这套组合
4.1 前端框架：轻量优先，启动速度是硬指标
这类工具的用户对启动延迟极其敏感。如果点开应用要等两秒才能操作，大概率就不会再打开了。所以前端框架的选择标准不是功能多强大，而是冷启动速度和多端一致性。
我对比过几套方案：原生开发启动最快但维护成本高；React Native生态好但冷启动有额外开销；Flutter渲染性能好但包体积偏大。最终我倾向于用Tauri加轻量前端框架的组合，桌面端包体积可以控制在10MB以内，冷启动基本在500毫秒左右。移动端则用原生或Flutter，根据团队技术栈决定。
核心原则是：任何超过1秒的启动延迟都是不可接受的。如果框架做不到，就换框架，而不是让用户等。
4.2 数据存储：本地优先，同步可选
任务数据必须本地存储，不能依赖网络。原因很简单：网络请求有延迟，延迟破坏即时反馈。用SQLite或轻量级键值存储都可以，关键是读写速度要快，而且不需要用户登录就能用。
同步功能可以作为可选模块存在，但不能成为使用前提。我见过太多工具因为强制登录和云同步把用户挡在门外。正确的做法是：本地数据永远可用，同步在后台静默进行，冲突时以本地为准。
4.3 通知系统：系统级提醒加应用内强化
通知不能只靠系统推送，因为系统推送容易被忽略或屏蔽。有效的做法是系统级提醒加应用内视觉强化双通道。系统提醒负责在用户离开应用时拉回注意力，应用内强化负责在用户使用时提供即时反馈。
具体实现上，可以用系统日历或提醒事项的API创建提醒，同时在应用内维护一个独立的提醒队列。两者通过本地数据库同步状态，避免重复提醒或遗漏。
4.4 跨设备策略：先做好单设备，再考虑多端
很多项目一上来就追求全平台覆盖，结果每个平台都做得半吊子。我的建议是：先把一个平台做到极致，通常是用户最常用的那个设备。比如如果目标用户主要在手机上，就先把移动端体验打磨好，桌面端可以用网页版过渡。
跨设备同步的复杂度主要在于冲突解决和状态一致性，这些问题在单设备场景下不存在。先解决核心体验，再扩展边界，是更稳妥的路径。
5. 核心功能模块的落地细节
5.1 任务队列的增删改查逻辑
任务队列是这个项目的核心数据结构。每个任务至少包含以下字段：唯一标识、标题、预估时长、创建时间、状态（待办/进行中/已完成/已跳过）、实际耗时。队列的排序策略可以支持手动拖拽和自动优先级两种模式。
关键细节在于状态切换的原子性。当用户点击“完成”时，任务状态更新、队列出队、下一个任务入队、反馈动画触发，这一串操作必须在同一个事务中完成，避免出现界面卡顿或状态不一致。代码上可以用一个状态管理库来集中处理，比如Redux或Zustand。
// 任务状态切换的简化逻辑 function completeTask(state, taskId) { const task = state.tasks.find(t => t.id === taskId); if (!task) return state; const updatedTasks = state.tasks.map(t => t.id === taskId ? { ...t, status: 'completed', completedAt: Date.now() } : t ); const nextTask = updatedTasks.find(t => t.status === 'pending'); return { ...state, tasks: updatedTasks, currentTask: nextTask || null, feedbackTrigger: Date.now() // 用于触发反馈动画 }; }5.2 计时与进度可视化
计时功能不是简单的倒计时，而是要把时间流逝变成可感知的视觉变化。我试过几种方案：环形进度条、线性进度条、颜色渐变背景、粒子消散效果。实测下来，环形进度条加颜色渐变的组合最直观，用户不需要看数字就能感知剩余时间。
计时精度不需要到毫秒级，秒级足够。但更新频率要足够高，至少每秒刷新一次界面，否则进度条会显得卡顿。可以用requestAnimationFrame来驱动渲染，保证流畅度。
5.3 中断处理与恢复机制
中断是ADHD人群的常态，工具必须优雅地处理中断。当用户切换到其他应用或锁屏时，计时应该暂停还是继续？我的建议是默认暂停，但提供继续选项。因为如果计时继续而用户实际没在做任务，数据就失真了。
恢复机制的关键是保留上下文。用户回来时，应该能看到中断前的状态：任务标题、已用时间、剩余时间、进度条位置。不需要重新选择任务或重新开始计时。
5.4 数据统计与回顾
统计功能的目的不是给用户压力，而是提供正向反馈的证据。所以统计维度应该聚焦在“完成了多少”而不是“错过了多少”。比如显示本周完成任务数、累计专注时长、连续使用天数，而不是显示未完成任务数或逾期任务数。
图表要简单直观，柱状图或热力图就够了。避免复杂的折线图或多维度对比，那些会增加认知负担。数据展示的频率也要控制，不要每次打开都弹统计页面，可以放在二级菜单里让用户主动查看。
6. 实测中踩过的坑和对应的解决方案
6.1 通知太多导致用户直接关闭权限
这是最常见的问题。一开始我设置了各种提醒：任务开始时提醒、任务过半时提醒、任务快结束时提醒、休息时间提醒。结果测试用户直接关闭了所有通知权限，工具彻底失效。
解决方案是把通知频率降到最低，只在两个时间点提醒：任务队列为空时提醒添加任务，以及用户设定的每日回顾时间。其他所有提醒都改成应用内视觉提示，不触发系统通知。
6.2 任务粒度太粗导致启动困难
用户添加的任务往往是“写报告”“整理房间”这种大颗粒任务，面对这种任务时启动阻力依然很大。解决方案是引导用户拆解任务，但拆解过程不能太复杂。
我试过在添加任务时强制要求填写子任务，结果用户直接放弃添加。后来改成可选拆解：添加任务后，界面显示一个“拆解”按钮，点击后弹出简单的输入框，用户可以快速添加几个子步骤。不拆解也能用，但拆解后体验更好。
6.3 进度数据丢失引发挫败感
有一次测试中，用户完成了几个任务后应用崩溃，重启后数据全部丢失。用户直接表示“再也不想用了”。这件事让我意识到数据持久化必须做到万无一失。
解决方案是每次状态变更后立即写入本地存储，而不是等应用关闭时统一保存。同时增加一个简单的导出功能，让用户可以手动备份数据。虽然增加了写入频率，但现代设备的存储性能完全能承受。
6.4 过度依赖手动操作导致使用中断
最初版本所有操作都需要手动点击：开始任务、完成任务、跳过任务、切换任务。用户反馈说“有时候手忙脚乱反而更焦虑”。后来增加了快捷键和手势支持，比如左滑跳过、右滑完成、双击开始。这些操作在移动端和桌面端都适用，大大降低了操作负担。
6.5 视觉设计过于花哨分散注意力
有一版我用了大量动画和色彩，结果用户反馈“看着很累”。后来回归极简设计：主界面只有任务标题、进度环和两个按钮。颜色只用黑白灰加一个强调色，动画只保留必要的过渡效果。简洁的界面反而让用户更容易聚焦。
7. 给想复现这个项目的开发者的几点建议
如果你打算动手做一个类似“i-have-adhd”的工具，我有几个从实际经验中总结的建议。第一，不要试图解决所有问题。ADHD管理涉及任务管理、时间感知、情绪调节、习惯养成等多个维度，一个工具能做好其中一个维度就已经很有价值了。第二，尽早找真实用户测试。这类工具的设计假设很容易偏离实际需求，只有真实用户的使用反馈才能告诉你方向对不对。第三，把启动速度当作第一优先级。功能可以少，但启动必须快。第四，数据安全不能妥协。本地存储加手动导出是最低配置，云同步可以作为增值功能但不能成为依赖。
这个项目最吸引我的地方在于，它迫使开发者从用户的真实认知状态出发去设计交互，而不是从功能列表出发去堆砌特性。当你把“用户可能连打开应用这件事都做不到”作为设计前提时，很多决策会变得清晰起来。
