ADHD Reader开源组件：把单词固定在屏幕中央的RSVP阅读器！

生物黑客、AI医疗 ADHD Reader开源组件：把单词固定在屏幕中央的RSVP阅读器！ #ADHD #生产力黑客 #注意力 #GitHub工具库推荐 2026-09-21 6K banq
患有注意力缺陷多动障碍的人经常会漏看页面上的一行字：你移开视线片刻，再回来，那句话就消失了。然后你不得不反复阅读同一段文字，直到你关闭标签页。

这是一个设计相当考究的 RSVP（快速序列视觉呈现）阅读器组件，代码质量和文档完整度在同类开源项目中属于上乘。

这个github项目（点击标题）功能：

• 文字始终锁定在中心
• ORP字母（视线落点）以红色突出显示
• 像“in the”这样的短词会被粘在一起，这样它们就不会闪烁。
• 逗号/句号的停顿时间会稍长一些。
• WPM滑块范围从100到900

技术栈：React + TypeScript + Vite，部署在 Vercel 上。MIT 许可，您可以复制该组件。

在线演示： 

ADHD阅读器（ADHD Reader）把每个单词都钉在屏幕正中央，让你的眼睛彻底停止左右扫视！

读三行就分心的人，这次有救了！

ADHD阅读器（ADHD Reader）是一个无运行时依赖的React组件，用RSVP技术把单词固定在屏幕中央，配上ORP锚点和节奏暂停，帮注意力缺陷多动障碍用户读完长文。你可以把它嵌进任何React应用，也可以只用它的引擎。

为什么快速闪烁的单词反而让你读不进去

你盯着屏幕，一个单词闪过去，又一个闪过去，眼睛还没来得及反应，句子已经跑到第五个词了。你往回翻，重新读，又分心了。

这就是大多数RSVP阅读器给人的第一印象。RSVP的全称是Rapid Serial Visual Presentation，快速序列视觉呈现，原理很简单：把一段文字拆成单词，一次只显示一个，固定在同一个位置，你的眼睛不需要移动，理论上阅读速度能翻好几倍。

理论很美好，现实很残酷。绝大多数RSVP工具只做了一件事，就是把单词按固定间隔闪出来。你设定每分钟300词，它就每200毫秒换一个词。你设定每分钟600词，它就每100毫秒换一个词。所有单词一视同仁，不管这个词是“a”还是“antidisestablishmentarianism”，不管后面跟着逗号还是句号，不管它是段落开头还是段落中间。

你的大脑收到的是一串没有节奏、没有重音、没有停顿的视觉轰炸。一开始你觉得很爽，速度确实快，但读到第三段你就开始走神了。不是因为你注意力差，而是因为这种节奏违背了大脑处理语言的基本方式。

大脑理解一句话，靠的不只是识别单个单词。它需要预测节奏，需要在逗号处稍微停一下，在句号处停得更久，在长单词上多花一点时间。这些停顿和变化本身就是意义的一部分。你把它们全部抹掉，大脑就失去了方向感。

ADHD阅读器（ADHD Reader）的作者看到了这个问题。这个组件没有追求“最快”，它追求的是“读得下去”。它给每个单词算了一个锚点，给标点加了不同的暂停时间，还把短词合并成词组来减少闪烁次数。这三件事加在一起，把一个粗糙的闪烁工具变成了一个能真正用来读长文的引擎。

ADHD Reader把单词钉在屏幕中央，眼睛终于不用动了

传统阅读的时候，你的眼睛在做两件事：一是识别单词，二是移动位置。每读一行，眼球要跳好几次，每次跳跃之后还要重新对准焦点。这个动作叫扫视，它消耗的注意力比你想象的多得多。

ADHD阅读器（ADHD Reader）把这件事彻底取消了。所有单词都出现在同一个地方，你的眼睛不需要移动，只需要识别。光是这一步，就释放了大量认知资源。

但光是“不动”还不够。如果单词简单地居中显示，长单词会把锚点推到左边，短单词会把锚点推到右边，你的眼睛虽然不移动，但每次换词的时候还是需要微调焦点。ADHD Reader解决这个问题的方式是ORP，全称是Optimal Recognition Point，最佳识别点。

