别再让 AI 乱做界面了,产品团队现在最该补的,可能是一个 DESIGN.md

这篇来自 George Nurijanian 的文章，标题是《DESIGN.md | The One File AI Needs to Match Your UI》。我看完后的第一反应是，这不只是写给设计师的，它其实更应该给产品经理、前端工程师、以及所有正在让 AI 参与 UI 生产的人看。

因为它点中了一个现在越来越常见、但很多团队还没真正正视的问题：

AI 已经能很快给你做出 10 个界面，但这 10 个界面看起来可能像 10 个不同产品。

一、AI 做 UI 的问题，已经不是“做不出来”，而是“做出来不像一套东西”

作者一开头举的例子特别准确。你让 Agent 分别做一个设置页、一个 onboarding 弹窗、一个 dashboard、再加一个 pricing page。单看每一张，可能都还行。但把它们拼在一起，你会发现像是四个不同团队、用四种不同品味、给四个不同产品做的界面。

logo 是同一个，气质完全不是一回事。

设计师其实很早就靠 design system 解决了这个问题。但 Agent 呢？Figma 对它们来说大多是“看不见的”，品牌 PDF 这类文档更差。于是就有了文章提出的核心答案：把设计规则写进 repo，写成一个 DESIGN.md。

二、什么是 DESIGN.md？它其实是给 Agent 看的“文本版设计系统”

文章里引用了 Google Stitch 团队的说法，DESIGN.md 本质上就是一个 plain-text 的设计系统文档，专门写给 AI agent 看。它放在项目里，直接告诉 Agent 产品应该长什么样、有什么感觉、哪些规则能碰、哪些不能碰。

它不是单纯一份“品牌说明书”，而是一份操作级的设计约束文件。里面要讲清楚颜色、字体、间距、组件规范、布局原则，以及最重要的，哪些事情绝对不要乱做。

作者做了一个很好的类比：

– README.md 是告诉人类“这项目是什么”

– AGENTS.md 是告诉 Coding Agent“怎么在 repo 里工作”

– DESIGN.md 则是告诉设计和编码 Agent“这个产品到底该长成什么样”

三、一个好的 DESIGN.md，必须同时有“值”和“理由”

作者特别强调，DESIGN.md 不该只有模糊的形容词，也不能只堆设计 token。它最好有两层。

第一层是机器可读的 YAML，比如颜色值、字体大小、圆角、间距、组件引用、属性配置；

第二层是人类可读的 markdown，用来解释界面应该有什么感觉、某种颜色负责什么任务、哪些布局模式允许出现、哪些组件风格永远不要乱发明。

这一点特别关键。因为纯 prose 只会给 Agent 一堆“clean”“premium”“friendly”“modern”这种很空的情绪词。纯 token 虽然精确，但没有判断。

一个 hex 颜色值本身，并不能告诉 Agent 这个颜色应该只用在主 CTA 上，还是可以刷满整个背景。

四、为什么 PM 现在也必须管这件事？

文章有一段我特别认同。过去 PM 最担心的是“从 idea 到 screen 太慢”，现在问题变成了“十分钟能出十个 screen，但这十个 screen 到底是不是同一个产品”。

这意味着，UI 生成越来越便宜之后，真正难的部分已经从“把界面做出来”，变成“判断这个界面是否属于这个产品”。

作者说得很直白，当 AI 接手更多制作工作，PM 的 judgment 只会变得更重要。

因为设计师能一眼看出问题，但 PM 也应该能说出一些非常具体的判断，比如这个产品到底是密集还是疏朗、偏企业感还是偏消费感、是强调行动还是强调审阅、应该克制还是应该更有表现力。

你不一定要替设计师做设计，但你至少得把产品判断写下来，别让 Agent 自己自由发挥。

五、最怕的不是 AI 做错，而是它“做得还行”，但整体很假

文章里列了一组典型问题，基本就是现在很多 AI 生成界面的通病：

– 圆角不对

– 字重不对

– CTA 层级错了

– 强调色用太多

– 没必要地发明了新卡片样式

– 表单和现有产品完全不像一家人

– 移动端布局像 Excel 一样崩掉

