企业官网建设流程全解析

1. 从“i-have-adhd”说起：一个标签背后的真实需求

第一次看到“i-have-adhd”这个项目标题，我脑子里蹦出来的不是某个具体软件，而是一类人的共同处境。ADHD，注意缺陷与多动障碍，在中文互联网上常被戏称为“多动症”，但真正身处其中的人知道，它远不止“坐不住”这么简单。注意力像一只不受控的飞虫，一会儿落在这一会儿落在那，启动任务像推一辆手刹没松的车，时间感知模糊到“五分钟”和“两小时”体感差不多。这个标题之所以能成为一个项目名，恰恰说明有大量的人正在用技术手段给自己“打补丁”。

我接触过不少以“i-have-adhd”为名的开源小工具、浏览器插件、命令行脚本，它们的共同点非常鲜明：不追求大而全，只解决一个具体到不能再具体的痛点。比如“打开电脑后自动屏蔽所有娱乐网站，只留一个待办清单”“把长文档自动切成每段不超过三行的卡片”“每25分钟强制弹出一个只显示当前任务的浮窗”。这些项目的作者往往就是ADHD亲历者，他们写代码不是为了炫技，而是为了让自己能顺利度过一个下午。所以这个标题对应的核心领域，我把它定位为注意力辅助工具与认知负荷管理，潜在需求是降低任务启动阻力、维持工作记忆、对抗时间盲区，核心技术点集中在极简交互、强制约束、外部化记忆、即时反馈这几个方向。

适合谁来参考这篇内容？三类人。第一类是自己有注意力困扰、想动手做个小工具改善日常的开发者；第二类是产品经理或设计师，想理解这类工具为什么长成那样；第三类是普通读者，想看看“用技术对抗分心”这件事到底能做到什么程度。我不打算把这个话题写成医学讨论，也不打算推荐任何具体药物或疗法，只聊工程和产品层面的实操经验。下面我会从设计思路、核心细节、实操过程、问题排查四个大块展开，中间穿插我踩过的坑和实测有效的做法。

2. 内容整体设计与思路拆解

2.1 为什么这类工具必须“反人性”设计

普通效率工具的设计逻辑是“给你更多选择，让你更自由”。但ADHD向工具的设计逻辑恰恰相反，它要主动剥夺选择。我试过用市面上主流的待办应用，功能齐全、界面漂亮，结果是我花了二十分钟给任务分类、打标签、调优先级，真正干活的时间被压缩到十分钟。后来我明白了，对于注意力容易漂移的人来说，每一个额外的选项都是一个分叉路口，而分叉路口越多，走到终点的概率越低。

所以“i-have-adhd”类项目的第一个设计原则就是单任务视图。屏幕上同时只显示一件事，其他所有内容要么隐藏，要么用灰度弱化。这不是审美偏好，而是认知负荷的硬性要求。工作记忆容量有限，当界面上有五个可点击区域时，大脑会不自觉地扫描全部五个，这个扫描过程本身就消耗了本该用于任务的资源。我在自己的脚本里做过对比测试：同样写一段代码，全屏编辑器加侧边栏文件树加底部终端，平均启动时间约四分钟；换成只留一个居中输入框、其他全黑，启动时间降到四十秒左右。差距就是这么直接。

第二个原则是强制时间盒。ADHD人群的时间感知往往是“现在”和“不是现在”，中间没有刻度。所以工具需要把抽象的时间变成可感知的实体。常见做法是倒计时进度条、逐渐变色的背景、或者每隔固定时间发出一次温和提示。注意，提示不能太刺激，否则会变成新的干扰源。我见过一个项目用整个屏幕边缘缓慢呼吸的色块来表示剩余时间，实测比数字倒计时更不容易引发焦虑。

第三个原则是外部化工作记忆。脑子里记不住的东西，全部扔到工具里。但扔的方式有讲究，不能变成另一个需要管理的系统。理想状态是“想到什么，两秒内记下，然后忘掉”。所以快捷键要极短，输入框要常驻，保存要自动。我自己的做法是绑定一个全局热键，按下后弹出一个只有一行的输入条，回车即存，不分类不标签，存完就消失。晚上再统一整理，整理时也只做“删除”和“保留”两个动作。

2.2 技术选型：为什么我最终选了命令行加本地文件