眼动研究发现，人眼识别一个单词的时候，并不是从第一个字母开始看的，而是落在单词偏左的某个位置。这个位置随单词长度变化，但不是线性的。ADHD Reader把单词长度分成五档：1个字母的词，锚点在第1个字母；2到5个字母的词，锚点在第2个字母；6到9个字母的词，锚点在第3个字母；10到13个字母的词，锚点在第4个字母；14个字母以上的词，锚点在第5个字母。

这个锚点字符会被涂成红色，并且用一对焦点刻度固定在屏幕中央。不管单词多长，这个红色字符始终在同一个位置。你的眼睛只需要锁定这个红色字符，整词的其他字母会向左右两边展开。

前导标点会被跳过。比如一个引号开头的单词，锚点不会落在引号上，而是落在引号后面第一个字母的ORP位置上。这个细节看起来很小，但它决定了你换词的时候眼睛要不要微调。有了ORP，你换词的时候几乎不需要任何眼球微动，红色字符的位置就是你的视觉锚点，从头到尾不变。

布局用的是三列网格，左边一列、中间自动宽度、右边一列。中间那一列放的是ORP字符，左右两列分别是ORP之前的字母和之后的字母。这种布局让ORP字符天然居中，不需要任何绝对定位或者JavaScript计算。

光有ORP不够，节奏才是让大脑不累的关键

ORP解决了眼睛的问题，但大脑的问题还没有解决。如果一个RSVP阅读器只是把每个词按同样的间隔闪出来，你的大脑会很快感到疲劳，因为它找不到节奏。

ADHD阅读器（ADHD Reader）给每个词帧算了一个延迟倍数。实际延迟时间是60000除以设定的每分钟词数，再乘以这个倍数。倍数可以叠加，标点、词长、段落位置都会影响它。

句末标点.、!、?、…的倍数是2.4，意味着遇到句号的时候，这个词会在屏幕上多停留1.4倍的时间。冒号、分号、破折号、连接号的倍数是1.8。逗号的倍数是1.5。右引号和右括号的倍数是1.2。段落换行的倍数是1.6，普通换行的倍数是1.15。

长单词也会得到额外时间。超过8个字符的部分，每多一个字符加0.04倍，上限是1.6倍。也就是说一个16个字符的长词会得到接近1.6倍的延迟。

短词合并也会增加延迟。如果当前帧合并了多个单词，每多合并一个词加0.15倍。所以“in the house”作为一个帧显示的时候，会比单独一个“house”多停留0.3倍的时间。

这些倍数相乘，最终的时间会拉开明显的差距。一个句末的长词可能得到2.4乘以1.6等于3.84倍的延迟，而一个句中的短词可能只有1.0倍。你的大脑在这种节奏里能找到呼吸感，它知道句号后面会慢下来，逗号后面会稍微慢一点，长单词后面会多给一点时间。

这种节奏不是机械的。它是基于语言学规律设计的，模仿的是你在默读时自然的停顿模式。ADHD Reader没有发明一套人为的节奏，它只是把默读时本来就存在的节奏搬到了屏幕上。

短词合并：为什么“in the house”要当成一个词来闪

RSVP阅读器有一个天然的缺陷：如果每个单词单独闪烁，你的视觉系统会感受到强烈的闪烁感。尤其是遇到连续短词的时候，比如“in the house”这种结构，三个词在600毫秒内闪过去，屏幕在不停地亮灭亮灭，你的大脑会觉得晃眼。

ADHD阅读器（ADHD Reader）的解决方案是短词合并。如果一个单词长度不超过4个字符，没有尾随标点，并且在功能词列表里，它就会被合并到下一个单词。合并可以链式进行，“in”可以合并成“in the”，“in the”可以继续合并成“in the house”。但链式合并有上限，最多合并3个单词，总长度不超过14个字符。

合并之后，ORP在最长的那一个单词里计算。所以“in the house”的锚点落在“house”上，而不是被粘住的“in”上。你的眼睛始终落在信息量最大的那个词上，而不是功能词上。

功能词列表是分语言的。英语有一份列表，包含了常见的介词、冠词、连词、代词。ADHD Reader还支持自动语言检测，它会扫描文本，根据短词列表的匹配情况来判断这段文字是英语还是其他语言。目前只支持英语和自动检测，也就是说它实际上只能处理空格分词的语言。

