用途
Refactoring Code 是一个系统化的代码重构方法论技能，用于在保持现有行为不变的前提下，改善代码结构、可维护性与简洁性。其核心原则是：重构改变的是结构，而不是功能；安全与清晰比优雅更重要。如果改变了代码“做什么”（而不仅是“怎么做”），那就不是重构，而是重写。
主要能力
该技能围绕以下职责展开：
- 简化复杂代码：拆分复杂函数、减少嵌套、提升可读性。
- 提取模式：识别并抽取可复用的组件、hooks、工具函数。
- 消除重复：应用 DRY 原则，同时避免过早抽象。
- 提升类型安全：强化 TypeScript 使用，尽可能消除 any 类型。
- 性能优化：识别不必要的重渲染，优化数据结构。
- 对齐规范：确保代码遵循项目模式与约定。
使用方式：五阶段重构流程
技能要求必须完成每个阶段后才能进入下一阶段，并提供可勾选的进度清单。
阶段一：理解当前行为。 彻底阅读现有代码，理解目的而非仅实现；识别输入、输出与副作用；用 Grep 查找所有调用点；记录当前行为、隐式契约与性能特征。完成标准是能用平实语言解释代码做什么、所有调用点与依赖已识别、当前行为已记录。
阶段二：验证测试覆盖（关键）。 在重构前确保存在行为驱动的测试，验证用户可观察的行为而非实现细节。技能给出了正反示例：好的测试通过真实依赖、按角色/标签/文本查询，验证用户工作流；坏的测试依赖内部状态或函数调用，会在重构时误报失败。若测试缺失或测的是实现细节，应先补充行为驱动测试并确保通过。
阶段三：识别问题。 系统化编目待改进项，常见类型包括：复杂度（嵌套超过 3 层、函数超过 50 行、参数超过 4 个）、重复（复制粘贴、重复模式）、命名不佳、类型安全缺口（any、缺失类型、类型断言）、性能问题（不必要重渲染、低效算法、包体积过大）、模式违规。完成标准是所有问题已记录位置、按类型与严重度分类、理解根因。
阶段四：制定重构计划。 将大重构拆分为小而可验证的步骤，每步可独立测试；按影响与风险排序，先做高影响低风险（如重命名变量），推迟高风险改动（如算法重写）；考虑向后兼容与渐进弃用；规划每步的验证方式。技能给出了将“抽取用户认证逻辑为可复用 hook”拆解为 7 步的示例。
阶段五：执行与验证。 一次只做一个改动，每次编辑单一职责，频繁提交，每次改动后运行测试，检查 TypeScript 编译（如 tsc --noEmit），必要时手动验证行为。若出现问题应立即停止，使用系统化调试技能排查，未理解根因前不继续，必要时回滚。
适用场景
适用于清理代码、减少重复、简化复杂度、增强类型安全、优化性能、对齐项目规范等。技能还提供了常见重构模式速查表，例如：长函数拆分为多个聚焦函数、重复代码提取为共享工具、深层嵌套改为提前返回与守卫子句、魔法数字改为命名常量、大组件拆分为小组件、复杂条件提取为命名函数、原始类型偏执改为类型/接口、长参数列表改为参数对象。
限制与边界
技能明确列出了红旗警示，出现时应停止并重新评估：重构时改变行为（那是重写）、跳过测试、为消除复杂度而增加复杂度、追求“聪明”的代码、删除解释“为什么”的注释、未考虑消费者就破坏现有 API、在模式出现三次前就抽象（三次法则）。同时给出了停止重构的标准：代码清晰易懂、重复已消除且未过度抽象、类型明确安全、测试通过且覆盖率维持、遵循项目规范、团队成员无需解释即可理解。若只是让代码“优雅”却更难理解、在模式出现三次前抽象、重构稳定且短期不会变的代码、未测量就优化性能，则不应继续重构。
该技能还要求与其他技能配合：添加行为驱动测试时需使用 writing-tests，重构意外破坏测试时需使用 systematic-debugging；并建议在声称重构完成前使用 verification-before-completion，编写测试时避免 testing-anti-patterns。
暂未提供的信息
资料未提供该技能的具体安装命令、支持的平台、收费或价格信息，也未提供官方文档链接之外的额外资源。