Cursor 的 Composer 是被高估的玩具
我觉得 Cursor 的 Composer 就是被过度吹捧了，实际开发中它根本不如手动拆解任务给单文件补全来得可靠。Composer 经常改完 A 文件漏 B 文件，或者引入你根本没提的依赖，最后 debug 时间比自己写还长。它只适合演示原型或者写点胶水代码，真到业务逻辑复杂一点就露馅。你们是靠着硬调提示词硬生生把它用顺了，还是早就弃坑回去用普通补全了？
回复（4）
登录后参与讨论
我觉得 Cursor 的 Composer 就是被过度吹捧了，实际开发中它根本不如手动拆解任务给单文件补全来得可靠。Composer 经常改完 A 文件漏 B 文件，或者引入你根本没提的依赖，最后 debug 时间比自己写还长。它只适合演示原型或者写点胶水代码，真到业务逻辑复杂一点就露馅。你们是靠着硬调提示词硬生生把它用顺了，还是早就弃坑回去用普通补全了？
登录后参与讨论
说真的我刚开始也觉得自己 prompt 没写对，后来发现是 Composer 它真的有自己的想法，动不动就给我整活。但我还是没弃坑，因为单文件补全有时候格局太小，只是现在学乖了，每次开 Composer 之前先把关键文件锁死，不然它真敢乱动我不敢动的地方。
我跟你一模一样，刚开始也觉得自己 prompt 没写好，后来发现它就是会自作聪明。不过我现在的办法是把它当高级搜索引擎用——让 Composer 先写一个改动的初稿，然后我手动把改动摘出来贴到对应文件里，只借用它的思路但不让它直接操作文件，这样既省了敲字的时间又不会乱改东西。你现在是完全不用了，还是像我这样只取一部分用？
说实话我觉得你俩这用法都挺拧巴的，又锁文件又手动画瓢的，那这工具的价值不就打了个对折吗。作为PM我肯定看ROI，如果每次用它都得像拆炸弹一样做一堆前置防御，那省下来的那点时间早被精神内耗吃回去了。我对它的定位就是高级原型机和临时脚本生成器，但凡涉及状态流转或者核心领域模型，我绝对不碰它，这玩意目前的能力边界根本就不在复杂业务逻辑这块。
我就直说了，你们这又是锁文件又是手动画瓢的，折腾半天不如直接开两个侧边栏写。Composer 这玩意我从 0.3 版就开始用，头一个月确实上头，后来发现它最大的问题不是改错文件，是它压根不理解你项目里的隐式约定——那些你在脑子里跑过八百遍的边界条件，它每次都给重新发明一遍。现在我只有在写单元测试或者批量改命名这种脏活时才开它，真到核心逻辑，连补全都嫌它啰嗦，直接关掉 AI 手敲，当年没 AI 的时候不也是一行一行码过来的么。