沉默是金，总会发光
大家好，我是沉默
很多人用 Cursor 写新功能的时候很爽，但一旦让它改 Bug，经常出现 东拉西扯、越改越乱、改不对重点 的情况。
其实，问题不是 AI 不行，而是你没用对方法。
**-**01-
1-3
一、上下文喂养：AI 改 Bug 的“粮食”
- 直接丢错误日志，比只说“报错了”有效 100 倍。
- 关键日志 + 出错堆栈 + 相关方法，Cursor 才能精准定位。
- 示例：
日志报错：java.lang.NullPointerException at UserService.save(UserService.java:42)相关代码如下：
给 AI 足够信息，它才能不瞎猜。
二、分步提问，不要一口气
-
错误做法：
“帮我修复这个类，功能写全。” -
正确做法：
-
- 先问 出错原因分析
- 再问 修复方案
- 最后让它 改代码
-
原理：AI 善于推理，不擅长一锅端。
三、Diff 模式，精准定位
- 如果直接复制整个文件，AI 容易乱动。
- 建议只给出问题的方法片段，并用：
// before...// after (need fixed)
这样能让 Cursor 聚焦差异，避免“顺手重构”一堆没必要的代码。
- 02-
4-6
四、引导性提示
AI 不知道你想要怎么改，就会发挥想象力。
比如 NullPointer 问题：
- 错误提示：
“修复这个报错。” - 正确提示：
“保持逻辑不变，只需增加空指针安全判断。”
给“边界”而不是“无限发挥”。
五、逐行确认修改
-
有些 Bug 牵一发而动全身。
-
让 AI 给出修改建议时，最好加一句：
“请用注释说明为什么这样修改。” -
这样可以看出它的逻辑，而不是盲改。
六、让 AI 帮你写测试
-
修 Bug 不难，难的是保证 不复发。
-
技巧：在修复后立刻让 Cursor 生成单测。
-
好处：既能验证 Bug 已修复，也能当回归用例。
- 03-
7-9
七、限制修改范围
-
有时 AI 会“手贱”，把文件风格、注释全改了。
-
加一句：
“除了修复这个 Bug，不要修改任何其他逻辑和命名。” -
效果立竿见影。
八、带上业务语境
-
Bug 不只是代码问题，还和业务逻辑相关。
-
多说一句：
“这是一个电商订单模块，方法负责库存扣减。” -
AI 会根据业务常识，避免“自以为合理”的错误修复。
九、多轮调优，别一次性依赖
- AI 第一次给的方案，不要盲信。
- 多问几轮：
-
- 这段代码是否存在隐藏风险？
- 有没有更优雅的写法？
- 是否符合线程安全？
让它自己审查自己。
**-****04-**10-12
十、让 AI 做 Code Review
-
修 Bug 后再问它：
“请从代码规范、性能和可维护性角度帮我审查修改。” -
这样你不仅修了 Bug，还顺带做了一次“自动 Code Review”。
十一、避免一次贴太大文件
-
超过 1000 行的类，AI 容易丢上下文。
-
最佳实践：拆分模块、逐段修改。
-
修完一块，再合并回去。
十二、闭环思维
-
不要让 AI 修完就算了。
-
标准流程：
-
- 分析 Bug
- 给出修复代码
- 生成单测
- Code Review
- 产出文档说明（记录原因 + 修复方式）
-
这样 Bug 修复才算真正闭环。
总结
AI 改 Bug 不是“扔代码 → 等答案”，而是需要你：
提供上下文 → 限定范围 → 分步提问 → 要求验证
只要用好这 12 个技巧，Cursor 就能从“神棍”变成“靠谱助手”。
**-****05-**粉丝福利
我这里创建一个程序员成长&副业交流群，
和一群志同道合的小伙伴，一起聚焦自身发展，
可以聊：
技术成长与职业规划，分享路线图、面试经验和效率工具，
探讨多种副业变现路径，从写作课程到私活接单，
主题活动、打卡挑战和项目组队，让志同道合的伙伴互帮互助、共同进步。
如果你对这个特别的群，感兴趣的，
可以加一下， 微信通过后会拉你入群，
但是任何人在群里打任何广告，都会被我T掉。