这类工具的技术栈选择，我走过三个阶段。第一阶段用现成的笔记软件加插件，优点是上手快，缺点是插件生态不稳定，而且软件本身的功能会不断诱惑你去折腾。第二阶段自己写图形界面应用，用Electron或Tauri，界面是漂亮了，但打包体积大、启动慢，而且图形界面本身就有太多可交互元素。第三阶段我回到了命令行加纯文本文件，配合一个极简的全局热键弹窗。

为什么是命令行？因为命令行的交互路径最短。打开终端、输入一个词、回车，整个过程不需要移动鼠标，不需要在多个窗口间切换。对于启动阻力极大的人来说，少一次鼠标移动都可能决定这件事做不做得成。而且命令行天然是单任务的，你输入命令时，屏幕上只有光标在闪，没有其他东西分散注意力。

为什么是纯文本文件？因为纯文本没有格式、没有元数据、没有同步冲突。一个任务就是一行字，完成就删掉或打个标记。我试过用数据库，查询是方便了，但每次打开都要等它加载，而且数据库文件损坏过一次，丢了半天记录，从此我就只信纯文本。本地文件还有一个好处是可以用任何工具打开，手机、平板、另一台电脑，只要能访问文件系统就行。同步问题我用最简单的方案解决：一个定时脚本，每隔几分钟把文件复制到一个共享目录，冲突时以最新修改时间为准。不完美，但够用，而且永远不会出现“同步失败导致无法启动”的情况。

2.3 功能边界：什么该做，什么坚决不做

做这类工具最容易犯的错误是功能蔓延。今天觉得“加个统计图表吧”，明天觉得“加个标签系统吧”，最后又变成一个臃肿的效率软件。我在项目初期就给自己定了一条硬规矩：任何新功能，如果不能在两次按键内完成操作，就不加。这条规矩帮我砍掉了至少十个“看起来很有用”的想法。

具体来说，我坚决不做的功能包括：任务优先级排序（排序本身就是决策负担）、任务分类标签（分类需要思考，思考就会分心）、完成率统计（统计会引发自我评判，自我评判会引发焦虑，焦虑会让人逃避使用工具）、社交分享（别人的进度与我无关，只会增加比较压力）。我保留的功能只有四个：快速记录、单任务显示、时间盒倒计时、完成即消失。这四个功能覆盖了百分之九十的日常需求，剩下的百分之十，我选择用纸笔或者直接放弃。

这里要特别说一下“完成即消失”这个设计。很多待办工具会把完成的任务划掉但保留在列表里，视觉上是一种成就感。但对ADHD人群来说，已完成的任务留在屏幕上就是视觉噪音，会不断提醒你“还有这么多事”。所以我的做法是任务完成后直接从文件里删除，不留痕迹。需要回顾的时候去备份文件里翻，但日常界面永远只有未完成的事。这个设计反直觉，但实测对降低焦虑非常有效。

3. 核心细节解析与实操要点

3.1 快速记录通道的搭建细节

快速记录是整个工具的入口，入口不顺，后面全白搭。我的方案是用系统级的全局热键，按下后弹出一个极简输入窗口。在Linux上我用的是sxhkd加dmenu的组合，在macOS上用的是skhd加alfred的自定义工作流，在Windows上用的是autohotkey加一个自己写的小弹窗。核心要求是：从按下热键到光标就绪，延迟不超过两百毫秒；输入框只有一行，不显示历史记录，不显示提示文字；回车保存后窗口立即消失，不显示“保存成功”之类的反馈。

为什么不要反馈？因为反馈也是一种打断。你输入完一个任务，心里知道它被记下了就够了，不需要视觉确认。我试过加一个短暂的绿色闪烁，结果每次都会不自觉地盯着看那零点几秒，累积起来也是分心。后来改成完全无反馈，反而更流畅。保存的文件格式极简，就是每行一个任务，前面加一个时间戳，方便后续整理时判断哪些是过期的。时间戳格式用YYYY-MM-DD HH:MM，不要用Unix时间戳，因为人眼要能直接读。

这里有个细节：输入框的字体要足够大，行高要足够宽。我一开始用默认的十二号字，后来发现盯着小字看本身就需要集中注意力，换成十八号字之后，输入过程轻松很多。背景色用深灰而不是纯黑，纯黑对比度太高，看久了眼睛累。这些细节看起来微不足道，但累积起来决定了你愿不愿意每次都用它。

