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

这问题太真实了，我也踩过同样的坑。其实AI对“复用已有组件”的理解很表面，它不会主动去翻你的项目结构，你光说“复用”它大概率就当没看见。我现在的做法是直接把Table组件的import路径和关键props粘贴进prompt里，明确告诉它“只能使用这个组件，不要自己写样式”。另外，复杂业务组件确实不适合让AI一步到位，我通常先让它生成骨架，再手动把重复逻辑抽成hooks，它反而能给点启发。

这问题太真实了，AI对项目上下文的理解确实有限，试试把现有组件的props和代码片段直接贴给它。

其实把需求拆细点，一次只让它改一个功能，比让它一口气生成整个组件靠谱得多。

这问题我太有同感了，之前用Copilot写个列表页也这样，我后来发现光在prompt里说要复用它根本记不住，得直接把现有Table组件的代码片段贴进去，再让它基于这个改。另外你把需求拆小一点，别指望它一次生成整个页面，而是让它先写数据获取逻辑或者分页那一小块，生成的重复代码会少很多。还有就是试试在注释里用中文写清楚“不要重复造轮子”，有时候比对话指令管用，但确实复杂业务还是别太指望它，半自动吧。

试试把现有Table组件的代码直接贴进prompt里，再告诉它“只改这几处”，比单纯说复用管用多了。

说实话这问题我太有同感了，刚用Cursor那会儿我也被气得不轻。后来我琢磨出个规律，这类工具对“上下文”的理解其实特别表面，它只认你当前文件里有什么，你口头说“复用已有Table组件”它根本不会主动去翻项目结构，你得把那个组件的路径和props接口直接贴在prompt里，甚至把组件的使用示例代码给它一段，它才勉强明白。另外我发现，与其让它从头生成整个业务组件，不如把任务拆成“先帮我写个搜索框的状态管理”这种小步骤，一步步引导，它反而能产出更贴合现有代码风格的东西。不过说真的，对于封装复杂业务逻辑，这些工具目前更像是个高级的代码补全器，你脑子里得有清晰的实现蓝图，它只是帮你省掉打字的时间，指望它替你思考架构还是不太现实。你可以试试在prompt里明确加上“严格参考项目中已有组件，不要新增样式和状态”，有时候加这句“不要xxx”比“要xxx”更管用，虽然也不是每次都灵。

这情况太常见了，问题还真不全在prompt上。Cursor和Copilot对项目上下文的感知其实挺有限，你口头说“复用Table组件”，但它可能压根没把那个组件的代码读进上下文里，自然就自己发挥了。我现在的做法是直接把要复用的组件文件路径或者关键代码片段粘到prompt里，然后明确告诉它“基于这份代码扩展，不要新建逻辑”，效果会好很多。另外复杂业务组件我一般让它分步骤来，先让它生成数据结构，再让它写交互，最后再套样式，一步到位反而容易让它胡来。你也可以试试在项目里加个.cursorrules文件，把封装规范写进去，比每次打prompt管用。

说实话这真不是你prompt的问题，这类工具对“复用组件”的理解很浅，它更擅长从零生成而不是基于现有代码库做增量修改。我试过把组件文件直接拖进对话里或者用@引用具体路径，让它先读一遍再改，效果会好不少。另外可以试试把需求拆得更碎，比如先让它只生成表格部分，再单独提分页逻辑，别指望一次搞定一个完整业务块。你要是摸透了它的脾气，就会发现它适合当个快速草稿机，真要精细化还是得自己动手改。

这问题太真实了，我一开始用Copilot写业务组件也这样。后来发现它不是忽略上下文，而是太依赖你当前文件里的代码风格，你最好把那个Table组件的props和用法直接贴在prompt里，或者干脆把组件文件打开让它先读一遍。另外这种复杂封装我一般会让它先写个骨架，再一步步让它填充细节，一次性要求太多它就会自己硬造一套逻辑。

这还真不全是prompt的锅，Cursor和Copilot对“复用”的理解比较表面，它更擅长单文件生成而不是跨文件找依赖。我试过把Table组件的路径和核心props直接贴进prompt里，稍微好点，但复杂业务还是得自己搭骨架。你可以试试在对话里先让它列个实现计划，确认了再写代码，能省不少返工。另外，把重复逻辑抽成自定义hook，它反而更容易识别和复用。

这问题我刚开始用的时候也撞过，后来发现光说“复用”不行，得把Table组件名和它的props结构直接甩给它，比如“用现有src/components/Table，传入columns和dataSource那种”。另外给它看一两段你项目里的真实代码当few-shot示例，比描述半天管用多了。复杂业务组件建议拆成几个小任务一步步生成，让它一次搞定整块逻辑确实容易放飞自我。

说实话你这问题我太有同感了，刚用的时候我也被气到过。后来发现关键不是prompt写多长，而是得把“复用”这个东西拆成具体指令，比如直接告诉它“只改数据请求部分，UI别动”或者“调用项目里的X组件，参数按这个类型传”。另外你得把目标组件文件路径贴进去，或者干脆先把那段引用代码复制到对话里，它才认账。

