现实版“汤姆·里德尔日记”：开发者在reMarkable平板上重现哈利波特魔法

核心要点

• 沉浸式魔法体验：高度还原《哈利·波特》电影中的交互，用户手写的墨水会被页面“吸收”消失，随后AI会以手写体自动回复。
• 无UI交互设计：彻底摒弃了屏幕背光、键盘和传统的聊天界面（Chat UI），仅保留手写笔与纸张的纯粹触感，追求极致的沉浸感。
• 底层硬件驱动：项目通过root权限直接驱动e-ink引擎，利用raw evdev获取4096级压感数据，实现高精度的手写捕捉。
• 复杂的渲染流程：回复内容经过LLM生成后，通过特定字体骨架化处理，模拟真实的逐笔书写过程，而非简单的文本弹出。
• 特定硬件限制：目前仅适配reMarkable Paper Pro（ferrari），且需要开启开发者模式并安装特定加载器，具有一定的技术门槛。

详细分析

魔法交互的技术内核：从压感到流式回复

Riddle项目的核心在于其对硬件底层的深度掌控。根据开发者Maxime Rivest在GitHub上的技术文档，该系统通过raw evdev直接监听手写笔的输入事件。这意味着它能够捕捉到全量程的4096级压力感应以及硬件级别的事件频率，确保了书写体验的细腻度与原始设备的笔触感保持一致。

当用户停止书写并进入2.8秒的空闲期（idle）后，系统会触发“提交页面”的操作。此时，手写内容被转化为PNG图像并传输至名为“oracle”的常驻LLM进程。该进程支持OpenAI兼容的API密钥，也支持本地运行。最令人惊叹的是其回复机制：AI生成的文本并非瞬间弹出，而是通过“Dancing Script”字体进行骨架化处理，转化为单像素的笔触路径。随后，这些路径被逐帧渲染到屏幕上，模拟出一种“隐形之手”在纸上流利书写的视觉效果，随后这些文字又会像魔法一样逐渐淡出，完美复刻了电影中汤姆·里德尔日记的神秘感。

深度定制的系统架构与运行环境

为了实现这种无缝的魔法感，Riddle采取了“接管模式”（takeover mode）。它在root权限下运行，能够停止厂商原有的用户界面（xochitl），直接接管e-ink显示引擎。在显示后端方面，它提供了两种模式：一种是基于qtfb的窗口化模式（在AppLoad应用内运行），另一种是基于quill的全屏接管模式。这种深度的系统修改确保了交互过程中不会有任何现代电子设备的UI元素干扰用户的魔法体验。

这种深度的系统修改对运行环境有着严格的要求。用户必须拥有一台处于开发者模式下的reMarkable Paper Pro，并建议使用remagic工具进行一键式环境配置。项目依赖于xovi和AppLoad框架来管理应用的加载。开发者特别强调，目前该项目仅在代号为“ferrari”的硬件、aarch64架构以及OS 3.26至3.27版本上通过了测试。由于涉及对底层引擎的直接操作，这种尝试具有一定的风险，开发者也明确表示该项目与reMarkable官方无关，并提醒用户务必保持SSH访问畅通，作为最后的“逃生舱”。

行业影响

Riddle项目不仅是一个有趣的极客尝试，它为AI硬件的交互设计提供了全新的视角。在当前AI应用普遍依赖对话框和打字输入的背景下，Riddle证明了利用特定硬件的物理特性（如电子纸的无背光、低延迟手写）可以创造出完全不同的情感连接。这种“无UI”的交互理念，预示着未来AI助手可能会更加隐形化，通过模拟人类熟悉的物理反馈（如手写、纸张吸收墨水）来降低技术的冰冷感。同时，该项目也展示了开源社区在闭源硬件平台上进行深度功能拓展的可能性，尽管这伴随着系统稳定性的挑战，但为电子纸设备从单一的阅读工具向创意交互终端的转型提供了范例。

常见问题

问题：我可以在普通的reMarkable 2上运行Riddle吗？

根据目前的原始信息，该项目明确指出仅在reMarkable Paper Pro（代号ferrari，aarch64架构）上进行了测试。由于它涉及直接驱动e-ink引擎的底层代码，不同型号的硬件架构差异可能导致其无法在reMarkable 2或其他旧款设备上运行，甚至可能导致设备故障。

问题：使用Riddle需要付费吗？

项目本身是开源免费的，但它依赖于大语言模型（LLM）来生成回复。用户需要提供自己的OpenAI兼容API密钥（在oracle.env文件中配置）。如果不使用API密钥，项目也提到了可以使用本地进程（pi），但这可能需要额外的本地计算资源配置。

问题：如果设备在运行过程中卡死怎么办？

开发者强烈建议在安装任何组件之前，确保设备的SSH访问功能正常。由于Riddle会停止官方UI并接管系统，SSH是用户在出现问题时恢复设备的唯一“逃生通道”。用户需要通过命令行工具（如scp）将文件传输至设备，并具备一定的终端操作经验，非技术用户需谨慎尝试。