我把吃灰的 Kindle 用起来了：给 AI 桌宠加一块电子墨水屏

这件事的起点其实特别简单：我桌上有一台 Kindle Paperwhite，吃灰很久了。

扔了舍不得，继续放抽屉里又有点浪费。它屏幕不大，性能也不强，但 e-ink 常显、不刺眼、耗电低，这几个特点放在今天反而挺稀缺。

前阵子我刚折腾过 Codex 桌面宠物：AI不再只躲在终端里：我把Floeva戒指孵成了会卖萌的Codex桌宠，让一个小宠物在电脑里显示 Agent 的运行状态。那篇里我写过一句话，桌面宠物不是装饰品，它更像一个轻量状态层。

于是我很自然地想到：

一开始真没想做什么严肃的监控系统，只是想把这台 Kindle 用起来，让它在桌面上有点存在感。

后来才发现，Claude Code 和 Codex 的状态刚好很适合放上去：谁在跑，谁闲着，在哪个项目里，抬头看一眼就知道。

实拍：Kindle 上单独显示 Codex 当前状态和最近任务。

所以这篇不是“我为了效率发明了一个看板”的故事。

更准确地说，是：我想让一台吃灰 Kindle 重新回到桌面上，顺手把它做成了 AI 桌宠的第二块屏。

一、不是先有需求，是先有一台吃灰 Kindle

Kindle 最尴尬的地方是：它还挺好，但你就是不怎么用。

看书有手机、iPad、微信读书；拿来当主力屏幕又太慢。它很难再成为一个“中心设备”。

但如果换个思路，不让它当中心，只让它承担一个很窄的任务：常显、低干扰、放在桌角。

这时候 Kindle 反而很合适。

它不像第二屏那样不断吸引你点开消息，也不像手机那样一亮就把注意力拽走。它慢，黑白，刷新也不频繁，天然适合做那种“不急，但一直有用”的信息展示。

这和我之前做桌面宠物的思路其实是一脉相承的。

桌面宠物不是为了多一个可爱的东西，而是把 Agent 的状态从日志里拿出来，变成一个余光就能感知到的小反馈。Kindle 只是把这个状态层从电脑屏幕里拿出来，放到了一块真实的 e-ink 屏上。

二、桌面宠物的延伸：把状态搬到实体屏上

既然起点是“桌宠的延伸”，第一版设计我就不想做成那种枯燥的监控面板：一堆数字、一堆进度条、再配几条日志。

Kindle 的纸质感屏幕，适合放点更轻、更有陪伴感的东西。

最后我定下来：两只像素小宠物，一只代表 Claude，一只代表 Codex。

实拍：Claude 和 Codex 两只像素宠物，加上下面的系统状态。

它们头顶各有一个小气泡：

• 正在跑：显示 in

• 闲着：显示 zzz...

后来发现这俩工具的社区里本来就有很适合像素化的形象：

• Claude Code 那边有 Clawd，一只橘色像素风小螃蟹，Code with Claude 活动现场还出现过相关周边

• Codex 桌面端有 Cloudling，一个云朵小生物，也能通过 /pet 命令召唤

我从社区项目 rullerzhou-afk/clawd-on-desk 里拿到了两套官方风格的 GIF，再用 Python + Pillow 自动转成 32x32 黑白像素图，直接喂给前端。

这一步比想象中重要。

如果只是写“Claude running / Codex idle”，你看两天就会腻。但换成两个小宠物之后，这块屏幕突然有了点桌面摆件的感觉。它不是强提醒，不制造压力，只是在那里安静地告诉你：谁还醒着，谁已经睡了。

三、真正的坑不是 AI，是 Kindle 浏览器

我原本以为，现在的 Kindle 浏览器再差，也应该是个能用的现代浏览器。

结果真机一跑才发现：它基本像 2014 年左右的 WebKit。JavaScript 很多时候跑不动，CSS Grid 不支持，连一些继承样式都不稳定。

给 Kindle 做前端，最重要的心法是：

1. SVG 很漂亮，但 Kindle 直接白屏

第一版宠物是用 SVG  一个个像素拼出来的，需要 JS 在客户端循环渲染。在 Mac 浏览器里看完美，推到 Kindle 上，一片空白。

解决办法很朴素：服务端直接生成 PNG。

我用 Pillow 把 32x32 sprite 用 Image.NEAREST 放大到 256x256，Flask 通过 /pet/claude.png 直接返回图片字节。Kindle 只需要会  标签就行。

2. CSS Grid 很现代，但 Kindle 不认

