第 23 讲：多文件改动时怎么降低 AI 失控概率

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

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

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

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

常见失控有 5 类：

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

不要直接输入：

复制代码

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

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

复制代码

你先不要修改代码。

请根据下面需求，分析可能涉及的文件、函数、调用链和风险点。

要求：
- 只输出分析，不写代码
- 区分"必须修改""可能修改""不建议修改"
- 标出每个文件为什么会被影响
- 如果信息不足，先列待确认问题

需求：
{{粘贴需求}}

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

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

复制代码

请把这个改动拆成 3 到 5 个小步骤。

每一步必须说明：
- 要改哪些文件
- 为什么先改这一步
- 完成后如何验证
- 如果失败，如何回滚

限制：
- 每一步只解决一个问题
- 不允许顺手重构无关代码
- 不允许修改未列入计划的文件

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

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

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

复制代码

好，全部实现。

建议改成：

复制代码

现在只执行第 1 步。

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

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

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

可以用这段提示词：

复制代码

请检查刚才的改动。

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

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

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

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

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

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

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

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