AI 设计工程化：淘宝闪购 B 端设计师从「交付图」到「交付代码」
淘宝闪购设计团队把 AI 提效从”生成设计稿”推到了”生成可上线的前端代码”：设计师用 Claude Code 类 IDE + 自研 SOP Skill 直接产出 React 工程代码，标准型推广页面的设计还原度接近 100%、走查沟通次数趋近 0，设计侧多承担了原本属于前端的 30% 工作量；代价是必须先在工程侧沉淀”业务流程-页面框架-组件使用-全局样式”四步设计 Skill，并由设计师继续承担质量把控——因为模型的运行上限与幻觉波动还没到能跳过人的程度。
基本信息
- 来源类型：文章（人人都是产品经理 · 作者：淘宝闪购设计，2026-09-21；原文首发于微信公众号 mp.weixin.qq.com/s/FKkUHKhi72NvLkQ4rd8DTA）
- 原文位置：raw/articles/2026-09-21-130815-tg-1f7e9c.md
- 原文 URL：https://www.woshipm.com/ai/6467628.html
- 消化日期：2026-09-21
- 作者背景：淘宝闪购设计团队（阿里体系内 B 端商家推广业务的设计团队）
- 篇幅说明：原文在抓取时未包含小标题下的配图与数据图表，正文段落完整；文中”4 种技术路径""提效效果”等章节以图示承载的部分，本文按可读文字如实记录并标注
核心观点
-
AI 时代设计师的交付物可以从”设计稿”变成”代码”：作者开篇提出的问题不是”怎么用 AI 画得更快”，而是”设计师是否只能交付设计稿？AI 时代下设计师是否可以参与到代码落地的部分”。淘宝闪购给出的答案是肯定的——AI 设计工程化的显著特点就是交付物变成了代码，设计师因此进入了原本属于下游的工程实现环节。这也是本文与大多数”AI 生成 UI”素材的分水岭：目标不是更好看的图，而是可上线的工程产物。
-
AI 提效有四条主要技术路径，选哪条取决于需求类型：文章明确区分了”标准型/定制型/创意型”需求——标准型需求结构标准、组件可复用，AI 适合做输出提效；定制型和创意型需求，AI 的价值是启发观点而不是替代产出。在这两类需求的判断之上，团队选择了”AI 设计工程化”这条路径，而不是停在设计稿生成。必须先分清需求类型再选技术路径，否则会出现”用生成工具做定制创意需求”的错配。
-
AI 设计工程化相对前两条路径有三个结构性优势：
- 标准化：设计师在设计过程和交付产物中直接使用三个代码库，研发可以直接用，不像设计稿和 HTML 那样还需要一层研发”转译”；
- 高效率：设计师跳过标注、切图等中间环节，设计还原度接近 100%，与研发的走查沟通次数逐步接近 0；
- （原文列举的第三条优势在抓取文本中以配图承载，未落到文字，本文不臆造。） 这三点构成了”工程化 > 设计稿 > HTML”的排序依据：HTML 解决了”能看见”，但没有解决”能直接用”。
-
代价是设计侧多承担约 30% 的、原属于前端的工作量，而且门槛不低：作者给出量化——新流程中设计比以往多承担 30% 工作（原属于前端开发）。这块工作对部分设计师是”全新的高门槛领域”，落地时会撞上两类问题：第一类，不熟悉 AI 设计工程工作流，不知道怎么推进流程；第二类，流程依赖设计师与 IDE 的多轮对话，效率太低。团队的对策不是培训每个人，而是联动研发沉淀 SOP Skill，把整个流程自动化——即用”把流程做成 Skill”来对冲”个体能力差异”。
-
Skill 的内容层直接移植了设计师自己的思维路径：面对”Skill 内容无从下手”，团队的做法是参考设计师的设计思维和路径——设计师拿到新需求后，往往先了解业务、梳理业务流程，再决定每个流程节点用什么页面框架，再确定每个页面用什么组件，最后保障整体输出符合设计样式规范。由此收敛出核心四步：业务流程 → 页面框架 → 组件使用 → 全局样式；同时从 4 个维度调研了 AI 生 UI 产品（包含 Lovable、Figma Make 等），先摸清 AI 的能力边界和擅长点，再决定 Skill 里该写什么、不该写什么。这是本文最可迁移的方法论动作：Skill = 把专家的既有思维路径显式化。
-
Skill 的框架层经历了”从复杂到轻量”的主动降级：最初的设想方案是双层父子结构——父层级负责整体流程编排，决定什么时候调用哪一个子 Skill。但团队判断这种结构复杂程度可能影响 AI 的理解与生成，最终以简洁轻量、渐进披露为设计原则，把所有内容收拢到单个设计 skill。这与 渐进式披露 的原则同源：约束密度比结构层级更重要，过度编排会抬高模型的推理负担。
-
设计资产 Skill 的维护边界：通用规范统一、业务规范分治：因为多业务的设计规范放进同一个 Skill 会导致 Skill 体积大幅膨胀、上下文爆炸，团队暂不进行多业务统一维护。暂定策略是——通用规范（Design Token、Layout、基础组件、基础模板等）统一维护，业务规范由不同业务的设计师分别独立维护。这是一个少见的、把”Skill 工程化成本”当作架构约束来处理的判断。
-
效果与边界同时被写入结论：目标是 80%-90% 设计提效，但模型上限与幻觉仍是硬约束：当前推广标准型页面的设计提效与研发提效已经落地；团队最终目标是标准型页面达成 80%-90% 的设计提效，仍在持续优化。同时作者明确写下限制——模型能力上限和模型幻觉波动导致”还无法完全跳过设计师，仍然需要设计师进行质量把控”。这与 AI幻觉、AI产品安全底线 的既有判断一致：AI 接管的是确定性的流程段，人保留的是最后一道判断。
实操内容保留
必填节。本文为方法复盘型文章，无代码块与可直接复制的 Prompt 模板；但给出了可直接照搬的 Skill 四步骨架、Skill 架构决策与维护策略，属于可复用的结构化实操内容，逐条保留如下。
代码/配置
（原文无代码块。与代码直接相关的可复用结论是”设计师交付物直接基于三个代码库”，即设计产物落到具体代码库而非设计稿 + 研发转译；原文未列出三个代码库的具体名称。）
Prompt 模板
（原文无 Prompt 模板。原文的做法是不手写 Prompt，而是把设计流程沉淀成 SOP Skill 自动执行整个流程。）
操作步骤
A. Skill 内容层的设计骨架（原文核心四步，按设计师原生的思考顺序排列）
- 业务流程：先了解业务，梳理出业务流程
- 页面框架：决定每一个流程节点需要用什么页面框架
- 组件使用：再确定每一个页面下使用什么样的组件
- 全局样式：最终保障整体页面输出符合设计样式规范
这四步的价值在于：它把”设计师拿到新需求后的既有思维路径”原样翻译成 AI 可执行的约束顺序，而不是另造一套面向 AI 的新流程。
B. Skill 建设的前置调研动作
- 从4 个维度调研 AI 生 UI 产品（含 Lovable、Figma Make），目的是摸清 AI 的能力边界和擅长点
- 调研结论用于决定 Skill 的边界：哪些环节交给 AI、哪些环节必须由人兜住
C. Skill 框架层的两次关键决策
- 初始方案：双层父子结构，父层级负责整体流程编排，决定什么时候用哪一个子 Skill
- 否决理由：结构较为复杂，可能影响 AI 理解与生成
- 最终方案：以简洁轻量、渐进披露为原则，所有内容收拢到单个设计 skill
D. Skill 共建与维护机制
- 判据：设计资产 Skill 需要长期迭代；多业务设计规范放入同一个 Skill 会造成 Skill 体积大幅膨胀、上下文爆炸
- 决策：暂不做多业务统一维护
- 分工：通用规范（Design Token、Layout、基础组件、基础模板等）统一维护；业务规范由不同业务设计师分别独立维护
E. 落地时的两类问题与对策（可直接用作自检清单）
- 不熟悉 AI 设计工程工作流、不知道如何推进流程 → 对策：联动研发沉淀 SOP Skill，自动化整个流程
- 流程依赖设计师与 IDE 多轮对话、效率太低 → 同上对策：用 Skill 替代人工多轮对话
关键概念
- 设计思维 — 本文 Skill 内容层的直接来源：把设计师”先业务、再框架、再组件、最后样式”的思维路径显式化为 Skill 骨架
- AI前端生成 — 本文是该领域向”B 端生产环节”延伸的案例：AI 前端生成的目标从可交互原型推进到可直接被研发使用的代码库
- Design Token — 被明确列为”通用规范”的组成部分，与 Layout / 基础组件 / 基础模板一起统一维护
- 渐进式披露 — 框架层被否决（双层父子结构）与最终收敛（单 Skill、简洁轻量）的原则依据
- Figma — 调研对象之一（Figma Make），用于校准 AI 生 UI 的能力边界
- 前端UI框架选型 — 本文的”交付代码”路径使框架选择从人的决策前移到设计环节
- Skill — 本文把 Skill 当作”流程资产”而非”提示词模板”：SOP Skill 的作用是把整个设计工程流程自动化
- AI幻觉 — 作者点明的限制之一：“当前的模型上限和幻觉波动，还无法完全跳过设计师”
- AI产品经理工作流 — 同属”把人的判断流程沉淀为可复用资产”的方法论谱系
- 未创建的概念：AI 设计工程化（本文的核心术语，指交付物为代码而非设计稿的设计工作方式）、业务流程-页面框架-组件使用-全局样式（四步 Skill 骨架）、双层父子 Skill 结构（被否决的方案）、AI 设计工程 SOP Skill（团队自研并联动研发沉淀的流程资产）
与其他素材的关联
- 与 AI前端生成：该实体记录的是”PM 用 AI 生成可交互页面”（营销页/后台/原型），验收维度是业务目标、信息层级、视觉风格、交互流程、工程实现；本文把主体换成了设计师、把交付物换成了代码库，并给出了工程化的量化收益（还原度接近 100%、走查趋近 0、设计侧 +30% 工作量）。两者是同一能力在不同角色、不同交付层级上的延续。
- 与 前端UI框架选型：该主题认为”框架是起点，成熟产品最终需要形成自己的设计系统”。本文是该判断在阿里体系内的一个落地样本——通用规范（Design Token / Layout / 基础组件 / 基础模板）统一维护、业务规范分治，正是”设计系统”在 AI 时代的组织形态。
- 与 2026-05-10-ai-frontend-usable-deliverable：同属”AI 生成前端可交付物”的方法论谱系。该素材强调 PM 的”设计表达能力 + 结构化验收能力”，本文则把能力载体从”人的能力”换成”团队沉淀的 Skill 资产”——个人能力差异被 Skill 抹平，但质量把控仍由人承担这一点两文一致。
- 与 2026-09-21-woshipm-pm-ai-tools-skills（同日 ingests）：该文讲 PM 如何选工具、自建 Skill（如需求澄清 Skill）；本文是设计师侧的对称叙事——自建 Skill 的出发点都是”把本专业既有的思考顺序显式化”（该文是”判别成熟度→复述已知/假设/缺失→分档分轮提问”，本文是”业务流程→页面框架→组件使用→全局样式”）。
- 与 2026-09-18-woshipm-workbuddy-ima-self-op-kb、2026-05-27-woshipm-consultant-employee-ai-era：同属”把个人经验变成组织能力”的落地方向，本文提供了设计职能内的具体版本。
- 与 2026-05-29-woshipm-shawn-abu-claude-code-6-weeks：该素材提出用 Design Token 写进 CLAUDE.md 让 AI 保持视觉一致性（“你只需要教它一次”）；本文把这一点升级为组织级的规范分层与维护分工。
原文精彩摘录
AI 能力蓬勃发展，各个领域设计师不断探索如何使用AI对日常设计输出进行提效，在技术逐步平权的背景下，设计师是否只能交付设计稿？AI时代下设计师是否可以参与到代码落地的部分？我会尝试结合淘宝闪购商家B端的推广业务，带来一些分享。
AI对于不同的业务助力点不同，对于标准型需求，因为其结构标准、组件可复用等特点，AI可以帮助输出提效，对于定制型和创意型需求，AI可以帮助设计师启发观点。
优势一：标准化。 设计师在设计过程及交付的产物中直接使用了三个代码库，研发可以直接使用，不像设计稿和HTML一样，需要再进行一层研发”转译”。
优势二：高效率。 设计师不需要经历标注、切图等中间环节，设计还原度接近100%，与研发的走查沟通次数逐步接近0。
在AI设计工程化中，设计师更多参与到下游的技术实现，从传统的”交付图”，转变为”交付代码”。在新流程中，设计比以往多承担30%工作（原属于前端开发），但是这块工作内容对于部分设计师是一个全新的高门槛领域。这里可能会遇到两类问题：第一类是不熟悉AI设计工程工作流，不知道该如何进行流程推进；第二类是流程依赖设计师与IDE的多轮对话，效率太低。所以为了降低其他设计师的使用门槛并且提高工程部署效率，已联动研发沉淀SOP Skill，可自动化进行整个流程。
内容层 ：为解决 Skill 内容无从下手的难点，参考设计师的设计思维和路径。设计师拿到新的需求后，往往需要先对业务进行了解，并梳理出业务流程，再决定每一个流程节点需要用什么页面框架，再确定每一个页面下使用什么样的组件，最终再保障整体页面输出是符合设计样式规范的。根据以上设计师的思维路径梳理出” 业务流程-页面框架-组件使用-全局样式 “核心4步骤，并且从4个维度调研AI生UI产品（包含Lovable、Figmamake等），了解AI的能力边界和擅长点。
框架层 ：最开始的设想方案是双层父子结构，即父层级负责整体的流程编排，决定什么时候用哪一个子Skill。但是这种结构较为复杂，可能会影响AI理解与生成，所以最终以简洁轻量、渐进披露为设计原则，将所有的内容收拢到单个设计skill。
共建机制 ：设计资产Skill需要长期迭代，因为多业务的设计规范都放入同一个Skill，可能会造成 Skill体积会大幅度膨胀，上下文爆炸，所以暂不进行多业务统一维护；目前暂定策略是通用规范（包含Design Token、Layout、基础组件、基础模板等）进行统一维护，业务规范由不同的业务设计师分别独立维护。
我们最终目标希望能够在标准型页面中达成80%-90%的设计提效，也在持续优化中。但是同时我们也要考虑AI的限制，主要体现在模型能力和模型幻觉。当前的模型上限和幻觉波动，还无法完全跳过设计师，仍然需要设计师进行质量把控。