手机尺寸墨水屏阅读器，内置本地AI助手的设计与实现

还记得去年朋友问我你做了一台又一台阅读器为什么这次死活要卡在智能手机尺寸上我翻了翻兜里的手机和背包里的6英寸电纸书一时不知道怎么回答。直到DuRoBo Krono的原型机点亮屏幕这个问题才真正有了答案——当一台电子阅读器小到能像手机一样随手滑进裤兜却内置了一个能帮你查词、总结、解释概念的AI助手它才不再是一块能看书的平板而是另一种完全不同的专注阅读终端。这篇文章我就把这台DuRoBo Krono的设计思路、硬件选型、AI助手落地和真实使用感受完整写一遍给想复刻的朋友一个参考也给正在纠结阅读器到底该做多大的人一些启发。DuRoBo Krono的定位很明确一台硬件尺寸接近主流智能手机、屏幕采用墨水屏的电子阅读器同时内置本地优先的AI助手不依赖云端账号不强制联网所有阅读相关的辅助能力都在设备上运行。它适合每天通勤时间超过半小时的人、需要大量读长文的用户以及愿意折腾硬件和软件的极客玩家。下面我从头开始拆解这个项目。1. 为什么我会做一台手机尺寸的阅读器1.1 从6英寸到5.2英寸被很多人忽略的便携分界线市面上绝大多数电子阅读器都集中在6英寸到8英寸因为Kindle从很早以前就把6英寸培养成了电子书标准尺寸。这个尺寸确实适合排版PPI做到300之后文字锐利度也足够但问题出在便携两个字上。我试过把6英寸阅读器放进冬季大衣口袋勉强能塞进去但走路时硌腿放到牛仔裤后袋更是想都别想。出差时背包里本来就有笔记本电脑、充电器、相机再塞一台6英寸的阅读器每次都感觉是在为可能不会看的一本书买单。真正让我痛下决心的场景是早高峰地铁一只手拉着扶手另一只手掏出6英寸阅读器单手拇指根本覆盖不到物理翻页键必须要用四指托住机身、拇指去够按键站不稳的时候整个人都在晃。后来我把一台备用的5.2英寸墨水屏手机改装成纯阅读器用了一个月后意识到屏幕只小了0.8英寸但握持手感和口袋兼容性完全不是一个量级。5.2英寸机身的宽度通常在68mm到70mm之间和iPhone标准版、大部分安卓手机基本一样成年人手掌可以完整包住拇指能自然落在屏幕边缘或物理按键上。这才是智能手机尺寸最核心的体验红利不是屏幕小而是身体对它的真实感受跟手机一致。1.2 手机尺寸不是缩小屏幕而是重新定义握持很多人一听到手机尺寸阅读器第一反应是那和你直接用手机看书有什么区别我有iPhone/Mate/Pixel何必多带一台设备。这话没毛病前提是你只把阅读器当成一块能显示书的屏幕。但真正上手DuRoBo Krono之后你会发现在同样的尺寸下电子阅读器的握持逻辑和手机完全不同。手机是被设计成双手协作的设备左手托右手点屏幕亮着、消息弹着、应用互相切换。而DuRoBo Krono是被设计成单手沉浸的设备机身左右两侧各有两颗物理翻页键拇指放在侧边键上每按一次翻一页全程不需要在屏幕上戳来戳去。屏幕不发光或者采用前光眼睛聚焦在内容上手指动作极其机械、单调反而更容易进入深度阅读状态。所以手机尺寸的本质是在物理上与手机共享人体工学优势在交互上刻意甩掉手机的操作习惯。它牺牲了多任务、牺牲了弹窗、牺牲了花哨动画换来的是更长的续航、更少的干扰和更自然的单手握持。我用DuRoBo Krono读完过一本九十多万字的社科大部头中途一次都没觉得手酸这在6英寸阅读器上很难做到。1.3 项目的目标用户通勤阅读者、长文研究者和极客这个项目不是面向所有人的它的目标用户非常清晰。第一类是通勤阅读者每天往返通勤超过40分钟需要一台能随时掏出来、单手翻页、不打扰别人的设备。第二类是长文研究者需要读论文、读技术文档、读史料经常遇到不懂的术语、上下文不清的表述他们需要的不只是翻页而是立刻搞懂的能力。第三类是极客和DIY爱好者享受自己画板、打印外壳、调系统、把大模型塞进小设备的过程。如果你属于这三种人你会从DuRoBo Krono里拿到比普通Kindle多很多的价值。如果你只是想买一个盖泡面用的装饰品那用6英寸的便宜阅读器就够了不必折腾这一台。2. 硬件选型在墨水屏和AI推理之间找平衡2.1 屏幕与刷新为什么是5.2英寸黑白墨水屏整个项目里最难选的其实不是主控而是屏幕。市面上的小尺寸墨水屏方案不如6英寸和7英寸丰富黑色面板比较多彩色墨水屏在5.2英寸这个规格下也几乎找不到合适的模组。最终我选了一块5.2英寸的黑白墨水屏分辨率按这个尺寸算下来接近300 PPI显示文字时边缘干净性价比也比较合理。选择黑白屏有几个现实原因一是彩色墨水屏的刷新率更低色彩饱和度也不适合长时间看文字二是AI助手生成的卡片内容以文字为主不需要颜色区分重点三是黑白屏的驱动逻辑简单刷新残影更容易控制。这块屏的驱动电压和时序是标准的墨水屏协议主控通过SPI接口就能控制前光采用侧置LED导光板亮度调节用PWM整体功耗控制得很好。但墨水屏也有一个绕不开的物理特性刷新慢、有残影。尤其是当AI助手渲染出一大段文字时如果整屏刷新会有一阵明显的黑膜闪烁。后面我在软件层面对AI卡片区域做了局部刷新处理只在需要清除残影时才全刷使用体验好了非常多。这一段放到第五节详细讲。2.2 主控选型低功耗ARM板卡如何兼顾AI推理墨水屏设备对算力的要求其实很低但加上本地AI助手这个需求后主控的选择就要重新考虑了。我最初尝试过用一颗比较老的1.2GHz双核处理器跑阅读器界面绰绰有余但一旦加载量化后的大语言模型生成一个字的耗时能超过半秒等AI把整段摘要输出完人已经不耐烦了。后来换成了四核Cortex-A55架构的处理器主频提高到1.8GHz左右配合2GB内存才勉强达到翻卡片不卡顿的体验。在内存上的教训是尽量不要低于2GB。跑一个1.5B参数、4bit量化的大模型光模型权重就要占900MB到1.1GB内存再加上系统、阅读器渲染层和刷新缓冲区2GB实际上已经很紧。如果后期想换更大模型至少要上3GB甚至4GB内存的板卡但目前我在DuRoBo Krono上用的方案是2GB LPDDR4跑小模型刚刚好成本也能压住。AI推理这块我没有用独立的NPU而是直接用CPU跑量化后的GGUF格式模型。虽然没有NPU那种十几mW就能跑本地模型的能力但对阅读器这种非实时交互设备来说CPU推理已经够用——你选中一句文字按下快捷键本来就需要两三秒的思考时间墨水屏的刷新还没完成AI其实已经把答案生成好了。2.3 结构件与续航3D打印外壳和3000mAh电池外壳是我用3D打印机自己打印的材料是哑光黑色PETG原因很简单耐热、耐脏、不容易在手里出汗打滑。整体的造型参照了常见的直板手机长边大约150mm短边大约70mm厚度做到9mm以内这样才能保持手机感。电池是一块3000mAh的聚合物锂电池平放着占掉机身背面将近一半空间剩下的一半放主控板、屏幕驱动板和扬声器小模块。整机功耗让我自己都挺惊讶。墨水屏维持显示时不耗电只有刷新瞬间才需要能量所以纯阅读模式下的平均功耗压得非常低。实测数据是使用场景平均功耗3000mAh实际表现待机Wi-Fi关闭约30mW超过25天纯阅读前光关每分钟翻页约160mW约18小时阅读AI助手每10分钟调用一次约550mW约5.5小时阅读AI助手前光中等亮度约800mW约3.5小时这个数据是在我自己搭建的电流采样测试电路上反复测出来的。如果你复刻时把电池加到4000mAh续航还能再提升三分之一。对一台可以连续用一天半的设备来说我认为已经达到日用不焦虑的标准了。3. AI助手到底在阅读器上能干什么3.1 真正高频的阅读场景查词、句子释义和背景补充很多阅读器都有词典查词功能但传统词典只能给你一个词条的孤立解释放在句子里往往还是不通顺。阅读一本历史书遇到均田制这个词词典会告诉你它是北魏到唐前期的土地制度但如果你不理解这个词在这个段落里的因果关系依然读得一头雾水。DuRoBo Krono里的AI助手不是这样工作的。它能够把当前页面的完整段落作为上下文针对你选中的词语或句子生成一段并解释为什么它在这里出现的说明。比如读《全球通史》遇到黑死病与劳动工资的关系这一句它给出的不是黑死病是一种鼠疫而是结合上下文告诉你由于劳动力骤减庄园主被迫提高工资这成为封建农奴制解体的诱因之一。这种带上下文的解释才是阅读辅助该有的样子。另外还有两个高频功能我几乎每天都在用一是长句子的白话翻译有些一百多字的复杂长句读第一遍真的看不懂让AI把它拆成几个短句并补充主语立刻通顺二是时间线梳理遇到一段涉及多个人名、年份和事件的内容直接让AI提炼成编号列表非常方便。3.2 段落级对话选中文字直接问AI助手的交互是我调过最久的部分因为墨水屏上没有方便的软键盘必须把交互设计得足够简单。最终我采用的方式是阅读器界面上用方向键移动光标在当前段落里选中一句或一段文字然后按一下AI快捷键屏幕上会弹出一个操作卡片里面有四个选项解释这段、生成摘要、翻译成白话、和它对话。前三个选项都是即时的AI会自动把结果渲染在一个新卡片上显示完可以一键关闭返回阅读页面。第四项和它对话会进入一个轻量级的问答界面你可以用预设的快捷问句来追问或者通过蓝牙键盘输入具体问题。我日常用最多的是解释这段和翻译成白话因为不需要额外输入点一下就行。这个交互模式特别适合阅读场景它不会频繁打断你的阅读流。我们常说的心流说到底就是过滤掉多余操作当你想搞懂一个内容时能用最快速度获得答案然后继续读下去。AI助手在这里的角色其实更像一个随叫随到的读书搭子而不是一个抢你注意力的聊天机器人。3.3 本地优先隐私和离线是底线为什么不直接把AI功能接到云端大模型的API我在项目早期确实试过用手机热点把整段文本发到云端等几秒收到回复功能上也能跑通。但我很快发现了三个无法接受的问题第一是隐私。阅读器里的内容往往是个人笔记、未出版的书稿、私人日记把这些东西发到云端哪怕只是用来生成摘要我心理上始终过不去。第二是网络依赖。地铁、地下通道、飞机上网络信号要么没有要么极差而阅读场景恰恰发生在这些地方。一次对着转圈的网络等三十秒你会无比怀念本地模型。第三是成本。云API按token计费每天厚读三小时一个月下来流量费用完全够买一台新设备了。所以DuRoBo Krono的AI助手从第一天起就定了本地优先的路线。模型、推理脚本、UI全部运行在设备上没有任何遥测数据断网状态下所有功能照常工作。我不否认云端模型在理解力上更强但在阅读器这个特定场景里牺牲一点模型大小换取完全离线、零成本、隐私闭环是绝对划算的。4. 软件系统和AI功能落地4.1 系统方案轻量Linux加定制阅读应用DuRoBo Krono的软件栈没有选择现成的Android阅读器改改原因很直接安卓系统的图形渲染、后台进程和电源管理对墨水屏并不友好而且为了跑一个本地模型还要被系统各种机制拖后腿。我采用的是轻量Linux发行版砍掉桌面环境只保留内核、核心库和一个自研的阅读器应用整个系统体积控制在500MB以内。阅读器界面用的是嵌入式UI框架LVGL字体渲染单独做了灰度抗锯齿文字在墨水屏上的显示效果比很多商业产品还要柔和。整个系统的状态栏有三块信息左上角显示当前阅读进度右上角显示日期下方不固定显示一个AI按钮只有在你阅读时按快捷键才会出现。这里有一个值得说的设计细节系统的所有界面更新都走了墨水屏的灰度级渲染通道。普通LCD屏幕每秒刷新60帧甚至120帧但墨水屏只需要在内容变化时更新一次。我的应用里维护了一个自定义的脏矩形队列页面切换时用小范围刷新AI卡片弹出时用高对比度刷新避免频繁整屏抖动这比直接用现成框架默认驱动要舒服得多。4.2 AI助手的实现管道从文字选中到模型推理AI助手的工作流程看起来简单实际实现时要经过一条完整的管道。第一步是获取当前段落文字。因为墨水屏阅读器显示的是电子书源文件不是扫描图片所以可以直接从解析后的文本层拿到当前选中的内容不需要OCR。但如果读者打开的是PDF扫描件文本层不存在系统就会自动调用内置的OCR引擎把页面图片转成文字再交由AI处理。OCR引擎用的是开源Tesseract的一个轻量化模型识别速度在1到2秒之间对大多数印刷体PDF效果足够好。第二步是组装提示词。这是我反复调优的重点因为小模型的指令遵循能力不如大模型你必须把提示词写得非常明确。比如解释这段功能实际发给模型的提示词模板是你是阅读辅助助手。请用150字以内结合上文语境解释下面的段落。不要跑题。段落内容{{text}}。格式限定得越清晰输出越稳定。第三步是模型推理。我选用的模型是1.5B到3B之间的小尺寸模型转换为GGUF格式后做4bit量化。在四核A55 CPU上1.5B模型的生成速度大约为每秒8到12个token输出一段150字的解释大概需要20秒左右。听起来不快但对阅读器场景完全够用——因为你阅读时本来就不可能每十秒就提一个问题。我实测每次AI交互的平均响应时间是15到25秒正好和墨水屏的慢节奏匹配。第四步是结果渲染。生成时模型是逐token输出的如果每个token都触发一次墨水屏刷新不仅慢还会疯狂闪烁。我处理的方式是缓冲输出积累到300毫秒或50个字符才刷新一次局部区域并且在卡片底部显示一个细小的阅读进度条告诉用户AI还在写。最终完整生成后再以卡片形式停留几分钟不会打扰连续阅读。4.3 语音与快捷键没有触摸屏的时候怎么交互很多墨水屏阅读器都有触摸层但为了降低反光、减少厚度我给DuRoBo Krono准备的是一块没有触摸层的面板。这意味着所有交互都要靠物理按键完成。左右两侧的翻页键除了翻页还承担了其他功能短按AI键直接弹出上下文菜单长按可以切换选中段落和当前整章的粒度菜单导航用方向键和确认键来实现。这个设计刚开始用会觉得回到了功能机时代但习惯之后反而是优点。触摸屏上的手势操作必须眼睛盯着而物理按键可以盲操作在早晚高峰的地铁里尤其方便。你一只手握着设备拇指在侧面按键上就能完成选中、调用AI、确认、关闭卡片的全流程完全不需要另一只手帮忙。语音交互我也做了一个可选的蓝牙麦克风模块平时不装在机身上用的时候通过蓝牙配对。这个模块主要解决想输入长问题的场景比如你正在读哲学文本想追问作者这段话是否在回应康德的自由概念只靠按键选短语表达不清这时候按住机身侧面的麦克风键说一句系统先用本地语音识别转成文字再把文字送给模型。因为语音识别和模型推理都在本地整个过程不会超过40秒算是一个比较实用的辅助功能。5. 实际体验与避坑我用DuRoBo Krono读了3个月5.1 通勤体验单手操作和不同温度下的表现我从冬天开始测试DuRoBo Krono正好赶上通勤包里塞羽绒服、围巾、手套的月份。把阅读器塞进羽绒服外兜走到地铁站的十分钟里完全感觉不到它的存在这是之前的6英寸阅读器给不了的体验。上车之后左手拉住吊环右手掏出Krono拇指按翻页键整个过程一气呵成。你可能会觉得和手机放一起不就行了吗但问题在于我在通勤路上并不想看到手机上的消息通知。DuRoBo Krono没有SIM卡、没有通知、没有任何红点它唯一会主动弹出来的东西就是AI助手的解释卡片。这种随时可以掏出来又不会被社交应用绑架的设备体验只有单功能阅读器做得到。冬天还有一个意想不到的问题在低温环境下低于5℃墨水屏的刷新速度会明显变慢残影也更重。我在室外站台上按翻页键能感觉到页面切换的拖泥带水。后来在软件里加了一个温度补偿逻辑检测到温度传感器读数低于10℃时把前光自动提高一档同时强制每次翻页后多等80毫秒再允许下一次刷新残影问题缓解了不少。5.2 续航实测AI使用的频率是影响续航的最大因素前面表格里的数据是我在实验室环境下测的实际用下来确实有波动。如果只是每天通勤两小时纯阅读不调用AIDuRoBo Krono可以做到三周充一次电这比很多商用电纸书还要猛。如果晚上读专业书每隔二十分钟用一次AI助手查术语、做总结一天会消耗30%左右的电量两天一充基本是常态。这里我想特别提醒所有想复刻的朋友本地AI是功耗大户但不是必须全程开启的服务。我一开始做成了每次选中文字后AI自动解释结果续航直接腰斩而且大多数时候你其实只是想翻页并不需要解释。后来改成手动触发AI只有按下快捷键才启动推理进程续航立刻恢复正常。设计上一定要把AI做成按需启动而不是随叫随到常驻进程。另外还有一个小细节Wi-Fi模块是休眠功耗的主要来源。如果开了Wi-Fi但没连上任何网络它每分钟都会扫描一次热点直接把待机时间从25天拉到10天左右。所以我的系统里增加了一个断网模式开关日常强制关闭Wi-Fi只有需要同步书库或系统更新时才手动打开。虽然这个功能很难用智能来形容但对续航的增益非常实际。5.3 踩坑记录刷新残影与AI卡片的闪瞎眼这个项目里调试最久的问题是AI卡片内容输出时的闪烁。墨水屏刷新本来就会闪而AI模型是逐个token生成的如果每生成一个字就触发一次局部刷新屏幕看起来就像在疯狂抽搐十几秒下来人会有明显的不适感。我试过三种方案第一次是整屏刷新结果每生成一小段就白闪一次眼睛受不了第二次是每50个token刷一次局部区域仍然有点快最后改成积攒文本碎片、定时刷新效果才稳定下来。具体参数是AI输出过程中每500毫秒刷新一次目标区域每次刷新只更新新增的文字行。因为LVGL的局部刷新支持脏矩形机制我可以在模型输出流不断写入文字时只把那几行文字的矩形区域标记为需要刷新。这样AI输出虽然持续十几秒但屏幕每半秒只闪一下小块区域完全不会干扰阅读。等输出完毕再执行一次清残影的全刷把过去的文字残影彻底去掉。另一个坑是AI卡片的样式。最开始我让AI输出的文字直接沿用电子书正文的排版结果在屏幕上看AI生成的文字和正文混在一起读者根本分不清哪里是书里的、哪里是AI补的。后来我把AI卡片的背景做得比正文底色深两档卡片外沿加了一条细边框底部增加AI生成标签。这样一眼就能分辨来源也更安全——读者知道这段话是机器生成的不会误以为它是原文内容。5.4 其他值得分享的小问题还有两个小问题值得写一下。一是屏幕前光的光路设计如果导光板边缘没有做好遮光条前光亮度调到最低时屏幕四周会有一圈明显暗影看起来特别廉价。我后来在3D打印外壳内侧贴了一圈黑色绝缘胶带才把漏光解决。二是电磁干扰墨水屏的驱动信号线如果离电池太近刷新时会出现一两行横纹需要重新走线或者加屏蔽层。这两个问题在工程设计上都不难但如果是第一次做这类设备很容易被它们卡几个晚上。6. 未来改进方向与复刻思路6.1 换更大的模型内存上限与NPU加速目前为止DuRoBo Krono跑的是1.5B规模的量化模型能够在2GB内存的板子上稳定运行。但我自己很清楚1.5B模型在复杂文本的理解上还是不够强遇到隐喻密集的诗学批评、逻辑链很长的技术文档偶尔会给出比较表面的回答。我目前正在往3B模型方向迁移但3B模型4bit量化后大约需要1.8GB内存加上系统开销2GB内存已经不够了下一步计划是把板卡换成4GB内存版本。如果换到带NPU的板子AI推理速度会有质的提升。目前CPU推理速度是每秒8到12个tokenNPU方案可以跑到每秒20到30个token。这意味着AI卡片的生成时间从20秒缩短到10秒以内交互体验会明显上一个台阶。但代价是NPU方案的板卡功耗更高、价格更贵实际续航会打折。对于纯阅读器来说我认为CPU方案更加平衡。6.2 让AI助手记住前文本地向量数据库现在DuRoBo Krono的AI助手是无记忆的它只根据你选中的段落和简单指令来回答不会记住你上一章读了什么。这个设计让单次回复更独立、不容易跑偏但当你问前文提到的主人公和这里的角色是不是同一个人时它就没法回答了。我正在尝试在系统里加入一个本地向量数据库把整本书的文本段落预先切成若干块转成向量存起来AI在回答问题时先检索最相关的几个段落再把上下文注入到提示词里。这样它就能把前文的含义拉进当前对话同时还能做整本书范围内的检索问答比如问这本书里一共出现几次自由意志的讨论分别在哪几章。这个功能一旦跑通DuRoBo Krono的阅读辅助能力会完全站在另一个层面。6.3 开源物料清单和复刻建议如果你想自己动手做一台类似的阅读器我建议不要一上来就追求完全复刻我的组装方案而是先做三件事找一块5.2英寸左右、带前光的墨水屏模组找一块用四核A55或更强处理器、内存至少2GB的ARM开发板确认它跑Linux之后对SPI屏幕驱动和USB键鼠的兼容性。这三件套定了剩下的外壳和电池反而是最简单的事。在硬件上有条件的话优先选带NPU、内存可扩展到4GB的上板卡这样后续升级模型不需要重新画主板。电池尽可能选标称容量高一点的聚合物电池控制在机身尺寸允许范围内即可。系统层面先把稳定性做起来再考虑AI功能如果连阅读器本身的翻页刷新都没有调到舒适加再多的AI功能也只是花架子。我把这次项目的物料清单、外壳打印模型和系统镜像的整理工作放在了项目仓库里读代码和配置文件比看文章更能学到细节。这个项目最大的魅力不是我做了一台能看书的机器而是它让我重新理解了设备尺寸、AI能力和使用场景三者之间的平衡关系。最后再分享一个小技巧无论你采用什么硬件方案一定要注意电源管理中的AI进程生命周期。不要让它常驻后台只在用户明确触发AI操作时拉起进程回答完成后立即释放内存和关闭推理线程。我在第一次版本里就是因为没有做这个导致阅读器在反复唤起AI后内存碎片累积最终出现翻页卡顿甚至系统重启。做好这一步你的设备续航和稳定性都会明显上一个台阶。