这件事的起点其实特别简单：我桌上有一台 Kindle Paperwhite，吃灰很久了。
扔了舍不得，继续放抽屉里又有点浪费。它屏幕不大，性能也不强，但 e-ink 常显、不刺眼、耗电低，这几个特点放在今天反而挺稀缺。
前阵子我刚折腾过 Codex 桌面宠物：AI不再只躲在终端里：我把Floeva戒指孵成了会卖萌的Codex桌宠，让一个小宠物在电脑里显示 Agent 的运行状态。那篇里我写过一句话，桌面宠物不是装饰品，它更像一个轻量状态层。
于是我很自然地想到：
既然 Codex 里可以养桌面宠物，那吃灰的 Kindle 能不能变成一块“实体桌宠屏”？
一开始真没想做什么严肃的监控系统，只是想把这台 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 自动转成 32×32 黑白像素图，直接喂给前端。
这一步比想象中重要。
如果只是写“Claude running / Codex idle”，你看两天就会腻。但换成两个小宠物之后，这块屏幕突然有了点桌面摆件的感觉。它不是强提醒，不制造压力，只是在那里安静地告诉你：谁还醒着，谁已经睡了。
## **三、真正的坑不是 AI，是 Kindle 浏览器**
我原本以为，现在的 Kindle 浏览器再差，也应该是个能用的现代浏览器。
结果真机一跑才发现：**它基本像 2014 年左右的 WebKit。JavaScript 很多时候跑不动，CSS Grid 不支持，连一些继承样式都不稳定。**
给 Kindle 做前端，最重要的心法是：
假装你回到了 2010 年。
### **1. SVG 很漂亮，但 Kindle 直接白屏**
第一版宠物是用 SVG 一个个像素拼出来的，需要 JS 在客户端循环渲染。在 Mac 浏览器里看完美，推到 Kindle 上，一片空白。
解决办法很朴素：**服务端直接生成 PNG。**
我用 Pillow 把 32×32 sprite 用`Image.NEAREST`放大到 256×256，Flask 通过`/pet/claude.png`直接返回图片字节。Kindle 只需要会 标签就行。
### **2. CSS Grid 很现代，但 Kindle 不认**
期望的布局是两只宠物左右并排。我一开始用了`display: grid`，Mac 上看好端端的。Kindle 上，两只宠物纵向堆成一列，每只占满整行。
第一反应是退回
布局。
我知道，2010 年之后还用 table 做布局多少有点逆时代。但在 Kindle 浏览器上，table 一度是唯一能保证横排的方案。
### **3. table 能救命，也会制造新的坑**
修完前两个坑之后，又发现宠物卡片的右边和下面 SYSTEM 卡片的右边对不齐，差了 17 像素。
debug 半天才发现：
在 Kindle 上不是按父容器内容区宽度算，而是按 border-box 外宽算，相当于忽略了父容器的 padding。于是 table 比旁边的 div 宽出一截。
最后的解法是彻底放弃 table，改用
+`float:left`+`box-sizing:border-box`。两个宠物 div 各占 50% 宽，中间共享一根边框，反而最稳。
这事也挺讽刺：你以为你在做一个 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 的系统状态也放上去：
| 指标 | 怎么读 |
| — | — |
| CPU | `psutil.cpu_percent()` |
| 内存 | `psutil.virtual_memory().percent` |
| 磁盘 | 自己算：`(total – free) / total` |
| 温度 | `smctemp -c`，主要用于 Apple Silicon |
| 网络 | `psutil.net_io_counters()`两次采样差 |
| 开机时长 | `time.time() – psutil.boot_time()` |
这里也踩了两个很典型的 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`：
加载：
launchctl load ~/Library/LaunchAgents/com.luojian.kindle-ai-monitor.plist
之后这服务就跟系统里的其他后台进程一样，我平时几乎感觉不到它的存在。
直到我抬头看一眼 Kindle。
## **七、真正开心的是：Kindle 终于回到桌面上**
现在 Kindle 就斜立在键盘右上方，屏幕常显，每 30 秒自动刷新一次。
看视屏看到半路，余光扫一眼：
Claude 还在`kindle-ai-monitor`项目里，已活跃 14 分钟，没卡。
Codex 在`shiguang-huimou`项目里，闲了 7 分钟，该回去看下进度。
CPU 30%，温度 48°C，网络上行 600KB/s，系统状态正常。
少切几次 terminal，当然是有用的。
但对我来说，更爽的地方是：这台本来躺在抽屉里的 Kindle，终于又成了桌面工作流的一部分。
它不抢注意力。普通第二屏会不断诱惑你看消息、看网页、看各种动效；Kindle 的 e-ink 屏很慢，反而天然克制。它只适合显示那些“不急，但一直有用”的信息。
这也是我做完之后最大的感受：
**很多旧设备不是没用了，只是它不该再承担主力设备的任务。**把它放到工作流里一个很窄的位置，反而会重新变得好用。
这个小工具目前没有开源，也不打算做成一个需要维护的开源项目。
一方面它非常依赖我自己的本地路径、设备摆放和使用习惯；另一方面，真正有复用价值的其实不是代码，而是这套思路。
如果你也有台吃灰的 Kindle，或者别的旧平板、旧手机、小屏设备，最值得抄的是这个方向：
把桌子上那台不舍得扔、但又不怎么用的电子设备，改成你工作流里的一个常显状态位。
E-ink 屏除了看书，真的还能干点别的。
