1. AI 做 UI 的“AI 味”到底从哪来
1.1 先搞清楚“AI 味”是什么
你肯定见过那种界面：紫色渐变背景、圆角卡片、Inter 字体、一堆无意义的留白、图标风格不统一、按钮颜色像是从调色盘里随机抓的。这就是典型的“AI 味”。
我用 Claude Code 和各类 AI 编程助手做过不下二十个界面项目，从后台管理系统到移动端 App 原型都试过。刚开始觉得效率真高，一句话就能生成整个页面。但跑多了就发现一个问题：AI 生成的 UI 有一种高度可辨识的“平均脸”特征。就像所有人用同一套滤镜自拍，单看还行，放一起就露馅了。
这种“AI 味”不是模型能力不够，恰恰相反，是因为模型太“平均”了。大模型在训练时见过海量的界面截图和前端代码，它学到的是所有界面的“最大公约数”——最安全的配色、最常见的布局、最不会出错的间距。结果就是每个输出都“还行”，但每个输出都“差不多”。
1.2 三个核心成因拆解
我把这个问题拆成三层来看，每一层的解决思路完全不同。
第一层：训练数据的均值回归。模型见过的 UI 越多，输出就越趋近于统计意义上的“平均 UI”。这跟推荐系统推热门内容是一个道理——最安全的选择就是最平庸的选择。你让 AI 设计一个登录页，它给你的永远是居中卡片、顶部 Logo、两个输入框、一个主色按钮。功能上没毛病，但放在一百个产品里你根本认不出哪个是你的。
第二层：缺乏设计约束。你给 AI 的提示词通常是“做一个电商后台的订单列表页”，但你没有告诉它：品牌主色是什么、圆角用几像素、阴影层级怎么分、表格行高是多少、空状态怎么处理。AI 没有这些约束，就只能自己“编”，而它编出来的东西就是训练数据里最常见的那些值。
第三层：缺少品味判断。这是最关键的。AI 不知道什么是“好设计”，它只知道什么是“常见设计”。你让它调整间距，它可能把 16px 改成 24px，但它不理解为什么这个场景下 20px 比 24px 更合适。品味这件事，目前大模型还真的不太行。
注意：不要指望换一个更强的模型就能解决“AI 味”问题。GPT-5 也好，Claude 4 也好，底层逻辑是一样的——它们都在做概率预测，不是在做出设计决策。
1.3 为什么 Google 的“品味优先”思路值得关注
Google 最近在设计工具链上的一系列动作，核心思路就一个：把品味从模型里抽出来，变成可配置的约束。他们内部推行的 DESIGN.md 规范就是一个典型例子——用一份结构化的设计描述文件，把品牌色、字体阶梯、间距系统、组件规范全部写清楚，然后让 AI 基于这份文件来生成 UI。
这个思路的本质是：不要让 AI 猜你的品味，直接告诉它你的品味是什么。听起来很简单，但实操下来效果差异巨大。我拿同一个提示词分别用“裸提示”和“带 DESIGN.md 约束”跑了两轮，后者生成的界面在一致性上至少提升了两个档次。
Claude Code 在这方面的适配也很有意思。它支持在项目根目录放一个CLAUDE.md文件来定义项目规范，你可以把设计系统的关键约束写进去，这样每次生成代码时它都会自动参考。这个机制跟 Google 的 DESIGN.md 思路异曲同工。
2. DESIGN.md 到底是什么，为什么它能治“AI 味”
2.1 一份设计约束文件的基本结构
DESIGN.md 不是什么官方标准，它更像是一种约定俗成的做法：用 Markdown 格式写一份设计系统说明，放在项目根目录，让 AI 工具在生成代码时自动读取并遵守。
我自己的 DESIGN.md 通常包含这几个部分：
# Design System ## Colors - Primary: #2563EB - Primary Hover: #1D4ED8 - Background: #F8FAFC - Surface: #FFFFFF - Text Primary: #0F172A - Text Secondary: #64748B - Border: #E2E8F0 - Danger: #DC2626 - Success: #16A34A ## Typography - Font Family: "Inter", system-ui, sans-serif - Heading 1: 32px / 1.25 / 700 - Heading 2: 24px / 1.33 / 600 - Body: 14px / 1.5 / 400 - Caption: 12px / 1.33 / 400 ## Spacing - Base unit: 4px - Scale: 4, 8, 12, 16, 24, 32, 48, 64 ## Border Radius - Small: 4px - Medium: 8px - Large: 12px - Full: 9999px ## Shadows - Card: 0 1px 3px rgba(0,0,0,0.1) - Dropdown: 0 4px 6px rgba(0,0,0,0.07) - Modal: 0 10px 15px rgba(0,0,0,0.1) ## Component Rules - Buttons: height 36px, padding 0 16px, radius 8px - Inputs: height 36px, border 1px solid Border, radius 8px - Cards: padding 24px, radius 12px, shadow Card - Tables: row height 48px, header bg Background这份文件不需要多复杂，关键是把 AI 容易“自由发挥”的地方全部锁死。颜色、字号、间距、圆角、阴影——这五个维度定死了，界面的“AI 味”至少去掉一半。
2.2 为什么 Markdown 格式比 JSON 更好
你可能会问：为什么不直接写一份 JSON 配置或者 Tailwind config？原因很简单：AI 读 Markdown 比读 JSON 理解得更准。
Markdown 有语义结构，标题层级天然表达了信息的从属关系。AI 在解析## Colors下面的列表时，能清楚知道这些是颜色定义。而 JSON 虽然结构化更强，但 AI 在生成代码时容易把配置值和实际使用场景脱节。
另外，Markdown 对人类也友好。你团队里的设计师可以直接改这份文件，不需要懂任何代码。改完提交，下次 AI 生成代码时自动生效。这个协作流程比让设计师去改 Tailwind config 顺畅太多了。
2.3 跟 Claude Code 的配合方式
Claude Code 默认会读取项目根目录的CLAUDE.md。你可以把 DESIGN.md 的内容直接写进去，或者用引用方式：
# Project Rules ## Design See @DESIGN.md for full design system. All UI code must: - Use colors from DESIGN.md only - Use spacing values from the 4px scale - Never use arbitrary values like `mt-[13px]` - Always use the component rules defined in DESIGN.md实测下来，Claude Code 在生成组件时会主动引用这些约束。比如你让它做一个订单卡片，它会自动用rounded-xl（对应 12px）、p-6（对应 24px）、shadow-card，而不是随机选一个rounded-lg或p-4。
提示：如果你用的是其他 AI 编程工具（比如 Cursor、Windsurf），它们也支持类似的规则文件机制。Cursor 用
.cursorrules，Windsurf 用.windsurfrules，思路完全一样。
3. 实操：从零搭建一套“去 AI 味”的 UI 生成流程
3.1 第一步：提取你现有的设计基因
如果你已经有产品在跑，最省事的做法是从现有界面里提取设计基因。打开你的产品，用浏览器 DevTools 检查几个核心页面，把以下信息记下来：
- 主色、辅助色、危险色、成功色的实际色值
- 标题、正文、辅助文字的字号和字重
- 卡片、按钮、输入框的圆角和内边距
- 页面主要区块之间的间距
如果你还没有产品，那就从零定义一套。我的建议是：不要超过 5 个颜色、3 档字号、5 档间距。选择越多，AI 越容易乱用。
3.2 第二步：写一份最小可用的 DESIGN.md
不要一上来就写几百行。先写最核心的 50 行，覆盖颜色、字体、间距、圆角、阴影这五块。然后拿一个简单页面测试一下效果。
我常用的测试提示词是这样的：
参考 DESIGN.md 中的设计规范，生成一个用户列表页面。 包含：搜索栏、表格、分页器、空状态。 使用 React + Tailwind CSS。如果生成的代码里出现了 DESIGN.md 中没有定义的颜色值或间距值，说明你的约束还不够明确，需要补充“禁止使用未定义值”这类规则。
3.3 第三步：建立组件级别的约束
页面级别的约束只能保证大方向不跑偏，真正要消除“AI 味”，得深入到组件级别。我在 DESIGN.md 里会额外加一段组件规则：
## Component Specifications ### Button - Primary: bg Primary, text white, hover Primary Hover - Secondary: bg white, border Border, text Text Primary - Ghost: bg transparent, text Text Secondary, hover bg Background - All buttons: height 36px, padding 0 16px, radius 8px, font 14px/500 ### Input - Height 36px, padding 0 12px, border 1px solid Border, radius 8px - Focus: border Primary, ring 2px Primary/20 - Placeholder: text Text Secondary ### Card - Padding 24px, radius 12px, shadow Card, bg Surface - Title: 16px/600, margin-bottom 16px有了这些规则，AI 生成组件时就不会自由发挥了。它知道按钮必须是 36px 高，输入框聚焦时必须有 ring，卡片的标题必须是 16px/600。
3.4 第四步：用 Claude Code 批量生成并校验
Claude Code 有一个很好用的能力：你可以让它生成代码后自己检查是否符合 DESIGN.md。我常用的提示词模板：
生成一个订单详情页组件。 生成完成后，逐项检查是否符合 DESIGN.md 中的规范。 如果发现不符合的地方，直接修正并说明修改了什么。这个“生成-自检-修正”的循环非常有效。实测下来，第一轮生成通常有 2-3 处不符合规范，自检后基本能全部修正。
3.5 第五步：建立视觉回归测试
这一步是进阶操作，但强烈建议做。用 Playwright 或 Cypress 对核心页面截图，每次 AI 生成新代码后自动对比截图差异。如果差异超过阈值，说明 AI 可能引入了不符合设计规范的改动。
// playwright 视觉回归示例 import { test, expect } from '@playwright/test'; test('order list page visual regression', async ({ page }) => { await page.goto('/orders'); await page.waitForLoadState('networkidle'); await expect(page).toHaveScreenshot('order-list.png', { maxDiffPixelRatio: 0.01, }); });这个机制能帮你兜住 AI 的“手滑”——有时候它会在你不注意的地方改了一个颜色或间距，肉眼很难发现，但截图对比能立刻暴露。
4. 常见问题与排查技巧实录
4.1 AI 不遵守 DESIGN.md 怎么办
这是最常见的问题。原因通常有三个：
原因一：DESIGN.md 太长，关键信息被淹没。如果文件超过 200 行，AI 的注意力会分散。解决办法是把最核心的约束放在文件最前面，用加粗或引用块突出。
原因二：约束不够具体。“使用合适的间距”这种描述等于没写。必须写成“所有间距必须是 4 的倍数，常用值为 8/12/16/24/32”。
原因三：提示词里没有明确引用。你需要在每次生成时都提醒 AI 参考 DESIGN.md。我通常会在提示词开头就写“严格遵守 DESIGN.md 中的所有规范”。
4.2 生成的界面还是“一眼 AI”怎么调
如果约束都加了但还是有 AI 味，问题可能出在布局层面。AI 倾向于使用最安全的布局：居中、等分、对称。你可以通过以下方式打破这种惯性：
- 在 DESIGN.md 里定义“布局例外规则”，比如“数据密集型页面使用左对齐紧凑布局，不使用居中卡片”
- 在提示词里明确指定布局方式，比如“使用左右分栏布局，左侧固定 240px 侧边栏，右侧自适应”
- 提供参考截图，让 AI 模仿特定布局结构
我试过给 AI 一张 Linear 或 Notion 的截图作为参考，生成的界面立刻就不一样了。AI 对视觉参考的理解能力比纯文字描述强得多。
4.3 多页面之间风格不一致怎么处理
这是 DESIGN.md 最大的价值所在。没有约束时，AI 生成十个页面可能有十种风格。有了 DESIGN.md，所有页面共享同一套颜色、字体、间距、组件规则，风格自然统一。
如果还是出现不一致，检查一下是不是有些页面用了不同的提示词模板。统一提示词模板和统一 DESIGN.md是保证一致性的两个关键。
4.4 常见问题速查表
| 问题现象 | 可能原因 | 解决方法 |
|---|---|---|
| 颜色随机出现 | DESIGN.md 未定义该颜色 | 补充颜色定义，加“禁止使用未定义颜色”规则 |
| 间距忽大忽小 | 未指定间距系统 | 定义 4px 基础单位和常用值列表 |
| 圆角不统一 | 未指定圆角规则 | 定义 3-4 档圆角值并指定使用场景 |
| 字体层级混乱 | 未指定字号阶梯 | 定义 H1-H4、Body、Caption 的字号和字重 |
| 组件样式不一致 | 未定义组件规范 | 在 DESIGN.md 中增加组件级别约束 |
| AI 忽略约束 | 提示词未引用 | 每次生成时明确要求参考 DESIGN.md |
| 布局千篇一律 | 缺少布局规则 | 定义不同场景的布局模式 |
4.5 几个我踩过的坑
坑一：DESIGN.md 写得太细，AI 反而不会用了。我曾经写过一份 500 行的设计规范，结果 AI 生成时频繁出错。后来精简到 80 行，效果反而更好。约束要精准，不要贪多。
坑二：忘了定义暗色模式。如果你的产品支持暗色模式，一定要在 DESIGN.md 里定义两套颜色值。否则 AI 会自己“发明”暗色配色，结果惨不忍睹。
坑三：没有版本控制。DESIGN.md 是活文档，会随着产品迭代不断修改。一定要用 Git 管理，每次修改都记录原因。否则过两个月你都不记得为什么某个颜色被改过。
坑四：设计师和前端各写一份。这会导致两份规范逐渐分叉。正确做法是只有一份 DESIGN.md，设计师和前端共同维护，AI 也读这一份。
5. 进阶玩法：让 AI 学会你的品味
5.1 用示例驱动代替规则驱动
规则能解决 80% 的问题，但剩下 20% 的“品味”很难用规则描述。这时候可以用示例驱动的方式：在 DESIGN.md 里放几个“标杆组件”的完整代码，让 AI 模仿。
比如你有一个特别满意的按钮组件，就把它的完整代码贴在 DESIGN.md 里，标注“所有按钮必须参照此实现”。AI 在生成新按钮时会自动对齐这个标杆。
5.2 建立“反模式”清单
除了告诉 AI 什么是对的，还要告诉它什么是错的。我在 DESIGN.md 里会专门加一段“禁止事项”：
## Anti-Patterns (Never Do These) - Never use purple gradients - Never use more than 2 font families - Never use border-radius larger than 16px on cards - Never use pure black (#000000) for text - Never use more than 3 levels of shadow - Never center-align body text longer than 2 lines这份清单是我从多次“翻车”中总结出来的。每次看到 AI 生成我不想要的效果，就把它加进禁止列表。久而久之，AI 的输出就越来越接近我的品味。
5.3 用 Claude Code 做设计审查
Claude Code 不仅能生成代码，还能做代码审查。你可以把一段 UI 代码丢给它，让它对照 DESIGN.md 逐项检查：
请审查以下组件代码，对照 DESIGN.md 检查： 1. 颜色是否全部来自定义列表 2. 间距是否全部是 4 的倍数 3. 圆角是否在允许范围内 4. 字体是否使用了定义的字号和字重 5. 是否有任何禁止事项被违反 输出格式：逐项列出检查结果，不符合的给出修正建议。这个用法特别适合团队协作——新人提交的代码可以先让 AI 过一遍，减少人工审查的负担。
5.4 持续迭代你的 DESIGN.md
DESIGN.md 不是写完就完了。每次你发现 AI 生成的结果不符合预期，就问自己：是规则没写清楚，还是规则里没覆盖？然后把缺失的规则补进去。
我自己的 DESIGN.md 从最初的 30 行迭代到了现在的 120 行，每一条都是踩坑踩出来的。这个过程本身就是把“品味”显性化的过程——你越清楚自己要什么，AI 就越能帮你实现。
6. 工具链选型与配置参考
6.1 AI 编程工具对比
| 工具 | 规则文件 | 设计约束支持 | 适合场景 |
|---|---|---|---|
| Claude Code | CLAUDE.md | 强，支持引用外部文件 | 全栈项目，复杂组件生成 |
| Cursor | .cursorrules | 中，需手动配置 | 前端项目，快速迭代 |
| Windsurf | .windsurfrules | 中，界面友好 | 团队协作，可视化配置 |
| GitHub Copilot | 无原生支持 | 弱，依赖注释 | 代码补全，小片段生成 |
Claude Code 在设计约束方面支持最好，因为它能读取项目中的任意文件作为上下文。你可以把 DESIGN.md、组件库代码、甚至 Figma 导出的设计 token 都喂给它。
6.2 推荐的项目结构
project/ ├── CLAUDE.md # AI 行为规则 ├── DESIGN.md # 设计系统规范 ├── src/ │ ├── components/ │ │ ├── ui/ # 基础组件（按钮、输入框等） │ │ └── business/ # 业务组件 │ ├── styles/ │ │ └── tokens.css # 设计 token 的 CSS 变量 │ └── pages/ └── tests/ └── visual/ # 视觉回归测试这个结构的关键是把设计规范（DESIGN.md）和设计 token（tokens.css）分开。DESIGN.md 给 AI 读，tokens.css 给浏览器用。两者内容一致，但格式不同。
6.3 设计 token 的同步方案
如果你用 Figma 做设计，可以用 Tokens Studio 插件导出设计 token，然后写一个脚本自动生成 DESIGN.md 和 tokens.css。这样设计师在 Figma 里改颜色，AI 和代码都能自动同步。
# 示例：从 Figma token 生成 DESIGN.md npx token-transformer tokens.json tokens.css node scripts/generate-design-md.js这个流程搭建一次，后续维护成本极低。设计师改完 Figma，跑一下脚本，提交，AI 下次生成就自动用新规范了。
7. 我个人的实操体会
这套方法我用了大半年，从最初被“AI 味”折磨到现在基本能稳定输出符合品牌调性的界面，最大的体会是：AI 不是设计师，它是执行者。你的品味越清晰，它的执行就越准确。
DESIGN.md 的本质不是一份技术文档，而是一份品味说明书。它逼着你想清楚：我的产品到底长什么样？我的品牌色到底是什么？我的间距系统是什么？这些问题想清楚了，AI 才能帮你把它们变成代码。
另外说一个反直觉的发现：约束越多，AI 的效率反而越高。没有约束时，AI 需要“思考”用什么颜色、什么间距、什么圆角，生成速度慢且质量不稳定。有了明确的 DESIGN.md，AI 直接查表执行，速度快、质量稳、返工少。
最后分享一个小技巧：每次 AI 生成完代码后，不要急着用。先让它自己对照 DESIGN.md 做一遍自检，把不符合的地方列出来并修正。这个“自检”步骤通常只需要多花 10 秒钟，但能省掉你后面 10 分钟的调试时间。
