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

.gitignore根本拦不住Cursor，它读的是你整个项目上下文，不是文件系统权限。我现在的做法是每次改完直接git diff，只保留自己想要的hunk，其他全revert，虽然麻烦点但比出bug强。另外prompt里可以试试加一句“只允许修改我指定的函数，其他代码一律视为只读”，会稍微收敛一点，但别指望100%听话。说到底还是得靠review，毕竟AI理解不了你业务里那些隐性的依赖关系。

这个我太有感触了，之前用Copilot也遇到过，它特别爱“顺手”优化掉一些看似冗余的代码，结果把业务逻辑搞坏。后来我学乖了，在prompt里明确要求“只输出diff，不要解释”，再加一句“改动范围严格限制在XX函数内”，效果会好一些，但偶尔还是会抽风。说到底AI没法真正理解上下文，轻量改动靠指令约束，核心逻辑还是得靠code review兜底，指望它完全听话不太现实。

说实话，锁定文件治标不治本，因为改到service层往往是一连串依赖引起的，它觉得不改就编译不过。我现在比较有效的是把要改的函数签名和边界条件直接写进prompt里，然后让它先描述计划再动手，至少能提前发现它想乱改的苗头。另外给Cursor加上规则文件（.cursorrules）也能减少一点，但真要完全防住，还是得靠测试用例砸出来。

试过把相关代码段复制进一个临时的txt文件，只让AI基于这个文件改，改完再手动贴回去，这样能隔离掉大部分“自作主张”。不过治标不治本，它还是会基于自己的“理解”去动别的参数。我现在最顺手的办法是改之前先把关键函数用git stash存个快照，然后让它随便造，跑完测试不对直接stash pop，省心

我一般会在让AI动手前，先把要改的函数或文件用注释写死，比如在代码里加一行“以下逻辑勿动”，然后明确告诉它只准新增，不准修改已有行。另外.gitignore锁文件没用，它根本不管那个，还是得靠指令里加负面约束，比如“禁止改动XX函数”。不过说实话，这种问题真要完全避免，最后还得自己过一遍diff，尤其是数据库查询和参数顺序这种，AI有时候真会脑补出错误逻辑。

我一般是把要改的函数或者文件路径直接贴在prompt里，然后明确说“其他地方一行都别动”，配合git diff快速检查改动范围，发现乱改直接revert。另外Cursor的Rules功能可以全局加一条“禁止修改与本次任务无关代码”，效果比每次现写提示词稳定不少。不过说实话，改到service层这种连锁反应真不好完全避免，我现在还是习惯每次commit前用diff逐行过一遍，顺手就把它的“好意”给撤回了。

试试把改动范围直接写进系统提示词，比如“只允许增改函数体，签名和import禁止动”。

我一般用Agent模式时单独开个MCP工具做diff审查，改完先看变更列表再合。

我一般是把要改的函数和它依赖的上下游函数直接整个贴进prompt，然后明确告诉它“只能改我贴的这段，其他一律别动”，效果比说“只改指定文件”好很多。另外Cursor的checkpoints功能挺好用的，每次生成前先存个档，改坏了一键回滚。不过说真的，这种问题到最后还是得靠code review，AI写代码本质就是个高级补全工具，别指望它理解你的架构意图。

我一般会把改动的范围直接写进system prompt里，比如“只允许修改XXX文件，其他文件一律禁止改动”，但说实话，光靠嘴说还是不够，Cursor有时候就是会“手滑”。我现在习惯把核心逻辑抽成独立的工具函数，AI要改也只能改壳子，改动前还得让它先列出diff让我确认，不然真不敢让它碰业务代码。另外.gitignore是防不住AI的，它读的是整个项目上下文，建议还是靠git diff + 分步提交来兜底。你试试让它每次只做一个任务，别一次性塞太多需求进去，效果会好不少。

