企业官网建设流程全解析

1. 从“i-have-adhd”说起：一个被严重低估的效率工具

第一次看到“i-have-adhd”这个标题，我脑子里蹦出来的不是医学名词，而是一类人——那些坐在电脑前，同时开着二十个标签页，微信消息闪个不停，手边还放着没喝完的咖啡，脑子里同时转着三件事，结果一上午过去，一件都没做完的人。如果你也是这种状态，那这个项目就是冲着你来的。

“i-have-adhd”本质上是一个面向注意力容易分散人群的效率辅助工具，它做的事情很朴素：把“我现在该干什么”这件事，从你混乱的大脑里剥离出来，交给一个外部系统去管理。它解决的核心问题不是“如何更努力”，而是“如何让努力这件事变得不需要意志力”。适合谁来参考？三类人：一是长期被多线程任务拖垮的职场人，二是需要长时间专注但总是被自己打断的学生和创作者，三是任何想给自己搭一套“防走神系统”的效率爱好者。

我接触过不少类似定位的工具，大多数要么做成一个花哨的待办清单，要么堆砌一堆番茄钟、白噪音、专注统计，最后用户还是不知道该干嘛。“i-have-adhd”的思路不太一样，它更像是一个认知负荷管理器，而不是任务管理器。这个区别很关键，后面我会展开讲。

2. 核心设计思路拆解：为什么“少即是多”在这里成立

2.1 注意力分散人群的真实痛点是什么

很多人以为注意力问题就是“容易分心”，其实真正的痛点在更前面一步：启动困难。你明明知道有件事要做，但就是无法开始，因为大脑在启动前会先评估这件事的“认知成本”，而注意力容易分散的人对认知成本的敏感度极高，稍微复杂一点的任务就会被判定为“太累了，先放放”。

这就导致一个恶性循环：任务越拖越多，心理负担越来越重，启动门槛越来越高。传统的待办清单解决不了这个问题，因为它只是把任务列出来，并没有降低启动门槛。你看着清单上二十件事，只会更焦虑。

“i-have-adhd”的设计逻辑，我理解下来是三条：

• 一次只暴露一个任务：界面上永远只显示当前要做的那一件事，其他全部隐藏。这不是功能缺失，是刻意设计。
• 任务颗粒度极小化：不是“写报告”，而是“打开文档，写下第一段的第一句话”。小到大脑不觉得有负担。
• 即时反馈替代长期奖励：完成一个小步骤立刻给视觉或听觉反馈，用即时满足感对冲注意力漂移。

2.2 为什么不做成“全能效率套件”

市面上很多工具喜欢做加法：日历、看板、笔记、计时、统计全塞进去。对于注意力容易分散的用户来说，这恰恰是灾难。每多一个功能入口，就多一个分心的理由。你本来想打开工具做事，结果先花了十分钟调整主题颜色和标签分类。

“i-have-adhd”选择做减法，我认为是明智的。它的核心交互链路极短：打开 → 看到当前任务 → 完成 → 下一个。没有侧边栏，没有多层菜单，没有“高级设置”。这种克制在效率工具领域反而稀缺。

提示：如果你正在自己搭建类似工具，第一条原则就是“砍功能”。每增加一个按钮，都要问自己：这个按钮会不会成为用户逃避当前任务的出口？

2.3 技术选型上的取舍逻辑

从实现角度看，这类工具的技术栈选择有一个核心矛盾：本地优先还是云端同步。本地优先的好处是打开速度快、离线可用、隐私好；坏处是多设备同步麻烦。云端同步则相反。

我的判断是，对于“i-have-adhd”这个场景，本地优先 + 轻量同步是最优解。原因很简单：注意力分散的人最怕等待。你打开工具想做事，结果转圈加载三秒，这三秒足够你切到另一个标签页然后彻底忘记本来要干嘛。本地存储保证打开即用，同步可以放在后台异步做，不阻塞主流程。

具体到技术实现，如果用 Web 技术栈，IndexedDB 或 SQLite（通过 WASM）做本地存储，Service Worker 做离线缓存，同步层用 CRDT（无冲突复制数据类型）处理多端合并，是比较成熟的方案。如果用桌面端，SQLite 加一个轻量同步服务就够了。关键原则是：任何网络请求都不能阻塞任务展示。

3. 核心功能模块与实操要点

3.1 任务拆解引擎：把“大山”切成“石子”

这是整个工具最核心的模块。用户输入一个任务，系统引导用户把它拆成若干个小步骤。拆解的逻辑不是随便切，而是按照“启动成本”来切。

我实测下来，一个有效的拆解模板是这样的：

1. 物理动作：我要做的第一个物理动作是什么？（打开某个文件、拿起笔、点开某个链接）
2. 最小产出：做完这个动作后，我能看到的最小产出是什么？（一行字、一个标题、一个空表格）
3. 停止条件：做到什么程度就可以停下来？（写完第一段、填完第一行）

