技能介绍

要解决的问题

高对比艺术风看起来简单，落到代码里很容易失控。视觉上，设计师凭感觉定下的 颜色值、字号 和 间距 到了组件层经常对不上；工程上，空态、加载态、错误态 往往没有统一约定，实现时各写各的。另一个常见坑是把无障碍要求写成「注意对比度」这类模糊提示，WCAG 2.2 AA 的验收口径无法落到代码审查里，最后要么遗漏，要么靠人肉检查兜底。这个技能的目标是把风格约束写成工程师能直接执行的规范，而不是一份需要二次解读的灵感文档。

核心能力

技能按一套固定流程生成设计系统指南，核心能力可以拆成四步：

先定义视觉基线：在 high-contrast, artistic 风格下固定 typography scale（12/14/16/18/24/30/36）、字体栈、颜色 tokens 与 spacing scale（4/8/12/16/24/32），后续规则统一引用 token，不散落 hex 值。
再补组件规则：为每个组件写清楚 anatomy、variants，以及 default、hover、focus-visible、active、disabled、loading、error 等状态，并明确键盘、指针和触摸下的交互行为与响应式边界。
把无障碍写成验收项：keyboard-first、可见 focus states、语义优先、44px+ 触摸目标、reduced-motion 支持都会转成可测试条件，而不是建议性描述。
输出反模式与评审清单：给出 don't 清单（低对比文本、节奏不一致、无意义装饰动效、语义混淆等）和一份可直接用在 code review 里的 QA checklist，方便团队快速判定合规。

适用边界与注意点

这套技能偏规范撰写与约束表达，不替代组件库、样式系统或具体前端框架。它适合在已有 UI 上做约束收敛，也适合为新项目建立初始规范；遇到 品牌冲突 时，优先保留无障碍要求，再谈视觉表达。生成内容应遵循简诗 AI 的安全边界：技能本身不自动安装依赖、修改系统权限、创建持久化任务或执行下载内容。涉及发送、发布、删除、付款、部署等外部写入操作时，技能会先展示目标与影响，等待用户明确确认；凭据仅用于用户指定的对应官方服务，不回显、不记录，也不转发到无关地址。命令和代码默认作为参考，只有在用户明确要求且目标范围清楚时才会执行。