SDD 设计沉淀

16分钟阅读

Vibe Design Playbook

以这篇文章为灵感，改造SDD 沉淀，设计出一套设计专用的这个 SDD 的一个流程

[PHASE1: 需求收敛]
  |-- 设计组件脑暴 --------> brainstorming
  |-- 需求清晰/PRD ------------> proposal
  |-- 产物: proposal.md（主要是为了知道这次的新增/编辑组件的一个需求背景，做一个设计角度上的需求收敛）
  v
[GATE1: A/B/C]
  |-- A --> [TRACK1: phase_1_complete] --> [PHASE2]
  |-- B --> 回到 PHASE1 补充
  \-- C --> 回到 PHASE1 重做
 
[PHASE2: 规格生成]
  |-- triage=plan --> 生成 spec.md 单文件 （仅仅是改一改某些 token、改一改间距等简单工作）
  |-- triage=full --> create/resync/amend （做一个新的组件/块/页面，或者是让其从截图/html/Figma翻译为组件库的某个组件）
  |      |-- create  -> 调用 token使用指南 SKILL、组件注册机制+SKILL
  |      |             -> OpenSpec propose -> 生成state.md/domain.md/design.md
  |      |-- resync  -> proposal 变更后重对齐方案
  |      \-- amend   -> 方案增量调整
  |-- 产物: spec.md 或 state.md(组件的正常态/空态/异常状态梳理)、design.md（组件背景/颜色/间距如何取值，即取哪一个 token）domain.md（可以用 L2/L1的那些组件可以利用）
  v
[GATE2: A/B/C]
  |-- A --> [TRACK2: phase_2_complete] --> [BRANCH PREP] --> [PHASE3]
  |-- B --> 回到 PHASE2 调整
  \-- C --> 回到 PHASE2 重做
 
[PHASE3: 执行实现]
  |-- 依赖检测 -> 断点恢复 -> 生成 impl-plan.md
  |-- [code] 逐任务执行
  |-- 完成后只 git add，不 commit
  v
[PHASE4: 验证]
  |-- 检查是否用的原子组件/token
  |-- 启动本地服务器，让设计能够直接从浏览器看到开发成果。
[GATE3: A/B/C]
  |-- A --> 设计验证一致[TRACK4: phase_4_complete] --> [PHASE5]
  |-- B --> 不一致：回到 PHASE2对规格（resync/amend）
  \-- C --> 部分用到了原生标签/硬编码，而非 token，[PHASE3: 执行实现]
  
[PHASE5:  规定提 PR]
  |-- 将 add 的内容新建本地分支并上传，并手动提 PR
  |-- 将这次变更的文档进行一次归档

学会把这个故事讲出来，为什么做，做了之后能干嘛，有什么收益，之前的流程是怎么样的，之后是怎么样的，需要对比。不然写的文档辉哥看了个寂寞

之前的一个设计的流程是什么：

  1. 用 Figma 画设计稿，交给开发
  2. 开发拿到这个设计稿，然后完成开发
  3. 在开发提测阶段，设计会进行走查，此时设计会揪出来很多细微的，细小的问题/错误
  4. 然后开发再花很多时间进行一个调整，直到设计走查满意

这样的一个流程所暴露出来的问题是什么：

  1. 开发和设计之间的语言有鸿沟，会导致多次检查→打回的一个繁琐的人力/pd 时间消耗。
  2. 开发为了节省时间，并没有按照规范使用 token，直接使用颜色变量/字体变量。后续变更的可维护性很差
  3. 设计画 Figma 的所需人力时间很长，迭代周期很长

