[分享] 为什么用 AI 自动归类书签是个伪命题?一次 400+ 收藏夹的确定性排坑实录

2 小时 14 分钟前
 unwillingto12

前几天我试着用本地 Agent ( Codex / Claude Code )帮我清理堆积了 4 年、400 多个 Edge 书签,本来以为一句话的事情,结果踩了一裤裆的工程暗坑。

今天把整个过程中的反直觉真相、工程死锁以及最终跑通的解决方案开源出来。

项目开源地址: https://github.com/askofcc/chromium-bookmark-guardian (无需安装任何插件或第三方脚本,纯 Prompt 规范,丢给你的本地 Agent 即可现场执行)


一、 两个反直觉的认知“打脸”

1. 为什么“让 AI 自动整理书签目录”是个彻头彻尾的灾难?

第一轮我让大模型根据 URL 和内容“智能重组分类”。结果它把属于我个人业务流的海外支付钱包 WebMoney,生硬地塞进了 常用站长与 SEO。 后来我想明白了:书签本质上是人的「空间记忆」和「私人业务上下文」。 当年我做站长要买外链,顺手需要办一张虚拟卡,所以虚拟卡自然在垂直业务目录下。AI 只有通识词向量,没有私人业务上下文。它自作聪明地按大词归类,看似整齐,实际把大脑建立了几年的空间肌肉记忆瞬间切碎,心理感受就是“东西全丢了”。 结论:书签治理的第一铁律,是 AI 严禁触碰用户原有的目录结构。

2. 传统死链工具(以及只查 HTTP 状态码的脚本)漏掉了 80% 的“假存活与黑产劫持”

市面上的扩展(如 Bookmarks Clean Up )通常只看返回码是不是 200 ,结果这几天深度复测发现:


二、 必须绕过的底层死锁:Chromium 云同步( Sync )反向覆写

如果你在后台关闭 Edge/Chrome ,直接用 Python 修改磁盘上的 Default/Bookmarks JSON 文件: 千万别这么干! 因为开启了微软/谷歌账号云同步后,Chromium 内部遵循硬性冲突规则 「 Remote parent wins (云端归属优先)」。你离线改的文件没有同步事务凭证,浏览器启动联网瞬间,云同步引擎会把云端旧目录全量拉下来覆盖你的本地修改!

有效解法: 通过系统自动化管道(如 macOS AppleScript / CDP ),向浏览器内部打开的 edge://favorites 或 chrome://bookmarks 注入原生脚本,直接调用浏览器内部特权接口 chrome.bookmarks.move()。 每一次移动都会作为原生事件被 Sync 引擎捕获并主动提交给云端,实现无感实时更新、零刷新生效、云端永久同步。


三、 终极工程准绳与一键抄作业

踩完坑后,我们总结出了一套 Chromium 书签无损治理的四大准绳:

  1. 结构绝对不动,组内频次浮顶(原有业务分类 100% 保持,只在文件夹内部把近期高频项置顶);
  2. 四层穿透探针,清仓隐蔽伪存活(双通道测活 + SSL 验真 + 灰产词库对抗 + 标题防假死);
  3. 客观二元隔离,零物理删除(移入末尾隔离箱细分子类,确定死亡项随时一键清空);
  4. 宿主原生特权注入(解决 Edge/Chrome 云同步回滚)。

如果你也有几百个吃灰的书签想清理,不用装任何扩展,也不用上传书签泄露隐私。

直接去 GitHub 复制那份 PROMPT.md 丢给你的本地 Agent ( Codex 、Claude Code 、Cursor 等):

👉 GitHub 项目地址: https://github.com/askofcc/chromium-bookmark-guardian

143 次点击
所在节点    分享创造
2 条回复
Tory12138
1 小时 58 分钟前
这个很有用
majiajia
1 小时 14 分钟前
介绍文档一股浓浓的 AI 味,建议“说人话”

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1246036

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX