AI 设计生产线

输入一份需求，拿回能交付的前端

全部设备页，React + shadcn 版本
全部设备页，Vue3 + Element Plus 版本
全部设备页，React + antd 版本

在职时，我把 AI 引入设计流程。离职后，把这套做法做成了一个工具：设计规则写成项目合同，AI 按合同生成页面、过检查，交出能打开、能安装、能接着改的前端。

7条链路 从需求、Figma 规范、参考图到大屏，七条工作链路全部跑通
3×14 同一套 14 页后台，antd、shadcn、Element Plus 三个组件库各做一遍
93/93 三端跑同一套行为断言，每端 93 条全部通过
  • ROLE独立设计与实现
  • TIME在职期间引入 AI 工作流 · 2026 年工具化
  • PLATFORMWeb（React / Vue3）· Figma

01Context

AI 出页面不稳定，根源是输入没有结构

“间距紧凑一点”“风格统一一点”，对人有用。对 AI 来说，缺规则、缺边界、缺检查标准。直接让它出页面，常见的问题是用错组件、编出后端没有的字段、带筛选的表格漏掉空状态。

我的判断是：AI 提高的是探索和生产效率；定义问题、制定规则、写清楚哪些不能做、把控质量，仍然是设计师的事。

直接让 AI 还原页面往往要返工四五轮

先把页面结构拆清楚，再生成降到一两轮

在职时的估算，依据项目沟通记录。

做这个工具时，先定了四个承诺

用的人是已经在用 Coding Agent 的设计师。他们常遇到的问题：生成结果偏离 Figma、漏状态、误用组件、改了没法稳定写回源码。

  1. 01开工前少猜会改变方案的歧义，先问清再动手
  2. 02生成中可接管随时暂停、改约束、缩小范围、回退
  3. 03交付后可修改真实页面像设计工具一样能选中、试改、写回源码
  4. 04完成有证据设计来源、决定、代码改动和验收结论能互相追溯

02Pipeline

输入一份需求，拿回能交付的前端

一条需求进来，先和项目合同放在一起。AI 读完该读的文件再生成，生成完要过三道检查。检查不过就停，问题写回出错的那一层。

一条需求从输入到交付 五步：需求和项目合同；CLI 一条命令编译这页要读的文件；AI 按规则和 Skills 生成；构建、浏览器、视觉三道检查；交付页面、Figma、package 或独立工程。第一步和最后一步由设计师把关。检查不过时，问题写回所属的那一层。 INPUTCLIGENERATECHECKDELIVER 需求 + 项目合同编译上下文AI 生成三道检查交付 锁定组件底座、设计来源和验收方式 一条命令列出必读文件，带路径、哈希和原因 按规则与 Skills 生成，三种输出模式 构建、浏览器交互、视觉比对，不过就停 页面、Figma、package、独立工程 设计师定标准 设计师签收 检查不过：问题写回需求、规则、组件或实现中出错的那一层
CLI

AI 开工前，
先知道该读哪些文件

交给 Claude Code、Codex 这类 Agent 做页面，它常常漏读规则，或者自己补假设。

所以 kit 带一条只读命令。给出项目和页面，列出这页必须读的文件，每个都带哈希和读取原因。引用的文件对不上，命令直接报错，不让开工。

$ npm run ai-readable -- inspect --page device-list实跑输出
"status": "ready""requiredReads": 16 个文件，节选：business-context.json项目合同98a428a5…pages.json页面合同b96cfbc9…flows.json流程合同7c4a342d…antd-6.5.0-….json设计包352b149e…recipes/list-page.md列表页配方9648fcda…rules/anti-patterns.md反例规则4cafb0e5…"implementation": "needs-task-contract"

同一套做法，铺成七条链路

