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

这问题太真实了，我刚开始用Copilot写业务组件时也这样，后来发现核心不在prompt多详细，而是AI压根没把你项目里的现有组件当“上下文”看。它默认你给它一个需求，它就从零生成最完整的代码，不管你是不是想复用。一个比较管用的招是把目标组件的props接口和关键代码片段直接粘进prompt，明确说“基于以下Table组件封装”，再给个使用示例，它才会照着写。另外，封装复杂业务组件这种事，AI其实更适合当“代码生成器”而不是“架构师”，你让它生成单次渲染的逻辑它很擅长，但让它自己判断怎么抽象复用，它就会陷入重复。我建议你先手动把表格的基础骨架搭好，只让AI填具体的列定义和搜索逻辑，这样能省很多事。还有个技巧是给AI看项目里其他类似组件的写法，比如把另一个已经封装好的列表组件贴给它，说“模仿这个风格写”，效果会好不少。说到底，这类工具对上下文的理解还停留在“你给的这一段”，你指望它记住整个项目的依赖关系，目前还是有点难。

这问题太真实了，AI写业务组件确实容易“自嗨”，让它先读现有代码再动手会好很多。

试试把相关组件代码直接贴进对话里，光说“复用”它真记不住。

说实话这不完全是你的问题，AI工具对“已有组件”的理解很表面，它更擅长生成独立代码而不是遵守隐式约定。我一般会在prompt里把组件props和接口直接贴给它，再明确说“只改body部分，别动其他逻辑”，效果会好一些。另外这种复杂业务封装，建议你先把骨架搭好，让它只填关键函数，不然它确实容易放飞自我。

这问题太真实了，我也踩过同样的坑。其实不全是prompt的锅，这类工具对“复用”的理解比较浅，你光说“复用已有的Table组件”它根本定位不到具体代码。我现在的做法是直接把那个Table组件的文件路径或者核心代码片段贴进上下文里，再明确说“基于这个组件改”，效果会好很多。另外复杂业务组件我建议拆成几个小步骤让它逐步生成，别指望一步到位，基本能避开重复代码的毛病。

说实话你这情况太典型了，我刚开始用Copilot写业务组件也这样，它默认就给你塞一堆完整实现，根本不管你项目里有没有现成的Table。后来我发现问题不在prompt写得好不好，而是这些工具对“复用已有组件”这种抽象指令理解得很弱，它们更擅长的是“从零生成”而不是“基于现有代码修改”。
我现在的做法是，先把项目里Table组件的props和用法直接贴进prompt里，明确说“只生成数据处理的逻辑，渲染部分调用这段代码”，效果会好很多。另外，如果你把table组件文件本身也加入上下文（比如在Cursor里用@引用），它就能更精准地模仿你的写法。
还有个土办法，就是先让它生成一版，然后你手动把重复代码抽成hook或子组件，再让它基于这个新结构生成，它就会学着你改。
说到底，这类工具目前更像个快速原型机，真要封装复杂业务，还是得自己把控架构，别指望它一次到位。

这问题太真实了，我刚开始用Copilot写业务组件时也这样，后来发现核心不是prompt写得多花哨，而是得把“复用”这个指令拆成它理解的细节。比如光说“复用已有的Table组件”，它根本不知道你那个组件的props长啥样，你不如直接把Table的接口签名或者一个使用示例粘进prompt里，它照着例子写反而靠谱。另外这类工具对长上下文的记忆确实有限，你项目里的公共组件它大概率没索引到，所以写复杂逻辑时我习惯先手动把骨架搭好，只让它填具体函数体，不然它自己发挥起来就是一场灾难。还有个土办法，把你要封装的逻辑拆成几个小函数逐个生成，再自己拼起来，比让它一口气生成一个完整组件成功率高得多。说到底它们更像高级自动补全，离“理解业务”还差得远，别太指望一次调教就听话。

这问题太真实了，我也踩过同样的坑。AI对“复用已有组件”的理解是很表面的，它更擅长根据你给的prompt“从零生成”，而不是去翻你项目里到底有哪些现成封装。我现在的做法是直接把那个Table组件的核心props和代码片段贴进去，再明确说“只改数据逻辑，样式结构别动”，效果会好很多。另外，像分页和搜索这种状态管理，其实很适合单独抽成一个自定义hook，让AI只负责hook内部逻辑，反而能避开它重复生成样板代码的毛病。

这问题太真实了，工具确实不太擅长复用抽象，得把组件路径和props直接贴进prompt里才管用。

试试把现有Table组件的代码片段直接丢给它，再强调“只改数据逻辑别动样式”，效果能好不少。

说实话这真不全是你的问题，AI生成业务组件本来就容易“自嗨”，尤其面对抽象逻辑时，它更倾向给你一个能跑但不优雅的完整代码。我自己的经验是，与其用自然语言描述，不如直接把那个Table组件文件拖进对话里，或者用@符号明确引用，再告诉它“只补全数据传入部分”。另外试试在prompt里加一句“不要新增任何组件或样式”，能有效压制它自作主张的手。说到底，这种工具适合写一次性逻辑，真要维护复杂封装，还是得自己搭好骨架再让它填肉。

这情况太常见了，不是你的prompt有啥大问题。AI工具对“复用”的理解就是复制粘贴一坨代码，它压根没搞懂你项目里那个Table组件的接口长啥样。我建议你直接把Table组件的props类型定义或者一两个使用示例贴进prompt里，让它照着样子写，比光说“复用”管用得多。另外复杂业务组件真别指望它一步到位，让它先搭骨架，你手动改细节反而更快。

说实话，你遇到的不是prompt技巧问题，是工具的上限问题。Cursor和Copilot对局部小逻辑挺灵，但真到了需要理解整个项目架构和组件依赖关系的时候，它们就是“装瞎”。我试过把现有Table组件的import路径和关键代码喂给它，它才会乖乖用那个，不然就默认生成全新的。你不如把需求拆细点，比如先让它生成搜索函数，再单独生成分页状态管理，最后你自己拼装，这样反而能少删点垃圾代码。

这问题太真实了，我也踩过类似的坑。核心在于AI对“复用”的理解很表面，你得把已有组件的接口、props甚至代码片段直接贴进prompt里，给它明确的“上下文锚点”。另外建议把需求拆成小步骤，先让它生成数据获取逻辑，再单独让它封装表格列配置，最后才组合UI，逼它一步步走，别指望一步到位。还有个小技巧是，在对话里主动说“不要创建新样式，直接引用xxx模块的className”，能有效减少它自由发挥的欲望。

这问题太真实了，复杂业务组件AI基本靠不住，你不如直接喂它你现有Table组件的代码片段当参考。

建议把“复用”改成“严格使用我提供的组件API”，再贴上组件props定义，效果立竿见影。

这问题太真实了，AI对已有封装的感知很弱，你不如直接把Table组件的props示例贴给它参考。

你试试在prompt里直接贴出已有Table组件的用法示例，比光说“复用”有效得多，AI就吃这套。

提示词里把已有Table组件的接口和用法贴给它，光说"复用"它根本不知道你长啥样。