宁波银行｜AI驱动的设计工作流

前段时间，我受邀为宁波银行设计团队开展了一场 AI 设计工具落地培训。

这次培训围绕 Figma、Codex 与 AI 设计工作流展开，主要讨论 AI 如何读取设计规范、复用已有资产、生成组件与页面，并参与后续的交互和设计交付。

从零基础 AI 课程，到一套完整工作流

这次培训中涉及的大部分方法和案例，其实都已经持续更新在我的零基础 AI 课程中。

在课程里，这些内容通常按照具体应用场景分别展开：

如何让 AI 读取 Figma 文件，如何整理设计规范，如何搭建组件，如何生成页面，如何把效果图转成可编辑资产，以及生成结果出现问题后该怎样处理。

为了适应企业设计团队的培训场景，我重新梳理了这些内容之间的关系。

原本分散在不同章节和案例中的实践，被重新串联成一套完整的 AI 设计工作流程：

先让 AI 理解团队的设计规则与现有资产，再使用这些规则生成组件和页面，最后通过设计师的检查与修正，持续沉淀新的规则。

这次整理的重点，也从单个工具的操作，转向 AI 如何真正进入一套已有的设计体系。

这次培训主要讲了什么

整场培训从传统设计系统如何适配 AI 开始。

设计团队通常已经拥有颜色、字体、间距、组件和页面规范。很多规则依赖团队长期形成的经验，并没有被完整写入文档。

当 AI 开始参与设计工作，这些经验需要逐渐转化成它可以读取和执行的内容。

在培训中，我围绕这条主线，演示了如何整理底层设计规范、建立组件资产索引、生成复合组件和页面，以及怎样把效果图转换成可编辑的 Figma 资产。

最后又延伸到交互状态、页面连线和设计交付。

技术内容很多，核心一直围绕同一个问题：

AI 如何基于团队已有的规则和资产工作。

培训现场的交流，也逐渐从工具操作进入了更具体的企业落地问题。

成熟的设计团队，为什么还需要 AI 创建资产？

对方领导首先提出了一个很实际的问题：

一个成熟产品通常已经有对应的变量、样式和组件。新产品也可以基于 Ant Design 等开源组件库进行定制，什么情况下还需要 AI 创建底层设计资产？

这个问题让我进一步补充了两类使用场景。

• 第一类是从 0 到 1 的新建。
• 第二类是成熟体系中的持续迭代，包括整理存量规范、补充变量、扩展组件、创建复合组件，以及完成大量重复的绑定和检查工作。

对于已经拥有成熟设计系统的团队，AI 的价值更多体现在读取、整理、审查、补充和批量执行。

团队现有的设计系统依然是标准，AI 在这个标准下帮助设计师减少重复工作。

AI 能理解团队默认的设计规则吗？

另一个让我印象很深的问题，是关于团队内部长期形成的设计经验。

对方以 Tab 为例。

同样是 Tab，可能存在页签式、下划线式和胶囊式等不同形式。它们适用于不同的页面层级和嵌套关系。

团队里的设计师通常知道应该怎样使用，但这些规则很难被完整描述出来。

AI 可以读取 Figma 中的图层、节点、组件和页面结构，但读取到内容，并不等于理解了内容背后的使用语义。

针对这类很难直接写成文档的经验，我提出了一种方式：

先选择具有代表性的典型页面，让 AI 同时读取页面的视觉效果和图层结构，再输出它对组件使用方式、层级关系和嵌套逻辑的理解。

设计师不需要从空白开始写出所有规则，只需要判断 AI 总结的内容是否准确，并对错误部分进行调整。

确认后的内容再沉淀为设计文档或 Skill，供之后的页面生成继续使用。

这个过程也体现了 AI 参与设计系统建设的一种方式：

由 AI 完成初步整理，设计师负责判断和校准。

高保真的 HTML，可以直接交付给研发吗？

在展示页面生成流程时，对方领导还提出了一个关于交付形式的问题：

如果 AI 已经可以生成高保真、具备交互和响应式能力的 HTML，项目又没有强制要求必须保留 Figma 设计稿，是否可以直接将 HTML 交给研发？

这个问题让讨论进一步进入了设计与研发之间的协作方式。

HTML 可以更完整地表达页面的视觉效果、响应式布局和交互状态，也可以作为一种可运行的设计原型。

独立生成的 HTML 和真实项目中的前端工程之间，仍然存在工程化处理。

真实业务通常还涉及团队组件库、项目框架、接口、权限、状态管理和代码规范。

因此，HTML 可以成为新的设计交付载体，具体能否直接进入研发流程，需要设计和开发团队共同定义标准。

这也意味着，未来的设计交付可能不再只有静态设计稿一种形式。

Figma、可交互原型与代码可以承担不同阶段的作用。

AI 能补充真实业务中的交互吗？

在培训最后，对方领导继续追问：

如果 AI 已经了解一个组件的交互状态，同时再提供具体业务逻辑，它补充页面交互的准确率怎么样？

对于加载、空状态、弹窗、抽屉、表单校验等常见交互，AI 已经可以根据通用规律完成初步补充。

银行业务中的交互会涉及更多具体条件，比如权限、业务状态、流程判断和特殊例外。

这些内容需要提前以需求文档、业务规则或知识库的形式提供给 AI。

即使规则已经被提供，最终结果依然需要产品和设计人员检查。

对方也提到，设计师目前需要阅读大量 PRD，再将其中的业务内容对应到页面、组件和交互中，这个过程容易遗漏细节。

AI 可以参与前期的需求阅读与信息整理，再结合已有设计资产生成初步方案。

这类能力的价值，可能并不只在于生成页面，还包括帮助设计师处理需求、规则与设计资产之间的关系。

企业团队关心的，已经不只是生成效果

这次培训中，对方提出的问题都围绕真实工作展开：

成熟体系如何使用 AI，团队经验怎样被 AI 理解，HTML 是否会改变设计交付，以及业务交互需要怎样提供给 AI。

这些问题也让我感受到，企业设计团队关注的重点已经逐渐发生变化。

大家更关心 AI 能否读取现有规范、复用团队资产、理解业务规则，并进入真实的协作与交付流程。

一个页面能不能生成出来，只是开始。

一次阶段性的整理

过去一段时间，我一直在零基础 AI 课程和自己的项目中，持续研究 Figma、Codex 与设计工作流之间的关系。

这次前往宁波，我将课程中原本分散的案例与方法重新整理，第一次以一套完整工作流程的方式，带到企业设计团队的培训现场。

现场提出的这些问题，也让我重新检查了这套方法的适用场景和实际边界。

这次培训既是一次分享，也成为了我对过去一段时间实践内容与零基础AI课程的一次阶段性整理。

记录一下这次宁波之行。