批量代码重构工具

什么时候需要它

改函数名、统一命名、SDK 升级后批量换 API——这类改动往往散落在几十个文件里。手工逐处改容易漏改、改错参数结构，也很难在提交前给出「改了多少处、哪些文件」的清晰摘要。

它怎么工作

技能依赖 read、write、exec，在仓库里做跨文件批量重构，常见场景包括：

• 重命名：如把全库的 getUserInfo 改成 fetchUser
• 模式替换：如把 axios.get/post 换成项目封装的 request.get/post，并尽量保留原有参数
• API 升级：把旧版 SDK 调用批量迁移到新写法

执行策略按规模自动切换：

• 1～9 个文件：用 Grep + Edit 做精准替换，适合局部、需要细控的改动
• 10 个文件及以上：自动进入批量执行模式，按文件逐次处理并汇总结果

典型流程是：先扫描受影响文件 → 按模式执行替换 → 输出变更摘要（文件数、替换次数、错误数）→ 对动态调用、条件分支等边界情况单独列出，便于人工确认。

适用边界

• 替换规则越明确、模式越稳定，效果越好；高度动态或字符串拼接出来的调用，技能会提示你人工核对。
• 大批量改动仍建议在分支上操作，结合 diff 与测试再合并。
• 它解决的是「已知目标形态、可描述为搜索/替换或重命名规则」的重构，不是从零设计架构或做语义级重构决策。