技能介绍

问题：极简风格为什么难以落地

设计稿一片纯白，代码却越写越「灰」——这是多数团队落地极简风格的常态：

硬编码色值满天飞：#F5F5F5、#EEEEEE、#FAFAFA 轮番出现，同一个中性灰有五六种写法。
间距没有节奏：margin: 10px、padding: 13px 随手写，8pt 基线在第三个屏幕就崩溃了。
无障碍被当成可选项：对比度不足的灰字、丢失的 focus-visible 态、小于 44px 的触控目标，往往在验收时才被发现。
「少即是多」退化成「没有规范」：组件各自为政，空状态、加载态、错误态几乎没有人定义。

这个技能如何工作

它扮演的角色是设计系统规范作者（design-system guideline author），而不是画图助手。核心能力分三层：

1. 先定义地基，再谈组件。 输出从 design tokens 开始：色彩用语义化 token 而非裸值（primary=#3B82F6、surface=#FFFFFF、text=#111827）；字体为 Roboto（正文）、Poppins（展示）、Inconsolata（等宽）；字号阶梯 12/14/16/20/24/32；间距锁定 8pt 基线。

2. 组件规则必须可执行。 每个组件都要写清 anatomy、variants、interaction states（default / hover / focus-visible / active / disabled / loading / error），以及键盘、指针、触摸三种输入的交互行为，并覆盖长标签、空状态、溢出等边界情况。

3. 质量门槛写死在产出里。 规范必须附带可测试的无障碍验收标准（WCAG 2.2 AA、可见焦点态、语义化 HTML 优先）、反模式清单（禁止低对比度文本、禁止无目的的装饰性动效）和一份能在 code review 里直接勾选的 QA checklist。

适用边界

它只生成规范文档和参考实现建议，不自动安装依赖、修改系统权限或执行下载内容；涉及发送、发布、删除、付款等外部写入操作时，必须先展示目标与影响并取得明确确认。
规则锚定 token、阈值或具体示例，不依赖「更精致」「更有呼吸感」这类模糊形容词。
当审美与可访问性冲突时，规范要求先保 a11y——这是 must 级别的约束，不是 should。

适合想给团队引入一套可维护纯白风格基线的前端工程师和设计系统负责人；不适合指望它一键生成整套 UI 组件库的场景。