宇宙暗黑霓虹风格设计

要解决的设计问题

未来感、科幻风界面（暗黑底色、霓虹强调色、空间感元素）很容易在多团队协作中失控：同一个按钮的蓝色可能是 #3B82F6，也可能是某个工程师随手写的 #2F6BFF；hover 效果在桌面端很炫酷，到键盘导航时却找不到焦点；为了视觉冲击力降低文字对比度，直接违反 WCAG 2.2 AA。更麻烦的是，这类风格往往缺乏统一的规范文档，组件规则散落在各个 PR 里，新人只能靠“问人”或“翻代码”来猜测约定。结果是：风格标识性很强，但实现质量高度依赖个人经验，且无法在 code review 阶段被系统性审查。

工作方式

这个技能的核心工作是生成可直接落地的设计系统指南，而不是给出一张漂亮的截图或灵感板。它的输出按固定结构组织，每一步都有明确输入和验收标准：

1. 先复述设计意图：用一句话概括本次要构建的体验（例如：“一个以暗黑为底、霓虹为强调的沉浸式空间导航界面”），再基于此提出规则，避免规则与意图脱节。
2. 先定义 Token 与基础约束，再谈组件：优先产出语义化 Token（primary、surface、text、danger 等），并给出字阶（12/14/16/20/24/32）、字重（400）、字族（Audiowide、JetBrains Mono）和间距阶梯（4/8/12/16/24/32）。规则要求必须使用语义化 Token，而不是原始 hex 值。
3. 组件规则覆盖完整生命周期：对每个组件说明 anatomy（结构）、variants（变体）、states（default / hover / focus-visible / active / disabled / loading / error）和交互行为（键盘、指针、触摸），并显式声明响应式行为与边缘情况（长标签、空状态、溢出）。
4. 无障碍要求可测试：每条无障碍声明都必须能在实现中被验证（例如“文本与背景对比度不低于 4.5:1”），而不是只写“注意可访问性”。
5. 内容与语气标准：写作语气要求简洁、自信、有帮助；明确禁止低对比度文本、不一致的间距节奏和模糊标签。
6. 反模式与迁移指引：针对已有不一致的 UI，给出禁止实现示例和迁移说明，帮助存量代码逐步收敛。
7. 以 QA 清单结尾：输出一份可以在 code review 中执行的检查清单，让设计规范具备工程化约束力。

约束语言使用 must（不可协商）和 should（推荐），每个 do-rule 至少配一个具体的 don't-example，避免只靠“好看”“高端”这类形容词来驱动决策。

适用边界

这个技能产出的是指南文档，不是可执行的 React 组件库或运行时样式表。它不负责直接生成 DOM 或 CSS 文件；团队仍需要自己实现 Token 管道和组件层。使用时需要注意：

• 必须先清晰陈述设计意图，否则后续规则可能偏离业务目标。
• 当视觉美学与无障碍冲突时，技能要求优先保证无障碍，并显式标记冲突点。
• 风格基础（例如暗黑主题、霓虹强调色）需要与你的产品品牌一致；若品牌已有成熟系统，应将该技能的 Token 作为参考而非强制替换。
• 它不替代真实的用户研究。间距、字号、对比度等数值是默认起点，在高可读性场景（金融、医疗、政府类）中需要根据实际用户测试调整。
• 安全边界：不自动安装依赖、不修改系统权限、不创建持久化任务或执行下载内容；涉及发送、发布、删除、付款、部署等外部写入操作时，必须先展示目标与影响并取得明确确认。