AI 应用人工智能AI 技能设计系统媒体生成【免费下载链接】open-design Best DeepSeek Harness Design Plugin. The open-source Claude Design alternative. ️ Local-first desktop app. ️ Your coding agent becomes the design engine: prototypes, landing pages, dashboards, slides, images video — real files, HTML/PDF/PPTX/MP4 export. Claude Code / Codex / Cursor / DeepSeek Harness / OpenCode 20 CLIs via BYOK.项目地址https://gitcode.com/gh_mirrors/opend/open-design点击查看免费下载在设计系统规模化落地时一个常被忽视却决定工程质量的问题是你手里的设计令牌Design Tokens到底从哪里来、凭什么可信、改了之后会不会破坏跨品牌的一致性。本文以开源仓库 open-design 中design-systems/refined设计系统包的source/evidence.md为核心拆解 OpenDesign 的「Design System 2.0 回填backfill」机制它如何用source/目录下的证据文件evidence 声明、token 源快照、token 合约报告把每一个 token 绑定精确回溯到tokens.css的声明行并借助 guard 脚本把「可追溯性」变成机器强制约束。读完本文你将掌握 OpenDesign 设计系统包的文件契约、TOKEN_SCHEMA 四层令牌模型、派生文件design-tokens.json/tailwind-v4.css的正确维护方式以及如何用pnpm guard验证一个设计系统包是否合规。一、什么是 Design System 2.0 backfill 与来源证据OpenDesign 仓库在design-systems/下维护了上百个品牌设计系统如 airbnb、apple、notion、stripe 等每个品牌目录都包含设计描述、编译后的 token 样式表与组件 fixture。refined是其中属于 Modern Minimal 类别的一个包目录位于 design-systems/refined。source/evidence.md即 design-systems/refined/source/evidence.md是该包的「来源证据声明」全文围绕一个关键立场展开This Design System 2.0 backfill is derived from the curated OpenDesign bundled fixture. It does not claim a fresh crawl of the original upstream brand repository or website.这句话定义了包的可信度边界refined的数据来源是OpenDesign 仓库内精选打包的 fixturebundled fixture而不是对上游品牌仓库或官网的重新抓取。这一声明不是可有可无的免责文字它直接决定了后续所有审计结论的强度——token-contract.report.json中每条 token 记录的reason字段都写着 no upstream recrawl was performed for this backfill与 evidence.md 的声明严格一致。从 manifest 看来源字段的机器化表达同样的来源信息被结构化进了包的机器可读入口 design-systems/refined/manifest.jsonsource: { type: bundled, origin: OpenDesign curated bundled fixture }而source.type的取值空间bundled/local/github/shadcn由清单校验逻辑在 design-systems/_schema/manifest.schema.ts 中强制bundled只允许携带origin说明local需要记录用户导入时的绝对路径github需要 URL 与 branch/commitshadcn需要 registry 引用信息。这意味着「来源」在 OpenDesign 中不是一个自由文本而是一等公民字段——证据声明既能给人读evidence.md也能被校验器验证manifest.schema.ts。二、来源证据文件清单source/ 目录的三件套evidence.md 明确列出了本次 backfill 的三个 fixture 文件以及它们在包内的角色文件相对路径作用设计描述design-systems/refined/DESIGN.mdAgent 提示词读取的规范设计散文视觉主题、色板、字体、间距、布局、组件、动效、语气与反模式Token 样式表design-systems/refined/tokens.css编译后的规范 token 绑定:root { ... }是所有派生文件的唯一事实源组件 fixturedesign-systems/refined/components.html自包含的参考组件集首段style内嵌与 tokens.css 完全一致的:root块可直接在浏览器独立渲染这三份文件构成了manifest.json中files字段的固定契约design必须是DESIGN.mdtokens必须是tokens.csscomponents可选但约定为components.html见 design-systems/_schema/manifest.schema.ts 中的validateFiles。DESIGN.md是视觉意图的来源定义了 refined 的「现代极简 优雅衬线字体 克制配色」风格。其中值得注意的一点是DESIGN.md声明的 Primary 色#3B82F6属于「style foundations」层面的 token 建议而实际落地到tokens.css时 refined 真正使用的品牌强调色是暖棕#9b5b32--accent——这恰好印证了 evidence.md 强调的「以 bundled fixture 为准、不做上游宣称」的可信度边界文档散文与编译 token 可能存在体系差异审计时以tokens.css声明行为准。三、Token 合约把每个绑定回溯到声明行evidence.md 的核心技术段落是 Token Contract 一节source/token-contract.report.jsonmaps every TOKEN_SCHEMA binding back to the committedtokens.cssdeclaration line.「TOKEN_SCHEMA」是 OpenDesign 的共享 token 契约规范实现位于 packages/contracts/src/design-systems/token-schema.tsdesign-systems/_schema/tokens.schema.ts仅做兼容性再导出。它定义了每个品牌tokens.css必须声明的一组 token按「谁决定值、缺省时怎么办」两个问题划分成四层层谁决定值品牌缺省时refined 中的示例A1-identity品牌作者guard 直接失败无回退--bg、--fg、--accent、--font-displayA1-structure品牌作者guard 直接失败--text-*字阶、--container-max、--section-y-*A2品牌带 fallback目前 guard 失败未来 derive 脚本可回填--motion-fast、--success、--space-4B-slot品牌或 schema 建议的别名guard 失败必须声明var(--兄弟token)或独立值--fg-2、--surface-warm、--meta、--border-soft此外还有品牌专属的C-extension不在共享 schema 中但通过BRAND_EXTENSIONS每品牌白名单或BRAND_EXTENSION_PREFIXES全局前缀白名单显式放行。refined 没有使用 C-extensiontoken-contract.report.json的 summary 中aliasTokens: 0表明它也没有使用 B-slot 别名折叠——四个 B-slot token 全部独立绑定。报告的结构56 个 token 的完整追溯design-systems/refined/source/token-contract.report.json 以schemaVersion: 1、contract: TOKEN_SCHEMA开头其 summary 给出了本包的一次完整体检summary: { totalTokens: 56, declaredTokens: 56, sourceBackedTokens: 56, sourceBackedA1: 26, fallbackTokens: 26, aliasTokens: 0, layerCounts: { A1-identity: 8, B-slot: 4, A2: 26, A1-structure: 18 }, score: 100, grade: excellent, recommendRebuild: false }这些数字可以直接与tokens.css的 57 行:root声明对应验证56 个 token 声明 1 行:root {。报告中每个 token 条目包含name/layer/valuetoken 名、分层与解析值confidence本次回填全部为high因为值直接来自 bundled fixturereason统一声明 no upstream recrawl was performed for this backfill与 evidence.md 相互印证sources精确到行号的文件引用例如[tokens.css:7]。以--accent-hover为例报告显示其值为color-mix(in oklab, var(--accent), black 8%)来源是tokens.css:18——这是用 OKLab 色彩空间按 8% 混合黑色生成的悬停态属于 A2 层schema 中同样带有fallback的推导型 token。tokens.source.json证据的原始快照与报告配套的 design-systems/refined/source/tokens.source.json 是更轻量的源快照sourceScope同样是open-design-bundled-fixture每条 token 记录只有name、value、layer、source四个字段source即tokens.css:行号。它是「抓取/回填发生时点」的静态留存而token-contract.report.json则是对照 TOKEN_SCHEMA 校验后的审计产物——两者配合回答「当时看到了什么」与「现在是否符合契约」两个问题。四、派生输出管理design-tokens.json 与 tailwind-v4.cssevidence.md 对维护流程给出了非常明确的指令design-tokens.jsonandtailwind-v4.cssare derived outputs and should be regenerated from the report and token stylesheet rather than edited by hand.也就是说包内有两类文件维护方式截然不同手写规范文件唯一事实源DESIGN.md、tokens.css、components.html派生输出禁止手改design-systems/refined/design-tokens.jsonDesign Tokens JSONformat: od-design-tokens/v1由tokens.css与token-contract.report.json推导其 summary 与报告完全一致56 token、score 100、grade excellentdesign-systems/refined/tailwind-v4.cssTailwind v4theme映射文件文件头注释明确写着 Derived from tokens.css. Keep tokens.css as the source of truth.。tailwind-v4.css的派生性质在结构上体现得尤其清楚它import ./tokens.css后在theme块内把每一个 token 映射为 Tailwind 命名空间——--color-accent: var(--accent)、--font-sans: var(--font-body)、--spacing-1: var(--space-1)、--shadow-raised: var(--elev-raised)、--duration-fast: var(--motion-fast)、--spacing-container-desktop: var(--container-gutter-desktop)。整份文件没有出现任何新的字面量全部通过var()转发从结构上杜绝了「两套值漂移」的可能。同理design-systems/refined/components.manifest.json 也是一个可重建缓存fixture.selectorCount: 48、classCount: 26由components.html与tokens.css推导属于同一类「按需重新生成」的派生文件。五、从证据到机器审计guard 检查如何守住契约evidence.md 描述的证据体系最终要落到可执行校验上。核心检查脚本是 scripts/check-tokens-fixture-sync.ts它导出了六个检查函数每个都注册为pnpm guard的独立条目使失败能精确归因到具体契约checkDesignSystemTokenFixtureSynccomponents.html的:root与tokens.css的:root在规范化后必须逐字节等价checkDesignSystemA1RequiredTokens每个品牌必须声明全部 A1-identity / A1-structure token缺失即失败checkDesignSystemA2RequiredTokens每个品牌必须声明全部 A2 tokenderive 脚本落地前如此见 design-systems/_schema/AGENTS.md 的说明checkDesignSystemBSlotRequiredTokens每个 B-slot token 必须出现在:root中可独立绑定也可用var(...)别名checkDesignSystemUnknownTokens品牌声明的每个 token 要么在共享 schema 中要么被BRAND_EXTENSIONS/BRAND_EXTENSION_PREFIXES显式放行checkDesignSystemA2DefaultsParity_schema/defaults.css中每个 A2 声明与token-schema.ts的fallback字段逐字节一致。为什么 A2 和 B-slot 在「有 fallback/alias」的情况下仍然要求品牌必须显式声明design-systems/_schema/AGENTS.md 给出了清晰的工程理由artifact 是由 Agent 把某一个品牌的:root块直接粘贴进单一style生成的不存在随包加载的全局默认样式表。如果tokens.css缺少--motion-fasttransition: var(--motion-fast)会解析为空并静默丢弃整条规则。因此运行时契约被收紧为「每个tokens.css必须声明每一个 A1 A2 B-slot token」defaults.css中的 fallback 是为未来的 derive 脚本准备的而不是运行时兜底。清单层面的校验则由 scripts/check-design-system-manifests.ts 负责凡是声明了 rich 字段usage、preview、sourceFiles、componentsManifest的包路径必须安全且存在、JSON 索引必须可解析、已提交的components.manifest.json必须与从components.htmltokens.css的全新推导一致。实操验证命令在仓库根目录可以单独运行 token 契约检查pnpm exec tsx scripts/check-tokens-fixture-sync.ts或运行包含全部设计系统子检查的完整 guardpnpm guard运行后refined 包的 56 个 token 会分别通过 A1 必选、A2 必选、B-slot 必选、未知 token 拦截、fixture 同步与 defaults 对齐六项检查与token-contract.report.json中score: 100 / grade: excellent / recommendRebuild: false的结论互相印证。六、把证据体系用于自己的设计系统包理解了 refined 的溯源结构后可以将其作为模板应用到其他设计系统包default、kami、openai、tom-modern 等均遵循同一契约。按 design-systems/refined/USAGE.md 的阅读顺序与约束维护一个合规包需要做到保留 schema token 名称原样——跨品牌切换的可靠性依赖共享 token 名不变不要用品牌私有名字替换--accent、--fg这类公共槽位使用--accent承载主操作、链接与焦点态每屏可见强调不超过两处schema 注释中标注为 lint 强制优先复用components.manifest.json中的既有组件组而不是发明新控件把source/目录当作 bundled fixture 回填的审计证据不要宣称存在未经证实的上游来源绝不绕过tokens.css直接手改design-tokens.json或tailwind-v4.css——它们是派生文件改动会立即被 guard 的 fixture 同步检查识别为漂移。若你的品牌需要 schema 之外的专属 token如tom-modern的--tm-shadow-hard、kami的--leading-display应走 C-extension 白名单路径当第二个品牌采用同名 token 时再按 C → B-slot → A2 的晋升规则将其移入共享 TOKEN_SCHEMA规则详见 design-systems/_schema/AGENTS.md 的 promotion path 一节。七、总结source/evidence.md篇幅虽短却是 OpenDesign 设计系统质量体系的缩影它用「来源范围声明」划定可信边界用tokens.source.json留存原始快照用token-contract.report.json把 56 个 TOKEN_SCHEMA 绑定逐条映射回tokens.css声明行并用「派生文件禁止手改」的纪律保证design-tokens.json、tailwind-v4.css与事实源永不漂移。最终这整套证据被scripts/check-tokens-fixture-sync.ts的六项 guard 检查与scripts/check-design-system-manifests.ts的清单校验固化为机器强制约束——让「这个设计系统包是可信的、可审计的、可安全切换的」从口头承诺变成可重复验证的工程结论。对于任何需要规模化维护多品牌设计令牌的团队这套「散文声明 结构快照 逐行映射报告 派生文件纪律 guard 强校验」的溯源模式都值得直接借鉴。赞分享AI 应用人工智能AI 技能设计系统媒体生成【免费下载链接】open-design Best DeepSeek Harness Design Plugin. The open-source Claude Design alternative. ️ Local-first desktop app. ️ Your coding agent becomes the design engine: prototypes, landing pages, dashboards, slides, images video — real files, HTML/PDF/PPTX/MP4 export. Claude Code / Codex / Cursor / DeepSeek Harness / OpenCode 20 CLIs via BYOK.项目地址https://gitcode.com/gh_mirrors/opend/open-design点击查看免费下载相关推荐OpenDesign 设计系统 2.0 源码证据机制解析以 Lingo 包为例的 Token 合约追溯与 Backfill 来源审计指南OpenDesign 设计系统 2.0 源码证据机制解析以 Lingo 包为例的 Token 合约追溯与 Backfill 来源审计指南 导读 本文基于 deAI 应用人工智能AI 技能设计系统媒体生成OpenDesign 设计系统来源证据与 Token 合约审计以 Lovable 包为例OpenDesign 设计系统来源证据与 Token 合约审计以 Lovable 包为例 设计系统包不仅要交付长得像的界面还要回答一个问题这些设计决策AI 应用人工智能AI 技能设计系统媒体生成OpenDesign 设计系统包的来源证据与 Token 契约审计以 Meta (Store) 设计系统 2.0 Backfill 为例OpenDesign 设计系统包的来源证据与 Token 契约审计以 Meta Store 设计系统 2.0 Backfill 为例 设计系统包进入 OpenAI 应用人工智能AI 技能设计系统媒体生成创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考