一、背景
最近在进行M站(WAP)首页项目重构时,遇到了一个颇为头疼的问题:需要将原有的Rax框架工厂推荐瀑布流组件迁移到新的React框架项目中,同时还要把原本用DX框架实现的FactoryCard组件用React重写。如果按传统开发方式,这种跨框架、跨端的迁移工作往往要花费大量时间去理解跨端代码原有逻辑、适配新框架API、处理样式兼容等问题。
但这次我想试试用AI+Code(基于Cursor开发环境)来加速这个过程。事实证明,这确实是一次有趣的实践,既有让人惊喜的提效体验,也暴露了一些需要人工把控的细节问题。
组件样式如下:
二、挑战
这次迁移面临几个核心挑战:
- 跨框架适配:Rax和React虽然语法相似,但在一些细节上存在差异;
- DX到React的跨端重写:原本的FactoryCard是用内部DX框架写的,需要转换为React+CSS实现,本身阅读理解原有DX代码就非常耗时,更不要说将其转化为React组件了;
- 业务逻辑优化:原有的筛选逻辑是两级结构,这里因为需要保持同步App的体验,需要简化为一级,但还要兼容原有数据结构(改动现有服务端成本与副作用过大)。
老组件-二层筛选 |
新组件-一层筛选 |
|
|
- 符合新项目规范:迁移后的组件也需要满足新的项目组件规范:例如响应式、RTL、无障碍等等
- 工程化改造:需要将API调用逻辑抽离原组件,适配新的工程项目,建立Mock数据体系,确保开发环境的稳定性。
三、AI辅助开发的完整流程
整个迁移过程就像是在拆解一台复杂的机器,然后用新的零件重新组装。Agent在这个过程中充当了一个经验丰富的技师,能够快速识别零件的对应关系,但具体的精细调校还需要人工来完成。
整体流程如下:
第一步:需求分析——明确迁移目标与约束条件
在项目开始前,我通过Prompt方式和AI首先明确了这次迁移的具体目标和限制条件:
提示词
核心目标: ● 将Rax框架的new-m-site项目中的MultiFloors组件迁移到fy25-m-site项目中去,重构为React框架 ● 重命名为FactoryRecommendWaterfall组件,体现业务特性 ● 将DX原生组件用React+CSS重新实现 ● 简化二级筛选为一级筛选,只需要subTab部分 技术约束: ● 必须保持数据结构的向后兼容 ● 样式需要从scss+rpx转换为less+px ● API调用需要抽离到服务层 ● 需要建立本地Mock数据系统 ● 符合fy25-m-site M站组件规范(RTL、响应式、无障碍) 业务约束: ● 移除点击Tab滚动到顶部的功能(产品要求) ● 确保埋点组件MDotElement使用正确 最后你先把迁移计划写一下给我,调整明确之后再改代码
这个阶段的关键是让AI完全理解项目背景和限制条件,避免后续的返工。
第二步:现有代码与框架分析——充分理解原有组件结构
接下来,我让Agent提前深入分析与理解原有的代码结构和技术体系。这个阶段我通过VSCode工作区功能同时打开了两个项目,让其能够直接对比新老项目的模块代码进行分析:
第三步:方案设计——共同讨论与明确迁移技术方案
基于上述方案要求与项目代码分析,我协同Agent共同制定了详细的迁移技术方案,这里的方案设计尤其重要的,还是需要我们仔细的校验与完善,好的规划与设计会大大提高Agent最后生成的组件代码准确性和完整性:
Agent设计的计划
## MultiFloors 组件迁移计划 ### 📋 **迁移概况** - **源组件**: `new-m-site/src/components/MultiFloors` (Rax框架) - **目标组件**: `fy25-m-site/src/components/FactoryRecommendWaterfall` (React框架) - **主要变更**: Rax → React,接口调用抽离,保持逻辑和样式一致 ### 🏗️ **目录结构规划** ``` fy25-m-site/src/components/FactoryRecommendWaterfall/ ├── index.tsx # 主组件文件 ├── index.scss # 样式文件 (迁移自原组件) ├── Tab/ # Tab子组件目录 │ ├── index.tsx # Tab组件 (只保留subTab部分) │ └── index.scss # Tab样式 └── types.ts # TypeScript类型定义 ``` ### 🔄 **核心改动清单** #### 1. **框架迁移 (Rax → React)** - ✅ `View` → `div` - ✅ `Text` → `span` 或合适的HTML标签 - ✅ `createElement` → React的 `createElement` - ✅ Rax hooks → React hooks (已经是相同的) #### 2. **接口调用抽离** - ✅ 将以下接口调用迁移到 `services/api.ts`: - `initTabs()` → `getMultiFloorsTabs()` - `getResultList()` → `getMultiFloorsData(dataParams)` - ✅ 使用 `gatewayRequest` 替代直接的 `axios` 调用 - ✅ 保持相同的请求参数和数据结构 #### 3. **组件入参优化** - ✅ 添加 `tabId` 作为必需的入参 - ✅ 支持外部传入初始tab配置 - ✅ 组件接口定义: ```typescript interface FactoryRecommendWaterfallProps { tabId: string; // 必需参数 className?: string; // 可选样式类名 onTabChange?: (tabItem: any, currentSub?: string) => void; // 可选回调 } ``` #### 4. **Tab组件简化** - ✅ 只保留 `subTab` 部分的功能 - ✅ 移除多层级tab,只支持一层筛选 - ✅ 迁移相关样式到React组件 #### 5. **DxRender处理** - ✅ 将 `<DxRender />` 调用注释掉 - ✅ 添加注释说明需要替换为React组件 - ✅ 保留数据结构供后续React组件使用 #### 6. **样式迁移** - ✅ 保持原有样式不变 - ✅ 调整Rax特有的样式类名 (如 `.rax-text-v2`) - ✅ 确保响应式布局正常工作 #### 7. **Hooks和逻辑保持** - ✅ `useOnScreen` hook保持不变 - ✅ 滚动加载逻辑保持不变 - ✅ 分页和筛选逻辑保持不变 - ✅ 粘性tab定位逻辑保持不变 ### 📝 **接口迁移详情** #### **新增API方法** (在 `services/api.ts` 中) ```typescript // 获取多楼层tabs配置 exportconst getMultiFloorsTabs = async () => { return await gatewayRequest({ query: { modelId: '10161' } }); }; // 获取多楼层数据列表 exportconst getMultiFloorsData = async (params: DataParams) => { return await gatewayRequest({ query: { modelId: '10162', ...params, pageSize: 10, endpoint: 'wap', } }); }; ``` ### 🎯 **验收标准** 1. ✅ 组件能够正常渲染和交互 2. ✅ Tab切换功能正常,支持一层筛选 3. ✅ 滚动加载功能正常 4. ✅ 样式与原组件保持一致 5. ✅ 接口调用正常,数据展示正确 6. ✅ DxRender部分已注释,不影响组件运行 7. ✅ 组件接受 `tabId` 参数并正常工作 ### ⚠️ **注意事项** - DxRender组件调用将被注释,需要后续替换为React组件 - 保持原有的模板处理逻辑,供React组件后续使用 - Tab组件简化为单层,如需要多层可后续扩展 - 样式单位使用rpx,确保移动端适配正常 --- **请确认此迁移计划是否符合您的要求,我将根据您的反馈调整后开始实施代码迁移。**
第四步:分步骤实施
按照上述既定技术方案,允许Agent开始着手进行具体的迁移实施工作,以下都是截取的部分Agent生成的具有代表性的代码片段:
4.1 基础框架转换——从Rax到React
// Rax版本核心结构 import { createElement, useEffect, useState, useRef } from 'rax'; import View from 'rax-view'; const MultiFloors = () => { return ( <View className="Grid-cell u-full"> <View className="sticky-tab"> <Tab tabs={tabs} onChange={onTabChange} /> </View> {dxData.moduleList?.map((item) => ( <DxRender key={item.data.action} data={item.data} templateDTO={templateDTO} /> ))} </View> ); }; // React版本转换结果 import React, { useEffect, useState } from 'react'; const FactoryRecommendWaterfall: React.FC<FactoryRecommendWaterfallProps> = (props) => { return ( <div className="factory-recommend-waterfall"> <div className="sticky-tab"> <Tab tabs={tabs} onChange={handleTabChange} /> </div> {dxData.moduleList?.map((item, index) => ( <FactoryCard key={item?.data?.action} data={item?.data} index={index} /> ))} </div> ); };
这一步骤完成后,其实整体瀑布流的容器布局已经基本搞定了(确实有点出乎意料的顺利),剩下来就是将原先DX渲染的FactoryCard部分搞定(即图中的占位部分):
4.2 跨端组件重写——从DX到React
这部分工作其实也是我想象中对AI最大的挑战,也是工作量最为集中的部分,需要将DX框架代码转换为React组件代码,这里我尝试借助之前首页双端代码生成的DX知识库来让Agent学习后进行转换:
指导AI生成转换方案
下面我需要生成最核心的FactoryCard来把替换临时渲染占位内容。这里的转换逻辑是这样的: 1. 原来的Card是DX框架写的,这里你需要参考“@DX-generate-guide.md”这篇文档获取DX框架知识 2. 我给你DX代码,你将其逆向转化为React的Card组件,生成对应tsx和less 3. 转换方案先给我看一下 这是对应FactoryCard的DX代码: <LinearLayout width="match_parent" height="match_content" orientation="vertical" backgroundColor="#ffffff" paddingBottom="16" direction="@triple{@isRTL{}, 'RTL', 'LTR'}" > <!--头部信息--> <LinearLayout width="match_parent" height="match_content" orientation="horizontal" paddingLeft="20" paddingRight="20" paddingTop="8" backgroundColor="#ffffff" onTap="@link{@data{}}" onBindData="@onBindData{@data{}}" direction="@triple{@isRTL{}, 'RTL', 'LTR'}" > <!-- 公司Icon --> <FrameLayout width="46" height="43" > <FrameLayout width="42" height="42" cornerRadius="8" clipsToBounds="true" > <ImageView width="match_parent" height="match_parent" scaleType="fitCenter" cornerRadius="8" gravity="center" clipsToBounds="true" imageUrl="@triple{@data{companyLogo}, @data{companyLogo}, 'https://sc01.alicdn.com/kf/H59bcea42cbb74830829df99a64f0ed6a2.png'}" /> <View width="match_parent" height="match_parent" cornerRadius="8" borderColor="#DDDDDD" borderWidth="1" clipsToBounds="true" /> </FrameLayout> <!--直播标需要右移4px--> <ImageView width="17" height="match_content" gravity="rightBottom" scaleType="fitCenter" imageUrl="@data{businessLogo}" visibility="@triple{@data{businessLogo},'visible','gone'}" /> </FrameLayout> <LinearLayout width="match_parent" height="match_content" marginLeft="8" orientation="vertical" > <!-- 公司名 --> <LinearLayout width="match_parent" height="match_content" orientation="horizontal" > <ListLayout width="match_content" height="match_content" orientation="horizontal" listData="@data{nameIconList}" gravity="center" > <ImageView width="30" height="12" marginRight="4" scaleType="fitCenter" imageUrl="@subdata{}" /> </ListLayout> <TextView width="match_parent" height="22" text="@data{companyName}" textColor="#222222" textSize="16" isBold="true" maxLines="1" lineBreakMode="end" weight="1" /> <View width="8" height="2" backgroundColor="#FFFFFF" gravity="center" /> <!--Ad--> <TextView width="25" height="16" text="Ad" textGravity="center" textSize="13" textColor="#888888" backgroundColor="#05000000" gravity="center" cornerRadius="4" visibility="@triple{@data{isP4P},'visible','gone'}" /> </LinearLayout> <!-- 公司简介第一行 --> <LinearLayout width="match_parent" height="match_content" marginTop="6" orientation="horizontal" > <ListLayout width="match_content" height="match_content" orientation="horizontal" listData="@data{detailIconList}" > <ImageView width="match_content" height="14" marginRight="4" scaleType="fitCenter" imageUrl="@subdata{}" /> </ListLayout> <ListLayout width="match_content" height="14" orientation="horizontal" listData="@data{subtitleList}" > <TextView width="match_content" height="14" text="@subdata{}" textColor="#222222" textSize="11" maxLines="1" lineBreakMode="end" /> </ListLayout> </LinearLayout> <!-- 公司简介第二行 --> <LinearLayout width="match_parent" height="match_content" marginTop="8" orientation="horizontal" > <TextView width="match_content" height="14" text="@data{industryAuthTag[0]}" textColor="#222222" textSize="11" maxLines="1" lineBreakMode="end" visibility="@triple{@data{industryAuthTag[0]}, 'visible', 'gone'}" /> <TextView width="match_content" height="14" text=" • " textColor="#222222" textSize="11" visibility="@triple{@data{industryAuthTag[1]}, 'visible', 'gone'}" /> <TextView width="match_content" height="14" text="@data{industryAuthTag[1]}" textColor="#222222" textSize="11" maxLines="1" lineBreakMode="end" visibility="@triple{@data{industryAuthTag[1]}, 'visible', 'gone'}" /> </LinearLayout> </LinearLayout> </LinearLayout> <FrameLayout height="12" width="match_parent" /> <ScrollerLayout width="match_parent" height="match_content" orientation="horizontal" showIndicator="false" > <LinearLayout width="match_content" height="match_content" orientation="horizontal" paddingLeft="20" paddingRight="8" listData="@data{productList}" > <LinearLayout width="156" height="match_content" orientation="vertical" onBindData="@onBindData{@subdata{}}" onTap="@link{@subdata{}}" > <FrameLayout width="144" height="144" cornerRadius="8" > <ImageView width="match_parent" height="match_parent" imageUrl="@subdata{image}" /> <ImageView width="match_parent" height="match_parent" imageUrl="https://sc01.alicdn.com/kf/H0b5abe3843d3493cb57ccb7d20217320D.png" /> </FrameLayout> <View height="8" width="match_parent" /> <TextView text="@subdata{minPrice}" textSize="16" height="20" width="match_content" textColor="#222222" isBold="true" gravity="center" visibility="@triple{@subdata{minPrice}, 'visible', 'gone'}" /> <View height="8" width="match_parent" visibility="@triple{@subdata{minPrice}, 'visible', 'gone'}" /> </LinearLayout> </LinearLayout> </ScrollerLayout> </LinearLayout>
紧接着AI会给出他的转换方案:
人工check后还是有一些细节问题,这里通过二次对话完善:
二次对话完善方案
1. TextView用div,ImageView用div + img 2. types放到父组件下面 3. 存在onBindData的节点可以用MDotElement组件包裹下进行打点配置,onTap就是跳转url 4. 给你一个Mock测试数据: { "companyLogo": "https://sc02.alicdn.com/kf/HTB1mWiVnkfb_uJjSsrb7626bVXaX.png", "companyName": "Shenzhen Quanyaohui Technology Co., Ltd.", "businessLogo":"https://gw.alicdn.com/imgextra/i3/O1CN011u0HZD1lVRNPKwzTq_!!6000000004824-1-tps-48-48.gif", "subtitleList": [ "3 yrs", " • ", "40+ 名员工", " • ", "3,600+ ㎡", " • ", "US$700,000+" ], "action": "...", "eurl": "product_1", "pid": "607_0000_8917", "nameIconList": [ "https://gw.alicdn.com/imgextra/i3/O1CN01sog9Zi1Ha4vsMZzkW_!!6000000000773-2-tps-90-36.png" ], "detailIconList": [ "https://gw.alicdn.com/imgextra/i4/O1CN01oR5RHV1sorSuIbjiH_!!6000000005814-2-tps-123-42.png" ], "productList": [ { "image": "https://s.alicdn.com/@sc04/kf/H385f60b975f94623aaaf44b7f9f1fb47y.jpg_220x220.jpg", "productId": "1600438021206", "traceInfo": { "activityTraceId": "homepageId:0$homepageType:factory$zoneId:0_$zoneType:home_factory_just4u$zoneIndex:0$moduleId:247802646$moduleType:manufacture$moduleIndex:0$elementId:1600438021206$elementType:product$elementIndex:0", "clickParam": "click_cid-3852#click_senseid-26426_500#pvid-8bd14d4b-d1c3-454a-9d5c-eaea2ebdd15e#realPos-0_0#id-1600438021206#pos-0#matchType-6#fatherId-null#isCurrentControl-baseline#cateId-127684037#cardId-247802646#isAIRefresh-false#triggerId-CN#rankScore-0.3845406174659729#score-0.95757860274634#", "spm": "a271p.page_home.just4u.0_0_0", "name": "home_factory_just4u" }, "minPrice": "US$1.70", "action": "enalibaba://detail?id=1600438021206", "p4p": true, "eurl": "product_1", "pid": "607_0000_8917" }, {...} ] }
最后AI进行了这次工作的总结,这里也需要人为校验下:
最终DX模块直接转化为FactoryCard子组件并嵌入到上一步的父容器中:
然后这里样式问题通过对话让AI进行优化,不过试了三轮都没改对...最后还是自己下场debug优化好了样式,这一点还是略有失望~但整体瑕不掩瑜:
4.3 API层重构与Mock数据建设
// 服务层抽离 exportconst getFactoryRecommendWaterfallTabs = async () => { if (window.location.hostname === 'localhost') { const { mockTabs } = await import('@/components/FactoryRecommendWaterfall/mock'); return { tabs: mockTabs }; } // 生产环境API调用... };
4.4 业务逻辑优化
将原有的二级筛选简化为一级,同时保持数据结构兼容:
// Tab组件简化处理 const allSubs: TabItem[] = []; tabs.forEach(tab => { if (tab.children && tab.children.length > 0) { allSubs.push(...tab.children); // 将子标签提升为主导航 } }); setAllSubTabs(allSubs);
第五步:问题发现与修复
在实施过程中,遇到了一些典型问题,可以通过多轮对话尝试让AI协助进行了针对性修复:
样式细节问题:
// 问题:产品列表滚动边界处理不当 .factory-product-list { display: flex; padding-right: 12px; gap: 4px; // 解决方案:用伪元素处理末尾间距(虽然不完美,但是也能解决问题) &::after { content: ''; width: 12px; flex-shrink: 0; } }
文本截断问题:
// 问题:多行文本截断不生效 .company-detail-row { .subtitle-list { flex: 1; min-width: 0; .subtitle-text { overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } } }
CORS跨域问题:
通过环境检测自动切换Mock数据,彻底解决开发阶段的跨域问题。
Tab交互体验:
移除滚动到顶部功能,避免用户在浏览过程中的突兀体验。
不过这里其实样式方面细节问题还不少,通过2-3轮对话AI也没办法完全改对,最后还是通过人工方式debug后修复,这部分可以说是不太顺的一个地方吧,其他方面尤其是组件规范、命名、交互功能都还是挺满意的
第六步:迁移完成总结
最后,Agent也会对此次的迁移过程进行总结,方便人为进行审查与优化:
总结
## ✅ 迁移完成总结 我已经成功完成了 **MultiFloors** 组件从 `new-m-site` (Rax框架) 到 `fy25-m-site` (React框架) 的迁移,组件重命名为 **FactoryRecommendWaterfall**。 ### 🎯 **迁移成果** #### **1. 目录结构** ``` fy25-m-site/src/components/FactoryRecommendWaterfall/ ├── index.tsx # 主组件(React版本) ├── index.less # 主样式文件 ├── Tab/ # Tab子组件 │ ├── index.tsx # Tab组件(简化版,只保留subTab) │ └── index.less # Tab样式 └── types.ts # TypeScript类型定义 ``` #### **2. 核心变更完成** - ✅ **框架迁移**: Rax → React (View→div, Text→span) - ✅ **接口抽离**: 新增 `getFactoryRecommendWaterfallTabs()` 和 `getFactoryRecommendWaterfallData()` - ✅ **样式迁移**: SCSS → Less,保持原有样式效果 - ✅ **Tab组件简化**: 只保留subTab部分,支持单层筛选 - ✅ **DxRender注释**: 已注释并添加占位内容 - ✅ **入参优化**: 支持必需的 `tabId` 参数 #### **3. 新增文件** - **useOnScreen Hook**: `src/hooks/useOnScreen.ts` (React版本) - **API接口**: 在 `services/api.ts` 中新增FactoryRecommendWaterfall相关接口 - **类型定义**: 完整的 TypeScript 接口定义 #### **4. 组件使用示例** ```tsx import FactoryRecommendWaterfall from '@/components/FactoryRecommendWaterfall'; // 基础使用 <FactoryRecommendWaterfall tabId="your-tab-id" /> // 带回调使用 <FactoryRecommendWaterfall tabId="your-tab-id" className="custom-class" onTabChange={(tabItem, currentSub) => { console.log('Tab changed:', tabItem, currentSub); }} /> ``` ### 🚀 **下一步工作** 1. **DxRender替换**: 将注释的 `DxRender` 组件替换为对应的React组件 2. **测试验证**: 在实际项目中测试组件功能 3. **样式调优**: 根据实际效果进行样式微调 组件现在已经可以正常使用,具备完整的tab切换、滚动加载、数据筛选功能,只需要后续替换DxRender组件即可完全投入使用!
四、AI提效分析:优势与局限并存
显著优势
1.模式识别能力强:在本地DX知识库加持下,能够快速理解DX组件的布局结构,并生成对应的Web实现方案。
2.工程化思维:主动建议API抽离、Mock数据设计等工程化实践。
3.持续学习与改进:在迭代过程中,AI能够记住之前的修改要求,后续的调整越来越精准。
4.多项目对比分析能力:通过VSCode工作区(Workspace)功能,可以同时打开新老项目,AI能够直接对比分析两个项目的代码结构,快速识别差异点和转换规律。特别是针对我这种新老项目迁移重构的case来说,让AI的上下文理解能力得到最大化利用,减少了反复解释项目背景的时间成本。
现实局限
1.样式细节把控不足:特别是在文本截断、布局边界、响应式适配等方面,经常需要人工调优。
2.业务逻辑理解深度有限:对于一些隐含的业务规则,比如什么情况下显示AD标签、如何处理数据异常等,理解不够深入。
3.跨平台差异感知不敏感:在DX到Web的转换中,对于一些平台特性差异(如滚动行为、点击反馈等)考虑不够周全。
五、可复用的迁移范式
通过这次实践,我总结出一套可复用的AI辅助组件迁移范式:
标准化流程模板
1.预分析阶段
- 梳理源组件的功能边界
- 识别跨框架的关键差异点
- 制定分步骤的迁移计划
2.架构设计阶段
- API层抽离与设计
- 数据流重构
- 组件拆分策略
3.逐步实施阶段
- 基础框架转换
- 样式系统迁移
- 业务逻辑适配
4.精细化调优阶段
- 样式细节调整
- 性能优化
- 兼容性测试
还有一些AICode实践建议:
六、总结与展望
这次AI辅助的组件迁移实践,让我对AI+Code的开发模式有了更深的认识。AI就像一个高效的初级开发者,能够快速完成基础的编码工作,但在业务理解、细节把控、性能优化等方面还需要资深开发者的指导。
从效率角度来看,这种协作模式确实带来了显著的提升:
- 原本需要2-3天的迁移工作,压缩到1天内完成;
- 减少了80%的重复性编码工作,人工编码只涉及到了Prompt与样式逻辑调优;
- 提升了工程化实践的规范性;
但更重要的是,这种模式改变了我们的工作方式。开发者的角色从"编码者"更多地转向了"架构师"和"审查者",我们需要:
- 更好地定义需求和约束;
- 更敏锐地识别和修正AI的偏差;
- 更深入地思考系统的整体设计;
展望未来,随着AI能力的不断提升,我相信这种协作模式会越来越成熟。但技术的本质不会改变——好的软件依然需要深入的业务理解、精细的技术把控和持续的优化迭代。
对于团队而言,建议在类似的迁移项目中:
1.建立AI辅助开发的标准流程
2.积累常见问题的解决方案库
3.培养开发者的AI协作能力
4.持续优化人机协作的工作模式
毕竟,最好的工具不是替代人的工具,而是能够放大人的能力的工具。
来源 | 阿里云开发者公众号
作者 | 九垠