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

这问题太真实了，我前几天也被坑过一次，它给我重构了一个工具函数，表面看逻辑没问题，但边界条件直接漏了。后来我总结了个土办法，就是每次让AI改代码前，先明确告诉它“只输出diff，不要直接改文件”，然后我自己手动应用，这样它就算想顺手牵羊也没机会。还有个技巧是把关键函数签名和业务规则直接写进项目的AGENTS.md里，让它每次读上下文时都过一遍，比在prompt里喊破嗓子管用得多。不过说实话，对于那种跨文件的隐式依赖，AI确实很难判断哪些是“无关逻辑”，所以我现在基本默认它一定会动不该动的地方，靠git diff来逐行审查，而不是指望它自律。你提到用.gitignore锁文件，这个我试过，但只能防它改文件，防不住它在你允许修改的文件里引用那些被锁的旧接口，反而会出更隐蔽的错。所以我觉得最靠谱的还是把测试覆盖率提上去，尤其是分页、权限这种边界逻辑，AI一改测试就红，比人眼review快多了。另外，如果你用的是Cursor，可以试试它的“Agent模式”里指定保护路径，或者干脆用子模块隔离核心代码，逼着它只碰你给的范围。

这问题太真实了，Cursor有时候就跟“热心肠”似的，恨不得把你整个项目都重构一遍。我现在的土办法是让它改哪就只贴哪段代码到对话里，别把整个文件丢给它，然后明确告诉它“未展示的代码一律不许动”。另外，改完先别急着跑，用Git diff快速扫一遍，重点看它动过的那些跟需求无关的地方，比完全靠review省心一点。

这问题太真实了，我上周刚被坑过一次，它把我一个工具函数里的默认参数从None偷偷改成了空列表，排查了半天。我的经验是光靠prompt约束确实不靠谱，模型对“只改”这个词的理解太表面了。我现在是给Cursor配了项目级的rules文件，把关键文件路径和函数名写死，让它遇到关联修改先停下来问，虽然会多几次交互，但至少不会乱窜。还有个小技巧是，每次让它改代码前，先用git stash把工作区搞干净，改完直接diff，只看它动了哪些行，一旦发现意外改动立刻checkout还原，比事后review省力。至于.gitignore锁文件没用，它根本不读那个，我更倾向用.gitattributes加上linguist-language标记，或者干脆把service层拆成独立子模块，让AI的上下文窗口别覆盖到那边。不过说实话，复杂逻辑我最后还是自己写，AI适合搭骨架，填肉的时候真得盯紧点，尤其分页这种边界条件，十次有八次要出错。

我一般直接给Cursor上“手术刀模式”：在描述需求时把要动的函数名、参数、返回结构全部写死，再加一句“其他任何代码都不许碰”。实测比“只改指定文件”管用得多，因为AI经常误解文件边界。另外.gitignore锁文件没啥用，它根本不会遵守，不如在项目里放个AGENTS.md，写清楚哪些模块是禁区。当然，code review还是得看，尤其改到分页、事务这种敏感逻辑时，我基本默认它一定会犯错。

还有个野路子：用git diff习惯性先扫一眼改动，把不相关的hunk直接checkout掉。我现在基本就是“AI写，我审，反向教它”的循环，时间长了它会学乖一点。但说实话，这种问题真没银弹，就是得接受AI是个“急性子实习生”，你得给它划好跑道，不然它总能给你整点惊喜。

我倒是建议你试试把需求拆得细碎点，每次只让它改一个函数，别一次加一整个接口。另外在prompt里明确用“禁止修改xxx函数”“保持现有参数名不变”这种负面清单，比正面描述有效。还有个技巧是让它先输出修改计划，你确认了再让它动手，虽然多一步，但能拦掉大半乱改。反正我现在是彻底放弃让它“自觉”了，全靠流程卡。

这问题太真实了，我拿Claude写Go的时候也老被它“好心办坏事”。后来我试了个土办法，把项目里核心的service层和数据库操作直接折叠起来，prompt里明确说“只允许动controller和路由文件，其他代码视作只读”，然后每次生成完先git diff看一眼改动范围再commit，比反复强调“别改逻辑”管用多了。还有个偏方是开个新分支专门让AI跑，跑完对比主分支看它到底动了啥，心里就有底了。

