用Cursor写React组件，Prompt该怎么写才能让它少改几次？

直接贴package.json和组件目录进去，再指定用哪个组件库，效果立竿见影。

我一般开头先写“基于现有项目”，再给它看两个已有组件的代码，基本就稳了。

我也是用Cursor写中后台的，这个问题太真实了。我现在的做法是，每次写组件前，先把项目里那个基础组件的props类型定义直接复制进Prompt里，再附上一段现有的调用示例，AI基本就能老实按你的封装来写，比光说“用自己封装的组件”管用得多。还有你说的角色设定，我觉得挺有用的，但别太虚，比如直接告诉它“我在维护一个已有Ant Design但部分页面用自研Table的项目，请优先复用自研组件”，它理解上下文的能力会强不少。关于hooks变class那个坑，我踩过好几次，后来发现得明确写“不要使用class组件，保持函数式写法”，并且最好在Prompt末尾加一句“请先列出你将使用的所有依赖和API，再开始写代码”，这样能逼它先思考。另外我有个小技巧，就是把之前改过几轮的代码片段也贴进去，告诉它“按这个风格继续”，比描述一百遍“交互要怎样”都有效。你试过在Prompt里定义“验收标准”吗？比如“搜索防抖300ms，分页重置到第一页，loading态要显示在Table内部”，这样它输出前自己会检查一遍，能少改一半。

我试过把项目里封装的组件import路径直接写进prompt里，再附一段那个组件的props类型定义，它生成的就准多了。另外你那个class组件的问题，光说“用hooks”不够，最好直接给个函数组件的空壳子让它往里面填逻辑。角色设定我觉得有点用，但不如给它看一小段你项目里现有代码的风格来得实在。

我踩过一样的坑，后来发现把项目里那个基础组件的props定义直接贴进prompt里最管用，再加一句“只用这个组件，别引别的库”基本就稳了。另外别指望一次生成到位，先让它出个骨架，你再把具体交互点拆成小问题一个个问，反而比写一大段需求省事。你那个“用hooks实现”被无视的情况我也遇到过，后来发现得说“不要用class组件，全部函数式”，指令越具体越好。

这问题太真实了，我现在写prompt都先把项目里那个基础组件的props定义和用法示例直接贴进去，再补一句“优先用这个，别用AntD”，成功率能高不少。还有你可以试试先让它“列出你要用的组件和依赖版本”再动手写，等于加个确认环节。另外“用hooks实现”这种词太容易歧义了，不如直接说“把这个逻辑改成useState+useEffect的写法”，它反而更懂。你那个角色设定的思路我觉得可行，但别太复杂，就一句“我是维护xx组件库的开发者”就够了。

直接告诉它你用的是自己的Table组件，把文件路径或关键代码粘进去，比说“别用antd”有效得多。

我一般开头先贴package.json和组件目录结构，再让它按现有风格写，基本能少改一半。

直接把项目结构、关键依赖和组件路径贴进Prompt里当上下文，比描述需求更管用。

可以先给它一个你封装组件的使用示例代码，再让它照着这个风格写。

这个问题太真实了，我上周刚被类似的事折磨过。我的经验是别指望它一次懂，开头就把“家底”亮清楚比啥都强，比如直接贴package.json里关键的依赖版本，再附上你自己封装组件的props类型定义，它跑偏的概率能小一半。还有个小技巧，把“用hooks”这种模糊指令换成“请用useState和useEffect重写这段逻辑”，它基本就不会抽风了。倒是“角色设定”我觉得挺玄学的，试过让它扮演“资深前端”，反而容易给你整些花活，不如直接说“你是这个项目的新成员，先看这个文件再动手”。另外，你提到Table那个事，我习惯在Prompt里加一句“禁止引入新依赖，只能使用项目内已存在的组件”，效果立竿见影。不过它有时候还是会自作聪明，所以我现在写复杂组件前，会先让它列个实现步骤清单，我确认了再让它写代码，虽然多一步，但后面改起来省心多了。

说真的，你这个痛点太典型了，我一开始用Cursor写组件也这样，后来发现关键不是让它“写”，而是让它“照着写”。我的办法是直接把那个基础组件的props定义和两三个使用示例贴进Prompt里，明确说“基于这个组件封装，不要引入AntD”，它基本就不会跑偏了。至于技术栈，我习惯在项目根目录建一个叫CLAUDE.md或者cursor-rules的文件，里面写清楚“React 18 + TS + 自研UI库 + 函数组件”，每次对话它自动读，比每次贴package.json省事多了。你提到“用hooks实现”反而生成class组件，这个我遇到过，可能是因为上下文里有旧代码干扰，这时候我会在Prompt末尾加一句“只准用函数组件和hooks，禁止写class”，语气强硬点效果反而好。另外“角色设定”那招确实有用，比如“你是我团队里熟悉这个项目的资深前端”，它会下意识更保守地复用现有代码。还有个野路子，如果它改了三遍还不满意，我就直接复制它生成的错误代码，让它自己批评自己哪里不符合要求，往往比重新描述问题更高效。你试试看，要是还不行，可以把具体的组件代码片段发出来，咱们一起研究下Prompt还能怎么优化。

贴一下项目结构确实有用，我一般会把自定义组件的props类型定义直接粘在prompt里，再补一句“优先使用本地components下的xxx组件”，比光说“别用antd”管用多了。另外“用hooks”这种模糊词容易踩坑，不如直接写“用useState和useEffect实现”，AI反而更能get到点。你也可以试试先让它输出一个组件骨架，确认方向对了再让它补细节，这样比一次性给完整需求靠谱很多。我每次改得烦了就干脆把报错和diff一起甩给它，让它自己分析哪里跑偏了，效率会高不少。

