> For the complete documentation index, see [llms.txt](https://zhouhao4221.gitbook.io/haiqing-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zhouhao4221.gitbook.io/haiqing-docs/02-design/ui-design-with-ai.md).

# 用 AI 从参考风格到自己的 UI 设计

## 核心思路

做 UI 设计时，很少有人从一张白纸开始。更常见的起点是：喜欢某个产品的风格、收集了一些参考截图、或者脑子里有一个模糊的感觉。

AI 能帮你完成的，是把这些输入转化为可用的设计——但前提是你知道怎么把"感觉"或"参考图"变成 AI 能执行的语言。

本文覆盖两种起点：

* **从设计参考图出发**：手上有一张完整的设计图，想以它为基础做自己的版本
* **从风格感觉出发**：只有模糊的喜好和灵感，需要先提炼再生成

***

## 路径一：从设计参考图出发

有完整参考图时，信息量更大，也更容易陷入"直接复制"的误区。正确的方式是把参考图当作设计系统的载体来分析，提取规律而不是像素。

### 第一步：读懂参考图的设计系统

对着参考图，逐层拆解：

**色彩层**

```
- 主色是什么色值？（用取色器获取）
- 背景色、面板色、边框色各是什么？
- 文字有几层颜色？主文字、辅助文字、禁用文字分别是什么？
- 强调色、错误色、成功色是什么？
- 整体用了几种颜色？（通常不超过 5 种）
```

**排版层**

```
- 字体是什么类型？（衬线 / 无衬线 / 等宽）
- 有几档字号？最小和最大分别是多少？
- 正文字号和行高是多少？
- 粗体用在哪里？用了几种字重？
```

**空间层**

```
- 最小间距单位是多少？（通常是 4px 或 8px 的倍数）
- 组件内边距是多少？（以按钮为基准）
- 组件之间的间距是多少？
- 模块之间的间距是多少？
```

**形状层**

```
- 圆角是多少？不同组件是否一致？
- 层级是用阴影还是边框还是背景色差来表达？
- 卡片有没有边框？
```

**组件层**

```
- 页面里出现了哪些组件？（列出清单）
- 每个组件有哪些状态？（默认 / 悬停 / 禁用 / 选中）
- 图标是什么风格？线性还是面性？粗细如何？
```

### 第二步：用 AI 辅助提取

把参考图（截图）上传给 AI，配合这个提示让它帮你提取：

```
这是一张 UI 设计参考图。请帮我分析它的设计系统，按以下维度输出：

1. 色彩：识别主色、背景色、文字色、边框色、语义色，尽量给出估算色值
2. 排版：字体类型、字号档位、行高、字重使用规律
3. 间距：最小间距单位推算、组件内边距、组件间距
4. 形状：圆角大小、层级表达方式（阴影 / 边框 / 背景色差）
5. 组件：列出图中出现的所有 UI 组件

对不确定的地方，说明你的推断依据。
```

AI 的分析不会完全精确，但能帮你快速建立对这个设计系统的整体认知，再由你校正细节。

### 第三步：决定借鉴什么、改变什么

参考图是别人产品的设计，直接照搬会有两个问题：一是版权风险，二是它的设计决策是为别人的产品服务的，不一定适合你。

用三个问题过滤：

```
保留：这个参考里哪些规律我完全认同，直接沿用？
（通常是：间距节奏、层级逻辑、信息密度）

调整：哪些地方我喜欢思路但需要改变具体值？
（通常是：颜色换成自己的品牌色、字号适应自己的内容密度）

替换：哪些地方不适合我的产品，需要换一个方案？
（通常是：组件风格、交互模式、特定视觉元素）
```

### 第四步：生成自己的版本

把提取的设计系统 + 你的调整决策，组织成提示：

```
我分析了一个参考设计，提取了以下设计系统：

色彩：
- 主色：[估算色值或描述]
- 背景：[值]
- 边框：[值]
- 文字（主 / 次）：[值]

间距基准：[值]px
圆角：[值]px
层级表达：[阴影 / 边框 / 背景色差]

我的调整：
- [列出保留 / 调整 / 替换的决策]

请基于以上设计系统，生成 [组件名或页面名]。
这是衍生设计，不是复制参考图。
```

***

## 路径二：从风格感觉出发

## 第一步：提炼参考风格

拿到参考（截图、产品链接、心情板）之后，不要直接扔给 AI 说"做一个类似的"。这样 AI 只会模仿表面，你也不清楚自己真正喜欢的是什么。

**正确做法：拆解参考，找出你真正喜欢的是什么。**

对着参考逐项回答：

```
整体感受：这个设计给你的第一感觉是什么？（克制 / 活泼 / 高级 / 温暖...）

色彩：
- 主色是什么？用在哪里？
- 背景是纯白还是带一点灰？
- 整体色调偏冷还是偏暖？
- 用了几种颜色？

排版：
- 字体是衬线还是无衬线？
- 字号变化大还是小？
- 文字间距宽松还是紧凑？

空间：
- 内容密度高还是低？
- 留白多还是少？
- 组件之间的间距是否规律？

形状：
- 圆角大还是小？
- 卡片边界是阴影还是边框还是无边界？

你不喜欢的部分：
- 参考里有哪些你不想要的？
```

完成这个拆解后，你已经有了一份"风格提取清单"，而不是模糊的"我想要像 XX 一样的风格"。

***

## 第二步：定义自己的风格

参考是起点，不是终点。从参考的拆解中，筛选出你想保留的、想改变的、想加入的。

**保留**：哪些地方你完全认同，直接沿用 **改变**：哪些地方喜欢思路但不喜欢具体执行 **加入**：你的产品有什么特别之处，需要在风格里体现

用这三个维度整理出你的风格决策，填入 `ui-style-guide.md`。这一步不需要精确数值，先用描述词占位：

```
主色：深蓝偏靛，比参考更沉稳一点
背景：极浅灰，不是纯白
圆角：比参考更小，4px 左右
留白：保留参考的宽松感，但内容区更紧凑
不要：参考里的彩色标签，改用灰度
```

***

## 第三步：用 AI 生成初稿

风格决策确定后，开始生成。这一阶段的目标是快速拿到可以讨论的视觉稿，不追求精确。

**提示结构：**

```
我正在设计一个 [产品类型]，目标用户是 [用户描述]。

风格参考：[产品名或简短描述，如"类似 Linear 的克制感"]

我的风格调整：
- [列出你的保留 / 改变 / 加入]

请生成 [组件名或页面名]，要求：
- [具体约束，如：无阴影、边框代替层级]
- [可选：提供一段现有组件代码作为风格基准]

先给一个初稿，不需要完美，我会在此基础上调整。
```

***

## 第四步：迭代收敛

初稿出来后，进入逐步收敛的过程。每一轮只调整一件事，原因是：改多了不知道哪个改动起了作用，下次遇到同样问题还是没有答案。

**迭代节奏：**

```
第一轮：整体比例和布局对不对？
第二轮：色彩关系对不对？
第三轮：字体大小和层级对不对？
第四轮：间距和密度对不对？
第五轮：细节——圆角、边框、图标
```

每轮的提示格式：

```
整体方向对了。现在只调整 [一个具体问题]：
- 问题：[描述哪里不对]
- 期望：[具体说明，不要说"更好看"]
- 不变：其他所有部分保持不变
```

***

## 第五步：沉淀为风格规范

当你对某个组件的输出满意了，把这次确定下来的决策记录到：

* **`ui-style-guide.md`**：把描述词换成精确值（"深蓝偏靛" → `#1E3A5F`）
* **`design-decisions.md`**：记录为什么做这个选择，特别是放弃了什么

这样下次做新组件或新页面时，AI 有具体数值可以遵守，不需要重新对齐风格。

***

## 常见卡点

**"说不清楚自己想要什么风格"** 不用先想清楚。先收集 5–10 个你觉得还不错的参考，用第一步的拆解方法逐一过一遍，共同点就是你的风格直觉。

**"AI 生成的和参考差太多"** 通常是因为描述词太模糊。"简洁"对 AI 没有意义，"无阴影、1px 边框、背景 #F5F5F5"才有意义。把感受词换成视觉属性词。

**"改了很多轮还是不对"** 停下来，重新做第一步。多数情况下不是 AI 的问题，而是你还没想清楚自己真正想要什么。把"不对"拆解成具体维度，找到根本分歧在哪里。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://zhouhao4221.gitbook.io/haiqing-docs/02-design/ui-design-with-ai.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