我一般直接在prompt里写“只准新增，禁止修改任何现有代码”，然后每次让它动工前把相关文件路径全列清楚，再不行就开个新对话，防止它把上下文里的旧逻辑当参考。不过说实话，最有效的还是给关键函数写测试，它一改挂了你立刻能发现，比人肉盯代码省心多了。另外git diff我基本每次必看，光靠锁文件不现实，它要改service层你拦不住的。

gitignore锁文件没啥用，我试过，它还是会读上下文改别的。我现在是让AI先输出diff，我批阅完再合，加上cursor的checkpoint能回滚，效率还行。另外prompt里直接写“只改xxx函数，其他一律不动”比“只改指定文件”管用得多。

这问题太真实了，Cursor在改代码时确实容易“顺手牵羊”。我现在的做法是每次让它改东西前，先把要动的函数体完整复制到prompt里，明确告诉它“只改这段，其他一概别碰”，同时把.gitignore里那些核心文件加上保护，但真碰上它改service层逻辑，还是得靠diff审查，效率确实有点低。

其实你也可以试试把关联的service层文件在prompt里点名设为“只读”，然后加一句“若需修改其他文件，请先说明理由，不要直接改”。我最近这么干之后，它乱动的次数少了很多，不过偶尔还是会抽风，code review那关是真的省不掉。

我都是把改动的diff先给它看，明确说只准动我画圈的部分，不然它真会顺手把祖传代码优化了。

我现在直接让AI每次改完先diff给我看，发现乱动就马上撤回，比写prompt管用多了。

这问题太真实了，Cursor有时候对“上下文”的理解就是会把关联文件都当成重构成分。我现在的土办法是每次让它改代码前，先把要动的函数整个复制到prompt里，明确说“只改这段逻辑，其他文件全部忽略”，效果比单纯锁文件靠谱点。另外强烈建议把分页这类核心逻辑封装成公共函数，AI改你私有函数总比改公共工具类安全。code review确实还是最后防线，但至少能少踩一半坑。

这个问题我太有共鸣了，Cursor在改代码时那种“顺手优化”的冲动简直像强迫症。我现在的做法是给AI划定物理边界，比如把核心service层的关键函数用注释块包起来，在prompt里写明“禁止修改//region锁定区域内的任何代码”，比单纯说“只改指定文件”有效得多。另外我发现一个技巧，让它先输出改动方案再动手，用“先列出你计划改动的函数和原因，等我确认后再编辑”这种命令式指令，能逼它收敛很多。至于gitignore锁定文件其实没用，因为AI操作的是工作区，不是git对象，你锁了它照样能改。真正兜底还是靠习惯，每次让AI改完，我都用git diff快速扫一遍，重点看参数顺序和逻辑分支，这比严格code review成本低多了。还有个偏方，把分页参数封装成对象传参，这样就算它乱改顺序，至少不会直接导致崩，编译期就能暴露问题。说到底AI就是个手快的实习生，你不能指望它自觉，得把环境设计得让它犯错成本变高。

我之前也踩过这坑，后来发现光靠prompt约束没用，得在给任务时把改动范围写死，比如明确说“只改controller层，service和model碰都不许碰”，它基本就老实了。另外.gitignore锁文件不现实，代码还是得走版本控制，我习惯每次让AI改完先自己git diff看一眼，重点扫参数顺序和逻辑分支，比全量review省力多了。你这分页搞反的问题，其实可以在测试里加个边界断言，崩了能直接定位到是AI手贱。

这个问题太真实了，Cursor有时候就像个过度热情的实习生。我现在的做法是给AI划“施工禁区”：每次让它改代码前，先复制当前函数完整代码，明确说“只改我贴的这段，其他函数一律别动”，同时把涉及到的参数名在prompt里原样列出来。另外我试过用.gitignore锁文件无效，它根本无视这个，最后还是靠提交前diff审查，重点看那些它“顺手”改的行，特别是分页和查询语句。

（然后我发现，把改动拆成更小的任务，比如先加路由，再单独写service，它反而更乖，不太会去碰无关逻辑。）

