最近这三个月我把手头一个订单管理项目的很多模块都交给了AI生成代码。准确说是让AI帮我写第一版我再往里面填业务逻辑。刚开始确实爽半天能出十几个页面的骨架省下大把起手式时间。但等到两周后开始做功能联调和跨页面改造我发现了一个让人冒冷汗的问题AI生成的代码跑起来一点问题没有一涉及改造和复用就特别拧巴。我一开始以为是自己prompt写得不够细后来把所有AI写的组件翻出来看了一遍才意识到根本不是prompt的问题而是AI在组件复用上有自己的一套“惯性”。这套惯性看似随机实际上高度一致。摸清之后我不但能提前预判AI会怎么拆代码还能反过来用它训练出自己的组件复用规范。这篇文章就把我在AI生成代码里挖到的复用规律完整摊开讲包括规律本身、背后的原理以及怎么顺着规律调教AI产出真正可复用的前端组件。1. 在AI生成代码里反复出现的四个复用怪癖AI不是不会复用它只是以它自己的方式“复用”。三个月里我翻了上百个由不同AI工具生成的组件文件对照着逐一检查复用性下面这四个模式出现的频率高到几乎成了铁律。1.1 怪癖一按“名字”拆文件不按“边界”拆逻辑第一个怪癖是AI拆文件的标准。你让它生成一个“商家管理页面”它会把表格、筛选器、分页器、详情抽屉全部塞进一个文件里。如果你让它“封装一个表单组件”它又会把一个表单相关的所有逻辑都塞进这个组件包括提交API调用、校验规则、错误提示、状态管理。简单说AI是按组件名拆分而不是按职责边界拆分。这带来的问题很直接当你需要复用的只是“商家表格”这一小块或者“表单校验”这一个小粒度的逻辑时AI写出来的整包代码没法拆只能整体复制然后把无关逻辑删掉删除过程中稍有不慎还会引出各种依赖报错。我实测下来这个怪癖最容易出现在页面级组件的生成中AI把页面当作默认的组件粒度一次性生成就会往里塞大量内容。举一个我实际生成的例子当时让AI写一个“合作商家管理页”它给出了这样的结构const MerchantManagePage () { const [merchants, setMerchants] useState([]); const [search, setSearch] useState(); const [detailVisible, setDetailVisible] useState(false); const [current, setCurrent] useState(null); useEffect(() { fetchMerchants(); }, []); const handleSearch () { api.get(merchants, { name: search }).then(setMerchants); }; const renderSearch () { return input value{search} onChange{(e) setSearch(e.target.value)} /; }; const renderTable () { return merchants.map((item) ( div key{item.id} onClick{() { setCurrent(item); setDetailVisible(true); }} {item.name} /div )); }; const renderDetail () { return current ( Modal visible{detailVisible} onClose{() setDetailVisible(false)} {/* 商家详情 */} /Modal ); }; return ( div {renderSearch()} {renderTable()} {renderDetail()} /div ); };这段代码跑起来没问题但当你需要在另一个页面复用“商家表格”时会发现表格的数据请求、筛选逻辑甚至详情抽屉全部耦合在一起拆出来等于重写。真正按边界拆应该是这样const MerchantList ({ data, loading, onItemClick }) { /* 只负责展示 */ }; const useMerchantQuery (params) { /* 只负责数据请求 */ }; const MerchantSearch ({ value, onChange }) { /* 只负责搜索交互 */ }; const MerchantDetail ({ visible, merchant, onClose }) { /* 只负责详情展示 */ };AI并不理解“当前这个代码块将来会出现在另一个页面上”它只会根据当前需求描述生成最“顺”的那一条路径。所以拆文件这件事必须由我们自己在描述里把边界给定死而不是指望AI自动领悟。1.2 怪癖二props在一次次需求中越堆越厚第二个怪癖我给它取名叫“props膨胀”。它的表现是当你基于一个旧组件追加新需求时AI倾向于在组件上增加新的props和条件分支而不是抽一个新的子组件出来。举个真实例子。我做订单列表时最初让AI生成了一张“订单卡片”满足“展示订单号、商品名、金额、状态”的需求。后来需要支持“点击卡片跳转详情”AI在组件里加了onClick和navigateTo。再后来需要区分“B2B订单”和“B2C订单”AI又给你加了一个type字段和一堆三目运算符。等到第五个需求进来时这个“订单卡片”组件的props已经从4个涨到了13个render函数里充满了嵌套的三目表达式。这个过程的每一步从局部看都合理在现有组件上加一个参数比新建一个组件要直接改动量最小。但全局来看组件正在变成一个“什么都知道”的全能怪物。复用端最直观的体验是——查这个组件的API文档比查业务文档还累调用时必须搞清楚20多种参数组合。// AI演进后的props第N轮需求下堆积而成 OrderCard order{order} showFooter footerText{customText} badgeTypevip useBusinessPrice showOriginalPrice{false} clickable navigateTo/order/detail compact{isMobile} highlight{order.priority 2} renderExtra{ExtraSlot /} /你问AI“能不能把展示型组件和交互型组件分开”它下一次还是会往props里加。因为它的训练语料里“同一组件加参数适配更多场景”这种写法太常见了远远比“抽子组件出面组合”多得多。这里需要区分两种组件设计参数少、变体多、通过children组合的组件更适合复用参数多、分支多、通过布尔开关控制的组件更适合独立成页我现在给自己设了一条红线当组件props超过8个或者布尔开关超过3个时就要求AI在生成时做拆分重写而不是继续追加。这条红线不解决语义问题但它是验证组件复用边界是否已被突破的最简单信号。1.3 怪癖三能用开关解决的事绝不上children第三个怪癖是AI对children和插槽的天然回避。我发现AI在生成一个内部内容需要扩展的组件时几乎默认不依赖children而是用一堆显式的渲染开关去等价模拟。最典型的场景出现在卡片、模态框、下拉面板这类容器组件上。比如“弹窗组件”AI生成的代码通常长这样Modal visible{visible} title订单详情 showFooter footerText确认 onCancel{handleCancel} onConfirm{handleConfirm} body{OrderBody /} /而真正可复用、可组合的Modal应当长这样Modal visible{visible} title订单详情 onClose{handleCancel} OrderBody / footer Button onClick{handleCancel}取消/Button Button typeprimary onClick{handleConfirm}确认/Button /footer /Modal为什么AI不爱用children原因是它并不理解“组合”这个概念。AI的预测逻辑是既然当前组件的最终形态可以被全部列举那直接生成所有分支和可选区域即可。而children是“空白选区”它需要对外部开放接口这类抽象在AI的训练文本中占比不高所以AI默认不会优先选择这个方案。这个规律的实际影响是AI生成的项目里容器组件都很难复用因为你无法在不改动组件源码的前提下向容器内注入内容。我做了一次统计在一个由AI首稿生成的管理后台里90%以上的容器组件在修改内容时都直接动了源码而不是通过组合来变更。应对策略有两种。一是生成容器类组件时明确要求“内容区域必须使用children插槽实现”二是用“开放区域提示词”直接告诉AI“这个组件作为大型页面的内容容器children中出现的所有子内容都不允许写死在组件内部”。把这两句话加入prompt之后AI生成container组件的复用性会有非常明显的提升。1.4 怪癖四样式的复用意识比逻辑复用差一大截第四个怪癖发生在样式层。AI复用一个样式类时最常见的行为是整段复制再微调而不是抽取变量、mixin或组件级样式变量。打个比方AI写页面时如果出现三个卡片组件卡片之间的间距和圆角完全一致AI会生成三份几乎相同的className字符串。当设计稿统一改圆角或配色时你得在三个甚至十多个地方同步修改。这种痛点对于维护过大型样式系统的前端来说再熟悉不过。在CSS-in-JS和Tailwind这类方案下AI的表现略有不同但本质一致它会复制相同的样式对象、重复的类名串而不是提取成常量或者复用类。/* AI常见的重复形态 */ .card-a { border-radius: 8px; padding: 16px; box-shadow: 0 2px 8px rgba(0,0,0,0.08); } .card-b { border-radius: 8px; padding: 16px; box-shadow: 0 2px 8px rgba(0,0,0,0.08); background: #f5f5f5; }样式逻辑的复用意识弱会导致几个连锁问题主题换肤的成本指数级上升组件抽离后样式依赖不清晰响应式断点在多组件之间漂移。修复思路是在prompt里添加“提取公共样式令牌”“定义设计变量”等约束并在代码审查时将样式重复提升为一等检查项。2. 为什么AI总在组件复用上“差半口气”写了这么多怪癖如果不分析根因下一次还是会踩同样的坑。我把AI生成代码的机制原理翻了一遍再用自己的实验验证了一下“差半口气”不是AI能力不行而是它固有的工作机制天然偏向那几种行为。这部分我聊三点根因。2.1 AI学的是“平均码风”不是“最佳实践”大语言模型在训练时做的事情本质是最大化“下一个token”的概率。它看到海量开源项目代码之后学到的是这些代码的“统计平均形态”。这意味着AI生成代码时选择的不是“最正确的写法”而是“出现频次最高的写法”。这就解释了一个现象你让AI“写一个订单卡片”它写出的是公开代码里出现一万次的普通订单卡片而不是某个优秀组件库里的高阶抽象卡片。公开代码里复制粘贴、props堆积、样式冗余的写法占了绝大多数AI把这些常见的、甚至可以说低质量的行为当成了基线。而人类资深工程师推崇的最佳实践在训练语料中占比并不高。所以AI的“复用性差”本质上是一种幸存者偏差的反面——它见过太多不讲究复用的代码导致“不讲究”成了它的默认行为。想让它讲究就得靠prompt把讲究的标准写出来。2.2 逐token预测与上下文窗口局部精明全局失忆第二个根因涉及AI的生成机制。它每次只能看当前上下文窗口内的代码生成一个长文件的中间时很容易忘记开头定下的抽象约束。所以AI在文件开头定义了一个组件接口到第200行时可能已经忘记了那个接口的约束于是直接复制粘贴。它不是“想”复制而是它在那个局部语境下只能想起最近出现过的代码形态。这个机制还导致AI在长期演进项目时“记不住”之前的组件设计每次生成都是基于最近几次会话的上下文。因此旧的组件不会自动演进成更好复用的形态只会在同一个会话内被不断重复使用。打个比方一个人近视到只能看清眼前30厘米他修补东西时只能看到最近的那几块木板。木板A和木板B长得像他就复制A的样子做了B完全没有意识到整张桌子有一个统一的风格。我做过一个对照实验同一个组件让AI一次性生成300行和分三次生成每次100行后者的复用意识明显更强。因为每次生成时上下文窗口里能装下的“设计约束”更多AI没机会在半路忘记自己要遵守的规则。2.3 训练数据里“能跑就算成功”的代码占比太高第三个根因是训练数据本身的质量问题。GitHub上有大量“一次编写、不再维护”的个人项目这些代码的特点是跑得通、功能齐全但几乎没有可维护性设计。AI从这个数据池里学习的“组件复用”概念很大概率就是这些项目里的常见模式一个巨型组件、一把props、一堆if。再加上像Stack Overflow这类问答平台里的代码大多以“解决一个孤立问题”为目标根本不会考虑代码将来会不会出现在别的页面里。这种数据分布直接决定了AI对“复用”的直觉和人类架构师对“复用”的定义存在系统性偏差。理解了这三层根因后面的调教思路就顺理成章了既然AI学的是平均码风我们就主动把最佳实践的约束喂给它既然AI会局部失忆我们就拆短生成步骤既然训练数据里大量存在低复用代码我们就用团队约束清单对冲它。3. 顺着规律反向调教让AI直接产出高复用组件知道了AI的习性办法就来了。与其每次生成完花大量时间重构不如让AI在生成阶段就遵守我们的组件边界规则。我从实践中沉淀出三套可复用的方法下面按推荐度排序。3.1 三步提示词法在动笔前先定组件边界最有效的办法是在需求描述阶段就把组件边界写清楚。我的标准提示词模板分三步第一步给出组件职责和边界清单。例如“UserCard组件只负责展示用户信息不包含数据请求、不包含路由跳转、不包含权限判断。”第二步给出props约束。例如“props必须全部是原始类型或轻量级对象不得传入整个store、不得传入API实例。”第三步给出组合约束。例如“可选的容器区域一律使用children实现禁止使用布尔开关控制内部子元素的渲染所有交互行为都通过回调props向外抛出。”完整模板长这样可以直接复制去用请生成一个名为 UserCard 的前端组件。 边界约束 1. 只负责展示用户的基础信息头像、昵称、简介、标签 2. 不包含数据请求、不包含路由跳转、不包含权限判断 3. 组件内部不依赖任何全局store或context props约束 1. props必须是原始类型或轻量级对象 2. 所有展示数据通过单个 user 对象传入 3. 所有交互行为通过 onAction 回调抛出 组合约束 1. 组件的可扩展区域使用 children 插槽实现 2. 禁止通过布尔开关切换不同的布局分支 3. 如果有多种展示形态拆分为独立的子组件暴露 样式约束 1. 颜色、间距、圆角必须引用设计变量禁止硬编码 2. 标签、按钮等可复用样式必须提取为公共样式类用这个模板之后AI生成的UserCard组件跟之前的“巨型怪物”完全不是一个物种。它知道自己的职责边界知道哪些事不该管也知道内容扩展要靠children而不是开关。我试过在同一个项目里一个用了约束模板一个没用两者的重构成本大概差出3倍。约束模板生成的组件基本可以直接进代码库另一个则需要人工做一轮大手术。3.2 分阶段生成策略接口先行骨架跟上实现收尾第二个方法是分阶段生成。每次让AI完成一个组件时我把它拆成三段阶段一先生成组件接口定义和业务说明只确定组件名、props、事件、外部依赖不写任何实现。阶段二生成组件骨架只搭结构不填逻辑确定JSX层级、style引用、children位置。阶段三生成具体实现填充数据处理和交互逻辑。每阶段之间人工审查一遍尤其是阶段一和阶段二。这个做法能有效防止AI在一个阶段内把所有事情做完。实测下来这样生成的组件复用性比一次到位高很多因为接口定义阶段不会被后面的实现细节带偏。具体操作时我会把三个阶段的prompt分开来调。比如第一阶段这样说不要写实现代码。先帮我设计一个 OrderTable 组件的接口。 要求列出组件名、props类型定义、事件回调、对外暴露的方法。同时说明这个组件适合哪些场景复用不适合哪些场景。等接口定了再进入第二阶段根据上面的接口生成 OrderTable 组件的骨架代码。 只需要JSX结构和基础的样式类引用不要写业务逻辑不要发起数据请求。最后才是实现阶段。我做过对比实验分三步生成的总时间虽然比一次性生成多了大约5分钟但后续维护和联调省下的时间远远不止这个数。3.3 把设计约束写进需求描述比事后重构省力十倍最后给大家一个核心认知与其把AI当成一个自动写码机不如把它当成一个“记住你团队规范的执行者”。你觉得AI写出的组件复用性差多数场景下是prompt里没有明确写出复用约束。我建议每个前端团队都维护一份“AI生成代码约束清单”内容包括组件命名规范例如页面组件用Page结尾展示组件用List/Card结尾props数量红线例如超过8个必须拆分children使用规范例如容器组件内容区必须用插槽样式变量规范例如颜色、间距、圆角统一引用token复用优先级规则例如先组合再传参先抽hooks再写逻辑把这些约束在生成组件时直接粘贴进prompt比完成任务后手工重构要省力得多。我目前几乎把所有约束都收进了一份公司内部文档任何新同事接手AI辅助开发时第一件事就是读这份清单。4. 一份可以直接抄作业的组件复用检查清单下面两张表是我自己一直在用的工具。以前我都是靠感觉判断组件写得好不好现在有了这套清单AI生成的任何组件都能在两分钟之内完成复用性体检。4.1 五个“危险信号”决定要不要重构拿到AI生成的组件后我会按下面的顺序快速扫一遍信号判断标准处理动作props超过8个数一下组件参数列表拆分或改用组合模式布尔开关超过3个扫描JSX中所有条件渲染分支用children或独立子组件替代文件超过300行统计组件文件行数按职责边界拆成多文件样式类名重复超过3处全局搜索相同className提取公共样式变量或类组件内部出现数据请求查找useEffect中的fetch/axios调用逻辑抽离为自定义hooks这套检查标准解决的是“要不要重构”的决策问题。实测下来AI生成的组件十个里有六七个会触发至少一项其中最多的是布尔开关和文件行数超限。处理动作本身也有优先级。我建议先处理数据请求的抽离再处理布尔开关再处理props膨胀最后再管样式。因为逻辑层的问题影响面最大样式问题虽然烦人但不至于导致架构崩坏。4.2 去AI化的重构顺序一旦决定重构AI生成的组件我按下面的顺序操作第一步把所有数据请求逻辑从组件内部抽出来转成自定义hooks。这步做完组件就从“数据驱动”变成“视图驱动”可复用性直接上升一个档次。第二步把条件渲染分支梳理一遍找出所有布尔开关逐个评估能否用children、renderProps或独立子组件替代。这个环节通常会大幅缩减props数量。第三步按职责边界拆分文件。核心原则是一个文件只做一件事一个组件只负责一个展示单元。第四步统一样式。抽取重复的样式类、设计变量替换掉硬编码的颜色和间距。重构完之后我还会把AI生成组件时的prompt同步更新一遍把这次发现的问题改成约束写进去。这样同一个坑不会踩第二次。5. 拿订单列表做个完整实验为了让上面这些规律不悬在纸面上我完整走了一遍“AI初稿到规律复盘到重构验收”的流程用例是订单列表页。这个过程面积不算大但足以看透AI的默认行为和经约束后的差异。5.1 第一次生成验收AI的默认行为我丢给AI一个很普通的描述“生成一个订单列表页面包含订单号、商品名、金额、状态支持筛选和分页。”AI的初稿保持了极高的“贯通式”风格一个OrderListPage组件内部包含筛选表单状态、分页状态、数据请求、表格渲染、空状态判断。我把整个代码扫了一遍前面提到的四个怪癖全部命中文件300多行、props虽然没有但组件的内部职责严重混杂、筛选条件用一堆布尔开关控制、样式类名重复出现也多。这个结果其实不算差功能性需求全都满足了。但所有代码耦合在一个组件里后续想复用“订单表格”这个展示单元恐怕得连带把筛选逻辑也搬过去。5.2 按规律重构后的组件结构我把同一个需求用带上约束的prompt重新生成了一遍并且用分阶段生成策略走完三步。最终得到的组件结构是这样components/ OrderFilter/ // 筛选区域只负责筛选交互 OrderTable/ // 表格展示只接收data和loading OrderPagination/ // 分页器只负责页码变化 OrderStatusTag/ // 状态标签只负责状态到样式的映射 hooks/ useOrderListQuery.js // 数据请求、筛选参数、分页逻辑 pages/ OrderListPage.jsx // 组合以上组件的页面入口跟AI初稿一比差异非常明显。初稿把五个职责揉进一个文件重构后的结构每一个文件都只有单一职责。尤其是useOrderListQuery这个hook它可以把数据请求这一层从任何视图组件中剥离出来以后换任何UI框架来呈现订单列表这个hook都可以直接复用。关键代码只需要看OrderListPage的组装逻辑就够了const OrderListPage () { const { data, loading, params, setParams } useOrderListQuery(); return ( div OrderFilter value{params.filter} onChange{setParams} / OrderTable data{data} loading{loading} / OrderPagination page{params.page} onChange{setParams} / /div ); };到这里“复用”并不是靠什么高深的组件设计技巧而是靠把职责边界划清楚。每个组件只负责自己那一小块组合关系在页面层级完成。后端的同事想接一个同样的列表直接复制这个目录结构就行。5.3 重构带给我的三个意外收获这个实验做完之后有三点是我事先没想到的。第一重构后的代码总行数反而更少了。初稿光一个页面组件就300多行重构后五六个文件加起来才250行左右。AI写代码时喜欢把所有分支和可选场景都展示出来拆开之后反而省掉了大量冗余的条件渲染。第二团队review代码的效率明显提高。以前的AI初稿review需要从头看到尾因为所有逻辑交织在一起。重构后的代码每个文件都能独立review其他人甚至不需要看完整上下文就能判断逻辑是否正确。第三AI对不同项目的生成质量差异很大程度上取决于初始需求描述里有没有组件边界。同样是订单页面我在另一个需求里写清楚了边界约束AI生成的质量直接逼近重构后的水平节省的时间是实打实的。另外还有一个操作上的小技巧。我习惯在AI生成完代码之后让它自己输出一份“组件复用自检说明”要求它逐条说明每个组件为什么是单一职责、每个props为什么存在、为什么选用children而不是布尔开关。这个办法很有效相当于逼着AI在执行层面把设计意图说一遍一说不清楚就说明那段代码的设计有问题直接标记出来人工介入。现在的我已经不会抱着“AI一次生成就能直接上线”的幻想了但也不再觉得AI写代码“不能复用”。关键是摸清它的规律再把我们的规范补进去。AI给的初稿是一个很好的起点而“复用性”的提升本质上是我们把工程设计的思考前置到了prompt里。