用Cursor写业务代码总被同事吐槽，是我姿势不对还是工具不行？

Cursor就这样，你越惯它它越爱自作主张，改bug前先明确告诉它别动其他代码。

这个问题挺典型的，我们组半年前也踩过一模一样的坑。Cursor的Composer确实有个倾向，就是它训练数据里大量高质量开源库的写法都是高度抽象、层层封装的，所以它默认就爱往那个方向走。但业务代码跟库代码是两码事，业务要的是能快速读懂、方便改，不是可复用性拉满。我后来摸索出来一个办法，就是在.cursorrules里明确写清楚项目约定，比如“禁止为只调用一次的逻辑创建helper函数”“修改bug时只改相关行，禁止顺手重构”。这个规则文件真的能压住它一大半的过度发挥。另外Composer模式我基本只用来做新模块的初稿，改bug老老实实切回单行Tab补全或者手动圈选范围，不然它那个diff能看瞎眼。还有个心得是prompt里加一句“保持最小改动原则，像在review严格的团队里提交PR那样”，效果挺明显的。你可以先试试规则文件加约束，如果还压不住，那可能就得考虑换个更克制的工具组合了。

这锅得AI背一半，Composer确实爱自作主张重构，改bug前先跟它说只改这一处别动别的。

这个我太有同感了，Composer一开就停不下来，改个空指针它能顺手把你整个service层重写一遍。我现在都逼自己先手写核心逻辑，再让AI只补边界和测试，不然review真的没法看。类型体操那个也真实，模型好像天生爱炫技，写出来的泛型过两天自己都看不懂。说白了工具没问题，是得给它划个圈，别让它自由发挥。

这问题真不全是工具的事，Cursor的Composer确实有“改一处动全身”的毛病，我一般会先圈定范围再让它动手，不然diff能吓死人。你同事说的“顺从AI”我也有同感，模型天然喜欢拆函数、加类型，写业务代码反而显得绕。我的做法是让它先给方案我再手动落地，或者干脆用inline模式只改局部。你可以试试在prompt里明确写“最小改动、不重构”，会好很多。