说实话你这情况太常见了，我刚开始用Copilot写业务组件的时候也这样，后来发现真不是prompt写得不对，是这些工具对“复用”的理解特别死板。它们更擅长从零生成一个完整东西，而不是去理解你项目里已有的Table组件长啥样、props怎么传，所以每次都会按训练数据里的“通用模板”来写，结果就是一堆重复的useState和样式。我现在的做法是，先把现有Table组件的关键代码片段直接粘到prompt里，告诉它“基于这个组件，只补充搜索逻辑”，这样它才可能收敛一点。另外，像分页这种逻辑，我干脆自己写个自定义hook，让AI只负责生成hook内部的状态和副作用，而不是整个组件，效果会好很多。还有个野路子，就是故意在prompt里加一句“不要写任何样式，不要重复定义状态”，有时候反而能逼它走捷径。但说真的，指望AI完全理解复杂业务上下文目前还不太现实，它更适合干那种“一次性、独立、边界清晰”的活儿，复杂封装还是自己动手吧。

这问题我遇到过，真不全是prompt的锅。你让AI“复用已有组件”，它其实看不到你项目里的Table长啥样，只能按通用模板硬写，所以重复代码很正常。我的经验是直接把那个组件的props和关键代码片段贴进prompt里，再明确说“只改数据逻辑，样式和结构别动”，效果会好很多。另外可以试试让它先写一个“骨架版本”，再一步步加功能，比一次性生成完整组件更可控。

试试把项目里的Table组件路径直接写进prompt，再附一段现有调用代码当范例，比单纯说“复用”管用得多。

说实话这问题我太有共鸣了，刚用Copilot那会儿我也被它那股“自作主张”的劲儿搞到崩溃。后来我发现关键不在prompt写得多详细，而是你得先把项目结构喂给它，比如在对话开头贴一下Table组件的props定义和现有用法，它才会真的“看见”上下文，不然它就默认按通用模板瞎编。

还有个野路子是，别让它一口气写整个组件，你拆成“先写搜索逻辑”再“单独写分页状态”，每步都明确说“不要碰样式”，它反而更听话。另外像那种重复的useState，我试过在prompt里加一句“如果已有类似状态就直接复用，别新建”，效果会好不少，但偶尔还是会犯轴。

不过说真的，这类工具对“封装”的理解确实很弱，它擅长的是生成独立小函数，不是理解你项目里的抽象层级。你要是真需要复杂业务组件，不如让它生成基础骨架，自己动手把重复部分抽成自定义hook，反而比跟它较劲省时间。

我倒是好奇你用的哪个模型版本？我更新到最新版后感觉上下文感知好了点，但偶尔还是会抽风，可能跟代码库大小也有关系。

这太正常了，cursor对项目上下文的感知其实很弱，尤其你这种“复用”指令，它根本没法像人一样去翻你整个代码库找组件。我一般会直接把Table组件的import路径和关键props贴进prompt里，甚至把那个组件代码复制一段给它看，它才会老实点。另外建议别让它一次性生成完整页面，拆成“先写表格列配置”再“写分页逻辑”这种小步骤，控制力会强很多，你可以试试。

试试把现有Table组件的文件路径直接贴进prompt，再补一句“严格按这个组件的props来写”，效果会好很多。

说实话这真不全是prompt的锅，我刚开始用也这样。工具对“上下文”的理解很浅，你嘴上说复用Table组件，但它根本没法像人一样记住你项目里那个组件的具体props和样式，所以不如直接把组件文件路径或者关键代码片段丢给它当参考。另外建议把需求拆小一点，别一次性让它生成整个带搜索分页的页面，先让它写一个纯表格，再一步步加逻辑，成功率会高很多。

说实话这问题我太有同感了，刚用Copilot那会儿我也被它气得不轻，后来发现根本原因不在prompt写得对不对，而是工具对“既有代码结构”的理解本来就有限。你让它复用Table组件，但它看到的只是你当前文件里的局部上下文，除非你明确把组件路径、props接口甚至关键代码片段直接贴进prompt里，否则它基本靠猜。我现在的做法是，要么把需求拆成特别小的原子任务，比如先只生成表格列的配置数组，再单独让它写分页逻辑，要么就在prompt里直接附上Table组件的props类型定义，这样它生成的东西至少能直接跑通。还有个野路子是，故意在prompt里写“参考项目里已有的admin/Table.tsx的写法”，然后手动把那个文件路径加进来，有时候效果比抽象描述强很多。不过说真的，这种复杂业务组件你指望它一步到位不太现实，我一般让它产出骨架，自己再花几分钟改改样式和状态管理，反而比反复调教它省时间。另外你可以试试在Cursor里用@符号引用具体文件，这个功能比纯文字描述上下文可靠得多。

说实话我一开始也遇到这个问题，后来发现关键不在于prompt多详细，而是得先把你那个Table组件的内容直接贴进对话里，或者用@引用让它看到源码，不然它真不知道你指的是哪个。另外可以试试让它先写伪代码或者列个步骤，确认逻辑后再生成完整代码，这样它会更按你的思路走。至于复杂业务组件，我自己的感受是它更适合搭骨架，细节逻辑还是得自己调，别太指望一步到位。