用 AI 修复 Bug 时如何不引入新问题：四个实用习惯
用 AI 编程助手修一个小 Bug 只需要几秒，但很多开发者心里都有一丝顾虑：这个修复会不会把别的地方改坏？这种担心是合理的。AI 工具很强，但它看到的往往不是全貌，一个粗心的提示词就可能让修复变成"解决一个问题、引入三个新问题"。
本文整理了一套任何人都能遵循的实用习惯，适用于个人项目、小应用维护，以及只想让代码继续平稳运行的中小型场景。
AI 生成修复的隐藏风险
AI 编程助手的工作原理是读取你提供的代码，再基于它学到的模式做出修改。当你只给它单个文件或函数时，它很可能遗漏重要上下文：共享的辅助函数、应用各部分之间流动的数据、只在特定条件下出现的边界情况。
一个常见场景：你让 AI 修复表单的校验 Bug。它重写了校验逻辑，报错消失了，但另一个页面上依赖同一个校验函数的表单跟着坏了——因为 AI 不知道这个函数被多处共用，而你又没有提。
风险不在于 AI 故意给出坏建议，而在于它基于不完整信息工作，而我们在赶时间时忘了给它需要的上下文。
习惯一：给出清晰、狭窄的 Bug 描述
打开对话框之前，先在脑子里把 Bug 描述清楚：到底哪里不对？期望行为是什么？问题出现在哪？
清晰的描述能让 AI 保持专注。不要说"表单坏了"，试试"邮箱字段接受了缺少 @ 的无效地址"；不要说"应用偶尔崩溃"，试试"在空表单上点击保存时应用崩溃"。具体描述能帮助 AI 理解你想修什么，同时避免它重写无关代码。描述含糊时，AI 会猜测问题所在，改动范围很容易超出必要。
习惯二：提供完整上下文，而不是孤立文件
AI 只能基于它看到的东西工作。如果 Bug 涉及两个文件——比如一个可复用组件和它调用的辅助函数——确保 AI 能看到两者。
如果用的工具可以直接读取项目文件，就明确告诉它哪些文件相关；如果是在聊天里粘贴代码，就把出问题的函数和它依赖的相关函数一起贴进去。例如按钮处理器调用了校验函数，就同时给出处理器和校验逻辑；如果 Bug 在某个值传入时才出现，就把传值的父级部分也带上。
不必把整个代码库都倒进去，只需要包含与故障点直接相邻的部分。
习惯三：先要解释，再让 AI 动手
避免意外副作用最简单的方式之一，是让 AI 在修改前先描述计划。可以试试这些提示词：
- "你会怎么改来修复这个问题？为什么？"
- "你能解释一下这个 Bug 的原因和你的修复思路吗？"
- "在动手前，先告诉我你认为哪里不对。"
当 AI 解释推理过程时，你有机会提前发现错误。如果解释里提到了意料之外的函数，或者方案范围太广，可以在任何代码被重写之前澄清。这一步多花一分钟，但你不仅得到了修复，还了解了 AI 眼中的问题，确保它走在正确方向上。
习惯四：坚持小而隔离的改动
改动越小，破坏其他东西的可能性越低。描述 Bug 时强调你要的是最小修复，例如：
- "修复邮箱字段的校验 Bug，不要改动表单其他部分。"
- "更新 calculateTotal 里的舍入逻辑，其他计算保持不动。"
- "让通知只触发一次，不要动通知系统其他部分。"
如果 AI 建议更大的重写——重命名变量、拆分函数、重构文件——先问自己是否真的必要。重写在有充分时间测试时没问题，但当你想快速得到一个可用修复时，坚持做最小的改动。
共享代码与涟漪效应
小 Bug 常常隐藏着更大的风险：一个辅助函数可能在五个地方被使用，一条样式规则可能影响应用里十个部分，一个变量可能被多个模块读取。
应用修复前，扫描一下共享的部分。如果 Bug 出在名为 formatDate 的函数里，就在项目里搜索其他调用 formatDate 的地方；如果是样式问题，检查样式名是否出现在其他样式文件或组件中。你也可以让 AI 帮忙："在项目里搜索这个函数的其他调用点。"
结语
AI 辅助修复 Bug 的关键，不在于找到一个能一次解决的提示词，而在于建立一套约束：清晰的描述、完整的上下文、先解释后修改、最小化改动、检查共享代码。这套流程让 AI 成为可信的帮手，而不是隐患的来源。
来源：Safe AI Bug Fixes That Preserve Working Code - DEV Community