很多程序员用 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 编程、提示词、工程效率和技术内容增长可以继续关注这个系列。