用Cursor写React组件，为什么Prompt越详细代码反而越烂？

我也遇到过，感觉不是bug，是模型在长上下文里容易“过度解读”。你把JSON结构一贴，它就觉得得帮你做数据缓存、状态同步，反而堆了一堆没用的抽象。我现在的做法是分两步：先让它出最简结构，跑通后再单独提需求加逻辑，比一口气喂一堆细节靠谱多了。

我也这样，细节给太多它反而想太多，简单点它才抓得住重点。

我也遇到过，感觉是上下文一长，模型就开始自己脑补架构，总觉得你给的细节不够，非得多加点东西才安心。后来我干脆分两步，先让它出个最简版骨架，再针对具体文件补细节，反而稳很多。长prompt里塞太多约束，它容易顾此失彼，JSON结构那种其实放单独文件里让它读更靠谱。项目赶的话，核心逻辑自己写，AI拿来写测试和样板代码确实更省心。

我也这样，细节给太多它反而加戏，简单说需求出来的代码干净多了。

我也这样，越写越细它越爱加戏，简单点反而稳。现在只丢核心逻辑给它，其他自己来。

我也碰到过，感觉不是Cursor的bug，是长prompt里细节太多，模型反而抓不住重点，就开始自己脑补。我现在都是先让它出个简单骨架，再分步补细节，比一次性塞一堆需求靠谱多了。你那个表格的例子就很典型，约束越少它越按套路走，反而干净。项目赶的话核心逻辑还是自己写吧，AI适合干重复性的活。

细节太多AI容易过度设计，简单指令反而让它抓重点。我现在只给核心需求，剩下的让它自己发挥。

这个现象我也踩过坑，而且不止Cursor，Claude和Copilot都有类似毛病。你给的需求越细，模型越容易把你描述的每一个点都当成“必须显式实现的指令”，于是它开始过度设计，把简单状态拆成多个useState，给每个回调套useCallback，生怕漏掉你提到的任何一个细节。但你说“写个表格带筛选”，它反而会走训练数据里最常见的简洁范式，因为约束少，模型能自己找最省力的路径。我后来总结出来的经验是，Prompt里只给边界和验收标准，不给实现路径，比如“数据来自这个接口，需要本地筛选，不要引入额外状态库”，这样模型就不会瞎发挥。至于长上下文bug，我觉得不完全是，更多是注意力被稀释了，你贴的JSON结构越详细，它越容易把数据形状和UI逻辑混在一起想。现在我写复杂组件都是先让AI出骨架，再手动补细节，核心逻辑确实不敢全交出去。

我也遇到过这种情况，感觉不是你的写法有问题，而是模型在长上下文里容易“过度解读”。你给的细节越多，它越倾向于把每个信息都当成必须实现的约束，于是就开始加useMemo、抽自定义hook、搞context，生怕漏了什么。其实很多细节你只是描述背景，它却当成了硬性需求。我后来学乖了，分两步走：先让它出个最简结构，跑通了再针对具体问题补prompt，比如“这个表格筛选后不需要缓存，去掉useMemo”。短prompt干净是因为模型没有那么多“责任”要扛，反而能抓住主干。另外JSON结构贴进去确实容易触发它做数据层抽象，除非你明确说“不要做任何状态管理，数据直接props传入”。项目赶的时候别硬刚核心逻辑，用它写工具函数和UI骨架，复杂状态自己来，效率反而更高。