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

我也有这毛病，后来在项目根目录放了个CLAUDE.md，明确写“保持现有类型和函数签名，除非有bug否则不做结构性修改”，再把例子里故意写错一个参数让它照着填，效果比在对话里强调好得多。另外你可以试试把规则写进.cursorrules，不同版本对这两文件的优先级不太一样，我这边是后者更听话。

我最近也遇到这问题，后来在项目根目录放了个rules.md，明确写“禁止修改与当前任务无关的代码”，然后把接口签名和数据结构直接贴进去当参考，比单纯说“不要改”管用多了。另外我发现新版本对.specify文件的遵守程度高一些，你可以试试把关键约定写进AGENTS.md里。不过说实话，它有时候还是会“灵机一动”，我现在干脆把大任务拆成特别小的步骤，每次只让它改一个函数，这样就算它想搞事也波及不到别的地方。

我都是把cursor当高级补全用，写完后自己改，别让它碰大块逻辑，省心多了。

我最近也遇到类似的问题，后来发现把项目里的.cursorrules写得特别具体，比如明确标注“禁止修改入参类型，除非抛出编译错误”，效果会比放.md里好很多。另外你可以试试在对话里直接甩给它一段你写的旧代码，跟它说“照着这个范式写”，它会比看文字描述更懂你的意图。不过说实话，版本更新后这毛病确实时好时坏，有时候得把“保持最小改动”重复强调两三遍才管用。

试试在对话里直接说“只改函数体，别动签名和调用方”，我每次开工前都重复一遍，比写md里管用。

规则文件确实不稳，我后来把关键接口注释写上禁止改动，它基本就老实了，你可以试试。

试试在agent里加一条“只改函数体，别动签名和数据结构”，比放md里管用多了。

我一般直接开个新对话把原代码贴进去，明确说按这个风格写，不然它老觉得自己是架构师。

我一般会在关键函数前面直接写注释，比如“别动签名，只填逻辑”，比放.md里管用多了，文件级的规则它经常漏。而且新版本确实对上下文更敏感，但也会更“自信”地重构，我现在干脆把改动diff直接甩给它看，让它自己意识到哪些是多余的。

试试在系统提示里加一句“只改函数体，禁止动签名和调用方”，我这边效果立竿见影。

或者干脆把规则写进项目里的AGENTS.md，比单独.md稳定多了。

我最近也被这个问题搞得很烦，尤其是它改完接口签名之后，调用方连带报错，我review的时候还得顺着它的思路往回捋，比我自己写还累。后来我试了个笨办法，在项目根目录放一个AGENTS.md，里面用很直白的语气写“所有公共函数签名保持原样，除非有明确注释要求变更”，但效果确实不稳定，有时候它还是会犯轴。我感觉这跟版本也有点关系，我用的是最新版，但它的上下文理解还是倾向于“主动改善代码”，而不是“最小化改动”。后来我干脆把每个函数的入参类型都写死成具体类，不给它发挥空间，这样它想改也没法轻易改。还有一个偏方是开一个单独的rules文件，里面写“只允许修改函数体，禁止改动函数签名和调用处”，配合claude模型用会老实一点，但也别指望100%遵守。说到底，这类工具更适合从零生成代码，做增量修改时它的“审美洁癖”反而成了负担，我现在遇到关键模块就直接切成手动模式。

我也是被这个折磨过一阵，后来发现光写“别改接口”没用，得在规则里加一句“只允许修改函数体内部，签名和调用处一律不动”，然后每次对话开头再贴一遍，基本能稳个七八成。另外版本确实有差异，我换到最新版后听话多了，但偶尔还是会抽风，所以现在写完都会用git diff快速扫一眼，看到无关改动直接revert，别让它养成习惯。

我最近也碰到过这情况，后来干脆在项目根目录放了个cursor.rules，把“禁止改动函数签名和返回类型”写在最前面，效果比.md稳定多了，你可以试试。另外版本确实有影响，我更新到最新版之后，它至少会先问一句而不是直接改。不过说真的，这种“自作聪明”的毛病有时候真得靠多敲几遍提示词让它记住，比如每次开工前先贴一遍约束。

