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

这事儿我也踩过坑，其实不是你prompt写得不对，是这类工具对“上下文”的理解特别表面，它只知道你当前文件里写了啥，很难真正懂你项目里那个Table组件的接口。我试过把组件路径和关键props直接贴进prompt里，再明确说“只改逻辑，模板和样式照抄现有代码”，效果会好不少。另外，用Cursor的“@”引用具体文件，比单纯说“复用已有组件”有用得多，Copilot的话就得靠你手动把那段代码先贴出来。反正复杂业务组件别指望它一步到位，当个高级补全工具用，心态就稳了。

试试把现有Table组件的文件路径直接贴进prompt里，再给个具体例子，它就老实多了。

这情况太常见了，别指望它读心，把“复用”改成“参考@/components/Table.tsx的写法”效果立竿见影。

这问题太真实了，AI对“复用”的理解就是照抄模板，不如直接把Table组件的文件路径和关键props喂给它。

说实话这问题我踩过不少坑，后来发现关键不是prompt写多详细，而是得先把项目里的Table组件路径和props定义贴给它，最好再附上现有代码片段当参考，不然它确实容易按通用模板瞎写。另外我试过在对话里明确说“不要生成样式，只返回逻辑部分”，效果比单纯说“复用”要好很多，你可以试试把需求拆成更小的子任务分步生成，别让它一口气搞个完整组件。

把通用逻辑抽到自定义hook里，prompt里直接引用hook名，AI就会少写很多重复代码。

试试先给它一个写好的示例组件，再让它“参考这个模式”改，比纯描述管用。

说实话这情况太常见了，我也踩过同样的坑。其实不完全是prompt的锅，Cursor和Copilot这类工具对“已有组件”的感知能力很弱，它们更擅长从零生成独立逻辑，而不是在既有代码库里做增量修改。我试过把Table组件的文件路径直接贴进prompt，甚至把组件代码片段粘进去，效果依然不稳定，经常是“假装”在复用，实际还是按自己的模板来。后来我发现一个稍微靠谱点的办法：在prompt里明确写“不要生成任何样式，不要创建新组件，只输出数据逻辑”，同时把目标组件的关键props列出来，比如columns、dataSource、loading这些，让它像填空一样补全。但说实话，如果业务封装比较复杂，我最后还是手动写核心部分，让AI只处理表格列配置或分页计算这种零碎活。另外你提到的重复useState和useEffect，我觉得是它训练数据里这类模板太固定了，你可以试试在注释里写“使用自定义hook useTableData”，它有时会顺着hook名字去推断逻辑，虽然不一定对，但至少比硬刚有效。反正别指望它一步到位，把它当个聪明点的自动补全工具，心态会好很多。

其实不全是prompt的锅，这类工具对“复用”的理解很表面，它更擅长生成独立代码而不是理解项目里已有的封装。你可以试试在prompt里直接贴上Table组件的props接口，或者给个简短的调用示例，比光说“复用”管用得多。另外，把大需求拆成小步骤一步步引导，让它先渲染表格再单独加搜索，出错率会低很多。

这问题太典型了，我刚开始用Copilot的时候也撞过这堵墙。说白了，AI不是没看上下文，而是它默认你会给它一个“完整的新文件”场景，所以习惯性把能写的都写全，尤其是像表格这种它觉得“缺了就跑不起来”的部分，反而忽略了复用逻辑。你可以试试把现有Table组件的props接口直接贴在prompt里，明确告诉它“只生成数据转换和状态管理，渲染交给Table”，比单纯说“复用”有效得多。另外，别指望它在复杂业务上一步到位，我现在的习惯是让它生成骨架，然后自己手动把重复部分抽成hooks或高阶组件，再拿这个结果去喂给下一个prompt，相当于给它一个“正确范例”去模仿。还有个土办法，如果你发现它总生成固定模式，就在代码库里放一个专门给AI看的REFERENCE.md，里面写清楚哪些场景必须复用哪些组件。说到底，这些工具还是更擅长“从零生成”而不是“增量修改”，你得多给它设限制条件，比如“不要生成样式”“不要生成useEffect”这种负面指令，反而比正面要求更管用。

这问题太真实了，我刚开始用Copilot写业务组件时也这样，后来发现核心不是prompt怎么写，而是工具对“上下文”的理解方式跟咱们想的不一样。它其实更像一个“超级补全器”，你给它的信息越多、越结构化，它才越可能复用已有的东西。比如你光说“复用已有Table组件”不够，最好直接把那个组件的props类型定义、或者一两个使用示例贴到prompt里，甚至用注释把关键文件路径标出来。另外，我建议把大任务拆小，让它先只生成数据获取逻辑，再单独生成表格列配置，最后写分页状态，每一步都基于上一步的代码来推进，这样它就不容易“自由发挥”了。还有个土办法，就是写一个自定义指令文件，比如在项目里放个AGENTS.md，把“必须优先引用Table组件，禁止重复定义样式”这类规则写进去，Cursor会读这个文件的，实测比聊天里反复强调管用。至于封装复杂业务组件，说实话现阶段这些工具更适合写一次性代码或者样板代码，真要抽公共逻辑，还是得自己动手，不然维护成本反而更高。

