工程熵治理

要解决的具体问题

仓库治理最常见的三个死结，根源往往不在代码本身：

• 同构脚本散落：同一类任务在根目录积累出几十个变体脚本，两个 agent 库各自实现了一套传话层，谁也不敢动。
• 文件噪声膨胀：前端仓库几十万文件里，node_modules/ 和 *.map 占掉 95%，真正的源码被淹没，任何检索和度量都失真。
• 多端项目无导航：架构横跨多个端，却没有一份 README 讲清目录角色和共享范式，AGI 和新人都无从下手。

直接 rm 是最容易踩的坑：删完才发现有引用，且不可还原。

核心能力与关键步骤

这个技能的第一性原理是：治理不是删文件，而是先软化、再治根因。熵减的最高杠杆按顺序是 归纳去重 → 软隔离(_TRASH_) → 根因 gitignore → 文档世界模型。

E1 归纳去重：先用文件结构、接口签名比对确认是否真同构（不靠肉眼），再把同构脚本收敛为公共库 + 工具集 + 策略匹配三个核心文件；双库重叠面用 grep 列出后抽取公共层。

E2 软隔离：所有删除类操作先 mv 进 _TRASH_/（backup/、scripts/、reports/ 子目录），确认无引用后清空；README 中存档被删清单，保证可追溯。

E3 根因 gitignore：针对前端膨胀，生成覆盖 node_modules/、dist/、*.map、.env 的 .gitignore，从度量上消除噪声——先隔离再评估。

E4 文档世界模型：根目录 README.md 用架构图 + 目录导航表串联各端，标注共享传话层范式与快速开始。

E5 双库分叉识别与合并：以「传话层通用 helper」为迁移单元，每迁移一个就跑两库单测 + 全仓 import 闭合审计，保留薄封装向后兼容，进度用「已统一 helper / 重叠面总数」度量。

通用执行协议：可逆优先、治根因不治现象、文档即地图；安全原则要求透明、可控、可逆、渐进，以及合并时的导入一致性。

适用边界与注意点

• 软隔离是不可跳过的必走步骤，不是可选项；_TRASH_ 未清空前才算清理完成。
• README 必须严格区分「现状 vs 规划」，把规划写成已实现会让后续决策基于错误世界模型。
• 只清噪声不补 .gitignore，文件数很快回潮——根因未治等于没治。
• 双库合并属于长周期项，应识别后规划主干，而非期待一次性改完；渐进快赢（清理、gitignore、README）先行。