第 23 讲：多文件改动时怎么降低 AI 失控概率
很多程序员用 AI 改单个函数时感觉还不错，一旦让它跨多个文件改需求，结果就开始失控：改了不该改的文件、漏掉调用方、顺手重构无关代码，甚至把原本能跑的逻辑改坏。
这篇讲一个更稳的做法：多文件改动不要直接让 AI “帮我改完”，而是先让它识别边界、列计划、分批执行、每步验证。
建议收藏这套流程，后面做重构、需求开发、Bug 修复都能复用。我会继续更新《AI 编程提效实战 30 讲》，下一讲会写如何让 AI 帮你设计命令行工具。
为什么多文件改动最容易失控
AI 改多文件代码时，真正的问题通常不是它不会写代码，而是它不知道边界。
常见失控有 5 类：
需求只说结果，没有说明哪些文件能动
AI 没先看调用链，就直接改实现
一次性改太多文件，人工很难 Review
顺手重命名、抽象、格式化，制造无关 diff
没有测试命令和回滚方案，改完只能凭感觉判断
多文件改动的核心不是“让 AI 多写一点”，而是把它从自由发挥拉回工程变更流程。
第一步：先圈定改动边界
不要直接输入：
帮我把这个需求实现一下。更稳的做法是先让 AI 做影响分析：
你先不要修改代码。 请根据下面需求，分析可能涉及的文件、函数、调用链和风险点。 要求： - 只输出分析，不写代码 - 区分“必须修改”“可能修改”“不建议修改” - 标出每个文件为什么会被影响 - 如果信息不足，先列待确认问题 需求： {{粘贴需求}}这一步的目标不是让 AI 显得谨慎，而是让你先拿到一张改动地图。没有地图就开始改，多文件任务很容易变成一堆无法解释的 diff。
第二步：要求 AI 给分批计划
多文件改动最忌讳一次性全改。更好的方式是让 AI 先拆成小批次。
请把这个改动拆成 3 到 5 个小步骤。 每一步必须说明： - 要改哪些文件 - 为什么先改这一步 - 完成后如何验证 - 如果失败，如何回滚 限制： - 每一步只解决一个问题 - 不允许顺手重构无关代码 - 不允许修改未列入计划的文件一个比较稳的顺序通常是：
先补类型、接口、配置或数据结构
再改核心业务逻辑
再改调用方和入口层
再补测试或示例
最后做清理和文档同步
这样做的好处是，每一步都能被 Review，而不是最后面对一大坨改动。
第三步：每次只让 AI 改一小步
如果 AI 已经给了计划，不要继续问：
好，全部实现。建议改成：
现在只执行第 1 步。 限制： - 只能修改计划中列出的文件 - 不要重命名公共函数 - 不要调整无关格式 - 改完后列出实际修改点 - 如果发现计划外文件必须修改，先停止并说明原因这个限制非常重要。它会把 AI 的行动空间压小，也方便你在每一步后做人工判断。
第四步：用验证清单卡住结果
多文件改动不能只看“代码写完了”。每完成一批，都要让 AI 输出验证结果。
可以用这段提示词：
请检查刚才的改动。 按下面结构输出： 1. 实际修改了哪些文件 2. 每个文件为什么需要修改 3. 是否存在计划外改动 4. 需要运行哪些测试或命令 5. 哪些风险仍然需要人工确认 6. 如果要回滚，应该撤销哪些文件这里的重点是“计划外改动”。如果 AI 改了计划之外的文件，就不要急着继续下一步，先让它解释原因。
一个完整可复制模板
下面这段可以直接复制到你常用的 AI 编程工具里：
最后给自己留一条回滚线
多文件改动前，最好先确认 3 件事：
当前分支是否干净，哪些改动是你自己的
是否能用测试、构建或最小复现验证结果
如果 AI 改坏了，能否按批次撤回
这也是为什么我不建议一次性让 AI 改完所有文件。真正能降低失控概率的，不是某个神奇提示词，而是把任务拆小、把边界写清、把验证前置。
总结
多文件改动时，AI 最适合做三件事：
帮你找影响范围
帮你拆分变更步骤
帮你整理验证和风险清单
不要把它当成自动提交代码的工具，而要把它当成一个需要边界和审查的协作者。你可以把今天这套“影响分析 + 分批计划 + 单步执行 + 验证清单”保存下来，下次做重构、联调修复、跨模块需求时直接套用。
我会继续更新《AI 编程提效实战 30 讲》，下一讲写：如何让 AI 帮你设计命令行工具。如果你关注 AI 编程、提示词、工程效率和技术内容增长，可以继续关注这个系列。