3.2 单任务视图的实现与调优

单任务视图的核心是“只显示当前任务，其他全部隐藏”。我的实现方式是一个常驻终端窗口，用watch命令每秒刷新一次，内容是从任务文件里读取的第一行。就这么简单。没有进度条，没有剩余时间，没有任务总数。只有一行字，告诉你现在该干什么。

但这里有个问题：如果第一行任务一直没完成，它会一直显示，时间长了就变成背景噪音，视而不见。所以需要配合时间盒机制。我的做法是每二十五分钟自动切换到下一行任务，不管当前任务有没有完成。切换时终端会清屏并显示新任务，同时发出一个很轻的提示音。这个设计的逻辑是：与其在一个任务上卡死，不如强制轮换，保持新鲜感。实测下来，很多原本会拖延很久的任务，在轮换几次之后反而更容易启动，因为每次重新看到它时，心理距离被重置了。

调优过程中我发现，任务的描述方式对启动难度影响极大。比如“写项目文档”和“打开文档文件，写第一段的三句话”，后者启动率高得多。所以我在记录任务时会刻意把任务拆到最小可执行单元。这个拆解动作不在记录时做，而在每天晚上整理时做。记录时只管扔进去，整理时才加工。加工的原则是：每个任务必须能在二十五分钟内看到明确进展，否则就继续拆。

3.3 时间盒倒计时的感知化处理

时间盒的难点在于让时间“被感觉到”。数字倒计时的问题是需要主动去看，而ADHD人群恰恰容易忘记看。所以我用了三种感知化手段叠加。第一种是终端背景色的缓慢变化，从深蓝逐渐过渡到深红，二十五分钟走完一个色相环。第二种是每五分钟一次的单音提示，音调随剩余时间减少而升高。第三种是窗口标题栏显示剩余分钟数，但字体很小，不主动看就注意不到。

这三种手段里，背景色变化是最有效的。因为颜色变化是 peripheral vision 能捕捉到的，不需要主动注视。我试过纯数字倒计时，经常是过了四十分钟才想起来看，而背景色方案下，我平均能在时间盒结束前三分钟左右意识到“快到了”。这个提前量很重要，它给了大脑一个缓冲，避免突然中断带来的烦躁。

参数方面，二十五分钟不是随便定的。我试过十五分钟、四十五分钟、六十分钟，最后发现二十五到三十分钟是启动阻力最低的区间。短于二十分钟会觉得“还没进入状态就结束了”，长于三十五分钟则中途走神的概率大幅上升。休息时间我设的是五分钟，但实际执行时经常延长到十分钟，这个我选择不较劲，能休息就休息，强制休息反而会引发逆反。

3.4 数据存储与备份的极简方案

数据存储我坚持纯文本加自动备份。主文件放在本地一个固定路径，文件名就叫tasks.txt。备份脚本每三分钟运行一次，把文件复制到一个带时间戳的备份目录，只保留最近二十个版本。备份目录可以放在任何地方，我放在一个同步盘里，这样手机也能看。但注意，同步盘只用来读，不用来写，写入永远只在本地主文件进行，避免同步冲突。

为什么不用数据库？除了前面说的启动速度和损坏风险，还有一个原因是纯文本可以用grep。我经常需要查“上周有没有记过类似的任务”，一个grep命令就搞定，不需要写查询语句。而且纯文本可以直接用版本控制工具管理，虽然我实际没用，但知道这个可能性存在本身就让人安心。

备份策略上我踩过一个坑：一开始用定时任务每五分钟复制一次，结果有次任务文件被误删，备份文件也在五分钟前，丢了五条记录。后来改成每次保存任务时立即触发一次备份，用文件系统的事件监听实现。这样虽然备份频率高了，但每次备份的文件很小，磁盘占用可以忽略。而且我加了一个“回收站”机制，删除的任务不是真删，而是移动到另一个文件里，保留三十天。这个机制救过我两次，都是误删了重要任务。

4. 实操过程与核心环节实现

4.1 环境准备与依赖安装

我以Linux环境为例，因为这是我最常用的开发环境，其他系统思路类似。首先需要的基础工具包括：一个终端模拟器（我用的是alacritty，启动快、配置简单）、一个窗口管理器（i3或sway，支持快捷键绑定）、一个文本编辑器（vim或nano，看个人习惯）、以及一个通知工具（notify-send或dunst）。这些工具在主流发行版的软件源里都有，安装命令因发行版而异，这里不展开。

