AI+Code驱动的M站首页重构实践：从技术债务到智能化开发

在大型团队里，重构一个长期低优先级维护的移动端站点，通常会面临一个非常现实的挑战：技术债高筑，但业务又不敢停下来等。阿里巴巴找品M站首页的重构项目，就是一个典型的例子——老旧的技术栈、复杂的历史逻辑，以及逐渐与App端拉大的体验差距，都让这个项目从启动起就带着一股“必须破局”的紧迫感。

这篇文章的核心，不是讲一个单纯的“从Rax迁移到React”的搬砖故事，而是想聊聊我们如何在这个重构过程中，通过一套完整的“楼层动态化”架构设计，并结合AI+Code的能力，把技术升级和效率提升真正落在实处。最终的数据是，70%的首页场景实现了标准化覆盖，标准化楼层的开发效率提升了90%以上，非标场景的研发速度也提升了40%+。听起来不错？关键在于方法。

一、项目背景与挑战

过去很长一段时间，公司的核心迭代资源都集中在App端，M站（WAP端）的投入优先级相对较低。这种“低优先级”带来的后果是累积的：

• 功能层面
  ：M站的业务功能迭代严重滞后于App，部分核心场景甚至无法正常满足用户需求，用户体验的差距肉眼可见。

• 技术层面
  ：基于Rax + DX的老旧技术栈，不仅维护成本极高，连发布流程都异常复杂，每一次小改动都像在做一次大手术。

• 效率层面
  ：团队缺乏打通AI+Code的工程能力，面对重复性高、规范性强的开发任务，依然靠纯手工操作，效率自然上不去。

基于以上痛点，我们设定了几个明确的重构目标：
首先是

——对标App页面进行全面升级，包括类目导航、功能楼层、多屏幕适配、RTL和无障碍等等。
其次是——将整个前端技术栈从Rax迁移到React生态，建立一套可长期维护的架构。
最后是——结合AI+Code和AI+Ops，全面提升研发效能，同时推动团队整体的AI工程能力升级。

二、技术方案设计

在技术选型上，我们最终决定启动一个全新的React前端工程。为什么没有选择继续在Rax上修修补补？原因很直接：Rax框架过于老旧，维护成本太高，而且不利于后续AI+Code的集成——它需要一个额外的私域知识库来支撑。相比之下，React生态更成熟，AI工具的支持也更完善。

新的架构移除了冗余的DX-SDK和适配代码，通过“楼层模板 + BFF + 星舰投放”的方式实现了动态化。说白了，就是在保持原有灵活性和扩展性的前提下，大幅度降低维护成本。

整个重构方案的核心，其实是围绕新版首页的楼层动态化来展开的。下面重点聊聊这套方案的设计思路，以及AI+Code在整个研发过程中的提效实践。

怎么让首页楼层既能满足多样化的业务需求，又不至于让前端团队“一把梭”式地每次都从头开发？我们的解法是：通过统一领域模型、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提效实践

在楼层动态化方案的落地过程中，我们发现了两个非常实际的痛点。

：新增一个楼层模板，不只是写个UI组件那么简单。开发者需要完成UI交互开发、多屏幕适配、RTL、无障碍、埋点规范等一系列工作，还要配套编写类型定义、mock数据和README文档。每套都要从头来过，工作量很大。

：开发者需要深入理解已有的楼层模板README，并结合首页场景的研发经验，才能准确判断一个新的需求是否能通过已有模板来支持。这其实是一个非常依赖经验的过程，对于新人来说尤其不友好。

3.2.1 智能楼层模板生成

针对上述痛点，我们设计了一套智能楼层模板生成方案。核心思路是：

：通过Figma-MCP + 需求描述 + 首页知识库 + Agent组合来实现。
：通过本地知识库沉淀 + Cursor-Rule + Cursor-Agent，做到无感生成。

实际效果是什么样的？
开发者只需要提供设计稿和需求描述，AI就能自动完成规范代码的编写——包括多屏幕适配、RTL、埋点、无障碍等，还能同步生成完整的类型定义、Mock数据和README文档。

下面分享一段提示词（snippet），展示了智能楼层模板生成的核心逻辑：

