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

试试把需求拆成小步，一次只让它改一个函数，顺便在prompt里加一句“禁止改动未标注代码”，能省不少事。

我都是先让它写单测，再拿单测去卡它的修改，逻辑跑不通它自己就老实了，比手写review省心。

我最近也在折腾这个，你试试把注释写得再细点，比如直接在注释里标清楚“别动Service层，只改Mapper的查询条件”，AI一般会老实很多。另外那种让AI修bug的prompt真不能太笼统，我一般会把报错堆栈和它之前改的那几行代码一起贴进去，然后明确加一句“只修复NPE，禁止改方法签名和返回值”，不然它真敢给你重写整个类。圈中代码让它只改选区这个我也没找到好办法，现在都是改完用diff工具逐个hunk看，实在不放心就自己上手改那几行，感觉AI更适合当个生成初稿的帮手，别指望它精准手术。

说实话你这情况太典型了，我刚开始用Cursor那会儿也差点被它气到摔键盘。后来我摸出来的路子是，别让它一次性生成整个方法，而是把伪代码拆成几个小块，每块明确标注输入输出和边界条件，尤其是字段映射和事务边界这种容易出幺蛾子的地方，直接写在注释里让它照着抄。至于改bug，我试过在prompt里加一句“只修改指定行号范围，禁止重构其他逻辑”，但效果时好时坏，有时候它还是会自作聪明，所以我干脆用git diff盯死它，但凡改动超纲就revert重来。还有个笨办法，就是把报错信息原样贴给它，附带你的猜测，比如“可能是这行没判空”，比笼统说“修复空指针”管用得多。不过说实话，指望它完全听话不太现实，我现在就把AI当个高级补全工具，核心逻辑还是自己写，它负责填模板和查漏。对了，你有没有试过在关键方法上手动加@Transactional后再让它补？我这么干之后，它乱加注解的毛病倒是好了不少。

我一般会在prompt里把边界条件直接焊死，比如“只改service层第X行到第Y行，不要动别的文件”，但说实话Cursor有时候还是会自作主张。后来我改用先让它列出修改计划，我确认了再让它动手，这样能少踩不少坑。另外“修复空指针”这种描述太模糊了，我都是直接把报错日志贴给它，再补一句“只加判空，别重写逻辑”，效果会好很多。你试试看能不能用git diff来回滚它乱改的部分，至少能省点心力。

我一般会把数据库表结构和关键字段直接贴进prompt里，再限定“只改我圈出的代码块，其他逻辑禁止动”，不然它确实容易放飞自我。另外修复bug时别让它“修复”，而是具体说“第X行返回null，请加个判断”，指令越窄它越老实，不然真的会把整个service层给你重写了。

说实话你这情况太典型了，Cursor补代码跟抽卡似的，运气好能一把过，运气差直接给你来个“惊喜重构”。我现在的做法是prompt里明确写“只修改指定行，保持其他逻辑和命名不变”，然后配合git diff盯着看，一旦发现它动了大手术直接ctrl+z回滚再换一种问法。另外事务注解和字段映射这种，我干脆自己写个模板让它往里填，AI自由发挥空间越小，翻车概率越低。你试试让它先输出修改计划再动代码，比直接让它改靠谱得多。

说实话你这个情况太典型了，我刚开始用Cursor那会儿也这样，后来发现核心问题不是它笨，是你给的上下文太模糊。我现在的做法是，prompt里直接贴出数据库表结构、实体类字段、还有它上次改完的diff，然后明确写“只修改第X行到第Y行，不许动其他方法”，它基本能老实很多。另外“修复空指针”这种需求太开放了，你得告诉它“在userService.findById里，当id为null时返回Optional.empty()，不要改调用方”，给它划出边界，它才不会自由发挥。至于事务注解乱加，我直接在项目里配了自定义的代码规范文档，让Cursor读一遍再干活，效果立竿见影。还有个土办法，就是每次改完先让它自己跑一遍测试，把报错信息贴回去让它修，比人肉review省心多了。不过说真的，AI写CRUD这种活儿，你还是得自己把骨架搭好，让它填肉，别让它从零设计，不然它总爱自作聪明搞些花活。

试试把伪代码注释写成带明确边界和异常处理策略的，然后让它只输出diff，别让它自由发挥，能省一半心。

试试把需求拆成最小粒度，一次只让它改一个方法，圈中代码加注释说明边界，能少踩一半坑。

我都是先手动把异常和事务写好，AI只补业务逻辑，不然它自由发挥起来真能把人整崩溃。

我跟你一模一样，后来放弃了让它改bug，直接定位到具体方法然后复制出来贴给AI，告诉它“只改这一段，别动别的”。另外prompt里加一句“保持现有代码结构和风格”能少很多幺蛾子，但字段名对不上这事还得靠你手动把实体类和表结构的关键信息贴给它。还有那个吞异常的问题，我现在都习惯在prompt末尾补一句“不要删除任何catch块或日志输出”，不然它真能给你删得干干净净。