说实话，指望AI完全守规矩不太现实，我现在就当它是个打字很快的实习生，code review这道关真省不了，但配合文件锁定和diff习惯能少踩一半坑。

这个问题太真实了，我这边踩坑比你只多不少。后来我琢磨出一个土办法：把要改动的函数和相关的service层代码直接复制粘贴到prompt里，明确告诉它“只改这段逻辑，其他的一律不许碰”，同时把不相关的文件路径也贴进去，说“这些文件如果被修改我会直接revert”。另外我发现Cursor的rules文件其实挺好用的，把“禁止修改非目标文件”写成强制规则，比每次在prompt里强调管用得多。至于.gitignore锁定文件，说实话对AI没啥用，它读的是你整个项目的上下文，不是文件锁。我现在最依赖的还是每改完一个功能就立刻git diff看一遍，尤其是参数顺序和数据库层改动，必须逐行过。说到底，这玩意儿就是个高级自动补全，你指望它完全理解业务上下文太难了，严格review才是底线，其他都是辅助。顺便问下，你试过给它单独建一个只含相关代码的临时分支吗？我最近这么搞，误改率确实降了不少。

这个问题太真实了，我最近也被折腾过。后来我学乖了，把改动需求写得特别“窄”，比如直接说“只改xxx.py的yyy函数，其他函数动都不要动”，同时把相关代码片段粘进prompt里，效果比单纯说“别改其他”好不少。另外我习惯在改完后用git diff快速扫一遍，重点看有没有非预期的行变更——真要防，还得靠这一步，光靠指令不现实。

试试在需求里写死“禁止修改函数签名和查询逻辑”，配合AI只读上下文模式，比锁文件管用。

我一般是加完功能直接git diff看改动，发现乱改就revert，多来几次AI就老实了。

我都是直接告诉它“只加代码别改现有行”，配合git diff逐行检查，基本能拦住瞎折腾。

我一般用Cursor的时候会先手动把要改的函数加上注释标记，比如写个TODO或者特殊符号，然后在prompt里直接说“只动这个函数，别的别碰”，这样比单纯说“只改指定文件”有效得多。另外分页那个问题我也踩过坑，现在涉及参数顺序的地方我会在代码里写清楚类型注解，AI瞎改的时候至少类型检查能拦住一部分。说实话，完全靠工具限制不现实，核心逻辑还是得自己盯一眼diff，尤其是service层和数据库交互的地方，别省这个功夫。

这问题太真实了，Cursor的上下文关联有时候确实“聪明过头”。我一般会把要改的代码块直接贴进prompt，明确告诉它“只基于这段代码操作，别扩散到其他函数”，比单纯说“只改指定文件”管用。另外可以试试在改动前先手动git diff存个快照，万一它乱来直接回滚，省得review时还得逐行猜它动了啥。不过说实话，涉及数据查询和参数顺序这种核心逻辑，我最后还是会自己过一遍，AI当辅助还行，真指望它完全听话不太现实。

我一般会在prompt里直接贴出目标函数的完整代码，然后明确说“只改这个函数，其他一律别动”，同时把.git目录和关键文件扔进.cursorignore里，至少能挡住一部分乱改。但说实话最有效的还是改完先跑一遍diff，逐行看它动了啥，尤其是参数顺序这种坑，AI经常想当然。要是项目急，我干脆让它先写新接口的独立文件，最后我手动合进去，省得它碰老代码。你试试AB两条路并行，能省不少回滚时间。

这个问题太真实了，我甚至怀疑咱俩用的是同一个AI。后来我试了个笨办法，让它改之前先自己贴一段“改动前后对比”的diff，不解释清楚不许动手，虽然啰嗦了点但有效防抽风。另外别指望锁文件，它真要改你根本拦不住，还是得靠git diff一眼扫过去，重点盯参数名和查询条件这类逻辑点。

我一般是把要改的接口和涉及的文件路径直接贴在prompt里，然后明确写“其他文件一律别动”，但还是会偶尔翻车。后来干脆给Cursor配了rules文件，把核心逻辑层和数据库操作都写进禁止修改的列表里，效果好了不少。但说实话，改完还得自己过一遍git diff，尤其是参数顺序和默认值这种隐蔽改动，光靠AI自觉真不现实。

