DESIGN · AI WORKFLOW

设计侧 AI 工作流
方案与思考

在已有 SDD 全流程之上，补齐尚未被覆盖的设计环节，建立一条标准化、可复用、带质量门的设计侧 AI 设计生产流程。

总览

两条并行泳道

整体可视为两条并行泳道：上为本方案的「设计侧 AI 工作流」，下为现有「基于 PM-SPEC 的全流程 AI 工作流」，两者经 PM-SPEC 与交付节点相接。

设计侧 AI 工作流图
图 1 · 设计侧 AI 工作流：PM-SPEC 输入 → pull-design-context → Figma MCP 搭建 → review-ui-spec 质量门 → 交付前端
产品侧 AI 工作流图
图 2 · 现有 SDD 全流程：需求 → vue-prototype-generator 产出 原型 + PM-SPEC + decisions
摘要

一页读懂

Summary

在原有 SDD（规格文档驱动开发）的全流程 AI 工作流——从原始需求出发，由 AI 同时产出 Vue 原型、结构化页面规格（PM-SPEC）与后端规格，跑通了「需求 → 原型 / 前端 / 后端」。这套流程当前已能产出大致可用的 CRM 界面。

本方案在此基础上，补齐其中尚未被覆盖的设计环节，建立一条设计侧的 AI 设计生产流程：以现有流程产出的 PM-SPEC 为输入，依托设计系统（范式库 + 组件库 + 规范），用 Figma MCP 由 AI 驱动页面搭建、设计师精修，再经一道设计质量门（review-ui-spec）审查后交付前端。

它的定位是衔接与补强，而非替代：复用现有流程的核心节点，不改动工程链路，可独立服务当前真实在跑的「PM → UI/UE → 前端」业务线，未来也可与 SDD 流程合并。其核心价值在于：AI 在无设计治理时能产出约 7 分的界面，剩下决定体验的 3 分——信息层级、状态完整性、交互细节——正是需要设计标准 + 质量门才能稳定补齐的部分。

01

背景与目标

现状。SDD 全流程 AI 工作流：人写原始需求（文字 / 截图 / Figma URL）→ AI（vue-prototype-generator）在一轮内同时产出 Vue 原型、路由、PM-SPEC（结构化页面规格）与决策记录 → PM-SPEC 再分别被下游消费，生成 API 契约与后端 dev-spec。该流程已能跑通主链路并产出可用界面。

缺口。这套以工程为主轴的流程中，设计（UI/UE）环节没有被显式建模：界面由 AI 直接生成、由代码侧审查，缺少一道面向「信息架构、状态完整性、交互与体验一致性」的设计治理。结果是界面整体可用，但存在可观测的体验问题。

目标。建立一条设计侧的 AI 设计生产流程，使设计环节同样 AI 化、标准化、可复用，并在交付前补上设计质量关卡。该流程需满足：

  • 能服务当前真实在跑的业务线（PM → UI/UE → 前端），不依赖 SDD 流程完全落地；
  • 与现有 SDD 流程可衔接、不冲突，复用其产出而非重造上游；
  • 让设计的工作内容从「产出像素」上移到「定义什么是好，并让 AI 稳定达到这个好」。
02

定位：与现有 SDD 流程的关系

设计侧流程不另起需求上游，而是接在现有流程之后、消费其结构化产出：

  • 输入源 = PM-SPEC。现有流程的 generator 已把需求结构化为 PM-SPEC（§1 页面概要：业务用途、目标用户；§4 Zone 规格：各区域展示什么、有哪些状态与操作）。设计流程直接消费 PM-SPEC，需求经由它间接、完整地传导给设计——设计不是「什么都不知道就自动化」。
  • 复用核心节点。新流程沿用现有流程中「以 PM-SPEC 为中枢、按 Zone 组织信息」的核心机制，并保持与工程链路对齐，避免在工程侧重复造轮子或产生分叉。
  • 非侵入式补充。设计流程在现有链路旁新增设计系统支撑与设计质量门两段能力，不改动原有的原型 / 前端 / 后端生成逻辑。
一句话定位：现有 SDD 流程负责「把需求变成可运行的东西」，设计侧流程负责「让交付物在体验上达标」，两者通过 PM-SPEC 衔接。
03

设计侧 AI 工作流详解

五步链路，从消费 PM-SPEC 到交接前端，中间以一道设计质量门构成回环：

1

输入：消费 PM-SPEC

以现有流程产出的 {feature}-{page}-PM-SPEC.md 为设计起点。PM-SPEC 已结构化承载页面意图与各区域（Zone）的展示要素、状态与操作，是设计的需求载体。

2

拉取设计上下文 · pull-design-context

搭建前拉取三类设计依据：产品风格范式库（该用什么页面范式）、组件库（用哪些构件）、规范。命名取 "context" 而非 "assets/token"，因为它拉取的不只是素材，还包括「该套用何种范式」的判断依据。

3

Figma MCP 驱动搭建 · AI 搭建 + 设计师精修

由 Claude 通过 Figma MCP 依据 PM-SPEC 与设计上下文搭建页面。此环节是协作而非全自动：AI 完成结构与初稿，设计师负责体验细节、边界状态与视觉调性的收口。

4

设计质量门 · review-ui-spec

对设计产物按设计审查规范逐项检查（信息架构、状态完整性、交互、UX 文案、可访问性、视觉一致）。不通过则回退 Step 3 重新搭建，形成质量回环；通过才放行。

