memory-audit-node-decomposition

# 节点分解 (Node Decomposition) 你面前有一条记忆，它不是死数据——里面装的东西确实有用——但它把多个独立概念塞进了同一个节点，导致无论你怎么写 disclosure 都无法精准覆盖全部内容。这是 `memory-audit-pattern-extraction`（合并上提）的逆运算：把一个臃肿的杂烩拆分成多个聚焦的独立节点。 --- ## 诊断信号 以下任一条件成立，就该拆分： - **体积信号**：单篇记忆体积 > 800 Tokens，且不是因为功能本身需要这个体量（如用户的完整档案），而是把多个主题塞进了同一个节点、或平铺了未经提炼的经验。 - **disclosure 失焦**：你写了一个 disclosure，但读完发现它只能触发这条记忆一半的内容。另一半在完全不同的场景下才有用。一条 disclosure 无法服务两个独立概念——这说明它们不该住在一起。 - **阅读时的跳读冲动**：当你读这条记忆时，你本能地跳过某些段落去找你需要的那部分。被跳过的部分和被读的部分属于不同的概念。 --- ## 拆分流程 **1. 识别概念边界。** 通读全文，标出独立的概念单元。判断标准：如果这两段话分别出现在两条不同的记忆里，它们的 disclosure 会完全不同吗？会→它们是独立概念，该拆。不会→它们是同一概念的不同侧面，不拆。 **2. 为每个概念确定归属。** 拆出来的概念不一定都留在原父节点下。问自己：未来的我在什么场景下需要想起这段话？那个场景对应的父节点是什么？按 `memory-audit-discoverability` 中的注意力狙击原则放置。 **3. 为每个新节点写独立的 disclosure。** 每条 disclosure 必须只对应一个概念。如果你发现一条 disclosure 仍然需要用"以及"、"同时"来连接两个触发场景——你没有拆干净。 **4. 处理原节点。** 当你把具体概念剥离成子节点后，原节点只剩下两种归宿： - 所有内容都已拆空 → **删除原节点**。 - 保留一个最核心的通用主张 → 用 `update_memory` 瘦身，让它成为新层级的父节点。 **多层过滤器原则（绝対禁止纯索引）：** 此原则适用于所有充当父节点的记忆——无论是被瘦身后保留的原节点，还是在拆分过程中**新建**的分组父节点。 绝不能让任何父节点沦为一个只写着"本话题包含以下几个方面，请查阅子节点"的目录页。你的 `read_memory` 机会极其有限，且每次下钻继续阅读子节点的几率都会衰减。如果花了一次检索机会，只读回来一个路标，这次检索就浪费了。 **记忆层级不是分类抽屉，而是层层递进的认知支架。** 每一层父节点自身应携带足以应对一般情况的核心认知；子节点只在遇到特定复杂情境、父节点的理解不够用时，才通过独立的 disclosure 引导继续深挖。 **空心节点词汇黑名单（硬性拦截）：** 在你写完一个父节点的内容后，立刻扫描你刚写的文字。如果出现以下任何一种句式，判定为废稿，强制重写： - "这里存放……"、"这里包含……"、"本目录存放……" - "包含以下几个方面"、"分为以下几类" - "详见子节点"、"请查阅子节点" - 任何只描述子节点分类而自身不携带可执行认知的内容 **父节点的正确写法**：以明确的第一人称视点，写下我对该领域当前最核心、可独立使用的认识。教训领域保留关键经历、反思与当前态度；事实资料领域保留重要观察、出处和判断基线。不把这些内容改写成无主语的“铁律”或“禁令”。读完父节点，即使暂时不点开子节点，我也应能处理该领域的一般情况。 **5. 质检。** 拆分后的所有节点（包括子节点和父节点）必须通过以下两项测试： - **冷启动质检**：一个刚开机的全新实例，能独立看懂这条记忆吗？（同 `memory-audit-dead-data-purge` 标准） - **父节点压力测试（仅父节点）**：假设删掉该父节点下所有的子节点，只看父节点自身的正文——如果它变成了一句正确但无用的废话（如"这里是技术规范"），这个父节点不合格，必须回到步骤 4 重写。