举个例子，任务“准备周会汇报”可以拆成：

每一步的启动成本都极低，低到大脑不会抗拒。而一旦开始，惯性往往会让你继续做下去。

注意：拆解步骤不要超过 7 个。超过 7 个，用户会感到新的压力。如果任务确实很大，先拆成 3-5 个大块，每个大块再单独拆。

3.2 单任务聚焦界面：视觉噪音的清除

界面设计上，“i-have-adhd”只显示当前步骤。但这里有个细节：已完成步骤的可见性。完全隐藏已完成步骤，用户会失去进度感；全部显示，又会造成视觉负担。

我的经验是，用极简的进度指示器替代列表。比如一排小圆点，已完成填充，当前高亮，未完成灰色。这样既有进度感，又不占注意力。圆点数量控制在 7 个以内，和步骤数对应。

颜色使用上，背景用低饱和度的中性色，当前任务用高对比度但面积小的强调色。避免大面积鲜艳色块，那会持续抢夺注意力。字体用系统默认无衬线字体，字号足够大，行高宽松，减少阅读压力。

3.3 即时反馈机制：让大脑“爽”一下

完成一个步骤后，必须有反馈。反馈的形式可以很简单：一个轻微的动画、一声短促的音效、进度圆点填充。关键是即时和可预期。即时是指完成动作后 100 毫秒内出现反馈；可预期是指每次反馈形式一致，让大脑建立条件反射。

我试过几种反馈方案，实测下来最有效的是“进度圆点填充 + 轻微震动（移动端）或短音效（桌面端）”。不要用弹窗，弹窗需要用户点击关闭，反而打断流程。不要用复杂动画，超过 300 毫秒的动画会让人不耐烦。

提示：音效音量要低，频率要短。我踩过的坑是用了一个 1 秒的提示音，结果每次完成都像被吓了一跳，后来换成 80 毫秒的轻微“嗒”声，体验好很多。

3.4 干扰记录与复盘：把“走神”变成数据

这个功能是加分项，但对目标用户很有价值。当用户中途切走或长时间无操作时，工具不阻止，而是记录一个“干扰事件”。一天结束后，用户可以看一个简单报告：今天被打断了几次，每次打断前在做什么任务。

这个数据的价值在于，它帮用户发现自己的注意力模式。比如你可能发现，每次做“写文档”类任务时最容易走神，而做“整理数据”类任务时反而专注。那就可以把写文档拆得更细，或者安排在精力最好的时段。

实现上，用visibilitychange事件监听页面切换，用blur事件监听窗口失焦，记录时间戳和当前任务 ID。数据存在本地，不上传。报告用简单的柱状图或时间线展示即可，不要做复杂的数据看板。

4. 完整实操流程：从零搭建一个最小可用版本

4.1 环境准备与技术栈选择

假设你要自己实现一个类似“i-have-adhd”的工具，我推荐的最小技术栈是：

• 前端：原生 HTML + CSS + JavaScript，或者轻量框架如 Preact（3KB）。不要用 React 全家桶，包体积和构建复杂度不值得。
• 本地存储：IndexedDB（通过 idb 库简化操作）或 localStorage（数据量小时够用）。
• 构建工具：Vite，配置简单，开发体验好。
• 部署：静态托管即可，因为核心逻辑都在本地。

如果你要做桌面端，Tauri 比 Electron 轻量得多，打包体积可以控制在 5MB 以内，启动速度也快。

4.2 数据结构设计

核心数据模型只需要两张表：

// 任务表 { id: "uuid", title: "准备周会汇报", steps: [ { id: "s1", text: "打开上周会议记录", done: false, order: 1 }, { id: "s2", text: "复制三个关键数据点", done: false, order: 2 } ], createdAt: 1690000000000, currentStepIndex: 0 } // 干扰记录表 { id: "uuid", taskId: "uuid", stepId: "s1", timestamp: 1690000000000, type: "visibilitychange" // 或 "blur" }

数据结构极简，没有用户系统，没有标签分类，没有优先级。这些“高级功能”在初期都是干扰。

4.3 核心交互实现步骤

第一步，实现任务创建和拆解引导。用户输入任务标题后，界面依次问三个问题（物理动作、最小产出、停止条件），每个问题一个输入框，回答完自动生成一个步骤。重复这个过程直到用户点击“够了，开始”。

第二步，实现单任务展示。从任务中取出currentStepIndex对应的步骤，全屏展示步骤文本。其他所有元素隐藏或极弱化。

第三步，实现完成动作。用户点击“完成”按钮或按空格键，当前步骤标记为完成，currentStepIndex加一，触发反馈动画，然后展示下一个步骤。如果是最后一步，展示任务完成界面。

第四步，实现干扰监听。在visibilitychange和blur事件中记录干扰，但不做任何提示。数据静默积累。

第五步，实现简单复盘。每天首次打开时，展示昨天的干扰次数和分布。用一句话总结，比如“昨天你被打断了 12 次，其中 8 次发生在写文档时”。

