memory-audit-node-decomposition

---
name: memory-audit-node-decomposition
description: 节点分解。当一个节点体积过大、或塞了多个不相关概念导致disclosure无法覆盖时使用。
disable-model-invocation: false
---

# 节点分解 (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 重写。