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

我一般会先把项目里最常用的那个基础组件的props定义直接粘进prompt里，再补一句“所有表格优先用这个组件”，这样跑偏概率能小很多。还有你说的角色设定其实挺管用，比如开头写“你是在维护这个中后台项目的资深前端”，后面再给具体需求，AI的默认倾向会明显不一样。另外像分页逻辑这种，我会直接说清楚“状态放父组件，子组件只抛事件”，不然它老爱自己搞个useState进去。

直接把项目里的package.json和组件目录结构贴进Prompt，再指定“基于现有XX组件封装”，比空喊技术栈管用多了。

我之前也踩过这坑，后来学乖了，写Prompt前先把项目里那个自己封装的组件import进来，再附上它几个常用props的示例代码，比贴package.json管用多了。还有“角色设定”确实有效，我会先写一句“你在维护一个xxx项目，请严格复用已有组件”，后面再提需求，跑偏概率小很多。不过你遇到的那个hooks变class的bug我也碰到过，有时候是模型抽风，直接回一句“保持函数组件，不要用class”再生成一次就行。

直接把项目里自定义组件的props定义和一行示例代码贴进prompt，比贴package.json管用多了。

直接把项目里封装的组件路径和props贴进prompt里，再给个“参照现有代码风格”的指令，我试了效果立竿见影。

我也碰到过这种问题，尤其是它默认用antd的时候，明明项目里是自研组件，改起来血压直接拉满。后来我学乖了，写Prompt前会把当前文件里import的组件路径和几个关键props先粘进去，相当于给它一个“上下文锚点”，它跑偏的概率低很多。还有，别只说要什么，得说不要什么，比如“不要用antd的Table，用common里的BaseTable，分页逻辑在hooks/usePagination里”，这种负面约束挺管用的。至于角色设定，我一般会在开头加一句“你是我们团队的前端，熟悉这个中后台项目，组件库在src/components下”，然后它生成的东西确实更贴合一点。但有个疑问想请教下，如果你给了package.json，它会不会因为依赖版本太老反而写出过时语法？我有点担心这个，所以一直没敢贴，不知道你试过没。另外你说的hooks反而生成class，我猜是它没理解“用hooks实现”具体指状态管理还是生命周期，不如直接说“用useState和useEffect管理搜索和分页状态”来得明确。

我之前也踩过这个坑，后来学乖了，每次写Prompt前先把项目里用的UI组件库、还有那个基础Table组件的文件路径直接甩给它，再补一句“别用antd，用@/components/Table”，基本就不跑偏了。角色设定确实有用，你可以试试开头写“你是我项目里的前端同事，熟悉我们的代码规范”，然后贴上package.json和组件结构，它理解上下文的能力会强很多。另外别一次给太全的需求，分两步走，先让它出核心逻辑，再单独调样式和交互，这样改起来反而快。

直接把项目里的package.json和组件目录贴进去，再补一句“只用我项目里已有的组件”，基本能少跑偏一半。

我一般还会在prompt里指定“参照src/components/Table.tsx的写法”，比光说“用hooks”管用多了。

说实话你这个痛点太真实了，我一开始用Cursor也这样，后来发现它其实特别吃“上下文”，但你的上下文得喂得够精准。我现在的习惯是，第一轮Prompt里直接粘项目里那个基础Table组件的props定义，再附上一个最小可运行的使用示例，它基本就不会自作主张去引Antd了。你可以试试把组件结构截图或者核心类型定义贴进去，但别整个package.json，那玩意儿信息太杂，AI反而会抓错重点。关于角色设定，我试过“你是我团队里的资深前端，熟悉我们的内部组件库”，但感觉效果不如直接给代码来得实在。另外你说的hooks变class，我怀疑是关键词冲突，比如你提了“用hooks实现”，但上下文里又有旧代码样例是class，它就会混淆，建议你在Prompt开头就明确写“本项目全部使用函数组件和hooks，禁止出现class组件”。还有个土办法，如果它跑偏了，别急着改，直接把那行错误代码删掉，然后补一句“参照上面给的BaseTable用法重新写”，比反复描述要省事得多。你现在的痛点我太理解了，毕竟中后台项目里样式细节和交互逻辑才是最难让AIget到的，我有时候甚至会把设计稿上的间距、颜色值直接写进Prompt里，这样它生成的就基本能用了。