输入不同，交付物不同，合同和检查是同一套。

  1. 01需求 → 可运行页面输入需求文档、项目合同交付可交互页面和可部署 build已跑通
  2. 02Figma 组件库 → 新页面输入Figma 文件、页面简述交付真实组件搭的 Figma 页面已跑通
  3. 03PRD + antd → 校准页面输入PRD、Figma 文件交付可交互页面和校准后的 Figma 节点已跑通
  4. 04Figma 规范 → 代码底座输入Figma 设计规范交付可安装的包和组件目录已跑通
  5. 05设计系统从 0 到 1输入设计简述交付规范站和 package已跑通
  6. 063D 态势大屏输入大屏简述交付可全屏运行的大屏和 build已跑通
  7. 07参考图 → 页面输入参考图、视觉方向交付可交互的重建页面已跑通

03Decisions

规则的价值，看它能不能跑起来

01

先冻结合同，再生成

每个项目先用一份合同，锁定需求、组件底座、设计来源和验收方式。生成的人和验收的人，对着同一个标准。

  • CONTRACT项目合同：需求 · 组件底座 · 设计来源 · 验收方式
  • 01生成
  • 02构建
  • 03浏览器检查
  • 04视觉检查
02

改一个 Token，
不该牵动整个组件库

中间 Token 只负责视觉这一层。控件规格、结构合同和共用的业务逻辑各是一层，三个组件库各用一套适配去读它们。最后，三端完成了一致性专项。

四层共享源，三个组件库 左边四层共享源：视觉层是 136 个中立 Token，控件层是 23 种控件规格，结构层是结构合同，逻辑层是 14 个页面控制器组成的共用业务核心。右边 antd、shadcn、Element Plus 三个组件库都读这四层。 SHARED SOURCE 视觉中立 Token 136 个 控件控件规格 23 种 结构结构合同 逻辑共用业务核心，14 个页面控制器 只管这一层 FOUNDATIONS antdReact · 基准 shadcnReact Element PlusVue3
03

坏案例不进库

组件和页面必须经过人工 review 才进库，免得后面的生成照着错的学。

我优先把失败写成“别这么做”的清单。正面原则模型大多本来就懂，真正值钱的是负面边界。

  • 确认文案只写“确定要删除吗？”，不写对象、数量和后果。
  • 列表已被“运行异常”视图过滤，阶段条仍显示全量计数，点选后得到空结果。
  • 紧急场景要求多轮确认；或界面写“正在核验”，后台并没有对应检查。
  • kit/rules/interaction-decisions.md · 反例节选
04

问题写回它所属的那一层

生成的列表页，行操作按钮越堆越多。判断下来，问题出在规则层，组件本身没毛病。

于是在交互规则里加一条。当时已有的 6 个列表页一起统一，之后新生成的页面也按这条走。

kit/rules/interaction-decisions.md提交 9fffaf3
## 5. 行操作：查看加至多两个当前状态动作适用条件：列表或表格的行内操作列，操作随记录状态变化（状态机驱动）。露出「查看」加至多 2 个当前状态下可执行的动作；超出的收进「更多」下拉。露出哪两个，按当前状态下的使用频率排，高频在前；危险动作不排第一个。「查看」在首列已有链接进入同一详情时可以省略，省下的位置不补新动作。
How规则怎么分层、怎么交给 AI

规则分六层：

  1. Design Tokens
  2. 组件调用规则
  3. 页面结构模板
  4. 状态反馈规范
  5. 异常处理规则
  6. 交付走查标准

例如 Button.Primary 单页 ≤ 1、Snackbar 必含结果 + 可撤销动作、Drawer 承载低频详情。异常提示必须讲清四件事：发生了什么、对用户的影响、下一步做什么、系统已经做了什么保护。

Figma 到代码：限定单画布范围，检查图层结构，节点数据和截图一起给；设计组件和代码组件的名称、变体、属性逐一对齐。前一个 Agent 先输出结构拆解和缺失信息，后一个 Agent 再生成，缺依据的地方标“待确认”。

规则封装成 Skills，每个包含流程、规范、模板和脚本。确定的逻辑交给脚本，判断和表达留给模型。

把界面拆成视觉、控件、结构、逻辑四层，并把它用到天安精灵运营后台的 14 个页面路由上，加上行为断言。

调优的通用做法：没识别出场景，补触发条件；乱用组件，补调用规则；漏了异常，补检查清单；同一个错误反复出现，写进规范；重复且规则明确的任务，改成脚本。

