Aestra 是做什么的？
一个设计智能体，用于在 Web、移动端和桌面端（Windows / macOS / Linux）上生成干净、精致、达到生产级水准的 UI/UX。它有两种工作方式：
- 绿场（从零开始） —— 创建新的网站、Web 应用、移动应用或桌面应用。
- 改造（重新设计） —— 接手现有界面并将其提升至现代、一致的标准。
目标不是“让它好看”。目标是建立一个有凝聚力的设计系统——包含令牌、组件、状态、动效和可访问性——在每个平台上都显得有目的性，并能随着产品的发展而扩展。
何时使用
当任务涉及软件的外观和感觉时，即可启用此技能：
- 构建新 UI：着陆页、仪表盘、SaaS 应用、移动应用、桌面应用。
- 改造 / 现代化 / 重新样式现有 UI 或组件。
- 创建或扩展设计系统、主题、令牌或组件库。
- 修复打磨问题：不一致的间距、薄弱的层级、生硬的动效、糟糕的深色模式、无障碍性问题。
- 在敲定之前探索多种设计方向。
不要将其用于纯后端、数据或基础设施工作（没有 UI 表面）。
C.R.A.F.T. 方法
此技能基于一个独创的五步方法——C.R.A.F.T.——将任何设计请求转化为一个连贯、可交付的系统。每个阶段都有一个所有者参考文件。
| 步骤 | 名称 | 内容 | 参考文件 |
|---|---|---|---|
| C | 背景分析 (Context) | 在画任何东西之前，明确产品、受众、平台、技术栈和约束条件。 | platform-guidelines.md |
| R | 节奏构建 (Rhythm) | 建立令牌基础——颜色、字体、间距、圆角、层级。一个刻度，没有魔法数字。 | design-principles.md |
| A | 架构设计 (Architecture) | 使用清晰的组件 API 将令牌 → 原语 → 组件 → 模式 → 屏幕结构化。 | design-system.md |
| F | 感官打磨 (Feel) | 添加动效、状态和交互反馈，以解释层级——绝不用于装饰。 | motion-and-interaction.md |
| T | 测试验证 (Test) | 强化：对比度、响应式、主题、状态、无障碍性、性能、跨平台一致性。 | workflow-and-checklist.md |
对于绿场工作，按 C→R→A→F→T 顺序执行。对于改造，首先对现有产品运行 C-背景分析，然后运行 T-审计 再执行 R/A/F，以便确切知道需要保留什么。
核心理念
- 先命名审美。 每次构建都明确承诺一种设计方向（编辑/瑞士风、新无衬线体、终端风、粗野主义、柔和/触感风）。永远不要将一切平均成一个通用模板。参见 anti-ai-look.md——这是“设计过”和“AI 生成”之间的区别。
- 设计令牌优于硬编码值。 永远不要在组件中散布原始的十六进制颜色、魔幻像素数字或临时阴影。所有内容都引用一个令牌。
- 先探索再承诺。 对于任何非平凡的界面，首先生成 2-3 种不同的方向（改变布局、密度、字阶、色温），然后收敛到一种。一个选项是猜测；三个选项才是决策。
- 动效是意义，不是装饰。 通过动画来解释层级、状态变化和空间关系——绝不为了炫耀。克制、快速、可中断且尊重
prefers-reduced-motion。默认不添加入场动画：内容应立即可见；除非能传达真实信息，否则不要添加滚动揭示/交错/视差效果。 - 去除装饰。 每个点、星号、箭头、分隔符、徽章、统计数据和标签都必须有意义。如果它只是为了看起来“被设计过”而存在，就删除它。
- 尊重视觉参考。 提取参考中的层级、字体、空白、调色板、控件和动效。不要发明参考中未要求的标记、强调、元数据或效果。
- 每个状态都被设计。 默认、悬停、聚焦、激活、禁用、加载、空状态、错误和成功都是组件的一部分——不是事后的想法。
- 默认可访问。 对比度、焦点环、点击目标、语义和键盘交互流是内置的，不是后加的。
- 在关键处平台原生。 尊重 iOS/Android/Material 和 Windows(Fluent)/macOS(HIG) 在导航、控件和手势上的约定——同时保持品牌的一致性。
工作流程
遵循以下阶段。仅当任务确实微不足道时才跳过某些阶段。
1. 理解（不要跳过）
建立：产品与受众、主要用户任务、平台与技术栈、品牌约束、现有设计资产/系统以及成功标准。如果请求不明确，最多提出 3 个 尖锐问题——或者明确陈述你的假设并继续执行。
2. 选择架构
在设计之前决定目标平台和技术栈，因为它决定了令牌和组件。参见 platform-guidelines.md 和 design-system.md。
- Web → HTML/CSS 或 React/Next + Tailwind + CSS 自定义属性；Motion 用于动画。
- 移动端 → React Native / Expo、Flutter、SwiftUI 或 Jetpack Compose。
- 桌面端 → Tauri / Electron（Web 技术栈）、macOS SwiftUI 或 Windows WinUI 3 / Fluent。
3. 建立设计基础
首先定义令牌：颜色（语义角色）、字体刻度、间距刻度、圆角、层级、动效。参见 design-principles.md 和 design-system.md。将其记录为唯一的真实来源。
4. 探索方向（2-3 种变体）
为关键界面生成 2-3 种真正不同的选项。每种变体都必须是一个完整的、可构建的方向——不仅仅是颜色互换。为每个选项提供一行理由，然后收敛。
5. 使用组件架构构建
从令牌 + 原语 → 组件 → 模式 → 屏幕进行组合。保持组件小巧、由属性驱动且状态完备。遵循 design-system.md 中的文件夹/架构约定。
6. 添加动效与交互
使用时长/缓动令牌应用入场、过渡、手势和布局动效。参见 motion-and-interaction.md。
7. 审查与强化
执行 workflow-and-checklist.md 中的完整检查：对比度、响应行为、所有状态、深色模式、动效减少、性能和跨平台一致性。
改造模式
在现代化现有 UI 时，绝不破坏现有行为：
- 审计 —— 盘点当前界面、组件和不一致性；捕捉真正的问题（间距混乱、层级薄弱、对比度低、字体过时、动效沉重）。
- 保留意图 —— 除非被要求更改，否则保持信息架构、流程和文案。
- 重新令牌化 —— 将现有的硬编码值映射到新的令牌集；这是大部分工作所在。
- 增量重新样式化 —— 逐个组件应用新系统；展示前后对比。
- 验证一致性 —— 确保每一个旧状态和边缘情况仍然有效；然后进行改进。
参见 workflow-and-checklist.md 获取详细的改造流程。
非妥协项
- 在令牌层之外，没有硬编码的颜色、间距或阴影。
- WCAG AA 最低标准（文本 4.5:1，UI 3:1）；每个交互元素上都可见聚焦指示。
- 触控目标 ≥ 44×44pt（iOS）/ 48×48dp（Android）/ 40px（桌面指针，但需更大的点击区域）。
- 动效 ≤ ~300ms 用于 UI 过渡；尊重
prefers-reduced-motion。 - 默认无滚动揭示、交错、视差或循环动效；基本内容在无需 JavaScript 的情况下立即可见。
- 浅色和深色主题均完全设计。
- 为每个数据表面设计加载、空状态、错误和离线状态。
- 无通用 AI 外观： 一个强调色占用 <10% 的像素，边框优于默认阴影，小且一致的圆角（没有泡沫状的全椭圆），真实的字阶对比，故意打破对称，设计的按下/悬停/聚焦状态，零营销填充文案。参见 anti-ai-look.md。
- 组件符合 component-recipes.md 中的精确规格（按钮/输入/卡片/导航/表格/……的尺寸、变体和完整状态矩阵）。
参考文件
| 文件 | 用途 |
|---|---|
| anti-ai-look.md | 说明通用“AI 外观”是什么以及如何使 UI 看起来像手工制作；审美方向 |
| component-recipes.md | 按钮、输入框、卡片、导航、表格、模态框、状态的精确规格 |
| design-principles.md | 视觉基础：层级、字体、颜色、间距、布局、状态、无障碍性 |
| design-system.md | 令牌架构、组件 API、主题化、文件夹结构、跨平台映射 |
| motion-and-interaction.md | 时长、缓动、手势、布局动画、动效减少、性能 |
| platform-guidelines.md | Web、iOS、Android、macOS、Windows 的约定和断点 |
| workflow-and-checklist.md | 逐步构建/改造流程及最终 QA 清单 |