– empty state 文案像 SaaS 广告，不像真实产品

这些问题单独看都不致命，但累加起来，整个产品就会有一种非常明显的“假感”。

六、一个强 DESIGN.md，写法必须从“形容词”升级到“规则”

作者给了一个特别好的对比。

弱的 DESIGN.md 会写：

– Minimal

– Premium

– Clean

– Friendly

强一点的会写成：

– 每个 screen 只允许一个 accent color，并且只给主操作用

– 正文文字保持在 15 到 16px，行高高于 1.4

– 卡片主要通过边框和 surface contrast 分层，不靠重阴影

– 主按钮是 filled，次按钮只能是 outline 或 text

– empty states 要直接、克制、功能导向，不要乱卖萌

– 移动端先收起次级信息，保留主行动作

差别就在这里，前者是描述心情，后者是可执行规则。

七、别只是把文件塞给 Agent，要逼它“引用规则”来解释自己

我觉得这是整篇文章里最实战的一招。

作者说，单纯把 DESIGN.md 附给 Agent 然后等它输出，还是太被动了。更好的做法，是要求 Agent 在生成后反向审查自己的结果。

比如让它列出：这个 screen 遵守了 DESIGN.md 里的哪些规则；

哪些地方发明了新的 pattern；

按钮、卡片、输入框、字体、间距、移动端行为分别对照了哪一段规则；

如果 DESIGN.md 没写，就明确说出来，并要求扩充文件，而不是自己偷着发挥。

这一步一做，DESIGN.md 就不再只是“静态文档”，而变成活的设计判定系统。

八、最适合放进 DESIGN.md 的，反而是 do’s 和 don’ts

作者认为，对 PM 最友好的部分，很可能就是 do’s 和 don’ts。我也同意。

因为这是最容易把产品判断写成自然语言规则的地方，比如：

– 每个 screen 只保留一个明显的主操作

– 运营类页面优先保证扫描效率

– empty state 要帮助用户走下一步

– 不要为了装饰滥用 accent color

– 不要把审批、评审、删除操作藏进低对比度菜单里

– 不要把高密度 B2B 流程页做成消费类 landing page 的感觉

这种规则，比“我们希望整体感觉更专业一点”有用太多。

九、一个 DESIGN.md 什么时候该更新？

文章这里也讲得很清楚，不是每次意见分歧都要改规则，但以下情况一出现，说明它该更新了：

– 新组件模式已经重复出现两次以上

– 设计方向明确变了

– PM 一直在看到同类 Agent 错误

– 同一类 review comment 一直重复出现

– 某个功能区有了不同的数据密度规则

– 移动端模式已经明显和桌面端分流

一句话概括就是：别为一时口味争论去改它，但如果系统性偏差反复出现，就必须回写规则。

十、这篇文章最值钱的判断：AI 时代，品味不能只靠“大家心里有数”

文章最后一句我非常认同。未来 PM 一定会把更多 UI 工作交给 Agent，而真正强的团队，会停止把 taste 当成一种只能靠记忆传承的东西。

DESIGN.md 的意义，不是替代设计师，也不是让 AI 突然会设计。它的作用更现实：把已经做过的判断沉淀下来，让 Agent 不要一屏一屏地重新发明产品。

这也是为什么我觉得这篇文章值得翻出来给更多中文团队看。因为接下来大家拼的，已经不是“谁最先会用 AI 生成界面”，而是“谁最先把自己的产品判断、设计哲学、交互标准和界面约束，系统化写进工作流”。

结语

如果你今天已经在用 Claude Code、Cursor、v0、Lovable 或各种 UI Agent 做原型和页面，那这篇文章其实是在提醒你一件事：

不要只给 AI 任务，也要给 AI 边界、标准和判断依据。

否则它确实能给你十分钟做十个 screen，但你最后得到的，可能只是十张“看起来都还行、放在一起全不对”的图。

而一个真正有用的 DESIGN.md，也许就是让产品从“AI 做得出来”，走向“AI 做得像你们自己产品”的那一步。

互动话题：

如果让你现在就给团队补一个 DESIGN.md，你最想先写进去的 3 条规则会是什么？