我一般是把改动的范围直接写进system prompt里，比如“只允许修改XXX文件，其他文件一律禁止改动”，然后每次对话前都贴一遍，效果好很多。另外Cursor那个agent模式确实容易扩散，我干脆把service层的代码先折叠或者临时改成只读，它就不会去碰了。不过说实话，分页这种参数顺序问题就算AI不改，我自己review时也容易看漏，还是得靠测试兜底。

这问题太真实了，我最近也被折腾得够呛。你提的.gitignore锁文件其实没用，那只是防误提交，挡不住AI直接改内存里的代码。我现在的做法是给每个文件开头写一段“禁区注释”，明确标注哪些函数、变量是核心逻辑，禁止改动，然后每次让AI动手前把这段注释复制进prompt里，效果比单纯说“只改指定文件”好很多。另外我试过用Cursor的“Agent模式”时，故意把需求拆得很碎，一次只让它碰一个函数，哪怕多跑几轮对话，也不让它一次改多个文件。还有个笨办法，就是把要改的地方先手动改成明显错误的样子，比如塞个语法错误进去，AI为了修复这个错误，就很少会去动别的逻辑了。说到底，code review还是躲不掉的，但至少能把这些“自作主张”的改动压缩到可控范围。你试过在rules文件里写死禁止修改的路径吗？我总觉得这功能应该更智能点，但暂时还没找到完美解法。

这问题太真实了，我上周刚被坑过。Cursor的模型上下文一长就容易“发挥过度”，特别是跨文件重构时，它总觉得顺手优化一下是好事。我现在的做法是，在prompt里明确写“只改我指出的函数体，禁止改动其他任何代码”，并且把要改的函数完整贴进去，给它一个“封闭范围”。另外.gitignore锁文件没用，那是给版本控制用的，AI根本不看。更靠谱的是用Cursor的Rules文件，把“不修改无关代码”写进项目级规则里，每次对话自动加载。但还是防不住它改依赖函数的调用方式，所以我习惯改完立刻用git diff看一遍，重点盯参数顺序和返回值处理。说实话，严格code review是最终兜底，但我也在尝试更细的指令，比如“如果要改关联函数，先列出来让我确认”，这样至少不会静默改动。你有没有试过在测试文件里写几个断言，让AI跑完自己验证？我最近在试这个，感觉比纯靠嘴说有用。

我也遇到过，后来发现光靠prompt约束没用，得在工程层面卡死。我现在是先把要改的代码块手动高亮选中，再让AI只动选区，能减少70%的乱改。另外.gitignore对AI没意义，它读的是整个项目上下文，不如把无关文件在对话里手动移除。还有个小技巧，让它改完先给diff，你确认了再合，别直接信任它。总归code review还是得留一手，尤其数据库逻辑这种隐性问题。

这事儿我太有同感了，尤其是FastAPI这种依赖注入比较重的项目，AI一改函数签名，连带service层的调用全得跟着遭殃。我后来试了个土办法，效果还行：把关键逻辑的核心函数直接拆成独立模块，然后在prompt里写死“绝对禁止修改xxx.py里的任何函数”，再配合git diff的逐行审查，基本能拦住80%的乱改。但说实话，靠.gitignore锁文件没用，那玩意儿是给编译产物用的，AI读代码时照样能看内容，你锁了它反而容易因为读不到上下文而瞎猜。更细粒度的技巧我目前觉得比较靠谱的是，在要求加功能时，把新代码的伪代码结构和边界条件都写清楚，甚至指定要复制的现有函数名，这样它倾向于模仿而不是重构。不过说到底，真碰上它偷偷改分页参数这种事儿，我觉得code review还是兜底的，但可以聪明点，提交前只跑相关接口的测试，用pytest选中那几个用例，别全量跑，不然每次都被它埋的雷耽误时间。你试过用Cursor的rules文件（.cursorrules）专门写一条“禁止修改非目标文件的import和函数参数”吗？我加了后情况好转不少，但对付它偶尔抽风改SQL逻辑还是有点力不从心，可能得靠更严格的类型注解和返回值校验来让错误暴露得更快。