用Cursor写个CRUD接口，AI改完的代码总带bug，大家怎么调教的？

确实是这样，Cursor有时候会自作聪明地重构逻辑，我一般会在prompt里明确写“只修改我选中的代码段，其他部分保持不变”，配合精确的代码片段能好一点。另外建议把数据库表结构和字段映射关系提前写进注释里，让它别猜字段名。至于事务注解，我习惯直接关掉AI生成事务的权限，自己手动加，省得它乱搞。

深有同感，Cursor补CRUD确实容易把字段名搞错，我现在习惯先在注释里把数据库字段和Java属性对应关系写清楚，能减少不少低级错误。至于改bug，我试过用“只修改第X行到第Y行，其他逻辑保持不变”这种限定范围的prompt，效果时好时坏，有时候它还是会自作主张。感觉还是得手动review，不过可以先用git diff对比改动，比逐行看省力些。

这情况太真实了，Cusor补全代码就是赌运气，尤其Spring Boot这种注解一堆的框架，它经常自作聪明给你加事务或者改方法签名。我现在的做法是先在注释里把数据库字段名、方法入参出参、甚至异常处理策略全写死，比如明确写“不要改动service层已有方法”，prompt越像需求文档它越老实。但就算这样，它改bug时还是容易发散，我后来发现一个土办法——把要改的函数整个复制出来，在prompt里单独贴给它，告诉它“只基于这段代码修复，禁止引用其他类”，能稍微控制点范围。另外它吞异常这个毛病是真恶心，我现在都会在检查清单里专门加一条“确认try-catch里有没有打印日志”，不然线上出问题连排查线索都没有。说实话，review AI的代码比手写累多了，但为了那点效率提升，只能在工程化约束上多下功夫，比如强制它生成DTO而不是直接操作实体类，至少字段映射错了能一眼看出来。你试试在项目里加个统一的异常处理器，告诉它所有异常都抛出去，让全局拦截，它就没法自己吞了。

建议把需求拆成小步走，别让它一口气补全整个方法。我一般先给明确的输入输出样例，再限定“只改XXX行，不动其他逻辑”，它听话很多。另外事务注解和字段映射这种，直接在prompt里写死数据库schema，能少踩一半坑。至于它吞异常，我都是加一句“保留原有异常处理逻辑，只修空指针判断”，效果还行。你试试把改动范围圈得更小，比如只贴出报错那几行代码，别给它整个方法上下文。

试试把需求拆成小函数让AI单独补，圈中代码用// TODO标记，我这么干后成功率明显高了。

这问题太真实了，我刚开始用Cue的时候也这样，后来发现关键不是把prompt写死，而是得把“最小改动”这个要求直接怼进指令里，比如明确写“只修改指定方法体，保持其他代码结构不变”，它有时候还是会犯轴，但概率能低不少。另外你那个被吞异常的情况我遇到过太多次了，现在我的习惯是让它改完必须用注释标出动了哪些地方，然后我review的时候专门盯那几行，其他部分直接忽略，不然真的会被带偏。还有一个土办法，就是给它喂一个特别具体的失败用例，比如“当id为null时返回空对象而不是抛异常”，比单纯说“修复空指针”管用一百倍，它就不会自己脑补重构了。至于圈中代码改，目前没有特别完美的方案，我一般是把要改的函数单独复制到一个临时文件里，改完再贴回去，虽然麻烦但至少能控制范围。说实话，用AI写CRUD就是这样，它像个特别主动的实习生，你得不停往回拽，等磨合出适合你项目的模板和约束习惯，后面会顺手很多。

试试在prompt里明确标注“只改指定行，其他逻辑别动”，然后让它先解释改动再动手，能省不少事。

用@workspace精确圈选代码再改，prompt里加一句“只动选中区域别碰其他”会好很多。

这问题太真实了，我前阵子也被折磨得够呛。我的经验是prompt里不写太细的约束，反而写清楚“只改哪几行，别动其他逻辑”，然后明确告诉它“不要吞异常，不要重写方法体”，比让它自由发挥靠谱得多。但就算这样，它偶尔还是会自作主张给你加个日志或者改个变量名，所以我后来干脆把生成代码当草稿，核心逻辑还是自己手写，AI只用来补样板代码和写测试。至于圈中代码这个功能，确实有，你选中代码块后按Ctrl+Shift+P调出命令面板，搜“编辑代码”或者用快捷键，能限定范围，但前提是你的描述得精确到变量级别，比如“把第3行的userId改成user.getId()”，别用“修复空指针”这种模糊指令。另外事务注解乱加这点，我在实体类上加了@Transactional(rollbackFor = Exception.class)后，它反而不乱搞了，你可以试试。说实话，现在AI写代码还是得当实习生用，活儿干完必须code review，但比从零写还是快多了，就是心态得放平。

