十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

OpenDesign Design System 2.0 源证据契约解析:以 GitHub 品牌包为例的 Token 可追溯审计实践

OpenDesign Design System 2.0 源证据契约解析:以 GitHub 品牌包为例的 Token 可追溯审计实践 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 仓库中design-systems/目录下每个子目录都是一个可移植的设计系统包当前共 151 个。自 Design System 2.0 起包的元数据层引入了源证据source evidence概念以 evidence.md 为核心的source/目录记录包内tokens.css每个 Token 的声明来源并通过token-contract.report.json建立从 TOKEN_SCHEMA 契约到具体 CSS 声明行的双向映射。阅读本文后你将掌握Design System 2.0 包的标准目录结构与sourceFiles字段的语义、Token 契约报告的指标含义、四层 Token 分层模型A1-identity / A1-structure / A2 / B-slot以及为什么design-tokens.json与tailwind-v4.css是只能重新生成、不可手改的派生产物。一、evidence.mdDesign System 2.0 包的证据文件design-systems/github/source/evidence.md 是 GitHub 品牌包design-systems/github的证据声明文件全文围绕三个核心事实展开1. Source Scope来源边界该文档首先明确此 Design System 2.0 backfill回填包的定位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.即GitHub 包的内容源自 OpenDesign 官方整理的捆绑夹具curated bundled fixture并未声称对上游品牌仓库或网站进行了全新爬取。这一点与manifest.json中的source字段完全对应source: { type: bundled, origin: OpenDesign curated bundled fixture }manifest.schema.ts 中定义了四种来源类型bundled仓库自带、local用户本地导入、github远程导入、shadcn注册表导入。其中bundled类型只允许type与origin两个键。换言之来源证据provenance是 v1 清单校验的第一道关卡——一个包声明自己来自何处就必须符合对应的 schema 约束。2. Included Fixture Files夹具文件清单evidence.md 明确列出构成该包的三个夹具文件design-systems/github/DESIGN.md— 设计意图散文Agent 的权威提示词来源design-systems/github/tokens.css— 编译后的语义 Token 样式表design-systems/github/components.html— 独立组件夹具这与清单files字段的定义一一对应design、tokens、components是 v1 契约中的固定文件名也与 design-systems/README.md 中每个捆绑包最小机器可读形态的描述一致design-systems/slug/ ├── manifest.json ├── DESIGN.md └── tokens.css3. Token ContractToken 契约evidence.md 用两句话定义了证据与派生产物的关系这是整个 Design System 2.0 数据流的枢纽source/token-contract.report.jsonmaps every TOKEN_SCHEMA binding back to the committedtokens.cssdeclaration line.design-tokens.jsonandtailwind-v4.cssare derived outputs and should be regenerated from the report and token stylesheet rather than edited by hand.即报告负责溯源派生文件负责消费。Token 契约报告把每一个 TOKEN_SCHEMA 绑定映射回tokens.css的具体声明行而design-tokens.jsonDesign Tokens JSON与tailwind-v4.cssTailwind v4 映射都是派生输出必须从报告与 Token 样式表重新生成而不是手工编辑。二、source/ 目录在包结构中的位置与 manifest 声明GitHub 包的完整目录结构如下仓库根路径design-systems/github/ ├── manifest.json ├── DESIGN.md ├── USAGE.md ├── tokens.css ├── components.html ├── components.manifest.json ├── design-tokens.json ├── tailwind-v4.css ├── preview/ │ ├── colors.html │ ├── spacing.html │ └── typography.html └── source/ ├── evidence.md ├── token-contract.report.json └── tokens.source.json其中source/目录由 manifest.json 的sourceFiles字段声明sourceFiles: { evidence: source/evidence.md, tokens: source/tokens.source.json, report: source/token-contract.report.json }在 manifest.schema.ts 中sourceFiles被建模为可选字段集合允许的键为scanned、evidence、tokens、report、snippets。校验器validateSourceFiles会对每个值调用expectSafeRelativePath即路径必须以相对路径声明不允许绝对路径、空段、.或..段见 manifest.schema.ts。值得注意的是该字段在 PR0 阶段是结构性的——守卫guard脚本验证其路径与 JSON 形态运行时发现行为不变只有选择携带manifest.json的包才会被强制校验。这保证了仅含 DESIGN.md 的旧包依然兼容。三、Token Contract Report逐 Token 溯源的机器可读报告source/token-contract.report.json 是 evidence.md 中Token Contract的落地实现。它包含summary汇总指标与 56 个 Token 的逐条映射其汇总如下{ totalTokens: 56, declaredTokens: 56, sourceBackedTokens: 56, sourceBackedA1: 26, fallbackTokens: 26, aliasTokens: 1, layerCounts: { A1-identity: 8, B-slot: 4, A2: 26, A1-structure: 18 }, score: 100, grade: excellent, recommendRebuild: false }这些指标的解读totalTokens / declaredTokens 56TOKEN_SCHEMA 契约要求 GitHub 包声明 56 个 Token报告确认全部已声明。sourceBackedTokens 56全部 56 个 Token 都能在tokens.css中找到对应声明行通过sources数组记录例如tokens.css:30。sourceBackedA1 26A1 层identity 8 structure 18全部有源支持。fallbackTokens 26恰好等于 A2 层的 26 个 Token——A2 是必带回退值的层详见下文分层模型。aliasTokens 1仅--surface-warm通过var(--surface)别名到兄弟 Token。score 100, grade excellent, recommendRebuild false报告确认该包无需重建。每条 Token 记录的核心结构以--bg为例{ name: --bg, layer: A1-identity, value: #ffffff, confidence: high, reason: Bundled tokens.css declares --bg; no upstream recrawl was performed for this backfill., sources: [tokens.css:30], sourceName: --bg }注意reason字段反复出现的措辞no upstream recrawl was performed for this backfill——它把来源边界的声明下沉到了每一条 Token 记录与 evidence.md 的 Source Scope 遥相呼应构成完整审计链。这正是 evidence 体系的设计意图让任何审计者都能从 Token 反查到声明行并同时获知该值只是 bundled fixture 的事实而不是从上游实时爬取的结果。四、四层 Token 分层模型TOKEN_SCHEMA要理解为什么报告按 A1-identity / A1-structure / A2 / B-slot 分层统计需要阅读 packages/contracts/src/design-systems/token-schema.ts 中的契约定义。四层模型由谁决定值与品牌缺失时会发生什么两个维度区分层性质说明GitHub 包中的示例A1-identity必填无回退Token 本身就是品牌背景、前景、强调色、字体栈--bg: #ffffff、--fg: #1f2328、--accent: #0969daA1-structure必填无跨品牌默认字体刻度、布局网格、区块节奏等结构性决策每个品牌自行定义--text-base: 14px、--container-max: 1280pxA2最终 tokens.css 必填但有 schema 级回退_schema/defaults.css提供默认值derive 脚本可在品牌未指定时内联--success: #1a7f37默认 #16a34aB-slot可选槽位可var()别名为跨品牌一致性存在无该层的品牌可别名到兄弟 Token--surface-warm: var(--surface)为什么 A2 是必带回退而非可选契约注释给出关键工程理由产物由 Agent 将一个品牌的:root块粘贴进单个style生成不存在来自全局默认样式表的运行时级联。如果粘贴的tokens.css缺失某个var()目标会产生损坏产物——例如transition: var(--motion-fast)解析为空后整条规则被丢弃。因此运行时契约是每个 tokens.css 必须声明全部 A1 A2 B-slot Token回退值存在于_schema/defaults.css仅供 derive 脚本内联。GitHub 包的 56 个 Token 分层如下与 tokens.css 声明一一对应A1-identity8--bg、--surface、--fg、--muted、--border、--accent、--font-display、--font-bodyA1-structure188 个字号刻度--text-xs~--text-4xl 2 个行高 1 个字距 3 个区块纵向节奏--section-y-* 4 个容器尺寸--container-max与 3 个 gutterA226--accent-on、--accent-hover、--accent-active、--success、--warn、--danger、--font-mono、8 个间距、4 个圆角、3 个阴影、--focus-ring、2 个动效时长、--ease-standardB-slot4--surface-warm、--fg-2、--meta、--border-soft五、tokens.cssGitHub 品牌的语义 Token 实现design-systems/github/tokens.css 是整个 GitHub 包的单一事实来源。它的文件头注释用三句话概括品牌身份与 DESIGN.md 完全一致纯白画布#ffffff canvas-subtle 次级表面#f6f8fa发丝级边框#d0d7de定义每个面板——密度优先于装饰。全站 system-ui 字体栈不加载自定义 webfont正文 14px而非 16px是产品密度身份的体现。Primer Blue#0969da用于全部交互暗示GitHub Green#1a7f37仅保留给成功/合并状态。几个值得注意的 schema 决策均已在 tokens.css 注释中记录--surface-warm别名到--surfacePrimer 体系中没有暖色层级。--fg-2与--fg同为#1f2328Primer 中没有 B-slot 文字拆分--meta与--muted同为#656d76。--radius-sm与--radius-md均为 6px——6px 是 Primer 全交互元素的通用圆角。--accent-active使用color-mix(in oklab, var(--accent), black 14%)计算按下态而非硬编码色值。阴影体系--elev-flat: none、--elev-ring: 0 0 0 1px var(--border)发丝环、--elev-raised仅用于极少数浮动元素——用边框而非阴影表达层级是 GitHub 表面的核心设计判断。焦点环--focus-ring: 0 0 0 3px rgba(9, 105, 218, 0.3)即 Primer 风格的 3px 强调色光环。这些语义 Token 在设计层面有完整依据DESIGN.md 的## 2. Color Palette Roles给出了每个颜色的角色定位Canvas Default / Fg Muted / Primer Blue / Success-Merge Green / Closed-Danger Red / Done Purple / Sponsor Pink## 5. Spacing Layout定义了 4px 基准网格与 1280px 容器上限## 6. Motion规定了 80ms hover / 200ms 开合与ease-out。而tokens.css正是把这些设计决策统一编译进 56 个 CSS 自定义属性的产物。六、派生产物design-tokens.json 与 tailwind-v4.cssevidence.md 强调的两个派生文件在仓库中均有明确实现与校验约束design-tokens.jsondesign-systems/github/design-tokens.json 是od-design-tokens/v1格式的 Design Tokens JSON。其头部声明了派生关系source: { tokensCss: tokens.css, tokenContractReport: source/token-contract.report.json }它把tokens.css的 56 个声明转换成结构化 Token 记录含name、value、type、layer、confidence、reason、sources等字段type按值推断为color、dimension、fontFamily、number、shadow、duration、cubicBezier等。仓库的 manifest 校验脚本 check-design-system-manifests.ts 明确规定design-tokens.json的存在要求sourceFiles.report同时存在——派生产物必须有溯源报告背书。tailwind-v4.cssdesign-systems/github/tailwind-v4.css 以注释开宗明义Derived from tokens.css. Keep tokens.css as the source of truth.它通过theme块把每个 CSS 变量映射为 Tailwind v4 主题键theme { --color-bg: var(--bg); --color-accent: var(--accent); --color-success: var(--success); --font-sans: var(--font-body); --font-mono: var(--font-mono); --text-base: var(--text-base); --radius-sm: var(--radius-sm); --shadow-raised: var(--elev-raised); --duration-fast: var(--motion-fast); /* ... 共 62 条映射 */ }命名映射遵循 Tailwind 惯例颜色映射为--color-*字体为--font-*字号为--text-*圆角为--radius-*阴影为--shadow-*时长与缓动为--duration-*/--ease-*间距同时映射--spacing-*与分区节奏--spacing-section-*。为什么不能手改这两个文件因为它们是缓存而非竞争性事实源。如果手工修改design-tokens.json或tailwind-v4.css而不更新tokens.css就会破坏派生文件一致性——这正是 evidence.md 明确警告的场景。修改的正确姿势是编辑tokens.css必要时同步 DESIGN.md再从 Token 契约报告与样式表重新生成派生文件。七、仓库守卫证据契约如何被强制校验evidence.md 定义的契约不是纸面约定仓库中有专门的守卫脚本强制执行。在 scripts/check-design-system-manifests.ts 中可以找到路径存在性校验sourceFiles中声明的每个文件evidence、tokens、report、snippets都必须存在第 110、133 行。派生文件背书design-tokens.json要求sourceFiles.report存在第 195 行。导入模式约束hybrid导入必须声明sourceFiles.evidence第 461-462 行verbatim导入必须声明sourceFiles.tokens与sourceFiles.snippets第 465-469 行——即证据要求随导入保真度提升而变严。另一个守卫 scripts/check-design-system-package-quality.ts 将imported package has source evidence与imported package has token evidence列为导入包的质量底线记录项。此外packages/contracts/src/design-systems/token-schema.ts头部注释还提到design-system: A2 defaults parity守卫用于强制 TOKEN_SCHEMA 文件与_schema/defaults.css之间 A2 回退值的字节级一致。因此整个证据链的信任模型是DESIGN.md设计意图→ tokens.css编译实现→ token-contract.report.json逐 Token 溯源→ design-tokens.json / tailwind-v4.css派生缓存→ 守卫脚本一致性强制。任何一环被破坏手改派生文件、删除证据文件、声明不存在的路径守卫脚本都会在pnpm guard/pnpm typecheck阶段报错。八、实践如何审阅与重新生成一个 Design System 2.0 包综合 USAGE.md 与 evidence.md 的指导审阅或重建 GitHub 这类捆绑包的建议流程先读USAGE.md理解包契约再读DESIGN.md把握视觉意图、约束与反模式anti-patterns。将tokens.css粘贴到产物第一个style块中再编写组件 CSS——所有取值必须引用:root中的语义 Token禁止在 Token 块外散落裸 hex 值USAGE.md 的 Avoid 条款。需要精确选择器或状态时查阅components.html需要快速组件清单时使用components.manifest.json。视觉抽查时打开preview/下的colors.html、typography.html、spacing.html三个预览页。核对溯源查看source/token-contract.report.json中每个 Token 的sources行号是否与tokens.css实际声明行吻合summary.score是否仍为 100。若设计变更只改tokens.css与DESIGN.md然后从报告重新生成design-tokens.json与tailwind-v4.css最后运行pnpm guard与pnpm typecheck验证全部守卫通过。同时要遵守 evidence.md 划定的边界不要声称该包拥有上游原始来源证据——它是基于 curated bundled fixture 的回填包reason字段中的no upstream recrawl声明是审计结论的一部分不应被改写或删除。小结source/evidence.md篇幅虽短却是 OpenDesign Design System 2.0 包质量体系的关键枢纽它定义了来源边界bundled fixture、夹具清单DESIGN.md / tokens.css / components.html与 Token 契约报告溯源 派生产物再生成三大约定。结合 manifest.json 的sourceFiles声明、token-contract.report.json 的逐 Token 溯源、tokens.css 的 56 个语义 Token 实现、token-schema.ts 的四层模型以及守卫脚本的强制校验可以得出清晰的工程结论证据不是装饰而是让 151 个品牌包在 Agent 生成产物的链路上保持可审计、可重建、跨品牌一致的结构化地基。对希望贡献新设计系统包或审计现有包的开发者而言从 evidence.md 出发沿这条链路走一遍就能完整掌握 Design System 2.0 的信任模型与操作规范。赞分享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 Design System 2.0 源码证据与 Token 契约解析以 Cafe 主题包为例OpenDesign Design System 2.0 源码证据与 Token 契约解析以 Cafe 主题包为例 Cafe 是 OpenDesign 仓库中AI 应用人工智能AI 技能设计系统媒体生成OpenDesign 设计系统 2.0 溯源审计实战以 design-systems/canva 的 Token 契约与证据链为例OpenDesign 设计系统 2.0 溯源审计实战以 design systems/canva 的 Token 契约与证据链为例 本文围绕 OpenDesiAI 应用人工智能AI 技能设计系统媒体生成G-Helper技术架构深度解析开源华硕笔记本硬件控制终极方案G Helper技术架构深度解析开源华硕笔记本硬件控制终极方案 在Windows笔记本生态系统中华硕设备的硬件控制一直依赖于Armoury Crate这类重AI 应用人工智能AI 技能设计系统媒体生成创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表