用 AI 重构老项目应该先让它干什么？

先读懂，再下手。本章模板让 AI 阅读关键文件后输出 3 件事：总结职责和主要数据流、标出耦合点和技术债、给出 5 步以内的重构计划（优先小步、可回滚）。先让 AI 画“地图”和 plan，确认方向对了再落 patch —— 一上来就改代码，AI 容易把不该动的也动了。

AI 做提取函数/组件时怎么避免它顺手改了业务逻辑？

prompt 里明确写“不要改业务逻辑”，并要求最小可行 patch。再加一道安全网 —— 修改前先让 AI 加类型或单测，把现有行为锁住，重构时一旦行为漂移测试会立刻报警。重构后再让 AI 写一段快速验证脚本（命令或手测），整步可回滚再 commit。

让 AI 提“分批文件列表 + 检查点”，而不是一次全改。同时要求生成 shim 或 adapter 作为兼容层，迁移完成再删除。这样每一批改完都能跑通现有 build，不会出现“切到一半两套代码同时跑不动”的死锁。CommonJS → ESM 同样的套路。

本章给两条：(1) 删除了大量代码且解释不清 —— 要求 AI 逐行说明理由，否则不合并；(2) 引入了新依赖但没说明版本和用途 —— 直接拒绝，要求补充。这两种情况大概率是 AI 在“看似合理地”把你不知道存在的功能删了，或者偷偷拉了个未审计的包。

本章练习给的步骤：让 AI 先写出重构计划，再交付 2 步 patch。每一步 patch 完都跑 lint 和 test，或者手测一遍，记录耗时和风险点。两步是刻意选的小颗粒度 —— 比“一次给我重构完”安全得多，出问题能立刻 git checkout 回到上一步。

📖

38 节

基础篇6

进阶篇18

工具篇13

实战篇1

让你的学习不被打断

👥2,847 人正在学习