Show HN：ReadKinetic——免费、本地优先的速读器，读你自己的书
文章摘要
ReadKinetic 是一个免费的、纯浏览器端运行的 RSVP 速读器，作者是 Esat Turan（HN 用户 SamuraiLion，自述是医学生）。
它的核心机制是 RSVP（Rapid Serial Visual Presentation，快速序列视觉呈现）：每次只在屏幕上的一个固定位置显示一个词，于是你的眼睛不再需要在页面上移动。按站点自己的说法，这消除了阅读的”机械成本”——词与词之间的跳视、每行末尾回到下一行开头的长距离回扫，以及对已经读懂的内容不自觉回看的反射（regression）。
本地优先是它的另一个立足点：文件的打开、解析和存储全部发生在你自己的浏览器里，从不上传到任何地方；也正因如此，应用一旦加载完成，断网后依然可用（它是一个 PWA）。没有账号，没有登录。
支持的格式相当齐全：EPUB（从书里读取章节、封面、书名和作者，直接从第一章打开）、PDF（在文本进入阅读界面前剔除页眉、页脚和页码）、无 DRM 的 Kindle 格式（MOBI、AZW3、PRC——带 DRM 的文件是加密的，任何浏览器都读不了，它会明说而不是导入一本空书）、FictionBook（FB2）、Word/OpenDocument/PowerPoint 系列（DOCX、DOC、DOTX、ODT、ODP、PPTX、ABW、RTF）、LaTeX、reStructuredText、Org-mode、Markdown、HTML、纯文本，以及直接从剪贴板粘贴的文字。语言方面支持英语、日语、中文、泰语、高棉语、老挝语和缅甸语——这些无空格分词的文字会做真正的分词，而不是把整段一次闪出来。
交互设计是触屏优先的：按住阅读区域即开始播放，松手停止；双击进入免手持连续播放；左右滑动是拖拽定位（scrub），上下滑动调节速度；桌面端有空格、方向键和完整键盘映射。阅读位置、速度和字体都是按每本书分别记住的，存在本地。
HN 评论精华
105 分、68 条评论。这条帖子的一大特点是作者 SamuraiLion 的回复极其详尽、技术性强且异常坦诚，几乎每条回复都在讲清楚一个具体的工程或认知取舍。（有意思的是，评论区末尾 satvikpendem 提醒他：”顺便说一句，你的评论正在被自动封禁，可能是因为新账号，也可能是因为写得太像 AI 触发了 HN 的检测器。”）
节奏（cadence）算法——本帖最受赞赏的技术细节
- tommytman 问：”我喜欢它停顿的位置和我平时读书会停的地方很接近，这个节奏是怎么定的？”
- 作者答这正是他最希望有人注意到的细节。最初是固定间隔，感觉糟透了——每个词都占同样的时间槽，句子永远”落不了地”，读起来像股票行情跳动。现在的做法是：由 WPM 设置得出一个基础时长，再叠加逐词的乘数——句末标点 3 倍，逗号和分号 2 倍，词长 8 个字符以上额外 0.7 倍。标点权重来自他把段落大声念出来、观察自己实际在哪里停顿——那些是换气点，给它们按比例更多的时间就把句子结构还了回来；长词加成则更接近眼动研究文献，注视时长随词长增加，”一个 12 个字母的词和 ‘the’ 占同样的时间槽就是不对的”。具体数字是靠大量真实阅读用耳朵调出来的。他也试过音节估计和词频加权，但都没有比”标点 + 词长”明显更好，反而让节奏更不可预测——而节奏的可预测性比技巧上的聪明更重要。
- achr2 建议加一个前瞻机制：如果预判到一个”不太可能一眼认出”的词要来了，就稍微减速。
RSVP 到底损失了什么——最有价值的认知讨论
- kadhirvelm：”对我来说最大的启示是，我平时居然在无意识地跳读那么多内容。要一个一个词地读完、记住并理解，比我预想的费劲得多。而且我才发现自己有多依赖词间的排版格式。”
- 作者的回答是全帖最重要的一段：正常阅读时人会跳过大约四分之一到三分之一的词，主要是 “the”、”of” 这类小词，你的眼角余光会在真正看到它们之前就抓到接下来的一两个词。RSVP 省下了眼动，但同时也剥夺了跳读能力——不管重不重要，每个词你都必须看。这两个因素可能互相抵消，而这很可能就是实际速度提升远低于大多数速读产品承诺的根本原因。他还承认排版丢失的问题他没解决：换行、段落形状、余光里的标点、以及”你在页面上处于哪里”的空间感全都没了；他用标点处的更长停顿找回了一部分句子韵律，但段落结构和对话结构仍然缺席——所以这个工具对大量对话的小说不管用。
- hazn：”我试过很多这类东西，对我不管用。词闪进脑子里，我能在很高的 WPM 下跟上’阅读’，但整个句子不成立。见了树，不见林。”
- broken-kebab 问背后的理论是什么。作者给了教科书级的回答：假设是阅读时间的很大一部分不是花在解码词上，而是花在移动眼球上；回看（regressions）占阅读时间的 10-15%，RSVP 把词固定在一处，消除了所有这些眼动，理论上只剩下词识别所需的时间。但他紧接着自我拆台：实践中这大概比不上用自己的眼睛读——你不能跳词，不能在走神时回退（原则上可以做”退回上一行”，但这需要额外时间，这类功能是双刃剑）。最受益的人群是那些平时回看最多、或最容易丢失位置的读者；它让”本该一口气读完”的散文变得更轻松更快，但在密集材料上、或视觉呈现本身承载信息的材料上会惨败。他还加了一句：”有些人的大脑就是不适合这个，这不是他们的错。”
关于速读本身的价值之争
- dombiscoff 唱反调：”在我看来这是徒劳。这种对速度的无限追求主要由那些不经常读书的人推动，所以他们不明白理解力恰恰来自停顿、翻页和回看。如果没有时间消化，那到底是在读一本书，还是只是在临场读一份稿子？”
- 作者的回应很有分寸：他承认其中很多点自己也认同，理解力确实随速度下降，整个行业确实过度吹嘘，所以他倾向于设一个务实的上限而不是标榜一个巨大数字。他认为论证的破绽在于把所有阅读归为同一类——为消遣读小说，和在拿到关键那 5 页之前先趟过 40 页背景资料，是根本不同的活动。”我是医学生，我的阅读大部分是第二种。你没法用愉悦的方式去’消化’一篇文献综述，唯一真正的目标就是过一遍而不被卡住。”他还指出，今天给他最深入反馈的人显然都是重度阅读者，这不是给不读书的人用的工具。
- satvikpendem：”或者像我这样，读得多、读得快，还想读更多。不是每个人都跟你一样。”他每周读一到两本、通常是大部头；读《魔戒》或密集内容时会慢下来，读通俗小说甚至非虚构时会快。作者由此得到一个关键洞见：分类的关键不是虚构/非虚构，而是”你为什么读”——是来感受语言本身，还是只是要拿到要点；并顺势意识到阅读速度应该按书记忆，而不是做成全局设置（既然位置已经是按书记的）。Arshad-Talpur 也独立提出了同样的需求。
- gverrilla 站在中间：”我同意对效率的追求最终是反效率的，但 RSVP 确实有些合理场景：屏幕小到放不下一段话（智能手表）、标题或通知的快速分诊，以及无障碍——比如眼动控制受损的人。”
- KSFirasa 说如果真要吸收材料，他必须慢下来，因为问题不在于眼睛认不认得词，而在于理解和留存达不到 100%。
产品与工程细节的问答
- carterEthan 问大 EPUB/PDF 的性能。作者答：解析是唯一的一次性成本，之后只是遍历一个词数组，900 页长篇和一个短篇的表现完全一样。PDF 最糟，用 pdf.js 需要逐页取文本层；EPUB 快得多，基本就是解压加解析 xhtml。真正的关键优化是把 IndexedDB 拆成两个 store——元数据一个、全文一个，这样打开书库列表时只读元数据，不会把所有书的全文拉进内存。最大的边界情况是没有文本层的扫描版 PDF（没有 OCR，什么都取不到），目前失败得不够响亮。
- Aaoo 和 wuschel 都问图表怎么处理。作者坦承这是当前的软肋：解析器只抽文本层，图片被直接丢弃，甚至不会告诉你这里原本有张图；表格比丢掉还糟——PDF 抽取会把表格按阅读顺序摊平成一串数字流。EPUB 好办，因为图片就是 zip 里的文件、在 spine 中位置明确，可以在正确的位置显示图片、暂停、等待按键继续——”你可以给文字定速，但你没法给一张图定速，没有合理的办法猜一个人需要看多久。”他还反思了图注：现在图注作为普通词流过去，你会看到”图 3 展示了……”一个词一个词地出现却看不到图；图注应该和图片绑定并排显示。表格大概也该当成图片渲染。
- jmiskovic 提出了作者称为”今天所有人给我的最好的点子”的建议：做一个类似代码编辑器 minimap 的低保真段落背景图，高亮当前词的位置。作者认为这一条同时解决了另外三个人提出的问题——RSVP 丢失的所有脚手架（段落断点、行距、你在文中的位置感）都能靠这个被动感知的外围地图找回来，而且它能提前告诉你”一首诗或不同段落风格要来了”，让你切换阅读模式，而不是以 400 WPM 的散文模式一头撞进去。段落和章节断点信息他已经有了，这只是渲染问题。jmiskovic 还建议主题选择的圆形图标应该预览真实的文字/背景配色，并指出应用不该分成两个模式（主界面应该吸收另一个的滚动和书签功能），作者都表示认同。
- 控制方式的可发现性是本帖最集中的用户抱怨。dithernaut、miguelxt、abuhl98、Arshad-Talpur、kesor、flowerbreeze 都反映找不到怎么调速或怎么切换播放模式。作者的回应很诚恳：上下方向键或垂直拖拽可以调速，双击锁定连续播放，但”提示行写的是 ‘Hold to read · ←→ scrub’，只字未提速度控制——你照着我发布的说明做了，而说明是错的。刚修好，可发现性优化本周排在队列最前面。”他还解释了为什么默认用”按住才读”：一旦你不在读，词就立刻停下来，注意力飘走时词不会继续往前跑——这对一个以专注为全部目的的应用来说是对的，但大多数人的直觉不是这样。dithernaut 还提出”保存成功”的 toast 弹窗会让人漏掉几个词，希望有个无 UI 的”禅模式”。作者的自我批评很到位：这个格式的全部基础是你的眼睛永远不用离开同一块区域，在词的旁边弹任何东西都恰好制造了它想消除的那次跳视——它直接攻击了它自己唯一的功能；而且自动保存本来就不该回显什么。
- m3rone 和 anoop_kumar 都提到了 E-ink。作者的分析很具体：E-ink 恰恰是人们真正读书的显示器，却是最不适合做这件事的显示器——局部刷新每秒只能更新几次且有残影，300 WPM（每 200 毫秒一个词）意味着你会透过前两三个词的残迹阅读；全刷能清干净，但整屏闪烁且慢到每秒只能一个词。对于”按句显示”的替代方案，他认为这不是变差而是变成了另一种东西：整句上屏后眼睛又会横扫，”无眼动”就没了，但保留下来的是消除回扫和消除在密集页面上丢失位置——那本来就是真实的痛点，按句分块更接近”引导式配速”而不是 RSVP，也许反而更适合一本书。
- lagrange77 建议和 Calibre 集成。作者的分析：明显的钩子是 Calibre 的内容服务器，但浏览器集成很笨拙——calibre-server 不吐跨源 CORS 头，让用户为了一个小工具去改 CORS 配置是个糟糕的交易。真正可行的路径是目录导入：Calibre 把一切按 Author/Title 文件夹存成普通文件，每本书旁边有 metadata.opf，用目录选择器遍历、读 opf 拿到真实书名作者（而不是靠文件名猜）、直接吸入 epub，会是很顺滑的批量导入。代价是 File System Access API 目前只有 Chromium 支持，Firefox/Safari 用户仍需逐个选文件——但这是可以优雅降级的划算取舍。
- jodysalt、jmiskovic 和另外几人都要浏览器扩展。作者说”今天下午你是第三个提这个的人，所以下一个任务显然就是做扩展”，并给出了他偏好的设计：转发型（右键把选中文本转发过去）比整页解析型是更好的原语，因为用户已经告诉你他想要什么，不需要那么多解析启发式。而且最妙的是完全不需要服务器——readkinetic.com 上的 content script 可以在同源下直接写入应用的 IndexedDB，扩展只是把你已经打开的页面的文本交给本地的阅读器副本，什么都不经过他的服务器。他还觉得”给网站嵌入一个’速读本页’按钮”的反向玩法很酷，同样的技巧倒过来用，连 fetch 都不用做，唯一的麻烦是要用 shadow DOM 和小体积包避免被宿主页面的样式弄乱。
- ohaodha 分享了自己的终端速读项目 ogma，用配置文件定义预处理钩子来转换 PDF 或网页。作者认为这比自己的做法干净得多：终端里可以 shell out 到 pdftotext 或 pandoc，用户用自己已经信任的转换器；而浏览器里你得把所有格式转换器打进下载包（他打包了 pdf.js、JSZip 和 mammoth），还是处理不了没见过的格式。
- olejorgenb 指出 Spritz 是大多数人最早见到这个概念的地方。作者确认并补充了谱系：RSVP 本身可追溯到 70 年代关于”无眼动时人能多快读词”的阅读研究；Spritz 的主要创新是识别点（recognition point）的最佳位置——把它固定住，让词的其余部分围绕它变化，加上上下的框架元素。他坦言自己用了这些，”没必要去申请别人早就开创的东西的专利”。他做这个的动机是：Spritz 只以 SDK 形式内嵌在别的应用里，从来没有独立的阅读器，你没法提交自己的 epub。
- celltalk 说自己在 DuoBook（语言学习应用）里也实现了 RSVP，两人交流了轴心字母（pivot）对齐问题——在比例字体里，轴心两侧字符间距变化会让整个词在眼前滑动；作者的做法是锚定轴心字符、让词的其余部分向两侧自由延伸，celltalk 则花了至少一周后接受”大约每一百个词会偏一点”。
- satoyoshidev 问日文书怎么办（没有空格，RSVP 按什么切分），rvnikita 问 iOS 应用计划，作者未在帖中作答。
- UnfinishedCompl 是唯一的敌意评论：”我不知道啊老哥。你做了不代表你就得分享。这为什么是头条新闻。”——然后贴了自己两周前 vibe 出来的同类东西。