AI 生成网页为什么总爱用蓝紫渐变

AI 生成 UI 的蓝紫渐变从哪里来

Vibe Coding（用自然语言驱动 AI 快速生成代码和界面的开发方式）流行之后，很多人会发现一个重复出现的现象：让 AI（人工智能）生成一个网页、SaaS 落地页、登录页或后台界面，只要没有明确指定颜色，它很容易给出蓝色、靛蓝、紫色这一组视觉方案。

典型结果通常长这样：

<button class="rounded-lg bg-indigo-500 px-4 py-2 text-white hover:bg-indigo-600">
  Get Started
</button>

<section class="bg-gradient-to-br from-indigo-50 via-white to-purple-50">
  <div class="rounded-2xl border border-indigo-100 shadow-sm">
    ...
  </div>
</section>

按钮是 indigo-500，背景从浅蓝过渡到浅紫，卡片边框带一点靛蓝，标题再叠一层蓝紫渐变文字。单看并不难看，但大量 AI 生成页面都采用同一套视觉语言后，它会迅速变成一种“默认 AI 味”。

蓝紫渐变本身没有问题。问题在于：当一个工具在没有上下文的情况下反复选择同一种风格，设计就从“为目标服务”变成了“复用数据里最常见的样子”。

Tailwind CSS 和 indigo-500 的路径依赖

Tailwind CSS 是一个 utility-first CSS framework（实用优先型 CSS 框架，CSS 是 Cascading Style Sheets，层叠样式表）。它不像传统 CSS 那样先写一堆语义化类名，再去样式文件里定义规则，而是直接通过原子类组合界面。

例如：

<button class="bg-indigo-500 text-white px-4 py-2 rounded-lg">
  Submit
</button>

这里的 bg-indigo-500 表示背景色使用 Tailwind 调色板里的 indigo 色阶，500 通常代表中等亮度和饱和度，适合做主按钮色。

早期 Tailwind 生态中的大量示例按钮、登录页、落地页模板都喜欢使用 indigo-500。这个选择有现实原因：

一个颜色被大量教程、组件库、开源模板和代码片段反复使用后，它就不只是一个设计选择了，而会变成训练语料里的高频模式。

整个循环大致是这样：

flowchart LR
    A[Tailwind 生态中的示例样式] --> B[教程和技术文章复用]
    B --> C[开源项目和 UI 模板沿用]
    C --> D[进入大模型训练语料]
    D --> E[AI 生成 UI 时更常选择蓝紫方案]
    E --> F[更多 AI 生成页面发布到网络]
    F --> C

大语言模型（LLM，Large Language Model）并不是在判断“蓝紫色一定最适合这个产品”，而是在根据上下文预测高概率输出。输入是“生成一个现代 SaaS 落地页”，模型在训练数据里见过太多蓝紫按钮、渐变背景和圆角卡片，于是这套组合就容易被当成安全答案。

可以把它理解成一个条件概率问题：

P(蓝紫渐变 | 现代网页 + SaaS + Tailwind + landing page) 很高

当提示词没有提供品牌调性、目标用户、行业属性、情绪方向和视觉禁区时，模型就会退回到最常见的样式分布里。

语料高频不等于设计最优

AI 生成 UI 的趋同，不只体现在蓝紫渐变上。很多常见设计元素也有类似问题。

这些结果不能简单理解为 AI “没有创意”。更准确地说，模型擅长复现训练数据里的统计规律，但不会天然区分“高频出现”与“真正合适”。

设计判断需要回答的问题通常更具体：

• 产品希望传递可靠、温暖、专业、活泼，还是高端？
• 用户是在工作场景中长时间使用，还是只浏览一次活动页？
• 主色是否和品牌、行业、竞品形成区分？
• 渐变承担的是背景氛围、状态提示，还是核心品牌识别？
• 文字、按钮和背景是否满足可访问性要求？

如果这些条件没有进入提示词或设计系统，AI 就只能用训练语料里最常见的组合来填空。