我也有同感，Cursor在写业务代码时确实容易“过度设计”，动不动就给你抽象一层，或者把简单数据结构换成类，好像不这样显不出它的能力。后来我发现光在全局规则里写“别改接口”没用，得把当前文件的上下文明确告诉它，比如“这个函数只处理dict，禁止引入pydantic”，而且要放在系统提示词的最前面，优先级才够高。另外，用Composer模式时我会在每次对话结尾加一句“只改我指定的代码块，其他地方保持原样”，效果比写在.md里稳定一些。我猜这和模型对指令的敏感度有关，有时候换个说法（比如“保持现状”而不是“不要改”）反而更管用。还有个土办法，就是把关键函数的签名写成注释直接贴在生成位置，它通常会更尊重眼前的代码。版本的话我目前用0.44.x，感觉比之前老实点，但偶尔还是会犯轴，只能靠多review兜底了。

说实话我跟你遇到的情况一模一样，后来我干脆在项目根目录放了个cursor.rules，把“禁止修改现有函数签名”和“新增代码必须模仿同文件风格”写成了硬性规则，比放.md里稳定多了。另外我发现它特别喜欢把dict改成pydantic是因为它觉得这样更“规范”，但你得明确告诉它这是内部工具，性能和维护成本优先，别整那些花活。还有个土办法是每次对话开头先把相关函数贴给它，然后加一句“只准改函数体，不准动参数和返回值”，基本能管住。不过版本确实有影响，我换了最新版之后感觉它对规则的理解强了不少，但偶尔还是会抽风，特别是上下文长的时候，你得时不时敲打它一下。最后建议你review时如果看到无关改动，直接撤销并备注原因，多来几次它就会学乖了。

试试在系统提示里加上“仅允许修改函数体内部，禁止改动签名和调用方”，我加了之后好很多。版本倒不关键，规则写具体点比啥都管用。

试试在规则里写“只能改函数体，禁止动签名和调用方”，我加了这条后清净多了。

版本倒不是关键，重点是把约束写具体，别让它有自由发挥的空间。

试试在系统提示里加一句“只改diff内代码”，或者用@Codebase限定范围，这版确实爱自由发挥。

我一般把接口定义扔进AGENTS.md里，再配合/cmd自定义指令，至少能管住八成。

我也遇到过，后来在项目根目录放了个cursor.rules，把“禁止修改函数签名”“禁止引入新依赖”这种写死，比.md稳定多了。另外你试试在对话里直接甩给它一段你写的代码，说“照着这个风格改”，比口头描述管用。

我最近也遇到这个问题，后来干脆在项目根目录放了个AGENTS.md，里面明确写“保持现有函数签名和数据结构，禁止引入新依赖”，然后把Cursor的自动补全改成手动接受，效果好了不少。另外你可以试试在对话里直接跟它说“只改函数体，别动外部接口”，有时候比全局规则更管用，但确实不太稳定，可能跟模型版本也有关系。

我最近也遇到类似情况，后来在项目根目录放了个rules.md，明确写“只允许修改指定函数体，禁止改动参数类型和调用方”，效果比在对话里强调稳定很多。不过它偶尔还是会抽风，我就直接ctrl+z回滚，然后手动把改动范围圈得更小再让它重写。另外检查一下是不是开了auto-apply，有些版本默认自动应用重构，关掉能少很多意外惊喜。

我也遇到过，后来干脆在项目根目录放了个AGENTS.md，明确写只允许在新增代码里改结构，现有函数一律照抄风格，效果比对话里提一嘴稳多了。另外可以试试把规则写进.cursorrules，优先级比.md高，我用了两周基本没再乱动签名。你那个改成pydantic的情况，大概率是模型觉得这样“更规范”，得在规则里直接禁用这类隐式迁移，不然它总觉得你在等它优化。