5

标注 / 规格交付 → 交接前端

审查通过后产出标注与交付规格，交接前端开发。

04

支撑：设计系统三层心智模型

设计流程的产出质量依赖一套分层清晰的设计系统。三层自底向上：

层级对应 skill内容说明
③ Pattern
页面范式·最大粒度		design-pattern-library归纳公司各产品成型页面（dashboard / 列表 / 表单）的风格范式与视觉调性现存且可延展的「成型样板」
② Component
构件		design-component-libraryFigma 业务组件库 + Element Plus 官方组件库及规范拼装页面的零件
① Token
原子·最小粒度		（并入 ②，不单列）色彩 / 间距 / 字号沿用 Element Plus，不自建；明示但不单列 skill

依赖关系：范式库（③）建立在组件库（②）之上——页面范式是用组件拼出来的成型样板。即「组件库是构件、范式库是用构件搭的成型样板，后者依赖前者」。Token 沿用 Element Plus 既有体系，不另立工作量。

05

质量门：为什么需要一道独立的设计审查

5.1 它和工程侧已有的审查不重复

现有体系中存在代码侧与规格侧的审查，但都不覆盖设计质量。三者对象、判据、所防风险完全不同：

review-ui-spec
设计侧·本方案		review-vue-code
工程侧·现有		spec-consistency-review
规格侧·现有
审查对象设计产物（Figma / 高保真）代码实现（Vue）PM-SPEC 内部字段
审查内容信息架构、状态完整性（空 / 错 / loading）、交互、UX 文案、可访问性、视觉一致组件用法、props、状态管理、性能、工程规范规格前后字段是否一致、有无冲突
防的是「做了个错的东西」（方向 / 体验错）「把东西做错了」（实现错）「规格自己矛盾」

5.2 现有界面上可观测的改进点

在当前 CRM 界面上可以直接观察到以下问题——它们恰好说明：缺少设计质量门时，AI 产出会落在哪些位置。这里作为改进价值的客观依据，非对既有成果的否定：

当前 CRM 界面截图
图 3 · 当前 CRM Dashboard 界面，标注若干可观测的体验改进点
  • 调试残留进入界面：如「⚠ 模拟错误 / Gerente 视图」等调试态常驻可见；
  • 状态设计缺失：部分区域缺空状态 / 加载 / 错误态；
  • 信息层级问题：Dashboard 出现主标题重复的同名卡片（「CLIENTES 8」与「CLIENTES 0」主标题相同，难以区分）；
  • 无意义的数据可视化：Crédito 列出现全 0 / 固定 77 的进度条，不传达有效信息；
  • 语言一致性：存在中西文混排。

5.3 设计审查规范 v1 · design-review-spec

基于上述真实界面问题倒推，形成 6 大类审查项，兼作 AI 审查规则与人工 checklist：

  • 0 · 调试残留与环境污染（阻断级）
  • 1 · 信息架构与层级（最高权重，也是 AI 最易失分处）
  • 2 · 状态设计完整性（空 / 加载 / 错误 / 部分数据 / 极值 / 权限）
  • 3 · 交互与操作
  • 4 · UX 文案（语言统一，禁中西混排）
  • 5 · 可访问性与视觉基础
06

价值与产出

这套流程让设计的角色发生上移——从「产出像素」转为「定义什么是好，并让 AI 稳定达到这个好」。具体价值锚点：

01

标准的定义者

简报模板、信息架构规则、设计审查规范、设计系统分层，均由设计定义，AI 仅执行。

02

质量门的把守者

可量化产出——拦截的问题数、消除的存量设计债务数，是可度量的交付指标。

03

体系的设计者

交付的不只是「用 AI 出图」，而是一套可复用的设计生产流程。

核心论点：AI 能产出 7 分界面，恰恰证明「无设计治理的 AI 流程有明确上限」。

7 → 9 分的差距——状态完整性、信息层级、交互细节、视觉收口——是 AI 在无标准约束时补不全、需要设计治理与人工精修才能稳定达成的部分。设计的价值不被 AI 取代，而是被 AI 放大并前移到「标准与治理」。

07

下一步

  • 盘点并建立 design-pattern-library：盘点公司各产品现存页面，归纳风格范式形成范式库。
  • 实现 review-ui-spec skill：可参照现有 spec-consistency-review 的结构落地为可执行审查。
  • Figma MCP 搭建环节的协作边界：明确标注「AI 搭建 + 设计师精修」，避免被理解为全自动。
  • 探索双关卡深化：在 PRD 阶段做设计规范「事前注入」（预防）+ PM-SPEC 阶段「事后审查」（拦截）的双重关卡（讨论方向，未在 v1 定稿落地）。
附录

名词与产物对照

名词含义
SDDSpecification-Driven Development，规格文档驱动开发
PM-SPEC结构化页面规格（如 crm-dashboard-PM-SPEC-v2.md），设计流程的输入源
pull-design-context拉取范式库 + 组件库 + 规范，喂给搭建环节
design-pattern-library页面范式库（③ 层）
design-component-library业务组件 + Element Plus 组件及规范（② 层，含 ① Token）
Figma MCPClaude 驱动 Figma 页面搭建的能力
review-ui-spec设计质量门 / 设计审查 skill
design-review-spec设计审查规范 v1（6 大类，AI 规则 + 人工 checklist）
设计侧 AI 工作流 · 方案与思考 · v1 定稿