这件事的起点其实特别简单：我桌上有一台 Kindle Paperwhite，吃灰很久了。
扔了舍不得，继续放抽屉里又有点浪费。它屏幕不大，性能也不强，但 e-ink 常显、不刺眼、耗电低，这几个特点放在今天反而挺稀缺。
前阵子我刚折腾过 Codex 桌面宠物：AI不再只躲在终端里：我把Floeva戒指孵成了会卖萌的Codex桌宠，让一个小宠物在电脑里显示 Agent 的运行状态。那篇里我写过一句话，桌面宠物不是装饰品，它更像一个轻量状态层。
于是我很自然地想到：
既然 Codex 里可以养桌面宠物，那吃灰的 Kindle 能不能变成一块“实体桌宠屏”？ 一开始真没想做什么严肃的监控系统，只是想把这台 Kindle 用起来，让它在桌面上有点存在感。
后来才发现，Claude Code 和 Codex 的状态刚好很适合放上去：谁在跑，谁闲着，在哪个项目里，抬头看一眼就知道。
实拍：Kindle 上单独显示 Codex 当前状态和最近任务。
所以这篇不是“我为了效率发明了一个看板”的故事。
更准确地说，是：我想让一台吃灰 Kindle 重新回到桌面上，顺手把它做成了 AI 桌宠的第二块屏。
Kindle 最尴尬的地方是：它还挺好，但你就是不怎么用。
看书有手机、iPad、微信读书；拿来当主力屏幕又太慢。它很难再成为一个“中心设备”。
但如果换个思路，不让它当中心，只让它承担一个很窄的任务：常显、低干扰、放在桌角。
这时候 Kindle 反而很合适。
它不像第二屏那样不断吸引你点开消息，也不像手机那样一亮就把注意力拽走。它慢，黑白，刷新也不频繁，天然适合做那种“不急，但一直有用”的信息展示。
这和我之前做桌面宠物的思路其实是一脉相承的。
桌面宠物不是为了多一个可爱的东西，而是把 Agent 的状态从日志里拿出来，变成一个余光就能感知到的小反馈。Kindle 只是把这个状态层从电脑屏幕里拿出来，放到了一块真实的 e-ink 屏上。
很多旧设备不是没用了，只是它不该再承担主力设备的任务。给它一个足够窄的位置，它就能重新变得好用。
既然起点是“桌宠的延伸”，第一版设计我就不想做成那种枯燥的监控面板：一堆数字、一堆进度条、再配几条日志。
Kindle 的纸质感屏幕，适合放点更轻、更有陪伴感的东西。
最后我定下来：两只像素小宠物，一只代表 Claude，一只代表 Codex。
实拍：Claude 和 Codex 两只像素宠物，加上下面的系统状态。
它们头顶各有一个小气泡：
后来发现这俩工具的社区里本来就有很适合像素化的形象：
- Claude Code 那边有 Clawd，一只橘色像素风小螃蟹，Code with Claude 活动现场还出现过相关周边
- Codex 桌面端有 Cloudling，一个云朵小生物，也能通过
/pet 命令召唤
我从社区项目 rullerzhou-afk/clawd-on-desk 里拿到了两套官方风格的 GIF，再用 Python + Pillow 自动转成 32x32 黑白像素图，直接喂给前端。
这一步比想象中重要。
如果只是写“Claude running / Codex idle”，你看两天就会腻。但换成两个小宠物之后，这块屏幕突然有了点桌面摆件的感觉。它不是强提醒，不制造压力，只是在那里安静地告诉你：谁还醒着，谁已经睡了。
我原本以为，现在的 Kindle 浏览器再差，也应该是个能用的现代浏览器。
结果真机一跑才发现：它基本像 2014 年左右的 WebKit。JavaScript 很多时候跑不动，CSS Grid 不支持，连一些继承样式都不稳定。
给 Kindle 做前端，最重要的心法是：
第一版宠物是用 SVG
解决办法很朴素：服务端直接生成 PNG。
我用 Pillow 把 32x32 sprite 用 Image.NEAREST 放大到 256x256，Flask 通过 /pet/claude.png 直接返回图片字节。Kindle 只需要会 ![]()
2. CSS Grid 很现代，但 Kindle 不认
期望的布局是两只宠物左右并排。我一开始用了 display: grid，Mac 上看好端端的。Kindle 上，两只宠物纵向堆成一列，每只占满整行。
第一反应是退回
布局。我知道，2010 年之后还用 table 做布局多少有点逆时代。但在 Kindle 浏览器上，table 一度是唯一能保证横排的方案。
修完前两个坑之后，又发现宠物卡片的右边和下面 SYSTEM 卡片的右边对不齐，差了 17 像素。
debug 半天才发现：
在 Kindle 上不是按父容器内容区宽度算，而是按 border-box 外宽算，相当于忽略了父容器的 padding。于是 table 比旁边的 div 宽出一截。最后的解法是彻底放弃 table，改用
+ float:left + box-sizing:border-box。两个宠物 div 各占 50% 宽，中间共享一根边框，反而最稳。这事也挺讽刺：你以为你在做一个 AI 状态看板，最后真正让你破防的是老浏览器布局。
越是跑在老设备上的东西，越不能相信“现代前端理所当然能用”。
我没有调用 Claude Code 或 Codex 的 API，也没有从 CLI 里硬解析输出。
原因很简单：状态看板要稳定，依赖越少越好。
Claude Code 和 Codex 本来就会把会话写到本地 JSONL：
~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl
我直接读这些文件：
- 是不是在跑：最新 JSONL 文件的 mtime 是否在 60 秒内
- 当前项目：读 JSONL 里第一个带
cwd 字段的事件，取 basename
唯一没做的是“Claude Code / Codex 使用额度”。
这个我一开始其实很想放上去，毕竟如果 Kindle 上能直接看到还剩多少额度，会很实用。
但折腾了一圈发现，Claude Code 和 Codex 的 CLI 目前都没有稳定接口可以直接拿到这个数字。Claude Code 里的 /usage 更像 CLI 内部能力，不是一个适合被外部服务长期依赖的公开接口；Codex 这边也没有我能放心写进常驻服务的额度 API。
所以 v1 只能放弃额度显示。
如果你知道更稳的方案，比如本地缓存位置、可用的命令输出、或者官方后来开放了相关接口，欢迎在留言里告诉我。我还挺想把这个模块补上的。 对这块屏幕来说，核心问题不是“我还能跑多久”，而是“它们现在有没有在跑”。
工具越轻，越适合常驻。状态看板不是控制台，别把它做成另一个需要维护的系统。
宠物显示完之后，Kindle 屏幕下半部还有一大块空白。索性把 Mac 的系统状态也放上去：
| |
|---|
| psutil.cpu_percent() |
| psutil.virtual_memory().percent |
| 自己算：(total - free) / total |
| smctemp -c |
| psutil.net_io_counters() |
| time.time() - psutil.boot_time() |
这里也踩了两个很典型的 macOS 坑。
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 就斜立在键盘右上方，屏幕常显，每 30 秒自动刷新一次。
看视屏看到半路，余光扫一眼：
Claude 还在 kindle-ai-monitor 项目里，已活跃 14 分钟，没卡。
Codex 在 shiguang-huimou 项目里，闲了 7 分钟，该回去看下进度。
CPU 30%，温度 48°C，网络上行 600KB/s，系统状态正常。 少切几次 terminal，当然是有用的。
但对我来说，更爽的地方是：这台本来躺在抽屉里的 Kindle，终于又成了桌面工作流的一部分。
它不抢注意力。普通第二屏会不断诱惑你看消息、看网页、看各种动效；Kindle 的 e-ink 屏很慢，反而天然克制。它只适合显示那些“不急，但一直有用”的信息。
这也是我做完之后最大的感受：
很多旧设备不是没用了，只是它不该再承担主力设备的任务。把它放到工作流里一个很窄的位置，反而会重新变得好用。 这个小工具目前没有开源，也不打算做成一个需要维护的开源项目。
一方面它非常依赖我自己的本地路径、设备摆放和使用习惯；另一方面，真正有复用价值的其实不是代码，而是这套思路。
如果你也有台吃灰的 Kindle，或者别的旧平板、旧手机、小屏设备，最值得抄的是这个方向：
把桌子上那台不舍得扔、但又不怎么用的电子设备，改成你工作流里的一个常显状态位。 E-ink 屏除了看书，真的还能干点别的。
粤ICP备14082021号
免费POC，
零成本试错
