AI 辅助设计规范检查：自动验证间距、字号与颜色的一致性 AI 辅助设计规范检查自动验证间距、字号与颜色的一致性一、那个用 13px 字号的表单和用 14px 的侧边栏——没人注意到直到审计那天一个后台管理系统的设计一致性审计发现了一个让人脸红的数字全站 270 个页面中使用的字号值有 18 种从 11px 到 48px但设计系统只定义了 7 种。间距值出现了 23 种从 2px 到 120px但 Token 只定义了 9 种。颜色值出现了 57 种 HEX 值Token 只定义了 32 种。这些非法值不是恶意添加的——是 7 位开发者在 3 年时间里每次解决一个这里间距看起来不太够的问题时随手敲下的margin-left: 14px或color: #5B6C7D。代码可以跑、页面视觉也还行但还行是设计规范的慢性死亡。每一次硬编码都让 Token 的权威性下降一点。AI 在设计规范检查中的角色是充当一个永不疲劳的规范警察——扫描所有 CSS 和 JSX 文件找出每一个不在 Token 注册表中的样式值生成合规报告并在 CI 中拦截新的违反。二、设计规范的自动审计模型flowchart TD A[扫描源码br/(CSS/JSX/TSX/Vue)] -- B[提取样式值] B -- C[分类] C -- C1[间距值br/(margin/padding/gap)] C -- C2[字号值br/(font-size)] C -- C3[颜色值br/(HEX/RGB/HSL)] C -- C4[圆角值br/(border-radius)] C1 -- D{在 Token 表中?} C2 -- D C3 -- D C4 -- D D --|是| E[✅ 合规] D --|否| F[❌ 违反规范br/标记 建议替代] F -- G[生成合规报告]三、设计规范自动检查器/** * 设计规范自动检查引擎 */ import { readFileSync } from fs; import { glob } from glob; import postcss from postcss; interface TokenRegistry { spacing: number[]; // 允许的间距值px: [4, 8, 12, 16, 20, 24, 32, 40, 48, 64] fontSize: number[]; // 允许的字号值px: [12, 14, 16, 18, 20, 24, 30, 36, 48] colors: string[]; // 允许的 HEX 颜色: [#3B82F6, #F8FAFC, ...] radius: number[]; // 允许的圆角值px: [0, 4, 8, 12, 16, 9999] } interface DesignViolation { file: string; line: number; property: string; actualValue: string; // 实际使用的值 suggestion: string; // 推荐使用的 Token severity: error | warning; } const TOKEN_REGISTRY: TokenRegistry { spacing: [4, 8, 12, 16, 20, 24, 32, 40, 48, 64], fontSize: [12, 14, 16, 18, 20, 24, 30, 36, 48], colors: [ #3B82F6, #2563EB, #1D4ED8, #0F172A, #475569, #94A3B8, #FFFFFF, #F8FAFC, #F1F5F9, #E2E8F0, #CBD5E1, #EF4444, #22C55E, ], radius: [0, 4, 8, 12, 16, 9999], }; /** * 检查 CSS 文件中的设计规范违反 */ function checkCSSFile(filePath: string): DesignViolation[] { const violations: DesignViolation[] []; const css readFileSync(filePath, utf-8); const root postcss.parse(css); root.walkDecls((decl) { const prop decl.prop; const value decl.value; // 间距检查跳过 CSS 变量赋值和 0 值 if (prop.match(/^(margin|padding|gap)/) !value.includes(var() value ! 0) { checkSpacing({ prop, value, filePath, source: decl.source, violations, }); } // 字号检查 if (prop font-size !value.includes(var()) { checkFontSize({ prop, value, filePath, source: decl.source, violations }); } // 颜色检查 if (prop.match(/^(color|background|border-color)/) value.match(/^#[0-9a-fA-F]/)) { checkColor({ prop, value: value.trim().split( )[0], filePath, source: decl.source, violations }); } // 圆角检查 if (prop border-radius value.match(/^\dpx$/)) { checkRadius({ prop, value, filePath, source: decl.source, violations }); } }); return violations; } function checkSpacing({ prop, value, filePath, source, violations }: any) { const pxMatch value.match(/^(\d)px/); if (!pxMatch) return; const px parseInt(pxMatch[1]); if (!TOKEN_REGISTRY.spacing.includes(px)) { const nearest findNearest(px, TOKEN_REGISTRY.spacing); violations.push({ file: filePath, line: source?.start?.line || 0, property: prop, actualValue: ${px}px, suggestion: 使用 var(--space-${nearest}) (${nearest}px), severity: error, }); } } function checkFontSize({ prop, value, filePath, source, violations }: any) { const pxMatch value.match(/^(\d)px/); if (!pxMatch) return; const px parseInt(pxMatch[1]); if (!TOKEN_REGISTRY.fontSize.includes(px)) { const nearest findNearest(px, TOKEN_REGISTRY.fontSize); violations.push({ file: filePath, line: source?.start?.line || 0, property: prop, actualValue: ${px}px, suggestion: 使用 var(--font-size-${nearest}) (${nearest}px), severity: warning, }); } } function checkColor({ value, filePath, source, violations }: any) { const hex value.toUpperCase(); if (!TOKEN_REGISTRY.colors.map(c c.toUpperCase()).includes(hex)) { violations.push({ file: filePath, line: source?.start?.line || 0, property: color, actualValue: hex, suggestion: 颜色 ${hex} 不在 Token 注册表中。请添加到 Token 或使用已有颜色。, severity: error, }); } } function checkRadius({ value, filePath, source, violations }: any) { const px parseInt(value); if (!TOKEN_REGISTRY.radius.includes(px)) { const nearest findNearest(px, TOKEN_REGISTRY.radius); violations.push({ file: filePath, line: source?.start?.line || 0, property: border-radius, actualValue: value, suggestion: 使用 var(--radius-${nearest}) (${nearest}px), severity: warning, }); } } function findNearest(target: number, allowed: number[]): number { return allowed.reduce((prev, curr) Math.abs(curr - target) Math.abs(prev - target) ? curr : prev ); } /** * 扫描整个项目的设计规范合规性 */ async function auditDesignCompliance(projectDir: string) { const cssFiles await glob(${projectDir}/**/*.{css,scss,less}, { ignore: [**/node_modules/**, **/dist/**], }); const allViolations: DesignViolation[] []; for (const file of cssFiles) { const violations checkCSSFile(file); allViolations.push(...violations); } // 按严重性分组统计 const errors allViolations.filter(v v.severity error); const warnings allViolations.filter(v v.severity warning); return { total: allViolations.length, errors: errors.length, warnings: warnings.length, violations: allViolations, report: generateComplianceReport(allViolations), }; } function generateComplianceReport(violations: DesignViolation[]): string { const byProperty: Recordstring, DesignViolation[] {}; for (const v of violations) { const key v.property; if (!byProperty[key]) byProperty[key] []; byProperty[key].push(v); } const lines [## 设计规范合规审计报告\n]; for (const [prop, items] of Object.entries(byProperty)) { lines.push(### ${prop}${items.length} 项违反); for (const item of items.slice(0, 5)) { lines.push(- \${item.file}:${item.line}\ — ${item.actualValue} → ${item.suggestion}); } if (items.length 5) lines.push(- ... 及其他 ${items.length - 5} 项); lines.push(); } return lines.join(\n); } export { auditDesignCompliance, checkCSSFile, TOKEN_REGISTRY }; export type { DesignViolation, TokenRegistry };四、检查器的边界合理违反与误报的差异。有些设计规范违反是故意的——比如一个折扣标签需要border-radius: 20px来形成胶囊形状而 Token 只定义了0/4/8/12/16/9999。在 Token 中20px不在表内但 9999 会形成完全的半圆角不符合设计需求。这种情况下团队的策略应该是将 20px 增加到 Token 注册表而非警告但不处理——如果它是合理需求就应该被正式化。Token 的演进和检查的同步。当设计师在 Figma 中新增了一个间距值--space-14: 56pxToken 注册表需要同步更新。如果检查器的 TOKEN_REGISTRY 是手动维护的它会在 3 天内落后于真实的 Token 文件。正确的做法是检查器从 Token 的 JSON 文件自动读取允许值——Token 文件是唯一真值源。五、总结设计规范检查器 提取样式值 → 与 Token 注册表对比 → 标记违规项。四个核心检查维度间距margin/padding/gap、字号font-size、颜色HEX、圆角border-radius。硬编码的像素值和 HEX 颜色是设计规范腐败的起点——每一处随手写的都是未来的雷。最佳替代建议 在 Token 注册表中查找最接近的值——14px → --space-4 (16px)。检查器的 Token 注册表应从 Token JSON 文件自动生成——避免手动维护不一致。如果某个违反是合理需求——将该值加入 Token 注册表而非在检查报告中标记豁免。CI 阻断策略error严格违反阻断合入warning轻微偏差仅在 PR 评论中提示。颜色检查需要将 HEX 值统一大写后进行对比——#3b82f6和#3B82F6在逻辑上是相同的。0和auto等特殊值不应被标记——它们在任何间距系统中都是合法的。设计规范检查的目标是让 Token 成为样式修改的唯一入口——任何绕过 Token 的修改都应该在 PR 阶段被发现。