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

说实话我也踩过这个坑，Composer写业务代码确实容易“用力过猛”，后来我改成先自己把接口和数据结构定好，再让它只填函数体，diff基本就控制在几行了。另外review意见里有价值的部分得反喂给模型，比如告诉它“这是业务模块，别动公共逻辑”，时间长了它会收敛不少。你试试把任务拆成原子指令，一次只改一个点，别让它自由发挥。

Cursor这锅背得冤，你得多用tab补全干杂活，大改动让它停在小步提交。

这问题我也踩过坑，Composer确实容易“用力过猛”，后来我改成只让它生成函数体，接口和类型自己先定好，diff直接小一大截。另外review的时候别光看逻辑对不对，得主动问它“为什么这么拆”，很多时候它只是概率上觉得这样像“好代码”，并不一定适合你们项目的实际复杂度。

Cursor当结对编程还行，当主力容易放飞自我，得带着明确约束去用它。

这事儿我太有同感了，Composer默认就是“过度设计”倾向，我后来直接改用它的小模型模式，或者把任务拆得特别细，让它只动那一个函数，别碰别的。而且review的时候我基本不看它写的逻辑，先看diff里有没有夹带私货，那些helper和类型体操基本全删。你下次试试让它先解释打算怎么改，再动手，至少能拦一半的“顺手重构”。

这真不是工具不行，是你还没给它立好规矩。我现在的习惯是写完就自己重读一遍，凡是它自己加戏的部分全砍掉，只留最直白的实现，review通过率一下就上来了。

Cursor写业务代码确实容易过度设计，我一般只让它出单点函数，整块重构还是自己来把控。

说白了它就是高级补全，你把它当结对程序员而不是架构师，review就不会那么惨烈了。