04Editor

不写代码的人，也能一块一块改页面

生成完的页面，产品经理、项目经理和新人也要改。编辑器在真实运行的页面上选、改、预览，确认之后才写进源码。

区块替换：筛选区换成“三个常用筛选”的版本，先在画布里预览，确认后再写入
  1. 01选中一块，说清能做什么

    点页面上的区块，右栏写出它叫什么、能做什么：替换、新增同类、删除、上移、下移。

  2. 02改之前，先看影响面

    改一个全局值之前，先提示“会影响 14 个页面、1027 处”，可以展开看是哪些。

  3. 03Token 带护栏

    字号只能走阶梯。文字和底色的对比度低于 4.5:1，不让写入，并给建议色。

  4. 04交给 AI 写回源码

    预览好的改动交给 AI 改写源码，改完自动跑项目检查。检查不过就撤销，文件逐字节还原。

首屏：画布里跑的是真实项目，右栏常显影响面
颜色：每组前景和背景标出对比度，偏低的给建议色

AI 用的是本机 DeepSeek V4.1 Flash。

05Delivery

交付物要能打开、能安装、能接着改

截图和报告只算证据。每条链路结束时，先交一样能直接用的东西。

  • PAGE可打开的页面

    浏览器里直接点，附可部署的 build

  • FIGMAFigma 节点

    用真实组件搭，写入后回读核对

  • SPEC规范站

    规则、Token、组件说明放在一起

  • PACKAGE可安装的包

    带安装命令和示例，换个目录能装能构建

  • EXPORT独立工程

    一条命令导出，附后端交接包

EXPORT

导出的工程，
离开 kit 也能跑

运营后台可以一条命令导出成独立工程。导出后单独安装、类型检查、构建都通过，15 个路由的浏览器断言通过，构建产物里没有编辑器的标记。

交给后端的部分一起打包：接口提案、模拟数据、权限表、接入说明。从页面推断出来的接口，标“待后端确认”。

tianshu-device-ops/导出结果
  • src/页面源码，独立挂载入口
  • handoff/后端交接包
    • openapi.yaml接口提案
    • API-CONTRACT.md20 处标“待后端确认”
    • PERMISSIONS.md权限来源与待确认矩阵
    • INTEGRATION.md接入位置与复验清单
    • mock/15 份模拟数据
    • source-contracts/生成时用的合同副本
  • verification/浏览器验收记录与截图
  • EXPORT-MANIFEST.json每个文件的 SHA-256

06Evidence

换组件库、换技术栈，规则还管用

Case A 里的运营后台，是用这条线生成的。同一份合同下面分出三支：换组件库、换技术栈、复用到新产品。前两支用来检验规则有没有绑死在某一个组件库上，初测的失败和最后的通过都留着。

ONE SOURCE 天安精灵 · 运营管理平台

一份业务事实，三份签字规格：136 个 Token、23 种控件、结构合同

01 · 换组件库

三个组件库，同一套 14 页

  • antd基准
  • shadcnReact
  • Element PlusVue3

控件规格、行为断言、视觉容差，三端用同一套检查验收。

02 · 换技术栈

同一个老后台，三个版本

  • 旧写法Vue 2 + element-ui
  • React 重写390/390
  • Vue3 迁移13/13

先把旧版的行为写成断言，两个重写版用同一套断言验收。

03 · 复用到新产品

抽出共享层，长出三个平台

  • 漏洞扫描19 页
  • 智能护网13 页
  • 零信任3 页

10 个组件和一个应用壳原样抽出来，三个平台直接引用。前两个的界面见 Case A 同类项目。

下面放大前两支。

同一套 14 页，三个组件库各做一遍

初测4,667

处属性差异

14 条路由，每端 461 个测点，shadcn 几乎全部对不上

控件1,882

项控件规格

三端各 1,882 项全部通过

行为93/93

条行为断言

三端同一套断言，全部通过；失败即中断的检查串在一起

视觉0.6px

几何容差

视觉看齐 antd，4px 以上的差异两端都是 0