本次的这样的一个原子组件库+ UI Designer SDD 流程能做到什么：

  1. 设计无需画设计稿、直接用 Agent 调用 SDD 流程，直出原型图/符合预期的模块组件，节省画 Figma 的时间
  2. 设计直出组件代码、自己开发、自己审查，审查无误后将代码交由开发进行下一步的业务逻辑开发。减少设计与开发之前走查的人力消耗/摩擦。
  3. 设计与开发语言相同：都是React 组件代码，进一步减少摩擦
  4. 设计可以直接修改原有上线组件样式，通过dev tools直接代理线上组件到本地，实现本地/线上级的预览、审查，修改样式的工作就不再消耗开发这里的人力/pd。

收益/目的：

  1. 设计无需再画画 Figma，减少设计时间
  2. 设计替代开发做样式调整工作，减少开发的时间
  3. 抹平设计与开发的语言鸿沟，减少这两者之间因为摩擦而产生的时间消耗

磁力小牛 UI Designer SDD 流程介绍

这个流程还是太繁琐了，对非开发人员不是很友好，因此打算得简化一下流程，仅仅留下一个验证的门控即可，分为以下几个阶段：

  1. /d2s setup 仅仅是为了准备环境，包括依赖下载、git的远端仓库权限检查（看是否能提交远端仓库之类的权限）、git 邮箱检查（需要为快手内部的邮箱，后缀为 @kuaishou.com）等等
  2. /d2s start + 用户输入的提示词。
    1. 先检查（基准分支）工作区是否干净，如果不干净直接 stash -u ，干净的话，先同步远端的基准分支，再基于基准分支启动一个本地分支
    2. 这个流程的主要任务是：将用户的一个需求转化为我们的规范化的文档。如果判断是简单的编辑需求，就产出 spec.md就行，如果是复杂的需求，就产出三个文档：state.md / design.md / domain.md。这里我认为可以加上一些追问，至于追问的细节程度需要进行一个把控，不能问得太细，但是我也不清楚需要问的一个程度是什么样，只要问得保证能让 Agent 输出这三个文档就行？这三个文档生成过后直接生成 impl-plan.md。然后直接开始改，直到改完过后，直接启动本地预览，这才进入第一个门禁：验证。
  3. /d2s close 设计师验证本次变更没问题过后就直接开始 add . / commit 并直接 push 本地分支到远端。

不行，上面的这些流程我改造过一遍，执行的时候完全不行，还是得慢慢来

现在我得理清楚这个问题的描述。在执行这套流程解决问题的时候，出现了以下 gap：

  • 设计并不懂什么才是业务组件，他们会认为一个例如一个导航栏就算一个业务组件。但真的是他们不懂吗，难道不是我不懂怎么划分这个业务组件的吗。在代码当中的业务组件，不仅仅会因为样式而进行拆分，可能会因为业务逻辑什么的，而进行拆分。例如他们直接把整个容器的样式作为 L3 组件，而代码里面，会把 container 相关的样式，直接写在 chat-content 里面，又或者侧边历史会话的组件，聪哥是直接把整个侧边栏历史容器，包含着历史会话列表+新建会话+左上角收起图标都作为一个容器放在 L3 组件当中。因此设计这里并不能把我我们想要的组件颗粒度/设计想法。因此，只能让他们遵循之前的一个设计逻辑，直接用我们的原子组件，而直接产出“模块”/“容器”级别的一个设计稿，设计无需关系他们是如何组合出来组件的，仅需要关系当前模块/容器的一个样式是否正确，交互是否正确即可，就算产出一个页面也无所谓。
  • 因此当前的当前的一个期望不是说让设计直接出来我们可以复用/组装的组件，而是说将产出 Figma 换一种形式，直接产出可以用的样式代码。再由我们来进行一个转换/翻译/拆分/复用。

