在计划重构、代码有异味或需要调整结构而不改变行为时使用。包括重构前立测试基线、小步原子提交纪律（每次只做一种变换）、大规模改动前先用grep确认影响范围、不顺手修bug不混在重构里。适用于AI编程助手代码优化、遗留代码重构、技术债务清理场景。
【适用场景】
什么时候用这个技能？
当你想重构代码、改善结构或消除代码异味，但又不想改变现有行为时，这个技能提供安全可控的重构流程。
典型场景包括：
- AI编程助手代码优化：让AI在保持功能不变的前提下改善代码结构 - 遗留代码重构：在不对现有功能造成风险的情况下逐步改善代码质量 - 技术债务清理：系统性地消除代码异味而不引入新问题 - 代码审查后整改：根据审查意见优化代码结构
这个技能解决什么问题？
重构中的典型问题：改了代码但引入了新bug、修改后行为发生了变化但没发现、重构范围蔓延导致风险不可控。这个技能通过立测试基线和原子提交原则，确保每次重构都是安全的、可回滚的。
【操作步骤】
重构前：立测试基线
Step 1：运行现有测试
在开始重构之前，先跑一遍现有测试，确认全部通过——这是你的安全网。
```bash npm test # 或项目对应的测试命令 ```
Step 2：没有测试的模块先补测试
如果被重构的模块没有测试，先补关键路径测试，确保重构后有参照。
Step 3：记录重构意图
明确重构的目标：这次重构是为了解决什么问题？
记住：重构目标是行为不变，任何行为变化都算新需求，应该另开一个任务处理。
重构中：执行纪律
小步原子提交
每次重构只做一种变换：
- 重命名变量/函数 - 提取一段代码为独立函数 - 调整代码顺序
每步完成后跑测试，确认测试通过再进行下一步。
先机械化后设计
先用工具级别的重构（IDE的重命名、提取函数等功能），再考虑更高层次的设计调整。
确认影响范围
在大规模改动之前，先用grep确认影响范围：
```bash grep -r "函数名" --include=".py" --include=".js" ```
不顺手修bug、不改格式
重构过程中如果发现了其他问题，记下来但不要在这次重构里处理——混在一起就无法回滚。
重构后：收尾自查
对照重构目标逐条检查是否完成。
用git diff通读改动，确认没有意外的行为变化。
关键行为手工验证一次，不能只看测试结果。
【代码模板】
重构前检查清单
``` [ ] 运行现有测试，全部通过 [ ] 为没有测试的模块补充关键路径测试 [ ] 明确重构目标，写下来 [ ] 确认重构范围，不超过本次目标 ```
原子提交日志模板
每次重构提交应该包含：
``` 类型: 重构 描述: [重命名/提取函数/调整顺序] 目标函数/变量 影响: 受影响文件列表 验证: 现有测试通过 + 手工验证结果 ```
影响范围确认命令
```bash
查找函数/变量引用
grep -rn "targetFunction" --include="*.py"查找文件引用
find . -name "*.py" -exec grep -l "TargetClass" {}查看改动统计
git diff --stat ```收尾自查清单
``` [ ] 重构目标逐条完成 [ ] 现有测试全部通过 [ ] git diff 无意外改动 [ ] 关键行为手工验证通过 ```
【复盘要点】
常见错误
| 错误 | 正确做法 |
|---|---|
| 不立测试基线就开始重构 | 先跑测试确认安全网存在 |
| 一次重构做多种变换 | 每次只做一种变换，原子提交 |
| 顺手修发现的bug | 记下来，下次另开任务处理 |
| 改了格式混在重构里 | 格式调整单独做，不在重构里混 |
| 不确认影响范围就动手 | 先grep确认影响面，再开始 |
什么时候不能重构？
- 测试全部失败：先修测试，而不是重构 - 关键功能马上要发布：发布后再重构 - 团队对重构目标没有共识：先讨论清楚再动手
重构与新功能的边界
如果重构过程中发现需要加入新功能：
1. 先完成重构（保持行为不变） 2. 用新commit添加新功能 3. 不要在重构里混新功能
来源：GitHub hackerFish/awesome-dsh-skills 来源URL：https://github.com/hackerFish/awesome-dsh-skills/blob/main/skills/dsh-refactor-safe/SKILL.md