用Cursor写React组件，AI总改我已有的代码逻辑，怎么调教？

这问题太真实了，我刚开始用的时候也被坑过。后来发现得在对话里明确圈住文件范围，比如直接跟它说“只改xxx.tsx，别碰hook文件”，不然它总觉得自己是在帮你优化全局。还有个土办法，就是把已经稳定的代码用git先提交一下，它乱改你就revert，多搞几次它也会“记住”边界。另外你可以试试在rules里写死“不得修改自定义Hook的类型签名”，比每次手动强调省心。

我刚开始用的时候也这样，后来发现得在对话里明确画个圈，比如直接说“只写组件，别碰hooks文件”，或者把已有代码单独锁定。还有个土办法，就是让AI每次改动前先列个改动清单给你确认，比事后发现崩了再回滚省事多了。

这问题太典型了，我刚用Cursor那会儿也差点被整崩溃。感觉它默认把整个文件都当成“可优化区域”，尤其是当你让它补全关联代码时，它会觉得改你已有的Hook是为了“保持一致性”，但实际上根本没理解你测试通过的那些边界条件。我的土办法是把已经稳定的Hook代码直接折叠起来，或者在对话里明确加一句“只准动新组件文件，别碰xxx.ts”，有时候还得把文件设为只读才管用。另外你可以试试在规则文件里写死，比如“禁止修改自定义Hook的类型签名”，它能记住一阵子，但换新对话又容易犯浑。后来我干脆把核心逻辑抽到独立的纯函数里，让AI只写UI层，这样它就算想乱改也够不着底层。还有个疑问，你用的是Composer还是Tab模式？我感觉Tab补全自作主张的概率更高，现在基本只用它生成新文件，修订老代码全靠手动提diff。反正别指望一步到位，这工具目前更像一个需要不断立规矩的实习生，你得时刻盯着它。

我刚开始用的时候也这样，后来发现它默认把整个文件当上下文，你写好的hook它觉得能优化就动了。试试在对话里明确说“只改xxx部分，别碰yyy”，或者把hook代码折叠起来，有时候模型看不到就不改了。另外建议把hook先commit一下，改崩了直接git checkout，血泪教训。

碰到过一模一样的情况，我甚至觉得Cursor对已有代码的“保护意识”特别弱，你越觉得它不该动的地方它越爱碰。后来我摸索出个笨办法，就是把已经写完的Hook单独拆到文件里，然后在对话里明确告诉它“这个文件是只读的，别改，只许新建组件文件”，虽然不能百分百拦住，但概率低多了。

另外你检查下是不是用的Composer模式，那个模式上下文一长就容易自作主张，我现在写关键逻辑都切到普通Chat模式，让它只输出代码片段，我自己往项目里放，反而更可控。还有个小技巧，每次给它任务前，先把Hook的关键类型定义贴进对话，并且加一句“基于以下接口实现组件，禁止修改签名”，它通常会遵守。

不过说实话，我觉得这跟AI的“惯性”也有关，它看到类型不匹配或者觉得有优化空间就手痒，咱们得学会给它画圈。你试试在项目根目录放个AGENTS.md文件，里面写上“现有模块逻辑稳定，辅助代码生成时不得改动已测试函数”这种规则，我试了几天，它遵守度确实高不少。说到底，工具好用归好用，关键地方的防火墙还是得自己搭，别太指望它自觉。

这问题太真实了，Cursor在补全代码的时候经常“自作聪明”地觉得你的hook不够完美，顺手就给你重构了。我现在的办法是，让AI改代码前明确用注释锁住关键文件，比如写上“不要修改下面函数签名”之类的指令，效果会好一些。另外也可以试试把Hook单独拆到一个文件里，再把那个文件在对话里设为只读上下文，基本就能避免它乱动了。

跟我的情况一模一样，尤其是TypeScript类型稍微复杂点，它就容易理解偏，然后自作主张帮你“优化”掉。我个人感觉它有时候是上下文窗口太短，把你旧的逻辑忘了。建议你每次补组件时，把那个Hook的核心代码重新贴一遍，并强调“仅参考，禁止改动”，它听话的概率会高不少。

我猜你是直接在对话里让它改组件，没给它明确边界？Cursor有时候会把你的意图放大，以为你要重构整个逻辑。试着把需求说窄点，比如加上“只负责组件渲染部分，不要动Hook内部实现”，它一般就会老实了。如果还不行，就把Hook文件加到.gitignore里，或者用编辑器自带的代码折叠功能，让它看不见细节。

