AI 设计系统在电商领域的落地复盘挑战、经验与下一步一、三个月前我们开始用 AI 管理设计系统现在它自己给自己提 PR 了回到三个月前的立项会议。产品负责人说我们每周至少有一处 UI 不一致问题设计系统定义了那么多 Token前端还是在写硬编码的颜色值。 设计师补充每次新活动页上线都要和开发对齐 30 个样式细节。那时候我们决定在三件事上引入 AIToken 自动映射与漂移检测、组件 API 设计建议、UI 一致性巡检。现在回头看有些做对了有些踩了坑有些根本不该用 AI 去碰。这篇文章不是我们做到了的胜利宣言而是三个月电商设计系统 AI 化的一次诚实复盘。二、做对了什么2.1 Token 漂移自动检测——ROI 最高的投入设计 Token 漂移是最常见的质量问题设计师在 Figma 里改了主色#1890FF→#1677FF前端仍然写的是旧的硬编码#1890FF。AI 的介入方式很简单每日定时扫描所有代码仓库用 AST 解析提取所有颜色值与设计 Token 的正式值做模糊匹配色差 5 的视为可能是 Token 但写成了硬编码生成差异报告并自动分配 Issue。这个功能上线第二周就发现了 47 处硬编码颜色——其中 12 处已经在线上生效了三个月。2.2 组件文档自动生成——消除了设计与前端的信息断层传统流程设计师在 Figma 说明文件中写组件用法 → 前端看不看全凭自觉。AI 的做法从 Figma 组件描述 前端组件的 Props 类型定义中自动聚合生成交互式 Playground 文档。每个 Token 的可选值、每个 Prop 的作用、变体之间的差异全在一个页面里。效果新入职的前端看一遍 Playground 就能上手写组件不需要追着设计师问这个间距到底用 8 还是 12。2.3 UI 一致性巡检——在大促前的最后一道防线双十一前夜AI 巡检脚本跑了一遍所有活动页发现两个问题秒杀模块的倒计时颜色在 H5 和小程序上不一致一个用#FF0000一个用#FF3300、商品卡片的阴影值在 iOS 和 Android 上分别为blur(8px)和blur(12px)。这些问题人工走查几乎不可能发现——光是检查 80 活动页的跨端一致性就够一个 QA 忙三天。三、踩了什么坑3.1 AI 设计建议没被采纳过模块四花了大量精力做AI 驱动的组件 API 设计建议——分析组件的使用频率、命名一致性、参数排列顺序然后给出优化建议。逻辑是对的数据是准确的但建议一次都没被采纳。原因组件的 API 设计不仅要考虑使用频率和命名一致性还要考虑向后兼容、团队认知习惯、上游依赖——这些信息 AI 拿不到。AI 能告诉你isLoading比loading更符合团队规范但它不知道改了命名会影响 200 调用点、需要跨 3 个仓库协调发版。教训API 设计建议不是纯技术分析问题是组织协调问题。AI 能做分析但决策必须人来做。3.2 Token 自动修复的 PR 被 CI 打回来了上线了AI 自动提交 Token 漂移修复 PR后第一个 PR 就被 CI 打回来了——AI 把Button组件的color: #fff替换成了 Token--color-white但--color-white的定义是#FFFFFF而不是#FFF导致 Button 文本颜色变成了背景色整页白屏。教训颜色值的匹配需要做归一化处理#FFF#FFFFFFrgb(255,255,255)且自动修复仅限于语义明确的场景如主色→--color-primary。凡是二义的替换多个 Token 的色差都 5必须人工确认后才能合并。3.3 截图对比的误报率一度高达 60%跨端 UI 差异检测用了截图 DOM 双通道方案。截图通道使用像素对比DOM 通道使用结构化对比。第一版截图对比的阈值设得太低——连 1px 的字体渲染差异都被判为不一致。调整方案忽略 antialiasing 导致的亚像素差异允许 ±1px、忽略字体渲染引擎差异中文字体在不同 OS 上的渲染宽度允许 ±2%、只对布局结构差异元素缺失、位置偏移 5px、尺寸差异 10%告警。调整后误报率降至 8%但需人工确认每一条告警——在真实的电商环境中没有零误报的图片对比。3.4 设计系统AGI 化步子太大第三个月尝试了设计规则的 AI 自主演化——让 AI 分析三个月的历史 Issue总结出新的设计规则并自动加入系统。结果是 AI 提出了一条规则所有按钮的最小点击区域应该 44px——但我们的设计系统明文规定最小 48px。AI 从 Bug 数据中学到了一条被违反的规则误以为是新发现的规则。教训AI 扮演执行者和检测者是合格的但扮演规则制定者还太早。规则的来源只有两个设计师的意图和用户的行为数据。AI 可以帮助分析数据、发现模式但这条规则该不该加入设计系统必须人类做最终决策。四、下一步4.1 短期1-2 个月AI 代码审查集成到 Git Hook。现在 AI 代码审查是定时任务放到 Git Hook 中实时拦截——在pre-commit阶段检测硬编码颜色和非法 Token 使用不通过不允许提交。Token 使用热力图。统计每个 Token 在代码中的使用频率和分布帮助设计师判断哪些 Token 可以废弃、哪些需要拆分为更细粒度的变体。4.2 中期3-6 个月Figma → 代码的双向同步。设计师在 Figma 中修改 TokenAI 自动生成前端代码 PR。反之前端在代码中新增组件变体AI 自动生成 Figma 组件库更新请求。多模态 UI 质量评分。结合截图视觉质量、DOM 结构语义质量、APCA 对比度无障碍质量、Lighthouse 性能分加载质量四个维度为每个页面生成综合质量评分。4.3 长期6-12 个月设计系统的数字设计师。不是替代人类设计师而是替代重复劳动——比如为这个新类目生成 3 套配色方案分别标注适用场景和 WCAG 合规情况设计师做最终选择。跨团队设计系统联邦。不同业务线的设计系统独立演化但通过 AI 检测可合并的重复 Token、语义冲突的 Token 定义——在团队级别做设计系统的治理。五、总结三个月 AI 设计系统的几点核心认知AI 做检测很靠谱——Token 漂移检测、UI 一致性巡检的准确率远高于人工AI 做建议需要过滤——API 设计建议、规则演化建议必须人类决策环节兜底AI 做修复必须收敛边界——自动修复 Token 漂移只做确定性的替换不做模糊的推断多模态是方向但不是银弹——截图 DOM 双通道比单纯截图对比可靠得多但仍然需要人工确认团队的接受度决定上限——做对了的技术能落地需要设计师和前端愿意把它纳入日常流程设计系统的 AI 化不是用 AI 替代设计师而是让设计系统的规则从文档变成代码从建议变成门禁。Token 应该是编译时报错而不是 Code Review 的口头提醒UI 一致性应该是自动化巡检而不是上线后用户发帖吐槽。三个月前我们把它叫做AI 设计系统。三个月后我更愿意叫它——设计系统的工程化。
