DESIGNMD.sh 这类东西，别只看成“又一个好看的设计素材站”。它真正戳中的，是 AI 写前端时最尴尬的一层：模型会写代码，也会照着组件库拼页面，但它经常不知道什么叫“这个品牌的气质”。
过去我们让 Agent 做 UI，常用话术是“参考 Apple 风格”“做得像 Nike 一点”“高级、克制、科技感”。这些词对人有用，对模型就有点玄。DESIGNMD.sh 做的事更朴素：把品牌视觉拆成一份 DESIGN.md，让 Agent 能读到颜色、字体、间距、圆角、组件状态和禁忌动作。
这不是灵感图库，而是把审美约束写成工程文件。
DESIGN.md 到底解决了什么
Google 推的 DESIGN.md，本质上是给 Coding Agent 看的设计系统说明。它不是 Figma，也不是完整组件库，而是一份 Markdown 文件：前面用 YAML 写机器可读的 token，后面用文字解释为什么这么用。
一份典型 DESIGN.md 会包含这些东西：
- 颜色：主色、背景色、文本色、边框色、状态色；
- 字体：标题、正文、标签、按钮分别用什么字号、字重、行高；
- 间距：页面留白、卡片内边距、网格节奏；
- 圆角和阴影：按钮、输入框、卡片该有多“软”；
- 组件规则：主按钮、次按钮、标签、导航、卡片怎么长；
- Do / Don't：什么能做，什么别碰。
这比一句“做得高级点”靠谱多了。因为 Agent 不是没能力写 CSS，它缺的是边界。边界一旦写清楚，模型犯低级审美错误的概率就会小很多。
举个简单例子：Nike 的 DESIGN.md 不是简单写“运动、酷、黑白”。它会把极高对比度、Futura 式大标题、黑白零售界面、灰色搜索和标签 pill、销售红和成功绿这些规则拆开。SpaceX 的文件也不是一句“太空科技感”，而是黑色画布、全屏照片、D-DIN 大写标题、极少 UI chrome、幽灵按钮这些具体约束。
这才是 Agent 真能执行的东西。
DESIGNMD.sh 的价值：把设计风格变成可安装资源
DESIGNMD.sh 是一个公共 DESIGN.md registry。它把社区整理好的设计说明集中起来，当前能看到 Apple、Nike、SpaceX、MongoDB、IBM、Cursor、Mistral AI、BMW M、PlayStation、Claude、Wired 等二十多个风格文件。
使用方式也很直接：
或者换成 SpaceX：
命令拉下来的不是一套图片，也不是一堆 CSS 成品，而是一份 DESIGN.md。你把它放进项目里，再告诉 Claude Code、Codex、OpenClaw、Cursor 或其他 Coding Agent：生成页面时先读取这份设计规范。
这一步看起来很轻，但工程意义不小。因为 Agent 终于有了一份固定的视觉上下文，而不是每次都靠 prompt 现场发挥。
为什么它比“给模型看截图”更稳
截图当然有用，尤其适合让模型理解一个页面大概长什么样。但截图有几个问题：
- 它很难稳定复用；
- 它不容易表达 hover、disabled、focus 等状态；
- 它不告诉 Agent 哪些元素是品牌核心，哪些只是当前页面偶然这么做；
- 它也不方便进入 Git、diff、review 和团队协作。
DESIGN.md 的优势恰好在这里。它可以版本化，可以审查，可以复制到多个项目，可以被 lint，可以导出成 Tailwind 或设计 token JSON。
说白了，截图更像“看一眼感觉”，DESIGN.md 更像“按规矩施工”。
对内部团队来说，这比借用 Nike、Apple 风格更值得看。真正有价值的用法，是把自己公司的视觉规范、产品页面规则、后台系统密度、按钮状态、表格习惯、空状态文案，全都沉淀成 DESIGN.md。
到那时候，Agent 生成的就不再是“像某个大厂”，而是“像你们自己”。
一个最小落地流程
如果你只是想试试，可以按这个顺序来：
然后在项目根目录放一个简单说明，例如：
如果是已有项目，就不要让 Agent 一次性重写全站。更稳的做法是先挑一个新页面，或者挑一个独立组件：
这样比较安全。因为 DESIGN.md 管的是视觉和体验约束，不该顺手把业务逻辑也改了。
给团队用，重点不是复制名牌风格
DESIGNMD.sh 上那些 Nike、SpaceX、Apple 风格很吸引人，但商业项目别上头。品牌风格不是公共皮肤包，尤其是知名品牌的字体、视觉语言、页面结构和营销气质，都不适合直接拿去做自己的产品。
更合理的用法有三种。
第一，用它学习拆解方式。看一份 Nike DESIGN.md，你会发现“运动感”最后会落到字号、字重、黑白对比、按钮形态和图片使用上。看一份 SpaceX DESIGN.md，你会发现“航天感”不是加星空背景，而是少颜色、强摄影、强标题、少装饰。
第二，用它做内部规范模板。把自己的官网、控制台、文档站、营销页拆成一份 DESIGN.md，交给 Agent 复用。以后新页面不是从零 prompt，而是先加载规范。
第三，用它做审美回归测试。Agent 改完 UI 后，不只跑单元测试和 E2E，也让它对照 DESIGN.md 自查：有没有用了禁用颜色？按钮圆角是不是跑偏？页面密度是不是不符合后台系统？
这听起来有点笨，但挺管用。AI 工程里很多稳定性，最后靠的就是这种笨文件。
一个内部 DESIGN.md 可以怎么写
如果你准备给自己的产品补一份，不用一上来写成完整设计系统。先写到 Agent 能执行就行。
写完之后，可以用 Google 的 CLI 检查结构和对比度：
再导出给 Tailwind：
这时候 DESIGN.md 就不是“给 AI 的提示词”，而是能进仓库、能 review、能演进的工程资产。
它的边界也要说清楚
DESIGN.md 不是万能药。
它不能替你做产品定位，也不能替设计师判断品牌该不该这么表达。它也不能保证 Agent 一次生成的页面就能上线。尤其是复杂后台、移动端适配、无障碍、暗色模式、真实数据密度，这些仍然要靠人审和测试兜底。
另外，公共 registry 的文件也要当成第三方输入看待。拉进项目之前，至少看一眼内容，确认没有奇怪指令、外部脚本、与项目安全策略冲突的要求。设计文件虽然看起来不像代码，但它会影响 Agent 的生成行为，别完全无脑信。
真正成熟的用法，是把 DESIGN.md 放进团队工作流：
- 新页面生成前，先读取 DESIGN.md；
- 修改视觉时，说明改了哪些 token；
- PR 里 review 设计规则，而不是只看截图；
- 线上发现风格漂移，把经验补回 DESIGN.md；
- 对重要产品页面，用 Playwright 或视觉回归工具做二次验收。
这样一来，AI 前端就不再只是“快点出个页面”，而是开始接近正常工程流程。
最后看，它补的是 AI 的审美记忆
AI 写 UI 最大的问题，不是不会写按钮，也不是不会用 Tailwind。它的问题是每次都像失忆：这个项目要紧凑还是要呼吸感？按钮该圆还是该硬？后台系统能不能放巨大 hero？品牌色到底该用在哪里？
DESIGN.md 给了一个很工程化的答案：别靠感觉，写文件。
DESIGNMD.sh 把这个思路做成了 registry，所以你可以一条命令拿到现成风格。但更重要的，不是把 Nike 或 SpaceX 的皮套到自己项目上，而是学会把自己的审美规则沉淀下来。
以后一个项目里有 README、AGENTS.md、CLAUDE.md、MCP 配置，再多一份 DESIGN.md，并不奇怪。代码有规范，Agent 有工具，界面也该有一份它能读懂的审美边界。