这个限制很重要。中文、日文、泰文这些语言没有空格，短词合并的逻辑完全不适用。ADHD Reader的文档里没有明确说“只支持英语”，但类型定义里语言选项只有auto和en，自动检测的目标也只有英语。这是一个需要用户自己发现的边界。

合并之后还有一个好处：闪烁次数减少了。一段100个单词的文本，经过短词合并之后可能变成60个帧。帧数减少意味着屏幕亮灭的次数减少，视觉疲劳也会降低。对于ADHD用户来说，减少视觉噪音本身就是一种注意力保护。

无依赖组件，你可以把它塞进任何React应用

ADHD阅读器（ADHD Reader）和Spreeder这样的RSVP阅读网站有一个本质区别。Spreeder是一个独立网站，你只能打开它的页面，把文字粘贴进去，然后在它的界面里阅读。你没法把Spreeder的阅读引擎嵌到你自己的博客、笔记应用或者学习平台里。

ADHD Reader是一个React组件。你可以用npm install把它装进你的项目，然后在你的代码里写一行，阅读器就出现在你的页面上了。没有运行时依赖，除了React本身。样式用的是Tailwind CSS v4的工具类，如果你不用Tailwind，可以把类名换掉，逻辑部分完全不依赖样式。

这个组件的接口设计支持受控和非受控两种模式。最简单的用法是给它一段文字，它自己管理速度和字号。如果你想让外部页面控制这些设置，可以传入wpm、theme、fontSize这些属性，再用对应的回调函数接收变化。组件内部用一个useControllableState钩子统一处理这两种情况，API很干净。

它还有一个无头引擎useRsvpReader。你可以完全不用它的UI，只用这个钩子来驱动你自己的标记。它返回当前词帧、播放状态、进度、播放和暂停函数。你可以用任何你想要的方式来展示单词，比如用Canvas画，用WebGL渲染，或者用纯文本。

命令式句柄也暴露出来了。你可以在组件上挂一个ref，然后从外部调用toggle、play、pause这些方法。这样你就可以用你自己的按钮来控制阅读器，而不需要用它内置的控制面板。

这些设计选择指向同一个目标：ADHD Reader不试图成为一个完整的阅读应用，它只做RSVP引擎和最基本的展示层。剩下的部分留给使用者。你可以把它嵌进Notion风格的编辑器，嵌进在线课程平台，嵌进电子书阅读器，嵌进任何你需要的地方。它不抢你的界面，不强迫你用它的一套UI。

这个定位和Spreeder形成了清晰的差异。Spreeder是一个目的地，ADHD Reader是一个零件。你去Spreeder的网站读书，你把ADHD Reader装进你自己的产品里。

它的节奏系统里藏着一个还没被验证的假设

ADHD Reader的节奏因子表看起来很有道理，句号停2.4倍，逗号停1.5倍，长单词多给时间，短词合并多给时间。这套规则是基于语言学直觉和阅读研究设计的，但它有没有被严格验证过，文档里没有说。

有一个具体的数字值得追问：为什么句末标点的倍数是2.4，而不是2.0或者3.0？为什么逗号是1.5而不是1.3？这些数字的来源是眼动追踪实验，还是作者自己的阅读体验？文档没有给出引用。

更关键的问题是，这些因子对不同阅读速度的人是不是都适用。在每分钟200词的速度下，2.4倍的句末延迟意味着句号后面会停720毫秒。在每分钟600词的速度下，同样的2.4倍只停240毫秒。慢速阅读的人可能觉得240毫秒的停顿太短，快速阅读的人可能觉得720毫秒太长。节奏因子是固定的，但人对节奏的感知是随速度变化的。

这个矛盾没有被解决。ADHD Reader的节奏系统比大多数RSVP工具都精细，但它仍然假设一套固定的倍数能适应所有速度和所有读者。这个假设是否成立，需要有人拿不同速度的真实读者去测。

如果这个假设不成立，那么最需要节奏感的那些读者，可能恰恰是固定倍数最不适用的人。这个组件把节奏做得越精细，这个未验证的假设就越值得被认真对待。