大家用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直观多了。你有没有试过让它先输出改动计划，而不是直接改代码？我现在遇到大改动就这么干，至少它能先“汇报”再动手，心理上觉得可控一点。

我一般直接把相关代码片段喂给它，然后明说“只动这个函数”，不然后果自负。😄

代码审查还是得留个心眼，我都是跑完测试再合并，不敢全信它。

我一般会让AI先输出diff，自己扫一眼再决定合不合并，比直接让它改省心很多。另外试试在系统提示里写死“禁止修改函数签名和数据库字段名”，比每次prompt强调管用。还有个小技巧，把要改的代码块单独复制出来问AI，改完再贴回去，能挡住大半乱动。不过说实话，严格review还是躲不掉的，尤其涉及分页这种边界逻辑。

这题我熟，之前用Copilot也踩过类似的坑。后来我干脆把要改的函数单独抽出来，让AI只针对这一小段代码操作，改完再合回去，基本能避免它顺手牵羊。另外，你提到.gitignore其实锁不住已跟踪的文件，不如试试在AGENTS.md里写死“禁止修改非本次需求相关函数”，效果比prompt里临时强调好很多。不过说真的，遇到这种牵连改动，最后还得靠diff review，我现在每次生成完第一件事就是git diff，扫一眼改动范围，比啥指令都管用。

这问题太真实了，我最近也被Cursor坑过一回，它给我重构一个工具函数时，顺手把返回值的类型都改了，要不是类型检查报错根本发现不了。后来我摸索出个稍微管用的办法，就是在每个prompt里明确写“只允许修改xxx.py文件中的xxx函数，其他任何代码都不许动”，然后配合着给它看上下文，但说实话它还是会偶尔“手痒”。我觉得.gitignore锁文件那个思路不太靠谱，因为AI是基于整个项目上下文理解的，你锁了文件它反而可能因为看不到关联代码而产生更多误判。我现在比较依赖的是把关键函数用类型注解和pydantic模型锁死，这样它改错至少会报错，比静默改逻辑强。另外就是养成习惯，每次让它改完东西，立刻用git diff扫一遍，重点看那些它没提但被改动的行，这比事后code review省心多了。说到底，AI写代码就像个手脚麻利但粗心的实习生，你既不能完全放手，也没法靠单一指令约束，最实际的还是让它每步改动都留痕，你自己当那个最后把关的人。

试试在Cursor的Rules里写死“禁止改动非本次任务相关函数”，再配合git diff审查，能省不少事。

这问题太真实了，Cursor这类工具在“理解意图”和“局部修改”之间其实挺矛盾的。我现在的做法是给AI划一条硬边界，比如在项目里建一个AGENTS.md文件，开头就写明哪些目录是只读的、哪些函数是核心逻辑不许动，然后每次提问都带上具体行号或函数签名，让它精确到“在get_user_list这个函数里加参数”，而不是“帮我在user模块加个接口”。但说实话，就算这样也防不住它偶尔抽风，我试过用git diff来审查每一次改动，稍微复杂点的重构基本都得自己重写一遍。另一个比较笨但有效的方法是，把关联的service层代码直接复制到prompt里，告诉它“这是现状，不要改，只基于这个写新函数”，比让它自己找上下文靠谱得多。至于.gitignore锁文件，那只能防止它动文件，并不能防止它改逻辑，所以我还是觉得，严格code review是底线，特别是数据库查询和分页这种容易踩坑的地方，每次跑一遍测试比啥都强。

这问题我太有同感了，Cursor这种工具你越顺着它写，它越爱顺手“重构”全局。我后来试了个土办法，效果还行——就是每次让它改代码前，先把相关的函数签名和核心逻辑复制到prompt里，然后明确写“基于我给你的这段代码，只新增xxx，不要改动我未贴出的部分”。但说实话，它还是会偶尔犯浑，特别是跨文件调用的时候。

你提到的.gitignore锁定文件其实没用，那是版本控制的范畴，AI根本不看那个。更靠谱一点的，是把Cursor的代码库索引范围缩小，或者干脆用Rules文件指定哪些目录是只读的，比如在项目根目录加个.cursorrules，写明“service层和models层只允许新增函数，禁止修改现有函数内部逻辑”。

不过就算这样，我也踩过坑，它有时候会为了“优化”把原本的查询条件给改掉，而且改得特别隐蔽。所以我现在基本默认：AI写完的diff必须逐行看，尤其是涉及数据库或分页的地方，我甚至会在测试里专门写个断言把offset和limit的顺序固定死。严格code review不是兜底，是必须的，但你可以让review更高效，比如只盯着它动过的那些行，而不是全量看。另外，你可以试试让它先写个变更计划再动手，虽然麻烦，但能减少不少突然“灵光一现”的改动。

我一般会让AI只生成diff片段而不是直接改文件，然后手动合进去，这样它想乱动都没机会。另外把测试跑起来再提交，像你说的分页问题一跑就露馅了。gitignore锁文件其实没用，它读的是整个项目上下文。

这个问题太真实了，我拿Copilot和Cursor都踩过类似的坑，尤其是改参数名这种“隐形破坏”，有时候代码逻辑没变，但语义变了，测试还发现不了。后来我学乖了，明确在系统提示里写“只能修改diff高亮区域内的代码，其他函数一律只读”，但说实话，AI对“关联文件”的理解还是太宽泛，它觉得有必要统一风格就会动手。gitignore锁文件没用，那是防提交的，防不了编辑器写入，我试过把service层设为只读，结果AI直接报错然后摆烂。更靠谱的是给每个任务建独立分支，让AI只在这个分支上干活，提交前用git diff重点看非目标文件的改动，发现一次就回滚一次，多来几轮它就会“长记性”一点。另外我习惯把关键函数的核心逻辑用注释写死，比如标注“此段勿动，依赖外部契约”，prompt里再强调一次，确实能降低乱改概率。但说真的，完全靠指令约束不现实，我现在固定流程是AI改完，我必跑一遍全量测试加diff审查，就当多一道工序，反而比人工写代码省下的时间还多。你试过给每个文件头部加“变更权限”注释吗？比如“仅允许新增函数，禁止修改现有行”，这个方法对我这边挺有效，但不确定是不是模型版本差异导致的。

这个问题太真实了，Cursor有时候确实“太聪明”，我一般直接在prompt末尾加一句“禁止修改任何未明确指出的函数签名和SQL语句”，然后用git diff仔细看一遍再提交。.gitignore锁文件没啥用，它读的是上下文不是文件系统，更靠谱的是把要改的函数单独抽出来让它改，改完再手动合回去，虽然麻烦但至少不会翻车。

我一般让它先复述改动计划再动手，确认没跑偏才放行，能少踩很多坑。