Cursor 与 AI 编程助手：改 bug 而不乱改

你将学到什么

1. 最小复现代码的编写方法：用最少的代码还原 bug 场景，让 AI 聚焦问题核心，避免冗余上下文干扰；2. AI 提示词的范围约束技巧：通过精准指令限定 AI 的改动边界，防止其擅自修改无关代码；3. Cursor 内置 diff 工具的使用：对比 AI 改动与原代码的差异，快速识别并拒绝不合理修改；4. 判断 AI 改 bug 边界的方法：明确哪些场景适合交给 AI，哪些必须手动处理。

适合谁

适合具备基础 Git 操作能力、日常需要在项目中修复代码 bug 的开发者。这类人群已经掌握基本编程逻辑，熟悉项目代码结构，但常常遇到 bug 定位慢、AI 改代码容易「越界」的问题，能通过本课程的方法提升 bug 修复效率，减少后续返工成本。

不适合谁

完全零基础、尚未独立写过任何代码的读者不适合学习本课程。因为课程内容建立在对代码逻辑、Git 基础操作的认知上，没有这些前置知识，无法理解最小复现代码的意义，也无法对 AI 的改动进行有效审阅。

操作步骤

1. 1从项目中提取触发 bug 的核心代码片段，去掉与 bug 无关的业务逻辑、注释、依赖调用。比如原代码是一个包含用户认证、日志记录的支付接口，若 bug 是金额计算错误，就只保留金额计算的函数和调用示例。
2. 2给代码添加必要的上下文说明，比如 bug 触发的条件、预期输出和实际输出。示例模板： ```javascript // 最小复现代码：金额计算 bug function calculateTotal(price, discount) { return price * discount; } // 触发条件：当折扣为 0.8 时 // 预期输出：80 // 实际输出：0.8 console.log(calculateTotal(100, 0.8)); ```
3. 3将这段代码复制到 Cursor 的编辑窗口，确保可以独立运行并复现 bug——这一步很重要，因为只有代码能独立复现问题，AI 才能精准定位原因，不会被无关代码误导。

1. 1在 Cursor 的输入框中编写提示词，明确要求 AI 只修改指定代码范围，禁止改动其他部分。可直接复制以下示例模板： "请修复以下代码中的 bug，要求只修改 calculateTotal 函数的逻辑，不改动任何其他代码，修复后需保证输出结果符合预期：[粘贴你的最小复现代码]"
2. 2如果是在完整项目文件中改 bug，要先选中需要修改的代码块，再调用 AI——Cursor 会默认将选中的代码作为上下文，减少 AI 读取无关代码的概率，同时在提示词中补充「只修改我选中的代码区域」的要求。
3. 3添加验证要求，比如「修复后请给出测试用例，证明 bug 已解决」，确保 AI 的改动有效，避免出现修复一个 bug 又引入新问题的情况。

1. 1AI 生成改动后，Cursor 会自动展示原代码与修改后代码的 diff 对比（diff 是指两段代码的差异对比，通过不同颜色标记新增、删除、修改的内容），先查看改动范围是否符合要求，比如是否只修改了你指定的函数或代码块。
2. 2对照以下审阅清单逐一检查： - 改动是否直接对应 bug 的原因？ - 是否新增了无关的变量、函数或注释？ - 修改后的代码是否符合项目的编码规范？ - 测试用例的输出是否与预期一致？
3. 3如果发现 AI 做出了无关改动，直接在 Cursor 中输入「请撤销刚才的无关改动，只针对 [具体 bug 点] 进行修复」，让 AI 重新生成修改方案，直到改动完全符合要求。

1. 1确认 AI 的改动无误后，将修复后的代码复制回项目文件中，运行项目的本地测试用例，验证 bug 是否真正解决——这一步不能省略，因为 AI 的改动可能在独立复现代码中有效，但放到完整项目中可能存在依赖问题。
2. 2使用 Git 提交改动时，先通过 git diff 命令再次对比本地代码与仓库代码的差异，确保没有引入其他无关修改，再提交并推送代码。

常见踩坑

踩坑 1：不给 AI 加范围约束，导致 AI 擅自重构代码。很多开发者直接让 AI「修复这个 bug」，没有限定改动范围，AI 可能会为了「优化」代码，修改原本正常的函数结构或变量命名，反而破坏项目的原有代码规范。这是因为 AI 的训练数据包含大量重构案例，会默认进行优化，但这不符合改 bug 的核心需求——只修复问题，不改动正常代码。

踩坑 2：不做本地验证就提交代码。AI 生成的修复代码可能在最小复现场景中有效，但放到完整项目中，可能因为依赖其他未包含在复现代码中的函数、变量，导致出现新的报错。比如 AI 修复金额计算 bug 时，假设了输入的价格是正数，但项目中可能存在价格为 0 的场景，直接提交会触发新的逻辑错误。

踩坑 3：过度依赖 AI，不会手动排查复杂 bug。对于涉及项目核心业务逻辑、多模块交互的复杂 bug，AI 可能无法通过单一代码片段理解整个流程，给出的修复方案可能治标不治本。比如电商项目中订单状态更新的 bug，涉及数据库事务、消息队列等多个模块，AI 仅靠一段代码无法定位根本原因，必须开发者手动排查日志、梳理流程。

本课小结

通过本课程的学习，你已经掌握了用 AI 编程助手精准改 bug 的核心方法：先用最小复现代码聚焦问题，再通过范围约束提示词限定 AI 的改动边界，最后用 diff 工具严格审阅改动。这些方法的核心逻辑是减少 AI 的无效上下文输入，明确 AI 的任务边界，避免其「画蛇添足」的改动。

同时你也明确了 AI 改 bug 的适用场景：适合单一函数、明确逻辑的简单 bug，不适合涉及多模块交互、核心业务逻辑的复杂 bug。后续在工作中，要先判断 bug 的类型，再决定是否交给 AI 处理，避免过度依赖导致的效率下降。

• 能独立写出包含触发条件、预期与实际输出的最小复现代码
• 能熟练使用 Cursor 的范围约束提示词模板，准确限定 AI 的改动边界
• 能通过 Cursor 和 Git 的 diff 工具识别 AI 的无关改动
• 能判断当前 bug 是否适合交给 AI 处理