这些问题我都得跟这些正职哥哥们讨论一下，看他们能不能点拨我一下。再问他们问题之前，我得整理好问题

  1. 设计与研发之前组件概念的 gap 问题。因此不能让他们直接产出组件，而是一个模块/容器/页面的代码原型，由我们直接翻译成组件，写页面的样式
  2. 如果是这样的一个流程，他们写出代码原型→我们再次翻译，那如何改变现有的一个 d2s模式。我的想法是单独像是 Figma 那样，直接出页面/画布。他想怎么设计就怎么设计。这样单独一个 page 一个侧栏？或者像他们说的那样，直接出一版纯前端的原型？这样做是否做得过于复杂？
  3. 如果是这样的话，预想的一个流程为：他们写一个代码原型 Page，由我们翻译为业务组件/可复用组件。在新增的场景下，他们就直接在 Design Lab 里面写，在编辑场景下，在组件库里面写对应组件，可以直接本地预览/线上代理预览。

建设一个独立的 Design Lab，而不是让设计直接改生产页

我愿称之为 Design Lab ，让设计这里生产出来模块级别的一个原型，然后再调各种 SKILL 来进行原型React代码→ 组件级别映射。

刚开会的一个记录点：设计这里不知道他是否用的是否是 token，所以说，应该直接在 原型的展示这里，直接写一个表格，表格里写得有各种变量的使用说明、Icon 的复用说明，L1 的复用说明，即在规格里面的 domain.md/ design.md里面的内容，需要展示在原型的页面里面，预计的实现形式是写一个统一的 data.tsx 模版，模板里面写好需要填的表头，以及需要填内容的一个 ts 类型。表格的话样式直接用原子组件 table，内容的话就以配置/变量的形式，填充进去，表头的内容是给设计看的，表格内容的话参考domain.md/ design.md涉及到的一些表格吧，然后把那些代码路径之类的，公共导出与研发强相关的，这些表头不要。

然后就是目前设计这里产出的 Ai 开头的这些东西不能直接列为 L3，而是类似上面说的 Design Lab 当中的一个模块/场景。就把他们这些放在Design Lab里面把，然后将 SPA 应用这里，在侧边栏区分一下，有一个顶层 tab，区分的 label 为：实际组件/原型图，组件这里的侧边栏组织形式不变，原型图这里的组织形式暂时以模块的形式来组织，就把类似这里 Ai 开头的这里设计产出的这些东西都放在Design Lab里面吧。然后需要将Design Lab的相关东西放/Users/mio/Develop/kuaishou-frontend-esp-sdd/repo/esp-robot/packages/robot-ui/src/design这里，组织形式是什么呢，就直接 index.tsx 写原型里面就行。然后在index最后引用data.tsx，将这些表格进行一个展示。

所以目前的一个 d2s流程都需要进行一个变更。现在设计里面产出的不是说是组件了，而是说是一个 React 原型模块。需要对流程有一定的更改，每次变更不是说在 Components/ 里面变，而是说在Design/ 这里加/编辑一个模块。之后的翻译步骤交给研发即可

2026-08-11

现在出现的一个问题是：demo很杂很乱，我需要梳理一下

  1. 原型图：demo 随便写，仅有一个 demo.tsx即可
  2. 原子组件，仅仅一个 demo.tsx
  3. 分子组件也是随便写 demo 的。
  4. 有注册的业务组件：L3 的话就是用三种状态容器

2026-08-19

统计口径

层级代码贡献卡片数卡片总数层内占比占全部卡片
L113190%0%
L24100%0%
L3650%0%
合计090—0%

2026-08-27

今天终于快上线了这个小牛了。来搞搞这个北极星指标： 总指标：D2S 适用需求端到端交付周期缩短率

总投入工时降低率
= 1 -（新设计工时 + 新研发工时）/（旧设计工时 + 旧研发工时）

口径：

交付周期缩短率
= 1 - D2S 需求 P50 交付周期 / 同类型传统需求 P50 交付周期

交付周期：
需求确认完成 → 生产代码合入/上线

流程变更：

旧：
需求确认 → Figma/标注 → 等待研发排期 → UI 还原
→ 设计走查 → 修改复验 → 测试 → 合入上线

新：
需求确认 → 设计生成并自验可运行界面
→ 研发完成数据/逻辑接入与 CR
→ 一轮生产验收 → 测试 → 合入上线