夜雨聆风很多小白使用 AI 编程工具时，会遇到一个很典型的问题：
你只是想改一个按钮文案，AI 却顺手重构了整个组件。
你只是想修一个报错，AI 却改了样式、数据结构、接口调用，还新增了依赖。
最后你很难判断：原来的 bug 到底修没修好？新的问题又是从哪里来的？
这篇文章讲一个非常实际的能力：如何让 AI 不乱改代码。
核心方法不是让 AI “更听话”，而是你要明确修改范围、约束输出格式、要求最小改动，并在修改前后做检查。
一、AI 为什么会乱改
AI 乱改代码，常见原因有 5 个。
第一，你的需求太宽。
比如：
帮我优化一下这个页面。“优化”可以指样式优化、性能优化、结构优化、交互优化、代码重构。AI 不知道你具体要哪一种。
第二，你没有说不要改什么。
如果你只说“修一下登录问题”，AI 可能会顺手改登录页、接口请求、状态管理、路由跳转。
第三，你让 AI 一次做太多事。
任务越大，AI 越倾向于改多个文件。
第四，AI 缺少项目约束。
它不知道项目已有规范，可能引入新的写法、新依赖、新目录结构。
第五，你没有要求它先给计划。
AI 直接动手时，你没有机会提前发现它准备改太多。
二、最重要原则：一次只改一个目标
小白使用 AI 改代码时，最稳的原则是：
一次只解决一个明确问题。不要这样说：
帮我修一下登录问题，顺便把页面做漂亮点，再优化一下代码结构。这句话同时包含：
修 bug。
改样式。
重构代码。
三个目标混在一起，出问题时很难定位。
更好的方式是拆开：
第一步：只修复登录按钮点击后没有反应的问题。不要修改样式，不要重构代码。
等 bug 修好并测试通过，再做第二步：
第二步：只调整登录页面视觉样式。不要修改登录逻辑和接口调用。
拆小任务，是控制 AI 的第一道防线。
三、在提示词里明确“只改哪里”
你要把修改范围写得具体。
不够好的说法：
帮我改一下首页。更好的说法：
请只修改首页标题区域的文案。不要修改按钮、列表、接口请求、路由和样式。
如果你知道文件路径，也要写出来：
请只修改 src/pages/HomePage.vue。不要修改其他文件。
如果你不知道文件路径，可以先让 AI 查找：
请先判断这个功能可能涉及哪些文件。暂时不要修改任何文件。
先定位，再修改。不要让 AI 一边找一边大改。
四、在提示词里明确“不要改什么”
“不要改什么”和“要改什么”同样重要。
可以直接写：
不要修改：1. 页面布局。2. 接口地址。3. 数据字段名。4. 路由配置。5. 依赖版本。6. 无关文件。
如果是修 bug，可以写：
只修复当前报错。不要重构，不要改样式，不要新增功能，不要升级依赖。
如果是改样式，可以写：
只修改 CSS 或样式类名。不要修改 JavaScript 逻辑，不要修改接口请求，不要修改数据结构。
这些限制能显著降低误改风险。
五、要求 AI 先给修改计划
不要让 AI 直接开改。
先要求：
请先给修改计划。计划里必须包含：1. 准备修改哪些文件。2. 每个文件改什么。3. 为什么必须改。4. 哪些文件不会改。5. 可能风险是什么。在我确认前，不要写代码。
这个步骤的价值很高。
如果你只是想改按钮文字，但 AI 计划修改 5 个文件，就说明它理解偏了。你可以及时纠正：
范围太大。 请改成只修改按钮文字，不要修改组件结构和样式。计划阶段发现问题，成本最低。
六、要求“最小修改方案”
最小修改方案，就是只改必要代码，不顺手重构。
可以这样要求：
请给最小修改方案。 只修改完成这个目标必须修改的代码。 不要做风格优化、结构优化或额外封装。如果 AI 给出大段代码，你可以继续压缩范围：
这个方案改动太大。 请重新给一个最小 diff，只改必要的几行。如果 AI 说必须大改，你要让它说明理由：
请说明为什么不能用更小改动解决。 如果必须改多个文件，请逐个说明必要性。对小白来说，可理解的小改动优先级高于看起来更“高级”的重构。
七、要求 AI 使用“替换前/替换后”格式
如果你手动复制代码，最怕不知道放哪里。
可以让 AI 用这种格式：
请按下面格式输出：文件：【文件路径】找到这段代码：【原代码】替换为：【新代码】修改原因：【一句话说明】
这个格式适合小白手动修改。
如果使用 AI 编程工具自动改文件，也可以要求它最后总结：
修改完成后，请列出：1. 实际修改了哪些文件。2. 每个文件改了什么。3. 是否有未按计划修改的地方。
这样你能核对 AI 是否越界。
八、不要轻易允许新增依赖
AI 有时会为了方便引入第三方库。
比如为了格式化日期，引入一个日期库；为了做弹窗，引入一个 UI 库；为了处理状态，引入一个状态管理库。
这不一定错，但对小白来说，新增依赖会带来额外风险：
需要安装。
可能版本不兼容。
项目体积变大。
后续维护更复杂。
你更难理解代码。
所以默认写：
不要新增第三方依赖。如果你认为必须新增，请先说明原因，并给出不新增依赖的替代方案。
多数小功能不需要新增依赖。
九、不要轻易允许重构
重构不是坏事，但不适合和修 bug 混在一起。
重构的特点是：功能看起来不变，但代码结构变化很大。
如果你让 AI 在修 bug 的同时重构，就很难判断问题：
是 bug 原本没修好？
是重构引入了新问题？
是测试步骤不完整？
所以可以写：
本次任务禁止重构。只允许为修复当前问题做必要修改。如果你发现代码结构问题，请单独列为后续建议，不要现在执行。
这句话能把“当前修复”和“未来优化”分开。
十、让 AI 标记不确定点
AI 乱改的一个原因是它假设自己知道全部上下文。
你要让它明确不确定点：
如果你不确定某个函数、组件、接口或字段是否存在，请明确说不确定。不要编造不存在的文件、函数或接口。
还可以要求：
在修改前，请列出你基于代码确认的事实，以及你仍然不确定的信息。这能帮助你区分“代码里明确有的东西”和“AI 推测的东西”。
十一、用版本备份降低风险
即使提示词写得很好，AI 仍然可能改错。
所以真实项目里，修改前要有回退点。
如果你会 Git，建议先提交一次：
git statusgit add .git commit -m "before ai change"
如果你不会 Git，至少复制一份项目文件夹备份。
然后再让 AI 修改。
这不是多余步骤。没有回退点时，小白很难从一堆改动里恢复原状。
十二、修改后检查 AI 是否越界
修改完成后，不要只看它说了什么，要检查它改了什么。
你可以让 AI 自查：
请检查本次修改是否越界：1. 是否修改了我没有要求的文件？2. 是否新增了依赖？3. 是否改变了接口字段或数据结构？4. 是否重构了无关代码？5. 是否影响了其他页面或功能？
如果使用 Git，可以查看差异：
git diff不会看 diff 也没关系，可以把差异交给 AI：
下面是 git diff。请帮我判断这次改动是否只围绕我的需求。如果有越界修改，请指出文件和原因。
十三、一个“防乱改”通用提示词
下面这段可以直接复制：
我是 0 基础编程小白。请帮我完成一个小修改。目标：【写清楚本次只做什么】允许修改范围：1. 【允许修改的文件或功能】2. 【允许修改的代码区域】禁止修改范围：1. 不要修改无关文件。2. 不要重构代码。3. 不要新增第三方依赖。4. 不要修改接口地址和字段名。5. 不要修改页面布局，除非本次目标明确要求。执行方式：1. 请先给修改计划，不要直接写代码。2. 计划中列出准备修改的文件和原因。3. 如果信息不足，请先问我。4. 我确认后，再给最小修改方案。5. 修改完成后，列出实际改动和测试步骤。
这个模板适合大多数小修改和 bug 修复。
十四、不同场景的限制写法
改文案：
只修改显示文案，不要修改样式和逻辑。改样式：
只修改样式，不要修改数据、接口和事件处理。修报错：
只修复当前报错，不要顺手优化代码。加字段：
只新增这个字段的展示，不要修改后端接口字段名。改接口：
只调整这个接口调用，不要修改其他接口封装。加功能：
只实现第一版最小功能，不要添加我没有要求的扩展功能。这些句子可以直接放进提示词里。
十五、小白应该拒绝哪些 AI 建议
如果 AI 给出下面几类建议，要谨慎：
“我将顺便重构整个组件。”
“建议升级项目所有依赖。”
“建议换一个框架实现。”
“建议重新设计目录结构。”
“建议引入一个大型组件库。”
“我已经把相关文件都优化了一遍。”
这些建议不一定错，但不适合混在一个小任务里。
你可以回复：
这次先不做这些优化。请只完成当前目标，并把其他建议列为后续待办。
把优化建议放到后续，而不是让它们污染当前任务。
十六、完成后的验收清单
每次 AI 改完代码后，用这 6 条检查：
1. 是否只改了预期文件？2. 是否没有新增依赖？3. 是否没有重构无关代码？4. 原本要修的问题是否解决？5. 相关正常流程是否仍然可用？6. AI 是否给出了测试步骤？
如果其中任何一条不满足，就不要急着继续做下一个功能。先把当前改动弄清楚。
这篇文章你需要记住什么
让 AI 不乱改代码，关键是控制范围。
你要做到：一次只改一个目标，明确允许修改范围，明确禁止修改范围，要求 AI 先给计划，优先选择最小修改方案，不允许无理由新增依赖或重构。
小白阶段不要追求“AI 一次性优化全部”。真实项目里，稳定可验证的小改动，比大而全的自动改造更可靠。
