阿里云M站首页重构通过AI+Code，实现70%场景标准化覆盖，非标场景提速40%+，并从Rax迁移到React，大幅提升开发效率。
原文标题：AI+Code驱动的M站首页重构实践：从技术债务到智能化开发
原文作者：阿里云开发者
冷月清谈：
怜星夜思：
2、文章提到“将AI视为新入职工程师的配对编程伙伴”，这个观点你认同吗？如果让你带一个“AI伙伴”，你希望它具备哪些能力？
3、面对AI生成代码可能出现的“幻觉”问题，文章提出了“分步骤确认机制”、“上下文强化策略”等应对方法。你认为还有哪些方法可以有效减少或规避AI幻觉？
原文内容
本文分享了阿里巴巴找品M站首页重构项目中AI+Code提效的实践经验。面对M站技术栈陈旧、开发效率低下的挑战，我们通过楼层动态化架构重构和AI智能脚手架，实现了70%首页场景的标准化覆盖 + 30%的非标场景的研发提速，开发效率分别提升90%+与40%+。文章详细介绍了楼层模板沉淀、AI辅助代码生成、智能组件复用评估等核心实践，为团队AI工程能力升级提供了可复制的方法论。
一、项目背景与挑战
1.1 业务现状分析
当前业务迭代以App为核心，PC端次之，M站（WAP）因长期低优先级投入，面临严重的技术债务问题：
-
功能层面：M站业务功能严重滞后于App端，部分核心场景无法满足用户需求，用户体验差距明显。
-
技术层面：基于Rax + DX的老旧技术栈，开发维护成本极高，发布流程复杂，迭代效率低下。
-
效率层面：缺乏现代化的AI+Code工程能力，无法充分利用AI工具提升研发效能。
1.2 重构目标设定
-
体验升级：对标App页面进行全面体验升级（类目导航、功能楼层、多屏幕适配、RTL、无障碍等）。
-
技术现代化：从Rax迁移到React生态，建立可维护的技术架构。
-
AI驱动：结合AI+Code/AI+Ops全面提升研发效能，推动团队AI工程能力升级。
二、技术方案设计
2.1 整体架构重构
经过技术评估，我们决定启动全新的React前端工程：
技术选型理由：
-
老版Rax框架过于老旧，维护成本极高；
-
不利于AI+Code集成（需要额外的私域知识库支持）；
-
React生态更成熟，AI工具支持更完善；
架构优势：
-
移除冗余的DX-SDK和适配代码；
-
通过楼层模板 + BFF + 星舰投放实现动态化；
-
保持原有动态性和扩展性的同时，大幅降低维护成本；
目前新版本工程整体架构图如下：
针对上述方案，核心重构点主要围绕新版首页的楼层动态化方案，同时这里也会介绍一下AI+Code在其研发过程中的提效实践
2.2 楼层动态化核心设计
我们通过统一领域模型 & BFF下沉业务逻辑 + 标准楼层模板沉淀 + DSL驱动实现了一套完整的楼层渲染引擎。
核心设计理念：分离首页楼层业务中"变"与"不变"的部分
-
"不变"部分：沉淀到楼层模板（通用UI交互、埋点规范、无障碍规范、类型定义、Mock数据、组件文档）
-
"变化"部分：抽象为DSL配置，通过BFF层实现数据驱动（差异化UI/交互、业务属性字段、埋点字段等）
用尽可能小的研发成本同时达到首页场景下要求的高复用性与高动态性。
该方案的实际研发流程如下：
商品楼层模板标准化内容示例：
// ProductFloor 组件属性类型
export type ProductFloorProps = {
// 动态模板类型，固定为 'ProductFloor'
dynamicTemplate: 'ProductFloor';
// 埋点信息
homeActivityInfo?: HomeActivityInfo;
// 楼层标题
title: string;
// 楼层标题图标
titleIcon?: string;
// 楼层副标题
subTitle: string;
// 楼层整体点击跳转链接
action: string;
// 商品卡片主标题样式
itemTitleStyle?: 'primary' | 'normal';
// 商品卡片副标题样式
itemSubTitleStyle?: 'primary' | 'normal';
// 背景图片 URL
backgroundImage?: string;
// 商品卡片列表
items: Item[];
// 是否使用 RTL 布局
isRTL?: boolean;
// 是否显示间隔块
isShowGap?: string;
};
// Item 类型定义
export type Item = {
// 项目唯一标识
id: string;
// 商品ID（如果是商品类型）
productId?: string;
// 项目标题
title: string;
// 标题颜色
titleColor?: string;
// 价格
price?: string;
// 主图URL
image: string;
// 主图宽度
imageWidth?: string;
// 主图高度
imageHeight?: string;
// 角标图片URL
cornerImg?: string;
// 角标宽度
cornerWidth?: string;
// 角标高度
cornerHeight?: string;
// 副标题
subTitle?: string;
// 副标题图标
subIcon?: string;
// 最小订单量文本
moqText?: string;
// 已售数量文本
soldText?: string;
// 本地库存标签
localField?: string;
// 国家国旗URL
countryFlagUrl?: string;
// 点击跳转链接
action?: string;
// 埋点信息
homeActivityInfo?: HomeActivityInfo;
// 是否显示闪购标签
showFlashDeal?: boolean;
// 闪购标签文本
label?: string;
// 图片中间描述信息
centerDesc?: string;
// 浏览量
views?: string;
};
成果数据：目前已沉淀ProductFloor和ThemeFloor两种核心楼层模板，覆盖3个Tab下70%的首页场景，剩余30%可通过新增楼层模板方式快速支持。
三、AI+Code提效实践
3.1 核心痛点识别
在楼层动态化方案落地过程中，我们发现了两个关键痛点：
开发工作量大：新增楼层模板需要完成UI交互开发、多屏幕适配、RTL、无障碍、埋点等规范实现，还需编写配套的类型定义、mock数据、README文档。
技术门槛高：开发者需要深度了解楼层模板README，结合首页场景研发经验才能准确评估新需求是否可通过已有模板支持。
3.2 AI+Code解决方案
3.2.1 智能楼层模板生成
方案设计：
-
视觉还原：Figma-MCP + 需求描述 + 首页知识库 + Agent组合
-
规范实现：本地知识库沉淀 + Cursor-Rule + Cursor-Agent无感生成
实施效果：
-
开发者只需提供设计稿和需求描述；
-
AI自动完成规范代码编写（多屏幕适配、RTL、埋点、无障碍等）；
-
生成完整的类型定义、Mock数据、README文档；
智能楼层模板生成-提示词分享：
提示词
# 创建动态楼层这个 snippet 用于在 DynamicFloors 目录中创建新的楼层。
步骤
- 注意下述相关命名只是以 NewFloor 示例，具体根据识别结果判断楼层与相关变量命名，不能直接用
NewFloor。
- 整体上各个代码文件格式规范方面可以参考 DynamicFloors/ProductFloor 下的一系列实现
- 需要符合WCAG 1.4 版本 AA等级的无障碍规范（尤其img元素需要补充alt字段）
1. 创建楼层目录，例如floors/NewFloor并在楼层目录下创建类型定义文件floors/NewFloor/types.ts：import type { HomeActivityInfo } from '@/components/DynamicFloors/types'; // 如果需要扩展通用 Item 类型，可以这样做 export interface NewFloorItem { // Item字段 } export type NewFloorProps = { dynamicTemplate: 'NewFloor'; title: string; subTitle?: string; action?: string; items: NewFloorItem[]; homeActivityInfo?: HomeActivityInfo; isRTL?: boolean; };2. 在楼层目录下创建模拟数据文件
floors/NewFloor/mock.ts,注意 image 相关数据调用 getRandomImage()方
法，不要自己写 url
3. 更新根目录的types.ts，添加新楼层的类型：// ... 其他导入 import type { NewFloorProps } from './floors/NewFloor/types'; // 更新 DSLData 类型 export type DSLData = (ProductFloorType | ThemeFloorType | GapFloorType | NewFloorProps)[];4. 使用
figma_d2cMCP 方法生成自定义卡片内容：
- 请求用户补充坑位卡片对应的设计稿链接（例如
：https://www.figma.com/file/xxxx），调用figma_d2c方法生成组件代码
- 生成的卡片代码替换到
floors/NewFloor/index.tsx，样式代码替换到floors/NewFloor/index.less- 不要对
figma_d2c生成的代码做任何修改
5. 更新根目录的mock.ts，导出新楼层的模拟数据：// ... 其他导入 import { mockNewFloor } from './floors/NewFloor/mock'; // 导出所有楼层的模拟数据 export { ..., mockNewFloor };6. 创建楼层组件
floors/NewFloor/index.tsx：import'./index.less'; // 分析设计稿，有楼层级别的标题才引入FloorTitleBlock import FloorTitleBlock from '@/components/DynamicFloors/blocks/FloorTitleBlock'; import ErrorBoundary from '@/components/ErrorBoundary'; import MDotElement from '@/components/MDotElement'; import React from 'react'; import { NewFloorProps } from './types'; const NewFloor: React.FC<NewFloorProps> = props => { const { items, homeActivityInfo, isRTL } = props; return ( <ErrorBoundary sceneName={'NewFloor'}> <div className="new-floor"> // 有楼层标题区域才需要该组件 <FloorTitleBlock {...props} /> <div className={`card-container ${isRTL ? 'rtl' : ''}`}> {items.map((item, index) => ( <MDotElement key={item.id} url={item.action} className="card" dotParams={{ sceneName: homeActivityInfo?.moduleType || 'NewFloor', pos: index, elementType: item.homeActivityInfo?.elementType, }} > {/* 自定义卡片内容占位，不要直接写内容 */} </MDotElement> ))} </div> </div> </ErrorBoundary> ); }; exportdefault NewFloor;6. 创建样式文件
floors/NewFloor/index.less：@import'src/styles/global'; .new-floor { padding: 16px 0; background: #fff; .card-container { display: flex; overflow-x: auto; scrollbar-width: none; padding: 012px; gap: 12px; &.rtl { direction: rtl; } &::-webkit-scrollbar { display: none; } .card { flex: 00auto; // 自定义卡片样式占位，不要直接写样式 } } }7. 更新
constants.ts中的组件映射：import GapFloor from '@/components/DynamicFloors/floors/GapFloor'; import ProductFloor from '@/components/DynamicFloors/floors/ProductFloor'; import ThemeFloor from '@/components/DynamicFloors/floors/ThemeFloor'; import NewFloor from '@/components/DynamicFloors/floors/NewFloor'; exportconst ComponentsMap = { ..., NewFloor, // 添加新楼层 };8. 在
pages/FloorTest/index.tsx中添加新楼层的测试：const FloorTestPage = () => { const testDSL: DSLData = [ ..., mockNewFloor, // 添加新楼层的测试数据 ]; return ( <div> <h1>Dynamic Floors Test Page</h1> <DynamicFloors DSL={testDSL} /> </div> ); }; exportdefault FloorTestPage;9. 创建说明文档
floors/NewFloor/README.md中增加新楼层的说明：# 新楼层 ## 组件概述 ## API 定义 ## 使用示例注意事项
1. 确保所有类型定义正确，特别是
dynamicTemplate的字面量类型
2. 使用ErrorBoundary包裹组件
3. 支持埋点功能，确保homeActivityInfo和dotParams的正确配置
4. 支持 RTL 布局
5. 遵循现有楼层的代码风格和最佳实践
6. 确保在constants.ts中正确导入和导出新楼层组件
7. 类型定义和模拟数据应该放在楼层目录下，根目录的types.ts和mock.ts只负责导出
8. 记得在FloorTest页面中添加新楼层的测试数据
9. 相关命名只是以 NewFloor 示例，具体根据识别结果判断楼层与相关变量命名，不能直接用 NewFloor
10. 优先使用现有的通用组件，如FloorTitleBlock来处理标题部分，注意如果没有楼层标题模块，不要强行
使用它！
11. 命名规范：
- 使用subTitle而不是subtitle
- 使用action而不是url
- 尽可能复用通用的Item类型，需要额外字段时通过继承扩展
- 组件属性类型以Props结尾，如NewFloorProps
- 模拟数据变量以mock开头，如mockNewFloor
12. 图片资源：
- 测试数据中使用实际的阿里巴巴图片链接，如
：‘https://s.alicdn.com/@sc04/kf/H6d8a4c02a984415e9c7052e5d95c09b0V.jpg_220x220.jpg’
- 不要使用 example.com 的示例图片链接
- 国家图标规范:
https://u.alicdn.com/mobile/g/common/flags/1.0.0/assets/{countryCode}.png，countryCode 使用
国家简称如pk、tr等。
13. 图片展示规范：
- 商品主图需要添加灰色遮罩层，使用.overlay类，背景色为#0000000a
- 图片容器需要设置position: relative，遮罩层使用绝对定位
14. 样式规范：
- 避免使用不必要的阴影效果
- 价格信息直接使用item.title展示，不要单独维护 price 字段
- 商品副标题（subTitle）使用黑色系（#222），而不是红色
- 横向滚动列表中的卡片间距（gap）使用 4px示例
参考 DynamicFloors/floors/PrdouctFloor 的实现：
- 类型定义：floors/PrdouctFloor/types.ts
- 模拟数据：floors/PrdouctFloor/mock.ts
- 组件实现：floors/PrdouctFloor/index.tsx
- 样式文件：floors/PrdouctFloor/index.less
- 组件映射：在constants.ts中添加PrdouctFloor
- 组件说明：floors/PrdouctFloor/README.md
- 测试楼层：在pages/FloorTest/index.tsx中添加新楼层的测试
3.2.2 智能组件复用评估
决策流程：
┌─────────────────┐ │ 获取楼层设计图 │ └─────────┬───────┘ ▼ ┌─────────────────┐ │ 分析楼层特征 │ └─────────┬───────┘ ▼ ┌─────────────────┐ │ 检查现有楼层组件 │ └─────────┬───────┘ ▼ ┌─────────────────┐ │ 阅读组件README文档│ └─────────┬───────┘ ▼ ┌─────────────────┐ ┌───┤ 相似度评估 ├───┐ │ └─────────────────┘ │ ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ │ 相似度高 (≥70%) │ │ 相似度低 (<70%) │ └─────────┬───────┘ └─────────┬───────┘ │ │ ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ │ 复用现有组件 │ │ 创建新组件 │ └─────────┬───────┘ └─────────┬───────┘ │ │ ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ │ 与开发者确认 │ │ 与开发者确认 │ └─────────┬───────┘ └─────────┬───────┘ │ │ ▼ ▼ ┌───────┐ ┌───────────┐ ┌──┤ 认同 │ ┌────┤ 认同 │ │ └───┬───┘ │ └─────┬─────┘ │ │ │ │ │ ▼ │ ▼ │ ┌───────────┐ │ ┌─────────────────┐ │ │ 生成测试 │ │ │ 创建新组件 │ │ │ 样例代码 │ │ └─────────────────┘ │ └───────────┘ │ │ │ ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ │ 不认同,需重新评估│ │ 不认同,询问需求 │ └─────────┬───────┘ └─────────┬───────┘ │ │ ▼ ▼ ┌───────────────┐ ┌──────────────────────┐ │ 迭代现有组件 │ │ 根据开发者反馈调整方案│ └───────────────┘ └──────────────────────┘
量化评估标准：我们将开发者的经验判断转化为可量化的评估指标。
## 五、分析标准1. 结构相似度分析
评估新楼层与现有楼层的结构相似度：
结构元素 权重 说明 布局结构 30% 整体布局、元素排列方式 主要组件 25% 卡片、图标、按钮等关键元素 交互模式 20% 点击、滑动、展开等交互方式 数据结构 15% 数据的组织和展示方式 样式特征 10% 颜色、字体、间距等样式细节 2. 功能差异分析
评估新楼层与现有楼层的功能差异：
功能方面 判断标准 核心功能 如果核心功能完全不同，建议创建新组件 交互方式 如果交互逻辑差异较大，建议创建新组件 性能要求 如果性能要求有特殊差异，建议创建新组件 业务逻辑 如果业务逻辑复杂且独特，建议创建新组件 设计意图 如果设计意图与README中描述的组件定位不符，建议创建新组件 3. 可配置性评估
评估现有组件通过配置支持新需求的可行性：
配置方面 评估指标 样式配置 现有组件是否支持所需的样式变化 结构配置 是否可以通过条件渲染调整结构 功能配置 扩展现有功能的难易程度 可维护性 添加配置后代码是否仍然清晰可维护 API兼容性 新需求是否符合README中定义的API规范 六、决策标准
1. 建议复用现有组件的情况
当满足以下条件时，建议复用现有组件并通过 props 扩展：
- 结构相似度评分 ≥ 70%
- 核心功能基本一致
- 通过少量配置可以支持新需求
- 不会导致组件过于复杂难以维护
- 复用后性能不会显著下降
- 设计需求与README中描述的组件定位和使用场景相符2. 建议创建新组件的情况
当满足以下条件时，建议创建新的楼层组件：
- 结构相似度评分 < 70%
- 核心功能有本质区别
- 需要大量配置才能支持，导致代码复杂度大幅增加
- 业务逻辑独特且复杂
- 有特殊的性能优化需求
- 未来可能有更多类似楼层需要基于此组件扩展
- 设计需求与现有组件README中描述的定位和应用场景明显不符
实施效果：
-
相似度评估准确率达到85%以上
-
避免了重复造轮子，提升了代码复用率
-
降低了技术决策的门槛和时间成本
3.3 端到端智能化链路
当上述两个核心功能模块基于AI能力完成了提效与落地之后，我们尝试将这些点状功能模块结合实际首页需求的链路进行整合，目前已经打通从 需求描述 + 设计稿 到 App/M站双端代码生成的链路：
链路优势：
-
一次输入，双端代码自动生成；
-
标准化的开发流程，降低人工决策成本；
-
完整的质量保障机制，确保输出代码符合项目规范；
演示视频：
双端代码生成链路-提示词分享：
本文档用于指导如何处理App与M站双端楼层需求的文档* 注意，完成需求分析之后一定要用户确认之后再进行代码生成工作
处理流程
1. Agent输入与需求分析：
* 开发者通过Agent输入相关信息。Agent的输入会基于以下三方面信息：
* 设计稿
* 双端生成要求（即App端和M站端的具体生成规则或需求）
* 需求描述（贴上PRD链接 或者 对要实现功能的文字性描述， 注意我们只关心PRD中首页楼层部分的改动）2. 输出需求描述内容：
* 输出需求描述，让用户判断是否准确或者有修改的地方，若可行，就准备继续生成楼层代码3. 双路径处理前端楼层代码-根据用户生成要求来进行：
* 路径A：M站楼层代码处理
* 触发“M站楼层代码生成链路”。
* 一定要参考项目.cursor/snippets/analyze-floor.md文档来处理M站楼层，一定要进行相似度打分，最终判断是复用已有楼层组件（一般情况都是复用ProductFloor或者ThemeFloor）还是新增楼层组件（相似度不高情况下）
* 处理好之后通知开发者运行项目，并前往floorTest页面预览mock数据下的楼层效果
* 路径B：App楼层DX代码处理
* 触发“App楼层DX代码处理链路”。
* 一定要参考项目.cursor/snippets/DX-generate-guide.md文档来生成DX代码
* 生成的DX代码存放在src/DXCode目录下
* 处理好之后通知开发者前往DX平台创建模板并使用生成的代码
4. 总结需求与生成的代码，以及如何测试验证这部分内容
四、AI+Code实践经验总结
4.1 协作理念转变
核心认知：将AI视为新入职工程师的配对编程伙伴
-
不是万能工具：需要明确的领域指南与编码规范；
-
不是无能助手：在代码生成、问题分析、方案建议方面有显著优势；
-
最佳实践：模块README、Types定义、无障碍通用规范等标准化内容特别适合AI快速生成；
4.2 幻觉问题应对策略
分步骤确认机制：
-
复杂任务拆解为多个小步骤，关键步骤必须用户确认；
-
本地知识库单篇文章控制长度，过长内容分步骤处理；
上下文强化策略：
-
关键约束和规范放在文档前半部分（注意力机制特性）；
-
增加具体示例而非抽象描述；
-
建立"解释-执行-验证"的标准工作流程；
验证与反馈循环：
-
要求AI执行前说明理解和计划；
-
及时反馈和纠正，实时修订知识库；
-
成功方案整理为可复用指南；
4.3 开发实践技巧
复杂组件处理：
-
缺少上下文时，通过多轮对话逐步完善；
-
AI可以在关键位置添加详细日志，便于问题追踪；
-
提供分层解决思路，考虑错误边界、性能、兼容性等边界情况；
工具使用优化：
-
善用Cursor的Rule功能，将项目规范文档梳理为项目级Rule；
-
选择最新模型（Claude4/3.7），避免使用Auto模式；
-
AI反哺文档，形成良性循环；
五、成果与展望
目前M站找品首页已经基于上述链路对标App页面进行了一波体验升级（类目导航/刷新、功能楼层、多屏幕适配、RTL、无障碍适配等）：
-
覆盖率：70%首页场景标准化覆盖；
-
效率提升：标准化楼层开发效率提升90%+，非标准化楼层开发开发效率提升40%+；
-
质量保障：自动化规范实现，减少人工错误；
-
技术债务：成功从Rax迁移到React现代化技术栈；
|
老M站首页 |
新M站首页（预发环境） |
新M站首页宽屏（预发环境） |
新M站首页RTL语言（预发环境） |
|
|
|
|
|
5.1 后续规划
-
能力扩展：将BFF层与投放层能力Agent化
-
领域深化：完成首页领域的Agent助理建设
-
经验推广：将成功经验推广到其他业务场景
结语
AI+Code不是银弹，但在合适的场景下能够显著提升开发效率。关键在于找到AI的优势领域，建立标准化的协作流程，并持续优化人机协作的方式。我们的实践证明，通过系统性的方法论和工具链建设，AI+Code能够成为团队研发效能提升的重要驱动力。
多模态数据信息提取
随着信息技术的快速发展，数据的获取与处理变得尤为重要。本方案提供多模态文件信息抽取能力，通过先进的人工智能技术，能够识别和解析各种格式的文件，包括文本、图像、音频和视频，从而提取出有价值的信息，大幅提升数据处理效率。
点击阅读原文查看详情。