重构遗留代码cursorclaude-code工作流

用 AI 重构遗留代码：从 800 行到 3 个模块

发布 2026-08-02更新 2026-08-02核实 2026-08-02

一句话结论

AI 重构遗留代码的成败，不取决于用 Cursor 还是 Claude Code，而取决于流程：先体检 → 让 AI 出重构计划 → 小步提交 → 每步可回滚。最大的坑是「让 AI 一口气大改 800 行」，结果 diff 没法 review、出错没法定位。把大任务拆成 5-10 个可验证的小步，成功率从约 50% 拉到 90%+。

重构前体检

动手前先用工具摸清代码债，别盲目相信 AI 的「我理解了」：

检查项	工具 / 命令	目的
圈复杂度	`npm run lint`（开 complexity 规则）/ sonarlint	找出「该拆」的函数
测试覆盖	`vitest --coverage` / `pytest --cov`	确认有没有安全网
依赖分析	`madge --circular` / import 可视化	找循环依赖、死代码
类型健康	`tsc --noEmit` / `mypy`	确认类型兜底

AIHO 观点：没有测试覆盖的遗留代码，先让 AI 补测试再重构。补测试是重构的「安全网」——否则你永远不知道 AI 改没改坏逻辑。补测试的方法见用 AI 写单元测试。

让 AI 先出「重构计划」再动手

不要直接说「重构这个文件」。先要计划：

分析 src/legacy/orderService.js（约 800 行），输出重构计划：
1. 识别职责（按业务拆成几个模块）
2. 标出高风险点（状态共享 / 副作用 / 隐式依赖）
3. 给出目标目录结构
4. 列出每步的验证方式（测试 / 手动）
不要改任何代码，只给计划。

AI 给计划后，你 review 风险点，确认无误再进入执行阶段。这一步能挡掉 80% 的「重构改坏逻辑」事故。

分步骤提示词模板

第 1 步：拆分巨型函数

把 processOrder() 按职责拆成 validateOrder / calcPrice / persistOrder 三个纯函数。
保持对外接口不变（仍导出 processOrder）。每拆一个函数补一个单元测试。

第 2 步：提取重复逻辑为 hook / util

扫描 src/ 里重复的日期格式化 / 错误处理代码，提取到 src/utils/。
替换所有调用点，确保行为一致。

第 3 步：加测试

按用 AI 写单元测试的三段式提示词补测试。

第 4 步：验证

跑 pnpm test + pnpm build，确认全绿。对比改动前后行为无差异。

每步回滚策略

铁律：每完成一个子目标就 commit。 任何一步翻车，git reset --hard <上一个干净 commit> 即可。

git add -A && git commit -m "refactor: split processOrder into 3 fns"
# 下一步前再 commit，绝不攒一大坨

Claude Code 用户可用 /rewind 回滚到任意 checkpoint（代码 + 对话）。Cursor 用户每步 Accept 前看 diff 预览，别无脑 Accept All。

AIHO 观点：git 是重构的「无限后悔药」。我们规定「任何单步 diff 不超过 200 行、必须能单独 revert」，AI 改得再顺也不能破这个规矩。

真实案例：90 分钟拆 800 行

一个 Express 的 orderService.js（800 行、0 测试、3 个循环依赖）：

时间	动作	结果
0-15 min	体检 + 让 AI 出计划	拆成 3 模块 + 标 2 个高风险点
15-35 min	拆函数 + 补测试	12 个单测，全绿
35-55 min	提取 utils + 去重复	删 120 行重复代码
55-75 min	去循环依赖 + 类型标注	tsc 通过
75-90 min	全量验证 + commit	测试 + build 全绿

关键：中间第 2 步 AI 把一个副作用写错（改了全局状态），因为每步都 commit，直接 git reset 回到上一步，改提示词重跑，没影响其他进度。

常见失败模式与对策

失败模式	表现	对策
大改一次性提交	diff 没法 review	拆成 <200 行小步
改了测试让它「通过」	假绿	测试先写好再改实现
破坏对外接口	调用方报错	第 1 步明确「接口不变」
引入新依赖	包体积膨胀	禁忌清单写「不引入未声明依赖」