鲜活色彩设计系统规范

为什么需要这个规范

在多人协作的前端项目里，常见的退化路径是：设计师标注了“按钮悬停要有活力”，工程师顺手填了一个相近的十六进制值。几次迭代后，同一系统里出现多个紫色、间距节奏断裂、focus 状态缺失，可访问性只能靠事后补救。这套 Vibrant 规范要解决的不是“看起来不够好看”，而是把视觉决策固化为可检查的工程约束，避免实现阶段继续累积随意值。

它如何工作

这个技能会扮演设计规范作者，输出一份可直接进入代码评审的实施文档。它先建立 design tokens 与基础约束，再扩展到组件层规则。

• 基础层固定关键值：排版使用 14/16/18/24/32/40 的字号阶梯；主字体为 Noto Sans，标题字体为 Fascinate，等宽字体为 Fira Code；颜色必须引用语义化 token，例如 primary=#7C61D4、secondary=#EAAE87、success=#16A34A，而不是散落的字面量。
• 组件规则覆盖完整状态：每个组件都要定义 default、hover、focus-visible、active、disabled、loading、error 等必要状态，并明确键盘、指针、触屏的交互行为。
• 规范文档按固定结构生成：先重述设计意图，再给出 tokens 与基础约束，随后定义组件分析、变体、状态与响应式行为；最后补齐可测试的可访问性验收项、内容写作要求、反模式和 QA checklist。
• 规则表达区分约束强度：非协商规则使用 must，推荐做法使用 should；每个 Do 规则必须配有对应的反例，避免只写形容词而不给出阈值或示例。

适用边界

它生成的是规范文档和参考实现建议，不会自动安装依赖、修改系统权限或创建持久任务。涉及发送、发布、删除、付款、部署等外部写入时，会先展示目标和影响，等待明确确认。安全边界也要求命令与代码默认只作为参考，只有在范围清楚且用户明确要求时才执行。