乐于分享
好东西不私藏

前端与 AI(十五):用 AI 重构代码时,最容易踩的三个坑

前端与 AI(十五):用 AI 重构代码时,最容易踩的三个坑

AI 很适合辅助重构。

它能快速阅读代码。

能找重复逻辑。

能生成替代实现。

能把一段复杂函数拆成几个小函数。

也能帮你补测试和总结 diff。

所以很多人第一次用 AI 重构代码时,会觉得很顺。

但这里也有风险。

重构本来就不是“让代码看起来更干净”。

它的目标是在不改变外部行为的前提下,改善内部结构。

AI 一旦目标不清、范围过大、验证不足,就很容易把小问题改成大风险。

这篇只讲三个最常见的坑。


01|坑一:把重构和改需求混在一起

重构最重要的前提是行为不变。

但 AI 很容易在重构时“顺手优化”。

比如你让它重构一个搜索组件。

它可能同时做了这些事:

  • 拆了 Hook。
  • 改了状态命名。
  • 调整了请求参数。
  • 优化了空状态文案。
  • 顺手加了防抖。
  • 改了错误提示。

这些改动看起来都合理。

但它们已经不只是重构。

它们改变了行为。

一旦出问题,你很难判断是结构调整导致的,还是行为变化导致的。

怎么避免

在提示里明确写:

这次只做结构重构,不改变任何外部行为。不要调整 UI 文案、接口参数、交互时机、权限逻辑和错误提示。如发现可以优化的行为,请列为建议,不要直接修改。

同时要求 AI 输出:

  • 这次重构改变了哪些内部结构。
  • 哪些行为明确保持不变。
  • 哪些潜在优化被暂时延后。

重构和需求修改要分开。

这条规则越早执行,后面越省心。


02|坑二:一次性改太多文件

AI 很擅长大范围修改。

这既是优势,也是风险。

你让它“整理一下这个模块”,它可能一次改十几个文件。

diff 很大。

看起来很系统。

但 Review 会变得困难。

因为你很难快速判断:

  • 哪些改动是必要的。
  • 哪些是顺手优化。
  • 哪些改变了行为。
  • 哪些可以独立回滚。

大 diff 最大的问题不是代码多。

而是意图混在一起。

更稳的做法

把重构拆成切片。

例如一个复杂列表页,可以这样拆:

  1. 先抽出查询参数构造逻辑。
  2. 再抽出列表状态枚举。
  3. 再统一 loading、empty、error 展示。
  4. 再把批量操作封装成 Hook。
  5. 最后清理重复代码。

每一步都应该能单独 Review。

每一步都应该能单独验证。

AI 的价值不是一次吞下所有复杂度。

而是在明确边界内快速完成小步。


03|坑三:没有测试和行为对照

没有行为对照的重构,是最危险的。

AI 可能让代码更简洁。

也可能不小心改变边界行为。

比如:

  • 空字符串和 undefined 的处理不同。
  • 请求参数少了默认值。
  • 权限判断顺序变了。
  • 失败后没有保留用户输入。
  • 防抖导致触发时机变化。

这些问题不一定马上报错。

但会在真实使用中出现。

重构前要先问

  • 当前行为有没有测试保护?
  • 没有测试时,是否能写出手动验证路径?
  • 哪些边界最容易被改坏?
  • 是否有线上数据或用户路径依赖当前行为?
  • 出问题后能否回滚?

如果这些问题回答不上来,就不要让 AI 大范围重构。


04|AI 重构的正确位置

AI 不是不能做重构。

它很适合做几类事情。

任务
适合程度
注意点
阅读复杂代码并总结结构
结果要回源码核对
找重复逻辑和候选抽象
不要直接抽全局能力
小范围函数拆分
保持输入输出不变
补测试骨架
中高
人决定风险优先级
大范围模块重构
中低
必须拆切片和验证
涉及核心业务规则重构
先人工写方案

真正适合 AI 的,不是“请你重构整个模块”。

而是“请你在这个明确目标下,完成一个可验证的小切片”。


05|一个更稳的 AI 重构工作流

可以按六步走。

第一步:先让 AI 读代码

不要直接让它改。

先让它回答:

  • 这个模块入口在哪里?
  • 核心状态有哪些?
  • 哪些逻辑重复?
  • 哪些函数职责过重?
  • 哪些地方风险最高?

第二步:让它提出重构计划

计划里要写清:

  • 目标是什么。
  • 不改变哪些行为。
  • 准备改哪些文件。
  • 每一步如何验证。

第三步:选择一个切片执行

一次只做一个切片。

例如只抽查询参数,不改 UI。

第四步:运行测试或人工验证

没有自动化测试,也要有手动路径。

比如筛选、分页、刷新、失败、权限。

第五步:让 AI 总结 diff 和风险

总结不是走形式。

它能帮助 Review 人快速判断改动意图。

第六步:再决定是否继续下一步

重构不是越快越好。

每一步稳定,整体才稳定。


06|提示词模板

目标:我想重构这个模块的内部结构,不改变外部行为。范围:本次只允许修改 A、B 两个文件,不改接口、不改 UI 文案、不改权限逻辑。参考:请先阅读相关文件,总结当前状态和风险。计划:先给出重构计划,不要直接改代码。验证:说明每一步如何验证行为不变。输出:完成后总结 diff、风险点和需要人工确认的地方。

这个模板的核心不是让 prompt 更长。

而是让 AI 知道边界。

重构最怕自由发挥。

边界越清楚,AI 越能发挥价值。


07|重构后的 Review 要看什么

AI 重构完成后,Review 不应该只看代码是否更短。

更要看行为是否仍然稳定。

可以按这几项检查:

检查项
要确认什么
行为一致
用户路径、接口参数、返回处理是否不变
diff 克制
是否混入无关功能、文案和样式调整
抽象合理
新抽象是否有稳定语义,而不是为了减少行数
回滚容易
如果出问题,是否能单独撤回这个切片
测试有效
测试是否覆盖重构最可能破坏的行为

AI 可能让代码更干净。

但干净不是唯一目标。

重构后的代码应该更容易理解、更容易验证,也更容易继续演进。

如果只是把复杂度从一个文件转移到另一个文件,就不算成功。


结语:AI 能提速,但不能替你定义重构边界

AI 很适合辅助重构。

但重构的责任仍然在人。

你要定义目标,限制范围,保留行为对照,设计验证路径。

如果这些没有做好,AI 只会让风险扩散得更快。

真正有效的 AI 重构,不是一次性改很多文件。

而是在清晰边界里,快速完成可验证的小步。

下一篇讨论 AI 产品交互:

AI 产品为什么不能只有聊天框。