说实话你这个问题太典型了，我刚开始用AI写代码那会儿也这样，尤其是事务注解和字段映射，它经常凭“直觉”给你补一堆没用的东西。后来我学乖了，伪代码注释里直接把数据库表结构、字段类型、甚至方法签名都贴进去，prompt里明确写“只补全XXX方法，参数和返回值不许动”，这样它发挥空间小，出错的概率就低很多。关于只改圈中那几行，我试过在注释里用类似“CHANGE START”和“CHANGE END”标记，然后prompt里强调只改这个区间，但说实话还是得靠人工review，AI模型很难理解“局部修改”的边界，它总觉得自己重写得更优雅。另外你说的吞异常这个问题，我现在的做法是直接在prompt里加一句“如果遇到空指针，返回null并打印日志，不要改动其他代码逻辑”，虽然不能100%避免，但至少能减少它自作主张的行为。还有个偏方，就是每次让它改完，先别急着接受，用git diff看一眼改动范围，如果超出预期就直接revert，多试几次它也会慢慢“记住”你的风格。说到底，这玩意儿就是个高级补全工具，别指望它真能理解业务，把prompt当代码规范写，约束越死它越听话。

我一般是把伪代码注释写得特别细，直接标清楚字段类型和数据库列名，AI补出来基本能用，但事务注解这种还是得自己review一遍。你让它修bug的时候，最好在prompt里加一句“只改指定行，别动其他逻辑”，不然它真会自由发挥。还有个办法，把报错日志贴进去，让它先解释原因再给方案，比直接让它改靠谱。话说你用的哪个模型？我感觉GPT-4o比Claude在这种小改动上听话一点。

我跟你一模一样，后来发现光靠注释不行，得把字段映射和事务边界直接写进prompt里，比如明确说“只改service层，别碰controller和mapper”。圈中改代码这个需求我也试过，基本靠把相关代码复制到新对话里让它改，再手动贴回来，虽然蠢但至少不会波及别的地方。还有个笨办法，就是让它先描述修改方案，你确认了再动手，能少踩不少坑。另外异常吞掉这个太真实了，我现在都会加一句“保持原有异常处理逻辑不变”，不然它总爱自作主张。

试试把改动范围直接写进prompt，比如“只改第X行到第Y行，别动其他”，再配合git diff手动回退乱改的部分。

用上精准的注释约束AI，比如“只修空指针判断，不改返回逻辑”，比让它自由发挥靠谱多了。

说实话你这情况太典型了，Cursor这玩意儿写CRUD确实容易翻车，尤其Spring Boot这种注解满天飞的框架。我现在的做法是，伪代码注释里直接把数据库字段名、表结构、甚至JPA的命名策略都写进去，AI基本不敢乱猜。但你要说让它只改圈中几行，目前真没特别好用的招，我试过在prompt里加“只修改标记区域，其他代码保持原样”，它偶尔还是会手贱重构，所以我现在干脆把要改的逻辑单独抽成一个方法，让它只动那个方法体，至少review范围可控。至于吞异常那个事，我一般会在注释里明确写“保留原有异常抛出逻辑，禁止catch后静默”，不然它总爱自作主张。另外，改完代码别急着跑，先diff一下，重点看它改了哪些非目标行，有可疑的直接git checkout还原，别信它的“顺手优化”。反正用久了就习惯了，把它当个特别容易跑偏的实习生，大方向你把控，细节它干，效率还是能上去的。

说实话我也有过这阶段，现在基本是让它按我的接口文档和表结构来写，prompt里直接贴字段定义和约束，比让它自己猜靠谱太多。圈中改代码那个，你用Cmd+L把选中区域加进上下文，再明确说“只改这部分”，会好一些，但别指望它100%听话。事务注解这种，我一般最后自己扫一遍，AI加的要么漏要么多，还是得靠人肉把关。

试试把改动范围直接框进TODO注释里，再让它只补那一段，效果会好点。

我都是先自己写好接口骨架，AI只填方法体，顺手把异常处理规则写死在prompt里。

试试把伪代码注释写细点，字段名和约束都标清楚，AI基本就不跑偏了。

圈中改代码得靠编辑器选区功能，不然它真敢给你重写整个方法。

我一般会把关键约束直接写进注释里，比如字段名、是否允许null、事务边界，AI猜错的概率能低不少。至于只改圈中几行，目前确实做不到，但你可以试试在prompt里强调“只修复异常，不要重构”，或者干脆把那段代码复制到新对话里让它改，改完再贴回来。另外，AI吞异常这个问题太真实了，我后来都习惯让它先打印日志再动手，至少能知道它干了啥。

我跟你情况差不多，后来发现关键是把需求拆成特别小的步骤，别让AI一口气干太多活。比如让它只补方法体，别碰签名和注解，或者干脆在注释里把异常处理写成明确要求，像“catch到异常就返回null，不许打日志”。至于只改圈中几行，目前没找到完美办法，我都是明确告诉它“只改第XX行到XX行，其他部分原样返回”，但偶尔还是会翻车。最有效的还是让它先解释改了啥，再决定要不要接受，不然review确实比自己写还痛苦。