拆解 Antdesign Skill 和 阿里云 Vibe design分享，让你的设计工作流进入 AI 时代（二）

源码解读

只看目录，只能证明“仓库里确实有东西”，就像看菜单不能证明菜是什么味道。下面直接挑几个真实文件，看模板究竟替 AI 预先做了哪些决定。

示例一：侧边导航模板已经处理交互状态

来源：SideLayout.tsx 第 19–70 行

interface MenuItem {
  id: string;
  label: string;
  icon?: React.ReactNode;
  children?: string[];
}

const SideLayout = ({ children }) => {
  const [collapsed, setCollapsed] = useState(false);
  const [openMenus, setOpenMenus] = useState(new Set(['menu2']));
  const [activeMenu, setActiveMenu] = useState('侧边菜单 1');

  const sidebarSections = [
    {
      title: '核心功能',
      items: [
        { id: 'menu1', label: '侧边菜单 1', children: [] },
        { id: 'menu2', label: '侧边菜单 2',
          children: ['子菜单 2-1', '子菜单 2-2'] },
      ],
    },
  ];

  const toggleSidebar = () => setCollapsed(!collapsed);
};

非技术解读：

• collapsed 记录侧边栏当前是展开还是收起；

• openMenus 记录哪些菜单组已经展开；

• activeMenu 记录用户当前选择了哪个菜单；

• sidebarSections 是需要被业务名称替换的示例菜单；

• toggleSidebar 负责切换侧边栏状态。

所以，这不是一张只能看的效果图，而是一个已经会展开、收起和记住选中项的页面外壳。AI 应保留这套状态结构，再把产品名、菜单和真实路由换进去。

示例二：复杂筛选模板已经固定容器与展开方式

来源：05-QueryFilter.tsx 第 9–36 行

<Card bordered={false} className="ds-search-panel ds-form-panel">
  <QueryFilter
    defaultCollapsed
    defaultFormItemsNumber={5}
    searchGutter={[24, 16]}
  >
    <ProFormText name="name" label="应用名称" />
    <ProFormDatePicker name="createDate" label="创建时间" />
    <ProFormText name="status" label="应用状态" />
    <ProFormText name="owner" label="负责人" />
    <ProFormText name="region" label="所在区域" />
  </QueryFilter>
</Card>

非技术解读：

• Card 提供白色搜索卡容器；

• QueryFilter 提供查询、重置及展开收起能力；

• defaultCollapsed 表示复杂筛选默认收起；

• defaultFormItemsNumber={5} 控制默认露出的字段数量；

• name、status、owner 等只是示例业务字段。

AI 真正需要做的是把这些字段换成客户、订单或工单的真实查询条件，再接上查询逻辑。搜索区长什么样，仓库已经替它少纠结了一轮。

示例三：批量操作表格提供了选择和提示结构

来源：04-BatchTable.tsx 第 113–168 行

<ProTable
  columns={columns}
  rowSelection={{
    selections: [Table.SELECTION_ALL, Table.SELECTION_INVERT],
  }}
  tableAlertRender={({ selectedRowKeys, onCleanSelected }) => (
    <Space>
      <span>已选 {selectedRowKeys.length} 项</span>
      <Button type="link" onClick={onCleanSelected}>
        取消选择
      </Button>
    </Space>
  )}
  tableAlertOptionRender={() => (
    <Space>
      <Button type="link">批量重启</Button>
      <Button type="link">批量下线</Button>
      <Button type="link">导出数据</Button>
    </Space>
  )}
/>

非技术解读：

• rowSelection 让用户可以选择多行数据；

• tableAlertRender 显示“已经选择多少项”以及取消选择；

• tableAlertOptionRender 放置批量操作入口；

• 模板中的“批量重启”和“批量下线”按钮没有真实业务处理函数。

最后一点很关键：这些按钮现在只是“长得像能干活”。谁能点、哪些记录能选、是否需要审批、失败后怎么恢复，都必须来自业务上下文并由项目代码真正实现。按钮有了，不代表业务就突然懂事了。

示例四：Token 把设计数值集中管理

来源：global-style.css 第 32–55、135–180 行

