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

这问题我太有同感了，刚开始用Copilot写业务组件时也这样，后来发现它确实不太会主动“读”你整个项目上下文，更像是在按当前文件里的模式猜。建议你试试把复用组件的import语句和关键props直接粘在prompt里，或者先手动写个最小调用示例再让它补全，比纯文字描述管用得多。另外，像表格这种复杂封装，我一般让它生成纯逻辑部分，样式和结构自己写，毕竟AI擅长的是把重复劳动做快，而不是做架构决策。

你试试把已有Table组件的代码片段直接贴进prompt里，再明确说“只改数据逻辑”，效果会好很多。

你这问题我遇到过，核心是AI对“复用”理解太浅，得把组件路径和具体props直接甩给它，光说“已有的”它真记不住。

其实这玩意儿更适合写无状态的小函数，复杂业务还是得人肉搭骨架，别太指望它chain of thought。

说实话这问题我太有共鸣了，AI写简单页面还行，一碰业务组件就爱自嗨，把Table的columns和render逻辑全硬编码进去。我觉得关键不是prompt多花哨，而是你得先把现有组件的接口、props类型、甚至一两个用法示例直接贴给它，让它“看着抄”而不是“凭记忆写”。

另外我发现，把需求拆成“先改数据结构，再改渲染逻辑”这种小步骤，一步步喂给它，比一次性让它生成整个功能要靠谱得多，不然它确实容易忽略上下文。你也可以试试在对话里明确说“不要生成新组件，只修改我给的这段代码”，有时候就是得反复强调，跟AI沟通确实得有点耐心。

这个我太有同感了，刚开始用Copilot的时候也是被它这种“自嗨式”生成整得头疼。后来我发现这其实不完全是prompt的问题，而是这些工具默认就是按“从零生成完整代码”的逻辑跑的，你让它复用组件，它脑子里没那个组件长什么样，只能自己瞎编一套逻辑进去。我现在的做法是先把已有的Table组件接口贴进prompt里，甚至直接给一小段调用示例，然后明确告诉它“只生成数据逻辑和props传递，不要写任何样式和子组件”。另外有个小技巧，把需求拆成两步，第一步让它生成纯函数或者hooks，第二步再让它接UI，这样比直接丢个大需求进去可控得多。其实这种工具写一次性页面或者简单列表确实快，但真要搞复杂业务组件，还是得靠人工把边界划清楚，不然它就是在用重复代码掩盖它对业务理解不足的事实。

这情况太常见了，不是你的prompt有问题，是这些工具对“复用”的理解比较肤浅，你光说“复用已有Table组件”它抓不住重点。我一般会直接把组件文件路径贴进上下文，或者在prompt里写清楚“不要新增样式，只调用src/components/Table.tsx里的Table”，这样准确率能高不少。另外复杂业务组件建议拆成几步生成，先让它搭骨架再往里填逻辑，一步到位它就容易放飞自我。

这情况我也遇到过，复杂业务组件还是得自己搭骨架，AI只适合填肉，别指望它理解你的上下文。

试试把Table组件的props接口直接贴进prompt里，再给个具体例子，比说“复用”管用多了。

这问题太真实了，我刚开始用Copilot写业务组件也这样，后来发现真不全是prompt的锅。你越是描述“复用已有组件”，它反而越倾向于把完整代码都给你生成出来，因为模型根本没能力去读你项目里那个Table组件的props和内部实现，它只能根据通用模式猜。我的做法是，干脆不在prompt里提“复用”，而是直接告诉它“组件结构参照项目里的xxx.tsx，但只生成数据逻辑部分”，然后把那个文件的路径或者一小段关键代码片段贴进去，这样它反而会收敛很多。另外，对于分页和搜索这种高频逻辑，我后来都自己写了个自定义hook，然后在prompt里明确说“调用useTableData这个hook，不要重复定义state和effect”，效果立竿见影。说白了，这类工具擅长的是“从零写完整功能”，不擅长“在现有代码上做增量修改”，你得主动帮它划定边界，把它当成一个需要你喂上下文的实习生，而不是一个能理解你整个项目的协作者。

这题我熟，刚踩完坑。问题大概率不在prompt，而是AI对“复用”的理解是“把代码复制一遍”，它没有项目全局概念，尤其Cursor这种，得靠@文件或者把Table组件的路径直接贴给它才行。另外试试把需求拆小，别让它一口气生成完整表格，先让它只负责数据逻辑，样式和渲染层自己写，AI在局部修改上听话多了。还有个野路子，在prompt里加一句“不要重复定义已有类型”，有时候能少抽风几次，但别抱太大期望。

说实话这问题我太有同感了，刚上手Copilot那会儿也总被它这股“自作主张”的劲儿整得没脾气。后来我发现，不是prompt写得不对，而是AI天然倾向于生成“完整且自洽”的代码，它默认你给的上下文就是全部需求，根本没能力去项目里翻你那个Table组件的具体props。我现在的做法是，在prompt里直接贴出那个组件的关键签名或者几行用法示例，然后再加一句类似“只返回数据逻辑和onChange处理，不要写任何JSX”这种负向约束，效果立竿见影。另外，分页和搜索这种状态管理，与其让它猜，不如你先把useState和useEffect的骨架写出来，让它只填空，这样它就不会重复发明轮子了。说到底，这类工具更适合做“从1到10”的补充，不太擅长“从0到1”的架构判断，你得把边界给它画死。

