一个包含 6 个独立进程的单仓，最大的文件有 3728 行。
这不是某个人偷懒的结果。它是长期叠加的自然产物：每个新需求都合理地加几行，几百个需求之后就成了这样。问题也不在"行数"本身，而在于没人能在一屏里理解它——于是没人敢改它，它继续变大。
先立边界，再拆文件
拆分之前先解决一个更根本的问题：哪些代码可以互相引用。
做法是物理隔离：共享层禁止 import 引擎层的任何东西。这条规则如果只写在文档里，三个月后就会被无声违反——所以写成了扫描测试：解析整个代码库的 import 关系，出现越界引用就测试失败，边界自检的输出必须是 0。
边界清楚之后，拆文件就变成了机械工作：按职责把大类拆成同名包加多个实现文件，对外 import 路径保持不变，调用方零改动。
顺手把约束一起锁住
用 AST 扫描做守卫测试，把几类隐性约束变成会失败的断言：
· 单个文件不超过 800 行（厂商 SDK 除外）<br />· 所有配置项必须在代码中真实被引用，不允许存在只声明不使用的字段<br />· 新增的配置面必须显式登记
架构约束要靠测试守住，不能靠 code review 时的口头约定。
最终 72 个超长文件清零，最大文件从 3728 行降到 689 行。更重要的是这套守卫会一直生效——它们不会因为某次赶需求而失效。