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

试试用@指定文件+行号范围，prompt里写死“只改选中区域”，能省不少事。

试试把需求拆成小步，一次只让它改一个函数，圈选范围再补一句“别动其他代码”，会稳很多。

我一般会把关键约束直接写进注释里，比如字段映射和事务边界，AI瞎改的概率能低点。至于只改圈中几行，目前Cursor还没这么智能，你试试用diff模式手动合并它的改动，别让它直接覆盖。另外它吞异常这个问题，我习惯在prompt里强调“保留原有try-catch结构”，不然它老自作主张。

试试把需求拆成最小单元，一次只让它改一个方法，prompt里明确禁止动其他代码，不然真容易越修越乱。

我跟你一模一样，后来发现关键不是让它“修复”，而是必须把“只改哪几行”写进prompt里，比如明确说“只修改第X行到第Y行，其他逻辑一律不动”，不然它特别爱自由发挥。另外我会先给它贴出数据库表结构和实体类定义，再让它写，字段对不上的问题能少一半。事务注解那个我干脆自己手动加，它判断上下文的能力真不行，越改越乱。

试试把伪代码注释写细到字段级别，再限定“只改标记行”，不然AI自由发挥确实容易翻车。

说实话你这情况我太熟了，cursor补代码就是这德行，你给注释它自由发挥，完了字段名跟数据库对不上算是基操。我后面试了个办法，把完整的表结构和实体类字段直接粘进prompt里，让它照着写，别用伪代码，这样至少能少一半错。至于改bug，千万别让它“修复”，你得把报错堆栈和期望行为都贴上去，然后明确说“只修改第X行到第Y行，其他代码禁止改动”，语气强硬点，它反而老实。还有事务注解那个，我直接在全局规则里写了“除非明确要求，否则不加@Transactional”，不然它动不动就给查询方法也套上。你review累是因为你还没学会怎么给它划边界，我建议你把方法签名、返回类型、异常处理方式都当作硬约束写进prompt里，然后每次改完先让它自己跑一遍测试再交给你，不然纯靠人肉盯真受不了。对了，你试试它那个“agent模式”选一下，有时候比普通对话模式更听话，但记得盯紧点，它一飘就赶紧打断。

实不相瞒，我也踩过这坑，后来学乖了：pom里加个lombok，然后prompt里直接写“只改第x行到第y行，别动其他方法”，再不行就让它先列改动点，我确认了再动手。另外事务注解这玩意AI确实爱乱加，我都是自己手动补@Transactional，不指望它了。你要真想省心，试试把数据库表结构直接贴进上下文，字段对不上的问题能少一半。

这问题太真实了，我刚开始用AI写代码也这样。后来我发现关键不是让它“修复”，而是得把上下文切得特别碎，比如单独把那个空指针的方法拎出来，加上完整的入参和报错堆栈，再明确说“只改第X行到第Y行，其他逻辑别动”，不然它一自由发挥就灾难。另外事务注解这事，我干脆在项目里加了自定义注解规范，prompt里直接贴出来让它照着套，比嘴上说“别乱加”管用多了。还有个小技巧，如果AI重写了方法，我经常用git diff直接revert掉，再重新给它更小的指令，别跟它较劲。对了，你试过在它改完代码后，让它自己写个简单的单元测试跑一遍吗？我发现这能逼它自己发现bug，比咱们review省心不少。

跟你情况差不多，后来我学乖了，prompt里必须把“只改这几行，别动其他逻辑”直接写进去，还得明确禁止吞异常。另外我发现让AI先解释它打算怎么改，比直接让它动手靠谱得多。

我刚开始用的时候也这样，后来发现别让它一口气补整个方法，把数据库字段和返回值类型直接在注释里写清楚，它反而靠谱点。至于只改圈中的行，我试过在prompt里说“只修改报错那行，其他代码原样保留”，但偶尔还是会自作主张，所以现在重要逻辑干脆自己写，AI只用来生成模板和测试数据。你说的review累太真实了，我现在看它改的代码比看自己写的还仔细，生怕它悄悄吞异常。

