用AI编程工具写React组件，总是生成重复代码，是我prompt写得不对吗？

说实话这问题我也遇到过，感觉AI对“复用已有组件”这种抽象指令理解得特别差，它更擅长按你给的代码片段或具体路径来生成。我试过在prompt里直接贴Table组件的导入路径和props接口，效果会好不少，另外把“复用”改成“请使用xxx路径下的Table组件，传入以下参数”这种明确指令，AI基本就不会自己重新写了。

这问题我也遇到过，感觉AI对“复用”的理解特别机械，得把已有组件的具体路径、props接口、甚至代码片段喂给它才行。我现在的做法是先手动把Table组件import进来，然后在prompt里直接说“基于这个import的Table，生成搜索和分页逻辑”，效果会好很多。另外Cursor的@符号引用文件功能挺有用的，不妨试试。

我也有同感，这类工具对“复用组件”的理解确实很弱，经常忽略你提到的封装要求。我试过把“复用已有Table组件”改成具体引用组件名和props结构，比如“基于BaseTable实现，只传递columns和dataSource”，效果好一些。另外可以尝试在cursor里用@符号引用相关文件，给它更明确的上下文依赖，比纯文字描述管用。

我也遇到过类似的情况，感觉AI对“复用”这个词的理解确实比较表面，它更倾向于生成完整代码而不是引用已有模块。建议你在prompt里直接把Table组件的路径或者关键props写出来，比如“使用src/components/Table，传入columns和dataSource”，这样它能更明确地执行。另外分页逻辑也可以单独封装成hook，AI反而更擅长生成这种独立的小功能。

把需求拆成小步骤喂给它，比如先定义接口再写逻辑，别指望一步到位。

说实话这问题太典型了，我也踩过同样的坑。AI生成代码时其实更擅长“从零到一”，而不是“在现有体系里做增量”，你让它复用Table组件，它脑子里根本没有你项目里那个组件的具体接口和样式约束，只能按它训练数据里最常见的模板来写。我试过比较有效的办法是，在prompt里直接贴一段那个Table组件的props定义和一行最简单的用法示例，比你说一百遍“复用”都管用。另外把需求拆细一点，别一次让它生成整个带搜索分页的完整组件，先让它生成“分页逻辑”或者“搜索状态管理”这种单个hook，再让它基于这个hook去拼UI，这样重复代码会少很多。还有个土办法，就是你自己先写一个最小的“骨架组件”放在那里，让AI只负责填充你标记出来的TODO部分，它反而更听话。说白了这些工具现在还是更像个“高级自动补全”，指望它理解你的架构设计还不太现实，但把上下文喂得足够具体，它还是能省不少事的。

试试把现有Table组件的代码直接贴进对话里，再让它基于这个写，光说名字它真记不住。

说实话这真不全是你的问题，我拿Copilot写业务组件也这样，它更擅长生成“一次性”的独立代码块，很难主动去识别你项目里已有的抽象。我试过比较有效的一个办法是，在prompt里直接贴一段现有Table组件的用法示例，再让它“参照这个模式生成”，比单纯说“复用”管用得多。另外，把大需求拆成几个小步骤分次生成，比如先让它只写搜索逻辑，再单独提分页，出错率会低不少。你如果试了还是不行，可以换个思路，让它生成基础版本，自己再手动把重复部分抽成公共方法，毕竟工具只是提效的，最后的结构还是得自己把控。

说实话你这个痛点太真实了，我也踩过一模一样的坑。后来琢磨出来一个规律：这些工具对“抽象复用”的理解其实很弱，你让它“复用已有组件”，它脑子里默认的“复用”就是重新生成一份代码，而不是去import你项目里的那个文件。我建议你换个思路，别让它从零生成，而是直接把你现有的Table组件代码贴给它，然后明确说“基于这段代码增加搜索和分页”，这样它反而能给出更贴合你项目的改动。另外，prompt里最好把约束写得更死一点，比如“不要创建新的样式文件，只修改Table.tsx”这种，不然它自由发挥的空间太大。还有个偏门技巧，就是给它看一个你手动写的“标准答案”示例，哪怕只有几行，它模仿的准确率会高很多。总之别指望它理解业务上下文，把它当成一个特别擅长抄作业但不懂设计的新人来看待，你会舒服很多。

说实话你这个情况太典型了，我也踩过同样的坑。Cursor和Copilot在生成独立小函数时确实好用，但一遇到需要复用内部组件的场景，它们就自动“失忆”，因为它们的上下文窗口是基于你当前打开的代码块计算的，你项目里那个Table组件如果不在它视线范围内，它根本不会主动去“翻旧账”。我的经验是，别指望它自己理解“复用”，你得直接把那个Table组件的import路径和核心props结构贴进prompt里，甚至给它看一眼组件的props定义，它才会老实按你的API来写。另外，把需求拆细一点，别一上来就让它生成整个带搜索分页的完整组件，先让它产出数据获取逻辑，再单独生成表格列配置，最后用“套壳”的方式手动组装，这样它的重复率会低很多。说到底，这些工具更像是“高级自动补全”，不是“架构师”，复杂业务封装还是得自己把控骨架，让它填肉。你要是懒，也可以试试在项目里加一个.cursorrules文件，把项目规范写进去，效果会好一截，但别指望它能帮你做抽象决策。

