凌晨三点翻 pager 邮件，顺手刷了下 GitHub。职业病，别学。刷到个小仓库，14 个星，1 个 fork。
就这？我盯着看了十分钟。
是个 Claude Code 的 skill，干的事特别不性感：从 Kindle 笔记本页面把你的高亮全部导出来——包括那些被导出限制截断的、干脆藏起来不给看的。
为什么要这个？用过 Kindle 导出的人都知道，Amazon 那个导出有数量和长度限制。你自己划的线，你自己买的书，导出来给你截一半。
这不叫限制。这叫劫持。
它怎么绕的？我看了眼流程，说实话糙得可爱：
DOM 抓高亮 -> Kindle.app 的 SQLite 读精确位置
-> Cloud Reader 渲染页面截图 -> Apple Vision 本地 OCR
-> 拼 Markdown -> 质量检查
四层缝在一起：AppleScript 驱动浏览器、啃 Mac Kindle 应用的本地 SQLite、本地 OCR、最后拼回带位置引用的 Markdown。单拎出来哪层都不难。难的是串起来、对齐位置、跑质量校验——这是那种“没有 AI 之前永远没人愿意写”的活儿。
不是不会写，是不值当写。为一年导几次高亮，手搓一套 OCR 对齐流水线？性价比不成立，没人会干。
AI 把这个“不值当”干掉了。这才是我以为的真提效——不是发布会上的十倍，是“一个下午把一件鸡毛蒜皮但确实烦人的事自动化掉”的一倍半。
验证强度我得多说两句。四本真实书，2432 条高亮，815 条被限制的，恢复出来的文本跟 Kindle 自己的位置标尺做字符级比对，偏差中位数 0 到 1。我审过的上生产的 PR，一半都不到这个验证强度。
补一刀：整个 pipeline 全本地跑，OCR 是 Apple Vision，没把你的书页往哪个 API 送。就冲这点，比一堆“顺手接个云端模型”的 skill 强。
按我这行的习惯，刺还是要挑的。
一是依赖链长到感人：Chrome 加登录态的 Amazon 账户、Control Chrome 扩展、Mac Kindle 应用、Xcode 命令行工具、Python3，还只支持 macOS。这条链上任何一环——Amazon 改个 DOM、Kindle 应用换个数据库结构——整个就哑了。缝合系统的维护性，懂的都懂：今天能用，明天看命。
二是版权那根线。它自己说明里写了：输出仅限个人笔记、保持私密。这个立场我认可——你自己划的线导出来自己看，跟当年给自己买的 CD 抓 mp3 是一回事。但真有人拿它批量扒书商用，那就是另一回事了。工具无罪，用工具的剧本我看过太多种。
扯远了。回到我真正想说的。
这一年我被「AI agent 自主干一切」的轰炸搞麻了。自主运维、自动 remediate、自动重构屎山——每一个都号称要替掉凌晨三点接电话的那个冤种，也就是我。真到生产环境，全是“看起来对”扛不住三点的老故事。
然后是这么个 14 星的仓库。导出高亮，小事。但它知道自己的边界在哪：每步干什么写得明明白白，验证做到字符级，依赖摆在前头，免责声明白纸黑字。它没有“自主”任何东西——人发起，机器执行，人验收。
这对比挺讽刺的。行业吹的是让 agent 当值长，真正能打的例子全是 agent 当工具。前者我到现在没见过不翻车的。后者满地都是，只是没人给“帮你导高亮”开发布会。
本期教训：判断一个 AI 工具能不能信，别看它宣称多自主，看它敢不敢把验证数据贴出来。字符级偏差中位数 0 到 1——这种数我信。提效十倍那种，我一个字都不信。