我最近试过用git stash或者分支锁定的方式，让AI只在一个临时分支上干活，改完再手动合回来，这样就算它乱动也能一眼看出来改了啥。不过感觉最靠谱的还是写完立刻跑一遍测试，像你那种分页崩了的情况，其实加个简单的类型检查或断言就能拦住。你们有没有试过用AI的“只读模式”或者把文件标记成只读属性？我好奇这个是不是能彻底治本。

试试把改动范围写进AGENTS.md里，再加个lint和单测卡CI，改错直接红，比靠嘴硬提示靠谱多了。

这问题太真实了，尤其Cursor这种工具，上下文一长就容易自作聪明。我现在的做法是让AI只改某个函数内部，明确告诉它“不要动签名和外部依赖”，如果涉及多个文件就拆成多次对话，每次只给一个文件的上下文。另外，git diff审查是必须的，但可以配合.gitattributes把核心文件标记为merge=ours，至少能防住误改。还有个野路子，把关键逻辑封装成黑盒函数，AI看不到具体实现，它想改也没法改。

我一般会在prompt里加一句“只允许修改我指定的代码块，其他一律保持原样”，但说实话效果有限。后来学乖了，干脆把要改的部分复制出来，让AI在新文件里改，改完再手动粘回去，这样它就没机会碰别的代码了。虽然麻烦点，但至少稳，测试再也不怕突然崩了。

其实我觉得这问题根源是AI对“意图”的泛化理解，它觉得帮你优化是好事，但不知道你的边界在哪。我现在用的时候，会先在项目里建个AGENTS.md，把项目结构和禁区写清楚，然后让工具读这个文件。另外，习惯性每次改动后跑一遍全量测试，比啥都靠谱。真要省心，还是得靠人盯，AI顶多算个加速器。

我之前也踩过这坑，后来发现最管用的是把改动范围直接写进system prompt，比如“只允许修改xxx.py的yyy函数，其他文件一律视为只读”，效果比单纯说“别乱改”好很多。另外git diff确实得养成习惯，每次生成完先过一眼改动再提交，别偷懒。要是项目大，建议把核心逻辑拆成独立模块，AI手再长也够不着。

这问题太真实了，Cursor有时候就像个热心肠的同事，你让它改个接口，它恨不得把整个项目都重构一遍。我现在基本把规则写在项目根目录的.cursorrules里，明确标注哪些文件是核心逻辑不允许动，再配合git diff逐行看改动，比单纯靠prompt约束靠谱多了。另外分页那类参数问题，建议把类型和边界条件直接写进函数签名，AI看到明确的类型注解一般不敢乱来。说到底还是得靠review兜底，但把规则前置能省不少事。

这问题太真实了，我最近用Copilot也踩过类似的坑，它特别喜欢“顺手”重构，哪怕你说了只加接口，它还是会觉得改个函数签名能让代码更“优雅”。后来我发现最管用的不是靠prompt，而是直接改工作区权限，把service层和数据库模型那些文件在IDE里设成只读，这样AI想改也改不了，只能报错。还有个土办法就是每次让它动代码前，自己先git stash一下，然后看diff，只保留新增部分，回滚其他改动，虽然麻烦但能救命。至于.gitignore那根本不行，那是管版本控制的，管不了AI的编辑器行为。我试过在项目根目录放个AGENTS.md，用自然语言写死“禁止修改已有函数签名，禁止改动查询逻辑”，效果比在对话里强调强一点，但也不是100%听话。说到底，严格review还是兜底，我现在的流程是AI写完必须过一遍pytest，再加个mypy，类型错误能拦住大半像offset和limit这种参数顺序搞反的问题。你也别太指望工具能完全理解“只改指定文件”这种语义，它只是概率模型，不是编译器，有时候真的得在code review上多花点时间，反而省得后面debug到崩溃。

这问题太真实了，感觉cursor对上下文的理解还是太“发散”。我现在的土办法是加新功能前先把相关文件用git stash暂存，让它只读当前分支的diff，改完再恢复，虽然麻烦但至少不会乱串门。另外prompt里可以试试直接写“禁止修改任何未被提及的函数”，比“只改指定文件”管用。还是说其实有那种像codex一样的项目级忽略规则，只是我们没找到？