这问题太典型了，其实不是你的prompt不行，而是这些工具对“已有代码”的感知力本来就弱。我试过直接把Table组件的文件路径贴进对话里，效果比光说“复用”好很多。另外建议把需求拆小，别一次让它生成整个页面，先让它写数据获取逻辑，再单独让它调你的组件，这样它反而不会乱塞一堆重复的样式和状态。还有个小技巧，如果它老生成useState，你就在prompt里明确写“只用props传数据，不要内部状态”，指令越具体它越听话。

这问题太真实了，我一开始用Copilot写业务组件也这样，后来发现不是prompt的锅，是工具本身对“上下文”的理解就挺浅的。你让它复用Table组件，它大概率只是扫描了当前文件，根本没去翻你项目里那个Table的props定义，所以只能按它训练数据里的通用模式瞎猜。我现在的做法是，先把Table组件的接口文档或者类型定义直接粘到prompt里，再明确告诉它“基于这个签名生成”，效果会好很多。另外就是别指望一步到位，先让它生成一个粗糙版本，然后你手动改一遍，把改完的代码再喂回去让它学，相当于给它建立项目内的“局部记忆”。还有个野路子，就是故意在prompt里写“不要用任何现成组件，全部手写”，它反而会去参考你代码库里已有的类似实现，因为这时候它更倾向于模仿你项目风格。说到底，复杂业务逻辑还是得自己把控，AI更适合帮你填模板或者处理纯函数部分，别太较劲。

这问题我刚开始用Copilot也遇到过，后来发现它确实更擅长写独立函数，不太会主动去梳理项目里的抽象层级。我的笨办法是把“复用Table组件”改成“从@/components/Table导入，并传columns和dataSource”，就具体到路径和props，它能听话不少。不过复杂业务组件还是得自己搭骨架，让AI只负责填肉，别指望它从零给你设计出高复用结构。

另外，把“不要生成样式”直接写进prompt开头，能省去好多删代码的麻烦。再不行就试试把项目里Table组件的完整代码贴进去当参考，给它“喂”一遍上下文，比干说管用多了。

试试把“复用已有Table组件”换成直接贴出组件路径和关键props，再明确说禁止新建样式，效果会好很多。

AI对“上下文”的理解很弱，你得像带新人一样把规矩列清楚，尤其是“不要做什么”。

说实话这真不全是prompt的锅，Cursor和Copilot对项目上下文的感知其实挺弱的，尤其是跨文件引用组件的时候，它根本记不住你那个Table的props长啥样。我现在的办法是，每次让它写之前，直接把Table组件的核心代码和调用示例贴进对话里，再强调一句“严格按这个接口来”，效果会好很多。另外复杂业务组件别指望一步到位，先让它生成骨架，再一步步追加逻辑，比一次性描述完要靠谱。

这问题太真实了，我一开始用也这样。后来发现关键是别让它直接写整个组件，而是把已有的Table组件路径和props接口贴进prompt里，明确说“基于这个组件封装”，它才能稍微听话点。另外对于复杂业务，AI更适合生成单次性的逻辑片段，真指望它维护抽象层级确实有点难。

说实话你这个情况太典型了，我刚用Copilot那会儿也这样，后来发现问题真不全在prompt上。这些工具本质是“概率预测”，你让它“复用Table组件”，它脑子里可能压根没存你项目里那个组件的具体签名，所以只能按最通用的写法来。我试过比较有效的办法是，在prompt里直接贴一段现有Table组件的调用代码，或者把相关的props类型定义也带进去，它才会“哦，原来你说的是这个”。另外，像这种复杂业务组件，我一般会让它先只生成数据逻辑部分，UI结构自己手写几行，再让它补全，反而比一次性生成整块要干净。还有个小技巧，把项目里的组件文档或者类型声明文件放到它能读取的目录下，有时候比prompt里说一万句都管用。你要是实在觉得它写重复了，也可以试试分两步走，第一步让它列出实现步骤，第二步再让它按步骤写，这样它上下文保持得会好一些。

说实话我也遇到过这情况，后来发现光靠prompt描述不够，得在项目里建个.cursorrules或者把组件文件直接拖进对话里引用，AI才能真的“看见”现有代码。另外别让它一次生成整个组件，拆成“先写表格列配置”再“套用Table组件”这种小步骤，指令越具体它越不容易放飞自我。至于分页逻辑，干脆自己写个自定义hook，让AI只填业务部分，省得它每次给你造新的轮子。

这问题太真实了，我也踩过同样的坑。后来发现光在prompt里说“复用”没用，得直接把现有Table组件的import路径和关键props贴给它，它才会老实点。另外这种复杂业务组件最好拆成小步骤让它一步步改，一次生成整个文件它肯定会自由发挥。

把公共逻辑抽成自定义hook再喂给AI当参考，比单纯说“复用”好用得多。

直接贴出你项目里Table组件的props定义，它才会照着写，不然就是瞎编。