8pt 设计规范
AaAaAaAa
示例输出
介绍
让模型生成界面时遵守同一套设计规范：8pt 间距、字号阶梯、圆角、阴影、配色与暗色模式。
它会做什么
- 输出设计令牌：间距、字号、圆角、阴影、颜色
- 生成 CSS 变量与 Tailwind 配置
- 检查已有页面中不符合规范的数值并给出修改
- 同时产出浅色与深色两套
安装
复制安装提示词交给模型，或用 8pt CLI 装进 Claude、Codex、Cursor 的 skills 目录，或在已接入 8pt MCP 的编辑器里直接调用。
$ npm i -g @8pt-dev/cli && 8pt skill ui-8pt-system
mcp › 使用 8pt MCP 调用 get_skill("ui-8pt-system")
文件结构
ui-8pt-system/
├── SKILL.md
├── tokens.css
├── tokens.json
├── reference/
│ └── rules.md
└── scripts/
└── audit_8pt.pySKILL.md
--- name: ui-8pt-system description: 让界面遵守同一套 8pt 设计规范：间距、字号阶梯、圆角、阴影、配色、暗色模式；可生成设计令牌，也可审查并修复已有页面。用户提到「设计规范」「设计令牌 / design tokens」「间距不统一」「8pt 网格」「暗色模式」「UI 走查」「Tailwind 配置统一」时使用。 author: 8pt --- # 8pt 设计规范 产出：`tokens.css`、`tokens.json`（以及需要时的 Tailwind 配置）、`audit.md`（审查模式）。 ## 1. 先问用户（最多 3 个，未回答用默认值） 1. 要做什么？A 新建规范 / B 审查并修复现有页面。默认：项目里已有界面代码就做 B，否则做 A。 2. 品牌主色？默认：`#4D74FF`（已验证对比度的整套色阶见 tokens.css）。 3. 技术栈？默认：自动识别——有 `tailwind.config.*` 用 Tailwind 映射，否则用 CSS 变量。 ## 2. 文件 - `tokens.css`：完整令牌（间距、字体、圆角、尺寸、动效、层级、品牌色、浅 / 深语义色、阴影）与基础样式。直接复制进项目。 - `tokens.json`：同一套令牌的 W3C Design Tokens 格式，给 Figma 插件 / Style Dictionary 用。 - `reference/rules.md`：每类令牌的用法规则、对比度要求、Tailwind 映射、audit.md 结构。 - `scripts/audit_8pt.py`：审查脚本（仅标准库），扫描 CSS / HTML / JSX / TSX / Vue / Svelte 中的非规范数值与硬编码颜色。 ## 3. 流程 A：新建规范 1. 复制 `tokens.css` 到项目（如 `src/styles/tokens.css`），在全局入口最先引入；复制 `tokens.json` 到 `design/tokens.json`。 2. 若用户给了新品牌色：按 `reference/rules.md` 第 4 节生成 300/500/600/700 四档，计算对比度（相对亮度公式 (L1+0.05)/(L2+0.05)），600 对白 ≥ 4.5、300 对 #0b0b10 ≥ 4.5，不达标就加深 / 提亮后重算；同步改 css 与 json。 3. Tailwind 项目：把 `reference/rules.md` 第 6 节配置合并进 `tailwind.config`。 4. 暗色模式：确认 `<html data-theme="dark">` 与系统偏好两种方式都能切换。 5. 写一个示例页面或组件（按钮、输入框、卡片各一）验证令牌生效。 ## 4. 流程 B：审查与修复 1. 运行 `python3 scripts/audit_8pt.py <源码目录> -o audit-scan.md`（脚本在本 Skill 目录内；把它复制到项目根的 `scripts/` 下再运行也可以）。 2. 人工补查脚本查不到的项：文字对比度、触控目标 ≥ 44px、字号层级是否超过 3 种 / 屏、暗色模式下有无写死的白底黑字、`:focus-visible` 是否被 `outline:none` 去掉。 3. 修复：按建议就近替换为令牌变量（如 `padding:10px 15px` → `padding:var(--space-2) var(--space-4)`）；视觉跳变明显的（相差 ≥ 4px 的字号）先列出来问用户再改。 4. 修复后重跑脚本，直到剩余项都有保留理由（第三方组件、图表内部、像素级图标）。 5. 按 `reference/rules.md` 第 7 节写 `audit.md`：结论、扫描表、人工检查、修改清单。 ## 5. 核心规格 - 间距 0 4 8 12 16 24 32 40 48 64 80 96 128；字号 12 14 16 20 24 32 48 64（行高 16 20 24 28 32 40 56 72）。 - 圆角 4 8 12 16 24 full；阴影 3 级；控件高 32 / 40 / 48。 - 对比度：正文 ≥ 4.5:1，大字与非文字 UI ≥ 3:1，浅色深色都要达标。 ## 6. 交付前自检 - [ ] tokens.css 与 tokens.json 数值一致（间距、字号、圆角、颜色逐项对过）。 - [ ] 组件代码里没有直接写的十六进制颜色和非令牌 px（重跑审查脚本确认，或列出保留理由）。 - [ ] 浅色、深色两套都逐页看过，文字对比度达标。 - [ ] 键盘 Tab 能看到焦点框；`prefers-reduced-motion` 下无动画。 - [ ] audit.md（审查模式）四个部分齐全，修改清单与实际改动一致。 ## 7. 不要做 - 不为了「贴近原稿」新增 13px、15px、18px 这类非令牌值；确有需要先问用户并加入令牌，而不是散落在组件里。 - 不擅自改变页面信息结构、文案或功能，审查只动样式。 - 不删除 `:focus-visible` 样式，不用纯颜色表达错误 / 成功状态。 - 不声称「符合 WCAG」除非逐项验证过；只报告实际检查过的项。 ## 8. 交付时回复用户 1. 做了什么（新建 / 审查）与改动的文件列表。 2. 审查模式：问题总数、已修复数、保留项及理由。 3. 采用的默认值（品牌色、技术栈）与需要用户决定的视觉变化。