开发者l3a0在GitHub上发布了一个Claude Code插件技能，叫kindle-highlights，专门解决一个亚马逊自己从没说清楚的问题：Kindle笔记本导出高亮时，超过某个隐形限额的内容会被截断甚至完全隐藏，只剩一个位置编号。这个技能在四本高亮密度很高的书上测试，一共提取2432条高亮，其中815条被导出限制拦截——454条被截断、361条彻底消失，最后全部找了回来，恢复文本和Kindle App自身的位置标尺相比，中位误差只有0-1个字符。这不是又一个导出脚本，而是第一次有人把"本地数据库+OCR"接到Claude Code的技能链条上，去啃这个业界公开抱怨了很多年却没人真正解开的限额问题。
三条腿拼出一份完整笔记
亚马逊的限额只卡在一个入口：网页版Notebook导出。l3a0的思路是绕开这个唯一入口。技能先抓取Notebook页面的DOM拿到能看见的高亮，再读取Mac Kindle应用本地同步的SQLite数据库——里面的server_view.serialized_payload字段记录着每条高亮精确到字符的起止位置，这是网页端从来不对外暴露的数据。对于完全隐藏、连位置号都对不上文本的那部分，脚本把Cloud Reader渲染出的页面画到canvas，本地跑一遍Apple Vision的OCR，再按已知的字符位置把文字切出来。三条路径对齐之后，误差压到了个位数字符以内。
- 结论.真正的解锁点不是"破解"了亚马逊的限额规则，而是找到了一个亚马逊没设防的旁路——本地App的同步数据库。
Readwise和Klib为什么做不到同样的事
这不是技术门槛问题。Readwise、Bookcision、Klib这些主流Kindle高亮管理工具，架构上都只吃同一个数据源：Notebook网页或者My Clippings.txt。这两个来源本身就是被限额过滤后的结果，工具再怎么优化前端呈现，也拿不到被隐藏的那部分。Readwise的官方文档甚至写得很直白：不会绕过出版商设置的限制，遇到不完整的片段就自动加个省略号意思一下。换句话说，商业公司不是没想到本地数据库这条路，而是选择不去碰。
商业公司止步的地方，恰恰是灰色地带开始的地方。
亚马逊官方文档从没公布过限额的具体计算方式，只承认"剪辑数量可能受限"。社区里流传的"10%规则"从未被亚马逊证实过，很可能因书而异，甚至按累计文本量而不是单本比例计算。这个信息差本身才是问题的起点：用户不知道规则是什么，也就没法判断自己是不是"正好"撞线。
别急着装：四本书的验证还太薄
这个技能只能在macOS上跑，而且前置条件不轻——得装Claude Desktop的"Control Chrome"扩展、改一项Chrome的开发者设置、装能编译Swift的Xcode命令行工具，还得让Mac版Kindle App和网页版登同一个账号、把书下载到本地。装齐这些之后，才轮到Claude去调度浏览器、读数据库、跑OCR。仓库自己也承认，这更像一份写在SKILL.md里的"agent playbook"，位置对齐、句子边界判断这些逻辑靠Claude实时执行，没有打包成一个独立成熟的生产工具。四本书的样本量，也远远撑不起"稳定可靠"的结论。
- 风险.书籍文本本身受版权保护，亚马逊的限额本质上是一层版权保护措施，技能作者自己也提醒恢复出来的笔记要保持私有——这条线踩得多重，取决于用起来的人。
对重度Kindle用户来说，这至少证明了一件此前没人验证过的事：被隐藏的高亮不是永久丢失，本地数据是可以拼回来的。但这套方案现在更像一个可复用的思路，而不是一个能装完就用的产品。真正值得盯的，是亚马逊会不会针对本地注释数据库或Cloud Reader渲染逻辑做出回应——如果堵上这个口子，这份"拿回自己数据"的路径可能比它出现得还快就消失。