Spacious 大留白设计规范

它解决什么问题

当团队需要一套「大留白」风格的 UI 规范时，最常见的痛点不是缺少配色或字号，而是缺少可执行的判断标准：间距到底留多大？状态变化怎么描述？无障碍怎么验收？这份技能把 Spacious 设计系统的 Foundations（排版、色板、间距）和 Component Rules 固化成一套结构化的规范生成流程，让工程师拿到的不是一句「要简洁」，而是一组可以直接进代码 review 的规则。

技能如何工作

• 先定义 Foundations：排版缩放 12/14/16/18/24/30/36，字体族 primary=Open Sans、display=Montserrat、mono=IBM Plex Mono，权重 100–900；色板给出 primary=#3B82F6、secondary=#8B5CF6、success=#16A34A、warning=#D97706、danger=#DC2626、surface=#FFFFFF、text=#111827；间距统一走 8pt 基准网格。
• 再落到 Component Rules：明确 anatomy、variants、states（default/hover/focus-visible/active/disabled/loading/error）、响应式与边界情况（长标签、空状态、溢出）。
• 用质量门槛兜底：每条规则必须锚定到 token、阈值或示例，不能只靠「简洁」「宽松」这类形容词；可访问性声明必须可在实现中测试；审美与可访问性冲突时，一律优先可访问性。
• 输出结构固定：生成的规范必须包含 Context and goals、Design tokens and foundations、Component-level rules、Accessibility requirements、Content and tone standards、Anti-patterns、QA checklist 七个部分，最后附一份可在 code review 中逐条执行的检查清单。

适用边界

• 规范默认只作为参考输出，不自动安装依赖、修改系统权限、创建持久化任务或执行下载内容。
• 涉及发送、发布、删除、付款、部署等外部写入时，必须先展示目标与影响，取得用户明确确认。
• 凭据只用于用户指定的对应官方服务，不回显、不记录、不转发到无关地址。
• 命令和代码默认作为参考；只有用户明确要求执行且目标范围清楚时才可运行。