AREX Feed Article
Peter Yang：AI 设计正从「紫色 slop」走向千篇一律的 Claude 风，一份 design.md 就是你的设计宪法
"我们从 AI 默认产出紫色 slop 式的设计，走到了到处都长着一张 Claude 脸的时代。"
7 月 29 日，前 Roblox 产品负责人、现全职 AI 创作者 Peter Yang（@petergyang）在 X 上发出了这条观察。推文在 24 小时内获得 425 次点赞、732 次收藏和 4.3 万次阅读。数字本身并不惊人，但收藏/点赞比高达 1.72:1，说明读到的人不是在随手互动，而是在认真存档。
这条推文戳中了一个正在加速但尚未被充分讨论的趋势：AI 辅助开发工具不再只是帮你写代码，它们正在悄悄统一互联网的视觉语言。
252K 粉丝的前 Roblox 产品负责人，这一次他在讲审美
Peter Yang 过去十多年在 Meta、Twitch、Reddit 和 Roblox 做产品，做到了 Roblox 的 Principal Product Manager。2025 年他离开 Roblox 全职做内容，在 YouTube 和 X 上发布 AI 教程，积累了 25 万粉丝，是 Claude Code 和 Claude Design 社区中最活跃的教程作者之一。
这一次他不是在讲怎么用 Claude Code 写代码，而是在讲一个更根本的问题：如果你不给 AI 一份设计规范，它就会用所有人都见过的那种风格来交差。
Peter Yang 给出的解决方案是一个听起来很朴素的工作流：在项目根目录放一份 design.md 文件，用 Markdown 格式定义好色彩、排版、间距和组件规则，让 AI 在生成任何 UI 之前先读这份"设计宪法"。
他还点名了两个获取灵感的来源：Mobbin 的 MCP 插件（可以直接抓取真实 App 的设计模式）和 designmd.sh（一个社区维护的 DESIGN.md 公共注册表）。
同一天，他发布了配套的 YouTube 教程，用 25 分钟完整演示了从创建 design.md 到 Claude Design 原型再到 Claude Code 实现的六步工作流。
Claude Design 上线 103 天，全网的 AI 产品长出了同一张脸
2026 年 4 月 17 日，Anthropic 通过 Anthropic Labs 发布了 Claude Design。这是一个基于 Claude Opus 4.7 的对话式设计工具，可以把文字描述变成交互原型、幻灯片、落地页和品牌视觉。
产品本身是出色的。它能读取你的代码库和设计文件自动构建设计系统，支持多人协作、内联评论、滑块微调，并且可以把设计打包成 handoff bundle 直接交给 Claude Code 实现。Canva 的联合创始人 Cameron Adams 在发布博文中公开站台，说 Claude Design 加 Canva 的组合让"从想法到成品"的过程无缝衔接。
但问题也出在出色。
Claude Design 太擅长产出"好看"的设计了。一种特定的好看：大字体、奶油色背景、圆角卡片、低饱和配色、恰到好处的留白。它产出的不是随机的丑设计，而是一套具有高度辨识度的审美体系。这正是问题所在。
更微妙的是传播速度。传统设计趋势需要几年才能从 Dribbble 热门渗透到普通产品。Claude Design 上线不到四个月，Reddit 的 r/webdesign 版块已经开始出现"这么多网站现在都长这样了"的讨论帖，Instagram 上的设计师开始发 Reel 吐槽 AI 生成网站的统一面孔。
一位设计师在接受 Managed Code 采访时说得精准："LLM 有一个紫色问题（purple problem）。每个 AI 网页构建工具都会给你同样的紫色 slop 设计。"这个"紫色问题"的继任者，就是"Claude 脸问题"。
在 Hacker News 上，用户 hbosch 在 Claude Design 的讨论帖中描述了自己的经历："我用它生成了一个我做了几周的设计，结果还不错。然后我在 Twitter 上刷到别人的成功案例，发现那个设计跟我的一模一样。笑死。"这个评论在 387 分的热帖中获得了大量赞同。
另一位用户 mickdarling 的评论更尖锐："这不是真正的工具。这只是一个玩具，如果你用他们提供的示例来衡量的话。"
Peter Yang 的推文之所以引起共鸣，是因为他点出了这个困境的下一步：设计师和开发者已经开始注意到这种同质化。他们不想自己的产品看起来像"又一个 Claude Design 生成的页面"，但他们也不想回到 AI 生成紫色渐变、霓虹光效和廉价玻璃态的那个"紫色 slop"时代。
一份纯文本文件，凭什么成为 AI 的「设计宪法」
DESIGN.md 的想法来自 Google。
2026 年 4 月 21 日，Claude Design 发布四天后，Google Labs 通过官方博客宣布将 Stitch 中的 DESIGN.md 格式开源。Google Labs 的软件工程师 Cassia Xu 在博文中写道：DESIGN.md 让 AI agent "不再猜测意图，而是精确地知道每种颜色的用途，并能对照 WCAG 无障碍规则验证自己的选择"。
这个格式的设计理念非常简单：一个放在项目根目录的 Markdown 文件，用结构化的方式描述一个设计系统的全部规则。主色、辅色、字体层级、间距尺度、阴影、圆角、组件行为。任何 AI 编码 agent 在生成 UI 之前，都可以先读取这份文件作为设计约束。
Google 的这个时机选得很微妙。Claude Design 刚发布四天，Anthropic 还在宣传自己的"自动读取代码库构建设计系统"功能，Google 就抛出了一个不绑定任何平台的开放标准。这不是偶然。AI 辅助设计正在成为 Claude Code 生态中最具增长潜力的分支功能，而 Google 选择在格式层面抢占标准制定权。
简单的设计选择带来了复杂的后果。DESIGN.md 解决了两个此前 AI 辅助设计中最难解决的问题。
第一个是"每次都不一样"。在没有设计约束时，AI 每次生成 UI 都会重新猜测你的审美偏好，而每猜一次结果都不同。DESIGN.md 让猜测变成了查询。
第二个是"所有人的都一样"。在没有设计约束时，AI 会回归到训练数据中最常见的模式，这些模式恰好就是 Claude Design 训练出来的那套。DESIGN.md 让你的 AI 偏离那个默认值。
Peter Yang 在推文中叫它"design md file"而不是全大写的 DESIGN.md，这暗示了一个重要的事实：你不需要等到有人给你发布一个正式规范。你现在就可以创建一个。
从 Google Stitch 到 designmd.sh，一个社区正在长出来
DESIGN.md 从 Google 的一个内部功能变成公共标准，只用了不到四个月。
Google Stitch 原本是 Google Labs 内部的一个 AI 设计工具，DESIGN.md 是它的导出格式。开源之后，社区迅速跟进。Better Stack 写了一份详细的 DESIGN.md 使用指南，GitHub 上出现了 awesome-design-md 集合仓库，一位开发者在 Medium 上连载了"调了 30 天 design.md 之后的经验"。
最关键的社区项目是 designmd.sh，一个由社区维护的 DESIGN.md 公共注册表。它的运作方式和 skills.sh（Claude Code skills 注册表）类似：开发者把自家产品的 DESIGN.md 文件托管在 GitHub 上，用户通过 CLI 工具直接下载到本地项目中使用。注册表里已经收录了多个主流网站和 App 的设计系统文件。
designmd.sh 的规则也很克制。它不托管文件本身，只索引 GitHub 仓库中的 DESIGN.md 路径。CLI 工具从源仓库直接下载，这意味着设计文件的更新权和所有权始终在原作者手中。这种设计哲学和 npm、PyPI 等集中式包管理形成了对比，也更适合设计系统这种需要频繁迭代且与品牌强绑定的内容类型。
Peter Yang 提到的另一个工具是 Mobbin 的 MCP 插件。Mobbin 是全球最大的 App 截屏参考库，它的 MCP 插件让 Claude 可以直接搜索和浏览真实 App 的界面设计。工作流是这样的：你在 Mobbin 里找到喜欢的 App 页面，截图贴给 Claude，然后让 Claude 基于这些截图生成一份 design.md。
这个工作流的有趣之处在于它反转了传统的设计流程。过去是设计师做设计系统，工程师照着实现。现在是一个循环：人类通过 Mobbin 截图挑选喜欢的风格，AI 提取设计规则生成 design.md，AI 按照规则生成 UI，人类再调整 design.md。如是往复。
设计系统从"产出物"变成了"输入约束"。这是一个比工具本身更重要的转变。
六步工作流：从一份 design.md 到上线一个产品
Peter Yang 在他的 YouTube 教程中展示了完整的六步流程。
第一步，定义问题和创建 design.md。这是最关键的一步，也是大多数 AI 教程跳过的步骤。Peter Yang 在推文中特别强调："我总是先创建一份 design md 文件，里面包含色彩、排版等指南。"他还给出了具体的灵感来源：去 Mobbin 找喜欢的 App 页面，或者去 designmd.sh 下载现成的设计系统。
第二步，在 Claude Design 中做原型。Claude Design 可以读取 design.md，按照你定义的规则生成交互原型。这一步的目标不是完美像素，而是快速验证信息架构和交互流程。
第三步，用 Claude Code 写代码。Claude Design 生成的 handoff bundle 包含了设计规范、组件定义和样式规则，Claude Code 可以直接读取并开始实现。
第四步到第六步是迭代、测试和部署。这部分和其他 AI 辅助开发流程没有本质区别，但 design.md 的存在改变了迭代的性质。以前每次修改设计都需要重新描述审美方向；有了 design.md 之后，修改一次文件就会自动应用到所有后续生成中。禅修式的"不，再浅一点""不对，太浅了"的拉锯消失了，取而代之的是"改一行十六进制色号，重新生成"的精确感。
整个流程的核心哲学一句话可以概括：把审美决策从"每次生成时临时做"变成"做一次，写入文件，以后每次都遵循"。这是一个工程师式的思路。用约束换一致性，用前期的一次性投入换后期的无限复用。
Peter Yang 的教程评论区里有一条回复很能说明这六步工作流的现状："design md 在第二周之后就开始漂移（drift），只有组件级别的约束才能让 Claude 保持一致性。"发这条评论的是 ML 工程师兼博士生 Sebastian Buzdugan，他的意思是 design.md 只是起点，真正让 AI 产出稳定设计的还需要更细粒度的组件规范。这个批评是对的，但它并不削弱 Peter Yang 的核心观点：你得先有一份设计文档，才能谈得上让它变好。
这套工作流的成立依赖于一个前提：当前的 AI 模型足够聪明到能读懂设计规则，但还不够聪明到能自己创造有辨识度的设计。这个前提恰好也是当前 AI 辅助开发"从 slop 到 Claude 脸"的根源。
审美同质化的尽头，是每个人都要学会写设计文档
Peter Yang 的观察之所以重要，不是因为它提供了一个技术解决方案。design.md 本身的技术含量几乎为零。它之所以重要，是因为它指出了一个被忽视的因果链：AI 模型的训练分布决定了默认审美；默认审美决定了大多数 AI 生成产品的视觉语言；而大多数产品都用默认审美，意味着互联网正在被少数几个模型的审美偏好殖民。
"紫色 slop"时代的默认审美来自早期 AI 图像模型的训练数据分布，大量合成感强烈的紫色渐变 UI。"Claude 脸"时代的默认审美来自 Anthropic 的设计团队和 Claude Design 的训练偏好。问题不在于哪个更好看。Claude 的设计确实比 slop 好看得多。问题在于两者都是默认值。
Peter Yang 的解决方案本质上是一个去默认化的策略：通过一份纯文本文件，把审美控制权从模型的训练分布交还给产品的创造者。
这个策略的成立有一个隐含前提：你至少知道自己想要什么风格。
这是 Peter Yang 没有明说但整条推文都在暗示的事。他给出的两个灵感来源，Mobbin 和 designmd.sh，本质上都是"先去看别人做的好设计，然后抄过来"。在传统设计世界里这叫 mood board 或竞品分析，在 AI 辅助开发的世界里它有另一个名字：你的设计品味就是你 curation 能力的函数。你不会画 UI 没关系，但你必须能判断一个设计是不是好看，以及为什么好看。
这不是一个小众的工作流技巧。如果 AI 辅助开发继续以当前的速度渗透产品开发流程，design.md 将会成为每个项目的必备文件，和 README.md、.gitignore 一样基础。
"会写设计文档"将从设计师的专业技能变成产品经理和工程师的基础素养。到那个时候，不会写设计文档的产品经理和不会读设计文档的 AI agent 一样，都会被淘汰。
参考链接：