# 创建动态楼层
这个 snippet 用于在 DynamicFloors 目录中创建新的楼层。
## 步骤
- 注意下述相关命名只是以 NewFloor 示例，具体根据识别结果判断楼层与相关变量命名，不能直接用 NewFloor。
- 整体上各个代码文件格式规范方面可以参考 DynamicFloors/ProductFloor 下的一系列实现
- 需要符合WCAG 1.4 版本 AA等级的无障碍规范（尤其img元素需要补充alt字段）
1. 创建楼层目录，例如`floors/NewFloor`并在楼层目录下创建类型定义文件 `floors/NewFloor/types.ts`：
```typescript
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_d2c` MCP 方法生成自定义卡片内容：
- 请求用户补充坑位卡片对应的设计稿链接（例如：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`：
```typescript
import './index.less';
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 = props => {
  const { items, homeActivityInfo, isRTL } = props;
  return (
    
      

        
        

          {items.map((item, index) => (
            
              {/* 自定义卡片内容占位 */}
            
          ))}
        
      

    
  );
};
export default NewFloor;
```
6. 创建样式文件 `floors/NewFloor/index.less`：
```less
@import 'src/styles/global';
.new-floor {
  padding: 16px 0;
  background: #fff;
  .card-container {
    display: flex;
    overflow-x: auto;
    scrollbar-width: none;
    padding: 0 12px;
    gap: 12px;
    &.rtl { direction: rtl; }
    &::-webkit-scrollbar { display: none; }
    .card {
      flex: 0 0 auto;
      // 自定义卡片样式占位
    }
  }
}
```
7. 更新 `constants.ts` 中的组件映射：
```typescript
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';
export const ComponentsMap = {
  ..., NewFloor,
};
```
8. 在 `pages/FloorTest/index.tsx` 中添加新楼层的测试：
```typescript
const FloorTestPage = () => {
  const testDSL: DSLData = [
    ..., mockNewFloor,
  ];
  return (...);
};
```
9. 创建说明文档 `floors/NewFloor/README.md` 中增加新楼层的说明：
```markdown
# 新楼层
## 组件概述
## API 定义
## 使用示例
```
## 注意事项
1. 确保所有类型定义正确...
...
14. 样式规范...

除了自动生成代码，另一个核心能力是对现有组件的智能复用评估。简单来说，就是当新需求来时，先判断能不能用已有的楼层模板，还是需要新建一个。

这个决策流程如下：

为了让这个决策过程更加客观，我们把开发者的经验判断转化成了可量化的评估指标：

• 结构相似度分析
  ：从布局结构、主要组件、交互模式、数据结构、样式特征五个维度进行加权打分。

• 功能差异分析
  ：重点考察核心功能、交互方式、性能要求、业务逻辑和设计意图是否一致。

• 可配置性评估
  ：评估现有组件通过配置支持新需求的可行性。

最终的标准很清晰：当结构相似度评分≥70%，且核心功能基本一致时，建议复用；如果评分低于70%，或者核心功能有本质差异，则建议创建新组件。

实际落地下来，相似度评估的准确率达到了85%以上。这不仅避免了重复造轮子，也大幅降低了技术决策的门槛和时间成本。

有了上述两个核心模块的AI化提效，我们尝试把这些点状的功能模块整合成一条完整的链路。目前已经实现了从“需求描述 + 设计稿”到“App/M站双端代码生成”的端到端打通。

这条链路的优势在于：一次输入，双端代码自动生成；标准化的开发流程，降低人工决策成本；完整的质量保障机制，确保输出代码符合项目规范。

四、AI+Code实践经验总结

一个很重要的认知转变是：不要想着用AI取代工程师，而是把它当作一个新入职的配对编程伙伴。

它不是万能的，需要明确的领域指南和编码规范来引导；但它也不是无能的，在代码生成、问题分析和方案建议方面有显著优势。实践下来发现，像模块README、类型定义、无障碍通用规范这类标准化内容，特别适合交给AI快速生成。

AI生成的代码不可能百分百准确，“幻觉”问题谁都会遇到。我们的应对策略是“分步骤确认”：把复杂任务拆解成多个小步骤，关键步骤必须由开发者逐一确认。

另外，在知识库的组织上也有一些技巧：单篇文章控制长度，过长内容分步骤处理；关键约束和规范放在文档的前半部分；多给具体示例，少用抽象描述。最后再建立“解释-执行-验证”的标准工作流程，形成闭环。

在实际开发中，有几个技巧值得分享：
处理复杂组件时，如果AI缺少上下文，可以通过多轮对话逐步完善；让AI在关键位置添加详细日志，便于问题追踪；提供分层解决思路，考虑错误边界、性能、兼容性等边界情况。

工具使用方面，善用Cursor的Rule功能，把项目规范文档梳理为项目级Rule；选择最新模型（Claude4/3.7），避免使用Auto模式；AI反哺文档，形成良性循环。

五、成果与展望

目前，M站找品首页已经基于上述链路，对标App页面进行了一波系统性的体验升级。从类目导航/刷新、功能楼层、多屏幕适配，到RTL、无障碍适配，都有了质的提升。

• 覆盖率：70%首页场景标准化覆盖。
• 效率提升：标准化楼层开发效率提升90%+，非标准化楼层开发效率提升40%+。
• 质量保障：自动化规范实现，有效减少人工错误。
• 技术债务：成功从Rax迁移到React现代化技术栈。

老M站首页	新M站首页（预发环境）	新M站首页宽屏（预发环境）	新M站首页RTL语言（预发环境）

下一步的计划有三个方向：
一是

——把BFF层与投放层的能力也Agent化；
二是——完成首页领域的Agent助理建设；
三是——把这次成功的经验和模式推广到其他业务场景中去。

AI+Code不是银弹，但在合适的场景下，确实能显著提升开发效率。关键在于找到AI的优势领域，建立标准化的协作流程，并不断优化人机协作的方式。这次实践让我们相信，通过系统性的方法论和工具链建设，AI+Code完全能够成为团队研发效能提升的重要驱动力。