初测时 shadcn 还是默认样式，和 antd 基准逐个测点比，几乎全部对不上。差异没有一处处手调：先把 136 个 Token 和 23 种控件规格定成三端共用的一份规格，各端照着转换，再用控件规格和行为断言一起验收。

antd：基准
shadcn：React
Element Plus：Vue3

同一张设备详情的三个版本。测点和断言管得住规格与行为，审美仍要人看。

老后台换技术栈，先锁住行为

我用一个按旧稿合成的旧写法后台做样本，先把它的行为写成一套断言：点了什么、应该出现什么、数据怎么变。然后分别用 React + shadcn 和 Vue3 + Element Plus 重写，用同一套断言验收。

旧写法：Vue 2 + element-ui
React：+ shadcn
Vue3：+ Element Plus

旧写法样本是按旧稿合成的，不是在职时的真实代码。

13/13

Vue3 版

四端各跑一遍，全部通过

390/390

React 版

全站 32 个路由的断言全部通过

1键

切回旧版

迁移期间新旧版本在同一个宿主里，随时一键切回

只用一套组件库的团队，一份规范加组件库自带的主题设置就够了。我要同时维护几套底座，是因为老后台换技术栈期间，React 和 Vue 两条线会同时在跑。

07Team

这套做法的起点，是在职时的设计流程

在职时，一条需求从进来到交付经过六段。每一段写清：AI 做什么，我判断什么。

一条需求经过的六段 需求理解、竞品分析、信息架构、视觉探索、原型验证、交付协同六段依次排开。AI 加速中间过程；起点的问题定义和终点的质量标准由设计师把关。需求理解段 AI 整理归纳关键信息，我判断需求优先级；竞品分析段 AI 批量收集和对比，我看它有没有漏掉维度、按目标匹配度和改动成本拆开比较；信息架构段我判断逻辑对不对；视觉探索段我决定方向选哪个。 问题定义 AI 加速中间过程 质量标准 需求理解竞品分析信息架构视觉探索原型验证交付协同 AI 做AI 我判断ME 整理归纳关键信息 批量收集和对比 需求优先级怎么排 有没有漏掉维度，按目标匹配度和改动成本拆开比 架构逻辑对不对 方向选哪个

AI 加速的是中间过程。起点的问题定义和终点的质量标准，始终在设计师手里。

按任务复杂度，决定给 AI 多少自由

  1. 01轻量任务用提示词和模板
  2. 02中等任务拆成可复用的 Skill
  3. 03复杂任务先让 AI 输出结构、假设、异常状态和待确认问题，确认后再生成

把个人探索，转成团队能复用的方法

在职时推动了四件事。

  1. 01

    提前介入

    PRD 评审时就介入，减少返工。

  2. 02

    交付结构化

    标注、状态、规则一次讲清。

  3. 03

    走查标准化

    问题写成可复核的尺寸、间距、色值和组件状态。

  4. 04

    经验进知识库

    个人能力变成团队资产。

2次

团队 AI 分享与方法拉齐

1位

带动 1 位设计师在日常文档与海报物料中落地 AI

08Review

让 AI 的产出，变得可以检查

做得好的

  1. 01合同和断言让 AI 的产出变得可检查；反例写进规则，失败记录全部保留。
  2. 02用换底座和换技术栈两种方式，验证了规则不依赖某一个组件库。
  3. 03问题按层回写，同类错误不再重复出现。

做得不够好的

  1. 01跨底座的维护成本高——三端对齐同一份规格，Token 和各端转换要一起维护。以后要加树形穿梭框这类复杂组件，三个组件库的底层能力不一样，光靠样式层很可能补不齐。
  2. 02断言管不了审美——几何容差和 1,882 项规格能自动卡住，版面节奏、留白仍要人看；早期的视觉一致性也是靠人工集中看出来的。
  3. 03还没进团队生产——目前只在自己的项目里跑通。放进团队，要改的是前后端已有的交付习惯，我预计这部分成本比工具本身高。工具也一度越做越大，后来主动收窄了范围。

AI 加速的是中间过程，起点的问题定义和终点的质量标准，始终在设计师手里。