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

这问题太真实了，Cursor对已有代码的“过度理解”确实容易好心办坏事。我现在的做法是，让它改代码前先明确圈定范围，比如直接在提示里写“只动组件文件，禁止修改hook.ts”，它基本就能守住边界。另外建议把hook的关键类型或逻辑用注释锁一下，AI看到标注后一般就不敢乱碰了。你试试在生成前加一句“保持现有API不变”，应该能省不少回滚的功夫。

我也遇到过这情况，后来发现是对话里上下文太模糊了，AI分不清哪些是“可动的”哪些是“不可动的”。现在我会在prompt里明确写“不要修改XXX文件”或者“只改动函数体内部”，效果好了不少。

另外建议你试试把Hook代码单独折叠或者加个注释标记，比如“以下代码为稳定版，禁止改动”，AI其实挺吃这套的。再不行就锁定文件，手动改完再放开，虽然麻烦点但至少不会崩。

有没有更详细的教程推荐？

这问题太典型了，我一开始用也这样。后来发现AI在生成关联代码时会把上下文里的已有代码当成“可优化”的部分，尤其是自定义Hook这类它觉得能“改进”的。我的办法是每次让它写新组件前，明确在指令里加一句“不要改动现有文件”，然后生成完自己再diff检查一遍，虽然麻烦点但比返工强。另外你可以试试把Hook文件单独锁起来，或者用git暂存，被改了直接回滚，几次下来它就会学乖一点。

这问题太典型了，我刚开始用那会儿也差点被整崩溃。后来我发现它特别爱“自作聪明”地重构你的代码，尤其是当它觉得你的类型定义不够“优雅”的时候。我现在基本把Hook文件单独锁起来，要么用.gitignore临时忽略，要么直接用对话里明确告诉它“只许动这个组件文件，别碰我那个Hook”。另外你试试在规则里写一行“所有已有函数签名和副作用必须保持不变”，能稍微抑制一下它的发挥欲。

还有个野路子，就是故意把Hook代码写得“丑”一点，比如加些看起来没用的注释或者稍微冗余的写法，它反而会敬畏一点，不太敢大动干戈。说到底，它就是个概率模型，你上下文里给的边界越清晰，它跑偏的概率就越低。它改你代码的时候你观察一下是不是因为你给的描述里带了“优化”或者“重构”这类词，有时候咱们无意中的指令词就是它动手的信号。我现在养成的习惯是，让它生成完组件后，先不急着用，diff一下看看它到底动了哪些地方，每次都得像个警察查监控一样。你也别太指望它理解“业务逻辑稳定性”这回事，在它眼里代码就是纯文本，没有“测试通过”这个概念。

试试在对话里明确说“只改组件，别动Hook”，或者把Hook文件单独关掉，我这么干后基本没再乱改过。

用子代理模式只给它开组件文件的权限，Hook那边锁死，AI手再长也够不着了。

这个问题太典型了，我刚用的时候也差点被气疯。后来发现它默认会把整个文件当上下文，你最好在对话里明确圈住“只改组件部分，别动useXXX”，或者干脆把Hook单独锁进一个文件里，别让它读。再不行就直接在系统提示词里写死“禁止修改已有函数签名”，效果立竿见影，但偶尔它还是会犯浑，得盯着点。

把已有文件加进context之前先锁定，或者单独开个新文件让它写，别让它一次看太多上下文。

用.gitignore或者直接告诉它“只改这个文件”，不然AI总觉得自己在帮你优化全局。

我刚开始用的时候也这样，后来发现得在对话里明确说“只要补组件，别动Hook”，或者直接在Hook文件顶部加个注释，告诉AI这是稳定代码不要改。你现在逻辑都测过了，建议把Hook放到单独文件里，用git先提交一下，AI改乱了直接revert，不用跟它纠结。另外试试给它一个详细的prompt模板，把“只允许改哪些文件”写进去，会省心很多。

试试在补代码前明确告诉它“只新增文件，别动已存在的”，或者把Hook文件标记为只读，能减少很多乱改的情况。

我一般遇到这种就直接把Hook代码复制出来，让它在新文件里写，完事再粘回去，省得跟它费劲。

把hook文件单独锁起来或者用@指定只读，我都是这么干的，省得它乱动。

我直接给它划重点“只写组件别碰hook”，它还是会改，后来干脆把hook塞进单独文件里才消停。

刚入门，这个对我帮助很大。

这问题太真实了，Cursor在补全上下文的时候经常自作主张动那些“看起来能优化”的代码，尤其对Hook的类型和依赖项特别手贱。我的办法是写组件前先用注释把Hook的接口锁死，比如// do not modify this hook，再不行就把Hook挪到单独文件里，这样它改动的概率会低很多。另外你试试在对话里直接说“只写组件，不要碰现有函数”，有时候有用，但确实得反复强调，挺累的。

