Impeccable Extract Flow 全解把重复 UI 提炼成可复用的设计系统【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable导读extract是 Impeccable 技能中面向「设计系统建设」的核心命令它负责在现有前端代码中识别可复用的模式、组件与设计令牌design tokens并将其抽取、整合进设计系统供系统化复用。本文以 Impeccable 的 extract.md 流程文档为主体结合仓库内技能定义与 DESIGN.md 规范完整讲解从「发现设计系统」到「抽取、迁移、文档化」的六步工作流、判定复用价值的量化标准以及必须规避的抽象陷阱。读完你可以在任何积累了重复样式代码的前端项目上独立执行一次安全、克制的设计系统抽取。适用范围说明Impeccable 的extract属于其 Commands 表中的Build构建类命令正式描述为 “Pull reusable tokens and components into design system”相关入口与定位见 .rovodev/skills/impeccable/SKILL.md。extract 在 Impeccable 工作流中的位置在 Impeccable 的命令体系中见 SKILL.md 的 Commands 表extract [target]与shape、init、document同属 Build 类别。它与两个相邻命令的分工值得先厘清以避免在错误的时机调用它init只采集持久化的产品事实并写入 PRODUCT.md不创造视觉世界、不写 DESIGN.md见 init.md。它是设计系统抽取的隐含前提——没有稳定的产品上下文抽取出来的抽象往往站不住脚。document把现有代码中已形成的视觉设计系统固化成根目录DESIGN.md含可机读的 YAML frontmatter token属于「记录既有体系」见 document.md。extract在代码层面主动执行抽取动作——把散落的重复实现提升为共享组件与令牌。当代码库已经积累了足够多的重复模式、而 DESIGN.md 还缺失或过时的时候extract与document经常配对出现先抽取真实复用的实现再把它们记录进规范。从技能的 Setup 看SKILL.md执行任何一条命令前需先运行一次context.mjs加载 PRODUCT.md、DESIGN.md 与 surface brief再依据其指示工作。extract也应遵循这一前提——在抽取前先知道项目捕获过的产品事实与既有设计语言。六步工作流总览extract流程文档把一次完整的抽取组织为六个阶段方向明确先发现Discover→ 再识别Identify→ 然后规划Plan→ 实施抽取与增强Extract Enrich→ 迁移既有使用Migrate→ 最后沉淀文档Document。前两步决定「抽什么」第三、四步决定「怎么抽」后两步决定「如何让抽取真正生效而不留下断点」。Step 1发现设计系统Discover the Design System第一步不是动手抽代码而是先找到并理解项目里既有的设计系统、组件库或共享 UI 目录。需要摸清的结构性信息包括组件组织方式组件目录如何分层、如何聚合命名约定组件名、文件名、CSS 类名遵循什么范式设计令牌结构颜色/字体/间距/圆角等令牌如何定义、层级如何组织导入导出约定模块之间通过什么方式互相引用。流程文档对这一步骤给出了一条CRITICAL 级红线如果项目中尚不存在设计系统此时不要擅自创建。应当直接向用户提问澄清无法自行推断的信息——用户偏好的存放位置与结构——先理解清楚再动手。这与 Impeccable 全局的「把 brief 当作最高权威、证据而非猜测驱动决策」原则一致。Step 2识别可抽取的模式Identify Patterns在目标区域target area内寻找可抽取的机会流程文档给出了六类典型信号模式类型典型例子抽取价值判断重复组件Repeated components按钮、卡片、输入框等相似 UI 模式出现3 次以上高硬编码值Hard-coded values本应成为令牌的颜色、间距、字体、阴影高不一致变体Inconsistent variations同一概念存在多种不同实现中高需统一意图组合模式Composition patterns表单行、工具栏分组、空状态等反复出现的布局/交互组合中类型样式Type styles重复的 font-size font-weight line-height 组合中动画模式Animation patterns重复的缓动、时长或关键帧组合中流程文档特意强调了一个量化门槛直接引述如下“Assess value: only extract things used 3 times with the same intent. Premature abstraction is worse than duplication.”只抽取「使用 3 次以上且意图一致」的东西。过早抽象比重复更糟。这一条是整个 extract 流程的方法论基石它把「3 次」和「相同意图same intent」同时设为硬性条件缺一不可。两个外观相似但服务于不同目的、承载不同业务的按钮属于「intent 不同」应当各自保留而非强行合并——这一判定标准在第六步的 NEVER 清单里还会再次出现。佐证在仓库的测试夹具中tests/fixtures/antipatterns/ 等目录以大量小尺寸 HTML/TSX/Vue/Svelte 样例组织反模式与通过样例侧面印证了 Impeccable 生态对「把视觉值系统化、可判定化」的重视——这与 extract 所追求的「消灭散落硬编码、收敛为可引用令牌」是同一设计哲学的两种表达。Step 3规划抽取方案Plan Extraction识别完成后需要产出一份系统化的抽取计划覆盖五个维度待抽取组件Components to extract哪些 UI 元素应升级为可复用组件待创建令牌Tokens to create哪些硬编码值应沉淀为设计令牌需支持的变体Variants to support每个组件需要哪些变体形态命名约定Naming conventions组件名、令牌名、props 名都要与既有模式保持一致迁移路径Migration path如何把既有使用处重构到新的共享版本上。流程文档在此给出的IMPORTANT 级原则同样值得反复强调“Design systems grow incrementally. Extract what is clearly reusable now, not everything that might someday be reusable.”设计系统是增量生长的。只抽取当下明确可复用的东西而不是所有「也许将来可复用」的东西。规划阶段的目标是克制而精准不是追求未来的完备性。Step 4抽取并增强Extract Enrich正式构建改进后的可复用版本。流程文档按三类产物给出了各自的增强标准组件Components清晰的 props API且带合理默认值为不同用例提供恰当变体variants内建可访问性ARIA 语义、键盘导航、焦点管理配套文档与用法示例。设计令牌Design tokens命名清晰区分primitive原语与 semantic语义两类层级有恰当的层级与组织结构每个令牌都要注明「何时使用」即 token 的语义含义。模式Patterns说明该模式适用的时机给出代码示例说明其变体与可组合方式。关于 primitive 与 semantic 的区分可以结合仓库中 DESIGN.md 的实际组织方式加深理解该文件在 YAML frontmatter 中把colors、typography、rounded、spacing等令牌类作为可机读层集中声明例如品牌锚点kinpaku-gold声明为oklch(84% 0.19 80.46)并明确「文件是事实来源frontmatter 是可移植导出」的同步纪律prose 正文只负责描述语义与使用场景。组件级定义如button-primary及其 hover 变体则通过引用 token 的方式拼装——这正是 extract 中「组件引用原语令牌」思想在成品规范里的落地形态。更完整的规格约束在 document.md 中有详细描述例如 token 引用语法{path.to.token}、组件子令牌被限定为 8 个属性backgroundColor、textColor、typography、rounded、padding、size、height、width、超出 schema 能力的阴影/动效/断点等内容放入.impeccable/design.jsonsidecar 而非强行塞进 frontmatter——这些约束都服务于「抽取后的令牌必须语义清晰、可被机器与 Agent 稳定消费」这一目标。Step 5迁移既有使用Migrate抽取完成只是开始真正的收益来自既有调用点的切换。流程文档将迁移分解为四步查找所有实例Find all instances系统地搜索被抽取模式的所有使用处系统性替换Replace systematically逐一更新使用处让它们消费共享版本充分测试Test thoroughly确保视觉与功能等价visual and functional parity删除死代码Delete dead code清理旧的局部实现避免两套实现长期并存造成漂移。这一步尤其要防的是「迁移不彻底」如果旧的重复实现被留在原地未来维护者会继续朝旧副本添加改动抽取反而制造出新的不一致。删除死代码是迁移闭环的最后一步不是可选项。Step 6沉淀文档Document把抽取结果固化到设计系统文档中将新组件加入组件库清单记录令牌的用法与取值补充示例与使用指引更新 Storybook 或组件目录component catalog等工具视图。在 Impeccable 的语境里「沉淀文档」与document命令形成天然衔接抽取完成后应当把真实形成且被复用中的令牌与组件录入到 DESIGN.md 的规范结构中frontmatter 承载可机读令牌、八个固定顺序的正文小节承载语义说明让后续 AI Agent 在生成新界面时能稳定「stay on-brand」。需要提醒的是若项目根目录已有 DESIGN.md更新前应展示现有文件并征询用户——选择刷新、覆盖还是合并这与 document.md 中的「不要静默覆盖」规则完全一致。NEVER 清单抽取的六条反向红线流程文档在末尾以NEVER形式给出了六条不可触碰的反例它们与前面的正向原则互为镜像是执行质量的自检项不做概括就抽取一次性/强上下文绑定的实现——extract one-off, context-specific implementations without generalization。抽出来的东西必须是被泛化过的通用形态。不要创建泛化到无用的组件——create components so generic they are useless。过度抽象的另一端同样是失败抽象的粒度应恰好落在「真实复用的意图」上。不要无视既有设计系统约定进行抽取——extract without considering existing design system conventions。命名、结构、引用方式都必须顺应当前系统的惯例否则抽取产物会变成新的异类。不要跳过完整的 TypeScript 类型或 props 文档——skip proper TypeScript types or prop documentation。共享组件的类型与文档是 API 的一部分不是可选修饰。不要为每一个值都建令牌——create tokens for every single value。令牌必须具有语义含义为一次性数值建立 token 只会污染令牌空间这与 Step 2 中「过早抽象比重复更糟」的判定一脉相承。不要抽取意图相异的东西——extract things that differ in intent。两个外观相似但用途不同的按钮应保持分离合并它们等于用表象覆盖语义。这六条红线可以浓缩成一句执行心法抽取的价值来自「真实、一致、系统内」的复用而不是抽象动作本身。一次理想 extract 的落地形态综合六步流程、红线清单与仓库中的规范证据一次高质量的extract [target]执行应呈现出这样的结果链摸清既有设计系统的位置与结构没有则不擅自新建先问用户用「3 次 相同意图」的标尺筛选出真正值得抽取的模式重复组件、硬编码值、不一致变体、组合模式、类型样式、动画模式产出覆盖组件/令牌/变体/命名/迁移路径的抽取计划且只覆盖「当下明确可复用」的范围构建带清晰 props、恰当变体、内建无障碍、配套文档的共享版本令牌遵循 primitive/semantic 分层并具备语义含义全量查找、系统性替换、验证视觉与功能等价、删除旧实现把新组件与令牌录进组件库与 DESIGN.mdfrontmatter 令牌 规范正文保持机器可读层与代码事实来源同步。整个过程始终受控于两条总原则让设计系统增量、克制地生长以及让抽取的每个产物都能被既有系统与未来 Agent 稳定地理解与复用。这套流程文档既是给执行 extract 的 Agent 的操作规程也是人工重构前端的可用检查清单——六步顺序、两组量化/定性红线可以直接迁移到任何以「系统化复用」为目标的代码库治理工作中。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Impeccable Extract Flow 全解：把重复 UI 提炼成可复用的设计系统
Impeccable Extract Flow 全解把重复 UI 提炼成可复用的设计系统【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable导读extract是 Impeccable 技能中面向「设计系统建设」的核心命令它负责在现有前端代码中识别可复用的模式、组件与设计令牌design tokens并将其抽取、整合进设计系统供系统化复用。本文以 Impeccable 的 extract.md 流程文档为主体结合仓库内技能定义与 DESIGN.md 规范完整讲解从「发现设计系统」到「抽取、迁移、文档化」的六步工作流、判定复用价值的量化标准以及必须规避的抽象陷阱。读完你可以在任何积累了重复样式代码的前端项目上独立执行一次安全、克制的设计系统抽取。适用范围说明Impeccable 的extract属于其 Commands 表中的Build构建类命令正式描述为 “Pull reusable tokens and components into design system”相关入口与定位见 .rovodev/skills/impeccable/SKILL.md。extract 在 Impeccable 工作流中的位置在 Impeccable 的命令体系中见 SKILL.md 的 Commands 表extract [target]与shape、init、document同属 Build 类别。它与两个相邻命令的分工值得先厘清以避免在错误的时机调用它init只采集持久化的产品事实并写入 PRODUCT.md不创造视觉世界、不写 DESIGN.md见 init.md。它是设计系统抽取的隐含前提——没有稳定的产品上下文抽取出来的抽象往往站不住脚。document把现有代码中已形成的视觉设计系统固化成根目录DESIGN.md含可机读的 YAML frontmatter token属于「记录既有体系」见 document.md。extract在代码层面主动执行抽取动作——把散落的重复实现提升为共享组件与令牌。当代码库已经积累了足够多的重复模式、而 DESIGN.md 还缺失或过时的时候extract与document经常配对出现先抽取真实复用的实现再把它们记录进规范。从技能的 Setup 看SKILL.md执行任何一条命令前需先运行一次context.mjs加载 PRODUCT.md、DESIGN.md 与 surface brief再依据其指示工作。extract也应遵循这一前提——在抽取前先知道项目捕获过的产品事实与既有设计语言。六步工作流总览extract流程文档把一次完整的抽取组织为六个阶段方向明确先发现Discover→ 再识别Identify→ 然后规划Plan→ 实施抽取与增强Extract Enrich→ 迁移既有使用Migrate→ 最后沉淀文档Document。前两步决定「抽什么」第三、四步决定「怎么抽」后两步决定「如何让抽取真正生效而不留下断点」。Step 1发现设计系统Discover the Design System第一步不是动手抽代码而是先找到并理解项目里既有的设计系统、组件库或共享 UI 目录。需要摸清的结构性信息包括组件组织方式组件目录如何分层、如何聚合命名约定组件名、文件名、CSS 类名遵循什么范式设计令牌结构颜色/字体/间距/圆角等令牌如何定义、层级如何组织导入导出约定模块之间通过什么方式互相引用。流程文档对这一步骤给出了一条CRITICAL 级红线如果项目中尚不存在设计系统此时不要擅自创建。应当直接向用户提问澄清无法自行推断的信息——用户偏好的存放位置与结构——先理解清楚再动手。这与 Impeccable 全局的「把 brief 当作最高权威、证据而非猜测驱动决策」原则一致。Step 2识别可抽取的模式Identify Patterns在目标区域target area内寻找可抽取的机会流程文档给出了六类典型信号模式类型典型例子抽取价值判断重复组件Repeated components按钮、卡片、输入框等相似 UI 模式出现3 次以上高硬编码值Hard-coded values本应成为令牌的颜色、间距、字体、阴影高不一致变体Inconsistent variations同一概念存在多种不同实现中高需统一意图组合模式Composition patterns表单行、工具栏分组、空状态等反复出现的布局/交互组合中类型样式Type styles重复的 font-size font-weight line-height 组合中动画模式Animation patterns重复的缓动、时长或关键帧组合中流程文档特意强调了一个量化门槛直接引述如下“Assess value: only extract things used 3 times with the same intent. Premature abstraction is worse than duplication.”只抽取「使用 3 次以上且意图一致」的东西。过早抽象比重复更糟。这一条是整个 extract 流程的方法论基石它把「3 次」和「相同意图same intent」同时设为硬性条件缺一不可。两个外观相似但服务于不同目的、承载不同业务的按钮属于「intent 不同」应当各自保留而非强行合并——这一判定标准在第六步的 NEVER 清单里还会再次出现。佐证在仓库的测试夹具中tests/fixtures/antipatterns/ 等目录以大量小尺寸 HTML/TSX/Vue/Svelte 样例组织反模式与通过样例侧面印证了 Impeccable 生态对「把视觉值系统化、可判定化」的重视——这与 extract 所追求的「消灭散落硬编码、收敛为可引用令牌」是同一设计哲学的两种表达。Step 3规划抽取方案Plan Extraction识别完成后需要产出一份系统化的抽取计划覆盖五个维度待抽取组件Components to extract哪些 UI 元素应升级为可复用组件待创建令牌Tokens to create哪些硬编码值应沉淀为设计令牌需支持的变体Variants to support每个组件需要哪些变体形态命名约定Naming conventions组件名、令牌名、props 名都要与既有模式保持一致迁移路径Migration path如何把既有使用处重构到新的共享版本上。流程文档在此给出的IMPORTANT 级原则同样值得反复强调“Design systems grow incrementally. Extract what is clearly reusable now, not everything that might someday be reusable.”设计系统是增量生长的。只抽取当下明确可复用的东西而不是所有「也许将来可复用」的东西。规划阶段的目标是克制而精准不是追求未来的完备性。Step 4抽取并增强Extract Enrich正式构建改进后的可复用版本。流程文档按三类产物给出了各自的增强标准组件Components清晰的 props API且带合理默认值为不同用例提供恰当变体variants内建可访问性ARIA 语义、键盘导航、焦点管理配套文档与用法示例。设计令牌Design tokens命名清晰区分primitive原语与 semantic语义两类层级有恰当的层级与组织结构每个令牌都要注明「何时使用」即 token 的语义含义。模式Patterns说明该模式适用的时机给出代码示例说明其变体与可组合方式。关于 primitive 与 semantic 的区分可以结合仓库中 DESIGN.md 的实际组织方式加深理解该文件在 YAML frontmatter 中把colors、typography、rounded、spacing等令牌类作为可机读层集中声明例如品牌锚点kinpaku-gold声明为oklch(84% 0.19 80.46)并明确「文件是事实来源frontmatter 是可移植导出」的同步纪律prose 正文只负责描述语义与使用场景。组件级定义如button-primary及其 hover 变体则通过引用 token 的方式拼装——这正是 extract 中「组件引用原语令牌」思想在成品规范里的落地形态。更完整的规格约束在 document.md 中有详细描述例如 token 引用语法{path.to.token}、组件子令牌被限定为 8 个属性backgroundColor、textColor、typography、rounded、padding、size、height、width、超出 schema 能力的阴影/动效/断点等内容放入.impeccable/design.jsonsidecar 而非强行塞进 frontmatter——这些约束都服务于「抽取后的令牌必须语义清晰、可被机器与 Agent 稳定消费」这一目标。Step 5迁移既有使用Migrate抽取完成只是开始真正的收益来自既有调用点的切换。流程文档将迁移分解为四步查找所有实例Find all instances系统地搜索被抽取模式的所有使用处系统性替换Replace systematically逐一更新使用处让它们消费共享版本充分测试Test thoroughly确保视觉与功能等价visual and functional parity删除死代码Delete dead code清理旧的局部实现避免两套实现长期并存造成漂移。这一步尤其要防的是「迁移不彻底」如果旧的重复实现被留在原地未来维护者会继续朝旧副本添加改动抽取反而制造出新的不一致。删除死代码是迁移闭环的最后一步不是可选项。Step 6沉淀文档Document把抽取结果固化到设计系统文档中将新组件加入组件库清单记录令牌的用法与取值补充示例与使用指引更新 Storybook 或组件目录component catalog等工具视图。在 Impeccable 的语境里「沉淀文档」与document命令形成天然衔接抽取完成后应当把真实形成且被复用中的令牌与组件录入到 DESIGN.md 的规范结构中frontmatter 承载可机读令牌、八个固定顺序的正文小节承载语义说明让后续 AI Agent 在生成新界面时能稳定「stay on-brand」。需要提醒的是若项目根目录已有 DESIGN.md更新前应展示现有文件并征询用户——选择刷新、覆盖还是合并这与 document.md 中的「不要静默覆盖」规则完全一致。NEVER 清单抽取的六条反向红线流程文档在末尾以NEVER形式给出了六条不可触碰的反例它们与前面的正向原则互为镜像是执行质量的自检项不做概括就抽取一次性/强上下文绑定的实现——extract one-off, context-specific implementations without generalization。抽出来的东西必须是被泛化过的通用形态。不要创建泛化到无用的组件——create components so generic they are useless。过度抽象的另一端同样是失败抽象的粒度应恰好落在「真实复用的意图」上。不要无视既有设计系统约定进行抽取——extract without considering existing design system conventions。命名、结构、引用方式都必须顺应当前系统的惯例否则抽取产物会变成新的异类。不要跳过完整的 TypeScript 类型或 props 文档——skip proper TypeScript types or prop documentation。共享组件的类型与文档是 API 的一部分不是可选修饰。不要为每一个值都建令牌——create tokens for every single value。令牌必须具有语义含义为一次性数值建立 token 只会污染令牌空间这与 Step 2 中「过早抽象比重复更糟」的判定一脉相承。不要抽取意图相异的东西——extract things that differ in intent。两个外观相似但用途不同的按钮应保持分离合并它们等于用表象覆盖语义。这六条红线可以浓缩成一句执行心法抽取的价值来自「真实、一致、系统内」的复用而不是抽象动作本身。一次理想 extract 的落地形态综合六步流程、红线清单与仓库中的规范证据一次高质量的extract [target]执行应呈现出这样的结果链摸清既有设计系统的位置与结构没有则不擅自新建先问用户用「3 次 相同意图」的标尺筛选出真正值得抽取的模式重复组件、硬编码值、不一致变体、组合模式、类型样式、动画模式产出覆盖组件/令牌/变体/命名/迁移路径的抽取计划且只覆盖「当下明确可复用」的范围构建带清晰 props、恰当变体、内建无障碍、配套文档的共享版本令牌遵循 primitive/semantic 分层并具备语义含义全量查找、系统性替换、验证视觉与功能等价、删除旧实现把新组件与令牌录进组件库与 DESIGN.mdfrontmatter 令牌 规范正文保持机器可读层与代码事实来源同步。整个过程始终受控于两条总原则让设计系统增量、克制地生长以及让抽取的每个产物都能被既有系统与未来 Agent 稳定地理解与复用。这套流程文档既是给执行 extract 的 Agent 的操作规程也是人工重构前端的可用检查清单——六步顺序、两组量化/定性红线可以直接迁移到任何以「系统化复用」为目标的代码库治理工作中。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考