D2S 设计及交付

14分钟阅读

磁力小牛 D2S：设计即交付

原文

文档（内网） 对应代码库：esp-robot/packages/robot-ui ｜ 文档生成时间：2026-07-30

Quote

把卡片交付从「Figma 贴图还原」升级为「规格驱动实现」：设计师先沉淀需求、状态和设计 token，AI 在明确边界内生成展示层代码，研发负责 Review 和数据接入。

一、背景

磁力小牛需要持续交付大量业务卡片——主动推送（Reach）、会话卡片（Chat）、诊断结果、成长任务……当前每张卡片的交付链路存在四个反复出现的问题：

问题具体表现代价
交付物是贴图设计师通过 Figma 出稿，研发用 AI 依据贴图还原，icon 需要手动拆取还原度低，icon 散落各处，无法复用
没有组件规范约束每张卡片设计师自行发挥，按钮、间距、颜色各做各的同类卡片风格不一，改一处要改十处
设计决策无文字依据token 选哪个、间距多少靠口头同步，没有可查的规格研发每次自行判断，返工成本高
走查占用时间多还原度低导致反复打回，一张卡片走查 2～3 轮是常态走查成为交付瓶颈，时间消耗不可控

二、参考调研

品牌团队：灵创（对话式生成 + HTML 交付）

参考：https://aicode.corp.kuaishou.com/internal-deploy/17596

设计师在平台上对话式描述需求，AI 生成完整页面（含 KPI 卡片、图表、表格），直接交付 HTML 链接，无需研发介入。

  • 优点：交付快
  • 局限：生成结果难以进入代码库持续维护，也缺少组件规范约束

DSP 团队：LinoKit（自研组件库 + 设计约束）

参考：https://lui2.frontend-cloud.corp.kuaishou.com/#message

DSP 团队自研了组件库 LinoKit，建立了 Figma 规范与代码组件的对齐关系，提供交互式文档站和实时 props 测试面板。

  • 优点：有设计约束、组件可持续维护
  • 局限：设计师仍依赖研发排期，走查流程没有本质变化

对比

维度灵创LinoKit磁力小牛 D2S
设计师能否自主驱动展示层能（生成即交付）不能（依赖研发）能
组件规范约束弱强强
可持续迭代弱强强
设计决策可追溯无无有
适用场景一次性展示页面通用组件库业务卡片持续交付

磁力小牛 D2S 的思路是：在 LinoKit 式组件约束的基础上，让设计师可以自主驱动展示层交付，同时把每次设计决策沉淀成可追溯的规格文档。

三、方案：从交付 Figma，升级为交付可运行界面

D2S 的目标不是让设计替代研发，而是将决定界面还原度的工作前移到设计侧。

过去，设计交付的是 Figma；研发需要将视觉稿再次翻译为 React 代码，Token、图标、间距、状态细节往往在实现阶段重新判断。现在，设计直接在小牛组件库中使用既有原子组件、Token 和图标，交付可运行、可预览的 React 界面。

边界

设计侧 D2S 到「设计验收完成」为止。后续生产组件拆分、数据接入、业务逻辑和研发 CR，仍由研发负责。

1. 增量场景：设计先交付原型，研发侧再完成工程化

  • Figma 出稿 → 被 React 原型生成替代
  • 研发翻译为 React 代码 → 被直接交付样式约束好的原型替代
  • 设计走查 → 被设计自验 + 原型评审合并，节点不再单独存在

2. 存量场景：设计直接完成样式调整

  • Figma 出稿 → 从设计稿驱动改为直接在真实线上组件中修改
  • 研发翻译 React 代码 → 从重复还原改为直接复用已有线上组件
  • 设计走查 → 从提测后的返工环节改为本地／线上环境自验
  • 依赖研发排期 → 设计无需依赖研发排期，针对线上存量组件直接修改样式

四、角色怎么变

这套流程没有减少研发的工程责任，而是重新分配了展示层工作。

角色过去现在
设计师Figma 出图，等待研发实现，在提测后多轮走查用组件、Token 和图标生成可运行原型；本地自验；提交原型或样式 PR
研发还原 Figma、处理样式细节、反复响应设计打回，同时开发业务逻辑负责生产组件拆分、数据接入、业务逻辑、代码 CR 与上线质量
AI根据截图或自然语言自行猜测样式在组件库、Token、图标和状态约束内生成展示层代码
产品基于静态图确认需求基于可运行原型确认需求与交互

设计和研发从「两套语言」变成「一套可执行语言」：设计看到的是组件、Token 和浏览器预览；研发拿到的也是组件、Token 和浏览器预览，而不是一张需要再次翻译的图片。

五、为什么现在可以做

这件事成立的前提，不是单纯使用 AI，而是小牛已经具备约束 AI 的组件基础设施。

  • 三层组件体系：L1 原子组件、L2 分子组件、L3 业务组件提供明确的复用边界。
  • 场景化 Token：颜色、字体、间距、圆角、阴影等视觉决策有统一来源，避免 AI 或研发临时猜测。
  • 统一图标资产：图标和动效通过 @/icons 复用，不需要从 Figma 手动拆取。
  • Docs 双入口：
    • 「实际组件」用于维护已经进入组件库的生产展示层。
    • 「原型图」用于设计新场景，承载模块级或页面级 React 原型。
  • 真实状态 Demo：Demo 不只是填数据，而是展示可验收状态；消息列表支持 Web 窄屏、Web 宽屏、Mobile 三种环境。
  • 线上代理调试：DevTools 可将线上组件代理到本地，设计能在接近真实环境的上下文中完成样式验证。

