Cursor写业务逻辑时总是自作主张改结构，大家怎么调教的？

我也遇到过，后来直接在系统提示里写“严格遵循现有代码风格，禁止引入新依赖或类型”，然后把项目里的关键接口签名贴进去当few-shot，效果比写.md稳定多了。另外可以试试把生成模式从agent切回普通补全，改动会小很多，至少不会主动去动调用方。你用的是不是默认的auto模式？那个确实容易放飞自我。

我也遇到过这情况，后来干脆在项目根目录放了个AGENTS.md，里面直接写“禁止修改现有函数签名和数据结构定义，新代码遵循文件内已有模式”，效果比对话提示稳定多了。另外可以试试把改动范围明确圈在某个函数体里，或者用一下Composer的plan mode让它先讲思路再动手，能少掉不少“惊喜”。

我也有同样的问题，后来发现光在md里写规则没用，得在对话里明确加一句“只改函数体，不动签名和调用方”，每次新会话都要重复一遍。另外可以试试把项目里的类型定义文件直接拖进对话上下文，让它先读一遍再动工，效果好不少。还有个偏方是开一个专门的“重构草稿”窗口，让它随便折腾，等确认完再手动合并，省得review时血压高。

我也遇到过这情况，后来发现把“只改函数体，别动签名和调用链”直接写进项目根目录的rules文件里，比放.md里管用得多，而且得用祈使句，语气硬一点。另外可以试试在生成前补一句“保持现有类型和结构，除非有bug”，效果会稳定一些，但偶尔还是会抽风。

版本倒不是主要问题，关键是它训练时就被优化了“主动重构”的偏好。我现在的做法是每次review先看git diff里非文件改动的部分，遇到自作主张的改动直接批量revert，再让它重新写，多来几次它就会老实不少。

试试在规则里直接写“严格按现有代码风格填空，禁止改动签名和类型”，再不行就锁文件版本。

我都是把改动范围限定在函数体内，明确告诉它别碰调用方，基本能治住这毛病。

试试在对话里直接甩一句“照着我给的接口写，别改结构”，不行就多敲几遍，比写md文件管用。

我一般把关键类型定义锁在文件里，再让它只改函数体，基本能忍住不手痒。

试试在系统提示里加“只改函数体，禁止动签名和调用方”，配合代码上下文一起给，能稳不少。

同感，这货就是爱炫技。我直接把规则写进项目里的CLAUDE.md，每次对话都带上，效果比.md强点。

我也有同感，Cursor对“优化”的执念太强了，尤其是pydantic这招真是一言难尽，review的时候还得琢磨它为啥要这么改。后来我直接把项目里的规则写进.cursorrules文件，明确禁止改动函数签名和入参类型，效果比.md稳定不少。另外，给它看一段你写的“标准风格”代码作为few-shot示例，比单纯下指令管用得多。版本其实关系不大，核心还是得靠规则约束加上即时纠正，你可以在它改错的时候立刻按Esc回滚，再用对话把要求钉死，慢慢它会学乖一点。

试试在规则里写死“只改函数体，别动参数和调用方”，我加了这条后消停多了。

把规则写进项目里的AGENTS.md，再配上.clinerules，基本能压住它的重构瘾。

我后来干脆在规则里写了“只改函数体，禁止动签名和调用方”，效果比在.md里说强多了。

把项目里.clinerules或规则文件写成“禁止改动类型定义和函数签名，只允许在函数体内填空”，比放.md里管用。

试试加个// @ai-no-refactor注释标记关键函数，我这么干之后它基本老实了。

这问题太真实了，我最近也被这玩意儿搞到头大。你那个dict被改成pydantic的例子我简直感同身受，它好像默认所有代码都是可以“改进”的，根本不考虑你写这个项目的上下文和风格一致性。我后来试了个稍微管用点的办法：在项目根目录放一个.cursorrules文件，里面直接写“禁止修改现有函数签名和数据结构定义，只允许在函数体内部添加逻辑”，比写在.md里要稳定一些，但也不是100%生效。另外我感觉它有时候是看代码里的“味道”来判断要不要重构的，比如你传dict的时候它可能觉得“不安全”就自作主张了，你试试在传参的地方加上类型注解，哪怕只是-> dict，它可能就会觉得“哦这个已经有约束了”而少管闲事。至于版本，我用的最新版也会这样，感觉是模型本身的倾向问题，不是版本bug。说到底还是得靠人肉review兜底，我现在已经接受它是个“带点主见的高级自动补全”这个设定了，改不了它就改变自己的预期吧。

我也碰到过这问题，后来干脆把项目里的conventions.md写得更细，比如“禁止引入新类型”“只允许修改函数体”，然后每次开新会话先让它读一遍再开工，效果好一些。另外你试试在代码里直接写注释标注“此处不要动结构”，有时候比全局规则管用。版本的话我用的2.x，感觉对上下文遵守度还行，但偶尔还是会抽风，得靠review兜底。