:root {
  --color-primary: #1677ff;
  --color-success: #52c41a;
  --color-warning: #faad14;
  --color-error: #ff4d4f;

  --border-radius: 6px;
  --border-radius-lg: 8px;

  --margin: 16px;
  --margin-lg: 24px;
  --padding: 16px;
  --padding-lg: 24px;
}

非技术解读：页面不应该随手发明颜色和间距，而应从这张“统一数值表”里取。这样即使不同页面由不同 AI 或开发者完成，也不至于一页像总部、一页像加盟店。

交互预览：代码看不懂没关系，直接看它跑起来

只读代码确实有点像拿着菜谱想象味道，所以报告同时配了一份可交互的本地预览：

预览页选择不同项目后，会在同一舞台中切换模板。它展示的是 7 个代表性场景，不是仓库全部 32 个 TSX 模板。

这份预览能够帮助非技术读者理解“模板”的真实含义：

模板源码
└─ 定义页面骨架、组件和通用交互

预览页面
└─ 展示模板运行后的可见结果

真实项目
└─ 在模板上替换业务字段、数据、权限和接口

预览页回答“最后长什么样”，源码回答“为什么会这样动”。一个看结果，一个拆机关，搭配阅读效果最好。

工作流程

识别任务是否属于覆盖范围

AI 根据用户请求判断是否属于管理后台、企业管理系统、表格页、表单页、列表页、详情页、数据看板等场景。

如果命中覆盖范围，则启用 Skill；如果属于未覆盖的低频组件能力，则可以回到 Ant Design 或 ProComponents 官方文档补充 API。

这类似先挂号再看病：AI 不该听见“做个页面”就条件反射地掏出 Ant Design，而要先判断这活是不是它的专业范围。

判断交付边界

接着是最容易出事故的一步：用户到底要整套后台、现有系统里的一页，还是一个局部组件？AI 会看两类信息。

首先读取用户表达：

• “从零搭建一个 CRM”通常表示需要完整应用；

• “在现有后台增加订单页”表示复用已有应用外壳；

• “只做一个筛选表格组件”表示只交付局部组件。

如果用户没有明确说明，AI 应继续检查项目：

• 是否已有 Layout 或 ProLayout；

• 是否已有路由；

• 是否已有侧边栏或顶部导航；

• 是否已有主题和 ConfigProvider；

• 当前项目是成熟应用还是空白脚手架。

判断原则为：

用户明确要求
    ↓
优先按用户要求执行
    ↓
用户未明确时检查现有工程
    ↓
最后才根据产品规模进行合理推断

对应结果包括：

• 从零新建完整中后台：生成导航框架和主内容区；

• 已有项目增加页面：复用 Layout、导航和路由，只实现内容区；

• 局部组件或单页 Demo：不额外生成完整后台外壳。

这里没有一个躲在幕后、永远正确的分类器。SKILL.md 只是给 AI 判断规则，AI 还要结合用户的话和工作区证据自己推断。证据不够时，正确动作应该是开口问，而不是自信满满地多盖一栋楼。

源码依据：仓库明确区分“从零新建”“已有项目新增页面”和“单页 Demo / 局部组件”三种边界，并规定相应情况下是否生成导航外壳。查看交付边界规则

源码片段（为便于阅读进行了换行）：

2. 判断交付边界：
- 0 到 1 新建：生成导航布局与主内容区
- 已有项目新增页面：复用现有 Layout / 导航 / 路由壳
- 单页 demo、局部组件：不强制生成导航

白话解释：AI 先判断用户要的是“整套房子”“在现有房子里装修一个房间”，还是“只做一件家具”。如果把一张桌子的需求理解成盖别墅，代码再漂亮也不能算超额完成。

选择一种导航布局

当任务需要应用外壳时，AI 根据系统复杂度选择：

Skill 要求选一种最匹配的布局，避免顶部导航、侧边导航和混合导航一起上阵，最后像三套导视系统在争夺方向盘。

导航布局可以类比商场的导视系统：小型商店只需要少量顶部入口，复杂商场则需要清晰的楼层和区域导航。

源码片段：