蓝紫渐变什么时候可以用，什么时候应该避开

蓝紫渐变不是“错误配色”。在某些场景里，它仍然合理。

判断一个颜色方案是否合适，不是看它是否流行，而是看它是否匹配产品目标。蓝紫适合表达冷静、科技、探索、未来感，但不适合承担所有产品的默认视觉。

用约束性提示词打破默认输出

很多人让 AI 做设计时，会写类似这样的提示：

生成一个现代、简洁、有高级感的 SaaS 落地页。

这个提示过于宽泛。模型会把“现代”“简洁”“高级感”映射到训练数据里最常见的 SaaS 模板，于是蓝紫渐变、圆角卡片、线性图标又会出现。

更可控的写法是给出约束：哪些不要用，应该转向什么风格，输出结果要遵守哪些设计令牌。

为一款面向独立咖啡店的库存管理工具生成落地页 UI。

色彩限制：
- 不要使用 blue、indigo、violet、purple 作为主色或渐变主色。
- 不要使用 from-indigo-*、to-purple-* 这类 Tailwind 渐变组合。
- 主按钮不要使用蓝紫色。

视觉方向：
- 使用温暖、可靠、轻量的色彩。
- 主色可以从咖啡棕、奶油白、柔和橙色中选择。
- 页面背景保持低饱和，内容区域需要有足够对比度。

组件限制：
- 卡片圆角不要使用 8px 或 16px。
- 图标优先使用填充图标，不使用默认线性图标。
- 渐变只能作为局部氛围，不要覆盖大面积内容背景。

输出要求：
- 给出色板。
- 给出 Tailwind CSS 类名。
- 给出按钮、卡片、背景三个组件的样式。

约束性提示词的关键不是简单说“不要普通”，而是同时提供三类信息：

如果只写“更有创意”，模型可能会给出更夸张的蓝紫渐变；如果写清楚禁区和替代方向，结果才会稳定偏离默认模板。

把颜色变成设计令牌，而不是让 AI 随机挑色

想让 AI 生成的界面更可控，最好不要让它每次都直接决定颜色。更稳的方式是先定义设计令牌，再让 AI 在令牌范围内组合页面。

设计令牌可以写成 CSS 变量：

:root {
  --color-bg: #fff8ef;
  --color-surface: #ffffff;
  --color-primary-50: #fff1df;
  --color-primary-100: #f8d8b4;
  --color-primary-500: #c86a3d;
  --color-primary-600: #a8522d;
  --color-text: #2f241d;
  --color-muted: #7a685d;

  --radius-card: 14px;
  --radius-button: 999px;

  --shadow-card: 0 10px 30px rgba(68, 48, 35, 0.08);
}

也可以放进 Tailwind 配置中：

// tailwind.config.ts
export default {
  theme: {
    extend: {
      colors: {
        brand: {
          bg: "#fff8ef",
          surface: "#ffffff",
          50: "#fff1df",
          100: "#f8d8b4",
          500: "#c86a3d",
          600: "#a8522d",
          text: "#2f241d",
          muted: "#7a685d",
        },
      },
      borderRadius: {
        card: "14px",
        button: "999px",
      },
      boxShadow: {
        card: "0 10px 30px rgba(68, 48, 35, 0.08)",
      },
    },
  },
};

再把这些令牌交给 AI：

只能使用以下设计令牌生成页面，不要新增 blue、indigo、purple 相关颜色：

颜色：
- bg: #fff8ef
- surface: #ffffff
- primary-500: #c86a3d
- primary-600: #a8522d
- text: #2f241d
- muted: #7a685d

圆角：
- card: 14px
- button: 999px

阴影：
- card: 0 10px 30px rgba(68, 48, 35, 0.08)

请生成一个登录页，包括标题、表单、主按钮、辅助链接和右侧插画区域。

这样做的好处很直接：AI 负责布局和代码组合，人负责定义视觉边界。模型不再从庞大的默认样式库里随机抽取，而是在一个明确的设计系统中工作。

