用Cursor写了个React项目，AI经常改坏不相关代码，是我姿势不对吗？

这问题我太有同感了，老项目里那种隐式依赖确实是大坑，AI根本分不清哪些变量是全局状态还是组件内部闭包，一改就顺着作用域链往上摸。我后来试了个笨办法，每次提需求时强制把相关组件的props和state类型定义粘进去，然后明确写一句“禁止修改未提及的文件和函数”，用英文写效果反而好点。但说实话，遇到那种跨文件共享的context或者自定义hook，还是经常翻车，感觉它压根没把整个依赖图加载进上下文，只盯着当前打开的几个文件。另外我怀疑是不是webpack的alias路径配置让它产生了误判，有时候它把同名文件当成同一个模块。你要不试试把改动范围缩小到单个函数，让它先输出diff而不是直接改文件，至少能看清楚动了哪里。回滚那个痛点我也懂，现在基本每次改完都手动git diff扫一遍，指望它自觉不太现实。

这问题太真实了，老项目里那些隐式依赖确实防不胜防，AI一“好心”就容易越界。我后来是直接把要改的函数或组件单独抽成一个临时文件让它改，改完再手动粘回去，虽然麻烦点但基本不会误伤。另外试试在prompt里明确加一句“只修改xxx函数，其他任何代码都不许动”，配合git diff先看一遍再提交，能省不少回滚的功夫。

Cursor对局部上下文的理解还是有限，尤其ts+webpack这种类型推导复杂的老项目，它经常自己脑补关联逻辑。你试试把相关依赖的type定义也贴给它，让它先理清关系再动手，出错率会低一些。

老项目隐式依赖多确实容易这样，试试把改动范围写成明确指令，比如“只改这个函数，别动其它”。

这问题太真实了，老项目隐式依赖多，AI确实容易自作聪明，建议把改动拆小点，一次只让它处理一个函数。

试试在prompt里明确写“只改XXX，其他文件一律别动”，再配合git diff检查，比锁文件管用。

老项目全局依赖太乱，AI确实容易自作聪明，建议改完用git diff逐个文件过一遍再提交。

我一般会让它先列改动计划，确认范围再动手，能少踩不少坑。

说实话这真不全是你的问题，老项目里隐式依赖太多，AI的上下文窗口根本装不下整个数据流，它只能靠猜，猜错了就顺手改旁边了。我试过最有效的办法是把要改的函数单独抽出来贴给它，改完再贴回去，虽然麻烦点但基本不会误伤。另外你可以在改完一个文件后立刻git diff看一眼，别攒着一起看，这样出问题定位也快。

这问题太真实了，老项目隐式依赖多，AI根本看不出边界。建议把要改的函数单独抽出来做成新文件让它改，改完再合回去。

这问题太真实了，老项目全局状态绕来绕去，AI一改就串线。不如把改动拆成小步，每次只喂它一段函数，明确禁止碰其他文件试试。

我建议用git先存个基线，让AI只负责生成diff，你自己手动合并不碰逻辑的部分。反正它“好心”越界是真管不住，不如干脆手动管控范围更省心。

这问题太真实了，老项目里各种隐式依赖和全局状态，AI根本没法靠上下文感知全貌。我一般会让它先描述改动方案、列出涉及文件再动手，或者干脆把要改的代码块单独贴进对话里，不让它直接碰编辑器。另外试试给组件写个简短的说明注释，告诉它哪里不能动，比锁文件管用。你用的什么模型？感觉Claude在克制性上比默认的好点。

这问题太真实了，老项目里各种隐式依赖和全局状态，AI根本没法靠上下文全理解。我后来是把要改的文件单独复制到一个新目录，让AI只在这个隔离环境里改，改完再手动合回来，虽然麻烦点但基本不会误伤。另外你可以在prompt里加一句“只允许修改我提到的函数体内部”，超出范围就让它直接说“需要改动其他文件”并停下，效果会好很多。

这问题太典型了，老项目里隐式依赖多确实是个大坑，但我觉得更核心的原因在于Cursor对“最小改动”的理解跟咱们不一样。它看到的是语法树和类型定义，可咱们心里装着的是业务边界和模块职责，它觉得“顺手”改掉的state可能刚好是另一个功能在用的，这种关联它根本感知不到。

我自己的经验是，与其让它直接改，不如把任务拆成“只描述现状+只描述目标”两段，比如明确说“这段函数里我只想改返回值格式，别动其他声明”，甚至直接把要改的行号贴给它。还有个土办法挺管用，就是先把相邻组件代码临时注释掉，让它只能看到你指定的部分，改完再恢复，虽然笨但能挡住它乱跑。

另外你可以试试在对话里加一句“如果发现需要改动范围超出我提到的文件，先停下来问我”，这能逼它收敛。不过说真的，老项目靠prompt完全防住不现实，我最后是配了git diff的自动检查脚本，每次生成后扫一遍非目标文件的改动，有就自动回滚，比肉眼盯靠谱多了。你用的什么webpack版本？有些老插件对AST的解析方式可能也在误导它。