本地 Docs 文档站预览覆盖：原子组件、分子组件、业务组件、原型四类归属；DevTools 支持线上代理调试。

六、预期收益与验证指标

收益不是「少写一点代码」，而是减少 Figma 与代码之间的反复翻译，以及由翻译偏差带来的多轮返工。

维度过去目标状态
需求评审依据静态 Figma可运行原型
新场景设计交付设计稿 + 标注React 原型 + 规格说明
存量样式修改设计提需求，研发实现设计直接修改并自验，研发 CR
视觉问题发现时点开发提测后的设计走查设计本地预览与线上代理阶段
设计走查多次走查打回研发接入后收敛为一轮验收
样式维护临时值、图标和样式容易散落Token、图标、组件复用关系可追溯
协作语言Figma 标注、口头同步、代码实现React、Token、组件和浏览器预览

七、实战演示：两条链路

  1. 存量场景，直接修改线上组件样式
  2. 增量原型场景，从需求到原型交接

附录：D2S 命令速查

流程编排

[PHASE 1: 需求收敛]
  |-- 设计组件脑暴 ------------------> /d2s brainstorming
  |-- 需求清晰 / PRD ----------------> /d2s proposal
  |
  \-- 产物: proposal.md
      记录本次新增/编辑的背景、场景、参考源、设计验收标准与非目标，
      完成设计角度的需求收敛。
  v
[GATE 1: A / B / C]
  |-- A --> [TRACK 1: phase_1_complete] --> [PHASE 2]
  |-- B --> 回到 PHASE 1 补充
  \-- C --> 回到 PHASE 1 重做
 
[PHASE 2: 规格生成]
  |-- triage=plan --> spec.md
  |      适用：仅调整既有 token、间距等简单样式，不涉及结构或状态。
  |
  \-- triage=full --> create / resync / amend
         |-- create
         |     |-- 小牛 UI Token 指南：Token 决策与 Gap
         |     |-- 小牛 UI 领域复用：L1/L2、图标、既有视觉模式
         |     |-- 小牛 UI 状态建模：正常、空、加载、异常等状态
         |     \-- OpenSpec 投影：state.md、domain.md、design.md
         |
         |-- resync --> proposal 或来源变化后，重新对齐规格
         \-- amend  --> 需求未变，只做方案增量调整
  |
  \-- 产物:
      spec.md：轻量样式改动规格
      state.md：正常、空、加载、异常等状态与验收
      domain.md：可复用 L1/L2、图标和既有视觉模式
      design.md：布局、颜色、间距、Token 决策与 Fidelity Gate
  v
[GATE 2: A / B / C]
  |-- A --> [TRACK 2: phase_2_complete] --> [BRANCH PREP] --> [PHASE 3]
  |-- B --> 回到 PHASE 2 调整
  \-- C --> 回到 PHASE 2 重做
 
[BRANCH PREP]
  \-- 检查工作区与 upstream，创建/切换 design/<change> 分支，
      确认后续实现只发生在该分支。
 
[PHASE 3: 执行实现]
  |-- 依赖检测 -> 断点恢复 -> 生成 impl-plan.md
  |-- 按任务实现原型或实际组件样式
  |-- 每项完成后运行必要检查
  \-- 只精确 git add，不 commit、不 push
  v
[PHASE 4: 验证]
  |-- 检查 L1/L2、图标、Token 与 Demo 状态复用
  |-- 检查原生标签与硬编码值是否有合规说明
  |-- 启动本地 Docs 服务，设计在浏览器验收
  \-- 消息列表额外验收 Web 372、Web 784、Mobile 372
  v
[GATE 3: A / B / C]
  |-- A --> 设计验证一致
  |          --> [TRACK 4: phase_4_complete] --> [PHASE 5]
  |-- B --> 规格或参考源不一致
  |          --> 回到 PHASE 2，执行 resync / amend
  \-- C --> 实现违反 Token / 原子组件约束
             --> 回到 PHASE 3 修正
 
[PHASE 5: PR 与归档]
  |-- 展示 staged diff，等待最终人工确认
  |-- 在已准备的 design/<change> 分支 commit、push
  |-- 归档本次 D2S artifacts
  \-- 交接 PR：当前仓库默认由设计师手动创建 PR

D2S 流程命令

步骤命令说明
启动变更/d2s start初始化状态，确认基线
脑暴需求/d2s brainstorming需求不清晰时引导收敛
写需求/d2s proposal需求清晰时直接结构化
生成规格/d2s spec产出 state / domain / design 三份文档
展示层实现/d2s buildAI 按规格实现，生成 impl-plan
自动验证/d2s verify审计 + 浏览器预览
提 PR 归档/d2s close建分支、push、归档 OpenSpec

新版 SKILL 非门禁编排

SKILL说明
小牛 UI 启动！启动组件库文档与小牛本地代理服务，并输出可访问的调试地址
小牛 UI 组件编写按仓库的组件复用、Token、Demo 和设计还原要求，新增或编辑组件及原型
小牛 UI 交付审计当前改动，确认 Gap 后创建分支、提交、推送并创建或交接 PR