我一般会把项目里关键的package.json和组件目录结构直接贴进Prompt里，再补一句“所有组件都基于src/components下的基础组件，不要引入新的UI库”，这样能省不少事。另外你提的角色设定挺有用的，我会先写“你是这个项目的资深前端，熟悉我们自研的Table组件”，AI生成的代码贴合度会高很多。还有个小技巧，如果它用了Ant Design，就明确告诉它“我们不用antd，用自带封装的”，几次之后它就记住了。

我跟你情况差不多，一开始也被这个坑过，后来发现Prompt里最关键的其实是“上下文锚点”。你光说“用hooks”没用，它可能压根没读你项目里的代码，你直接把那个基础组件的import路径和props定义甩给它，再告诉它“基于这个组件封装”，效果立刻不一样。我现在写复杂组件前，会先花两分钟把相关文件路径、依赖版本、甚至一段现有的调用示例贴进去，相当于给它画个地图，它跑偏的概率就小多了。

还有个小技巧，就是别让它一次性生成整个组件，先让它输出一个“实现方案清单”，比如分几步、用哪些现有工具函数、状态怎么管理，你确认了逻辑再让它写代码。这样虽然多一轮对话，但省掉后面反复改的时间，算下来更划算。

另外你说的“角色设定”我试过，比如“你是一个熟悉我司中后台规范的前端工程师”，但说实话作用不如直接给代码示例大，模型还是更吃具体证据。你可以试试在Prompt末尾加一句“如果某个交互细节不确定，先按现有代码风格默认处理，并在注释里标出来”，这样至少它不会自作主张去用AntD。

最后想问下，你那个自己封装的Table组件，如果它没找到，是不是因为项目里文件名和组件名对不上？我有次就是吃了这个亏，后来习惯把关键组件的文件结构也贴一段进去。

我试过把项目里的package.json和组件目录结构直接贴进Prompt，确实比光说“用自己封装的组件”管用，但得注意别贴太多，不然它容易抓不住重点。还有个小技巧是先喂一段现有组件的代码，告诉它“照着这个风格写”，比纯文字描述靠谱得多。

另外你说的“角色设定”我也在用，比如先写一句“你是我团队里的前端，熟悉我们内部UI库”，它生成的代码明显更贴项目习惯。不过分页Table这种场景，我建议你干脆把需求拆成两步，先让它写核心逻辑，再单独调样式，反而比一次催它搞定少改几轮。

贴package.json这个思路是对的，但光贴这个还不够，Cursor的上下文窗口有限，你得把“边界”划清楚。我一般会直接告诉它“项目里已经装了antd，但表格必须用src/components/BaseTable，这个组件支持search和pagination参数”，然后顺手把BaseTable的props类型定义贴进去，它基本就不会跑偏了。还有个土办法，就是写Prompt时先加一句“不要引入新依赖，所有样式用less变量”，这样能挡住它自作主张装库。至于角色设定，我试过“你是一个熟悉我们公司中后台规范的前端工程师”，效果有一点，但不如把现有代码里某个相似组件的完整文件丢给它当参考来得直接。另外你提到hooks变class，可能是它理解错了“用hooks实现”的意思，我一般改成“必须用函数组件+useState/useEffect，禁止写class”，把动词换成具体API名，错误率会低很多。最后建议你把“改错成本”也写进去，比如“如果拿不准，就先用最简单的方式实现，然后问我”，这样它能少点自由发挥。

