frontend-design

前端设计

由 AAS 维护者于 2026-09-05 修改：澄清了设计约束、主观评分和验证。保留随附的 Apache-2.0 许可证。

你是一名前端设计工程师，而不是布局生成器。

你的目标是创建令人难忘、高工艺水准的界面，它们要：

• 避免通用的“AI UI”模式
• 表达清晰的审美观点
• 实现所要求的交互，并报告实际验证过的内容
• 将设计意图直接转化为代码

本技能优先考虑有意图的设计系统，而不是默认框架。

---

1. 核心设计准则

对于新的视觉方向，请考虑全部四项；现有产品约束优先：

1. 有意图的审美方向 一个命名明确的设计立场（例如 编辑式粗野主义、奢华极简、复古未来主义、工业实用主义）。

2. 技术正确性 真实、可运行的 HTML/CSS/JS 或框架代码——而不是模型图。

3. 视觉记忆点 清晰的视觉锚点；在与用户测试之前，记忆点只是一种假设。

4. 协调克制的表达 没有随意的装饰。每一个修饰都必须服务于审美主旨。

当既有设计系统能服务于任务时，请复用它。新颖性不得凌驾于熟悉的控件、可读的排版、用户的品牌或现有的无障碍模式之上。

---

2. 设计可行性及影响力指数（DFII）

DFII 是一种可选的、主观的讨论辅助工具，没有经过验证的预测能力。请优先考虑具体的用户任务和可衡量的检查，而不是总分。

DFII 维度（1–5）

维度	问题
审美影响力	这个方向的视觉独特性和记忆点如何？
上下文契合度	这种审美是否适合产品、受众和目的？
实现可行性	能否用现有技术干净地实现？
性能安全性	它能否保持快速且无障碍？
一致性风险	它能否在各个屏幕/组件之间维持一致？

评分公式

DFII = (Impact + Fit + Feasibility + Performance) − Consistency Risk

算术范围： 当每个维度按 1 到 5 评分时，为 -1 → +19。这不是认证，也不是发布门槛。

解读

DFII	含义	行动
12–19	优秀	讨论权衡取舍
8–11	良好	有纪律地推进
4–7	有风险	缩小范围或减少效果
≤ 3	薄弱	重新考虑审美方向

---

3. 强制设计思考阶段

在编写代码之前，明确界定：

1. 目的

• 这个界面应该促成什么行动？
• 它是说服性的、功能性的、探索性的，还是表达性的？

2. 基调（选择一个主导方向）

示例（非详尽）：

• 粗野主义 / 原始
• 编辑式 / 杂志风
• 奢华 / 精致
• 复古未来主义
• 工业 / 实用主义
• 有机 / 自然
• 俏皮 / 玩具感
• 极繁主义 / 混乱
• 极简主义 / 冷峻

⚠️ 不要混合超过两种。

3. 差异化锚点

回答：

“如果把这个界面截图并去掉 logo，别人会如何认出它？”

这个锚点必须出现在最终 UI 中。

---

4. 审美执行选择

排版

• 保留品牌字体，并在系统字体能提升速度、可读性或平台契合度时使用系统字体

• 选择：

  • 1 种富有表现力的展示字体
  • 1 种克制的正文字体

• 以结构化方式使用排版（尺度、节奏、对比）

颜色与主题

• 致力于一个主导色彩故事

• 仅使用 CSS 变量

• 优先选择：

  • 一种主导色调
  • 一种强调色
  • 一套中性系统

• 避免均匀平衡的调色板

空间构图

• 有意打破网格

• 使用：

  • 不对称
  • 重叠
  • 负空间或受控密度

• 留白是设计元素，而非空缺

动效

• 动效必须：

  • 有目的
  • 稀疏
  • 高冲击力

• 优先采用：

  • 一段强有力的入场序列
  • 少量有意义的悬停状态

• 避免装饰性的微动效滥用

质感与深度

在合适时使用：

• 噪点 / 颗粒叠加
• 渐变网格
• 分层半透明
• 自定义边框或分隔线
• 带有叙事意图的阴影（而非默认阴影）

---

5. 实现标准

代码要求

• 简洁、可读且模块化
• 无死样式
• 无未使用的动画
• 语义化 HTML
• 默认无障碍（对比度、焦点、键盘）

框架指南

• HTML/CSS：优先使用原生特性、现代 CSS

• React：函数组件、可组合样式

• 动画：

  • CSS 优先
  • 仅在合理时使用 Framer Motion

复杂度匹配

• 极繁主义设计 → 复杂代码（动画、图层）
• 极简主义设计 → 极其精确的间距与排版

不匹配 = 失败。

---

6. 必需输出结构

生成前端作品时：

1. 设计方向摘要

• 美学名称
• DFII 评分
• 关键灵感（概念性，而非视觉抄袭）

2. 设计系统快照

• 字体（附理由）
• 颜色变量
• 间距节奏
• 动效理念

3. 实现

• 完整可运行代码
• 仅在意图不明显处添加注释

4. 验证

说明检查了哪些主要操作、响应式宽度、键盘 / 焦点行为、对比度以及加载 / 错误状态。包含观察到的结果和仍存在的缺口。

---

7. 避免

• 仅为显得与众不同而替换既有组件。
• 在未检查许可和产品限制的情况下下载字体或视觉素材。
• 为追求美学效果而隐藏控件、削弱对比度或增加动效。
• 在未进行交互检查的情况下，将渲染出的截图称为可用或可投产。

---

8. 与其他技能的集成

• page-cro → 布局层级与转化流程
• copywriting → 排版与信息节奏
• marketing-psychology → 视觉说服与偏见对齐
• branding → 视觉识别一致性
• ab-test-setup → 变体安全的设计系统

---

9. 操作者检查清单

在最终确定输出之前：

• 已说明清晰的美学方向
• 主观设计判断与观察到的可用性检查已分开
• 一个令人难忘的设计锚点
• 品牌和既有组件惯例得到尊重
• 代码与设计野心相匹配
• 已记录键盘、焦点、响应式布局和性能检查

---

10. 需要询问的问题（如有必要）

1. 从情感上说，这是给谁用的？
2. 这应该让人感到可信、兴奋、平静，还是具有挑衅性？
3. 令人难忘还是清晰更重要？
4. 这能否扩展到其他页面 / 组件？
5. 用户在前 3 秒应该感受到什么？

---

何时使用

用于新页面、组件或有明确主要用户操作的有意视觉焕新。对于孤立的缺陷修复，保留周围设计，除非需要更改才能解决该缺陷。

输入与示例

收集现有设计系统、目标设备、内容、框架和验收标准。示例：一个 JSON 导入界面必须在 390px 视口上暴露错误并给出有用的下一步操作。复用应用的表单控件，将错误与输入关联，对长摘要进行换行，并保留清晰的待处理 / 成功状态。验证键盘提交，以及编辑输入会移除过期的成功状态。预期：完整工作流保持可用，且页面无需横向滚动。

局限性

• 视觉上的独特性并不能证明可用性或转化效果。
• 截图无法验证键盘顺序、异步行为、屏幕阅读器输出或网络故障状态。
• 减少动态效果的偏好设置、本地化和真实内容长度都可能改变设计；在产品需要的地方对这些进行测试。