4.4 参数计算与性能优化

这里有一个容易被忽略的参数：步骤切换的动画时长。我试过 0ms、100ms、200ms、300ms、500ms，最终选择 150ms。0ms 太生硬，大脑来不及确认“上一步完成了”；500ms 太慢，急性子用户会烦躁。150ms 刚好够感知，又不拖沓。

另一个参数是自动保存频率。每次状态变更都写 IndexedDB 会有性能开销，但延迟写入又可能丢数据。我的方案是：状态变更时先更新内存，然后用requestIdleCallback在浏览器空闲时写入。实测下来，即使快速连续完成多个步骤，也不会丢数据，且主线程不卡顿。

注意：IndexedDB 的写入是异步的，不要用同步思维去写代码。每次写入返回 Promise，要处理好错误和重试。

5. 常见问题与排查技巧实录

5.1 用户不按预期拆解任务怎么办

这是最常见的问题。用户可能直接输入“写报告”就点开始，不拆解。这时候工具不能强制，但可以引导。我的做法是：如果用户跳过了拆解，在展示任务时加一行小字提示“这个任务看起来有点大，要不要拆一下？”，点击可以回到拆解流程。不强制，但给出口。

另一个情况是用户拆得太粗，比如“写报告”拆成“写第一部分、写第二部分、写第三部分”。这时候可以在完成第一个步骤后，如果检测到步骤耗时超过 25 分钟，提示“这一步花了比较久，要不要再拆细一点？”

5.2 干扰记录太多导致复盘报告失去意义

如果用户一天被打断 50 次，报告就没法看了。我的处理方式是：报告只展示前 5 个最频繁的干扰时段，其余归为“其他”。同时，如果干扰次数超过阈值（比如 30 次），报告顶部加一句“今天干扰较多，可能不适合做需要深度专注的任务，明天可以试试把这类任务安排在精力更好的时段。”

5.3 多设备同步冲突怎么处理

如果你做了同步功能，冲突是必然的。最简单的方案是“最后写入胜出”，但这对任务状态来说不够好。更好的方案是用 CRDT 的思路：每个步骤的完成状态是一个独立的布尔值，合并时取“或”运算（只要有一个设备标记完成，就算完成）。这样不会出现“在 A 设备完成了，在 B 设备又变回未完成”的情况。

5.4 常见问题速查表

5.5 独家避坑技巧

第一个坑：不要用 localStorage 存任务列表。localStorage 是同步 API，数据量大时会阻塞主线程。我早期版本用 localStorage，任务多了之后每次保存都卡一下，体验很差。换成 IndexedDB 后流畅很多。

第二个坑：不要做“智能推荐”。我试过根据用户历史推荐下一步做什么，结果推荐逻辑复杂，效果还不好。用户根本不看推荐，反而觉得界面变复杂了。后来砍掉，只保留用户自己拆解的步骤。

第三个坑：音效文件要预加载。第一次播放音效时如果才去加载文件，会有延迟，反馈就不即时了。在应用启动时用Audio对象预加载，或者用 Web Audio API 生成简单音调，零加载时间。

第四个坑：进度圆点不要超过 10 个。超过 10 个，用户数不过来，进度感就没了。如果步骤超过 10 个，用“3/12”这样的数字替代圆点。

6. 这个项目还能怎么扩展

如果你已经跑通了最小可用版本，有几个扩展方向值得考虑，但记住原则：扩展不能增加主流程的复杂度。

第一个方向是时段建议。根据干扰记录，工具可以学习用户的专注模式，然后在用户创建任务时建议“这类任务你通常在上午 10 点做效率更高，要不要设个提醒？”提醒要轻，不要弹窗，在任务卡片上显示一行小字即可。

第二个方向是模板库。用户可以把常用的任务拆解保存为模板，下次直接调用。比如“周报”模板、“客户沟通”模板。模板库要藏在二级页面，不要放在主界面。

第三个方向是协作模式。但这个要谨慎，协作会引入社交压力，而社交压力对注意力容易分散的人来说可能是负担。如果做，只做“共享进度”不做“互相监督”。

第四个方向是数据导出。让用户可以导出自己的干扰记录和任务完成数据，用于个人分析。格式用 CSV 或 JSON，简单直接。

我个人在实际操作中的体会是，这类工具的价值不在于功能多，而在于每一个设计决策都在降低启动门槛。你每增加一个功能，都要问自己：这个功能会让用户更容易开始做事，还是更容易逃避做事？答案如果是后者，再酷的功能也要砍掉。

最后分享一个小技巧：如果你自己用这个工具，把它的图标放在手机或电脑桌面最显眼的位置，但不要放在第一屏。放在第二屏，这样你打开它需要多一个滑动动作，这个动作本身就是一个“我真的要开始做事了”的心理仪式。听起来有点玄，但我实测下来，这个小小的摩擦反而提高了使用意愿。