这问题太真实了，老项目里隐式依赖多，AI确实容易“自作聪明”去碰那些它觉得相关的代码。我一般会让它先输出一个精确的修改计划，确认只涉及目标文件和函数后再动手，这样能拦住不少瞎改。另外可以试试把不相关的组件文件临时移出项目目录，或者用命令行工具只给AI喂单个文件内容，从物理上限制它的视野，比纯靠prompt约束靠谱。

这问题太典型了，老项目里隐式依赖多确实是个大坑，AI有时候会“自作聪明”地帮你“修复”它以为的bug。建议你试试在prompt里加一句“只允许修改我指定的函数体，其余代码无论对错都不要动”，比单纯锁文件管用。另外把改动拆成多个小任务，每次只让它干一件事，出错概率会低很多，就算改坏了也容易定位回滚，别怕麻烦。

试试把改动拆成小任务，每次只让它碰一个文件，改完立刻diff确认，别让它一口气干太多活。

这问题太真实了，老项目里隐式依赖确实容易让AI自作聪明。我一般会让它先描述改动计划，确认只动目标函数后再执行，比直接下指令稳很多。另外可以试试把不相关的组件代码折叠起来，减少它“看到”的范围，或者干脆用git单独commit每次改动，局部对的部分挑出来合并，比全量回滚省心。

说实话你这情况太典型了，老项目里隐式依赖确实是AI最大的坑，它看到的只是你喂给它的那几行代码，但全局的context它根本猜不透。我试过类似场景，后来学乖了，让AI改之前先明确告诉它“只改这个函数内部逻辑，其他文件一律不许动”，甚至会在prompt里加一句“如果你觉得需要动其他地方，请先输出你的计划，等我确认再执行”。另外你试试把要改的文件单独抽出来给AI看，别让它同时读一堆组件，它一“好心”就容易把相邻state当成相关逻辑顺手优化了。还有个土办法，改完先不急着回滚，用git diff一点点看，把AI改对的局部手动挑出来，错的还原，虽然麻烦但比让它再改一遍靠谱。说到底，工具再聪明也是代码补全plus，别指望它能理解你公司的业务约定，你给的约束越死，它越不容易越界。要是项目里真有什么全局store或者自定义hook，最好先在prompt里把数据流画清楚，不然它下次还会给你“惊喜”。

说实话这真不怪你，老项目里隐式依赖太多确实是个大坑，Cursor对全局上下文的理解基本靠猜，你锁文件它也会通过import链“自作聪明”地扩散修改。我试过最有效的一招是：把需求拆成“只改这个函数体，不动签名和引用”，然后明确告诉它“如果发现依赖问题，只输出警告不要自动修复”。另外，老项目建议开个单独的rules文件，写上禁止修改的路径模式，比每次@文件要稳得多。还有个小技巧是让AI先给你一个改动计划，你确认了再让它动手，别让它直接输出代码。关键是它改完你只瞄一眼diff里非目标文件的部分，养成习惯就少踩坑。至于prompt，试试给个伪代码级别的输入输出示例，比描述逻辑管用很多。

说实话你这个情况我太懂了，老项目里那一堆隐式依赖确实是AI的盲区，它根本没法像人一样去追踪每个变量的引用链，所以经常是“局部最优”地觉得改了这块就能跑，结果把你别的逻辑给带偏了。我自己的经验是，别让它直接改大文件里的某个函数，而是把要改的那段代码单独抽出来贴给它，明确告诉它“只基于这段代码输出完整替换块”，这样它发挥空间小很多。另外你可以试试在提需求时加一句“禁止修改任何未在描述中出现的变量或函数”，虽然不能百分百保证，但确实能降低误伤概率。还有个土办法，就是每次让AI改之前，先用git stash把当前状态存好，改完哪怕它出错了，你也能用git diff精准挑出它动过的行，只回滚那些非预期的改动。至于锁定文件那个功能，我试过也得看情况，有时候它还是会通过import链去“理解”上下文然后自作主张。说到底，老项目里如果你自己都对全局依赖没把握，那AI肯定更没把握，所以可能最靠谱的还是把任务拆得更原子化，一次只让它动一个点，别指望一次性搞大重构。

我也被这个坑过，感觉不完全是你的姿势问题。Cursor改代码时会倾向于“顺手优化”它看到的周边逻辑，尤其是老项目里那些隐式依赖和魔法字符串，模型读不出边界在哪，就容易越界。我的经验是别让它一次改整个文件，先用@把范围缩到具体函数或组件块，再明确说“只修改这个函数内部，其他行保持原样”。另外可以在prompt里加一句“不要改动任何import、state声明和依赖数组，除非我明确要求”，这招对我挺管用。还有个偏方是让它先输出diff或修改计划，你确认了再让它落地，虽然多一步但能少回滚几次。老项目本身类型和依赖就乱，AI理解全局确实吃力，所以别指望它一次到位。我现在都是小步走，改完立刻git diff扫一眼，发现越界就单独把那几行还原，比整个回滚安全多了。