用Cursor写React组件，它老给我生成“最佳实践”但项目跑不动，咋整？

prompt里直接加一句“别用任何优化API，保持代码简单”，它立马老实。AI吃这套。

说实话我也踩过这坑，后来发现得在prompt里先写清楚“项目当前阶段”和“不要过度优化”，不然它默认按大厂标准来。hook报错多半是它自作主张改了依赖顺序，把生成代码贴回来让它看着报错信息改，比直接说“简化”管用。另外建议让它先给方案框架，确认逻辑后再补全，别一上来就生成整块组件，不然调试起来更费劲。

这问题太真实了，AI生成的代码看着高大上，跑起来全是坑，建议把项目背景和约束写进prompt里。

说实话你这个问题我太有同感了，上周我也被它整得差点砸键盘。它那个“企业级最佳实践”就是个免责声明，你让它简化它反而更来劲，跟复读机似的。我后来发现，别跟它聊“优化”，直接甩给它你报错的那段控制台日志，然后命令它“别加useCallback和memo，保持现在这个逻辑，只修hook顺序”。另外，prompt里你得明确写“项目初期，优先可读性，禁止任何性能优化”，它才会老实点。还有，别让它一口气写整个组件，拆成小函数让它一步步补，出错能定位到具体哪一行。至于类型体操，我直接跟它说“用any，但注释写明原因，等我后期再补”，不然它能把一个表单组件写成数学论文。你试试把上下文里贴一段你的package.json版本，有时候是它默认生成的依赖跟你项目里antd版本冲突了。最后，别指望它是架构师，就当个手快的码农，代码必须自己过一遍再跑。

说实话这情况太正常了，Cursor对中小型项目容易“用力过猛”，它训练数据里企业级代码太多，默认就往复杂了写。你可以在prompt里直接加一句“保持简单实现，禁止useCallback/memo/useRef除非必要”，然后让它先跑通再说。还有那个hook报错，多半是它把条件判断放在hook前面了，你让它先检查hooks顺序，别急着优化。我一般遇到这种就直接把报错贴回去，让它自己修，比重新生成靠谱。另外复杂业务逻辑我建议你拆成小函数喂给它，一次别让它看太多上下文，不然容易放飞自我。

说实话你这情况太典型了，Cursor本质是个话痨型选手，你越给它发挥空间它越来劲。我试过直接把需求拆成“这个组件只需要A和B两个props，内部状态用useState，不需要任何优化”，它立马老实多了。另外你那个hook报错大概率是它把条件判断里的hook挪了位置，这种问题你直接甩报错日志给它看，比说一百句“简化点”都管用。还有，别指望它一次生成就完全能跑，我一般让它先出个能用的版本，再让它针对某个具体函数优化，分步来反而效率高。至于“企业级最佳实践”这种鬼话，你直接回它“这个项目用不上，给我删了”，它真会删，别惯着。我猜你刚上手还在跟它磨合期，多试几次就知道它其实就是个高级补全工具，别当架构师用。

这问题太典型了，Cursor本质是拿大厂代码库喂出来的，默认就往“可扩展性”上卷，根本不管你的项目阶段。我建议你在prompt里直接写死“不要使用useCallback/memo/useRef，用最朴素的写法，优先保证可读性”，它其实挺吃这套的。另外hook报错八成是它自己把逻辑顺序搞乱了，别硬改，直接让它重写整个组件，比一步步纠错快得多。

这锅得让prompt背一半。你得在需求里直接写“别用memo和useCallback，优先保证能跑”，不然它默认按大型项目标准来。另外hook报错八成是它把逻辑拆得太碎导致依赖顺序乱了，建议让它把相关逻辑聚合成一个自定义hook，别散着写。我一般会先让它出个最小可用版本，再手动优化，AI写的代码当参考可以，直接上线还是得自己过一遍。

你prompt里直接让它别用memo和useCallback，它就不敢瞎加了，这玩意儿得调教。

说实话你这个情况太典型了，AI生成的“最佳实践”有时候就是拿模板硬套，根本不管你项目上下文。hook调用顺序报错多半是它把逻辑拆得太碎，或者用了条件hook，这种代码连review都费劲。

我自己的经验是，别让它直接写整个组件，而是给它限定一个非常具体的输入输出，比如“用AntD的Table实现带分页和筛选的列表，不要加memo和useCallback”。它要是还加，你就直接说“删掉所有优化，保持代码可读性优先”。