核心脚本我用Python写，因为Python在大多数系统上预装，而且标准库足够用，不需要额外安装依赖。脚本主要做三件事：读取任务文件、显示当前任务、管理时间盒。我把它拆成三个独立的小脚本，而不是一个大程序，这样每个脚本的逻辑都很简单，出问题容易排查。三个脚本分别叫show_task.py、timer.py、add_task.py，放在~/bin目录下，加上可执行权限。

全局热键的绑定在窗口管理器的配置文件里做。以i3为例，在~/.config/i3/config里加一行bindsym $mod+space exec --no-startup-id ~/bin/add_task.py，这样按下Win加空格就会弹出输入框。输入框我用的是dmenu，因为它足够轻量，而且支持自定义颜色和字体。命令是dmenu -p "" -fn "monospace:size=18" -nb "#2d2d2d" -nf "#e0e0e0"，参数含义分别是提示文字为空、字体等宽十八号、背景深灰、前景浅灰。

4.2 任务记录脚本的完整实现

add_task.py的逻辑很简单：调用dmenu获取用户输入，如果输入非空，就在任务文件末尾追加一行，格式是时间戳 任务内容。时间戳用datetime.now().strftime('%Y-%m-%d %H:%M')生成。追加时用open(file, 'a')模式，确保不会覆盖已有内容。写入后立即触发备份脚本，备份脚本用shutil.copy2复制文件到备份目录，文件名加上当前时间戳。

这里有个细节：dmenu默认是从标准输入读取选项列表，如果标准输入为空，它会显示一个空列表。我们需要的是纯输入框，所以要用dmenu -p ""并传入一个空的标准输入。在Python里可以用subprocess.run调用，传入input=b''。另外dmenu的返回是字节串，需要解码成字符串并去掉末尾换行。如果用户按Esc取消，dmenu返回非零退出码，脚本直接退出即可。

任务内容的格式我建议不要加任何特殊符号，就是纯文字。因为后续处理时用split(' ', 1)就能把时间戳和内容分开，简单可靠。如果任务内容里本身有空格，也没关系，因为只分割第一个空格。时间戳格式固定为YYYY-MM-DD HH:MM，长度固定，方便用字符串切片提取。这些看似琐碎的约定，在后续写整理脚本时会省很多事。

4.3 单任务显示与时间盒的联动

show_task.py负责显示当前任务。它读取任务文件的第一行，提取时间戳后面的内容，然后打印到终端。如果文件为空，就显示“没有任务，去记录一个吧”。这个脚本本身不处理时间盒，时间盒由timer.py控制。timer.py的逻辑是：启动一个二十五分钟的倒计时，每秒钟更新一次终端背景色，每五分钟播放一次提示音，倒计时结束后发送一个信号给show_task.py，让它切换到下一行任务。

两个脚本之间的通信我用的是文件信号。timer.py在倒计时结束时，往一个临时文件里写一个字符，show_task.py每次刷新时检查这个文件，如果有内容就读取下一行任务并清空信号文件。这种方式比进程间通信简单，而且即使两个脚本重启也不会丢失状态。终端背景色的更新用ANSI转义序列实现，格式是\033]11;#RRGGBB\007，其中RRGGBB是十六进制颜色值。颜色从深蓝#1a1a2e渐变到深红#2e1a1a，用线性插值计算每一秒的颜色值。

提示音我用的是paplay播放一个预先生成的短音频文件，频率从四百赫兹逐渐升到八百赫兹。音频文件用sox生成，命令是sox -n beep.wav synth 0.1 sine 400。每五分钟播放一次，音量设得很低，刚好能听到但不刺耳。实测下来，这个提示音在安静环境下足够引起注意，在嘈杂环境下可能被淹没，所以如果工作环境噪音大，可以考虑加一个视觉闪烁作为补充。

4.4 每日整理流程的具体操作

每天晚上我会花十分钟整理当天的任务文件。整理流程分三步。第一步是删除已完成的任务，这个在白天完成时就已经做了，所以晚上主要是检查有没有遗漏。第二步是把剩余任务重新拆解，把大任务拆成小任务。拆解的标准是：每个任务必须能在二十五分钟内完成，或者至少能看到明确进展。第三步是把拆解后的任务按优先级重新排序，但排序只分两档：今天必须做和今天可以做。不做更细的优先级划分，因为细分本身就是负担。

