bookmark-organizer

# Bookmark Organizer — 书签策展（curation，非清扫） > **路线已迭代**：从「规则优先 + LLM 兜底」的工具化路线，转向**策展哲学路线**。 > 正则能识别格式，不能识别意义——把策展交给规则，等于把博物馆典藏交给保洁。 > 方法论全文见 `书签治理体系方法论方案_20260612.md`（本 skill 是其执行约定的浓缩）。 ## 🚨 Red Flags: DO NOT SKIP THIS SKILL | agent 会找的借口 | 为什么是错的 | |---|---| | "规则命中率高，直接按 classification-rules 跑就行" | 旧规则优先路线已被否定；书签治理先做人物画像与三层本体裁决，规则只能做机械辅助。 | | "收件箱先留着以后再看" | `⏳ 收件箱` 是缓冲区，不是长期类目；交付时不得残留任何带 URL 的收件箱。 | | "H/敏感内容不好处理，放 H/H2/H3 分卷即可" | 机械分卷不是组织；必须深层中性安置并语义分组，报告只出聚合计数。 | | "大库可以 chunk 并行分类" | 判断类步骤禁止 chunk；人物画像与本体分层必须全局上下文，只有机械步骤可并行。 | ## 🏛 核心：三层本体论 一份 15 年的书签不是一种东西，是三种东西压在同一棵树里。第一层按**行动性**分段，绝不按主题： | 层 | 价值 | 要求 | 例 | |---|---|---|---| | ⚡ **工作台** Workbench | 可达性 | 快 | 家庭控制台、医院内网、高频工具 | | 📚 **资料库** Library | 可检索性 | 有序 | 3D 模型站、设计素材、机场列表 | | 🗿 **年轮** Strata | 存在 > 访问 | 保真 | 2012 年的饭否、威锋越狱帖、雅思报名页 | > 「2011 年怪物猎人配装帖」的真正类目不是「游戏攻略」，是 **「2011 年的我」**。 > **删除只针对「无信息量」，永不针对「过时」**——过时是历史，无信息才是垃圾。年轮删一条 = 烧一页日记。 `⏳ 收件箱` 是缓冲区不是桶：有「清空」约定，治理结束时**不得残留任何带 URL 的收件箱**。 ## ⚖️ 设计决策登记册 D01–D14（执行的唯一裁决依据） | # | 决策要点 | |---|---| | **D01** | 定位为**策展**而非清扫（博物馆隐喻：入库、编目、轮展） | | **D02** | 第一层按行动性分段 `⚡/📚/🗿/⏳`，不按主题 | | **D02-补**（V7） | 用户手动布局可将**工作台条目提至顶层**（每日入口值得一级地产，如 `🏠银杏汇` 从 `⚡常用` 子夹提为顶层图标）；属 D02/D04 内**正当变体非偏差**，复核只在「叶子超额」等机械可判维度介入，不二次裁决用户的本体分层偏好 | | **D03** | 结构铁律：深度 ≤3、单夹 ≤50、一级 ≤10、**禁止「其他/杂项」桶**（收件箱是唯一豁免，因为它有清空约定） | | **D04** | **可投屏原则**：第一层在共享屏幕场合可见而无尴尬；敏感内容深层中性安置 | | **D05** | 删除政策：机械删除仅限 `chrome-extension://`/`chrome://`/重复副本；**死链不删**；判断性删除逐条写理由 | | **D06** | 去重五规则：①策展路径 > 导入树副本 ②取更具体路径 ③取信息量最大标题 ④`add_date` 取全副本**最早值** ⑤导入孤本单独过堂禁批删 | | **D07** | 年代还原 = 最早时间戳 + 内容年代**双源推断**（add_date 在迁移时被重置，单源不可信） | | **D08** | 重命名**分层力度**：活层积极改写；用户自创元数据保留语义、规范形式；年轮层克制（只修裸 URL 与截断）。**过度重命名档案 = 给老照片美颜** | | **D08-补**（V6→V7） | 子桶 **>40 条 或 命名不具语义** 即须按域名/主题再裂一层——二者为**或**关系，**语义命名不豁免容量上限**（V7 中 `综合社区论坛 84`、`门户与资讯 52` 皆语义命名仍超载）；机械序号（H/H2/H3…）禁止作为长期结构。**深度仲裁**：「单夹 ≤50」刚性优先于「深度 ≤3」软预算，冲突时**只允许再裂一层**，硬边界＝条目仍在可用导航深度内（不深埋失访）。H 敏感桶的裂分**报告仅出聚合计数**（子夹名+计数，无明细标题/URL/域名，D12） | | **D09** | 环境绑定书签（内网 10.x/192.168.x/localhost）归对应工作台并在标题注明环境 | | **D10** | 【CC 裁决①】年轮按**生命阶段叙事**组织，命名 = `年代区间 + 时代名`；零散条目落**年代兜底桶**（有语义，不违反 D03） | | **D11** | 【CC 裁决②】bookmarklet 保留，集中封存为时代标本 | | **D12** | 【CC 裁决③】敏感内容深层中性安置（`📚 资料库/影音·PT/H（私密资料）`）；**不**单独导出文件；**报告与 QA 仅出聚合计数** | | **D13** | 【CC 裁决④】死链本轮零探测、零标注（分层判据是「会不会再用」而非「活不活着」） | | **D14** | 执行架构：**判断全局化**（禁止 chunk）、**并行仅机械**、**全程双台账**（删除+重命名）、**原件只读** | ## 🛤 P0–P4 执行管线 | Phase | 性质 | 动作 | 验收门 | |---|---|---|---| | **P0 机械清理** | 零判断，可并行 | 删内部页/脚本；按 D06 去重（最早 add_date 回写；孤本保留） | 行数对账等式成立；抽 20 条删除记录人审 | | **P1 全局画像** | 判断，**全量上下文禁止 chunk** | 确认人物编年史；内容年代双源推断；产出时代划分草案 | 时代划分交用户过目，超时默认采纳 | | **P2 三层分拣** | 判断密集，逐条 | 每条按分拣决策树 → `⚡/📚/🗿/🗑`，附置信度；灰区入待审清单（物理落收件箱，保留 CC 倾向） | 100% 有去向；低置信 ≤10% 且全部人审 | | **P3 结构与重命名** | 判断+机械 | 装配资料库主题树（≤2 层）与年轮时代盒；按 D08 分层重命名 | 结构铁律全过；重命名抽样合格 | | **P4 验收交付** | 验证 | 执行五维验收 | 五维全过，情感验收为最终门 | > **判断永远在全局上下文中做，并行只用于无判断的机械步骤**（D14）——这是前两轮失败的直接反制。 > P2 灰区的存疑项物理落 `⏳ 收件箱`、`suggested` 字段保留 CC 倾向；后续清空轮按时代戳/用途直接落位，不回流。 ## ✅ 五维验收标准 1. **数量对账**：输入 URL 数 = 输出 URL 数（集合逐一相等，零丢失）。 2. **结构铁律**：深度 ≤3、单夹 ≤50、一级 ≤10、无「其他/杂项」桶、无带 URL 的收件箱残留。 3. **命名分层**：活层信息量达标；年轮层未过度美化（定向抽审）。 4. **本体正确**：抽样条目落在正确的层（工作台/资料库/年轮），而非单一主题维度。 5. **情感验收**（最终门）：用户翻开年轮能认出「当年的自己」，有考古乐趣。 > 敏感内容（D12）：以上 QA 全程**仅出聚合计数**，报告不含任何明细标题/URL。 ## 🚧 执行红线（违反即作废重来） 1. **原件只读**：所有操作在副本上；绝不写 Chrome 活动 Profile / 原始导出文件。 2. **判断禁止 chunk**：人物画像与分层裁决必须单上下文全量；并行仅限机械步骤。 3. **URL 零丢失**：搬移只改父子结构，保留原节点（guid / dates / url）；输入=输出。 4. **敏感内容仅聚合**：H 一脉的报告/日志/QA 不暴露标题与链接（D12）。 5. 无 git commit/push、无外部消息（除非用户明确要求）。 ## 📦 产出物 1. **`Bookmarks.v6-cleaned.json`**（或对应版本）—— 完整 Chrome Bookmarks JSON，可重导入。 2. **治理报告 `*-cleanup-report.md`** —— 聚合计数（层级分布、子文件夹分布、验收结果），敏感内容不出明细。 3. **双台账** —— 删除台账（每条理由）+ 重命名台账（原标题 → 新标题），供回滚与审计。 4. 入库时 MD 索引放 Obsidian vault `00-Inbox/`（两阶段收件箱工作流），不直接写终目录。 ## 🧰 脚本（确定性工作交给代码，语义判断交给你） `scripts/` 下的 CLI 仍可用于**机械步骤**：parse（HTML/Chrome JSON 嗅探）、去重对账、render、timeline（年份考古：URL 去重取最早 add_date、迁移批次检测）。 V6 的转换/验收以任务级一次性脚本实现（如 `v6_transform.py` / `v6_verify.py`：逐条 PLACEMENT 映射 + 五维断言），更贴合「策展按条裁决、脚本只做搬运与校验」的分工。 ## ⊗ 反驳关联：已废弃的「规则优先」约定 > 旧版本（[[AI书签整理方案_Hermes集成_20260611(废弃)]] 一脉）的以下主张**已被否定，保留作反面教材**： - ⊗ **「`classification-rules.json` 是唯一类别来源 / 现编类别 = 类别爆炸」** —— 固定 taxonomy 用单一主题维度碾压三种本体，是第 2 轮失败根因。类目来自**人物画像 + 三层本体**，不来自规则文件。 - ⊗ **「L1 规则免费处理 60%，跳过 = 烧 token」** —— 把覆盖率当质量指标。策展的成本花在判断上是应该的，不是浪费。 - ⊗ **「16 chunk 并行分类」** —— chunk 使分类器只见局部、拼不出人物画像，而无画像即无正确分类。**判断必须全局化**（D14）。 - ⊗ **「每条都有类目 = 完成」** —— 覆盖率 ≠ 质量；真正的门是五维 + 情感验收。 旧规则文件可作历史参考，但**不再是分类的事实来源**。 ## ✅ Verification Checklist (RUN BEFORE RETURNING RESULTS) - [ ] 是否先做全局画像与三层本体裁决，而不是直接套固定规则？ - [ ] 是否保证输入/输出 URL 数与唯一 URL 集合完全一致（除非用户明确批准删除）？ - [ ] 是否清空所有带 URL 的 `⏳ 收件箱` / Inbox 桶？ - [ ] 是否消除机械分卷（如 H/H2/H3）并改为语义子文件夹？ - [ ] 敏感内容报告是否只含聚合计数，不含明细标题/URL？ - [ ] 是否生成可复验脚本或命令，并在回禀前真实跑过？ **任一未过，回到对应 Phase 重做；不得只给文字解释。**