当你的 AI 自动化体系碎片化：四实例合并实录

当你的 AI 自动化体系碎片化：四实例合并实录

上周我打开文件管理器，准备给 Synapse 加一条新规则时，手停住了。桌面上赫然躺着四个 Synapse 目录：Synapse-Mini、Synapse-Work、Synapse-Lab、Synapse-Archive。我试图回忆哪一个是”最新权威版本”——我想不起来。更糟的是，每个目录里的 CLAUDE.md 都在过去两周被各自修改过：这个改了执行链、那个加了新角色、另一个调整了 Hook 配置。我的 AI 自动化体系，在我毫无察觉的情况下，分裂成了四个互相漂移的物种。

漂移是怎么发生的

回看 git log，分裂的轨迹很清晰。第一次 clone 发生在两个月前，我想”试一个新想法，不要搞坏主仓库”——于是多了 Synapse-Lab。三周后换了台机器做客户演示，又 clone 了一份 Synapse-Work。某天我想归档一个旧版本快照，随手拷了份 Synapse-Archive。每一次拷贝当下都有合理动机，但没有任何机制保证改动能回流。于是 Lab 里调优的智囊团评分规则从未进入主仓库；Work 里修复的一个 Hook 路径 Bug 也停留在本地。每个副本都在独立演化，都”能跑”，但没有一个是完整的。

识别配置漂移的三个信号

合并前我先做了诊断。第一个信号是行为不一致：同一句”今天跑情报管线”，在四个目录触发的 Agent 列表不同——有的还在用旧的 agent-butler 命名，有的已改为 agent-CEO。第二个信号是交叉引用失效：某个 SOP 文档引用的 Skill 路径，只在其中两个实例里存在。第三个信号最隐蔽——记忆断层：我在 Lab 里对 Claude 说”按上次讨论的方案”，它茫然失措，因为”上次”的对话历史在 Work 的会话里。当你的 AI 开始频繁要求你”重新说明上下文”，大概率不是模型问题，是你的体系碎了。

合并决策：选权威版，不是选最新版

直觉会说”拿时间戳最新的那份当主干”。我没这么做。我的做法是先列出一张对比矩阵：四个实例 × 七个维度（CLAUDE.md、hooks、agent-CEO/config、skills、obs 知识库、凭证映射、活跃任务）。每个格子标三种状态——最新、有独特价值、已过期。结果很反直觉：没有任何单一实例在所有维度都领先。Mini 的 Hook 配置最稳定、Lab 的 Skill 实验最丰富、Work 的知识库沉淀最厚、Archive 里反而有一个被误删的早期方法论文档。

所以合并不是”选一个删三个”，而是以 Mini 为骨架，按维度择优移植。我把 Mini 定为未来唯一的权威仓库（原因：它的 Git 历史最干净、CI 钩子最完整），然后逐维度从其他三个实例挑零件：Lab 的 skills/ 目录整体合入、Work 的 obs/01-team-knowledge/ 以三路合并方式并入、Archive 里的遗失文档单独恢复为一次命名清晰的 commit。整个过程我强制自己做了两件事：每次移植写一条 commit message 说明来源和理由；所有非权威副本在合并完成后立刻重命名为 Synapse-DEPRECATED-YYYYMMDD，而不是删除——留一周观察期，确保没有遗漏。

可复用的原则

这次合并让我沉淀出四条原则，供任何在规模化使用 AI 工具的团队参考：

**1. 权威版本必须唯一且命名无歧义。**不要依赖”我记得哪个是主的”，要依赖目录名本身。我现在只允许一个叫 Synapse 的目录存在，实验性副本一律带后缀并加有效期。

**2. 拷贝之前，先问能否用分支解决。**90% 的”我想试个新想法”的场景，本质是需要一条 Git 分支，而不是一份新 clone。物理副本是配置漂移的根源。

**3. 建立定期对账机制。**我现在每 7 天跑一次 audit_harness()，对比权威仓库和任何本地副本的关键配置 diff。漂移在 7 天内被发现，修复成本是线性的；漂移两个月才发现，修复成本是指数级的。

**4. 合并按维度择优，不按时间戳择新。**最新的不一定是最好的，最好的往往散落在多个副本中。矩阵对比 + 逐维移植，比”整体覆盖”安全得多。

合并完成那晚，我删掉了桌面上三个 DEPRECATED 目录。AI 再次给出一致的、可预期的行为。那种”只有一个权威版本”的确定感，比任何新功能带来的兴奋都更值钱。

如果你在构建 AI 工程团队，欢迎参考我们开源的 Synapse 框架。