| 侧边导航 | 功能模块较多、信息层级较深 |
| 顶部导航 | 菜单项较少（≤9 个） |
| 混合导航 | 多个独立业务子系统 |

白话解释：这里提供的不是三个视觉皮肤，而是三个适用于不同信息复杂度的导航结构。查看导航选择源码

选择业务组件

AI 将需求映射到页面组件，例如：

• 查询条件 → 单行筛选工具栏或 QueryFilter；

• 结果数据 → Table、ProTable、List 或 ProList；

• 数据录入 → 基础表单、分步表单或嵌入表单；

• 对象详情 → Descriptions 或 ProDescriptions；

• 数据分析 → 图表和指标卡。

部分规则是条件化的。例如：

• 筛选项不超过 4 个且一行能清晰容纳：使用单行工具栏；

• 筛选项达到 5 个或需要展开收起：使用搜索卡承载的 QueryFilter。

QueryFilter 可以理解为一种专门处理复杂查询条件的高级筛选表单。上述数量不是本报告自行总结，而是仓库中的明确选择规则。查看筛选选型表

源码片段：

| 筛选项 ≤4 个 | 单行工具栏 |
| 筛选项 ≥5 个，或需要展开收起 | QueryFilter |

白话解释：条件少就轻装上阵，条件多再上复杂筛选区。三个输入框没必要搭一座“查询控制中心”。

按需读取对应规范

这套 Skill 个头不小，所以要求 AI 根据任务按需读取：

页面布局     → layout.md
表单         → components_Form.md
表格         → components_Table.md
列表         → components_List.md
详情         → components_DescriptionList.md
图表和指标卡 → components_Chart.md

这能避免 AI 一口气吞下整本手册，然后在真正开工时忘了自己刚才看过什么。

这与员工按任务查手册类似：做客户管理时不需要同时通读图表和登录页面的全部规定。

复制最匹配的代码模板

如果 scripts/ 已经有对应模板，AI 就该从那里起步，而不是每次都以“我有一个全新的想法”为由重造页面。

AI保留模板中的：

• 页面和 DOM 结构；

• 关键 className；

• 组件组合；

• 间距节奏；

• 交互分区；

• Design Token 用法。

然后再替换具体业务内容。

例如，客户批量分配页面可以从 04-BatchTable.tsx 开始。模板负责表格骨架和选择机制；用户的 PRD 或业务规格负责告诉 AI 哪些客户允许分配、谁有权限分配，以及失败后如何处理。

接入 Design Token 和全局样式

AI 需要将 global-style.css 复制到用户项目，例如：

src/styles/global-style.css

随后在应用入口全局引入，并根据项目情况配置 ConfigProvider 和 ProConfigProvider。复制模板后不能继续依赖 Skill 仓库内部的相对路径。

ConfigProvider 可以理解为 Ant Design 的“全局装修总控”：主题颜色、圆角等配置放在应用最外层，里面的页面统一执行，省得每个房间单独宣布审美主张。仓库给出了复制 CSS、全局引入和配置主题的完整清单。查看 Token 接入清单

源码片段：

import './styles/global-style.css';

<ConfigProvider
  theme={{
    token: {
      colorPrimary: '#1677ff',
      borderRadius: 8,
    },
  }}
>

白话解释：第一行加载统一样式；ConfigProvider 再把主色和圆角作为整个应用的公共设置。二者必须正确接入，否则模板虽然存在，页面也可能没有预期的视觉效果。

运行和验收

完成后应检查：

• 组件是否正常渲染；

• 控制台是否报错；

• 交互是否符合规范；

• 是否存在不必要的硬编码颜色；

• 是否使用 TypeScript any；

• 标题、面包屑和导航是否重复；

• 表格操作列是否换行或溢出；

• 分页和卡片间距是否重复叠加；

• Design Token 是否真正生效。

完整流程可概括为：

识别任务
  ↓
判断交付边界
  ↓
选择布局
  ↓
选择业务组件
  ↓
读取对应规范
  ↓
复制标准模板
  ↓
替换业务内容
  ↓
接入 Design Token
  ↓
运行与验收