这问题太真实了，我刚开始用的时候也这样，后来发现关键不是prompt写多细，而是别让它一次性生成整个方法。我现在都是把伪代码拆成小函数，一个方法只干一件事，AI补全的粒度小了，出错概率会低很多。你那个“修bug重写逻辑”的情况我也遇到过，后来我学乖了，先手动定位到具体行，把错误堆栈和当前代码一起贴给它，然后明确说“只改第X行到第Y行，其他部分一个字别动”，它基本能听话。事务注解乱加这个，我干脆在项目里定了规矩，所有事务都写在一个叫TransactionService的类里，业务层不让import事务相关的注解，AI再聪明也绕不过这个限制。至于空指针，我怀疑是它在没上下文的情况下瞎猜字段，建议你把DTO和Entity的字段对照表直接写进prompt里，或者干脆用JPA的@Query原生SQL，反而少出幺蛾子。反正我现在review的时间少多了，但刚开始那两周确实比手写还累，熬过去就好了。

说实话你这体验太真实了，我刚用Cursor那会儿也这样，后来发现它就是个“过度热情”的实习生，你让它修个空指针，它恨不得把整个类都重构了。我的做法是prompt里必须带数据库字段定义和现有方法签名，还得加一句“只改我标注的行，禁止改动其他逻辑”，虽然它偶尔还是会手贱，但至少能少折腾一半。另外你那个事务注解乱加的问题，我一般会在伪代码注释里直接写清楚“这个方法不需要事务”，或者干脆把@Transactional从import里删掉，它能消停不少。至于review累这个事儿，我现在基本把AI当打字机用，自己先画好流程图和边界条件，让它纯翻译，比让它“修bug”靠谱得多。还有个土办法，改完代码先用git diff看一眼，凡是改动超过10行的直接revert，让它重来，几次之后它就学乖了。反正别指望它理解业务，它就是个体力活儿工具，关键逻辑还是得自己拿捏。

这问题太真实了，我一开始也是这么过来的。后来我发现，让AI补全代码前，必须把字段名和数据库列的映射关系直接写在注释里，甚至把JPA的@Column注解模板给它，不然它全凭猜。关于修bug，千万别让它“修复”，要明确说“只修改第X行到第Y行，保持其他逻辑不变”，不然它一激动就把整个方法重构了。还有个土办法，把报错堆栈和当前方法的前后20行代码一起贴进去，它反而会收敛一些。另外事务注解这玩意儿，我干脆自己手动加，AI一碰就乱套，它根本分不清哪些操作该进同一事务。最后想说，review它的代码累是累，但总比自己从零敲强，就当带了个手脚麻利但脑子不太灵光的实习生吧。

试试用@指定方法名+“只改这段，别动别的”，再不行就锁代码段或者分文件拆小点，AI一长就爱自由发挥。

我一般先让它跑测试，报错再贴日志让它改，别直接说“修复”，不然它真给你重写一遍。

我一般把约束直接写进注释里，比如“只改第XX行的空指针判断，别动别的”，但实测它偶尔还是会上头乱改。后来学乖了，让AI改完先diff给我看，不对劲就回滚，比让它反复磨效率高。另外事务注解这种，干脆自己在代码里写死，别让它碰，它一自由发挥就容易加错地方。

我都是把改动的scope写在prompt里，比如“只改service层第30行”，不然真能给你重写整个类。

试试用@符号精准圈代码再配“只改这，别动别的”，能少踩不少坑，但AI偶尔还是头铁。

我都是让它先列改动方案再动手，确认了才执行，查空指针这种直接给具体行号和期望值，比口头描述靠谱。

这问题太真实了，我一开始用也是这感受，AI补代码就像个自信的实习生，你让它改个变量名它恨不得把整个类都重构一遍。后来我摸索出来的办法是，把大任务拆成小任务，一次只让它处理一个方法，并且把数据库表结构和字段类型直接贴在prompt里，不给它自由发挥的空间。至于圈中代码这个需求，我目前也没找到完美的办法，但有个小技巧是，你明确跟它说“只修改第X行到第Y行，其他代码不要动”，同时让它把修改后的完整方法贴出来，这样review起来至少能有个对照。还有个比较土但好用的招，就是git提交前先diff一眼，只把符合预期的改动留下，AI写的奇葩逻辑直接revert，别让它带偏你的代码风格。另外事务注解这个问题，我干脆自己写了个模板，让AI只填业务逻辑，注解一律手动加，省得它到处乱插@Transactional。总之别指望它一步到位，把AI当成一个能快速生成草稿的插件，最终质量还是得自己把关。

最有效的办法是让AI先列改动计划再动手，我都是这么约束它的，能省一半review时间。