说实话这问题我也踩过坑，AI对“复用”的理解往往停留在字面，你得把Table组件的props和用法直接贴进prompt里，它才会照着写，光说名字真没啥用。另外这种复杂业务组件别指望一次生成，我一般让它先出骨架，再一步步改逻辑，比来回重写省心多了。你要是实在烦了，可以把常用的分页、搜索逻辑抽成自定义hook，每次让它直接调用，能少不少重复劳动。

说实话这问题我太有同感了，刚用Cursor那会儿也天天跟它较劲。你发现没有，AI对“复用”的理解特别表面，你说复用Table组件，它可能只记住了“表格”这个关键词，压根没去翻你项目里那个Table的长啥样。后来我试了个土办法，直接把现有Table组件的import路径和核心props贴在prompt里，比如“用@/components/Table，接受columns和dataSource”，它立马就老实多了。另外一个坑是，像分页这种逻辑，AI默认会给你塞一整套useState和handleChange，但其实你项目里可能已经有现成的hooks了，所以最好明确告诉它“不要自己写状态，用useTableQuery这个hook”。我个人感觉这些工具更适合写一次性UI或工具函数，真要封装业务组件，你得把它当新同事带，每一步约束得死死的。对了，你可以试试在Cursor里用@符号引用具体文件，让它先“看”一遍再动手，效果比纯文字描述好不少。

说实话这情况太常见了，问题大概率不在prompt上，而是这些工具本身对“已有组件”的理解就很弱。你试下把Table组件的props类型定义直接贴进对话里，再明确说“只接收data和columns”，它就不会自己发挥了。另外我习惯在生成前加一句“不要写样式，不要创建新状态”，然后让它先输出结构再迭代，比一次性给完整需求靠谱得多。你再试试把项目里的组件文件拖进上下文，效果会好不少。

这问题我太有同感了，刚用Cursor那会儿也差点被它气死。其实真不全是prompt的锅，这类工具对“复用已有组件”的理解很表面，它看到的是你项目里Table标签的字符串，但没法像人一样理解你封装的props和业务边界。我后来学乖了，干脆把现有Table组件的核心代码片段直接粘进对话里，再明确说“只改数据源和列配置，其他别动”，效果立刻不一样。另外有个小技巧，就是给AI限定“只输出组件骨架，样式全用className引用”，它能少发挥很多。但说实话，复杂业务组件我还是倾向自己写逻辑，AI用来生成纯展示的子组件或重复的表单校验代码，效率翻倍。你要是让它一步到位生成带查询、分页、状态同步的完整业务块，它大概率会给你造出一堆自嗨的冗余代码，这跟prompt写得好不好关系真不大。

AI生成器本质是“新写”不是“重构”，你得把组件路径直接贴在代码块里，再强调“只改这处逻辑”。

这情况太常见了，我也踩过类似的坑。你光说“复用已有组件”不够，得把组件路径和关键props直接贴进prompt里，比如“从@/components/Table引入，用columns、dataSource这些接口”，它才可能去查上下文。另外这类工具对单文件生成还行，跨文件重构确实容易犯傻，建议你把它当高级自动补全用，别指望它理解整个项目架构。我现在都是先手写一个带注释的骨架，再让它填逻辑，效率反而高很多。

这问题太真实了，我也踩过一样的坑。其实不是prompt写得不对，是这些工具对"复用已有组件"的理解就是会把代码补全得特别完整，尤其是Table这种带状态管理的，它默认给你一套能跑的方案。我后来是把公共逻辑抽成自定义hook，然后在prompt里直接贴hook的签名和关键props，它就老实多了。另外建议把"不要生成样式"这种负面指令写成"只返回JSX，不带className"，效果会好很多。

这问题太真实了，我也是被重复代码搞烦了，后来直接把公共组件路径写死在prompt里才稍微好点。

试试把现有代码片段直接贴进去，光说“复用”它真get不到，得喂给它看才行。

这很正常，AI写复杂业务组件确实容易跑偏，建议把现有Table组件的props和用法直接贴给它，比光说“复用”管用多了。

这问题太真实了，我刚开始用Copilot写业务组件也这德行。后来发现光说“复用”没用，得把Table组件的props和用法直接贴在prompt里，或者干脆把文件路径甩给它，让AI先读一遍再动手。

另外像这种封装逻辑，我一般会让它先写个最基础的骨架，把useState和useEffect的职责用注释标清楚，再一步步往里填，别指望一步到位。工具本身对“上下文”的理解其实挺肤浅的，你当它是个记性不好的实习生，得把关键信息塞到它嘴边才行。

对了，你试试在写需求前先夸它一句“你之前写的那个分页逻辑很棒，这次也保持同样风格”，有时候玄学比逻辑管用。