用真实参考生成更自然的渐变

渐变容易显得模板化，往往不是因为渐变不好，而是色彩来源太单一。自然环境、摄影作品、品牌材料、实体产品都可以提供更丰富的色彩关系。

常见参考可以这样转化：

一个可控流程是：

flowchart LR
    A[收集真实参考] --> B[提取 3 到 5 个关键色]
    B --> C[调整亮度和饱和度]
    C --> D[检查文字与背景对比度]
    D --> E[生成 CSS 变量或 Tailwind 色板]
    E --> F[让 AI 基于色板生成组件变体]
    F --> G[人工筛选并固化到设计系统]

让 AI 做二次优化时，可以这样写：

基于以下渐变色板生成 UI 变体，不要改变色相方向：

渐变：
- 起点：#f6b27a
- 中点：#ffe0b5
- 终点：#fff8ef

任务：
- 生成 3 组按钮状态：default、hover、disabled。
- 生成 3 组卡片背景：普通卡片、强调卡片、提示卡片。
- 生成 2 组页面背景：营销页背景、表单页背景。

限制：
- 不要加入 blue、indigo、purple。
- 所有正文文字与背景需要满足 WCAG AA 对比度。
- 输出 CSS 变量和 Tailwind class 示例。

WCAG（Web Content Accessibility Guidelines，网页内容无障碍指南）AA 是常用的可访问性对比度标准。颜色方案不只是视觉风格问题，也会影响阅读和操作。尤其是渐变背景上放文字时，需要检查浅色区域是否会让文字对比度不足。

生成结果需要做的设计检查

AI 给出的 UI 初稿可以作为起点，但不能直接当成设计系统。每次拿到生成结果后，至少检查这些点：

如果发现页面里到处都是这类组合，就说明模型回到了默认路径：

bg-gradient-to-br from-indigo-50 to-purple-100
text-transparent bg-clip-text bg-gradient-to-r from-indigo-600 to-purple-600
bg-indigo-500 hover:bg-indigo-600
border-indigo-100
shadow-purple-100

可以直接要求它重写：

重写这段 Tailwind UI，移除所有 indigo、blue、purple、violet 相关类名。
使用已有 brand 色板替代，不要新增颜色。
保留布局结构，只调整色彩、按钮状态、卡片层级和可访问性对比度。

更可靠的 AI UI 工作流

把 AI 当成“界面生成器”时，它容易输出平均化结果；把 AI 放进明确流程里，它更适合承担重复劳动。

flowchart TD
    A[明确产品气质和用户场景] --> B[定义色彩禁区与视觉方向]
    B --> C[建立设计令牌]
    C --> D[让 AI 生成页面或组件]
    D --> E[检查对比度、状态、层级和一致性]
    E --> F{是否符合设计目标}
    F -- 否 --> B
    F -- 是 --> G[沉淀为组件库或模板]

这个流程里，人负责判断方向，AI 负责生成候选方案和代码细节。只要色彩、圆角、阴影、图标和组件状态都有明确约束，生成结果就不容易掉回蓝紫渐变模板。

蓝紫渐变不是问题，默认使用才是问题

AI 生成网页总爱用蓝紫渐变，本质上是工具、教程、开源代码和训练语料共同形成的路径依赖。Tailwind CSS 生态中的 indigo-500 只是一个典型入口，真正起作用的是“高频样式被继续复用，高频复用又被模型继续学习”的循环。

设计里没有永远正确的颜色。蓝紫可以表达科技感，暖色可以表达亲近感，中性色可以表达稳定感，自然渐变可以带来更真实的氛围。关键不在于避开某一种颜色，而在于让每个视觉选择都有明确理由。

AI 可以生成页面，但不能替代设计判断。把提示词写成约束，把颜色整理成设计令牌，把渐变建立在真实参考上，再用可访问性和组件一致性做检查，生成结果才会从“像 AI 做的”变成“符合产品目标的界面”。