这问题太真实了，我刚开始用Cursor的时候也差点被它整崩溃。后来发现关键不是prompt写多细，而是得把“范围”和“副作用”焊死在需求里，比如直接说“只改service层的findUserById方法，不要动其他方法，不要加事务注解，异常抛给上层”。你圈代码那个需求，目前最靠谱的办法是用git diff先看它改了什么，然后手动revert掉多余的部分，别指望它自觉。另外它吞异常这个毛病，我一般会在prompt末尾加一句“保持原有异常处理逻辑不变”，但有时候还是会被它自作聪明地“优化”掉，所以代码review真的省不了。我现在是让它生成函数体，但接口签名、字段映射这种核心逻辑全自己写，AI只当个高级补全工具用。你试试让它先写单元测试再补实现，这样它改坏逻辑时测试会先炸，能拦住一部分低级错误。

试试把需求拆成小函数单个喂给它，圈中代码让它改，别让它一次动整块逻辑，能少踩很多坑。

试试在prompt里直接写明“只改指定行，别动其他代码”，配合git diff盯住改动，能省不少事。

我一般用两步：先让它给方案再动手，圈选代码后单独开对话，别混着聊。

我一般先把数据库字段和实体类的映射关系直接贴进prompt里，再让它补全，不然它瞎猜肯定对不上。你那个“修复空指针”的问题我也遇到过，AI特别容易过度理解，所以我都是让它“只修第x行到第y行的逻辑，别动方法签名和返回结构”。另外事务注解我会自己加，AI加的要么漏要么多，不放心。还有个小技巧，如果它改崩了，直接Ctrl+Z回退再重试一次，有时候比反复调教更省心。

我一般会在prompt里把改动的范围圈死，比如直接说“只改第xx行到xx行，其他逻辑别动”，这样AI大部分时候不会越界。另外你那个吞异常的问题，我习惯让它把异常往上抛或者打日志，别用catch吞掉，不然排查起来真要命。还有就是字段名对不上，我干脆把实体类和表的映射关系直接贴在prompt里，省得它瞎猜。说实话，AI写代码就是得当实习生管，边界划清楚才能少擦屁股。

我跟你情况差不多，后来发现关键是把需求拆成特别小的任务，比如“只改findById方法里userName为null时的处理”，别让它自己发挥。另外我习惯在prompt里加上“禁止动其他方法，禁止改方法签名”，然后明确说“只改我标注的TODO区间”，这样能少踩很多雷。不过说实话，AI改完的代码我还是得跑一遍测试，尤其事务和异常处理这俩地方，基本每次都得出问题。

试试把伪代码注释写详细点，字段类型和边界条件都标清楚，AI瞎写的概率能降不少。

我都是让它先列改动计划再动手，不然它真敢把整个service层重构了。

我跟你情况差不多，后来发现别让它一口气补整个方法，把任务拆小点，每次就让它改你圈出来的那几行，prompt里直接写“只修改指定行，不要动其他代码”会好很多。还有事务注解这问题，我干脆在数据库字段和实体类上都加了注释，AI基本就不乱猜了。不过说实话，它改完的代码我还是要过一遍，就当是找了个手快的实习生吧。

我跟你一模一样，让AI改bug经常顺手把旁边逻辑也重构了。后来我学会了把要改的函数整段复制到新对话里，明确说“只改我标记的这几行，其他代码一个字都别动”，效果好了不少。另外事务注解这事，我干脆在项目里用全局默认配置，然后prompt里直接写死“不加任何@Transactional”。还有个土办法，每次让它改完，先git diff看下改动范围，不对就revert重来，比review省心多了。

说真的，你这个情况我太懂了，Cursor补代码就是“看着省事，实则擦屁股”。我现在基本放弃让它一次性写对，反而逼自己把伪代码注释写得像需求文档一样细，连字段类型、表名、异常处理方式都写进注释里，它跑偏的概率能低三成。至于“只改圈中几行”，我试过在prompt里明确加“仅修改指定行号，禁止重构其他函数”，但效果随缘，它有时候还是会自顾自优化。后来我干脆用git diff做硬隔离——每次让它改完，我直接看diff，不符合预期就revert，再在对话里把它的错误代码粘回去，告诉它“这是错误版本，只准修这个，别动别的”，反复几次它才稍微听话点。还有个土办法，就是给AI配一个“对照测试”的prompt，让它改完必须跑一遍我给的测试用例，报错才允许继续改，不然它永远觉得自己是对的。反正现在的感受是，调教AI比写代码更考验耐心，你得把它当成一个记忆力差还爱自由发挥的实习生，规则得反复强调，甚至得用上CI检查来兜底，不然review真能累到怀疑人生。

跟你情况差不多，后来我发现把数据库表结构直接贴进prompt里，再让它严格按字段名来写，比光给注释靠谱得多。另外别让它“修复”什么，就圈中代码说“只改这几行，其他别动”，它有时候能听话，但得反复强调。你试试在系统提示里加一句“禁止重写未选中逻辑”，会好一点，虽然偶尔还是抽风。我现在基本是让它生成小段代码，大改还是自己来，AI当个高级补全用反而省心。