很多程序员用 AI 改单个函数时感觉还不错，一旦让它跨多个文件改需求，结果就开始失控：改了不该改的文件、漏掉调用方、顺手重构无关代码，甚至把原本能跑的逻辑改坏。

这篇讲一个更稳的做法：多文件改动不要直接让 AI “帮我改完”，而是先让它识别边界、列计划、分批执行、每步验证。

建议收藏这套流程，后面做重构、需求开发、Bug 修复都能复用。我会继续更新《AI 编程提效实战 30 讲》，下一讲会写如何让 AI 帮你设计命令行工具。

为什么多文件改动最容易失控

AI 改多文件代码时，真正的问题通常不是它不会写代码，而是它不知道边界。

常见失控有 5 类：

• 需求只说结果，没有说明哪些文件能动

• AI 没先看调用链，就直接改实现

• 一次性改太多文件，人工很难 Review

• 顺手重命名、抽象、格式化，制造无关 diff

• 没有测试命令和回滚方案，改完只能凭感觉判断

多文件改动的核心不是“让 AI 多写一点”，而是把它从自由发挥拉回工程变更流程。

第一步：先圈定改动边界

不要直接输入：

帮我把这个需求实现一下。

更稳的做法是先让 AI 做影响分析：

你先不要修改代码。 请根据下面需求，分析可能涉及的文件、函数、调用链和风险点。 要求： - 只输出分析，不写代码 - 区分“必须修改”“可能修改”“不建议修改” - 标出每个文件为什么会被影响 - 如果信息不足，先列待确认问题 需求： {{粘贴需求}}

这一步的目标不是让 AI 显得谨慎，而是让你先拿到一张改动地图。没有地图就开始改，多文件任务很容易变成一堆无法解释的 diff。

第二步：要求 AI 给分批计划

多文件改动最忌讳一次性全改。更好的方式是让 AI 先拆成小批次。

请把这个改动拆成 3 到 5 个小步骤。 每一步必须说明： - 要改哪些文件 - 为什么先改这一步 - 完成后如何验证 - 如果失败，如何回滚 限制： - 每一步只解决一个问题 - 不允许顺手重构无关代码 - 不允许修改未列入计划的文件

一个比较稳的顺序通常是：

1. 先补类型、接口、配置或数据结构

2. 再改核心业务逻辑

3. 再改调用方和入口层

4. 再补测试或示例

5. 最后做清理和文档同步

这样做的好处是，每一步都能被 Review，而不是最后面对一大坨改动。

第三步：每次只让 AI 改一小步

如果 AI 已经给了计划，不要继续问：

好，全部实现。

建议改成：

现在只执行第 1 步。 限制： - 只能修改计划中列出的文件 - 不要重命名公共函数 - 不要调整无关格式 - 改完后列出实际修改点 - 如果发现计划外文件必须修改，先停止并说明原因

这个限制非常重要。它会把 AI 的行动空间压小，也方便你在每一步后做人工判断。

第四步：用验证清单卡住结果

多文件改动不能只看“代码写完了”。每完成一批，都要让 AI 输出验证结果。

可以用这段提示词：

请检查刚才的改动。 按下面结构输出： 1. 实际修改了哪些文件 2. 每个文件为什么需要修改 3. 是否存在计划外改动 4. 需要运行哪些测试或命令 5. 哪些风险仍然需要人工确认 6. 如果要回滚，应该撤销哪些文件

这里的重点是“计划外改动”。如果 AI 改了计划之外的文件，就不要急着继续下一步，先让它解释原因。

一个完整可复制模板

下面这段可以直接复制到你常用的 AI 编程工具里：

最后给自己留一条回滚线

多文件改动前，最好先确认 3 件事：

• 当前分支是否干净，哪些改动是你自己的

• 是否能用测试、构建或最小复现验证结果

• 如果 AI 改坏了，能否按批次撤回

这也是为什么我不建议一次性让 AI 改完所有文件。真正能降低失控概率的，不是某个神奇提示词，而是把任务拆小、把边界写清、把验证前置。

总结

多文件改动时，AI 最适合做三件事：

• 帮你找影响范围

• 帮你拆分变更步骤

• 帮你整理验证和风险清单

不要把它当成自动提交代码的工具，而要把它当成一个需要边界和审查的协作者。你可以把今天这套“影响分析 + 分批计划 + 单步执行 + 验证清单”保存下来，下次做重构、联调修复、跨模块需求时直接套用。

我会继续更新《AI 编程提效实战 30 讲》，下一讲写：如何让 AI 帮你设计命令行工具。如果你关注 AI 编程、提示词、工程效率和技术内容增长，可以继续关注这个系列。