用Cursor写React组件，为什么总生成一堆用不上的复杂逻辑？

太真实了，我也遇到过这种情况。感觉Cursor特别爱“炫技”，你让它写个列表，它能给你整出个状态管理方案来。后来我学乖了，prompt里直接加一句“不要抽象，不要优化，用最简单的useState和map实现”，效果好多了。其实它那些hook和memo本身没错，但对业务代码来说就是过度设计，反而增加维护成本。

prompt里加一句“不要抽象，不要优化，最简实现”会好很多，它默认就爱炫技。

这还真不全是Cursor的锅，它训练数据里那些开源项目的“最佳实践”味儿太冲了，默认就按生产级标准给你堆料。我后来学乖了，prompt里直接写“不要抽hook，不要性能优化，全部写在一个组件里”，情况好很多。你也可以试试把“保持简单”这种要求放在最前面，甚至让它先给个v0版本再迭代。不然每次光删那些用不上的抽象，比自己写还累。

我也有同感，prompt写得越具体它反而越爱自由发挥。后来我试了试在prompt里直接加一句“不要抽象，不要封装，全部写在组件里”，效果立竿见影。感觉它更像是个爱炫技的实习生，你得把“不做什么”也交代清楚才行。

我刚开始用的时候也这样，后来发现得在prompt里明确加一句“不要用额外抽象，直接写最简单实现”，不然它默认你是个写框架的人。其实它是在按最佳实践来猜你需求，但对业务代码来说过度设计反而难维护。我现在都先让它出个最简版，跑通了再让它加东西，这样可控多了。

这真不怪你，Cursor这货就是喜欢“过度设计”，我怀疑它的训练数据里全是那些追求最佳实践的代码仓库。你让它写列表，它恨不得把整个应用的架构都给你搭好，生怕你觉得它不够专业。我现在的办法是prompt里直接写死“不要自定义hooks，不要memo，不要抽象，就写最直接的实现”，效果好很多。不过话说回来，它可能也是被那些“高质量代码”评测标准给带偏了，毕竟简单直接的代码反而不好“秀肌肉”。

我刚开始用Cursor的时候也有这感觉，明明需求就一页纸，它非要给你整出个三层架构来。后来我琢磨了一下，问题可能出在prompt的措辞上，你光说“实现一个用户列表”，它默认就按最佳实践给你堆料，什么可维护性、扩展性全考虑进去了，压根没管你实际场景就是个小工具页面。我现在都直接写“不要用自定义hook，不要memo，不要useCallback，直接写在组件里”，它反而老实多了。另外我发现它特别喜欢参考开源项目的写法，那些项目要应对各种边界情况，自然逻辑就复杂，但咱们业务代码真没那么多讲究。其实说到底，AI是照着“好代码”的标准在生成，但咱们要的往往是“够用就行”的代码，这中间的落差只能靠你自己去校准。你有没有试过在prompt里加上“保持代码简单直接，不要过度设计”这类约束？我加上之后生成结果明显清爽不少。

我倒觉得这锅不全在Cursor身上，它本质是个概率模型，你给它一个具体目标，它当然倾向于输出“看起来最专业”的完整方案。你想要的简单列表，在它训练数据里可能反而是少数派，毕竟网上教程都在教最佳实践。

我自己也踩过这坑，后来摸索出一个办法：在prompt里直接限定“不要自定义hooks，不要性能优化，用最基础的useState和useEffect，代码行数控制在80行以内”。这样它基本能收敛，偶尔还是会多嘴，但删起来容易多了。

另外我怀疑你是不是在跟它对话时，前面几轮给了它什么暗示？有时候它会把上下文里的“抽象”理解成“需要更多抽象”。你可以试试新开一个会话，把需求说得更“笨”一点，比如“就用一个组件，数据写死在文件里，不用封装api”。

不过说真的，用Cursor写业务代码，本来就得抱着“它是个爱炫技的实习生”的心态来用。你让它写核心逻辑它反而容易跑偏，让它补样式或改bug倒挺听话。我现在都是让它写测试用例和类型定义，这部分它多写点我还能接受。

你有没有试过在回复里直接跟它说“这太复杂了，删掉这些”让它自己改？有时候它改一次反而比你自己删更快，虽然偶尔会越改越糟。

AI生成代码的通病，它默认给你“最佳实践”而不是“够用就行”，你得在prompt里明确拒绝这些。

确实，得反复强调“不要封装”，不然它总想炫技，简单需求整出一堆抽象层。