整理时我会用vim打开任务文件，用dd删除行，用o插入新行。vim的快捷键操作比鼠标快得多，而且不需要在窗口间切换。整理完成后，我会把文件内容复制一份到备份目录，文件名加上日期。这个备份是长期保留的，和自动备份不同，自动备份只保留最近二十个版本，长期备份保留所有日期。这样以后想回顾“上个月这个时候在干什么”，直接翻对应日期的文件就行。

整理过程中有一个重要原则：不要边整理边做任务。整理就是整理，做任务就是做任务，两者混在一起会导致整理时间无限延长。我给自己定了一个硬性时间限制：十分钟。时间一到，不管整理到什么程度，都停下来，开始做第一个任务。这个限制逼着我快速决策，避免在整理阶段陷入完美主义。

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

5.1 工具启动延迟的排查思路

最常见的问题是热键按下后弹窗延迟。如果延迟超过半秒，使用意愿就会大幅下降。排查时先看dmenu的启动时间，在终端里直接运行time dmenu，看它本身耗时多少。如果dmenu本身很快，那问题可能在热键绑定上。i3的exec命令默认是异步的，但有时候会因为窗口管理器正在处理其他事件而排队。可以尝试在exec后面加--no-startup-id，或者改用i3-msg exec。

另一个常见原因是字体加载。如果dmenu配置了系统里没有的字体，它会花时间搜索替代字体。解决方法是明确指定一个已安装的字体，用fc-list | grep确认字体名称。我遇到过因为字体名称写错导致每次弹窗都要等一秒多的情况，改成正确的字体名后延迟降到几十毫秒。还有一次是输入法的问题，dmenu在某些输入法框架下会等待输入法初始化，换成fcitx5的dmenu兼容模式后解决。

如果以上都排查了还是慢，可以考虑换一个更轻量的弹窗工具，比如rofi的dmenu模式，或者自己用zenity写一个。但zenity依赖GTK，启动更慢，不推荐。最极端的方案是用xterm加一个简单的shell脚本，但那样输入体验会差很多。我的建议是优先排查字体和输入法，这两个是最常见的罪魁祸首。

5.2 任务文件损坏的恢复方法

纯文本文件虽然不容易损坏，但也不是绝对安全。我遇到过两次文件内容变成乱码的情况，一次是因为磁盘写入时断电，一次是因为同步盘冲突。恢复方法取决于备份策略。如果有自动备份，直接从备份目录复制最近一个正常版本即可。如果没有备份，可以尝试用fsck检查文件系统，或者用strings命令从磁盘扇区里提取残留文本。

预防措施比恢复更重要。我的做法是每次写入任务时都用flush和fsync确保数据落盘，虽然会稍微慢一点，但避免了断电丢数据。Python里可以用f.flush()加os.fsync(f.fileno())实现。另外，任务文件不要放在同步盘的实时同步目录里，而是放在本地，用定时脚本单向复制到同步盘。这样即使同步盘出问题，本地文件不受影响。

还有一个技巧是给任务文件加一个简单的校验。每次写入时在文件末尾追加一行#CHECKSUM:xxxx，xxxx是前面内容的简单哈希。读取时先验证哈希，如果不匹配就报警。这个方案会增加一点复杂度，但对于重要数据来说值得。我用的是Python的hashlib.md5，计算速度快，碰撞概率低到可以忽略。

5.3 时间盒失效的几种情况和应对

时间盒失效通常表现为：倒计时结束了但没注意到，或者注意到了但不想切换。前者是提示不够明显，后者是心理抗拒。提示不够明显的情况，可以增加提示手段，比如加一个全屏闪烁，或者让终端窗口自动置顶。但要注意，提示太强烈会变成惊吓，反而引发烦躁。我的经验是背景色变化加声音提示已经足够，如果还是注意不到，可能是工作内容本身太吸引人，这时候强制切换反而不好，可以允许延长一个时间盒。

