aesthetic-application

美学应用

概述

将指定的美学转化为完整、可供开发者直接使用的设计规范：包括结构化的令牌规范表、文化标记列表、组件级说明，以及用于标记冲突的标记部分。所有决策都具体且可实现，绝不使用抽象的氛围描述。涵盖美学框架的全部 7 个维度。

兼容性 / 工具

此技能有意不声明 allowed-tools 前置元数据。它可在兼容 Agent Skills 的运行时之间移植，并依赖读取此 SKILL.md、技能本地的 references/ Markdown 文件，以及已安装的 aesthetic-literacy 词典。如果 Agent 具有文件读取工具，请使用这些工具加载文件；否则，请用户提供相关摘录。

何时应用此技能

适用于以下情况：

• 用户要求“让它看起来像 X”、“应用这种美学”或“为 X 设计令牌”
• 用户需要根据某种美学方向编写交付开发者的规范
• 用户要求提供扎根于某种美学的 CSS 变量、设计令牌或组件说明
• 用户提供了有依据的视觉取值，需要将其整理为令牌

以下情况不要应用：

• 尚未确定美学方向（请先运行 aesthetic-literacy 消歧）
• 用户需要组件实现建议、无障碍问题解决方案或性能建议（不在范围内）

依赖项

需要：aesthetic-literacy（7 维框架、词典、不可妥协项）
支持使用用户提供的参考图中有依据的取值；如有明确提供的取值，应优先于词典中的近似值。

已安装用户的技能本地参考文件：

• references/output-contract.md — 所需的响应结构和质量标准
• references/token-template.md — 完整的令牌表框架
• references/css-translation-patterns.md — 按美学维度划分的 CSS 实现模式
• references/component-notes-contract.md — 组件说明的必要覆盖范围

知识库路径

在生成令牌或组件说明之前，请从已安装的 aesthetic-literacy 技能中加载规范词典条目：

• 必要时，通过 aesthetic-literacy/references/aesthetic-index.md 查找标识符。
• 将 aesthetic-literacy/aesthetics/<slug>.md 作为常规应用设计的资料来源加载。
• 在起草最终交付内容之前，加载 references/output-contract.md。

常规应用设计工作流中不要加载根目录研究日志。根目录下的 knowledge/aesthetics/ 资料和仅追加日志属于溯源、维护或研究资源；只有在用户明确要求溯源、维护或研究详情，或规范条目标记了必须核查来源的不确定之处时，才加载它们。

6 步应用工作流

第 1 步 — 确认美学方向

明确说出美学名称。不要在含糊不清的情况下继续。

• 如果用户的描述含糊（“让它看起来很酷” / “有未来感”），请先应用 aesthetic-literacy 消歧协议
• 如果用户要求的术语是子类或相关美学（例如“outrun”、“datamoshing”、“old money”、“Web 2.0 Gloss”），而不是规范标识符，请确定其上位美学，加载对应的词典条目，阅读子类 / 相关美学部分，并注明应强化该子类的哪些特定重点。请说明：“正在以 [connotation mode] 模式应用 [parent aesthetic]，并突出 [subset] 的特点。”
• 加载 aesthetic-literacy/aesthetics/<slug>.md，并将其作为实际应用的指导资料来源
• 如果没有规范条目，且该美学鲜为人知或较为小众，请说明此公开软件包目前缺少足够的、基于来源的指导，而不要编造取值
• 明确说明：“正在以 [connotation mode] 模式应用 [aesthetic name]。”

第 2 步 — 确定风格意图

选择并说明以下四种风格模式之一：

模式	含义	适用场景
Authentic（原汁原味）	纯粹、符合时代背景的表达	小众受众、文化产品、自我觉察的语境
Nostalgic quotation（怀旧引用）	唤起怀旧感，同时融入更新：兼顾当代易用性与鲜明可辨的美学基因	消费品、生活方式品牌
Ironic pastiche（戏仿拼贴）	带有自觉意味的夸张，用于制造诙谐效果或评论	编辑内容、创意项目
Contemporary revival（当代复兴）	通过当代设计审美加以过滤，重新诠释	强调传承的现代科技产品

如果用户没有明确指定，请根据上下文推断并明确说明你的推断。不确定时请询问。

第 3 步 — 收集约束条件

在生成输出之前，收集并记录以下内容：

• WCAG AA：记录任何对比度冲突。标出这些冲突——不要解决。由开发者决定如何处理与无障碍要求冲突的美学设计。
• 深色模式：这种美学是否有自然的深色模式变体？还是说深色模式会从根本上改变这种美学？
• 平台：Web、iOS、Android 还是印刷品？（动效和字体能力差异显著。）
• 融合：这是否是多种美学的混合？指出两种源美学，并找出产生冲突的维度。

