大家用AI写代码时，怎么让它别“自作主张”改掉原有逻辑？

这问题太真实了，Cursor有时候就跟过于热情的员工似的，你让它加个接口它顺手把整个service层都重构了。我现在的土办法是让它改之前先自己列个改动清单，明确告诉它哪些文件绝对不许碰，虽然麻烦点但比事后debug强。另外分页这种容易出错的逻辑，我会直接在代码里写死注释提醒它别动，实测比在prompt里强调管用。说到底还是得靠review兜底，但至少能少踩几个坑。

这个问题无解，本质上是AI对上下文理解太宽泛，不如直接把关联函数锁进单独文件里再开新会话写。

我试过最有效的就是改完立刻git diff看差异，发现乱动直接revert，比写prompt管用多了。

这问题太真实了，Cursor有时候就是“热心过头”。我的土办法是每次让它改代码前，先手动把要动的函数或者文件用注释标个TODO，然后在prompt里直接说“只处理TODO标记的部分，其他逻辑当黑盒别碰”。另外.gitignore锁文件没用，那是管版本控制的，管不住AI的上下文窗口。最后还是得靠diff review，我习惯每轮改完先跑一遍git diff，看到无关改动直接checkout还原，比事后修bug省心多了。

这问题太真实了，我最近也被Cursor坑过一回，它给我改个DTO字段，居然把另一个模块的ORM查询条件一起带了节奏，查出来的数据直接少了一半。后来我学乖了，在prompt里加一句“只允许修改我选中的代码块，其他一律视为只读”，但这玩意儿跟玄学似的，有时候管用有时候翻车。我现在的土办法是，让AI改完代码后，我立刻用git diff看一眼，凡是它动过的非目标文件，直接checkout还原，比在prompt里反复强调省心多了。另外我发现一个细节，如果你在工程根目录放一个CLAUDE.md或者.cursorrules，把项目的核心约定写进去，比如“分页参数统一为page和size，禁用offset/limit”，AI犯错的概率会小很多，因为它会把这些当全局约束。但说实话，真要完全杜绝它自作主张，目前我觉得不现实，毕竟它得理解上下文才能改得动代码，理解过头了就会“顺手帮忙”。所以我的底线是，核心业务逻辑的service层改动必须人工审，接口和DTO这种边角料可以放它自由发挥，但测试用例一定要跑一遍，别只靠review，跑挂了比review直观多了。你有没有试过让它先输出改动计划，而不是直接改代码？我现在遇到大改动就这么干，至少它能先“汇报”再动手，心理上觉得可控一点。