用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里明确拒绝这些。

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

prompt里直接加一句“不要任何优化和抽象”，能砍掉八成多余代码。

我最近也碰到过一模一样的情况，给它的prompt越具体，它反而越喜欢往深了挖。后来我琢磨了一下，问题可能出在我们把“实现一个功能”理解成“帮我写一个完整的最佳实践demo”了，它默认你是在搭一个要长期维护的大型项目，所以才会自动上全套的抽象和性能优化。但实际业务里，很多时候就是一次性页面，或者内部工具，能跑就行，谁在乎那点重渲染的消耗啊。我现在基本会把prompt里加上一句“保持简单，不要额外抽象，不要优化性能”，再配合一下它生成的代码，把那些用不上的hook和memo手动删掉，反而效率更高。另外我怀疑Cursor的训练数据里高质量代码样本可能都是偏工程化的，所以它“觉得”这样写才专业，但咱们要的其实就是个能交差的活儿。你有没有试过给它限定文件数量或者明确说“所有逻辑都写在这个组件里”？我试过几次，虽然偶尔它会犯倔，但大部分时候能听话不少。

这太真实了，我也有同感。有时候它给的抽象程度简直像在写开源库，明明一个useState就能搞定的事非得套个自定义hook。后来我学乖了，prompt里直接写“不要封装，不要优化，用最直白的方式实现”，效果立竿见影。不过话说回来，它可能也是被训练得太“正确”了，生怕你以后要扩展，结果反而成了负担。

我也有同感，有时候prompt写得挺细了，它还是忍不住往工程化方向卷。后来我试了下在prompt里直接加一句“不要抽象，不要优化，只要最直白的实现”，效果能好不少。另外它可能觉得复杂点显得专业，但业务代码真没那么需要那些花架子。

说明prompt写得还不够“笨”，得直接告诉它“不要封装，不要优化，就写最基础的实现”。

AI的默认值是炫技，你不拦着点它能把整个项目架构都给你重构了。

这题我太有同感了，Cursor好像默认你写的是要上线的企业级项目，不给你塞点memo和自定义hook就浑身难受。后来我发现得在prompt里直接写“不要抽象，不要性能优化，用最直白的useState和useEffect实现”，它才老实点。不过说实话，它这种过度设计有时候也能给点灵感，就是得自己花时间删，反而更累了。你试过给它限定代码行数或者指定只能用某个组件库吗？

这还真是AI写代码的通病，你越把需求描述得“标准”，它就越往工程化最佳实践上靠。我猜是训练数据里高质量项目的占比太高了，导致它默认你也要应付复杂场景，其实很多时候一个页面就活两星期，写那么严谨纯属浪费。我现在都会在prompt末尾加一句“禁止抽象，全部写在该组件文件里，不要拆分函数”，效果立竿见影。另外如果你只是要个能跑的demo，甚至可以故意把需求说得“笨”一点，比如“用最直接的方式，不用考虑复用”。

prompt里直接写死“不要抽hook、别用useCallback”，能好点，但确实心累。

AI这玩意儿就爱炫技，你让它写列表它非给你整出个架构来。

这问题挺典型的，我一般会在prompt里直接加一句“用最直白的写法，别加memo和useCallback，不用抽hook”，效果会好不少。其实它默认往“生产级”方向靠，是因为训练数据里这种模式太多，不代表你项目真需要。我现在的做法是先让它出个最简版，跑通了再按需重构，反而省时间。你要是嫌每次都得说，也可以存个规则文件或者用项目级的指令固定住。

这毛病太常见了，我一般直接在prompt里加一句“别过度设计，能跑就行”，效果还行。