用途
递归分解协议用于在决定“构建新系统”之前，将目标系统、仓库或架构逐层拆解，并与已有基座进行诚实对比，使“构建新”这一结论是被论证出来的，而非默认假设。它主要解决代理或开发者因只接触系统表层（Macro 层）而误以为一切独特、进而重复实现已有工具的问题。
四个层级
协议将系统分为四层，每层对应一个核心问题与粒度：
- Macro（整体系统）：整个东西是做什么用的？粒度为一个系统。例如“跨会话持久化记录所有提示词的注册表”。
- Bricks（组件）：由哪些组件构成？粒度为 3–12 个组件。例如捕获钩子、会话解析器、索引生成器、归档存储。
- Elements（概念原语）：组件操作哪些概念？粒度为 5–20 个概念。例如会话、提示词原子、捕获事件、索引条目、归档路径。
- Primitives（基础操作）：概念之下反复出现哪些基础操作？粒度为一个小型封闭集合。例如仅追加写入、内容哈希去重、frontmatter 解析、glob 遍历、ID 生成。
分解是递归的：任何无法用一句话说清的 Brick，都需要单独进行四层分解。
工作流程
-
读取声明意图：只读方式读取 seed.yaml（或仓库的清单/章程等价物），它声明系统自认为是什么。若无 seed，则记录为治理发现（未声明系统），并从 README 与入口点重建意图。在形成自己的判断前，逐字记录声明的 Macro 陈述。
-
自顶向下遍历源码：从入口点 → 主要模块 → 数据文件。每一层问层级问题，不是“这段代码做什么”，而是“它由什么构成”。Bricks 列表应来自实际结构（目录、服务、脚本），而非文档声明；与 seed 的声明做差异对比并记录分歧。
-
自底向上提取 Elements 与 Primitives：Elements 是跨多个 Brick 存活的共享概念词汇；若一个名词只出现在一个 Brick 中，则属于内部细节而非 Element。Primitives 是 Elements 之下反复出现的动词/操作。判断原语性的测试：该操作能否被提升为无领域知识的库？若能，则为 Primitive。保持 Primitive 集合小而封闭；原语列表过于庞杂意味着你停在了高一层。
-
构建基座对比表：对范围内每个已有基座（兄弟仓库、平台服务、先前系统），按层对比。表格列包括层级、新系统、基座 A、基座 B、裁决。单元格词汇：✅ 相同 / ≈ 重叠（指出差异）/ ❌ 缺失。
-
发布复用裁决：真正新颖的最高层级决定构建姿态：
- 新颖 Macro、下层共享 → 在已有基座上做薄组合，只构建组合部分。
- 新颖 Bricks → 在已有系统内新增组件；扩展而非分叉。
- 仅新颖 Elements/Primitives → 几乎总是误读，需重新审视。
- 无新颖 → 吸收：所谓“新系统”只是已有系统的一个视图，将需求路由到那里。 明确陈述裁决及支撑它的层级。将分解与表格作为工件提交，它是构建决策引用的证据。
反模式
- 仅从文档分解：README 描述的是愿景，应遍历源码。
- 停在 Bricks：组件级对比会掩盖复用——多数“窃取”发生在 Elements 与 Primitives 层。
- 与零个基座对比：没有对比表的 boil-down 只是图，不是协议；表格才是交付物。
- 将 seed 视为绝对真理：它是系统的自我形象；seed 与源码的分歧本身就是顶级发现。
- 开放式原语列表：若 Primitives 超过约 12 个，说明层级混淆；应将领域特定的提升回 Elements。
适用场景与限制
该协议适用于评估是否应新建系统、仓库或架构，尤其适合代理委派场景中避免重复造轮子。其限制在于：需要可访问的源码与已有基座信息；若缺乏对比基座，协议效果受限。资料未提供具体平台、收费、价格或效果数据。