还有个土办法，你可以在prompt里加一句“代码风格参照现有项目，不要引入新依赖或高阶模式”，一般能压住它。说到底，AI是辅助，你才是最终拍板的人，跑不通的“最佳实践”就是垃圾代码，直接让它改到能跑为止。

这问题我太懂了，AI最容易把简单需求硬套上复杂模式。你直接跟它说“保持现有依赖，不要引入额外hooks，按最小改动实现”，它会老实很多。另外hook报错八成是它生成的组件里条件语句包了hook，你让它逐段重写比全局改靠谱。别迷信最佳实践，能跑通再优化不迟。

说实话我也踩过这个坑，后来发现关键是把“最佳实践”关掉或者写清楚“不要优化，只要能跑”。你可以在prompt里直接说“保持简单，不要用memo和useCallback”，它一般会听话的。至于hook报错，大概率是它生成的组件里条件渲染了hook，你让它把逻辑重构成单一出口就行。这工具写点样板代码还行，复杂业务还是得自己把控，别全信它。

你这个情况我太懂了，Cursor对中小型项目就是容易用力过猛，它脑子里全是大型团队的代码规范。hook报错八成是它把条件判断和hook混在一起写了，你直接让它“只保留必要逻辑，删掉所有性能优化”试试，别跟它客气。另外建议把项目依赖版本贴给它，有时候它生成的是新版API，跟你本地装的antd版本对不上。复杂业务还是自己搭骨架，让它填肉比较靠谱，别指望一步到位。

说实话你这问题我太懂了，cursor就这德行，你越让它“优化”它越来劲，一堆memo和useCallback全是自我感动。我后来干脆在prompt里直接写“不要用任何性能优化API，保持代码简单，优先保证能跑”，效果立竿见影。还有那个hook报错，八成是它把条件判断放在了hook前面，这种基础错误它偶尔会犯，你直接截图报错给它看，让它自己修，比你说一百遍都管用。

prompt里直接写“不要优化，能跑就行”，多试几次比跟它辩论省心多了。

说实话你这情况太典型了，我一开始用Cursor也被它那套“最佳实践”坑过。它训练数据里塞满了大型项目的高大上解法，但根本不管你项目实际处在哪个阶段。你让它写业务组件，它默认你是个要维护十年的大型系统，useCallback、memo这些全给你堆上，结果你自己都还没理清楚状态流，它先给你把依赖关系整复杂了，hook顺序报错基本都是它自作聪明地改你的自定义hook导致的。

我的经验是，prompt里得直接写死约束，比如“不要用memo和useCallback，除非有性能测试证明需要”，“保持props扁平化，禁止类型体操”，甚至直接告诉它“这是个小项目，按最简单的写法来”。另外，它报错白屏的时候，别让它自己修，让它把报错信息原封不动贴给你，你手动改比它瞎猜靠谱。

还有一点，别让它一次生成整个组件，你拆成几个小函数让它逐个写，每一步都跑一下验证。这工具本质是个高级补全器，不是架构师，你得当它是个特别会写代码但没常识的实习生，命令得下细。最后，实在不行就关掉它的自动修复功能，只用来生成纯UI部分，业务逻辑自己写，这样能省一半的折腾时间。

说实话这体验我太懂了，AI生成那套模板看着唬人，但对实际项目就是过度设计。你可以试试把“不要用useCallback和memo，保持代码可读性优先”直接写进系统提示词里，或者干脆把报错信息和最小复现代码丢给它，让它先修运行问题。另外别太迷信它的“最佳实践”，自己公司项目的技术栈和阶段只有你最清楚，工具只是辅助，跑通比好看重要。

直接把项目背景和约束贴给它，让它别整花活，我都是开头写死“禁止useMemo/useCallback，保持简单”。

这情况太真实了，AI生成的“最佳实践”很多时候就是堆料，根本没考虑你项目的实际状态。你那个hook报错大概率是它把条件判断和hook混在一起写了，这种低级错误它自己根本察觉不到。我建议你prompt里直接加一句“不要使用useMemo/useCallback/memo，保持代码最小可用”，效果立竿见影。另外别指望它一步到位，把它当个高级补全工具用，核心逻辑自己把控，它只负责填样板代码，这样能省不少折腾时间。

你prompt里直接写“别用memo和useCallback，简洁优先”，它一般就会听话，别跟它聊最佳实践。