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 用.cursorrulesWindsurf 用.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.mdDESIGN.md 不是写完就完了。每次你发现 AI 生成的结果不符合预期就问自己是规则没写清楚还是规则里没覆盖然后把缺失的规则补进去。我自己的 DESIGN.md 从最初的 30 行迭代到了现在的 120 行每一条都是踩坑踩出来的。这个过程本身就是把“品味”显性化的过程——你越清楚自己要什么AI 就越能帮你实现。6. 工具链选型与配置参考6.1 AI 编程工具对比工具规则文件设计约束支持适合场景Claude CodeCLAUDE.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和设计 tokentokens.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.mdAI 直接查表执行速度快、质量稳、返工少。最后分享一个小技巧每次 AI 生成完代码后不要急着用。先让它自己对照 DESIGN.md 做一遍自检把不符合的地方列出来并修正。这个“自检”步骤通常只需要多花 10 秒钟但能省掉你后面 10 分钟的调试时间。