心理抗拒的情况更复杂。有时候是因为当前任务正做到关键处，不想被打断；有时候是因为下一个任务太讨厌，不想开始。前者可以设一个“延长”快捷键，按一下延长五分钟，但最多延长两次。后者需要检查任务拆解是否到位，如果下一个任务还是太大，就当场拆小。我还在工具里加了一个“跳过”功能，按一下直接跳到下下个任务，给一个逃避的出口。逃避不可耻，有时候跳过之后反而能静下心来做后面的任务。

还有一种情况是时间盒节奏和实际工作节奏不匹配。比如有些任务需要深度思考，二十五分钟刚进入状态就结束了。这时候可以设一个“深度模式”，把时间盒延长到五十分钟，但每天最多用两次。这个限制很重要，否则深度模式会变成常态，时间盒就名存实亡了。

5.4 常见问题速查表

这张表里的每一条都是我实际遇到过的，有些坑踩过不止一次。比如字体问题，我在三台不同的机器上都遇到过，每次都是因为换了系统之后忘了重新配置字体。后来我把字体配置写进了一个初始化脚本，新机器上跑一遍就搞定，省了很多重复劳动。

6. 进阶扩展与个人实践体会

6.1 用语音输入进一步降低记录阻力

文字输入虽然快，但有时候手头正忙，或者单纯不想打字。这时候语音输入是个很好的补充。我的方案是用whisper.cpp在本地做语音转文字，配合一个全局热键，按下后录音，松开后自动转文字并保存到任务文件。整个流程不需要联网，隐私有保障，而且延迟可以接受。whisper.cpp的base模型在普通笔记本上转写一句话大约需要一到两秒，足够快。

配置上需要注意麦克风的权限和录音时长。我设的是最长录音十秒，超过自动停止。转写结果直接追加到任务文件，不加时间戳以外的任何处理。语音输入的好处是可以在走路、做家务、甚至洗澡的时候记录想法，这些场景下打字是不现实的。但缺点是转写可能出错，尤其是专有名词。我的做法是转写后不立即纠正，等晚上整理时再改，因为纠正本身会打断当前的活动。

6.2 用环境音遮蔽外部干扰

ADHD人群对声音干扰特别敏感，但又不能完全戴降噪耳机，因为可能错过重要提示。我的方案是播放白噪音或粉红噪音，音量刚好盖过环境噪音但不盖过提示音。粉红噪音比白噪音更柔和，长时间听不容易疲劳。我用sox生成一个无限循环的粉红噪音文件，用play命令循环播放，音量设在百分之二十左右。

这个方案的关键是噪音的音量要稳定，不能忽大忽小。我用的是一个固定的音频文件，不是实时生成的，所以音量恒定。另外，噪音的频谱要尽量平坦，不要有突出的频率，否则听久了会烦。粉红噪音在低频部分能量更高，听起来比白噪音更自然。如果觉得粉红噪音还是太吵，可以试试布朗噪音，更低频，更沉闷，适合需要深度专注的场景。

6.3 个人实践中的几点真实体会

我用这套工具快两年了，最大的体会是：工具能解决的问题是有限的，但有限的那部分解决好了，生活质量会有明显提升。以前我经常一整天什么都没干，晚上陷入自责，第二天更没动力。现在至少能保证每天有几个二十五分钟是真正在做事的，累积起来就很可观。工具没有治好我的注意力问题，但它给了我一个可以抓住的把手。

第二个体会是不要追求完美执行。我一开始给自己定规矩，每天必须完成八个时间盒，结果做不到就沮丧，沮丧就放弃。后来改成“能做几个做几个，做了就比没做强”，反而坚持下来了。工具是为人服务的，不是人为工具服务。如果某天状态特别差，一个时间盒都做不了，那就接受，明天再来。

第三个体会是定期回顾比日常使用更重要。我每周会花半小时翻看过去一周的任务文件，看看哪些任务反复出现但一直没做。这些任务通常要么是拆解不够，要么是根本不该做。前者继续拆，后者直接删。这个回顾过程帮我砍掉了很多“看起来应该做但其实不重要”的事，让任务列表越来越短，启动阻力越来越小。

最后分享一个小技巧：在任务文件的第一行永远放一个“最小任务”，比如“打开编辑器写一句话”。这个任务小到不可能失败，任何时候看到它都能立刻完成。完成之后，往往就有动力继续做下一个任务了。这个技巧我用了很久，屡试不爽。启动是最难的，一旦动起来，惯性会帮你走很远。