代码重构 Prompt：让 AI 做安全的大规模重构

用法

对需要重构的代码，配合下面的 prompt。适合跨文件重构、改接口签名、提取公共逻辑等场景。

Prompt

我需要重构以下代码，请按安全重构流程执行，不要跳步：

## 1. 影响分析（先做这个，不要改代码）
列出这次重构会影响的所有文件和函数：
- 直接影响：被改的文件 / 函数
- 间接影响：调用方 / 被调用方
- 测试影响：哪些测试需要更新

## 2. 测试基线（确保重构前测试通过）
- 跑一遍现有测试，确认全绿
- 如果没有测试，先帮我写覆盖当前行为的测试（不要写期望行为）
- 测试不过就停下，不要继续重构

## 3. 重构计划
把重构拆成 N 个小步骤，每步：
- 改什么（具体到文件 + 函数）
- 为什么这步是安全的
- 这步后测试应该仍然全绿

## 4. 分步执行
按计划逐步执行，每步完成后：
- 跑测试
- 如果测试失败，立即回滚这一步，告诉我原因
- 测试全绿才继续下一步

## 5. 清理
- 删除废弃的旧代码
- 更新相关注释和文档
- 跑完整测试套件最终确认

## 规则
- 不要一次性改超过 3 个文件
- 不要改变公共 API 的行为（签名可以加可选参数，不能删/改已有参数）
- 不要在重构时顺便修 bug（另开任务）
- 每一步都要可独立提交

---

需要重构的代码：
（粘贴代码或描述重构需求）

效果

不加 prompt 时 AI 经常一把梭——一次改 10 个文件，测试挂了不知道哪步出错。

加了这条 prompt 后 AI 被迫分步执行，每步验证，出问题能立即定位到具体步骤。大幅降低重构引入 bug 的概率。

分步执行长什么样

比如"把回调风格的 fetchUser(id, cb) 改成 Promise 风格"，跨 8 个调用点。这条 prompt 会让 AI 这样走：

1. 影响分析：grep 出 8 处调用 + 3 个测试文件，列清单。
2. 测试基线：先跑现有测试确认全绿；某调用点没测试，先补一个覆盖当前回调行为的测试。
3. 计划：拆成"① 新增 Promise 版函数（保留旧版）→ ② 逐个迁移调用点 → ③ 删旧版"三步。
4. 分步执行：每迁一个调用点跑一次测试；第 5 个调用点迁移后测试红了，立即回滚这一步并报告"该处依赖了回调的同步副作用"，而不是硬改完 8 个再说。

关键在第 4 步的"红了就停、回滚、报告"——这是和"一把梭"最大的区别。一把梭改完 8 个文件测试挂了，你根本不知道是哪一处引入的。

何时用这条、何时用轻量版

• 改一段代码、不跨文件 → 用 安全重构 Prompt（更轻）
• 跨文件、改签名、提取公共模块 → 用本条

为什么有效

• 强制先做影响分析：大规模重构翻车几乎都不是因为改错，而是因为没改全——影响面清单是唯一的防线。
• 要求先建测试基线：没有绿测基线，重构后的「通过」毫无意义，这是大规模重构 Playbook 里的第一步。
• 分步执行 + 每步可验证：一次性大改会让 diff 无法 review，分步让每一步都能单独回滚。

进阶（自动化）

用 worktree 隔离重构分支，边改边跑主分支测试对照：

git worktree add ../refactor-branch -b refactor/auth
cd ../refactor-branch && pnpm test   # 确认基线绿
# 每完成一步：跑测试 + 单步 commit，便于二分
git commit -am "refactor(auth): step 3 — extract token service"

并行推进多个重构任务时，见 git worktree 并行 Agent 工作流。

反例（AI 默认会写的烂版本）

默认输出：直接给一份「重构后」的完整文件，2000 行 diff，测试跑挂了也不知道是哪一步引入的。

加了 prompt 之后：先输出影响清单（12 个调用点、3 处测试、1 个导出符号），再给 5 步计划，每步一 commit、每步跑测试，第 3 步失败时能直接 revert 到 step 2。

延伸阅读

• 安全重构 Prompt · 测试生成 Prompt
• 大型重构的 AI Agent 工作流 — 把这条 prompt 嵌进完整流程