用途：将承担过多职责的“上帝对象”（类或模块）拆解为各自只负责一件事的内聚单元，遵循单一职责原则（SRP）。
适用判断：类有 10 个以上方法且跨越多个不相关关注点；模块从 5 个以上领域导入（数据库、HTTP、邮件、认证、格式化等）；每次加功能都要改动同一文件；对该类做单元测试需 mock 半个系统；类名以 Manager、Service、Handler、Utils、Helper 结尾却什么都做。
主要流程分四阶段。阶段一审计：逐方法、逐字段梳理职责清单并分组（如认证、持久化、通知、格式化、业务），识别耦合与共享状态，评估每组能否独立成类。阶段二设计目标结构：精确命名新单元（用 UserRepository、UserAuthenticator 等，避免 UserHelper、Utils 这类模糊名），先定义接口/契约，再画依赖图，出现环说明边界划错。阶段三执行拆分：一次只拆一个职责，顺序为先纯逻辑（格式化、校验）、再 I/O 边界（仓储、API 客户端）、最后编排；移动方法时先复制不剪切，让原类委托新类，跑通测试后再删除原方法；共享可变状态应归入某一单元或做成值对象传递，不要留在原类当胶水。阶段四输出：职责映射表、完整的新文件代码、瘦身后的原类，以及迁移说明（公共 API 破坏性变更、构造函数新增注入点、归属模糊的方法）。
启发式与边界：调用两个组的方法属于编排，应留在协调者或建显式用例类；拆分后出现循环依赖说明边界错误；仅 1–2 个方法的小类若职责确实独立也可保留；用组合而非继承拆分；框架特有上帝对象遵循框架约定；拆分后重写测试直接针对新单元。
完成前检查：每个新类只有一个变更理由；新类名不以 Manager、Utils、Helper 结尾；无循环依赖；原类只剩薄协调层；各单元可独立测试；公共 API 变更已记录。
限制：资料未提供该技能的安装命令、平台支持、收费方式或具体实现依赖，暂未提供。