第 4 步 — 为各维度做出具体决策

逐一处理全部 7 个维度。每项决策都必须是可实施的值：

维度	必需输出
配色	十六进制值及其角色分配（背景、表面、主色、次色、强调色）
排版	字体名称（若未指定字体，则说明字体类别）、字重、字号、字距、行高
纹理	CSS 属性和值（或“无”）
形状	圆角值（px）、几何风格说明
动效	时长范围（ms）、缓动方式（名称或 cubic-bezier）、首选动画类型
空间规范	基准间距单位（px）、刻度（4px / 8px / 12px 等）、密度描述
文化标记	应包含的 3–5 个信号；应避免的 2–3 个信号

第 5 步 — 解决冲突

如果美学融合产生冲突，请明确解决：

• 指出两种源美学
• 找出存在冲突的具体维度
• 说明各维度的解决方案：
  • 哪种源美学优先？
  • 或者：采用兼顾两者的综合方案？
  • 或者：由用户解决冲突（标出冲突，不要猜测）

不要留下未解决的融合。未解决的融合会导致输出不协调。

第 6 步 — 生成输出

生成以下全部 4 个输出部分。

---

输出格式

1. 设计令牌规范

扁平、与系统无关的令牌值表，涵盖颜色（7 个令牌）、排版（8 个令牌）、形状（3 个）、动效（3 个）、间距（6 个）和布局（4 个，可选）。将其转换为项目使用的令牌系统（CSS 自定义属性、Tailwind 配置、DTCG JSON、Sass 变量、Swift/Android 令牌等）。

加载 references/token-template.md，查看包含所有令牌名称、类别和说明的完整空白模板。

输出格式说明：令牌表是主要的、与格式无关的输出。如果开发者明确要求 DTCG JSON、CSS 自定义属性或 Tailwind 配置，请转换为所需格式。EXAMPLES.md 中提供了 DTCG JSON 示例。

2. 文化标记

应包含（3–5 个信号）：

• 信号 1
• 信号 2
• 信号 3

应避免（2–3 个信号）：

• 反向信号 1
• 反向信号 2

3. 组件说明

为 12 个关键 UI 组件提供简短、可实施的说明：按钮、卡片、输入框、导航、主视觉/页眉、标题、分隔线、链接、徽章/标签、模态框/叠加层、警报/通知、图标。

加载 references/component-notes-contract.md，查看完整的组件覆盖要求。

4. 标记

需要开发者关注的问题——不要解决，只需指出：

• WCAG 冲突：列出调色板中未达到 AA 对比度的颜色组合（正文文本为 4.5:1，大号文本为 3:1）
• 减少动态效果：如果美学风格依赖动态效果，请注明（在 prefers-reduced-motion 下会消失的效果）
• 深色模式缺失：如果未生成深色模式变体，请注明
• 美学疲劳风险：如果美学风格处于“饱和度峰值”阶段，请注明，以便留意时机
• 未解决的混合冲突：第 5 步中标记为需要用户决策的任何冲突

示例

不确定输出格式、令牌表结构或如何处理混合冲突时，请加载 EXAMPLES.md。其中包含完整的 Y2K 规范、残酷主义 + WCAG 解决方案，以及装饰艺术混合示例。

注意事项

• 绝不要用文字描述代替令牌。 开发者需要的是 #C0C0C0，而不是“金属质感表面”。每项输出都必须是可实现的值。
• 未经检查，不要宣称某种美学风格与 WCAG AA 不兼容。 原始残酷主义（黑底白字、白底黑字）轻松满足 AA。找出实际存在冲突的颜色组合，不要笼统地声称不兼容。
• 绝不要让混合冲突悬而未决。“融合 X 的优雅与 Y 的简洁线条”只是设计简报，不是规范。请指出冲突维度，并针对每个维度给出明确决策。
• 始终包含文化标记。 缺少包含 / 避免文化信号列表的令牌会产生可能适用于任何风格的通用规范。文化标记是不可妥协的输出要求。

参考资料

需要令牌格式规范、无障碍阈值或字体来源时，请加载 REFERENCES.md：

• W3C DTCG JSON 令牌格式 → DTCG 格式规范
• WCAG 对比度阈值 → WCAG 2.1 SC 1.4.3；WebAIM 对比度检查器
• 字体来源 → Google Fonts、Fonts In Use