我最近也遇到类似情况，后来发现把规则写进项目里的AGENTS.md还不够，得在对话里反复强调“只改函数体，不动签名和数据结构”，然后每次它自作主张就立刻回滚并跟它说“你改多了”。另外可以试试在生成前先让它复述一遍你的约束，相当于强制它确认上下文。版本的话我用的最新稳定版，感觉这问题跟模型抽风概率关系更大。

试试在对话里直接甩一句“只改函数体，别动签名和调用方”，比写md管用，我最近就这么干的。

我也碰到过，后来直接在系统提示词里加了条“严格遵循现有代码风格和类型，禁止引入新抽象”，再把相关代码片段贴进对话里当few-shot，效果比写在md里稳定多了。另外你看看是不是开了agent模式，那个确实更喜欢大动干戈，切回普通补全反而老实。

我最近也遇到这个问题，后来干脆在项目根目录放了个cursor.rules文件，把“禁止重构现有函数签名”和“优先沿用当前代码风格”写进去，效果比.md稳定多了。另外你可以试试在对话里明确说“只改我指出的部分，别动其他代码”，必要时用git diff盯紧点，发现越界就立刻回滚。版本的话，新版本确实更听话一点，但核心还是得靠规则约束。

我也踩过这坑，后来学乖了，每次让它改代码前先加一句“保持现有结构和类型不变，只做最小修改”，然后生成完先别急着合，用diff工具扫一遍。你那种dict被改成pydantic的情况，我试过直接在提示词里写“禁止引入新依赖或新类”，基本能压住。另外记得把规则文件放项目里，别只靠对话，不然换个会话又打回原形。

你这情况我懂，Cursor有时候就是“好心办坏事”。我现在的做法是给它一个明确的“代码风格指南”文件，里面直接写死“业务代码禁止自行抽象，参数类型必须与原函数一致”，然后每次开新对话都先@一下这个文件。要是它还是乱搞，就把它改的那段代码复制回去，再补一句“按原样重写，别用你自己的想法”，多来几次它就记住了。

这问题太真实了，我甚至怀疑咱俩用的是同一个AI。它那个“过度设计”的毛病真不是版本问题，是模型底层就倾向于给你“最优解”而不是“最合适解”。我后来试了个笨办法，在项目根目录放一个AGENTS.md，里面不是写“不要改”，而是直接写“所有函数参数必须保持dict类型，禁止引入新类，除非任务描述明确要求”，然后每次对话开头把这段复制进去，比放在全局rules里管用得多。另外我发现一个关键点是，如果你在提示词里加了“这是生产代码”或者“最小化diff”，它往往会收敛很多，但也不是百分百稳定。还有个歪招，就是故意在现有代码里写点带注释的“丑陋”结构，比如“# 这里故意不用pydantic，因为调用方是脚本”，它有时候会变得很谨慎，不敢乱动。说真的，这玩意儿就像个实习生，你得给它划出绝对禁区，否则它总觉得自己比你懂架构。

我还以为就我一个人遇到这问题，看来Cursor这毛病是通病。它那个“顺手优化”的冲动，简直跟程序员看到烂代码就手痒一样，控制不住。我后来干脆把规则直接怼到项目根目录的AGENTS.md里，写“所有改动必须基于diff最小化原则，禁止引入新依赖或修改类型定义”，然后每次对话开头再复述一遍，效果比放在普通md里强不少，但也偶尔会抽风。另外我试过在生成前加一句“只输出函数体，不要解释”，能减少一部分它自作主张的冲动。你要不看看是不是用了Composer模式？那个模式默认就爱做大重构，切到Chat模式或者用Edit指令会老实很多。不过说实话，它改pydantic可能是在模仿你项目里其他代码的风格，你要是能给它一两个明确的“反面例子”，比如直接把那个dict传参的旧代码贴进上下文，它就知道该抄哪个样了。

我最近也碰到一模一样的情况，特别是写内部工具的时候，它那个“过度设计”的倾向特别明显。后来我干脆把工作流拆成两步，第一步只让它生成最小可运行的代码，明确告诉它“保持现有类型和函数签名完全不变”，第二步再单独开个对话去讨论重构建议，这样至少review的时候能分清哪些改是它自作主张的。你试过在系统提示里加“只做增量修改，禁止删除或替换已有类型定义”这种强约束吗？我加了之后感觉比写.md文件稳定不少，不过偶尔还是会抽风，尤其是上下文长了之后。还有个小技巧，就是故意在代码里留几个简单的TODO注释，让它觉得有地方可以“填空”，而不是去动你写好的部分。对了，你用的版本是0.4几还是更新的？我换到最新版之后觉得它更倾向于遵守明确指令了，但代价是偶尔会变得特别死板，连明显的bug都看不出来。