试试把项目里Table组件的文件路径直接贴进prompt，再加一句“严格参照这个文件的写法”，效果会好很多。

这问题太真实了，我也踩过一样的坑。后来发现别让AI直接生成整个组件，而是先给它看一遍现有Table组件的用法示例，再让它基于这个模式改，效果会好很多。另外把需求拆细一点，比如先让它做搜索逻辑，再单独弄分页，别一口气全塞给它，它一贪多就容易放飞自我。

这问题我太有感触了，AI写组件确实容易“自嗨”式地整一堆重复代码。你试试在prompt里把“复用”改成“不要写任何样式和状态逻辑，只生成调用现有Table的JSX结构”，同时把已有的Table组件代码直接粘贴给它看，它没上下文就全靠猜。另外这种封装性强的业务组件，我建议你手动写好一个模板，让AI基于模板改数据，而不是让它从零生成，效果会稳定很多。

说实话这问题我也踩过坑，AI对“复用”的理解特别表面，它可能压根没把你的项目结构读进去。我后来是把Table的props类型和常见用法直接贴在prompt里，再补一句“只写数据获取和分页逻辑，别碰UI”，效果会好很多。另外你试试让Cursor先读一下你的组件文件再生成，别让它凭空发挥，它能记住的上下文比你想的少多了。

试试把项目里的Table组件路径直接贴进prompt，再给个具体使用示例，它就老实多了。

这问题太真实了，AI对“复用组件”的理解基本就是瞎猜，不如直接把组件代码贴进prompt里让它照着改。

试试把现有Table组件的代码直接贴进对话里，再明确说“只改数据逻辑，别动样式和结构”，效果会好很多。

AI对“复用”的理解很表面，你得给它具体参照物，不然它只会按通用模板硬写。

说实话这问题我太有共鸣了，刚开始用Copilot写业务组件时也天天被它这种“自嗨式”生成整崩溃。后来我发现问题还真不全在prompt上，这类工具本质是概率模型，它更擅长顺着你当前文件的代码风格补全，而不是理解“复用某个抽象组件”这种全局设计意图。我试过最有效的办法是先把Table组件import进来，然后在注释里写清楚“基于这个Table封装，只处理数据获取和分页逻辑”，再让它填空式生成，而不是给一大段需求让它自由发挥。另外把相关props类型定义好也很关键，模型看到明确的接口约束，反而比自然语言更容易“闭嘴”。不过说实话，真要封装复杂的业务组件，我现在还是手写为主，最多让它生成样板代码，不然重构的时间比省下来的时间还多。你试试把需求拆小点、多给示例，别指望它一口气干完，效果会好不少。

这问题我太有同感了，刚开始用Copilot写业务代码的时候也差点被绕进去。后来我发现这类工具本质上是“基于统计的补全器”，它更擅长按你当前文件里已有的模式往下写，而不是真的理解你项目里那个Table组件的封装边界。你光在prompt里说“复用”，它脑子里没概念，与其指望它“听话”，不如先手动把import和Table的props接口写出来，再让它只补数据逻辑部分，这样它的注意力会被限制住。另外，像分页、搜索这种通用逻辑，我一般会先自己写好一个自定义hook，比如useTableQuery，然后让AI直接调用这个hook，效果会好很多——你给它一个“工作流锚点”，它就不会自由发挥了。还有个土办法，把项目里其他组件已经用这个Table的代码片段直接贴几行到prompt里作为few-shot示例，它模仿起来比听你描述准确多了。至于重复生成useState和useEffect，多半是因为它没有足够上下文判断状态归属，你可以在当前文件顶部把相关的类型定义和已有状态都写上，它就会倾向于复用而不是新建。说到底，这些工具适合当“快速打字员”，不适合当“架构师”，复杂业务还是得自己定好骨架，再让AI去填肉。

AI写业务组件确实容易瞎编，你得把现有Table的props和代码片段直接贴进prompt里当上下文，光说“复用”它理解不了。

试试分步骤拆需求，先让它生成数据逻辑，再单独处理UI，比一次性要求强多了。

这问题太真实了，其实不是prompt的锅，工具对上下文的理解本来就有限，给它喂个示例代码比说十句都管用。

简单点说，直接把你那个Table组件的props和用法贴进去，再让它改，效果立竿见影。