ARTICLE · 1035067
AI 做 UI 为什么总有一股“AI 味”, 品味优先的解药来了?
AI 做 UI 为什么总有一股“AI 味”？用 DESIGN.md 和反 Slop 技能，把设计要求写清楚
大家好，我是民酱。
最近几个月，我用 Claude Code & Codex 做了不少前端页面。速度确实快，但有一个问题越来越扎眼：生成的 UI，总有一股“AI 味”。
紫色渐变、三列功能卡片、玻璃面板，再配一个大圆角按钮。页面挺完整，换掉 Logo，却好像也能给另一个产品用。
字体、颜色、布局单独看，都不一定有问题。放在一起，却很难看出这个产品到底有什么特点。
这一篇，我想把这件事拆开：怎么给 AI 设计上下文，哪些工具能帮忙，以及做完之后怎么验收。上个月整理的工具清单，也补进了最近 Vercel、Figma 和 Impeccable 的几个新案例。
三句话速览：
先给依据：DESIGN.md 记录颜色、字体、组件规则和使用理由，让 AI 做界面时有东西可查。 再管执行：设计技能帮助确定方向，组件映射帮助复用已有实现，规则检查帮助发现偏差。 最后看结果：文件写得再详细，也要拿实际页面验证；反复出现的修改意见，应该写回规范。
一、“AI 味”从哪里来
（一）页面没有回应具体需求
一个开发者工具、一个儿童教育产品、一家建筑工作室，需要传达的信息和气质都不一样。
如果最后都变成“大标题 + 三张卡片 + 注册按钮”，问题就很具体了：布局没有围绕内容做选择。
字体也是一样。Inter 可以用，紫色也可以用。需要解释的是：为什么这个项目适合它们？同一个页面里的其他选择，是否和它们一致？
这里说的 AI slop，主要指这种反复套用常见模式、缺少具体设计判断的输出。
（二）“高级一点”缺少可执行的信息
你让 AI“做一个现代、简洁、高级的后台”，它仍然要猜很多东西。
用户每天看多少条数据？主要操作是什么？页面应该紧凑，还是留出更多阅读空间？项目里已经有哪些组件？
这些信息没有讲清楚，模型就容易沿用常见模式。模型能力会影响结果，上下文和验收方式也会。
所以，我会先把问题收窄：用户进来要做什么，哪些设计选择已经确定，哪些还需要 AI 提方案。
（三）修改没有积累下来
第一次说“卡片太多”，第二次说“按钮颜色不对”，第三次又在改间距。
如果反馈只留在当前对话里，换个任务就可能重新来一遍。你付出了审阅时间，却没有留下可复用的规则。
每次确认过的设计选择，都值得留下使用条件。下一次遇到同类页面，AI 才有依据可循。
这些依据可以先放进一个文件。
二、DESIGN.md 应该写到什么程度
（一）数值和理由，都要有
Google Labs 的 DESIGN.md 项目，用 YAML frontmatter 记录结构化设计值，用 Markdown 正文解释设计意图和使用规则。（参考 CLAUDE.md 和 AGENT.md）
这里的设计 token，可以理解为有名字的设计值，比如主要文字色、按钮圆角和正文大小。名字让不同组件能够引用同一套约定。
以 MyBrand 为例，一份简化的设计说明可以包含下面这些内容：
产品定位
面向每天处理大量任务的运营人员。优先保证信息扫描效率和主要操作的可发现性。
基础设计值（示例）
颜色：主色 #182230，强调色 #2563EB，背景色 #F7F8FA。 正文：使用 system-ui 字体，字号 1rem。 圆角：小圆角（sm）为 6px。 间距：小（sm）8px、中（md）16px、大（lg）24px。
使用规则
颜色：强调色用于主要操作和选中状态，避免大面积装饰。 布局：批量比较信息优先使用表格，用留白和对齐建立层级，按内容需要划分容器。 组件：优先复用已有按钮、表单和表格组件，补齐加载、空数据、错误和禁用状态。 约束：沿用已有 token，新增数值时说明用途。动画应帮助理解操作反馈，并考虑减少动态效果的偏好。
这里值得注意的是“面向每天处理大量任务的运营人员”。
它解释了后面的选择：为什么强调扫描效率，为什么批量比较优先用表格。只有一组色值，AI 仍然可能做出一张好看的营销首页。
这里为了方便阅读，展示的是说明内容。实际写入 DESIGN.md 时，再将基础设计值整理成 YAML frontmatter，其余规则放进 Markdown 正文，并补齐字体回退、交互状态和组件细节，按使用的规范版本校验。
完整文件格式与可复制示例，见文末参考资料「Google DESIGN.md 规范与 CLI」。
（二）让文件真正进入工作流程
文件放进仓库之后，要在项目指令里明确什么时候读、如何用。
几个文件可以这样分工：
README.md：介绍项目和使用方法。 AGENTS.md：记录 Agent 参与项目的约定。 CLAUDE.md：补充 Claude Code 使用的项目指令。 DESIGN.md：记录界面规则、设计理由和例外条件。
不用为了凑齐名字把同一段话写四遍。在你实际使用的指令文件里，要求 Agent 修改 UI 前读取 DESIGN.md、检查已有组件，完成后说明偏离规范的地方即可。
Google 的 CLI 可以帮助校验、比较和导出，常用命令有四条：
校验规范：检查 DESIGN.md 是否符合规则。npx @google/design.md lint DESIGN.md
比较版本：查看两份设计规范之间的变化。npx @google/design.md diff DESIGN.md DESIGN-v2.md
导出 Tailwind v4 主题：将设计值转换为主题样式。npx @google/design.md export --format css-tailwind DESIGN.md
导出 DTCG token：将设计值转换为 DTCG 格式。npx @google/design.md export --format dtcg DESIGN.md
校验通过，只能说明相应规则通过，页面仍然需要检查。
（三）和 Figma 配合时，补上组件映射
Figma 适合查看具体布局、组件和视觉关系，DESIGN.md 适合记录项目里需要反复遵循的规则。是否两者都用，取决于现有流程。
Figma 官方 MCP 在 2025 年 6 月 4 日发布公开 beta，让编码 Agent 能获取设计上下文。结合 Code Connect，还可以知道设计中的组件对应代码里的哪个实现。
这个区别很实际。
假设设计稿里有一个步骤条。AI 可能看懂了外观，却自己拼了一套出来。项目里原有组件的状态、交互和无障碍处理，就都绕过去了。
所以，已有产品除了说明“长什么样”，还应该说明“用哪个组件、传哪些属性”。后面 Coinbase 的案例，就在检验这件事。
如果手头还没有设计说明，可以从现有产品或参考页面开始整理。
三、按手头材料选工具
工具名字很多，但选择时先看输入：你有现成规范、参考网站，还是只有截图。
下面保留几组有明确用途的候选。它们是调研入口，不代表我逐个做过实测；提取耗时、安装量和组件数量也不作为统一排名。
（一）有参考网站：先提取，再筛选
这一类工具主要帮助你收集颜色、字体、间距和布局线索。
brandmd：把网站设计信息整理成 DESIGN.md，适合先拿到一份可编辑的说明。提取后仍要核对内容和交互状态。 design-md-extractor：围绕网站设计规则做提取，适合需要继续梳理组件和样式细节的场景。输出是否覆盖目标页面，要实际检查。 design-distill：把提取和应用分成配套技能，适合把参考风格带进后续实现。应用前需要筛选哪些规则适合自己的产品。 get-web-design：通过 Chrome DevTools MCP 采集页面信息，适合需要结合页面结构、计算样式和截图分析的场景。使用前要准备好浏览器连接。
如果只想找一个起点，也可以看 awesome-design-md 里的品牌风格参考。社区整理的说明和官方品牌规范要分清楚，拿来之后先改成自己的产品要求。
提取结果里有一个区别值得单独看：源码 CSS 和计算样式各自提供什么。
源码 CSS 有助于理解变量、选择器和样式组织。Computed Styles，也就是计算样式，有助于确认元素在当前环境下实际采用的值。
两者可以互相补充。hover、focus 和不同屏幕尺寸下的表现，需要分别触发或切换后采集，单次读取不能包办。
（二）只有截图：先还原看得见的部分
截图能展示视觉结果，却不包含完整的实现信息。
screenshot-to-html：面向截图到 HTML 的实现，适合先做一个页面原型。原型里的交互仍需要明确需求。 screenshot-to-design-system：尝试从截图整理设计 token 和组件示例，适合提炼重复使用的视觉规则。单张截图无法证明所有组件都遵循同一套规则。 Codia AI：提供截图到可编辑 Figma 的路径，适合还需要回到设计工具继续调整的场景。转换结果要检查图层和组件组织。
比如，截图里的侧栏是固定宽度还是按比例缩放？按钮按下后会怎样？文字变长会不会换行？这些都需要补充说明。
因此，只有截图时，先把可见部分还原，再逐项补状态和响应式规则，会更容易验收。
（三）已经有代码库：优先复用现成组件
如果项目已经用了 Tailwind 或 shadcn/ui，先让 Agent 理解项目里的主题和组件。
shadcn/ui 官方 skill 强调结合组件库和 Registry 工作。对已有项目来说，这能帮助 Agent 找到可用实现，减少重复编写。
tailwind-context-resolver-mcp 这类工具，则可以提供本地主题上下文，帮助核对类名和 token 是否存在。是否能自动阻止错误，还要看具体工具和项目是否接入了检查流程。
换到 Vue、Svelte、Angular 或移动端，判断方式也一样：组件能不能复用，设计值能不能映射，平台交互是否需要单独处理。
SwiftUI 可以继续看 ios-design-swiftui 这类专用技能。React Native 和 Flutter 则需要分别核对组件、主题和原生交互。仅凭一份工具清单，还不足以判断哪个生态是“空白”。
（四）工具找到哪里就够了
Skills.sh、Awesome Agent Skills 和 awesome-design-skills，可以作为继续查找的入口。
找到候选后，回到项目仓库看它的输入、输出和依赖。一个工具声称支持“设计系统”，可能只输出颜色字体，也可能包含组件与验证流程，不能只看名称。
至于全站复刻，范围会更大。页面结构、资源、路由和业务交互都可能要处理。如果目标只是借鉴视觉风格，先做设计提取就够了。
规则和组件准备好之后，下一步是检查 AI 有没有照着做。
四、反 Slop 和验收，各能管什么
（一）frontend-design：先把方向选清楚
Anthropic 的 frontend-design 会引导 Agent 在实现前考虑用途、视觉方向和差异点，并避免反复套用常见的 AI 界面模式。
它适合设计方向还没有确定、需要探索页面表达的阶段。
但用在已有产品里，需要先遵循品牌和组件规范。如果项目已经确认了字体，不能为了避开“AI 味”就随意换掉。
新页面要有自己的内容重点，也要和已有产品保持一致。 这两件事需要一起考虑。
（二）Fluid 和 Impeccable：把部分问题变成检查
Fluid 提供确定性的检测器，扫描源代码里的常见视觉和动效问题，并支持接入 CI。Impeccable 则结合设计命令、检测器和浏览器工具，帮助检查和调整页面。
这些工具适合处理能够描述清楚的问题：某种效果是否反复滥用，是否出现不合适的动效写法，某些元素是否偏离已有规则。
它们也有边界。检测到一种字体或渐变，只能说明命中了某条规则。这个选择是否合适，还要结合产品和页面内容。
接入 CI 时，先区分哪些是提醒，哪些需要阻止提交，再处理合理的例外。规则应该服务于项目已经确认的设计要求。
（三）设计漂移、视觉回归和无障碍要分开看
设计漂移，指实现逐渐偏离约定。比如，原来应该引用主要按钮色，后来却在几个页面里分别写了相近的颜色。
Design Drift Detector、DesignGuard AI 等工具，可以作为继续调研的方向。选型时要看清楚，它检查的是代码值、设计 token，还是设计稿与实现之间的差异。
视觉回归关注的是页面变化。Playwright 截图比对可以帮助发现错位、溢出和布局变化，但字体渲染、抗锯齿也可能带来差异。
语义分析可以辅助解释变化，仍然需要需求和基准作依据。仅靠两张截图，不能确定一次改色是不是作者有意为之。
无障碍检查也要留出人工验证。对比度等项目适合自动检查，键盘流程、错误提示是否清楚、操作能否完成，还需要实际走一遍。
（四）这套流程的代价，是持续维护
DESIGN.md 会过时，组件接口会变化，截图基准也需要更新。
如果只增加规则，却没有删除失效要求，Agent 可能同时读到互相矛盾的说明。组件改了，映射没有改，也会把它引向旧用法。
因此，我会把维护范围控制在实际使用的部分：
一个临时页面，先明确方向和验收要求。 多人维护的产品，补齐组件映射和设计值约定。 经常重复生成的页面，再建立固定评测和自动检查。
最近几个案例，正好能看到这套流程如何继续往前走。
五、最近的新进展：规则有没有用，拿页面来验证
（一）Vercel：连 DESIGN.md 本身也要测试
8 月 31 日，Vercel 分享了自己的 design.md 实践。
他们最初把内部设计技能整理成公开提示词，但不同模型读完同样的说明，仍然生成了差异很大的页面。后来，团队改用固定任务反复测试，把发现的问题分别写进设计说明、公共样式表和自动检查。
比如，“表格太挤”是一条反馈。把它改成“证据表格应充分利用可用宽度”，就有了可以观察和检查的要求。
这个例子让我更看重规则的验证方式。你写了一条要求，下一次同类问题是否真的减少？如果没有，就继续查：规则没加载、表述不清楚，还是缺少对应组件？
Vercel 的案例支持一个很实用的做法：保留修改前的结果，固定任务和输入，再比较新规则带来的变化。不要只凭新版本看起来顺眼，就认定规范起作用了。
（二）Figma：组件映射能减少多少猜测
9 月 2 日，Figma 公布 Coinbase 使用 Code Connect 的测试。
在同一设计、提示词和模型的三次重复测试中，平均 Token 使用量减少 11.5%，实现时间减少 22.3%，成本减少 22.5%。组件选择和设计系统遵循情况也有所改善。
这是特定任务的小样本结果，不能直接当成所有项目的预期收益。
它给已有产品提供了一个检查方向：如果 Agent 总在重写已有组件，先核对组件映射和使用说明。设计稿里的外观信息，与代码里的组件接口，需要一起提供。
组件接口更新时，映射也要跟着维护。否则上下文再多，也可能是在重复旧信息。
（三）Impeccable：开始检查选中的设计有没有落实
Impeccable 在 8 月至 9 月初的更新里，补了几块实际流程：
8 月 14 日：加入面向 iOS、Android 原生界面的验证流程。 8 月 26 日：改善多项目仓库中各自 DESIGN.md 的加载。 9 月 1 日：增加设计稿到代码的阶段验收，检查结构、排版、材质、素材和响应式还原。 9 月 4 日：统一规则引擎，让 CLI、浏览器和实时模式使用同一套检查。
这几项更新对应的是设计落地后的问题。
设计方向已经选好了，代码做出来却可能走样：标题比例变了，图片被占位素材替代，手机端只剩简单堆叠。页面能运行，还需要确认它保留了哪些设计要求。
原生应用验证也说明，检查方式开始按平台区分。但这仍不能直接推导出 React Native、Flutter 的设计系统适配已经完整。
（四）怎么选，从你当前缺什么开始
如果你准备把这些工具用起来，我会按下面的顺序判断：
没有设计方向：先写清产品、用户和页面任务，再用 frontend-design 等技能探索。 有参考网站：选一个提取工具，整理并筛选 DESIGN.md。 只有截图：先还原可见部分，再补交互状态和响应式要求。 有现成设计稿和组件库：优先补 Code Connect 等组件映射，以及框架对应的使用说明。 总在重复改同类问题：加入 Fluid、Impeccable 或针对项目编写的检查，并保留前后结果。
流程可以先压缩到五步：明确任务、提供规则和组件、生成页面、检查实际结果、写回有效反馈。
从一个页面跑通，比同时装一组工具更容易判断哪里有帮助。
总结
如果只让我先准备两样，我会选一份贴合项目的 DESIGN.md，再配一个适合当前任务的设计技能。已有产品先围绕组件库工作，需要探索新方向时再用 frontend-design。
上手可以按这个顺序：
第一步：选一个具体页面，写清用户要完成什么。 第二步：整理已经确定的字体、颜色、布局和组件规则。 第三步：让 AI 实现，在桌面和手机上检查主要操作与异常状态。 第四步：把反复出现的修改意见写回规范，下次用同类任务验证。
以后再觉得页面“有股 AI 味”，先指出具体是哪一处：信息没有重点、组件没有复用，还是视觉选择和产品用途对不上。
问题说具体，规则才能写具体。每次改完留下依据，下一次做页面时才有东西可用。
参考资料
设计上下文与组件复用
Google DESIGN.md 规范与 CLI - github.com/google-labs-code/design.md awesome-design-md：品牌风格参考 - github.com/VoltAgent/awesome-design-md Figma MCP 首次公开 beta 公告 - www.figma.com/blog/introducing-figma-mcp-server/ shadcn/ui 官方 skill - github.com/shadcn-ui/ui/blob/main/skills/shadcn/SKILL.md tailwind-context-resolver-mcp - github.com/vola-trebla/tailwind-context-resolver-mcp ios-design-swiftui - github.com/EnzoChen0618/ios-design-swiftui
网站与截图提取
brandmd - github.com/yuvrajangadsingh/brandmd design-md-extractor - github.com/jpoindexter/design-md-extractor design-distill - github.com/Muluk-m/design-distill get-web-design - github.com/liaocaoxuezhe/get-web-design screenshot-to-html - github.com/sevzq/screenshot-to-html screenshot-to-design-system - github.com/WCF900905/screenshot-to-design-system Codia AI - codia.ai/
设计技能与验收
Anthropic frontend-design - github.com/anthropics/skills/blob/main/skills/frontend-design/SKILL.md Fluid - github.com/Darcos-Loft/fluid Impeccable 更新日志 - impeccable.style/changelog/ Design Drift Detector - mcpmarket.com/tools/skills/devteam-design-drift-detector DesignGuard AI：设计与代码漂移检测 - www.designguardai.com/solutions/design-code-drift-detection Playwright 截图比对文档 - playwright.dev/docs/test-snapshots
2026 年 8—9 月案例
Vercel：How our agents build on-brand pages with design.md - vercel.com/blog/how-our-agents-build-on-brand-pages-with-design-md Figma：How Coinbase used Code Connect to guide agents and shrink token costs - www.figma.com/blog/how-coinbase-used-code-connect-to-shrink-token-costs/
技能目录
Skills.sh - skills.sh Awesome Agent Skills - github.com/VoltAgent/awesome-agent-skills awesome-design-skills - github.com/bergside/awesome-design-skills