说实话你这个痛点我太懂了，刚开始用Cursor的时候我也老被它那套“自以为是的聪明”搞崩。后来我摸索出来的办法是，别把它当通用AI，得把它当成你团队里那个刚入职的实习生，你得给它划清楚边界。比如写组件前，我一般会先丢一小段现有组件的引用代码进去，顺便告诉它“这个项目里咱们用的是自己封装的XTable，别碰AntD”，这样它基本就不会跑偏了。关于hooks那个问题，我也遇到过，后来我发现光说“用hooks”不够，得加一句“不要用class组件，也不要引用React.Component基类”，类似这种反向排除法特别管用。另外我觉得角色设定确实有用，但别太虚，直接写“你是一个熟悉中后台项目、擅长封装通用组件的前端开发，现在要维护这个项目的表单模块”，比单纯说“你是专家”有效得多。你还可以试试在Prompt末尾加一句“如果技术选型和现有代码冲突，请先问我而不是自作主张”，这能省下不少来回改的时间。对了，你那个分页和搜索的逻辑，是打算自己手写还是也用它生成？我最近在试让AI先画个状态机再写代码，感觉逻辑稳了不少。

贴package.json确实有用，但光贴这个不够，Cursor对项目上下文的理解其实挺依赖你给的信息密度。我之前是把公共组件的props定义直接复制进Prompt里，再附上一个用过的实例代码，它生成的就靠谱多了。还有个偏方，你可以在项目根目录放一个CONVENTIONS.md，里面写清楚“所有表格必须用X组件，禁止直接引AntD Table”，然后在Prompt里加一句“先读CONVENTIONS.md再动手”，效果立竿见影。至于角色设定，我试过“你是一个熟悉我司中后台代码规范的前端”，感觉对风格有微调，但对具体API选型帮助不大，核心还是得把约束条件写死。另外你那个hooks变class的问题，很可能是你上下文里某段旧代码是class的，它照着模仿了，所以我会在Prompt末尾特别强调“保持函数式组件，不要用this”。最后，如果改超过三轮，我直接手动改完再让它学一遍我的改法，反而比继续对话省时间。

直接把项目里的组件路径和关键依赖贴进prompt，再给个“参照现有XX组件风格”的例子，比笼统说“用hooks”管用多了。

可以先喂它一段你封装组件的代码，加一句“所有交互都按这个模式来”，它能少跑偏一大半。

把项目里封装的组件路径和props直接贴进prompt，再指定“不准用antd”，基本能少改一半。

先给AI一个“你是我们组前端”的角色，然后丢一段现有代码当参照，比光说技术栈管用。

直接把项目里封装的组件import路径和props接口贴进prompt，比贴package.json管用多了，我这么干后返工少一半。

试试给它一个“你是我司前端，只能用已有组件库”的角色设定，再给个最小可运行示例当参照，基本能稳住不跑偏。

我之前也踩过这个坑，后来发现关键不是把package.json整个贴进去，而是把你要用的那个基础组件的props接口定义直接粘给AI，比如它接受哪些参数、有没有render props或者ref透传。你光说“用我封装的组件”，它根本不知道你封装了什么，自然就默认AntD了。

另外“用hooks实现”这种指令确实容易翻车，因为Cursor对上下文的理解是碎片化的，你最好直接说“把这个组件改成函数组件，用useState管理分页参数，用useEffect监听搜索条件变化”，具体到函数名和状态字段，它反而不会跑偏。

还有个偏方，我习惯在Prompt开头加一句“当前项目是一个中后台管理系统，基础UI库是XXX，风格偏简洁，不要引入额外依赖”，这算是你说的角色设定吧，但一定要放在最前面，别藏在长描述里，不然AI可能忽略。

再就是分步写，别一次让它生成整个Table，先问它“基于这个接口定义写个表格骨架”，确认结构对了再让它加搜索和分页逻辑，每步给个明确的小目标，改动次数能少一半。我最近这么搞，基本两三次就能定稿了。

直接把项目里的package.json和组件目录结构粘进Prompt，再指定“基于XX组件二次封装”就稳多了。

我一般开头先写“我在xxx项目里，用的是xxx技术栈”，它跑偏概率能降一半。