期望的布局是两只宠物左右并排。我一开始用了 display: grid，Mac 上看好端端的。Kindle 上，两只宠物纵向堆成一列，每只占满整行。

第一反应是退回 

我知道，2010 年之后还用 table 做布局多少有点逆时代。但在 Kindle 浏览器上，table 一度是唯一能保证横排的方案。

3. table 能救命，也会制造新的坑

修完前两个坑之后，又发现宠物卡片的右边和下面 SYSTEM 卡片的右边对不齐，差了 17 像素。

debug 半天才发现：

最后的解法是彻底放弃 table，改用 

这事也挺讽刺：你以为你在做一个 AI 状态看板，最后真正让你破防的是老浏览器布局。

四、状态数据不用 API，直接扫本地 JSONL

我没有调用 Claude Code 或 Codex 的 API，也没有从 CLI 里硬解析输出。

原因很简单：状态看板要稳定，依赖越少越好。

Claude Code 和 Codex 本来就会把会话写到本地 JSONL：

• ~/.claude/projects/

• ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl

我直接读这些文件：

• 是不是在跑
  ：最新 JSONL 文件的 mtime 是否在 60 秒内

• 当前项目
  ：读 JSONL 里第一个带 cwd 字段的事件，取 basename

• 最近任务
  ：按 mtime 倒序取最近 6 个会话

唯一没做的是“Claude Code / Codex 使用额度”。

这个我一开始其实很想放上去，毕竟如果 Kindle 上能直接看到还剩多少额度，会很实用。

但折腾了一圈发现，Claude Code 和 Codex 的 CLI 目前都没有稳定接口可以直接拿到这个数字。Claude Code 里的 /usage 更像 CLI 内部能力，不是一个适合被外部服务长期依赖的公开接口；Codex 这边也没有我能放心写进常驻服务的额度 API。

所以 v1 只能放弃额度显示。

对这块屏幕来说，核心问题不是“我还能跑多久”，而是“它们现在有没有在跑”。

五、顺手把 Mac 状态也塞进去

宠物显示完之后，Kindle 屏幕下半部还有一大块空白。索性把 Mac 的系统状态也放上去：

这里也踩了两个很典型的 macOS 坑。

1. APFS 会让磁盘占用看起来不对

psutil.disk_usage("/").percent 在我的 Mac 上一直显示 63%。但我自己 df -h 看是 97%。

原因是 macOS 用 APFS，根 / 是只读 System 卷，用户数据在 /System/Volumes/Data。psutil 报告的 used 只是 System 卷自己的文件，并没有把 Data 卷算进去。

解决办法是不直接用 du.used，而是自己算 total - free。同一个 APFS 容器里所有卷共享 free space，这个减法在 APFS 和传统单卷文件系统上都更符合直觉。

2. Intel 时代的温度工具，在 M 系列上会失灵

最先尝试的是 Homebrew 上的 osx-cpu-temp，装完一跑返回 0.0°C。

后来才发现，这个包主要是给 Intel Mac 写的，读的 SMC 键在 Apple Silicon 上不存在。

最后我从 narugit/smctemp 源码 make 了一份，装到 ~/.local/bin/。smctemp -c 在 M 系列上能正确返回温度。

六、要真常用，就别靠手动启动

最后一步是让服务开机自动起，崩了自动拉。

macOS 上原生方案就是 launchd。我写了一个 ~/Library/LaunchAgents/com.luojian.kindle-ai-monitor.plist：

加载：

之后这服务就跟系统里的其他后台进程一样，我平时几乎感觉不到它的存在。

直到我抬头看一眼 Kindle。

七、真正开心的是：Kindle 终于回到桌面上

现在 Kindle 就斜立在键盘右上方，屏幕常显，每 30 秒自动刷新一次。

看视屏看到半路，余光扫一眼：

少切几次 terminal，当然是有用的。

但对我来说，更爽的地方是：这台本来躺在抽屉里的 Kindle，终于又成了桌面工作流的一部分。

它不抢注意力。普通第二屏会不断诱惑你看消息、看网页、看各种动效；Kindle 的 e-ink 屏很慢，反而天然克制。它只适合显示那些“不急，但一直有用”的信息。

这也是我做完之后最大的感受：

这个小工具目前没有开源，也不打算做成一个需要维护的开源项目。

一方面它非常依赖我自己的本地路径、设备摆放和使用习惯；另一方面，真正有复用价值的其实不是代码，而是这套思路。

如果你也有台吃灰的 Kindle，或者别的旧平板、旧手机、小屏设备，最值得抄的是这个方向：

E-ink 屏除了看书，真的还能干点别的。