用途：在不改变代码行为的前提下改进现有代码结构。适用于用户要求重构、清理、重组或简化代码，功能因现有结构难以添加，重复代码需多处修改，模块过大难以理解，或耦合导致单元无法独立测试等场景。测试未通过、不理解当前行为或作为功能分支附带任务时不应重构。
主要能力与核心概念：区分“加行为”与“重构”两顶帽子，同一编辑中不同时做；重构前提是行为可观测，即覆盖待改动路径的绿色测试套件；每步足够小、可单独命名和回退，每步后运行测试；先让改动变容易，再做容易的改动。
使用方式：1. 确认工作树干净且测试通过，如 git status --short、npm test；2. 用一句话命名坏味道与目标形态；3. 覆盖不足时先补特征测试，如 pytest --cov=orders --cov-report=term-missing tests/orders；4. 每次只应用一个变换，优先使用 IDE 自动重构；5. 每步后运行测试，失败则回退上一步；6. 重复直到达到目标形态即停止；7. 验证行为未变，如 git diff main --stat、git diff main -- '*.d.ts' 'openapi.yaml'。
适用场景与限制：识别霰弹式修改、发散式变化、依恋情结、基本类型偏执、长参数列表、重复类型条件等坏味道。最佳实践包括每次提交一个重构、不混入行为变更、优先删除死代码、朝下一个功能重构。反模式包括无测试重构、伪装成重构的大爆炸重写、修复途中重构、第二次出现就抽象、静默更改公共契约、重构即将删除的代码。资料未提供具体收费、价格、平台或效果信息。