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

这问题太真实了，我一开始用Copilot也这样。其实不是prompt写得不对，是工具对“复用”的理解太表面，它压根没把项目里已有的Table组件当成上下文，只是按通用模板生成。我后来发现，直接在prompt里贴出那个组件的文件名和关键props，甚至把import语句写出来，它反而能收敛很多。另外复杂业务组件建议还是拆成小函数一步步喂给它，一次让它干一件事，比让它一口气封装完靠谱。

这问题大概率不是prompt的锅，是工具对项目上下文感知有限，你把组件拆细点、给个明确示例它才不乱来。

大概率是你没把现有Table组件的代码直接贴进上下文，AI看不到就默认自己造轮子。下次把组件文件内容带上，再明确说“只改逻辑别动样式”。

说实话这真不怪你，我一开始也这样。Cursor这类的工具对“复用”的理解很表面，它更擅长从零生成，而不是去识别你项目里已有的组件。我的经验是别让它猜，直接把Table组件的props和关键代码段粘进prompt里，再明确说“只写调用逻辑，别动样式”。另外也可以试试给它一个反面例子，告诉它“不要生成类似的重复结构”，比单纯说“复用”有效得多。

说实话这还真不全是prompt的锅，我也遇到过这情况，尤其是Copilot，它更擅长补全局部代码，对“复用已有组件”这种全局约束经常直接无视。你可以试试把Table组件的props接口和典型用法直接贴进prompt里，别只说名字，把它当成上下文的一部分喂给它。另外，复杂业务组件建议先让AI生成结构骨架，再手动把重复部分抽成hook或者子组件，这比让它一步到位靠谱多了。

建议把项目里的Table组件路径和用法直接贴进prompt里，别只说复用，AI真记不住上下文。

问题不在表述，是这类工具对“已有组件”的识别很弱，试着把组件代码片段粘进去当参考。

这情况太真实了，我也踩过坑。其实问题不在于prompt写得好不好，而是这些工具对“复用”的理解就是直接贴代码，你得把已有的组件路径和关键props直接甩给它，比如“import {Table} from '@/components'，然后只生成数据逻辑和列配置”，它才能老实点。另外建议把需求拆成两步，先让它生成一个纯函数处理分页和搜索，再让它套进Table里，成功率会高很多。复杂业务组件还是得自己搭骨架，AI负责填细节，不然改它的重复代码更头疼。

这问题我太有同感了，刚用Cursor那会儿也这样，后来发现真不是prompt写得不对，是这些工具对“上下文”的理解特别浅，你以为它记住了整个项目，其实它只盯着你当前打开的那几个文件。你那句“复用已有的Table组件”，它可能压根没去翻你那个组件长啥样，直接在生成代码里自己又造了一个轮子，所以才会出现一堆重复的useState和useEffect。

我现在的做法是，要么把目标组件的完整代码直接粘到对话里，明确告诉它“基于这段代码改，别新增逻辑”，要么就把需求拆得特别碎，比如只让它生成表格的列配置，分页逻辑我自己写。还有个比较野的路子，你可以试试在项目的根目录放一个CLAUDE.md或者.cursorrules文件，把常用的组件规范、禁止重复定义这些规则写进去，它会优先参考这个，比你在prompt里吼一嗓子管用得多。

不过说实话，这种工具用来写一次性页面或者样式模板是真快，但真要搞那种需要严格遵循现有架构的复杂业务组件，它目前确实容易“犯迷糊”。你可以试试让它先生成一个基础骨架，然后你手动把关键部分改掉，把它当成一个高级的代码补全器，而不是全自动的同事，这样心态会好很多。

这问题太真实了，AI写业务组件就爱自嗨，恨不得把整个表格都给你重写一遍。试试把组件名和props接口直接写进prompt里，约束力会强很多。

这问题太真实了，我也踩过同样的坑。后来发现不是prompt写得不对，而是工具压根没把你项目里的Table组件索引进上下文，你得在对话里明确“参考src/components/Table.tsx里的实现”或者直接贴一段现有代码让它照着写。另外，这种AI更适合生成一次性代码块，真要封装复用逻辑，不如让它先列出组件拆分的思路，你手动搭好骨架再让它填肉。

这还真不全是prompt的锅，AI工具对“复用”的理解比较浅，它更擅长从零生成完整代码，而不是主动去匹配你项目里已有的抽象。我之前也踩过坑，后来发现直接把Table组件的props和用法贴进prompt里，再加一句“严格使用这个接口”，效果会好很多。另外，对于复杂业务组件，与其让它一口气生成，不如拆成几个小函数一步步来引导，这样上下文不会丢。

说实话你这个情况太典型了，我刚开始用Copilot的时候也这样，后来发现真不是prompt写得不够好，是这些工具对“复用”的理解跟咱不一样。它们倾向于生成完整自包含的代码，因为这样在训练数据里最“安全”，你让它引用外部组件，它反而容易犹豫。

