DESIGN.md：Google 真正发布的不是画布，是一个文件
上周所有人都在聊 Google Stitch 的“AI 设计画布”有多炫，但说实话，真正值得我们这些搞产品、搞开发的琢磨半天的，不是那个画布。
是一个文件：DESIGN.md。
一个文件，干掉设计师-开发者之间的“三次交接”
传统产品开发流程，有个经典老问题叫“三次交接”。PM 写完 PRD 扔给设计师，设计师出完稿再扔给开发，开发看着标注吭哧哧还原。每次交接，都是一次信息损耗。PRD 里写个“简洁大气”，设计师理解成大留白，开发理解成把边框全去掉。需求传着传着就变形了，最后上线的东西，谁看谁不满意。
Google 的 DESIGN.md 干了件看起来特简单的事：把设计系统变成一个标准化的、Agent 可读的文本文件。颜色、字体、间距、组件规范——所有这些，都用结构化文本定义，而不是锁在 Figma 那个 .fig 文件里。
正如 @PawelHuryn 在他那条 23 万浏览的推文里说的，一针见血：
"Everyone's covering 'vibe design' and the canvas. But Stitch now has an MCP server that connects directly to Claude Code, Cursor, and Gemini CLI. Your coding agent can read your design system while it builds."
这才是真正的杀手锏。当 Stitch 通过 MCP（Model Context Protocol）server 直接连上编码 Agent 时，整个链路就变了：PM 描述业务目标 → Stitch 生成 UI → 编码 Agent 读取 DESIGN.md 自动实现。以前三个团队的工作，现在变成了一个闭环。
这不是那种“提效 30%”的渐进式改良，这是直接把交接这个环节给取消了。
设计师会被取代吗？答案比你想的复杂
这个话题下最火的一条推文来自 @samtwtss，957 万浏览量，就一句话：“bro, it's so over for designers”。近千万人看了这条，快一万人点了赞。这种恐慌，是真的。
@AI_Jasonyu 作为一名资深 UI 设计师，也给出了更具体的判断：“Stitch 确实是可以取代百分之八九十的 UI 设计师了。”
但我想说，这个“80-90%”的数字，取代的不是设计师这个职业本身，而是设计师日常工作中那 80-90% 的像素搬运工活儿。
想想设计师每天都在干嘛：从组件库里拖按钮、调间距、对齐元素、导出切图、写标注——这些本质上都是执行层的工作。AI 确实能做，而且做得更快更准，还没脾气。
但设计系统本身是谁定义的？用户调研是谁做的？产品到底该用什么样的视觉语言，才能传达出什么样的品牌情绪？一个 B 端产品和一个消费级 App 的信息架构，为啥要不一样？这些判断，AI 暂时给不了。
DESIGN.md 的出现，实际上把设计师的核心价值，从“画像素”推向了“定义系统”。 你可能不再需要手动画 200 个页面了，但你得决定这 200 个页面应该遵循怎样的规则。这是一种升级，不是淘汰——前提是你愿意升级。
Figma 为什么没有先做这件事？
@developedbyed 说出了很多人的心声：“Honestly shocked Figma wasn't the first one to do this。”
确实挺意外的。Figma 手握全球最大的设计师用户群、最完善的设计系统基础设施（Design Tokens、Variables），按理说最有资格做出“设计到代码”的闭环。
但 Figma 的商业模式决定了它的局限——它是一个协作画布，核心价值在于让更多人在上面花更多时间。把设计系统导出为一个纯文本文件，让 Agent 绕过 Figma 直接生成代码？这等于在自己的护城河上架桥，有点自断财路的意思。
@fiapp_pro 的观察也很有意思：很多 AI 设计工具的思路本身就是错的。它们还在试图做一个“更智能的画布”，而不是重新思考设计信息应该如何被结构化、传递和消费。Google 选择了一条完全不同的路——不做更好的画布，做更好的协议。
MCP 是一个开放协议，DESIGN.md 是一个纯文本文件。这意味着任何编码 Agent 都可以接入，任何工作流都可以集成。Google 没有试图垄断设计工具市场，它在定义设计系统和代码之间的通信标准。这一招，高明得多。
真正的变化：从“文件交接”到“上下文共享”
退一步看，DESIGN.md 解决的核心问题不是设计，是上下文断裂。
在传统工作流中，PRD 是一个文档，设计稿是一个文件，代码是一个仓库——它们各自独立，靠人脑来保持一致性。每次有人问“这个需求改了，设计和代码都同步了吗？”，答案通常是尴尬的沉默，或者一个“应该吧”的敷衍。
当设计系统变成代码仓库里的一个文件，被 Agent 实时读取和执行时，“同步”这个概念本身就消失了。不存在不同步，因为只有一个源。
这才是 DESIGN.md 最深远的影响——它不只是一个设计工具的创新，它在暗示一种新的产品开发范式：所有上下文都应该是 Agent 可读的、版本化的、存在于同一个工作流中的。
设计系统如此，产品需求如此，测试用例也应如此。
今天是 DESIGN.md，明天可能是 PRODUCT.md、TEST.md。当所有上下文都变成 Agent 可以理解的结构化文本，那“团队协作”这件事本身，可能就得被重新定义了。
不是人和人之间的协作变多了，而是人和 Agent 之间的协作，取代了大部分人和人之间的交接。设计师定义系统，PM 定义目标，Agent 负责中间的一切。
这个未来，可能比我们想象的来得更快。