我也遇到过这情况，后来在对话里明确跟它说“只改我指定的文件，别动Hook”会好一些，但偶尔还是会抽风。建议把已经稳定的代码用git提交一下，AI改坏了直接revert，比跟它讲道理快多了。另外试试把Hook的类型定义和实现拆成两个文件，它有时候是看到整个上下文太复杂才忍不住动逻辑的。

用.cursorrules限定只让它新增文件，别碰已有代码，亲测管用。

我也遇到过这情况，后来在.cursorrules里加了一条“不要修改未被要求修改的文件”，明显好很多。另外可以试试用@符号精确指定上下文，只把需要参考的Hook文件圈进去，别让它自动扫描整个项目。还有个笨办法就是先commit再让AI动手，改崩了直接回滚，比跟它反复拉扯省心多了。

我也遇到过这情况，后来发现是Cursor默认会扫描整个文件上下文，你让它补组件它可能觉得顺手把Hook也优化了。我的做法是先把Hook文件关掉或者用@只引用需要的部分，再明确告诉它只写新组件别动其他文件。另外可以在提示里加一句“不要修改已有代码，只新增”，基本就不乱改了。

这问题太常见了，我一般会在prompt里明确写“只改我指定的文件，别动已有的hook”，或者用@精确引用文件范围。

我一般只让它补新文件，老代码先锁住别让它碰。你可以在提示里加一句“不要修改已有Hook”，会好很多。

这个我也遇到过，Cursor默认会把它认为“相关”的文件都纳入上下文，你那个Hook它可能觉得有优化空间就顺手改了。我的做法是在.cursorrules里明确写清楚：只允许修改当前打开的文件，其他文件一律只读参考。另外提问的时候加一句“不要改动已有Hook的任何逻辑和类型”，基本上就能管住它了。

我之前也遇到过类似问题，后来换了方案。

提示词里加一句“只改我指定的文件，别动已有代码”，我试过挺管用，你可以试试。

这个问题我也踩过坑，Cursor默认会把整个文件甚至相关文件都塞进上下文，它看到你的Hook觉得“不够优雅”就忍不住动手。我现在的做法是在项目根目录放一个.cursorrules文件，明确写清楚“不要修改已有Hook的参数和类型定义，只允许新增组件文件”，效果立竿见影。另外你可以在对话里用@符号只引用需要参考的文件，而不是让它自己扫整个目录，这样它就不会越界去动你的Hook了。还有个技巧是先把Hook的接口用注释写死，比如在文件顶部加一行“此文件已冻结，请勿修改”，AI对这类指令的遵从度还挺高的。不过说实话，有时候它改你的代码是因为你的Hook和组件之间确实存在类型不匹配，它想帮你修，只是方式太粗暴。所以每次它改完，你得用git diff仔细看一遍，别直接accept。我现在养成的习惯是让AI先输出方案再动手，确认没问题了再让它写代码，这样可控很多。

我也遇到过这个，后来发现关键是在prompt里明确圈定修改范围，比如直接说“只允许新建文件，不要动hook目录下任何代码”，Cursor一般会遵守。还有个习惯是先把要改的文件用@引用进来，没引用的它就不太会去碰。实在不行就把hook代码复制到对话里当上下文，然后强调这是只读参考。另外可以试试在项目根目录加个.cursorrules文件，把“禁止修改已有逻辑”写进去，挺管用的。

我也遇到过，Cursor特别爱“顺手”改别的文件。后来我基本只圈选要新增的那几行，然后用 Cmd+K 局部生成，不让它自己去找上下文。还有个习惯是把已经定稿的 Hook 先 commit 一下，改崩了直接回滚，省得跟它掰扯。其实可以在 .cursorrules 里写清楚“不要修改已有文件”，会老实不少。

我也遇到过这个问题，Cursor默认会把你整个文件当成可编辑范围，它觉得“顺手帮你优化一下”是好事，但对咱们来说就是灾难。后来我摸索出一个办法，在提示词里明确加一句“只允许在指定区域新增代码，禁止修改任何已有函数签名和类型定义”，它听话很多。还有个更狠的招是把已有的Hook单独放到一个文件里，然后用@引用它，这样AI改不到源文件，只能基于类型去写新组件。不过有时候它还是会偷偷改import或者加一些没必要的useEffect，我一般会开着git diff，它一动手我就revert再重新下指令。说到底Cursor还是偏向“帮你重构”而不是“帮你补全”，得反复强调边界才行。

可以试试在prompt里明确说只改指定文件别动Hook，或者用.cursorrules锁住已有代码。我一般先让AI读一遍再动手，不然它老自作主张。