设计规范

设计系统（design system）是一套可复用的组件、模式、指南与代码的集合，用于在多个产品与团队间保持界面一致性；设计规范（design specification）则是对具体设计决策（尺寸、颜色、间距、状态、交互行为等）的书面规定。二者常被混用，但设计系统在范围上通常大于设计规范：设计规范是设计系统的组成部分之一，而非其全部。^{44Design Systems: A Practical Guide to Building and Maintaining Design Systemssmashingmagazine.com前往参考资料 ↓在新标签页中打开|55Design Tokens: What They Are and Why They Mattercss-tricks.com前往参考资料 ↓在新标签页中打开}

在业界通行的定义中，设计系统至少包含设计令牌（design tokens）、组件库、模式库与使用指南等层次；设计规范往往对应其中的令牌与组件规格层，即把设计决策固化为可查阅、可执行的规则。^{55Design Tokens: What They Are and Why They Mattercss-tricks.com前往参考资料 ↓在新标签页中打开|66Design Systems Handbookdesignbetter.co前往参考资料 ↓在新标签页中打开}

设计规范与设计系统在治理方式上存在区别：设计规范偏向文档化的静态约定，更新周期较长；设计系统强调规范与代码同源、随产品迭代持续演进，通常配有版本管理与发布流程。^{44Design Systems: A Practical Guide to Building and Maintaining Design Systemssmashingmagazine.com前往参考资料 ↓在新标签页中打开|77Design System vs. Style Guide: What's the Difference?uxdesign.cc前往参考资料 ↓在新标签页中打开}

设计系统与设计规范的关系可以概括为「系统是载体，规范是内容」：设计系统提供组件、工具与流程等承载机制，设计规范提供具体的约束与标准；脱离设计系统的规范容易沦为无人执行的文档，脱离规范的设计系统则容易失去一致性约束。^{44Design Systems: A Practical Guide to Building and Maintaining Design Systemssmashingmagazine.com前往参考资料 ↓在新标签页中打开|66Design Systems Handbookdesignbetter.co前往参考资料 ↓在新标签页中打开}

在智能座舱等跨端场景中，设计规范需要同时覆盖车载 HMI 与移动端、Web 端等多类终端，设计系统则通过令牌与组件复用把这些规范落到不同平台，二者形成「规范定义标准、系统保证落地」的分工。^{77Design System vs. Style Guide: What's the Difference?uxdesign.cc前往参考资料 ↓在新标签页中打开|88Automotive HMI Design Guidelinessae.org前往参考资料 ↓在新标签页中打开}

设计规范与品牌手册在核心目标上存在根本差异：品牌手册的首要目标是确保品牌识别要素（标志、色彩、字体、语调）在各类传播场景中保持一致，其内容以品牌价值观、视觉识别系统和应用示例为主；而设计规范的首要目标是确保产品界面与交互行为在跨团队、跨平台交付中保持一致，其内容以组件库、布局栅格、交互状态、无障碍要求和代码实现规则为主。^{11Design Systems: A Practical Guide to Creating Design Languages for Digital Productssmashingmagazine.com前往参考资料 ↓在新标签页中打开|99Brand guidelinesen.wikipedia.org前往参考资料 ↓在新标签页中打开}

品牌手册通常由品牌或市场部门主导制定与维护，服务对象包括广告、公关、包装、线下物料等传播职能；设计规范通常由产品设计团队（或设计系统团队）主导，服务对象是产品经理、设计师和前端工程师，其更新节奏与产品迭代周期绑定。^{99Brand guidelinesen.wikipedia.org前往参考资料 ↓在新标签页中打开|66Design Systems Handbookdesignbetter.co前往参考资料 ↓在新标签页中打开}

在内容粒度上，品牌手册对标志最小尺寸、安全空间、色彩色值（如 Pantone、CMYK、RGB）给出规定，但一般不涉及界面组件的交互状态；设计规范则必须定义按钮的默认、悬停、按下、禁用、聚焦等状态，以及表单校验、加载、空状态等动态行为，这些内容在品牌手册中通常缺席。^{11Design Systems: A Practical Guide to Creating Design Languages for Digital Productssmashingmagazine.com前往参考资料 ↓在新标签页中打开|1010Building a Design System: Brand vs. Productuxdesign.cc前往参考资料 ↓在新标签页中打开}

设计规范与品牌手册并非互斥：成熟的设计系统往往将品牌手册中的色彩、字体、标志使用规则作为"品牌基础"层纳入设计规范，再在其上叠加组件与模式层，因此二者在组织实践中常呈现为包含或引用关系，而非替代关系。^{99Brand guidelinesen.wikipedia.org前往参考资料 ↓在新标签页中打开|1111Design Tokensw3.org前往参考资料 ↓在新标签页中打开}

从交付物形态看，品牌手册多以 PDF 或静态网页形式发布，更新频率低、版本周期以年计；设计规范则越来越多地以可检索的在线文档、带代码片段的组件文档站（如 Storybook 类工具）形式存在，并与代码仓库联动，版本更新可达到周或日级别。^{66Design Systems Handbookdesignbetter.co前往参考资料 ↓在新标签页中打开|1212Design Systemsnngroup.com前往参考资料 ↓在新标签页中打开}

在治理与合规层面，品牌手册的偏离通常通过品牌审批流程（如市场物料上线前的品牌审核）来约束；设计规范的偏离则更多依赖设计评审、组件库代码审查和设计令牌（design tokens）的单一来源来约束，前者是流程性治理，后者是工程性治理。^{1010Building a Design System: Brand vs. Productuxdesign.cc前往参考资料 ↓在新标签页中打开|1212Design Systemsnngroup.com前往参考资料 ↓在新标签页中打开}

有观点认为，随着设计令牌将品牌色彩与字体抽象为可被代码消费的变量，品牌手册与设计规范之间的边界正在变得模糊，部分组织已将二者合并为统一的"品牌与产品设计系统"文档；但这一做法在大型多品牌企业中仍不普遍，因为品牌传播与产品交付的决策链和更新节奏差异较大。^{1111Design Tokensw3.org前往参考资料 ↓在新标签页中打开|1212Design Systemsnngroup.com前往参考资料 ↓在新标签页中打开}

视觉规范是设计规范中规定界面视觉表现层规则的部分，通常涵盖色彩、字体排印、图标、间距与栅格、圆角与阴影、动效等基础视觉要素，以及这些要素在组件与页面中的组合方式。^{1313Material Design 3 — Foundationsm3.material.io前往参考资料 ↓在新标签页中打开|1414Human Interface Guidelinesdeveloper.apple.com前往参考资料 ↓在新标签页中打开}

色彩规范一般以设计令牌（design token）的形式定义语义化色板，区分品牌色、功能色（成功、警告、错误、信息）与中性色，并规定各层级文字与背景的搭配组合及其对比度要求。^{1313Material Design 3 — Foundationsm3.material.io前往参考资料 ↓在新标签页中打开|1515Web Content Accessibility Guidelines (WCAG) 2.2w3.org前往参考资料 ↓在新标签页中打开}

字体排印规范规定字族、字重、字号阶梯、行高与字间距，并常以「字号/行高」配对的形式给出层级化文本样式，供标题、正文、辅助文字等场景直接引用。^{1313Material Design 3 — Foundationsm3.material.io前往参考资料 ↓在新标签页中打开|1414Human Interface Guidelinesdeveloper.apple.com前往参考资料 ↓在新标签页中打开}

间距与栅格规范通过一套基准单位（常见为 4 或 8 的倍数）约束内外边距与元素间隔，并以列栅格与断点定义响应式布局，使不同页面在视觉节奏上保持一致。^{1414Human Interface Guidelinesdeveloper.apple.com前往参考资料 ↓在新标签页中打开|1616Design Tokens Format Moduletr.designtokens.org前往参考资料 ↓在新标签页中打开}

图标规范通常规定图标的绘制网格、线宽、端点与转角样式、尺寸档位与命名规则，以保证同一套图标在视觉重量上统一。^{1313Material Design 3 — Foundationsm3.material.io前往参考资料 ↓在新标签页中打开|1717Carbon Design System — Iconographycarbondesignsystem.com前往参考资料 ↓在新标签页中打开}

圆角、阴影与层级规范用一套有限的层级（elevation）档位表达元素的前后关系，避免同一界面中出现随意取值的阴影与圆角。^{1313Material Design 3 — Foundationsm3.material.io前往参考资料 ↓在新标签页中打开|1414Human Interface Guidelinesdeveloper.apple.com前往参考资料 ↓在新标签页中打开}

动效规范规定过渡时长、缓动曲线与触发场景，用于表达状态变化与空间关系，同时约束动效不得妨碍操作效率。^{1313Material Design 3 — Foundationsm3.material.io前往参考资料 ↓在新标签页中打开|1818Motion — Material Designm3.material.io前往参考资料 ↓在新标签页中打开}

视觉规范中的对比度要求通常引用 WCAG 2.x 的可访问性准则：正文文本与其背景的对比度至少为 4.5:1，大号文本至少为 3:1。^{1515Web Content Accessibility Guidelines (WCAG) 2.2w3.org前往参考资料 ↓在新标签页中打开}

视觉规范与设计令牌、组件库之间存在分层关系：视觉规范给出规则与取值，设计令牌把取值编码为可被代码消费的变量，组件库再引用令牌实现具体组件，从而让视觉规则在设计与开发两侧保持同源。^{1616Design Tokens Format Moduletr.designtokens.org前往参考资料 ↓在新标签页中打开|1919Carbon Design Systemcarbondesignsystem.com前往参考资料 ↓在新标签页中打开}

成熟的视觉规范通常同时提供正例与反例（do / don't）示例，并说明规则的适用边界与例外审批方式，而非仅罗列取值。^{1313Material Design 3 — Foundationsm3.material.io前往参考资料 ↓在新标签页中打开|1414Human Interface Guidelinesdeveloper.apple.com前往参考资料 ↓在新标签页中打开}

设计规范通常被划分为视觉规范与交互规范两大类；其中交互规范侧重整体的层级关系、逻辑与流程方面的定义，对已确认会使用的常用组件给出概念定义，由于业务存在不确定性，交互规范更多是框定一个范围，设计师在该范围内进行设计。^{2020为什么要制定设计规范？_手机网易网m.163.com前往参考资料 ↓在新标签页中打开}

交互规范大体上包含结构、布局、公用组件、业务组件、反馈、公用流程（如编辑）与业务流程（如下单）等类别，再在这些大类下逐层细分，构成完整的规范体系。^{2020为什么要制定设计规范？_手机网易网m.163.com前往参考资料 ↓在新标签页中打开}

与交互规范相比，视觉规范会事无巨细地规定字体、颜色、边距等具体参数，属于明确且基本不可随意变更的规范，除非出现新组件，已有内容都要按规范实现。^{2020为什么要制定设计规范？_手机网易网m.163.com前往参考资料 ↓在新标签页中打开}

在多人协作的设计环境中，交互规范对达成设计统一性起着越来越重要的作用；制定规范的初衷包括团队内部协作、可追溯的版本更新、组件化设计与复用、提升开发效率，以及在多条业务线并行时起到统一作用。^{2020为什么要制定设计规范？_手机网易网m.163.com前往参考资料 ↓在新标签页中打开}

组件规范是设计规范中针对可复用界面单元（按钮、输入框、下拉菜单、卡片、标签、提示条等）所定义的统一约束集合，通常规定每个组件的结构、尺寸、状态、交互行为、可访问性要求与使用场景，使不同页面与不同团队产出的界面保持视觉与行为一致。^{2121Component guidelinesdesign-system.service.gov.uk前往参考资料 ↓在新标签页中打开|2222Componentsm3.material.io前往参考资料 ↓在新标签页中打开}

在主流设计系统的文档结构中，组件规范一般按「用途说明—结构解剖—变体与尺寸—状态—交互与动效—可访问性—使用禁忌」的顺序组织，其中状态部分至少覆盖默认、悬停、聚焦、按下、禁用与加载等情形，以保证开发实现与设计稿一一对应。^{2121Component guidelinesdesign-system.service.gov.uk前往参考资料 ↓在新标签页中打开|2323Component architecturecarbondesignsystem.com前往参考资料 ↓在新标签页中打开}

组件规范中的尺寸与间距通常不写死像素值，而是引用设计令牌（颜色、字体、间距、圆角、阴影等基础变量），组件层只消费令牌而不直接定义原始值，从而在换肤、暗色模式与多端适配时只需改动令牌层。^{2222Componentsm3.material.io前往参考资料 ↓在新标签页中打开}

组件规范与代码实现之间通常通过「设计稿组件—代码组件」的命名与属性映射表来对齐，规范文档中会标注每个变体对应的组件属性（props）与默认值，减少设计交付与前端实现之间的偏差。^{2323Component architecturecarbondesignsystem.com前往参考资料 ↓在新标签页中打开}

可访问性是组件规范的必备组成：规范需为每个交互组件规定键盘操作方式、焦点可见样式、语义角色与 ARIA 属性、对比度下限与触控目标最小尺寸，常见做法是直接引用 WCAG 2.2 的成功准则编号作为验收依据。^{1515Web Content Accessibility Guidelines (WCAG) 2.2w3.org前往参考资料 ↓在新标签页中打开|2424ARIA Authoring Practices Guide (APG): Patternsw3.org前往参考资料 ↓在新标签页中打开}

组件规范通常配套「使用指南」与「反例」两部分：前者说明何时选用该组件、何时应改用其他组件，后者以图示列出常见误用，用于在评审中快速判定实现是否合规。^{2121Component guidelinesdesign-system.service.gov.uk前往参考资料 ↓在新标签页中打开|2323Component architecturecarbondesignsystem.com前往参考资料 ↓在新标签页中打开}

组件规范的版本管理需要与组件库的发版节奏绑定，规范中应记录每个组件的引入版本、废弃（deprecated）状态与替代方案，避免旧组件在多产品线中长期并存造成维护负担。^{2525Semantic Versioning 2.0.0semver.org前往参考资料 ↓在新标签页中打开}

组件规范的粒度存在取舍：粒度过细（为每个业务场景定制组件）会导致组件数量膨胀、复用率下降；粒度过粗则迫使业务方自行拼装，反而产生不一致。常见做法是区分基础组件与业务组件两层，基础组件严格收敛，业务组件允许在基础组件之上组合。^{2222Componentsm3.material.io前往参考资料 ↓在新标签页中打开}

在智能座舱场景中，组件规范还需额外规定驾驶态下的组件约束，例如行车中禁用或简化复杂交互组件、增大触控目标、限制动效时长与闪烁频率，以降低驾驶员分心风险。^{2626NHTSA Driver Distraction Guidelinesnhtsa.gov前往参考资料 ↓在新标签页中打开}

内容与文案规范（content and copy guidelines）是设计规范中约束「界面里写什么、怎么写」的部分，与色彩、间距、组件等视觉规范并列，属于设计系统的基础层。它通常规定语气与语调（tone of voice）、术语表、句式与标点、大小写、数字与日期格式、错误信息写法、按钮与标签的措辞等内容。^{11Design Systems: A Practical Guide to Creating Design Languages for Digital Productssmashingmagazine.com前往参考资料 ↓在新标签页中打开}

Mailchimp 的《Content Style Guide》是业界被广泛引用的内容规范范例，它把品牌语气定义为「我们说话的方式」，并给出「用平实语言」「写得像人说话」「该轻松时轻松、该严肃时严肃」等可操作原则，同时配套一份术语与用法词表。^{2727Content Style Guidestyleguide.mailchimp.com前往参考资料 ↓在新标签页中打开}

GOV.UK 的设计系统设有独立的「Content style guide」栏目，其内容规范覆盖标点、数字、日期与时间、缩写、专业术语、链接文字、错误信息等条目，并明确要求使用平实英语（plain English），面向公众服务的文案以可读性优先。^{2828Content style guidedesign-system.service.gov.uk前往参考资料 ↓在新标签页中打开}

苹果的《Human Interface Guidelines》在「Writing」章节中提出界面文案应清晰、简洁，并强调文案要与界面元素配合、避免冗余，同时给出大小写、标点与术语使用的一般性建议。^{2929Human Interface Guidelines: Writingdeveloper.apple.com前往参考资料 ↓在新标签页中打开}

微软的《Microsoft Writing Style Guide》是面向技术文档与界面文案的公开风格指南，规定语气应「温暖而放松、理性而清晰」，并给出全球化写作、无障碍写作、术语与大小写等具体规则，被大量产品团队直接借用为文案规范底本。^{3030Microsoft Writing Style Guidelearn.microsoft.com前往参考资料 ↓在新标签页中打开}

内容与文案规范通常包含一份术语表（glossary / word list），用于统一同一概念在产品各处的叫法，避免同义词混用造成的理解成本；术语表条目一般给出推荐用词、禁用词与示例句。^{2727Content Style Guidestyleguide.mailchimp.com前往参考资料 ↓在新标签页中打开|2828Content style guidedesign-system.service.gov.uk前往参考资料 ↓在新标签页中打开}

错误信息（error message）的写法是内容规范中的高频条目，通行做法是说明发生了什么、为什么发生、用户下一步能做什么，避免使用错误码或指责性措辞作为唯一提示。^{2828Content style guidedesign-system.service.gov.uk前往参考资料 ↓在新标签页中打开|3030Microsoft Writing Style Guidelearn.microsoft.com前往参考资料 ↓在新标签页中打开}

内容规范中的语气与语调通常按场景分层：品牌宣传、常规操作、出错与高风险操作使用不同的语气强度，规范会给出各场景的示例，而不是只给一套统一口吻。^{2727Content Style Guidestyleguide.mailchimp.com前往参考资料 ↓在新标签页中打开|3030Microsoft Writing Style Guidelearn.microsoft.com前往参考资料 ↓在新标签页中打开}

内容与文案规范的可执行性依赖与设计、开发流程的绑定，例如把术语表接入设计工具的文案检查、在组件库中为按钮与表单预置标准措辞、在评审清单中加入文案项，否则规范容易停留在文档层面。^{2828Content style guidedesign-system.service.gov.uk前往参考资料 ↓在新标签页中打开}

内容规范与本地化（localization）紧密相关：面向多语言产品的文案规范通常要求避免依赖文化特定隐喻、控制字符串长度、为翻译预留扩展空间，并在术语表中给出多语言对照。^{3030Microsoft Writing Style Guidelearn.microsoft.com前往参考资料 ↓在新标签页中打开}

设计规范中的审计与盘点，指对现有设计规范文档、组件库、设计令牌及其在产品中的实际使用情况进行系统性清点与合规检查，以识别规范漂移、冗余条目和未覆盖场景。^{11Design Systems: A Practical Guide to Creating Design Languages for Digital Productssmashingmagazine.com前往参考资料 ↓在新标签页中打开}

设计系统审计通常分为两类：一类是界面清单审计，逐页清点实际使用的组件、样式与模式；另一类是规范文档审计，核对文档条目与代码实现是否一致。^{3131Design System Audit: How to Audit Your Design Systemuxdesign.cc前往参考资料 ↓在新标签页中打开}

审计结果通常以规范覆盖率、组件复用率和偏离项清单三项指标呈现，作为后续规范修订的输入。^{3131Design System Audit: How to Audit Your Design Systemuxdesign.cc前往参考资料 ↓在新标签页中打开}

审计与盘点应设定固定周期，常见做法是随产品大版本或设计系统版本发布同步执行，而非一次性活动。^{11Design Systems: A Practical Guide to Creating Design Languages for Digital Productssmashingmagazine.com前往参考资料 ↓在新标签页中打开}

审计发现的偏离项需要分级处理：影响一致性与可访问性的偏离优先修复，纯视觉微差可纳入后续迭代。^{3131Design System Audit: How to Audit Your Design Systemuxdesign.cc前往参考资料 ↓在新标签页中打开}

盘点还应覆盖规范文档本身的生命周期状态，标记已废弃、待评审和草案中的条目，避免过时规范继续被引用。^{11Design Systems: A Practical Guide to Creating Design Languages for Digital Productssmashingmagazine.com前往参考资料 ↓在新标签页中打开}

在规范起草阶段，ISO/IEC 指令（ISO/IEC Directives, Part 2）要求标准文本必须遵循规定的结构（如前言、范围、规范性引用文件、术语和定义、要求等章节顺序）和起草规则，以确保不同起草委员会产出的标准在形式上一致、可被机器和人工共同处理。^{3232ISO/IEC Directives, Part 2: Principles and rules for the structure and drafting of ISO and IEC documentsiso.org前往参考资料 ↓在新标签页中打开}

ISO/IEC 指令第 2 部分对“要求（requirement）”“推荐（recommendation）”“允许（permission）”“能力（capability）”和“可能性（possibility）”等助动词的用法作出严格区分，起草者必须按规范选用 shall/should/may/can 等词，以避免规范文本产生歧义。^{3232ISO/IEC Directives, Part 2: Principles and rules for the structure and drafting of ISO and IEC documentsiso.org前往参考资料 ↓在新标签页中打开}

W3C 的规范制定流程（W3C Process Document）把规范起草与评审划分为工作草案（Working Draft）、候选推荐标准（Candidate Recommendation）、提案推荐标准（Proposed Recommendation）和 W3C 推荐标准（W3C Recommendation）等成熟度阶段，每个阶段都设有公开评审期和反对意见处理机制。^{3333W3C Process Documentw3.org前往参考资料 ↓在新标签页中打开}

W3C 流程要求规范在进入候选推荐标准阶段前必须解决所有已提出的正式反对意见（Formal Objection），并记录处理结果；正式反对意见由 W3C 主任或其指定代表裁决，裁决过程与理由对公众可见。^{3333W3C Process Documentw3.org前往参考资料 ↓在新标签页中打开}

IETF 的规范起草以互联网草案（Internet-Draft）为起点，任何个人均可提交；草案需经过工作组讨论、工作组最后呼叫（Working Group Last Call）、IESG 评审和 IETF 最后呼叫（IETF Last Call）等评审环节，才能进入 RFC 发布流程。^{3434The IETF Process: an Informal Guideietf.org前往参考资料 ↓在新标签页中打开}

IETF 的 RFC 2026（《互联网标准进程》第三版）规定，标准轨道规范在成为互联网标准（Internet Standard）之前须经历拟议标准（Proposed Standard）和草案标准（Draft Standard）两个成熟度等级，并须证明存在多个独立、可互操作的实现。^{3535RFC 2026: The Internet Standards Process -- Revision 3rfc-editor.org前往参考资料 ↓在新标签页中打开}

在软件与产品设计规范领域，设计评审（design review）被定义为在规范或设计定稿前，由跨职能评审者对文档进行系统性检查的正式活动，其目的包括发现缺陷、确认需求覆盖和降低后期返工成本；IEEE 1028-2008 将评审划分为管理评审、技术评审、审查（inspection）、走查（walk-through）和审计等类型。^{3636IEEE 1028-2008: IEEE Standard for Software Reviews and Auditsstandards.ieee.org前往参考资料 ↓在新标签页中打开}

IEEE 1028-2008 对审查（inspection）规定了角色分工（如主持人、作者、评审员、记录员）和过程步骤（策划、预备会、个人准备、审查会议、返工、跟踪），并强调审查应由受过培训的评审者按既定流程执行，而非临时召集的会议。^{3636IEEE 1028-2008: IEEE Standard for Software Reviews and Auditsstandards.ieee.org前往参考资料 ↓在新标签页中打开}

在汽车功能安全领域，ISO 26262 要求安全计划中明确安全活动的工作产物（work product）及其评审与确认活动，规范类文档（如安全需求规范、技术安全概念）须经过验证评审并保留评审记录，作为功能安全审计的证据。^{3737ISO 26262-2:2018 Road vehicles — Functional safety — Part 2: Management of functional safetyiso.org前往参考资料 ↓在新标签页中打开}

开源规范项目常采用“公开文本 + 议题跟踪 + 拉取请求”的起草与评审模式：规范源文件以版本库形式公开，任何人均可提交修改建议，由维护者或编辑团队评审合并，评审讨论与变更历史全程留痕。^{1515Web Content Accessibility Guidelines (WCAG) 2.2w3.org前往参考资料 ↓在新标签页中打开}

在规范起草中，将规范性内容（normative）与资料性内容（informative）明确分离是通行做法：规范性条款构成符合性判定的依据，资料性内容（如示例、背景说明）不构成要求，二者在文本中须以不同章节或标注方式区分。^{3232ISO/IEC Directives, Part 2: Principles and rules for the structure and drafting of ISO and IEC documentsiso.org前往参考资料 ↓在新标签页中打开}

规范评审的有效性受评审规模影响：多项软件工程实证研究表明，审查会议规模过大或准备时间不足会降低缺陷发现率，因此实践中常建议控制单次评审的文档篇幅与评审人数。^{3636IEEE 1028-2008: IEEE Standard for Software Reviews and Auditsstandards.ieee.org前往参考资料 ↓在新标签页中打开}

设计规范作为一份持续演进的文档资产，其版本管理需要为每次发布建立唯一且可追溯的版本标识，通常采用语义化版本号（主版本.次版本.修订号）区分破坏性变更、向后兼容的新增与纯修正，使设计、研发与测试各方能准确对齐所依据的规范版本。^{2525Semantic Versioning 2.0.0semver.org前往参考资料 ↓在新标签页中打开}

语义化版本规范（Semantic Versioning 2.0.0）规定：主版本号在出现不兼容的 API 变更时递增，次版本号在向后兼容地新增功能时递增，修订号在向后兼容的问题修正时递增，并允许以预发布标识和构建元数据作为扩展，这为设计规范这类对外承诺接口稳定性的文档提供了通用的版本号约定。^{2525Semantic Versioning 2.0.0semver.org前往参考资料 ↓在新标签页中打开}

设计规范的维护应建立变更日志（changelog），按版本记录新增、变更、废弃与移除的条目，并注明生效日期与影响范围，使下游使用方能够评估升级成本；业界通行的做法是将变更日志与版本号一同纳入代码仓库或文档站点，随发布流程自动生成或人工核对。^{3838Keep a Changelogkeepachangelog.com前往参考资料 ↓在新标签页中打开}

将设计规范以代码仓库中的文本文件（如 Markdown、JSON、YAML 令牌文件）形式管理，可以复用软件工程已有的分支、合并请求、代码评审与标签发布机制，使规范的每次修改都留下作者、时间、评审意见与差异记录，从而把版本管理从人工台账转为可审计的工程流程。^{11Design Systems: A Practical Guide to Creating Design Languages for Digital Productssmashingmagazine.com前往参考资料 ↓在新标签页中打开}

设计令牌（design tokens）作为设计决策的机器可读载体，其版本化是设计规范版本管理的关键环节：令牌文件一旦变更，需要同步更新消费该令牌的组件库与多端产物，因此实践中常将令牌包作为独立版本化的制品发布，并在组件库中锁定所依赖的令牌版本区间。^{1616Design Tokens Format Moduletr.designtokens.org前往参考资料 ↓在新标签页中打开}

设计规范的废弃（deprecation）流程需要给出明确的过渡期与替代方案：在规范中标注某条规则或某个组件已废弃、说明替代项、约定移除的目标版本，并在过渡期内保持旧规则可用，避免使用方在无预警的情况下被迫返工。^{3838Keep a Changelogkeepachangelog.com前往参考资料 ↓在新标签页中打开|11Design Systems: A Practical Guide to Creating Design Languages for Digital Productssmashingmagazine.com前往参考资料 ↓在新标签页中打开}

设计规范的维护需要明确的责任人与评审机制，通常由设计系统团队担任规范的所有者（owner），对变更提案进行评审并决定是否纳入、何时发布，同时通过公开的提案渠道收集使用方需求，使规范演进有据可依而非由个别项目临时改动。^{11Design Systems: A Practical Guide to Creating Design Languages for Digital Productssmashingmagazine.com前往参考资料 ↓在新标签页中打开}

设计规范与实现代码之间的一致性维护是版本管理的难点：规范文档更新而组件库未同步、或组件库先行而文档滞后，都会造成版本漂移；常见对策是把文档中的示例与组件库的真实实现绑定（如从同一份源码生成示例），并在发布流程中加入文档与实现的一致性检查。^{11Design Systems: A Practical Guide to Creating Design Languages for Digital Productssmashingmagazine.com前往参考资料 ↓在新标签页中打开|1616Design Tokens Format Moduletr.designtokens.org前往参考资料 ↓在新标签页中打开}

面向多产品线的设计规范在版本管理上需要区分“规范版本”与“产品采用版本”：规范可以持续发布新版本，而各产品线按自身排期逐步升级，因此规范需要提供版本兼容说明与迁移指南，帮助产品线评估从旧版本升级到新版本所需的工作量。^{3838Keep a Changelogkeepachangelog.com前往参考资料 ↓在新标签页中打开}

设计规范的版本归档与历史可查是维护工作的基本要求：已发布版本的规范应长期保留并可访问，以便追溯历史设计决策、排查旧版本产品的问题，以及在合规审计中说明当时的规范依据。^{3838Keep a Changelogkeepachangelog.com前往参考资料 ↓在新标签页中打开|11Design Systems: A Practical Guide to Creating Design Languages for Digital Productssmashingmagazine.com前往参考资料 ↓在新标签页中打开}

Material Design 是谷歌提出的一套集合视觉、交互与前端实现的界面设计规范，其目标之一是以视觉形式囊括经典设计原则并展现前沿创新与技术，目标之二是以移动端为基础，把不同尺寸、类型的设备统一起来。^{3939谷歌官方Material Design设计规范使用指南pixso.cn前往参考资料 ↓在新标签页中打开}

Material Design 最初与 Android 平台紧密绑定，是移动端开发主流中除 iOS 之外的第二套设计规范；其要义后来被大量设计师借鉴到 Android 之外的项目中，成为 UX、UI 设计师常被要求学习的设计规范之一。^{3939谷歌官方Material Design设计规范使用指南pixso.cn前往参考资料 ↓在新标签页中打开}

Material Design 规范已被第三方设计工具内置：Pixso 将其作为内置设计规范上线，并同步发布到其资源社区，用户可在设计界面的资源入口直接调用。^{3939谷歌官方Material Design设计规范使用指南pixso.cn前往参考资料 ↓在新标签页中打开}

Apple 的人机界面指南（Human Interface Guidelines，简称 HIG）是 Apple 面向其各平台开发者发布的官方界面设计规范文档，其历史可追溯至 1978 年，是现存持续维护时间最长的平台设计规范之一。^{4040基本的设计原则 - WWDC17 - 视频 - Apple Developerdeveloper.apple.com前往参考资料 ↓在新标签页中打开}

在 Apple 的表述中，HIG 的定位不是让应用「做得漂亮或工整」，而是让界面设计根本上服务于人；Apple 设计推广团队明确把「人机界面」而非「用户界面」作为其文档的正式名称，强调设计对象是具备人性的人而非抽象的「用户」。^{4040基本的设计原则 - WWDC17 - 视频 - Apple Developerdeveloper.apple.com前往参考资料 ↓在新标签页中打开}

Apple 将设计原则归纳为满足人类对安全、意义、成就与美的需求，并认为这些原则能帮助设计出更受欢迎、易于理解、充满力量且令人满意的用户体验；这一原则体系在 WWDC 2017 的「基本的设计原则」演讲中被系统阐述。^{4040基本的设计原则 - WWDC17 - 视频 - Apple Developerdeveloper.apple.com前往参考资料 ↓在新标签页中打开}

HIG 对反馈（feedback）作了类型化区分：状态反馈告知系统当前状态，完成反馈告知操作成功或失败，警告反馈提示潜在问题，错误反馈提示某操作已造成错误；Apple 以汽车仪表为例说明关键状态信息（如挡位）需要在多个位置重复呈现。^{4040基本的设计原则 - WWDC17 - 视频 - Apple Developerdeveloper.apple.com前往参考资料 ↓在新标签页中打开}

Apple 在 2017 年前后对 macOS 的 HIG 进行了重新设计改版，并配合 WWDC 演讲、演示幻灯片与 Apple 设计大奖等形式对外推广其设计规范，形成「文档＋演讲＋奖项」的规范传播组合。^{4040基本的设计原则 - WWDC17 - 视频 - Apple Developerdeveloper.apple.com前往参考资料 ↓在新标签页中打开}

HIG 的规范内容以跨平台一致性为目标，同一套人机界面原则被同时应用于 macOS、iOS 等不同设备形态，Apple 在演讲中以车载场景的反馈设计作为跨场景适用性的例证。^{4040基本的设计原则 - WWDC17 - 视频 - Apple Developerdeveloper.apple.com前往参考资料 ↓在新标签页中打开}

Ant Design 是由蚂蚁集团（Ant Group）体验技术部开发并开源的一套企业级 UI 设计语言与 React 组件库，其官方定位是「服务于企业级产品的设计体系」，包含设计价值观、设计原则、组件规范和配套的 React 实现。^{4141Ant Design 设计语言官方文档ant.design前往参考资料 ↓在新标签页中打开|4242ant-design/ant-design: An enterprise-class UI design language and React UI librarygithub.com前往参考资料 ↓在新标签页中打开}

Ant Design 的设计价值观被概括为「自然、确定性、意义感、生长性」四条，其中「确定性」强调通过一致的交互与视觉规则降低企业级产品的认知与协作成本，是其在 B 端场景中被广泛采用的核心主张。^{4141Ant Design 设计语言官方文档ant.design前往参考资料 ↓在新标签页中打开}

Ant Design 的组件规范以「组件—模式—模板」的分层方式组织：基础组件（如 Button、Input、Table）定义单一交互单元，模式（Pattern）描述多个组件组合解决特定业务问题的方式，模板（Template）则给出完整页面的布局与信息层级范例。^{4141Ant Design 设计语言官方文档ant.design前往参考资料 ↓在新标签页中打开|4242ant-design/ant-design: An enterprise-class UI design language and React UI librarygithub.com前往参考资料 ↓在新标签页中打开}

Ant Design 的 React 实现以 npm 包 `antd` 发布，采用 TypeScript 编写并提供类型定义，支持按需加载与主题定制（通过 ConfigProvider 与 Design Token 机制），截至 2020 年代中期其 GitHub 仓库 star 数超过 9 万，是企业级 React 组件库中采用度最高的项目之一。^{4242ant-design/ant-design: An enterprise-class UI design language and React UI librarygithub.com前往参考资料 ↓在新标签页中打开}

Ant Design 在 5.0 版本中引入 Design Token（设计令牌）体系，将颜色、字体、圆角、阴影等视觉变量抽象为可计算、可继承的令牌层级（Seed Token → Map Token → Alias Token），使主题定制从覆盖 CSS 类名转为修改令牌，这一机制被视为设计规范与代码实现之间「单一事实来源」的工程化尝试。^{4141Ant Design 设计语言官方文档ant.design前往参考资料 ↓在新标签页中打开}

Ant Design 的规范文档同时面向设计师与开发者：设计侧提供 Axure/Sketch/Figma 资源与设计原则说明，开发侧提供组件 API、交互行为与可访问性说明，这种「设计—代码」双轨文档结构是其在跨职能团队中落地的重要条件。^{4141Ant Design 设计语言官方文档ant.design前往参考资料 ↓在新标签页中打开|4242ant-design/ant-design: An enterprise-class UI design language and React UI librarygithub.com前往参考资料 ↓在新标签页中打开}

Ant Design 采用 MIT 许可证开源，允许商业项目自由使用、修改与分发，这降低了企业将其作为内部设计规范基线的法律与采购门槛。^{4242ant-design/ant-design: An enterprise-class UI design language and React UI librarygithub.com前往参考资料 ↓在新标签页中打开}

Ant Design 的规范并非静态文档，而是随组件库版本迭代同步更新，其设计原则与组件行为在 GitHub 上以 issue 与 RFC 形式公开讨论，形成「规范—实现—反馈」的闭环维护机制。^{4242ant-design/ant-design: An enterprise-class UI design language and React UI librarygithub.com前往参考资料 ↓在新标签页中打开}

有批评意见指出，Ant Design 的默认视觉风格（如蓝色主色、紧凑的信息密度）在面向消费者的 C 端产品中辨识度不足，直接套用容易导致产品外观同质化；这一观点主要来自设计社区的经验讨论，而非系统性研究。^{4343Why does every website look like Ant Design?news.ycombinator.com前往参考资料 ↓在新标签页中打开}

Fluent Design System 是微软为 Windows 及其跨平台产品线建立的设计语言与设计规范体系，其第二代版本以「Fluent 2」名义发布，并以公开网站形式提供完整的设计指南、组件与设计令牌文档。^{4444Fluent 2 Design Systemfluent2.microsoft.design前往参考资料 ↓在新标签页中打开}

Fluent 2 的图标规范把图标定义为在布局中承载语义作用的元素，要求图标始终可识别、功能明确且易于理解，并将图标划分为系统图标、产品发布图标与文件图标三个集合，分别给出应用场景、用法与授权说明。^{4444Fluent 2 Design Systemfluent2.microsoft.design前往参考资料 ↓在新标签页中打开}

Fluent 的系统图标以 MIT 许可证开源，并通过 GitHub 上的 fluentui-system-icons 仓库与 Figma 社区文件对外分发，使第三方产品可以直接复用同一套图标资产。^{4444Fluent 2 Design Systemfluent2.microsoft.design前往参考资料 ↓在新标签页中打开}

Fluent 采用基于设计令牌（token）的规范结构：控件在运行时读取语义化的颜色角色、圆角与字体令牌，而不是硬编码具体色值，主题切换与用户覆盖都通过替换令牌取值实现。^{4545fluent.mdgithub.com前往参考资料 ↓在新标签页中打开|4646Fluent (Windows): design referenceraw.githubusercontent.com前往参考资料 ↓在新标签页中打开}

在 Fluent 的令牌体系中，颜色以语义角色而非原始色值命名，例如强调色默认值、控件强描边、主文本等角色分别映射到不同的令牌字段，浅色与深色主题各自维护一套角色取值表。^{4545fluent.mdgithub.com前往参考资料 ↓在新标签页中打开|4646Fluent (Windows): design referenceraw.githubusercontent.com前往参考资料 ↓在新标签页中打开}

Fluent 规范对高对比度模式的处理依赖应用显式选择或通过配置文件提供对比度覆盖，而非自动读取操作系统的无障碍对比度偏好，这一取舍在跨平台实现中会带来适配负担。^{4646Fluent (Windows): design referenceraw.githubusercontent.com前往参考资料 ↓在新标签页中打开}

多屏协同规范是智能座舱设计规范的一个子类，用于约束仪表屏、中控屏、副驾屏、HUD 等多块显示设备之间的信息分配、交互流转与视觉一致性，其核心目标是避免驾驶员因跨屏信息切换而分心。^{4747智能座舱多屏交互设计指南（T/CAAMTB 118-2023）caam.org.cn前往参考资料 ↓在新标签页中打开}

中国汽车工业协会 2023 年发布的《智能座舱多屏交互设计指南》（T/CAAMTB 118-2023）将多屏协同划分为「信息分层」「任务流转」「视觉统一」三个规范维度，并建议仪表屏只承载安全关键信息、中控屏承载主要交互、副驾屏承载娱乐内容。^{4747智能座舱多屏交互设计指南（T/CAAMTB 118-2023）caam.org.cn前往参考资料 ↓在新标签页中打开}

ISO 15008:2017 对车载视觉显示的信息呈现提出了可读性与注意力分配要求，虽未专门针对多屏协同，但被业界普遍作为多屏信息优先级划分的底层依据。^{4848ISO 15008:2017 Road vehicles — Ergonomic aspects of transport information and control systems — Specifications and test procedures for in-vehicle visual presentationiso.org前往参考资料 ↓在新标签页中打开}

在工程落地层面，多屏协同规范通常以设计令牌（design token）与组件库的形式固化，要求同一信息在不同屏幕上的字号、色彩、间距遵循统一的设计令牌体系，以保证视觉一致性并降低适配成本。^{1111Design Tokensw3.org前往参考资料 ↓在新标签页中打开}

部分主机厂在多屏协同规范中引入「主驾优先」原则，规定当多屏内容冲突时，仪表与 HUD 的信息优先级高于中控与副驾屏，副驾屏内容不得在行驶中向主驾屏迁移。^{4747智能座舱多屏交互设计指南（T/CAAMTB 118-2023）caam.org.cn前往参考资料 ↓在新标签页中打开}

随着座舱域控制器与多屏 SoC 的普及，多屏协同规范还需覆盖跨屏渲染的时延与帧同步要求，以避免拖拽、流转类交互出现视觉撕裂或响应迟滞。^{1111Design Tokensw3.org前往参考资料 ↓在新标签页中打开}

智能座舱的多模态交互规范需要同时约束语音、触控、手势、视线、物理按键等多种输入通道，并规定各通道之间的融合与仲裁规则，而非只针对单一交互方式分别立规。团体标准 T/CI 1600-2026《智能座舱人机交互系统多模态融合技术规范》即以「多模态融合」为规范对象，由宁波普瑞均胜、中国一汽、北京理想汽车、北京理工大学等整车、零部件与高校单位共同参与起草。^{4949T/CI 1600-2026 智能座舱人机交互系统多模态融合技术规范-中国标准在线服务网spc.org.cn前往参考资料 ↓在新标签页中打开}

多模态交互规范在座舱中的落地通常以「融合」为核心：规范需要定义同一意图被多个通道同时表达时的优先级与冲突消解方式，例如语音指令与触控操作指向不同目标时以哪一路为准，从而避免不同供应商的模块各自为政导致体验割裂。T/CI 1600-2026 将多模态融合作为标准名称与适用范围的核心限定词，反映出行业把融合规则视为座舱交互规范的关键内容。^{4949T/CI 1600-2026 智能座舱人机交互系统多模态融合技术规范-中国标准在线服务网spc.org.cn前往参考资料 ↓在新标签页中打开}

智能座舱多模态交互规范的制定主体呈现「团体标准先行」的特征：T/CI 1600-2026 属于团体标准（T/CI 编号），由企业、高校等产业主体联合提出，而非由国家强制性标准统一规定。这类标准通常用于在国标、行标尚未覆盖多模态融合细节时，为供应链协作提供可参照的技术约定。^{4949T/CI 1600-2026 智能座舱人机交互系统多模态融合技术规范-中国标准在线服务网spc.org.cn前往参考资料 ↓在新标签页中打开}

多模态交互规范在座舱中的应用还涉及对参与起草单位所代表的不同角色的协调：整车企业（如中国一汽、北京理想汽车）、零部件与电子供应商（如宁波普瑞均胜、重庆君歌电子）、声学与显示技术公司以及高校研究机构同时参与，意味着规范需要兼顾系统集成方与部件供应方在接口、时延、融合策略上的可执行性。^{4949T/CI 1600-2026 智能座舱人机交互系统多模态融合技术规范-中国标准在线服务网spc.org.cn前往参考资料 ↓在新标签页中打开}

智能座舱的驾驶状态适配，指设计规范依据车辆行驶状态（驻车、低速、高速、自动驾驶激活等）动态约束信息呈现量与交互通道：行驶中限制长文本阅读与复杂菜单层级，驻车时放开视频与深度设置，从而在满足安全冗余的前提下保留功能完整性。^{5050ISO 15008:2017 Road vehicles — Ergonomic aspects of transport information and control systems — Specifications and test procedures for in-vehicle visual presentationiso.org前往参考资料 ↓在新标签页中打开}

国际标准化组织发布的 ISO 15008 针对车载视觉显示的信息呈现给出了可读性与视觉负荷方面的建议，被业界作为行驶中信息显示密度与字号、对比度等参数设计的参考依据之一。^{5050ISO 15008:2017 Road vehicles — Ergonomic aspects of transport information and control systems — Specifications and test procedures for in-vehicle visual presentationiso.org前往参考资料 ↓在新标签页中打开}

美国国家公路交通安全管理局（NHTSA）发布的驾驶员分心指南提出，单次视线离开前方道路的操作时长应控制在约 2 秒以内，并据此对车载电子设备的手动操作序列长度提出限制，这一量化口径被广泛引入座舱交互设计规范。^{5151Visual-Manual NHTSA Driver Distraction Guidelines for In-Vehicle Electronic Devicesfederalregister.gov前往参考资料 ↓在新标签页中打开}

中国已发布推荐性国家标准 GB/T 26773《智能运输系统 车道偏离报警系统 性能要求与检测方法》等车载预警类标准，以及针对车载信息显示的相关规范，为国内座舱在行驶状态下的信息呈现提供了本土化依据。^{5252GB/T 26773-2011 智能运输系统 车道偏离报警系统 性能要求与检测方法openstd.samr.gov.cn前往参考资料 ↓在新标签页中打开}

在驾驶状态适配的落地方式上，主流做法是按车速与挡位划分状态机：车速为零且处于 P 挡时进入驻车态，允许视频播放与多层级设置；车速超过阈值后自动收起视频与键盘输入，切换为语音与方向盘按键为主的交互通道。^{5050ISO 15008:2017 Road vehicles — Ergonomic aspects of transport information and control systems — Specifications and test procedures for in-vehicle visual presentationiso.org前往参考资料 ↓在新标签页中打开|5353Automotive UI design: adapting the in-vehicle experience to driving contextdl.acm.org前往参考资料 ↓在新标签页中打开}

驾驶状态适配与自动驾驶等级强相关：在 L2 及以下辅助驾驶激活时，规范通常仍要求驾驶员保持对道路的持续监控，因此信息呈现限制不因辅助驾驶开启而放宽；只有在更高自动化等级下才讨论放开非驾驶相关内容的边界。^{88Automotive HMI Design Guidelinessae.org前往参考资料 ↓在新标签页中打开}

部分车企与研究者主张，随着高阶辅助驾驶普及，座舱应在系统确认驾驶员脱手且处于监管状态时适度放开娱乐内容，以提升长途出行体验；另一部分安全研究者则认为在驾驶员仍承担接管义务的阶段放开内容会显著提高分心风险，双方对放开边界存在公开分歧。^{88Automotive HMI Design Guidelinessae.org前往参考资料 ↓在新标签页中打开|5454Driver distraction and takeover performance in conditional automation: a reviewsciencedirect.com前往参考资料 ↓在新标签页中打开}

驾驶状态适配的规范落地依赖状态检测的可靠性，包括挡位信号、车速信号与驾驶员监控系统（DMS）的融合判断；若状态识别失效，可能出现行驶中误放开视频播放等风险，因此规范通常要求对关键状态信号设置冗余校验与失效降级策略。^{5353Automotive UI design: adapting the in-vehicle experience to driving contextdl.acm.org前往参考资料 ↓在新标签页中打开|5555Euro NCAP Assisted Driving Gradingeuroncap.com前往参考资料 ↓在新标签页中打开}

在具体参数上，常见规范将车速阈值设在约 5 至 15 公里/小时区间用于切换驻车态与行驶态，并对行驶态下的文本行数、菜单层级深度与单屏信息条目数给出上限，具体数值因厂商与车型而异，尚无统一强制口径。^{5050ISO 15008:2017 Road vehicles — Ergonomic aspects of transport information and control systems — Specifications and test procedures for in-vehicle visual presentationiso.org前往参考资料 ↓在新标签页中打开|5353Automotive UI design: adapting the in-vehicle experience to driving contextdl.acm.org前往参考资料 ↓在新标签页中打开}

Figma 的插件运行在浏览器沙箱化的 JavaScript 环境中，通过官方提供的 Plugin API 读取和修改文档节点、样式与组件，插件可发布到 Figma Community 供他人安装，也可仅在团队内部私有分发。^{5656Figma Plugin API Documentationfigma.com前往参考资料 ↓在新标签页中打开}

Figma 插件清单文件 manifest.json 必须声明编辑器类型（如 figma、figjam、dev 等）、入口脚本与权限（如 currentuser、activeusers、fileusers 等），权限声明决定了插件能访问的文档与用户数据范围，是设计规范类插件做合规审查时的基础约束。^{5656Figma Plugin API Documentationfigma.com前往参考资料 ↓在新标签页中打开}

Sketch 自 2016 年起提供官方 JavaScript API 与插件体系，插件以 .sketchplugin 包形式分发，可调用 Sketch 文档模型、图层与共享样式；这使得针对 Sketch 的设计规范检查（如命名、样式引用、符号使用）可以脚本化。^{5757Sketch Developer — Pluginsdeveloper.sketch.com前往参考资料 ↓在新标签页中打开}

Adobe XD 提供 Plugin API 与插件管理器，插件使用 JavaScript 编写并通过 manifest 声明命令与面板；随着 Adobe 于 2023 年宣布 XD 进入维护模式并停止新功能开发，围绕 XD 的设计规范插件生态的长期维护前景存在不确定性。^{5858Adobe XD Plugin APIsdeveloper.adobe.com前往参考资料 ↓在新标签页中打开}

Penpot 是开源的设计与原型工具，其插件系统基于 JavaScript 并在浏览器中运行，插件可通过官方插件 API 访问文件、页面与对象；开源属性使团队可以把设计规范校验插件与内部 CI 流程结合，而不依赖闭源插件市场。^{5959Penpot Plugin Systemhelp.penpot.app前往参考资料 ↓在新标签页中打开}

设计令牌（design tokens）以平台无关的 JSON 等格式描述颜色、字体、间距等基础样式变量，Style Dictionary 等工具可将同一份令牌源编译为 CSS、iOS、Android 等多端产物，插件与构建脚本因此可以把设计规范中的令牌同步到代码侧。^{6060Style Dictionarystyledictionary.com前往参考资料 ↓在新标签页中打开}

在 Figma 生态中，Tokens Studio（原 Figma Tokens）等插件把设计令牌直接管理在文档内，并支持导出为 JSON、CSS 变量等格式，使设计规范中的变量层与开发侧令牌文件保持同源。^{6161Tokens Studio for Figmatokens.studio前往参考资料 ↓在新标签页中打开}

Storybook 的 Figma 插件（@storybook/addon-designs）允许在组件故事中嵌入 Figma 画板或原型链接，把设计规范中的组件示例与实现侧组件文档并列展示，减少规范文档与代码实现脱节。^{6262Storybook — Design integrationsstorybook.js.org前往参考资料 ↓在新标签页中打开}

设计规范落地通常需要把规范检查嵌入既有工作流：一类做法是在设计工具内以插件形式做实时校验（命名、样式引用、组件实例），另一类是在提交或构建阶段以脚本或 CI 任务做批量审计，两者互补而非替代。^{5656Figma Plugin API Documentationfigma.com前往参考资料 ↓在新标签页中打开|6060Style Dictionarystyledictionary.com前往参考资料 ↓在新标签页中打开}

插件化规范检查的常见局限包括：插件 API 覆盖范围受宿主工具限制、跨工具（Figma/Sketch/XD/Penpot）无法共用同一份插件代码、插件权限与数据访问需要安全审查，以及插件市场中的第三方插件存在维护中断风险。^{5656Figma Plugin API Documentationfigma.com前往参考资料 ↓在新标签页中打开|5757Sketch Developer — Pluginsdeveloper.sketch.com前往参考资料 ↓在新标签页中打开|5959Penpot Plugin Systemhelp.penpot.app前往参考资料 ↓在新标签页中打开}

代码组件库是将设计规范中的视觉样式、交互状态与布局规则以可复用代码形式固化的实现载体，使设计决策从文档描述转为可直接调用的程序接口，从而在工程层面保证规范被执行。^{11Design Systems: A Practical Guide to Creating Design Languages for Digital Productssmashingmagazine.com前往参考资料 ↓在新标签页中打开}

设计令牌（design tokens）是代码组件库与设计工具之间的中间层：颜色、字体、间距、圆角、动效时长等原子化取值以平台无关的键值对存储，再由构建工具分别输出为 CSS 变量、iOS/Android 资源或 JavaScript 常量，使同一套规范能跨端一致落地。^{6363Design Tokenslightningdesignsystem.com前往参考资料 ↓在新标签页中打开}

W3C 设计令牌社区组发布的 Design Tokens Format Module 草案定义了设计令牌的 JSON 交换格式，为不同设计工具与代码组件库之间交换令牌数据提供了标准化基础。^{1111Design Tokensw3.org前往参考资料 ↓在新标签页中打开}

Storybook 是组件库开发中广泛使用的隔离开发与文档环境，它把每个组件的各种状态作为独立“故事”渲染，并自动生成可交互的组件文档，使设计规范中的状态矩阵（默认、悬停、禁用、加载等）在代码层面可被逐一验证。^{6464Storybook: Frontend workshop for UI developmentstorybook.js.org前往参考资料 ↓在新标签页中打开}

组件库的版本管理与语义化版本（SemVer）约定是规范落地的治理手段：破坏性变更需升主版本号并在变更日志中标注，使依赖该库的产品团队能评估升级影响，避免规范更新在多产品线中失控。^{2525Semantic Versioning 2.0.0semver.org前往参考资料 ↓在新标签页中打开}

代码组件库与设计工具之间的双向同步长期依赖人工或半自动流程，Figma 的 Variables 与 Dev Mode 等能力使设计侧令牌与代码侧变量建立映射，但两端数据结构与命名约定的差异仍是落地中的主要摩擦点。^{6565Figma Variables and Dev Modehelp.figma.com前往参考资料 ↓在新标签页中打开}

在智能座舱场景中，代码组件库需同时覆盖车机 HMI 的触控、语音与物理按键等多种输入方式，并满足行车场景下的可读性与操作安全约束，因此组件库通常需要在通用设计系统之上叠加车载专用的尺寸、对比度与交互时序规则。^{88Automotive HMI Design Guidelinessae.org前往参考资料 ↓在新标签页中打开}

文档站点生成工具的核心机制是将以 Markdown 或 MDX 等纯文本格式撰写的规范内容，通过静态站点生成器（SSG）编译为可部署的 HTML/CSS/JS 静态资源，从而在不依赖后端数据库的情况下提供全文检索、版本切换与导航侧栏等阅读体验。^{6666Static site generatoren.wikipedia.org前往参考资料 ↓在新标签页中打开|6767Markdownen.wikipedia.org前往参考资料 ↓在新标签页中打开}

Docusaurus 由 Meta 开源，定位为「内容驱动型网站」的静态站点生成器，内置文档版本化（versioning）、国际化（i18n）、侧边栏自动生成与 Algolia 搜索集成，常被设计系统团队用于承载组件规范与使用指南。^{6868Docusaurus 官方文档docusaurus.io前往参考资料 ↓在新标签页中打开}

VitePress 是基于 Vite 与 Vue 的静态站点生成器，由 Vue 团队维护，其前身为 VuePress；它利用 Vite 的开发服务器实现近乎即时的热更新，并默认输出轻量静态页面，适合中小规模的设计规范文档站。^{6969VitePress 官方文档vitepress.dev前往参考资料 ↓在新标签页中打开}

Storybook 虽以组件隔离开发与调试为核心，但其 Docs 功能（基于 MDX 与自动生成的 ArgsTable）可以把组件的属性表、示例与设计说明合并为可发布的文档页面，因此常被设计系统团队当作「活文档」站点使用，与纯静态文档站形成互补。^{7070Storybook Docsstorybook.js.org前往参考资料 ↓在新标签页中打开}

在落地层面，文档站点通常与代码仓库同源管理：规范文本随组件代码一同提交，通过 CI 流水线在合并请求时构建预览、在主分支合并后自动部署到静态托管服务，从而保证文档与实现版本同步。^{6868Docusaurus 官方文档docusaurus.io前往参考资料 ↓在新标签页中打开|7171GitHub Actions documentationdocs.github.com前往参考资料 ↓在新标签页中打开}

文档站点的可检索性是落地效果的关键指标之一；Docusaurus 与 VitePress 均支持接入 Algolia DocSearch 或本地全文搜索插件，使设计规范的条款级内容可被直接定位，而非只能靠目录逐层浏览。^{6868Docusaurus 官方文档docusaurus.io前往参考资料 ↓在新标签页中打开|6969VitePress 官方文档vitepress.dev前往参考资料 ↓在新标签页中打开}

版本化能力对设计规范尤为重要：当组件库发布破坏性变更时，文档站需要保留旧版本规范的快照，Docusaurus 的 versioned docs 机制允许在同一站点内并存多个版本文档并通过下拉菜单切换。^{6868Docusaurus 官方文档docusaurus.io前往参考资料 ↓在新标签页中打开}

静态站点生成方案并非唯一选择；部分团队采用 Confluence、Notion 等协作平台或自建 CMS 承载设计规范，其优势在于非技术成员可直接编辑，代价是版本控制粒度与代码同源能力较弱。^{11Design Systems: A Practical Guide to Creating Design Languages for Digital Productssmashingmagazine.com前往参考资料 ↓在新标签页中打开}

设计规范通过统一组件、样式与交互模式，显著降低设计与开发之间的沟通成本，并减少重复劳动。^{11Design Systems: A Practical Guide to Creating Design Languages for Digital Productssmashingmagazine.com前往参考资料 ↓在新标签页中打开}

设计规范作为单一事实来源，有助于跨团队协作时保持设计决策的连贯性，避免因人员变动导致的设计漂移。^{66Design Systems Handbookdesignbetter.co前往参考资料 ↓在新标签页中打开}

在智能座舱等多屏、多设备场景中，设计规范能确保不同屏幕尺寸与交互方式下体验的一致性，降低用户认知负荷。^{7272Designing for Automotive HMI: Best Practices for Consistencysae.org前往参考资料 ↓在新标签页中打开}

设计规范的维护与更新需要持续投入，若缺乏治理机制，规范容易过时，反而可能阻碍创新。^{7373Design System Governance: Maintaining Consistency at Scaleuxdesign.cc前往参考资料 ↓在新标签页中打开}

设计规范一旦建立，其维护成本往往超过初始制定成本。设计系统需要持续投入人力进行组件更新、文档维护、版本管理和跨团队协调，这些长期开销在多数组织的设计系统实践中占据主要比重。^{7575Design Systems: A Practical Guide to Building and Maintaining Design Systemsoreilly.com前往参考资料 ↓在新标签页中打开}

设计规范的维护成本随系统规模呈非线性增长：组件数量、平台覆盖数（Web、iOS、Android、桌面端）和消费团队数量的增加，会带来组合爆炸式的兼容性测试与同步更新负担。^{7575Design Systems: A Practical Guide to Building and Maintaining Design Systemsoreilly.com前往参考资料 ↓在新标签页中打开}

设计规范维护中最容易被低估的成本是「治理成本」——即决定谁有权修改规范、如何处理例外请求、如何推动各产品团队采纳新版本所需的组织协调工作，这部分成本无法通过工具自动化消除。^{7575Design Systems: A Practical Guide to Building and Maintaining Design Systemsoreilly.com前往参考资料 ↓在新标签页中打开}

设计规范与代码实现之间的漂移（drift）是维护成本的持续来源：设计稿更新后若未同步到组件库，或组件库更新后未回写设计文档，就会产生设计与实现不一致，需要额外审计和修复工作。^{7575Design Systems: A Practical Guide to Building and Maintaining Design Systemsoreilly.com前往参考资料 ↓在新标签页中打开}

为控制维护成本，业界常见做法包括：建立单一事实来源（single source of truth）、将设计令牌（design tokens）作为设计与代码之间的共享层、以及采用语义化版本管理来降低升级破坏性。^{7575Design Systems: A Practical Guide to Building and Maintaining Design Systemsoreilly.com前往参考资料 ↓在新标签页中打开}

设计规范的维护成本还包括培训与推广成本：新成员入职、跨团队宣讲、文档可发现性建设等持续投入，若缺失会导致规范被绕过或误用，反过来推高后续修复成本。^{7575Design Systems: A Practical Guide to Building and Maintaining Design Systemsoreilly.com前往参考资料 ↓在新标签页中打开}

在智能座舱等嵌入式场景中，设计规范的维护成本还受硬件差异、车机系统版本碎片化和安全法规变更的影响，需要额外的适配与合规审查投入。^{7575Design Systems: A Practical Guide to Building and Maintaining Design Systemsoreilly.com前往参考资料 ↓在新标签页中打开}

设计规范在跨团队协作中的首要价值是充当「通用语言」：当设计、前端、后端、测试等角色各自按自己的习惯产出时，同一个交互元素（如返回按钮）会出现尺寸、颜色、样式不一致，同一个业务字段（如客户编号）会在多个接口里使用不同变量名，对接成本因此显著上升；统一的规范把这些约定固定下来，使不同角色对同一对象的描述可以互相对齐。^{7676被很多人低估的标准化设计规范，到底能创造多少价值 - 产学研m.jscxyp.cn前往参考资料 ↓在新标签页中打开}

缺乏规范约束的协作成本往往在项目后期集中爆发：前期为追求速度而放弃规范，通常会在数月后表现为改一处牵动全身、新功能难以叠加，最终不得不推倒重构，重构耗时可能超过从零开发。这说明规范投入的收益是延迟兑现的，跨团队协作中「先快后慢」的账需要在项目立项阶段就向各方说明。^{7676被很多人低估的标准化设计规范，到底能创造多少价值 - 产学研m.jscxyp.cn前往参考资料 ↓在新标签页中打开}

跨团队协作中更隐蔽的问题是「漂移」而非「冲突」：各职能团队各自维护一份自己的「真相」——前端写在组件文档工具里，iOS 团队写在 Swift 包中，无障碍专家写在协作文档里，设计师写在设计工具里。这些团队本身都没有错，但彼此的表述不可通约，系统会在无人察觉的情况下慢慢不再一致，且因为没有任何环节会大声报错，漂移比冲突更难诊断。^{7777A design system is a system of truth - zeroheightzeroheight.com前往参考资料 ↓在新标签页中打开}

设计规范要真正支撑跨团队协作，不能只记录「决定了什么」，还要记录「为什么这样决定」。缺少决策理由的规范在团队更替、引入 AI 辅助生成或多方评审时无法被正确复用，团队只能反复回到原点重新争论；把推理过程一并文档化，是让规范在协作中可被继承的关键。^{7777A design system is a system of truth - zeroheightzeroheight.com前往参考资料 ↓在新标签页中打开}

跨团队协作的主要挑战之一是规范的所有权与维护责任分散：设计规范横跨设计、工程、内容、无障碍等多个职能，任何单一团队都无法独立维护其全部内容，而一旦没有明确的责任归属与同步机制，规范就会退化为某一职能的内部文档，其他团队则继续沿用各自的本地约定。^{7777A design system is a system of truth - zeroheightzeroheight.com前往参考资料 ↓在新标签页中打开}

跨团队协作的另一挑战是规范落地形态的碎片化：同一套设计决策需要同时以设计组件库、代码组件库、平台原生实现、无障碍说明等多种形态存在，各形态的更新节奏不同步，就会出现「规范已改、实现未改」或「实现先行、规范滞后」的窗口期，协作方在此期间依据的其实不是同一份规范。^{7777A design system is a system of truth - zeroheightzeroheight.com前往参考资料 ↓在新标签页中打开}

在跨机构、跨组织的协作场景中，标准化设计规范的作用比单一团队内部更突出：不同机构的设计与研发人员没有共同的日常沟通渠道和组织惯例，规范成为唯一稳定的对齐依据，缺少它时协作方需要为每个细节单独协商，沟通开销随参与方数量快速上升。^{7676被很多人低估的标准化设计规范，到底能创造多少价值 - 产学研m.jscxyp.cn前往参考资料 ↓在新标签页中打开}

中国无障碍设计的基础性法律是《中华人民共和国无障碍环境建设法》，该法于2023年6月28日由第十四届全国人民代表大会常务委员会第三次会议通过，自2023年9月1日起施行，是我国无障碍环境建设领域首部专门性法律。^{7878全球法规网-中国商务法规policy.mofcom.gov.cn前往参考资料 ↓在新标签页中打开}

住房城乡建设部办公厅于2025年2月24日发布《关于进一步加强城市无障碍设施建设工作的通知》（建办城〔2025〕7号），明确要求深入贯彻落实无障碍环境建设法，提升城市无障碍设施建设水平，并统筹适老化设施建设，打造安全便捷、连续贯通、多元包容的无障碍和适老化环境。^{7878全球法规网-中国商务法规policy.mofcom.gov.cn前往参考资料 ↓在新标签页中打开}

该通知将无障碍设施建设与适老化设施建设统筹推进，反映出中国无障碍设计规范体系正从单一面向残障群体的无障碍，向覆盖老年人等多元群体的全龄友好设计扩展。^{7878全球法规网-中国商务法规policy.mofcom.gov.cn前往参考资料 ↓在新标签页中打开}

在国际层面，无障碍设计的核心标准是国际标准化组织发布的ISO 9241-171《人机交互 ergonomics 第171部分：软件无障碍指南》，该标准为软件界面与交互设计提供了面向残障用户的可访问性要求与建议。^{7979ISO 9241-171:2008 Ergonomics of human-system interaction — Part 171: Guidance on software accessibilityiso.org前往参考资料 ↓在新标签页中打开}

万维网联盟（W3C）发布的《Web内容无障碍指南》（WCAG）是数字产品无障碍设计领域被引用最广的技术标准，其2.1版于2018年成为W3C正式推荐标准，围绕可感知、可操作、可理解、健壮性四项原则组织成功准则。^{8080Web Content Accessibility Guidelines (WCAG) 2.1w3.org前往参考资料 ↓在新标签页中打开}

WCAG 2.1在WCAG 2.0基础上新增了移动端触控、低视力对比度、横向滚动与动画控制等成功准则，以回应移动设备与触屏交互普及后出现的新无障碍问题。^{8080Web Content Accessibility Guidelines (WCAG) 2.1w3.org前往参考资料 ↓在新标签页中打开}

美国《康复法案》第508条（Section 508）要求联邦机构采购、开发、维护和使用的电子与信息技术必须对残障人士可访问，其技术标准在2017年由美国无障碍委员会（Access Board）更新，并与WCAG 2.0 AA级对齐。^{8181Section 508 of the Rehabilitation Actaccess-board.gov前往参考资料 ↓在新标签页中打开}

欧盟于2016年通过《欧盟无障碍法案》（European Accessibility Act，指令(EU) 2016/2102针对公共部门网站，指令(EU) 2019/882针对产品与服务），要求包括自助终端、电子通信服务、电子商务在内的关键产品与服务满足统一的无障碍要求，成员国须在2025年6月28日前将其转化为国内法。^{8282European Accessibility Act (Directive (EU) 2019/882)eur-lex.europa.eu前往参考资料 ↓在新标签页中打开}

在智能座舱与车载交互领域，无障碍设计标准尚不完善，现有法规多聚焦于物理空间与网页内容，针对车内触控、语音与视觉交互的系统性无障碍要求仍处于探索阶段。^{7878全球法规网-中国商务法规policy.mofcom.gov.cn前往参考资料 ↓在新标签页中打开|8080Web Content Accessibility Guidelines (WCAG) 2.1w3.org前往参考资料 ↓在新标签页中打开}

在汽车领域，ISO 26262《道路车辆 功能安全》是设计规范必须对齐的强制性国际标准，它按 ASIL 等级（A 至 D）对安全相关电子电气系统的开发流程、验证与确认活动提出要求，设计规范中的安全需求、追溯矩阵与验证准则通常直接引用该标准的条款。^{3737ISO 26262-2:2018 Road vehicles — Functional safety — Part 2: Management of functional safetyiso.org前往参考资料 ↓在新标签页中打开}

ISO 26262 在 2018 年发布第二版，将适用范围从乘用车扩展到公共汽车、卡车、摩托车等所有量产道路车辆，并新增了对半导体、软件工具置信度等方面的指导，这直接影响了车载系统设计规范中关于组件级安全论证的写法。^{3737ISO 26262-2:2018 Road vehicles — Functional safety — Part 2: Management of functional safetyiso.org前往参考资料 ↓在新标签页中打开|8383ISO 26262:2018 second edition publishediso.org前往参考资料 ↓在新标签页中打开}

在智能座舱与车载信息娱乐系统的交互设计上，美国国家公路交通安全管理局（NHTSA）发布的《Human Factors Design Guidance for Driver-Vehicle Interfaces》给出了分心驾驶相关的界面设计准则，包括单次操作时长、视觉信息呈现密度与触控目标尺寸等建议，常被车企作为 HMI 设计规范的合规依据。^{8484Human Factors Design Guidance for Driver-Vehicle Interfacesnhtsa.gov前往参考资料 ↓在新标签页中打开}

联合国欧洲经济委员会（UNECE）的 R155 法规（关于网络安全与网络安全管理体系）与 R156 法规（关于软件更新与软件更新管理体系）自 2022 年起对在欧盟等市场新认证的车辆生效，要求整车厂建立覆盖设计、开发、生产与后市场的网络安全管理体系，因此车载系统的设计规范需纳入威胁分析与风险评估（TARA）的输出。^{8585UN Regulation No. 155 — Cyber security and cyber security management systemunece.org前往参考资料 ↓在新标签页中打开|8686UN Regulation No. 156 — Software update and software update management systemunece.org前往参考资料 ↓在新标签页中打开}

ISO/SAE 21434《道路车辆 网络安全工程》为车辆网络安全工程提供了全生命周期的流程框架，与 UNECE R155 的合规要求相互衔接，设计规范中的网络安全需求、接口防护与漏洞管理条目通常参照该标准组织。^{8787ISO/SAE 21434:2021 Road vehicles — Cybersecurity engineeringiso.org前往参考资料 ↓在新标签页中打开}

在移动应用与网页设计领域，W3C 发布的《Web Content Accessibility Guidelines (WCAG) 2.2》是国际通行的无障碍设计规范，其四项原则（可感知、可操作、可理解、健壮）与分级符合性（A/AA/AAA）被广泛写入产品设计规范与验收标准。^{1515Web Content Accessibility Guidelines (WCAG) 2.2w3.org前往参考资料 ↓在新标签页中打开}

在医疗设备软件领域，IEC 62304《医疗器械软件 软件生命周期过程》规定了软件开发、维护与风险管理的过程要求，医疗器械的软件设计规范需与其安全分级（A/B/C）对应，并保留可追溯的设计历史文档。^{8888IEC 62304:2006 Medical device software — Software life cycle processeswebstore.iec.ch前往参考资料 ↓在新标签页中打开}

在航空领域，RTCA DO-178C《机载系统和设备合格审定中的软件考虑》是机载软件设计规范必须遵循的适航标准，它按软件等级（A 至 E）规定目标与活动，设计规范中的需求追溯、验证独立性与配置管理要求均源自该文件。^{8989DO-178C Software Considerations in Airborne Systems and Equipment Certificationrtca.org前往参考资料 ↓在新标签页中打开}

在工业自动化领域，IEC 61508《电气/电子/可编程电子安全相关系统的功能安全》是功能安全的基础标准，其安全完整性等级（SIL 1–4）方法被下游行业标准（如汽车 ISO 26262、过程工业 IEC 61511）引用，工业控制系统的设计规范通常以 SIL 定级作为安全相关设计的起点。^{9090IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systemsiec.ch前往参考资料 ↓在新标签页中打开}

在金融与支付行业，PCI DSS（支付卡行业数据安全标准）对涉及持卡人数据的系统设计提出要求，包括网络分段、加密传输、访问控制与日志留存等，支付类产品的设计规范需将 PCI DSS 的控制项映射到系统架构与接口设计中。^{9191PCI DSS v4.0pcisecuritystandards.org前往参考资料 ↓在新标签页中打开}

在隐私与数据保护方面，欧盟《通用数据保护条例》（GDPR）第 25 条确立「数据保护默认与设计」（Data Protection by Design and by Default）原则，要求在产品与系统设计阶段即嵌入数据最小化、假名化与访问控制等措施，这已成为涉及个人数据处理的产品设计规范的必要条款。^{9292Regulation (EU) 2016/679 (GDPR), Article 25 — Data protection by design and by defaulteur-lex.europa.eu前往参考资料 ↓在新标签页中打开}

在智能座舱的人机交互层面，ISO 15008 对车载视觉显示的信息呈现（如字符尺寸、对比度、颜色使用）给出规范，ISO 9241 系列则对交互系统的可用性与人因工程提出通用要求，二者常被引用于座舱显示与交互设计规范的编制。^{5050ISO 15008:2017 Road vehicles — Ergonomic aspects of transport information and control systems — Specifications and test procedures for in-vehicle visual presentationiso.org前往参考资料 ↓在新标签页中打开|9393ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开}

在软件工程与系统设计规范层面，IEEE 1016《软件设计描述》规定了软件设计说明（SDD）应包含的内容与组织方式，IEEE 830 则对软件需求规格说明提出推荐实践，这两份标准是设计文档规范化写作的经典依据。^{9494IEEE 1016-2009 Standard for Information Technology — Systems Design — Software Design Descriptionsstandards.ieee.org前往参考资料 ↓在新标签页中打开|9595IEEE 830-1998 Recommended Practice for Software Requirements Specificationsstandards.ieee.org前往参考资料 ↓在新标签页中打开}