我遇到过一模一样的，后来发现它改逻辑多半是因为上下文里给了太多自由度。你可以试试把需求描述得更“死”一点，比如直接说“用这个Hook的现有签名，别加任何副作用”，或者用git diff盯着，每次让它改完就revert掉不该动的部分。另外，把Hook文件设成只读或者直接折叠起来，AI看不到就不太会去碰，算是物理隔离了。

这玩意儿就是欠调教，我现在都习惯性先给它划红线，比如“参数和返回值一个字符都不许动”，然后自己把Hook文件用注释围起来，它基本就老实了。不过说实话，有时候它改完反而更健壮，只是你测试得重跑一遍，建议把关键逻辑写成单测，它一改你就跑一下，崩了马上回滚，时间长了它自己也会学乖。

我也遇到过一次，后来发现是没把Hook文件标记成只读，在设置里加个规则基本能拦住。另外补组件时尽量把需求描述得细一点，明确说“不要动已有的xxx函数”，AI会老实很多。实在不行就让它先给你看diff，你确认了再合并，别直接接受。

这问题太真实了，我头一回用的时候也差点被气死。后来发现得在对话里把“不许动现有代码”这句话钉死，或者直接把Hook文件单独关掉，不让AI读，它就没法瞎改了。另外你可以在生成组件前，把Hook的接口和类型粘贴出来，明确告诉它“只准用这些，不准碰实现”，会好很多。它有时候是太“热心”了，想帮你重构，但咱们没要求就别让它动。

这问题太真实了，我刚开始用的时候也差点被搞崩溃。后来发现得在对话里明确告诉它“只改组件，别动Hook”，或者干脆把Hook文件单独关掉，不让它读。另外你可以试试在代码里加个注释标记，比如“此文件勿改”，AI有时候真能识别这种指令。不过说实话，让它写新代码还行，改已有代码是真不靠谱，我现在都是让它给方案，自己动手改。

这问题太真实了，我刚开始用的时候也差点被搞疯。后来我摸出个规律，AI在补组件时特别喜欢“顺手优化”它看到的上下文，尤其是当它觉得你的Hook“不够健壮”的时候，其实它根本不理解你的业务边界在哪。我的做法是，让AI改代码前，先在对话里明确圈定范围，比如直接跟它说“只动这个文件里从第X行到第Y行的部分，其他函数严禁改动”，甚至会把Hook的代码复制出来贴在prompt里，让它基于这段“冻结代码”去写组件，而不是让它自己翻文件。还有个土办法，就是给Hook加个“只读”注释，比如在函数上方写一行// DO NOT MODIFY THIS FUNCTION，实测下来它遵守的概率会高不少，虽然偶尔还是会犯轴，但至少不会每次都犯。另外，你也可以把测试文件丢给它看，告诉它“这段逻辑已经过了单测，你改了就得对测试负责”，有时候它反而会收敛一点。说到底，这工具就是个会察言观色的实习生，你得把规矩立在前面，不然它真能给你把地基给刨了。

试试把Hook文件标记成只读，或者在对话里明确说“别动这个文件”，我这么干之后清净多了。

Cursor这个毛病确实烦，我一般让它先出方案，确认了再动手改代码。

把Hook文件单独锁起来或者拆到独立目录，AI就很少越界了，再不行就在prompt里明确写“别动已有代码”。

我一般把已经写好的逻辑直接标成只读，或者干脆让它只输出新增文件的代码，改老代码就手动合并。

这个问题太真实了，我一开始用也差点被气疯。后来发现核心在于你得把Hook当成“只读依赖”来交代，在prompt里明确写“不要修改useXXX文件，只在新组件里import并使用”，它一般就会老实很多。另外我习惯把Hook的代码先折叠起来或者单独开一个标签页，让AI的上下文窗口里看不到完整实现，它想改也没法改。还有个土办法，就是每次让它动手前，手动把Hook文件改成只读权限，macOS上用chmod，Windows就改文件属性，AI发现写不进去就会自觉绕开。不过说真的，Cursor这个“过度自信”的毛病在复杂类型推导上特别明显，你要是用了泛型或者联合类型，它经常自作主张给你“优化”成更简单的写法，结果类型收窄全乱了。我现在养成的习惯是，凡是涉及核心业务逻辑的文件，一概不给它写权限，只让它写那些纯展示的组件，这样至少能保住底线。你试试把“绝不修改已有文件”写进项目级规则里，配合它那个rules文件，坚持几天会好很多。