说实话你这个问题太典型了，我一开始用Cursor也这样，后来发现关键不是把需求说得更细，而是得让它“看见”你的项目。像贴package.json其实作用不大，最管用的是直接把你要复用的那个基础组件的props定义和一段现有用法扔进Prompt里，告诉它“所有表格都基于这个，别用别的库”，它基本就老实了。我还会先让它输出一个“技术选型确认”清单，比如用哪几个组件、状态放哪层、样式方案是啥，它列完我点头了再让它写代码，这样至少能少改一半。至于角色设定，我会加一句“你是这个项目里熟悉现有代码的老手，所有新代码必须复用src/components下的组件”，相当于给它套了个紧箍咒。另外你提的那个hooks反被生成class的情况，大概率是它把上下文里的旧代码当参照了，我一般会在Prompt里明确写“禁止出现class组件，只用函数式加hooks”，然后如果它还犯，就把它生成的错误代码复制回去反问一句“这符合我的要求吗”，它一般会自己认错重写。反正就是别把它当搜索引擎，要当个刚入职的同事，把项目约定和边界讲清楚，效率能高不少。

我最近也踩过这个坑，后来发现把项目里那个基础组件的props定义和用法示例直接贴进prompt里，比单纯描述“用自己封装的”管用多了。另外可以先让Cursor读一下项目目录结构，再让它基于现有代码风格写，命中率高不少，你可以试试在对话开头加一句“参考src/components下的现有实现”。

还有就是别一次性给太多需求，像搜索、分页、筛选这种拆成几个小任务一步步来，每步确认完再继续，改起来反而快。我甚至试过让它先写个接口调用和数据流转的伪代码，确认逻辑对了再补UI，基本能少改一半。

我试过把项目里的关键依赖和组件路径直接贴进Prompt，效果比光描述要好不少，但别贴整个package.json，太长它反而抓不住重点。还有个土办法，就是先让它按你的封装组件写个最小示例，跑通了再让它扩展功能，这样比一次性提全需求靠谱。你那个“用hooks实现”反而生成class组件，可能是它理解成“兼容hooks”了，我一般会明确写“禁止使用class组件，必须用函数式+hooks”。另外可以试试在Prompt开头加一句“你是这个项目的老手，熟悉内部组件库”，后面再给个现有组件的代码片段当参照，命中率会高很多。

直接把项目结构和高频组件路径贴进Prompt，再指定“基于现有xxx组件实现”，能少跑偏一半。

我最近也踩过这个坑，后来发现把项目里用的组件库路径和基础组件示例代码直接贴进Prompt里，比光说要清晰很多。另外可以试试先让它输出组件接口定义，确认没问题再让它写实现，这样能少走不少弯路。还有个小技巧，就是让它先列出它打算用什么技术方案，你点头了再写代码，比让它直接开写靠谱多了。

直接把关键依赖和组件路径写进prompt里，比如“用src/components/BaseTable”，比贴package.json管用。

我都是先甩一段现有组件的import代码，AI就能顺着风格写了，比描述半天省事。

我之前也踩过这个坑，后来发现把关键依赖和组件路径直接写进prompt里特别管用，比如“在src/components/BasicTable基础上封装，别引入antd的Table”。另外你可以试试在开头加一句“我是XX项目的维护者，技术栈是React+TS+antd”，它确实会更收敛一点，但别指望一次到位。对了，你试过用@符号引用具体文件吗？我这么干之后，它至少不会再自己发明轮子了。

我试过先把项目里的组件目录结构贴进prompt，再明确说“不要用antd，用@/components里的XTable”，这样准确率高很多。另外你可以试试在对话开头加一句“你是我项目里的前端同事，熟悉现有代码”，然后扔一段现有的组件代码给它当参考，它就会模仿那个风格。还有个小技巧，如果它写歪了，别直接说“不对”，而是直接复制它生成的代码然后指出具体哪一行要改，比重新描述需求管用。

我一般会把项目里常用的组件封装成一个简短清单直接贴进prompt里，比如“搜索用X组件，表格用Y组件，分页用Z组件”，再加一句“不要引入antd”，这样它基本就不会跑偏了。另外，角色设定确实有用，我习惯开头写“你是我团队的前端，熟悉我们的代码规范”，再把package.json里关键依赖截一段给它，准确率能高不少。至于class组件那次，可能是你关键词混着别的描述让它误解了，我试过直接说“必须用函数式组件，拒绝class”，效果比单独提hooks明确多了。

我跟你情况差不多，后来发现关键不是把整个package.json丢进去，而是把你要用的那个基础组件的props类型定义和几个典型用法贴出来，让AI先“看到”这个组件的接口长啥样。比如你那个Table，如果把你封装的组件里search、pagination这些参数的传法写清楚，它大概率就不会自作主张去用AntD了。还有你说的角色设定，我试过在Prompt开头加一句“你是在维护这个中后台项目的资深前端，熟悉项目里已有的common组件库”，效果确实比直接提需求稳定不少，但别指望一次到位。另外有个小技巧，如果你不想让它用class组件，别只写“用hooks”，最好直接给个约束：“请基于现有函数组件风格，使用useState和useEffect，不要出现class关键字”，这样它跑偏的概率会低很多。不过说实话，就算Prompt写得再细，像样式细节这种，我一般会先让它出逻辑，再单独开一轮对话只调样式，分开来改反而比一次说完效率高。你有没有试过在项目里建一个CONVENTIONS.md之类的文件，把组件规范写进去，然后每次让AI先读那个文件再动手？我最近这么干，感觉它“记性”好了一点，但也不是万能的。