JC Bookmarks

收藏夹乱，通常不是因为条目多，而是判断依据被藏起来了：该区分的（官方还是中转）混在一个夹，该分组的（组件还是模板）靠记忆，该读的文档埋在第四层，标题里全是营销话术。

整理的目标不是「分得细」，是打开任何一层都知道自己在看什么。

什么时候用

• 收藏夹条目过百，找东西开始靠搜索而非浏览；
• 从别的浏览器导出一份 HTML，想并进当前浏览器；
• 层级越叠越深，或者出现「杂项 / 其他」这种承认失败的文件夹；
• 标题带着站点长尾（xxx - 免费在线工具_支持批量_官方正版），列表扫不动。

不适用于：只是想删几条书签（直接用浏览器书签管理器）、需要保留访问历史或登录态（书签文件不含这些）、以及没有备份前提下的破坏性写入。

注意「待整理」不算失败。首次整理时它是个筐，需要消灭；整理完成后它是个收件箱，应该保留——见下一节。

先诊断

输入有两种，先分清：

写回前必须查两件事，否则前面白做：

1. 同步状态。Preferences 里的 sync.has_setup_completed 为 true，说明登录即同步，本地改完一启动就会被云端合并回去（实测会从 7 个顶层变回 19 个、条目从 561 涨到 592）。
2. 加密副本。Chrome 130+ 会在明文旁边写 EncryptedBookmarks2，进入读密文阶段后，明文改动不生效。

细节见 references/chrome-writeback.md。

第一步 收敛层级

• 顶层 ≤ 8 个，二级夹 2-4 个，总层级 ≤ 3 层（收藏夹栏算第 1 层）。
• 判断一个文件夹该不该存在：它只是「类型 / 阶段 / 子模块」吗？ 如果是，把信息写进条目名字，不要建目录。
• 两种平铺法，用来吸收「子夹多但每个只有几条」的情况：
  • 资料类：主题 · 名称，例 论文 · 知网检索、求职 · 土豆资料库
  • 设计类：类型 · 名称，例 组件 · React Bits、图标 · iconfont

平铺的代价是夹内条目变多（40-50 条是正常量），换来的是少点两层。条目数不是问题，找错地方才是。

第二步 分类

三个维度，按这个优先级判断：

1. 可信度——有跑路风险的品类（AI 服务、API、代充、账号），先按域名归属分：
   • 官方：域名属于厂商自己（openai.com、volcengine.com、bailian.console.aliyun.com）
   • 中转与 API：第三方转发、聚合、监控、拼车
   • 这条判断标准单一，且是使用者最关心的（"这家会不会跑路"），不要拿"工具类型"去切它。
2. 用途——拿来用的（工具/组件）、拿来读的（文档/资料）、给项目用的（内部系统）。
3. 归属——工作项目单独成顶层，不要塞进「工作 / 学习 / 生活」这种三合一筐再套子夹。

反例：把「官方 key 页」和「中转站」放在同一个 API 与中转 夹里，等于把要判断的东西混在一起。

第三步 命名

统一成 品牌 - 用途：

Z.ai Chat - Free AI powered by GLM-4.6 & GLM-4.5   →  Z.ai - GLM 对话
Free AI Resume Builder Trusted by +4 Million…      →  Rezi - AI 简历
buxuku/video-subtitle-master: 批量为视频生成字幕…    →  video-subtitle-master - 视频字幕

规则：

• 品牌在前，用途用中文，中间一个短横；用途压到 2-6 个字。
• 不翻译品牌名（Kimi 不写成「月之暗面」），但用途必须中文化（GUI → 图形界面）。
• 同一家的多个页面，用不同用途区分，别都叫「官网」：腾讯云 - COS 控制台 / - 域名控制台 / - 轻量服务器。
• 清掉：零宽字符（U+200B-200F、U+2060-2064、U+FEFF）、_ ｜ ~ emoji、- 飞书云文档 这类尾巴。
• 项目自己的文档、带课次版本的、中文站名本来就干净的，不要硬套格式。

标题里的隐形字符是最容易被忽略的问题：导出的 HTML 里，一批文档的标题前面挂了几十个零宽字符，肉眼看是空白，导致整列都是「乱码」。清除即可，不需要访问 URL 重命名。

第四步 排序

夹内三层 key：厂商分组 → 主题/类型前缀 → 拼音。

厂商分组的意义是把同源的东西连成段（火山的 8 条、腾讯的 4 条各自成段），组间顺序按使用权重排，不按字母排——否则「阿里」永远压在「百度」前面，与你实际打开频率无关。

前缀（主题 · / 类型 · ）优先级高于品牌，因为它已经表达了更强的分组意图。

拼音排序需要 pypinyin，没有就退回 Unicode 序（中文会显得随机，但不影响正确性）。

日常维护（inbox 模式）

首次整理是一次性重排。结构稳定之后，不要再每加一条就想着放哪——那会让收藏这个动作变慢。

建一个顶层 待整理 当收件箱，新收藏一律扔进去，攒到一定量再统一处理。整理时：

python scripts/triage.py --chrome          # 读浏览器现状，产出清单
python scripts/triage.py --chrome --apply  # 确认后批量搬动

triage.py 只回答「这条该去哪」，不给命名建议——命名是判断活，留给模型或人。规则按 first-match 走，顺序见脚本顶部 ROUTES。

20 条是分水岭

这条判断比脚本本身重要：小批量时，导出导入的成本和风险都高于手动拖。

归类看不清就看站点

标题里的「代充」只说明商业模式，不说明卖什么。实测一条 蔚莱云Ai出海跨境账号代充，按标题会判成 AI 代充，抓页面才发现卖的是「海外 IP + 推特/谷歌/电报账号 + AI 订阅 + API 中转」的一揽子账号店，应该进 账号与充值。

判断依据：

• 卖单一 AI 服务的会员/账号（ChatGPT 代充、Claude Pro 充值）→ AI > 代充
• 卖一揽子账号、卡、号、接码、海外 IP，AI 只是其中一项 → 代理与账号 > 账号与充值

其它看不清的情况同理：抓一下 <title> 和 meta description 就够，不必打开浏览器。

写回

三条铁律：

1. 不要点「导入书签」——那是追加，会得到两套（新 561 + 旧 581）。必须替换 Bookmarks 文件。
2. 先关同步。关不掉就带 --disable-sync 启动一次，确认结果后再决定长期方案。
3. 合并写回，不整份覆盖。按 URL 配对沿用原 guid / id，只改名字和位置；checksum 留空交给浏览器重算。

脚本：python scripts/merge_back.py --write，写入前自动备份三件套，写完用 --check 复核。

已知坑

交付

一次整理至少留四样东西，缺一样都可能返工：

1. bookmarks.json——整理后的 Chromium 结构，后续所有改动从它出发；
2. bookmarks-整理后.html——标准 HTML，任何时候都能导入恢复，也是换设备时唯一的可靠路径；
3. 变更报告——删了什么、为什么删、改了什么名、结构前后对照，供用户逐条否掉；
4. 可视化检查页（可选）——把 JSON 挂到本地服务上，用拖拽界面微调，比看报告直观。

脚本

organize.py 顶部四张表（TOP_ORDER / TOP_RENAME / MOVES / RENAMES）是示例配置，第一次用先按自己的库改，不要直接跑。

两个脚本的分工不要混：triage.py 只处理新增（几条到几十条，规则驱动、可回退），organize.py 处理结构本身（顶层、二级夹、排序）。日常只用前者。