我现在的做法是，先把现有Table组件的props和用法直接粘进prompt里，明确说“基于这个接口生成”，而不是只说“复用已有的”。另外，把需求拆得更碎一点，比如先让它只写搜索逻辑，再单独生成分页，最后让它组装，这样比一次性提大需求靠谱得多。

还有个土办法，就是给AI看一个你手动写的“理想输出”片段，哪怕只写几行，它就能模仿那个风格和结构，比纯文字描述管用十倍。不过说真的，复杂业务组件我觉得还是自己搭骨架更稳，AI更适合填肉，比如生成表格列配置、表单校验规则这种重复但逻辑简单的部分。

你试试把需求拆成“生成表格列的配置数组”和“封装一个usePagination的hook”这种小任务，成功率会高很多。工具这玩意儿，就得顺着它们的脾气来，硬掰是掰不过来的。

这问题太真实了，我也踩过同样的坑。后来发现光在prompt里说“复用”没用，得把现有Table组件的props和用法直接贴给它，让它照着那个接口写，不然它根本不知道你已有的东西长啥样。另外，复杂业务组件建议拆成小步骤生成，先让它写数据获取逻辑，再单独生成UI部分，比一次性让它出整块代码靠谱得多。

还有就是别指望它完全记住上下文，每次对话前把关键约束再强调一遍，比如“用我项目里的xxx组件，不接受内联样式”，这样成功率能高不少。工具终归是工具，它擅长写骨架，业务封装还得自己动手改。

这还真不全是prompt的锅，Cursor和Copilot对“复用”的理解挺死板的，你不给具体路径和props类型，它大概率就自己发挥写一套新的。我试过在项目里建一个.cursorrules文件，把Table组件的API和典型用法写进去，生成质量会好很多。另外别让它一步到位，先让它输出业务逻辑骨架，再单独让它补UI细节，拆成两步走会听话一点。

说实话这真不全是prompt的锅，我也踩过这坑。Cursor这类的工具对“复用组件”的理解很表面，它更多是顺着你给的最近代码往下接，不会主动去翻你项目里已有的Table封装。我试过把Table组件的props和用法直接粘到对话里，再让它基于这个写，效果会好很多，但复杂业务逻辑还是得自己拆成小函数去引导它一步步生成。

另外你可以试试在prompt里写“不要生成样式，只输出逻辑”，或者干脆把重复代码抽成子组件再喂给它。这玩意儿就是个高级补全插件，别指望它真懂架构，我写多了现在都把它当打字机用了。

这问题太真实了，我也被折腾过。你光说“复用现有的Table组件”不够，得把组件路径、props接口甚至具体代码片段都甩给它，不然它根本不知道你项目里长啥样。另外，这类工具对长上下文的理解确实有限，建议把需求拆成小步骤，先让它生成一个纯逻辑的hook，再单独让它写渲染部分，比一次性怼个大需求靠谱得多。我现在基本把Copilot当高级代码补全用，复杂组件还是自己搭骨架，让它填肉。

说实话这真不全是prompt的锅，我试过在Cursor里把现有Table组件的文件路径直接拖进对话，再明确说“基于这个文件封装”，它还是会偶尔抽风给你写一套新的。后来我索性把公共组件抽成单独的代码片段（snippet），遇到重复生成就直接手动改，省心不少。

另外你试试把需求拆得更碎一点，比如先让它只生成表格的列配置，再让它单独处理分页逻辑，别指望一步到位。工具对“复用”的理解确实很弱，哪怕你给出具体函数名，它也可能因为上下文窗口限制而忽略。我现在基本把它当高级自动补全用，复杂业务逻辑还是自己搭框架，它填肉。

说实话你这情况太正常了，AI写业务组件本来就容易陷入“从零生成”的惯性，尤其是你让它“复用Table组件”这种指令，它可能压根没识别出你是想让它引用项目里的某个文件，反而理解成“写个带Table样式的组件”。我建议你直接把Table组件的文件路径和关键props贴进prompt里，或者用Cursor的代码库索引功能让它先扫一遍项目结构，比单纯用文字描述管用得多。另外，真碰上复杂封装逻辑，别指望它一次到位，让它先列个实现步骤再逐段生成，比逼它一口气写完靠谱。

另外我试过把通用逻辑抽成自定义hook再喂给它，效果会好一点，但说到底这工具还是适合写胶水代码和模板，真要动脑子设计抽象还是得自己来。你试试把需求拆小一点，比如先让它只负责搜索逻辑，再单独管分页，最后手动拼起来，这样它反而没那么容易跑偏。

试试在prompt里直接贴上现有Table组件的导入路径和关键props，AI对显式代码的遵从度比描述高得多。

把需求拆成“只生成数据获取逻辑”这种小任务，别让它一口气干完所有事，重复代码能少一半。

这问题不在prompt，AI对“复用”的理解很表面，得把组件路径和props直接贴给它。另外试试把现有Table代码塞进上下文，它就会照着写了。