这里的“运行”是真的把项目启动起来，不是盯着代码看两分钟以后宣布“理论上没问题”。按钮装死、样式没加载、页面溢出、控制台报错，这些都要跑起来才肯现身。

示例说明

假设用户提供：在现有 CRM 中增加客户列表。销售只能查看自己的客户，主管可以查看团队客户。支持按姓名、手机号和状态查询；主管可以批量更换负责人；已成交客户不能删除。

AI 不该直接冲去写代码，而要先把需求拆成两层。

业务层：由用户或 PRD 提供

• 角色：销售、主管；

• 数据权限：个人客户、团队客户；

• 查询字段：姓名、手机号、状态；

• 批量规则：只有主管可以更换负责人；

• 状态规则：已成交客户不能删除。

PRD 是 Product Requirements Document 的缩写，即“产品需求文档”。它负责说明产品为什么做、给谁用、有哪些规则。

界面实施层：由 Ant Design Skill 提供

• 发现项目已有 CRM 外壳，因此不重复生成导航；

• 三个筛选条件可在一行容纳，因此选择单行筛选工具栏；

• 客户数据使用表格展示；

• 批量更换负责人采用批量操作表格结构；

• 客户详情采用描述列表；

• 页面间距、卡片、圆角和颜色使用统一 Token；

• 生成后检查操作列、分页和权限入口是否正确。

最终结果不是 Skill 突然觉醒、无师自通了客户业务，而是三方拼图：

用户提供业务事实
        +
Skill 提供设计与实现方法
        +
AI 负责映射、编码和验证

工作原理

明确的执行规则

“做一个合理的筛选区”听起来很有道理，执行起来等于没说；“筛选项不超过 4 个且一行可容纳时使用单行工具栏”才是 AI 能照着判断的规则。

明确不同信息源的优先级

这套 Skill 先把信息来源的优先级排好了：

1. 已覆盖场景优先遵循 Skill；

2. 有模板时从模板开始；

3. 有规范但没有模板时按照规范生成；

4. 未覆盖能力再参考官方组件 API；

5. 官方文档补充 API，但不推翻 Skill 已定义的结构与视觉规则。

这相当于把裁判顺序先写清楚，减少 AI 今天参考这个示例、明天又被另一个页面带跑偏。

源码还规定生成结果必须写入用户工作区，而不是修改 Skill 自身。这保证“规范模板”和“具体项目代码”相互分离。查看输出规则

源码片段：

1. **禁止写入 Skill 目录**

白话解释：Skill 是公共母版，客户项目是使用母版生成的成品。AI 应该改成品，不能为了装修 301 室，顺手把整栋楼的施工图改了。

通过模板锁定基础结构

文字规范仍可能产生多种理解，而模板直接固定：

• DOM 和组件层级；

• 工具栏位置；

• 卡片结构；

• 关键类名；

• 常见交互；

• 间距来源。

AI 主要负责适配业务，不必每次重新发明页面骨架。自由度少一点，输出反而更稳定——这次“限制创造力”是优点。

通过 Design Token 统一视觉

不同页面共享颜色、间距、圆角和阴影变量，减少随意硬编码，使主题调整能够集中完成。

同时提供正向规则和禁止项

Skill 不仅说明应该怎么做，还明确禁止：

• 同一页面出现两套主标题；

• 一级入口页自动添加面包屑；

• 少量筛选项滥用复杂 QueryFilter；

• 同时使用内置和外置两套分页；

• 操作链接被压缩、裁切或换行；

• 页面级卡片采用不一致的圆角与阴影；

• 随意硬编码颜色。

例如，源码规定页面主标题只能有一个来源，避免布局层和页面层各显示一次标题。查看页面标题规则

源码片段：

7. **页面标题唯一来源**

白话解释：导航框架只提供菜单和内容容器，具体页面自己显示标题，避免用户看到两个相同标题。

禁止项的作用就是给 AI 的自由发挥装护栏。毕竟“有创意”用在海报上可能是夸奖，用在企业后台分页上通常不是。

用验收清单形成闭环

规则不能只在开工前念一遍，做完还得拿它回来对答案。这样 Skill 才从“告诉 AI 怎么做”，走到了“检查 AI 有没有真的做对”。