AI 设计系统在电商领域的落地复盘：挑战、经验与下一步

一、"三个月前我们开始用 AI 管理设计系统，现在它自己给自己提 PR 了"

回到三个月前的立项会议。产品负责人说："我们每周至少有一处 UI 不一致问题，设计系统定义了那么多 Token，前端还是在写硬编码的颜色值。" 设计师补充："每次新活动页上线，都要和开发对齐 30+ 个样式细节。"

那时候我们决定在三件事上引入 AI：Token 自动映射与漂移检测、组件 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=#FFFFFF=rgb(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 中修改 Token，AI 自动生成前端代码 PR。反之，前端在代码中新增组件变体，AI 自动生成 Figma 组件库更新请求。

多模态 UI 质量评分。结合截图（视觉质量）、DOM 结构（语义质量）、APCA 对比度（无障碍质量）、Lighthouse 性能分（加载质量）四个维度，为每个页面生成综合质量评分。

4.3 长期（6-12 个月）

设计系统的"数字设计师"。不是替代人类设计师，而是替代重复劳动——比如："为这个新类目生成 3 套配色方案，分别标注适用场景和 WCAG 合规情况，设计师做最终选择。"

跨团队设计系统联邦。不同业务线的设计系统独立演化，但通过 AI 检测"可合并的重复 Token"、"语义冲突的 Token 定义"——在团队级别做设计系统的治理。

五、总结

三个月 AI 设计系统的几点核心认知：

1. AI 做检测很靠谱——Token 漂移检测、UI 一致性巡检的准确率远高于人工
2. AI 做建议需要过滤——API 设计建议、规则演化建议，必须人类决策环节兜底
3. AI 做修复必须收敛边界——自动修复 Token 漂移只做"确定性的替换"，不做"模糊的推断"
4. 多模态是方向但不是银弹——截图 + DOM 双通道比单纯截图对比可靠得多，但仍然需要人工确认
5. 团队的接受度决定上限——做对了的技术能落地，需要设计师和前端愿意把它纳入日常流程

设计系统的 AI 化不是"用 AI 替代设计师"，而是"让设计系统的规则从文档变成代码，从建议变成门禁"。Token 应该是编译时报错而不是 Code Review 的口头提醒，UI 一致性应该是自动化巡检而不是上线后用户发帖吐槽。

三个月前，我们把它叫做"AI 设计系统"。三个月后，我更愿意叫它——设计系统的工程化。