这个项目源于一个很真实的观察：很多人用手机、平板或者电子书阅读器看书，阅读统计页面上只有一个平均速度，但真正的问题在于阅读速度在十分钟内会不断漂移——快起来一目十行，慢起来一行能盯三十秒，而自己完全没有感知。等一本书读完，好像读了很多，能记住的内容却少得可怜。智能书立就是在这样一个场景下做的：把传统书立只负责“把书撑住”的物理功能，升级成带AI Agent的阅读行为感知与速度优化终端。它能实时感知阅读状态，判断当前是在精读、泛读还是已经走神了，然后通过电子墨水屏上的动态调整、环境光提示甚至轻微的触觉反馈，把阅读节奏拉回一个高效且可持续的区间。这套方案的适用对象很明确：想做智能硬件结合AI应用的人，关注阅读行为分析与边缘计算的人，以及对“速度优化”这件事有切身需求的长期阅读者。它本质上不是一个新的“阅读App”，而是一个把传统家居物件智能化、并且把AI Agent塞进边缘设备里的完整落地案例。1. 智能书立的定位与AI Agent的核心价值1.1 从物理书立到智能书立，到底改变了什么传统书立就一个功能：把一个或者一排书夹住，不让书倒。这东西用了上百年，已经非常成熟，几乎没有什么可优化的空间。真正值得做的是把书立从“被动支撑工具”变成“主动阅读助手”。我在设计这个项目时，首先明确了书立最自然的“观察位置”：书立立在书桌上靠近阅读者一侧，高度正好能覆盖到书页的上半部分，这个位置天然适合放传感器。它不像手机那样需要用户刻意低头看屏幕，也不像智能手表那样必须接触皮肤，它是一个“被忽视但始终在场”的设备。硬件底座的选型我踩过不少次，最后定的方案是这样的：一个窄条形书立形态的外壳，内部集成主控板、摄像头模组、毫米波雷达、电子墨水屏、光照传感器、扬声器和锂电池。正面朝向人的区域嵌入720p摄像头，用于捕捉用户头部姿态和注视方向；侧面向内朝向书页的位置放毫米波雷达，用于检测翻页动作和手部接近。电子墨水屏安装在书立的顶部斜面，不占用桌面空间，显示实时阅读速度和调整建议。这套硬件组合不需要很高的成本，关键是在于“设备始终在视野边缘”，不会像手机一样争夺注意力。它要做的是悄悄感知，在需要的时候才介入。1.2 AI Agent在阅读场景中的任务边界很多人会把“AI Agent”理解成一个聊天机器人，这是一个很常见的误区。在智能书立这个项目里，Agent的本质是一个感知-决策-执行闭环：感知模块持续判断用户的阅读行为，决策模块判断当前阅读状态是否健康，执行模块通过显示、灯光、声音或者振动把优化指令传递出去。这里要特别说明：Agent和普通的“规则引擎”不一样。规则引擎也能做“速度超过阈值就提醒”这类事情，但它没有目标建模能力。AI Agent会维护一个“当前阅读者画像”，包括习惯速度区间、持续专注时长、对提示的敏感程度，以及近五分钟的变化趋势。它不是在每个时刻独立判断“速度快了还是慢了”，而是把所有信息放在一个时序上下文里，综合判断“用户当前的学习效率是否在下降”。我在实际架构里把Agent拆成了四个子模块：行为感知模块：负责识别面部朝向、注视点停留、头部俯仰角度变化、手部翻页动作。速度评估模块：结合文本行信息和注视点的停留时间，估算出实时阅读速度。状态分类模块：把阅读状态分为“精读”、“泛读”、“扫描速读”、“注意力涣散”四类。干预策略模块：根据当前状态和历史状态，决定要不要干预，以及用什么方式干预。1.3 这套系统能解决的真实痛点阅读速度本身并不是越高越好。我见过很多朋友用“一周读十本”来标榜自己的阅读量，但如果你问他书里讲了什么，往往只能说出一个模糊的感觉。反倒是那些读得慢一些、偶尔停下来思考的人，输出质量高得多。智能书立要解决的核心矛盾是“自适应调速”和“主动干预”的平衡。它不试图把你的速度拉到一个固定值，而是把你的浮动区间压缩到一个合理范围内：既不会因为内容艰深而卡住不动，也不会因为内容浅显而飞速扫过。当系统检测到你连续三分钟速度低于正常区间的50%，会判断你可能遇到了理解障碍，此时电子墨水屏上会显示“建议放慢到当前速度的三分之二再回看一遍当前段”，而不是单纯催促你读快点。这个项目适合两类人参考。第一类是智能硬件创业者，可以借鉴的是“低成本传感器如何组合出可靠行为感知”的方案。第二类是阅读工具产品经理，可以借鉴的是“速度优化不是越快越好，而是找到每个人的最佳认知负荷区间”这个产品理念。2. 整体架构与关键选型2.1 感知层：传感器选型与布置感知层我最终选择了“摄像头 + 毫米波雷达 + 光照传感器”三合一方案，而不是只用摄像头。理由很简单：摄像头虽然能提供最丰富的视觉信息，但在弱光环境下表现不稳定，而且连续录像会带来隐私压力和功耗负担。毫米波雷达正好互补，它能低功耗感知手臂移动、翻页动作以及阅读者的接近距离，不依赖光线，也不采集任何生物特征。摄像头在方案里的定位是“注意力方向估计器”。我用的不是人脸识别，而是头部姿态估计模型。关键逻辑是：当人正在阅读时，面部朝向和视线方向会保持一个相对稳定的角度区间；如果摄像头捕捉到连续的头部偏转或低头时间异常，就可以判断用户可能在看手机、发呆或者趴下休息了。毫米波雷达的布置位置非常考究，我试过放在书立侧面和放在书立底部，最后确定的方案是靠近书脊一侧的斜上方。这个角度能同时覆盖三个观测区域：人手接近书本的路径、翻页时手掌的横向扫过、阅读者靠近书桌时的躯干距离。雷达的采样频率设置在20Hz就足够了，更高的频率只会增加功耗，并不会带来更准确的行为分类结果。光照传感器看着不起眼，但它是自适应显示的基础。因为电子墨水屏的对比度受环境光影响很大，如果室内灯光偏暗，墨水瓶显示的字体看起来就会模糊，用户会不自觉地凑近书本，这不仅影响阅读速度，还影响坐姿。光照传感器采集的数据会被Agent直接用于调整屏的字体粗细和背光亮度，形成“感知-执行”的小闭环。2.2 决策层：边缘端Agent的推理框架与模型决策层是整个系统的神经中枢。我评估过两种路径：一是把所有数据上传云端，让大模型处理后再下发指令；二是在设备端直接跑轻量化模型，云端只做模型的更新和个人画像的同步。最终我选了第二种，理由很直接：阅读行为数据非常个人化，而且阅读过程需要低延迟干预，如果每一次状态判断都要经过网络往返，数据感知到速度调整的延迟会达到几百毫秒，这在实时体验上是没法接受的。设备端跑的模型是基于轻量化姿态估计模型改造的。原来的模型是为了识别人体动作，我用阅读场景的标注数据做了迁移学习，在模型最后几层接入了一个状态分类头，可以同时输出头部姿态、视线方向和阅读状态三个预测结果。整个模型的参数量控制在千万级以内，在带NPU的嵌入式平台上可以做到单帧推理时间低于80毫秒。Agent的状态机设计是这样的：每2秒做一次全链路状态评估，以5分钟为窗口计算一个“阅读稳定性指数”，用这个指数来决定当前的干预强度。它的好处是避免“速度刚快了一点就立刻提醒”的神经质行为。实际体验中，如果系统过于敏感，用户会很快关掉提醒功能，所以在决策逻辑上我会强制加入“观察窗口”机制，任何干预指令都必须满足至少持续4秒的异常状态才能触发。2.3 执行层：电子墨水屏与提示交互电子墨水屏是执行层的主角，它有天然的优势：低功耗、不发光、类纸质感。我用了一块小尺寸墨水屏立在书立的斜面顶部，实时显示当前速度、目标区间和一句简短的调整建议。这里有一个很关键的设计选择，就是“不要用弹出式通知干扰阅读”。传统的智能设备习惯用弹窗提示，但用户正在看书时，视野内突然出现Logo、图标和文字弹窗，注意力会立刻被击穿。我的方案是让墨水屏保持极简风格：默认状态下只显示一个窄条速度计量表，颜色不变，数字很小；只有需要干预时，才显示一行建议文字并保持三秒，然后自动恢复为窄条显示。除了墨水屏，我还加入了微弱的音频提示。扬声器放在书立底部，正常情况下不发声。当系统判断用户的阅读速度连续五分钟高于舒适区上限、且内容复杂度较高时，会播放一声非常轻的“嗒”声，频率在500Hz左右，响度控制在40分贝以下，这个强度既能让用户注意到，又不会吓到人。还有一个很有意思的交互是触觉反馈。我在书立接触桌面的四个角落都加了微型振动马达，当Agent判断用户已经进入“注意力涣散”状态超过三分钟时，会以每15秒一次的频率轻轻振动桌面。这么做的好处是：提示不经过视觉通道，用户不会因为看了提示而中断阅读，而是下意识地重新聚焦到书本上。2.4 数据链路：本地决策为主、云端标定为辅整个系统的数据链路我坚持“本地决策优先”的原则。传感器采集的数据全部保存在本地，只有两种情况会触发云端通信：一是用户主动开启数据同步功能时，将阅读摘要（不包含原始视频或点云）上传；二是Agent模型版本更新时，从云端拉取新的模型权重。这么做有两个实际考虑。其一是隐私保护，书立长期放置在书桌上，摄像头和雷达会持续感知环境，如果数据全部上传，用户会产生很自然的心理抗拒，设备就会被闲置。其二是稳定可靠，阅读场景不能依赖网络，如果断网就罢工，这套系统就变成了一个电子书立，非常尴尬。我实际测试下来，本地决策链路的端到端延迟大约在300到500毫秒。具体分配是：传感器采集50毫秒、姿态推理80毫秒、状态分类40毫秒、显示刷新100毫秒，再加上一些余量。这个延迟对阅读场景来说可以接受，因为阅读不是一个需要“毫秒级响应”的任务，干预时机只要在一句话的边界附近出现，就能自然地融入阅读节奏。3. 阅读速度优化的核心算法与参数调优3.1 阅读速度的连续估计方法阅读速度的估计是整套系统的基础。传统方法很简单：拿一本书的总字数除以阅读总耗时，就能得到一个平均速度。但这个数值过于粗糙，它无法反映你在第十分钟状态下滑、第二十分钟又重新集中注意力的过程。智能书立需要的是“连续速度曲线”，而不是一个平均分。我的做法是把速度估计分解成两个尺度。小尺度上是“行级速度估算”：摄像头和雷达配合识别一次翻页动作，同时记录翻页前的总注视时长，然后根据当前书的行字数估算出翻页当行的阅读速度。大尺度上是“窗口速度估算”：以5分钟为滑动窗口，统计窗口内识别到的文本总行数，乘以每行平均字数，除以窗口时长，得到这个时间段的平均速度。行级速度容易受到单页停顿影响，波动极大；窗口速度足够平滑，但反馈太慢。实际使用中，我会把两者按0.3和0.7的权重融合，得到一个兼顾灵敏度和稳定性的实时速度估计。这个融合权重是我在多个测试场景下试出来的，如果只依赖行级速度，系统会频繁误报，因为用户很可能在某一段艰深内容上多停留了两分钟，这是合理行为，不能判定为“速度过慢”。def estimate_speed(window_chars, line_chars, window_seconds, line_duration): window_speed = window_chars / (window_seconds / 60) line_speed = line_chars / (line_duration / 60) fused_speed = 0.7 * window_speed + 0.3 * line_speed return fused_speed这里要特别注意文本来源问题。书立面对的可能是纸质书，系统并不能识别具体的文字内容，那怎么知道每行有多少字呢？我采取的方案是在Agent设置阶段让用户输入当前阅读书籍的字数和页数，系统会算出平均每页行数，再用视觉检测到的排版空白区域估算出实际行数，两者结合得到一个粗略的“每行字数”。这个方法不如OCR精确，但胜在隐私性好，而且不需要对书页拍摄高清照片，实际误差控制在15%以内，对速度优化来说足够用了。3.2 区分“略读”“精读”和“涣散”三种状态速度优化不能只看速度数字，还要结合行为特征理解“这个速度是怎么来的”。同样的每分钟400字，可能是流畅精读，也可能是走马观花地翻页。为了区分，我设计了一个“注视行为分类器”。它的输入特征是：头部俯仰角序列、注视点居中偏移量、翻页频率、手部静止时间。当一个用户处于精读状态时，面部会微微低垂，视线焦点在书页中上部位稳定，翻页动作间隔规律，手部移动少。当用户处于略读状态时，头部俯仰角变化较快，手部频繁调整书页位置，注视点跳动幅度较大。当用户处于涣散状态时，头部会不自觉抬高或者偏转，视线焦点可能长时间偏离书页区域，同时翻页间隔变得不规律。这个分类器我用了随机森林，而不是更复杂的深度学习模型。原因是阅读行为数据量不大，随机森林在小样本上表现稳定，而且可解释性强，能直接输出每个时刻属于三类状态的概率。为了让分类更准确，我还在特征里加入了“时间上下文”，也就是把前两分钟的状态序列也作为输入，让模型能识别出状态之间的转移趋势，比如从“精读”逐步滑向“涣散”的过程。3.3 动态调整策略：字号、行距与干预时机有了状态分类之后，Agent的作用就体现出来了。它不是机械地告诉你“你太快了”或者“你太慢了”，而是通过一组“软性调整策略”来干预阅读行为。首要干预手段是墨水屏上的“阅读锚点提示”。当Agent判定用户处于精读且速度偏快时，墨水屏会显示一条细线在当前行位置，起到视觉锚点的作用，帮助用户稍微放慢视线移动速度。如果速度偏慢且判定原因是内容理解困难，墨水屏会显示“建议回退到本页前三分之一处重读”，这个建议是基于翻页行为自动生成的。第二个干预手段是环境光微调。书立内置的补光LED灯带会在Agent判断用户表现疲劳时，将色温从明亮冷白逐渐过渡到温暖暖白。这个变化是缓慢的，用户往往不会明确感知到灯光变了，但身体会跟着放松下来，从而改善长时间阅读带来的视觉疲劳。第三个干预手段才是直接的规则提醒，但会包裹在“建议语气”里。我测试过多种提示文案，发现最有效的是“慢下来，回顾一下刚才这段”这句话，它不会让用户产生被命令的感觉。生硬的“速度过慢！请加快”会被绝大多数用户反感，最终导致功能被关闭。干预时机同样很重要。我在Agent逻辑里设定了一个“观察-确认-介入”三步流程。第一步，系统检测到异常状态后先观察4秒，不采取任何行动；第二步，如果4秒后状态依然异常，系统再次确认目标状态与历史趋势的一致性；第三步，确认无误后才触发对应的干预动作。这整个流程大概需要6到8秒，虽然看似有点慢，但能过滤掉绝大多数环境干扰导致的误判断。3.4 冷启动校准与个性化参数每个人的阅读速度基线都不同。一个常年读网络小说的用户，舒适速度可能在每分钟700字以上；一个阅读学术论文的学生，每分钟250字可能已经是在飞速翻阅了。智能书立必须支持个性化校准，否则优化就无从谈起。我的做法是设置一个“冷启动阶段”，即用户第一次开始阅读的前15分钟，Agent只记录数据，不做任何干预。这15分钟的数据会被用来计算个人的初始速度中位数、方差和典型注视时间长度。之后Agent以这个中位数为基准，把目标区间设置为“中位数的正负25%”，而不是用统一的绝对值。这套系统还支持长期学习。每次阅读结束后，Agent会把当天的速度曲线、干预次数和用户在干预后的反应记录下来，更新个人画像。如果发现用户经常忽略某个类型的提示，Agent会自动降低那类提示的触发频率，以防用户产生提示疲劳。这个设计非常重要，因为很多阅读工具失败在提示太频繁，最后用户把所有通知都关闭了。4. 落地过程中踩过的几个坑4.1 环境光照变化导致行为感知抖动第一个让我头疼的问题是光照传感器和摄像头在自然光环境下的互相干扰。晴天下午四点的阳光会从窗户斜射到桌面上，书立上的摄像头如果正对窗户，画面会过曝，导致头部姿态估计的准确率从正常的90%以上直接掉到70%左右。排查后发现，问题不只是摄像头过曝，更严重的是光照传感器会先一步判断“环境太亮”，自动调高墨水屏的对比度来适应。但这个调节又会影响摄像头画面中的明暗分布，造成姿态模型的输入分布发生偏移。这种传感联动形成的循环干扰，在晴天下午尤其明显。解决方案是给摄像头区域加了一片偏光镜片，同时把光照传感器的调节频率降低到每三秒一次，并且在算法层面增加一条规则：如果光照变化超过阈值，系统强制冻结当前姿态模型的输入参数，等待画面亮度重新稳定后再继续更新。一条简单的规则，解决了两个传感器互相“打架”的问题。4.2 头部微动被误判为“想要翻页”毫米波雷达检测翻页动作原本是为了辅助摄像头判断阅读进度，但我发现它对“伸手拿咖啡杯”和“翻页”的识别存在歧义。雷达利用多普勒效应感知移动目标，当人手快速横向扫过书本上方时，多普勒信号和翻页非常相似，经常被误判为一次翻页。问题的影响是实质性的：如果系统把一次“拿杯子”误判为翻页，它就会以为当前页阅读完毕，速度估计中的行数就会虚增，速度曲线也出现跳变。更麻烦的是，这个错误还会让Agent误以为用户阅读速度很快，在一段时间内降低干预强度。解决时我没有继续调高雷达阈值，而是采用了“传感器投票机制”：翻页动作必须同时满足毫米波雷达检测到扫过动作、摄像头捕捉到页面机器均匀的手腕旋转、以及墨水屏上的进度数据未发生冲突这三个条件，才会被确认。这个机制用了三周时间去验证，最终把误判率从12%降到了2%以下。4.3 电子墨水屏刷新方案干扰阅读连续性电子墨水屏的低功耗是优点，但它的刷新机制是个大坑。墨水屏最常见的刷新方式是全局刷新，每一屏内容更新时整块屏幕会先反色闪一下，从白色变成黑色再变回白色。这个闪烁如果出现在文字阅读过程中，会非常明显地打断视觉流。实验对比了几种刷新参数，发现局部刷新模式可以做到几乎无感，副作用是屏幕上会出现轻微的残留痕迹，特别是显示速度条这种边缘锐利的图形时，残影更加明显。为了兼顾无感和清晰度，我采用了一个折中方案：速度表使用细线条图形而非粗体块，并且每一分钟的整点时刻做一次完整的背景清洗刷新，其余时间全部用局部刷新。这个细节对阅读体验的提升非常明显。最开始用全局刷新时，几位测试者都反馈“屏幕每几分钟闪一下，会不自觉地抬头看屏幕”，改成局部刷新加定时清洗后，再也没有人提起屏幕闪烁的问题。4.4 功耗与实时性之间的取舍边缘设备的功耗约束和实时性要求是天然矛盾的。摄像头如果连续工作，系统功耗会接近1.5W，锂电池大概能撑六个小时；毫米波雷达连续工作的功耗只有0.2W，但单独使用又无法提供足够丰富的视觉信息。我的优化思路是分级唤醒。默认状态下，摄像头以每秒2帧的低帧率运行，仅做头部姿态的粗检测；毫米波雷达以20Hz频率运行，持续监测靠近和翻页事件。当雷达检测到用户已经开始阅读，也就是连续五分钟没有大幅度手臂动作时，摄像头才切换到每秒8帧的高精度模式。高精度模式只持续到阅读暂停为止。这套策略在实际使用中把平均功耗控制在了0.8W左右，待机功耗只有0.15W，充满电基本能保证一整天的阅读使用。对一款桌面设备来说，每天充电一次我可以接受，换来的是一整天低延迟的智能响应体验。5. 量化效果与后续扩展方向5.1 实测数据：速度波动区间缩小了多少我在验证阶段找了几位阅读习惯差异很大的测试者做了为期两周的使用记录，场景都是连续阅读三小时电子书或纸质书。采集的核心指标是“单位小时内的速度波动系数”，也就是速度曲线标准差除以均值。没有使用智能书立时，几位测试者的速度波动系数普遍在0.35到0.45之间。这个数值意味着什么？它表示在一小时阅读中，快段和慢段的速度差异最高能达到一倍以上。使用智能书立的AI Agent优化功能后，波动系数降到了0.18到0.25之间，阅读节奏变得明显平稳。更有参考价值的数据是“有效阅读时间占比”。系统按照状态分类器统计，没有优化时，测试者平均每小时有12到18分钟处于低效或涣散状态；启用优化后，这个数字减少到5到8分钟。低效状态时间缩短了60%左右，这是我最看重的数据，因为它说明速度优化不只是让用户“读得快”，而是让注意力更稳定。同时我也记录了一个值得警惕的副作用：有两名测试者在优化干预下阅读速度下降了大约一成，这主要是因为Agent在检测到内容艰深时会主动建议放慢节奏。但他们对应的理解率测试得分反而提升了，所以这个速度下降是健康的。5.2 从阅读速度到阅读质量：后续想做的事当前版本的核心指标是“速度波动优化”，下一个版本我希望把重点从“读得多快”迁移到“记住多少”。目前的Agent可以通过翻页频率和回看行为粗略推断理解率，但还缺少更细粒度的语义线索。一个可行的扩展方向是在书立中加入微距摄像头，在用户翻页前拍摄书页边缘的少量内容，结合OCR获得当前段落的部分文本，然后利用本地运行的小型语言模型生成该段落的“理解度自检问题”。用户不需要回答，Agent只需要记录用户在看到问题后的翻页延迟时间，就能判断是否真正理解。这个方案既能提供深度的阅读质量分析，又不会像考试一样打扰用户。另一个扩展方向是结合音频输入。如果书立能拾取用户阅读时的朗读声音，就能通过语音的流利度和停顿分布来判断阅读状态。默读时嘴巴不动，但能看到喉部微动和呼吸节拍的变化；朗读时可以直接分析语音信号。这些信息可以进一步增强Agent对阅读状态的判断能力。我在整个项目里最大的体会是：AI Agent在阅读场景中真正的价值并不是催人快读，而是帮人找到适合自己的节奏。速度优化这件事，指标上追求的是波动收敛和专注时长提升，体验上追求的却是让用户几乎感觉不到系统的存在。智能书立作为一个物理形态安静、感知能力克制、干预手段温和的Agent载体，恰好很适合承载这个目标。如果后续把阅读质量维度加上，这个书立就不再只是一个速度仪表盘，而是一个真正能陪人读书的桌面伙伴了。
这个项目源于一个很真实的观察：很多人用手机、平板或者电子书阅读器看书，阅读统计页面上只有一个平均速度，但真正的问题在于阅读速度在十分钟内会不断漂移——快起来一目十行，慢起来一行能盯三十秒，而自己完全没有感知。等一本书读完，好像读了很多，能记住的内容却少得可怜。智能书立就是在这样一个场景下做的：把传统书立只负责“把书撑住”的物理功能，升级成带AI Agent的阅读行为感知与速度优化终端。它能实时感知阅读状态，判断当前是在精读、泛读还是已经走神了，然后通过电子墨水屏上的动态调整、环境光提示甚至轻微的触觉反馈，把阅读节奏拉回一个高效且可持续的区间。这套方案的适用对象很明确：想做智能硬件结合AI应用的人，关注阅读行为分析与边缘计算的人，以及对“速度优化”这件事有切身需求的长期阅读者。它本质上不是一个新的“阅读App”，而是一个把传统家居物件智能化、并且把AI Agent塞进边缘设备里的完整落地案例。1. 智能书立的定位与AI Agent的核心价值1.1 从物理书立到智能书立，到底改变了什么传统书立就一个功能：把一个或者一排书夹住，不让书倒。这东西用了上百年，已经非常成熟，几乎没有什么可优化的空间。真正值得做的是把书立从“被动支撑工具”变成“主动阅读助手”。我在设计这个项目时，首先明确了书立最自然的“观察位置”：书立立在书桌上靠近阅读者一侧，高度正好能覆盖到书页的上半部分，这个位置天然适合放传感器。它不像手机那样需要用户刻意低头看屏幕，也不像智能手表那样必须接触皮肤，它是一个“被忽视但始终在场”的设备。硬件底座的选型我踩过不少次，最后定的方案是这样的：一个窄条形书立形态的外壳，内部集成主控板、摄像头模组、毫米波雷达、电子墨水屏、光照传感器、扬声器和锂电池。正面朝向人的区域嵌入720p摄像头，用于捕捉用户头部姿态和注视方向；侧面向内朝向书页的位置放毫米波雷达，用于检测翻页动作和手部接近。电子墨水屏安装在书立的顶部斜面，不占用桌面空间，显示实时阅读速度和调整建议。这套硬件组合不需要很高的成本，关键是在于“设备始终在视野边缘”，不会像手机一样争夺注意力。它要做的是悄悄感知，在需要的时候才介入。1.2 AI Agent在阅读场景中的任务边界很多人会把“AI Agent”理解成一个聊天机器人，这是一个很常见的误区。在智能书立这个项目里，Agent的本质是一个感知-决策-执行闭环：感知模块持续判断用户的阅读行为，决策模块判断当前阅读状态是否健康，执行模块通过显示、灯光、声音或者振动把优化指令传递出去。这里要特别说明：Agent和普通的“规则引擎”不一样。规则引擎也能做“速度超过阈值就提醒”这类事情，但它没有目标建模能力。AI Agent会维护一个“当前阅读者画像”，包括习惯速度区间、持续专注时长、对提示的敏感程度，以及近五分钟的变化趋势。它不是在每个时刻独立判断“速度快了还是慢了”，而是把所有信息放在一个时序上下文里，综合判断“用户当前的学习效率是否在下降”。我在实际架构里把Agent拆成了四个子模块：行为感知模块：负责识别面部朝向、注视点停留、头部俯仰角度变化、手部翻页动作。速度评估模块：结合文本行信息和注视点的停留时间，估算出实时阅读速度。状态分类模块：把阅读状态分为“精读”、“泛读”、“扫描速读”、“注意力涣散”四类。干预策略模块：根据当前状态和历史状态，决定要不要干预，以及用什么方式干预。1.3 这套系统能解决的真实痛点阅读速度本身并不是越高越好。我见过很多朋友用“一周读十本”来标榜自己的阅读量，但如果你问他书里讲了什么，往往只能说出一个模糊的感觉。反倒是那些读得慢一些、偶尔停下来思考的人，输出质量高得多。智能书立要解决的核心矛盾是“自适应调速”和“主动干预”的平衡。它不试图把你的速度拉到一个固定值，而是把你的浮动区间压缩到一个合理范围内：既不会因为内容艰深而卡住不动，也不会因为内容浅显而飞速扫过。当系统检测到你连续三分钟速度低于正常区间的50%，会判断你可能遇到了理解障碍，此时电子墨水屏上会显示“建议放慢到当前速度的三分之二再回看一遍当前段”，而不是单纯催促你读快点。这个项目适合两类人参考。第一类是智能硬件创业者，可以借鉴的是“低成本传感器如何组合出可靠行为感知”的方案。第二类是阅读工具产品经理，可以借鉴的是“速度优化不是越快越好，而是找到每个人的最佳认知负荷区间”这个产品理念。2. 整体架构与关键选型2.1 感知层：传感器选型与布置感知层我最终选择了“摄像头 + 毫米波雷达 + 光照传感器”三合一方案，而不是只用摄像头。理由很简单：摄像头虽然能提供最丰富的视觉信息，但在弱光环境下表现不稳定，而且连续录像会带来隐私压力和功耗负担。毫米波雷达正好互补，它能低功耗感知手臂移动、翻页动作以及阅读者的接近距离，不依赖光线，也不采集任何生物特征。摄像头在方案里的定位是“注意力方向估计器”。我用的不是人脸识别，而是头部姿态估计模型。关键逻辑是：当人正在阅读时，面部朝向和视线方向会保持一个相对稳定的角度区间；如果摄像头捕捉到连续的头部偏转或低头时间异常，就可以判断用户可能在看手机、发呆或者趴下休息了。毫米波雷达的布置位置非常考究，我试过放在书立侧面和放在书立底部，最后确定的方案是靠近书脊一侧的斜上方。这个角度能同时覆盖三个观测区域：人手接近书本的路径、翻页时手掌的横向扫过、阅读者靠近书桌时的躯干距离。雷达的采样频率设置在20Hz就足够了，更高的频率只会增加功耗，并不会带来更准确的行为分类结果。光照传感器看着不起眼，但它是自适应显示的基础。因为电子墨水屏的对比度受环境光影响很大，如果室内灯光偏暗，墨水瓶显示的字体看起来就会模糊，用户会不自觉地凑近书本，这不仅影响阅读速度，还影响坐姿。光照传感器采集的数据会被Agent直接用于调整屏的字体粗细和背光亮度，形成“感知-执行”的小闭环。2.2 决策层：边缘端Agent的推理框架与模型决策层是整个系统的神经中枢。我评估过两种路径：一是把所有数据上传云端，让大模型处理后再下发指令；二是在设备端直接跑轻量化模型，云端只做模型的更新和个人画像的同步。最终我选了第二种，理由很直接：阅读行为数据非常个人化，而且阅读过程需要低延迟干预，如果每一次状态判断都要经过网络往返，数据感知到速度调整的延迟会达到几百毫秒，这在实时体验上是没法接受的。设备端跑的模型是基于轻量化姿态估计模型改造的。原来的模型是为了识别人体动作，我用阅读场景的标注数据做了迁移学习，在模型最后几层接入了一个状态分类头，可以同时输出头部姿态、视线方向和阅读状态三个预测结果。整个模型的参数量控制在千万级以内，在带NPU的嵌入式平台上可以做到单帧推理时间低于80毫秒。Agent的状态机设计是这样的：每2秒做一次全链路状态评估，以5分钟为窗口计算一个“阅读稳定性指数”，用这个指数来决定当前的干预强度。它的好处是避免“速度刚快了一点就立刻提醒”的神经质行为。实际体验中，如果系统过于敏感，用户会很快关掉提醒功能，所以在决策逻辑上我会强制加入“观察窗口”机制，任何干预指令都必须满足至少持续4秒的异常状态才能触发。2.3 执行层：电子墨水屏与提示交互电子墨水屏是执行层的主角，它有天然的优势：低功耗、不发光、类纸质感。我用了一块小尺寸墨水屏立在书立的斜面顶部，实时显示当前速度、目标区间和一句简短的调整建议。这里有一个很关键的设计选择，就是“不要用弹出式通知干扰阅读”。传统的智能设备习惯用弹窗提示，但用户正在看书时，视野内突然出现Logo、图标和文字弹窗，注意力会立刻被击穿。我的方案是让墨水屏保持极简风格：默认状态下只显示一个窄条速度计量表，颜色不变，数字很小；只有需要干预时，才显示一行建议文字并保持三秒，然后自动恢复为窄条显示。除了墨水屏，我还加入了微弱的音频提示。扬声器放在书立底部，正常情况下不发声。当系统判断用户的阅读速度连续五分钟高于舒适区上限、且内容复杂度较高时，会播放一声非常轻的“嗒”声，频率在500Hz左右，响度控制在40分贝以下，这个强度既能让用户注意到，又不会吓到人。还有一个很有意思的交互是触觉反馈。我在书立接触桌面的四个角落都加了微型振动马达，当Agent判断用户已经进入“注意力涣散”状态超过三分钟时，会以每15秒一次的频率轻轻振动桌面。这么做的好处是：提示不经过视觉通道，用户不会因为看了提示而中断阅读，而是下意识地重新聚焦到书本上。2.4 数据链路：本地决策为主、云端标定为辅整个系统的数据链路我坚持“本地决策优先”的原则。传感器采集的数据全部保存在本地，只有两种情况会触发云端通信：一是用户主动开启数据同步功能时，将阅读摘要（不包含原始视频或点云）上传；二是Agent模型版本更新时，从云端拉取新的模型权重。这么做有两个实际考虑。其一是隐私保护，书立长期放置在书桌上，摄像头和雷达会持续感知环境，如果数据全部上传，用户会产生很自然的心理抗拒，设备就会被闲置。其二是稳定可靠，阅读场景不能依赖网络，如果断网就罢工，这套系统就变成了一个电子书立，非常尴尬。我实际测试下来，本地决策链路的端到端延迟大约在300到500毫秒。具体分配是：传感器采集50毫秒、姿态推理80毫秒、状态分类40毫秒、显示刷新100毫秒，再加上一些余量。这个延迟对阅读场景来说可以接受，因为阅读不是一个需要“毫秒级响应”的任务，干预时机只要在一句话的边界附近出现，就能自然地融入阅读节奏。3. 阅读速度优化的核心算法与参数调优3.1 阅读速度的连续估计方法阅读速度的估计是整套系统的基础。传统方法很简单：拿一本书的总字数除以阅读总耗时，就能得到一个平均速度。但这个数值过于粗糙，它无法反映你在第十分钟状态下滑、第二十分钟又重新集中注意力的过程。智能书立需要的是“连续速度曲线”，而不是一个平均分。我的做法是把速度估计分解成两个尺度。小尺度上是“行级速度估算”：摄像头和雷达配合识别一次翻页动作，同时记录翻页前的总注视时长，然后根据当前书的行字数估算出翻页当行的阅读速度。大尺度上是“窗口速度估算”：以5分钟为滑动窗口，统计窗口内识别到的文本总行数，乘以每行平均字数，除以窗口时长，得到这个时间段的平均速度。行级速度容易受到单页停顿影响，波动极大；窗口速度足够平滑，但反馈太慢。实际使用中，我会把两者按0.3和0.7的权重融合，得到一个兼顾灵敏度和稳定性的实时速度估计。这个融合权重是我在多个测试场景下试出来的，如果只依赖行级速度，系统会频繁误报，因为用户很可能在某一段艰深内容上多停留了两分钟，这是合理行为，不能判定为“速度过慢”。def estimate_speed(window_chars, line_chars, window_seconds, line_duration): window_speed = window_chars / (window_seconds / 60) line_speed = line_chars / (line_duration / 60) fused_speed = 0.7 * window_speed + 0.3 * line_speed return fused_speed这里要特别注意文本来源问题。书立面对的可能是纸质书，系统并不能识别具体的文字内容，那怎么知道每行有多少字呢？我采取的方案是在Agent设置阶段让用户输入当前阅读书籍的字数和页数，系统会算出平均每页行数，再用视觉检测到的排版空白区域估算出实际行数，两者结合得到一个粗略的“每行字数”。这个方法不如OCR精确，但胜在隐私性好，而且不需要对书页拍摄高清照片，实际误差控制在15%以内，对速度优化来说足够用了。3.2 区分“略读”“精读”和“涣散”三种状态速度优化不能只看速度数字，还要结合行为特征理解“这个速度是怎么来的”。同样的每分钟400字，可能是流畅精读，也可能是走马观花地翻页。为了区分，我设计了一个“注视行为分类器”。它的输入特征是：头部俯仰角序列、注视点居中偏移量、翻页频率、手部静止时间。当一个用户处于精读状态时，面部会微微低垂，视线焦点在书页中上部位稳定，翻页动作间隔规律，手部移动少。当用户处于略读状态时，头部俯仰角变化较快，手部频繁调整书页位置，注视点跳动幅度较大。当用户处于涣散状态时，头部会不自觉抬高或者偏转，视线焦点可能长时间偏离书页区域，同时翻页间隔变得不规律。这个分类器我用了随机森林，而不是更复杂的深度学习模型。原因是阅读行为数据量不大，随机森林在小样本上表现稳定，而且可解释性强，能直接输出每个时刻属于三类状态的概率。为了让分类更准确，我还在特征里加入了“时间上下文”，也就是把前两分钟的状态序列也作为输入，让模型能识别出状态之间的转移趋势，比如从“精读”逐步滑向“涣散”的过程。3.3 动态调整策略：字号、行距与干预时机有了状态分类之后，Agent的作用就体现出来了。它不是机械地告诉你“你太快了”或者“你太慢了”，而是通过一组“软性调整策略”来干预阅读行为。首要干预手段是墨水屏上的“阅读锚点提示”。当Agent判定用户处于精读且速度偏快时，墨水屏会显示一条细线在当前行位置，起到视觉锚点的作用，帮助用户稍微放慢视线移动速度。如果速度偏慢且判定原因是内容理解困难，墨水屏会显示“建议回退到本页前三分之一处重读”，这个建议是基于翻页行为自动生成的。第二个干预手段是环境光微调。书立内置的补光LED灯带会在Agent判断用户表现疲劳时，将色温从明亮冷白逐渐过渡到温暖暖白。这个变化是缓慢的，用户往往不会明确感知到灯光变了，但身体会跟着放松下来，从而改善长时间阅读带来的视觉疲劳。第三个干预手段才是直接的规则提醒，但会包裹在“建议语气”里。我测试过多种提示文案，发现最有效的是“慢下来，回顾一下刚才这段”这句话，它不会让用户产生被命令的感觉。生硬的“速度过慢！请加快”会被绝大多数用户反感，最终导致功能被关闭。干预时机同样很重要。我在Agent逻辑里设定了一个“观察-确认-介入”三步流程。第一步，系统检测到异常状态后先观察4秒，不采取任何行动；第二步，如果4秒后状态依然异常，系统再次确认目标状态与历史趋势的一致性；第三步，确认无误后才触发对应的干预动作。这整个流程大概需要6到8秒，虽然看似有点慢，但能过滤掉绝大多数环境干扰导致的误判断。3.4 冷启动校准与个性化参数每个人的阅读速度基线都不同。一个常年读网络小说的用户，舒适速度可能在每分钟700字以上；一个阅读学术论文的学生，每分钟250字可能已经是在飞速翻阅了。智能书立必须支持个性化校准，否则优化就无从谈起。我的做法是设置一个“冷启动阶段”，即用户第一次开始阅读的前15分钟，Agent只记录数据，不做任何干预。这15分钟的数据会被用来计算个人的初始速度中位数、方差和典型注视时间长度。之后Agent以这个中位数为基准，把目标区间设置为“中位数的正负25%”，而不是用统一的绝对值。这套系统还支持长期学习。每次阅读结束后，Agent会把当天的速度曲线、干预次数和用户在干预后的反应记录下来，更新个人画像。如果发现用户经常忽略某个类型的提示，Agent会自动降低那类提示的触发频率，以防用户产生提示疲劳。这个设计非常重要，因为很多阅读工具失败在提示太频繁，最后用户把所有通知都关闭了。4. 落地过程中踩过的几个坑4.1 环境光照变化导致行为感知抖动第一个让我头疼的问题是光照传感器和摄像头在自然光环境下的互相干扰。晴天下午四点的阳光会从窗户斜射到桌面上，书立上的摄像头如果正对窗户，画面会过曝，导致头部姿态估计的准确率从正常的90%以上直接掉到70%左右。排查后发现，问题不只是摄像头过曝，更严重的是光照传感器会先一步判断“环境太亮”，自动调高墨水屏的对比度来适应。但这个调节又会影响摄像头画面中的明暗分布，造成姿态模型的输入分布发生偏移。这种传感联动形成的循环干扰，在晴天下午尤其明显。解决方案是给摄像头区域加了一片偏光镜片，同时把光照传感器的调节频率降低到每三秒一次，并且在算法层面增加一条规则：如果光照变化超过阈值，系统强制冻结当前姿态模型的输入参数，等待画面亮度重新稳定后再继续更新。一条简单的规则，解决了两个传感器互相“打架”的问题。4.2 头部微动被误判为“想要翻页”毫米波雷达检测翻页动作原本是为了辅助摄像头判断阅读进度，但我发现它对“伸手拿咖啡杯”和“翻页”的识别存在歧义。雷达利用多普勒效应感知移动目标，当人手快速横向扫过书本上方时，多普勒信号和翻页非常相似，经常被误判为一次翻页。问题的影响是实质性的：如果系统把一次“拿杯子”误判为翻页，它就会以为当前页阅读完毕，速度估计中的行数就会虚增，速度曲线也出现跳变。更麻烦的是，这个错误还会让Agent误以为用户阅读速度很快，在一段时间内降低干预强度。解决时我没有继续调高雷达阈值，而是采用了“传感器投票机制”：翻页动作必须同时满足毫米波雷达检测到扫过动作、摄像头捕捉到页面机器均匀的手腕旋转、以及墨水屏上的进度数据未发生冲突这三个条件，才会被确认。这个机制用了三周时间去验证，最终把误判率从12%降到了2%以下。4.3 电子墨水屏刷新方案干扰阅读连续性电子墨水屏的低功耗是优点，但它的刷新机制是个大坑。墨水屏最常见的刷新方式是全局刷新，每一屏内容更新时整块屏幕会先反色闪一下，从白色变成黑色再变回白色。这个闪烁如果出现在文字阅读过程中，会非常明显地打断视觉流。实验对比了几种刷新参数，发现局部刷新模式可以做到几乎无感，副作用是屏幕上会出现轻微的残留痕迹，特别是显示速度条这种边缘锐利的图形时，残影更加明显。为了兼顾无感和清晰度，我采用了一个折中方案：速度表使用细线条图形而非粗体块，并且每一分钟的整点时刻做一次完整的背景清洗刷新，其余时间全部用局部刷新。这个细节对阅读体验的提升非常明显。最开始用全局刷新时，几位测试者都反馈“屏幕每几分钟闪一下，会不自觉地抬头看屏幕”，改成局部刷新加定时清洗后，再也没有人提起屏幕闪烁的问题。4.4 功耗与实时性之间的取舍边缘设备的功耗约束和实时性要求是天然矛盾的。摄像头如果连续工作，系统功耗会接近1.5W，锂电池大概能撑六个小时；毫米波雷达连续工作的功耗只有0.2W，但单独使用又无法提供足够丰富的视觉信息。我的优化思路是分级唤醒。默认状态下，摄像头以每秒2帧的低帧率运行，仅做头部姿态的粗检测；毫米波雷达以20Hz频率运行，持续监测靠近和翻页事件。当雷达检测到用户已经开始阅读，也就是连续五分钟没有大幅度手臂动作时，摄像头才切换到每秒8帧的高精度模式。高精度模式只持续到阅读暂停为止。这套策略在实际使用中把平均功耗控制在了0.8W左右，待机功耗只有0.15W，充满电基本能保证一整天的阅读使用。对一款桌面设备来说，每天充电一次我可以接受，换来的是一整天低延迟的智能响应体验。5. 量化效果与后续扩展方向5.1 实测数据：速度波动区间缩小了多少我在验证阶段找了几位阅读习惯差异很大的测试者做了为期两周的使用记录，场景都是连续阅读三小时电子书或纸质书。采集的核心指标是“单位小时内的速度波动系数”，也就是速度曲线标准差除以均值。没有使用智能书立时，几位测试者的速度波动系数普遍在0.35到0.45之间。这个数值意味着什么？它表示在一小时阅读中，快段和慢段的速度差异最高能达到一倍以上。使用智能书立的AI Agent优化功能后，波动系数降到了0.18到0.25之间，阅读节奏变得明显平稳。更有参考价值的数据是“有效阅读时间占比”。系统按照状态分类器统计，没有优化时，测试者平均每小时有12到18分钟处于低效或涣散状态；启用优化后，这个数字减少到5到8分钟。低效状态时间缩短了60%左右，这是我最看重的数据，因为它说明速度优化不只是让用户“读得快”，而是让注意力更稳定。同时我也记录了一个值得警惕的副作用：有两名测试者在优化干预下阅读速度下降了大约一成，这主要是因为Agent在检测到内容艰深时会主动建议放慢节奏。但他们对应的理解率测试得分反而提升了，所以这个速度下降是健康的。5.2 从阅读速度到阅读质量：后续想做的事当前版本的核心指标是“速度波动优化”，下一个版本我希望把重点从“读得多快”迁移到“记住多少”。目前的Agent可以通过翻页频率和回看行为粗略推断理解率，但还缺少更细粒度的语义线索。一个可行的扩展方向是在书立中加入微距摄像头，在用户翻页前拍摄书页边缘的少量内容，结合OCR获得当前段落的部分文本，然后利用本地运行的小型语言模型生成该段落的“理解度自检问题”。用户不需要回答，Agent只需要记录用户在看到问题后的翻页延迟时间，就能判断是否真正理解。这个方案既能提供深度的阅读质量分析，又不会像考试一样打扰用户。另一个扩展方向是结合音频输入。如果书立能拾取用户阅读时的朗读声音，就能通过语音的流利度和停顿分布来判断阅读状态。默读时嘴巴不动，但能看到喉部微动和呼吸节拍的变化；朗读时可以直接分析语音信号。这些信息可以进一步增强Agent对阅读状态的判断能力。我在整个项目里最大的体会是：AI Agent在阅读场景中真正的价值并不是催人快读，而是帮人找到适合自己的节奏。速度优化这件事，指标上追求的是波动收敛和专注时长提升，体验上追求的却是让用户几乎感觉不到系统的存在。智能书立作为一个物理形态安静、感知能力克制、干预手段温和的Agent载体，恰好很适合承载这个目标。如果后续把阅读质量维度加上，这个书立就不再只是一个速度仪表盘，而是一个真正能陪人读书的桌面伙伴了。