用Cursor写React组件，prompt怎么组织才能让它一次生成靠谱代码？

我觉得你这个问题很多用Cursor的人都会遇到，核心可能不在于“一次讲完”还是“分步骤”，而在于给它一个可参照的“骨架”。我会先把组件拆成状态、UI结构、事件处理三块，像写技术验收单一样把每个字段的必填/可空、分页边界条件和空态文案写清楚，甚至直接贴一个mock数据的示例，这样它生成时不容易自由发挥。另外我发现让Cursor先输出一个带TODO注释的伪代码框架，再让它逐段填实现，比一口气要完整代码稳定很多，因为它能顺着上下文自己补逻辑，也不容易遗漏loading。你可以试试在prompt末尾加一句“请确保处理了加载失败和列表为空的场景”，这种明确提醒比泛泛说“要完善”有效。

我都是把交互细节拆成清单喂给它，再补一句“没写loading和空状态就重写”，成功率能高不少。

先让它搭骨架再填肉，比一口气全塞给它靠谱，不然它老自作主张漏逻辑。

我一般把交互细节拆成两步问，先出结构和状态，再补边界逻辑，比一次说全好用很多。

我自己的经验是别一口气全塞给它，先让它把组件结构搭出来，你确认了骨架再让它补逻辑，这样出错率低很多。另外prompt里最好直接写死状态怎么处理，比如“空数据时显示xx文案，加载中显示spinner”，不然它默认就给你省了。你还可以试试让它先列一个实现清单再写代码，相当于让它自己先规划一遍，出来的东西靠谱不少。

别指望一口气描述完就能出完美代码，我一般先让Cursor把组件骨架和props定义出来，确认结构没问题再让它补搜索、分页这些逻辑。关键是把状态流转说清楚，比如loading什么时候true什么时候false，空状态在哪个条件下展示。另外可以给它一个你写过的类似组件当参考，比纯文字描述管用多了。

我一般不会一上来就让它写完整组件，而是先让它把props和state列出来，确认接口对了再往下走。像表格这种，我会先把列定义、数据来源、分页是前端切还是后端请求这些说清楚，不然后面它自己猜就容易跑偏。你说的漏空状态和loading，其实可以在prompt里直接写成验收条件，比如“必须包含loading骨架、空数据提示、请求失败重试”，它就会当成硬性要求去补。分步骤确实更稳，但也不用太碎，先结构后逻辑两轮基本够用，中间记得把上一轮的代码贴回去让它增量改，别重新开新对话。还有个挺关键的，Cursor里最好把项目里已有的同类组件或工具函数@进去，它照着现有风格写，比口头描述十句都管用。

分步骤让它先出结构再补逻辑会靠谱很多，我一般先让它列组件骨架和状态，确认没问题再让它填具体逻辑。像表格这种一定要在prompt里点明空状态、loading、分页边界这些，不然它默认只写happy path。还有个偷懒的办法，先丢个类似组件让它模仿，比纯文字描述稳多了。

我之前也踩过这坑，后来发现关键是别一次性把整个组件丢给它。我一般先让它只出组件骨架和props定义，确认结构对了再逐步补搜索、分页这些逻辑，最后单独让它加loading和空状态。这样虽然多轮几次，但返工少很多。还有个技巧是把“边界情况”直接写进prompt里，比如“数据为空时显示Empty组件，加载中显示Skeleton”，它就不会漏了。

我一般先让它出组件骨架，再分步补搜索、分页和空状态，一口气全塞容易漏。

我之前也踩过这坑，后来发现关键是别一次把啥都塞进去，先让它出个骨架，确认字段和结构对了再补分页、搜索这些交互逻辑，改起来反而快。空状态和loading这种细节可以在补逻辑那一步单独强调，或者直接说“参考antd的Table写法”，它一般就不会漏。全堆一段里描述，它容易顾此失彼。

我一般会先让Cursor把组件骨架和props定义出来，确认结构没问题再让它补具体逻辑，这样比一口气全说完稳很多。像表格这种交互组件，空状态和loading我会直接在prompt里列成必须包含的检查项，不然它默认不写。另外给它一两个你项目里现成的组件当参考，生成风格会统一不少，改起来也省事。

我一般会先让Cursor把组件拆成UI和逻辑两层，UI部分用伪代码描述清楚结构和状态，比如loading、空数据、搜索栏、分页这些都要点名。逻辑部分再单独让它实现数据请求和分页交互，别一次性全塞进去。另外prompt里最好带个简短的数据结构例子，不然它很容易自己瞎编字段名。多试几次你会发现，越像写技术方案那样写prompt，它出的代码越稳。

写得挺好，建议补充一些性能数据。

有没有更详细的教程推荐？