文章目录前言一、从 Vibe Coding 到 Vibe Design变化的不是工具而是创作方式1.1 Vibe Design 的出现其实并不突然1.2 创作的门槛开始从“会不会操作工具”转向“能不能描述清楚”1.3 从“亲手完成”到“组织一次有效迭代”二、Stitch 2.0 做了什么从“生成图片”到“生成可继续开发的设计资产”2.1 从一句描述开始把模糊想法变成可讨论的界面2.2 真正的差异不在“生成得好看”而在“能不能继续迭代”2.3 DESIGN.md 和 MCP设计资产开始进入 Agent 工作流写在文后 个人主页铁皮哥欢迎关注 作者简介28届校招生后端开发/Agent 方向在学 学习内容Java、Python、计算机视觉、大语言模型、Agent开发 专栏内容从零开始的Claude Code零代码生活持续更新中✨不只背八股更想搞懂为什么这样设计前言这两年开发者对Vibe Coding这个词应该已经不陌生了。以前写代码我们更习惯先把逻辑想清楚再一行一行实现。遇到不会的语法、报错或者框架用法就去查文档、搜博客、翻 Stack Overflow。但现在很多时候流程已经变了。我们会先用自然语言描述自己想做什么让 AI 生成一版代码再根据实际运行结果不断修改、调试和重构。开发者的工作重心也开始从“亲手写出每一行代码”慢慢转向“描述目标、提供上下文、判断结果是否可靠”。也就是说编程这件事正在从一种偏手工的实现过程变成一种人与 AI 协作的创作过程。而最近看到Google Stitch 2.0的推出我突然意识到类似的变化也正在设计领域发生。以前我们想把一个产品想法做出来中间往往要经过很多环节需求文档、线框图、高保真设计稿、前端还原、接口联调。每一个环节都需要不同角色不断沟通、解释和对齐。但 Stitch 2.0 这类工具正在尝试缩短这条链路。你不再一定要先熟练掌握设计工具也不一定要从空白画布开始一点点拖组件。你可以直接描述一个页面的目标、风格和功能让 AI 先生成一个可以讨论、可以修改、可以继续推进的设计结果。我们未来更关注的点可能是怎么把需求、设计、代码和工具组织成一个更稳定的 AI 工作流代码是这样设计也是这样。一、从 Vibe Coding 到 Vibe Design变化的不是工具而是创作方式在聊 Vibe Design 之前我觉得有必要先回到 Vibe Coding。因为这两个词看起来一个属于代码一个属于设计但它们背后其实指向的是同一件事AI 正在改变我们把想法变成作品的方式。以前我们写代码更像是在“操作机器”。脑子里先想清楚逻辑然后把它翻译成代码再通过编译器、运行结果和报错信息不断修正。这个过程当然也需要创造力但大部分时间里开发者面对的是很具体的实现细节这个函数怎么写这个接口怎么调这个状态怎么维护这个 Bug 为什么出现。可 Vibe Coding 出现之后很多人的开发流程开始发生变化。我们不再总是从空白文件开始敲第一行代码而是先把自己想要的结果描述出来。比如我想做一个博客后台首页左侧是文章管理和数据分析入口右侧展示阅读量趋势、热门文章、评论变化和待办事项。然后 AI 会先生成一版初稿。它可能不完美甚至有些地方写得很粗糙但它确实帮我们跨过了“从 0 到 1”的那一步。接下来开发者做的事情变成了审查、修改、补充约束和验证结果。这里最有意思的变化不是 AI 替我们写了多少代码而是开发者和代码之间的关系变了。以前我们更像是代码的直接生产者。现在我们越来越像是一个“导演”告诉 AI 想要什么效果指出哪里不对补充项目上下文再决定最终能不能合并进真实项目。这就是 Vibe Coding 真正带来的变化。它不是单纯换了一个更聪明的编辑器也不是多了一个自动补全插件而是让编程从“逐行实现”慢慢变成了“描述目标 约束结果 持续迭代”的过程。1.1 Vibe Design 的出现其实并不突然理解了 Vibe Coding再看 Vibe Design就会发现它并不是凭空冒出来的新概念。过去一个产品想法要变成页面通常要经历一条很长的链路。先有人把需求写出来再有人整理信息架构然后设计师画线框图、做高保真稿前端再根据设计稿还原页面。如果中途需求变了或者某个交互没有讲清楚大家就要重新沟通、修改、确认。这个流程本身没有问题真实工作里也确实需要这些步骤。但问题在于很多早期想法其实还没有复杂到需要完整走一遍流程。比如我只是想快速看看一个“技术博客数据分析后台”大概长什么样。我想知道它的首页应该放哪些模块阅读量趋势和热门文章怎么排版评论区数据是否需要单独做一张卡片。在过去如果我不会设计工具这个想法大概率只能停留在脑子里或者用很粗糙的草图表达出来。但 Vibe Design 想解决的正是这一步。它让一个人可以先不用纠结画布、组件、间距、字体而是直接描述自己的想法我想要一个面向个人开发者的博客分析后台整体风格简洁首页展示阅读趋势、热门文章、评论增长和收藏转化率布局偏 B 端控制台。AI 先生成一版界面。然后我再继续说信息密度再高一点卡片之间的间距缩小整体风格更像专业工具不要太像营销页面。这个过程和 Vibe Coding 很像。第一次生成不是终点而是一个可以继续修改的起点。1.2 创作的门槛开始从“会不会操作工具”转向“能不能描述清楚”我觉得 Vibe Design 最值得关注的地方不是它能不能画出特别惊艳的 UI而是它改变了创作的入口。过去设计工具本身就是一道门槛。不是所有人都熟悉 Figma不是所有人都知道组件该怎么摆也不是所有人都能把脑子里的产品想法快速画成一个像样的页面。于是很多时候一个想法在早期根本没有机会被充分讨论。因为它还没被可视化出来别人只能听你描述很难判断它到底好不好。Vibe Design 把这件事变轻了。它允许一个没有设计背景的人先把想法变成一个可以看的东西。哪怕这版设计还不够成熟至少它已经从一句抽象描述变成了一个可以被指出问题、可以被修改、可以被继续推进的原型。这其实很像 Vibe Coding 对编程新手的影响。以前你想做一个功能可能卡在项目结构、语法细节、框架配置上。现在 AI 可以先帮你搭出一个大概的形状让你把注意力更多放在“这个功能到底要解决什么问题”上。设计也是一样。当 AI 可以快速生成界面时人的注意力就会从“怎么画出来”转向“这个界面是否合理”。页面的信息优先级对不对用户一眼能不能看懂核心数据这个按钮应该放在这里吗这个交互会不会让人误解整体风格是否符合产品定位这些判断才是更接近设计本身的部分。所以 Vibe Design 并不是让设计变得不重要了反而是把一部分机械操作往后推让更多人提前参与到产品表达里。1.3 从“亲手完成”到“组织一次有效迭代”Vibe Coding 和 Vibe Design 还有一个共同点它们都让“第一次完成”变得更容易了。代码可以先生成一版。页面也可以先生成一版。文案、接口、测试用例甚至产品说明也都可以先有一个初稿。但初稿变容易之后真正重要的东西反而更明显了。因为 AI 生成的结果经常是“看起来差不多”但不一定真的可用。代码可能能跑但结构很乱。页面可能好看但不符合真实业务。交互可能完整但用户路径并不顺。设计风格可能统一但信息重点放错了地方。这时候人要做的就不是简单地点一下“生成”而是组织一轮又一轮有效迭代。我需要知道哪里不对也要知道该怎么描述“不对”。我不能只说“优化一下”而要能说清楚这个页面的核心目标是让用户快速看到博客增长情况所以阅读趋势应该比文章列表更突出评论数据可以弱化不要和核心指标抢视觉层级。这样的反馈才会让 AI 更接近真实需求。也就是说在 Vibe Coding 和 Vibe Design 里人的价值并没有消失只是位置发生了变化。我们从“亲手完成每一个细节”逐渐变成“定义目标、补充上下文、审查结果、推动迭代”的人。这也是为什么我觉得 Vibe Design 值得开发者关注。它不是设计领域孤立发生的一次工具升级而是整个软件生产方式变化的一部分。以前软件开发更像一条流水线需求传给设计设计传给前端前端再和后端对接口。现在 AI 正在尝试把这些环节连接起来。想法可以直接生成页面页面可以继续变成组件组件背后又会牵出接口、数据模型和业务逻辑。从这个角度看Vibe Design 不只是“AI 会画界面了”。它真正说明的是软件开发正在从手工操作工具转向组织上下文和驱动 AI 迭代。而这才是从 Vibe Coding 到 Vibe Design 最值得关注的变化。二、Stitch 2.0 做了什么从“生成图片”到“生成可继续开发的设计资产”如果只用一句话介绍 Stitch 2.0很容易把它说成是一个可以根据自然语言生成 UI 的 AI 设计工具。这句话当然没错。Google 官方对 Stitch 的介绍也是它可以为移动端和 Web 应用生成 UI让设计构思变得更快、更简单。但如果只看到“生成 UI”这一层其实还是有点低估它了。因为现在能生成界面的工具已经不少了。你给 AI 一段描述它生成一张看起来不错的 App 页面或者生成一个后台管理页面这件事本身已经不算特别新鲜。Stitch 2.0 真正值得关注的地方在于它想把设计过程继续往后推一步让设计结果可以被修改、被复用、被导出甚至进入后续的开发工作流。换句话说它的目标不是停在“生成一张图”而是生成一份可以继续开发的设计资产。2.1 从一句描述开始把模糊想法变成可讨论的界面很多产品想法在最开始的时候其实都是很模糊的。比如我说“我想做一个技术博客后台。”这句话听起来很清楚但真正要落到页面上马上就会遇到一堆问题。首页应该展示哪些数据阅读量趋势是不是最重要评论、收藏、点赞要不要放在同一屏文章列表应该偏内容管理还是偏数据分析整体风格应该像个人工具还是像企业级 SaaS 后台这些问题如果只停留在文字里讨论起来会很抽象。但只要有了一版界面哪怕它还很粗糙很多问题就会立刻暴露出来。这也是 Stitch 2.0 的第一层价值它能把一个还没有完全成型的想法快速变成可以看的东西。你可以直接描述我想做一个面向个人开发者的博客数据分析后台首页需要展示阅读量趋势、热门文章、评论增长、收藏转化率和选题建议整体风格简洁信息密度适中。然后它先生成一版界面。这版界面未必就是最终结果但它让讨论变得具体了。你可以指着某个模块说这里信息太散了这个卡片权重太高了这个趋势图应该放到更核心的位置这个页面看起来更像营销站而不是工具后台。这和 Vibe Coding 里 AI 先生成一版代码很像。很多时候第一版代码并不是为了直接上线而是为了让我们看到一个可运行的雏形。Stitch 生成的第一版设计也是一样它不是终点而是一个起点。过去从想法到界面中间隔着设计工具、组件知识、布局能力和审美经验。现在这条路被缩短了你先把意图说出来AI 帮你生成一个初稿然后人再开始判断和调整。这个变化看起来简单但对早期产品构思很有帮助。因为很多时候一个想法只有被画出来才真正开始接受检验。2.2 真正的差异不在“生成得好看”而在“能不能继续迭代”AI 生成图片最容易让人兴奋也最容易让人误判。一张漂亮的 UI 图第一眼确实很吸引人。但真实的软件设计不是发朋友圈它一定要继续往下走。页面之间有没有一致性按钮、卡片、表单是不是同一套风格移动端和 Web 端能不能适配用户点完一个按钮之后下一步该去哪里这个页面背后需要哪些接口和数据如果一个 AI 工具只能生成一张静态图那它更多是灵感工具。它可以帮助我们找方向但很难真正接入软件生产流程。Stitch 2.0 更值得关注的地方是它把自己定位成一个可以持续迭代的设计环境。根据公开介绍这次更新里包括自然语言和语音输入、无限画布、新的设计 Agent以及围绕用户旅程、交互原型和动态反馈的能力。这意味着用户不只是输入一次 Prompt然后等它吐出一张结果图。更理想的流程应该是这样的你先描述一个大方向Stitch 生成几版界面你挑出其中比较接近的一版继续补充约束你让它调整布局、提高信息密度、换一种视觉风格你再让它补充下一个页面或者把静态界面连接成一个可走通的用户路径。这个过程更像是在和一个设计搭档沟通而不是在用一个图片生成器抽卡。比如一开始我让它生成“博客数据分析后台”它可能给我一个很通用的 B 端页面。但我继续补充这个页面不是给企业团队用的而是给一个正在求职的个人开发者用的。重点不是复杂报表而是帮助我判断哪些文章更适合放进简历所以热门文章、收藏率和评论质量应该比总阅读量更重要。这时候设计就不再只是视觉问题而开始和产品目标绑定。页面怎么排取决于我想解决什么问题。模块怎么突出取决于用户最关心什么。交互怎么组织取决于这个工具最后要帮人完成什么动作。这也是为什么我觉得 Stitch 2.0 不能只被理解成“AI 画图变强了”。它更重要的地方是让设计从一次性产物变成了一个可以被上下文持续推动的过程。在 Vibe Coding 里我们不是只让 AI 生成一段代码就结束而是不断告诉它项目结构、业务规则、接口约束和错误信息。在 Vibe Design 里也一样我们不是只让 AI 生成一张界面而是不断告诉它产品目标、用户路径、视觉偏好和设计规范。真正有价值的不是第一张图而是后面这一轮又一轮迭代。2.3 DESIGN.md 和 MCP设计资产开始进入 Agent 工作流如果说自然语言生成 UI 是 Stitch 2.0 最容易被感知的能力那DESIGN.md和MCP就是更值得开发者关注的部分。因为它们说明了一件事设计不再只是给人看的稿子也开始变成 Agent 可以读取、传递和复用的上下文。Google 官方在介绍 Stitch 时提到Stitch 可以从 URL 中提取设计系统也可以使用新的 DESIGN.md。DESIGN.md 是一种 agent-friendly 的 Markdown 文件用来在 Stitch 与其他设计、编码工具之间导入或导出设计规则。这个点很有意思。过去我们提到设计系统更多会想到 Figma 组件库、颜色规范、字体规范、间距规则。这些东西当然有价值但它们很多时候是“人看了之后再理解”。而 DESIGN.md 这种形式明显更适合被 AI 消费。它可以把一个产品的设计规则写成结构化文本比如这个产品的主色是什么按钮风格是什么卡片应该有什么圆角页面整体是偏极简、偏专业还是偏活泼。这让我想到开发领域里已经很常见的一些文件。README.md 帮开发者理解项目。OpenAPI Schema 帮系统理解接口。AGENTS.md 或类似约定文件可以告诉 Coding Agent 这个项目的规则。而 DESIGN.md 则可以理解成告诉 Agent 这个产品应该长什么样。当设计规则可以被写进一个 Markdown 文件里事情就变得不一样了。你不再只是把一张设计稿发给别人然后让对方靠经验理解。你可以把设计风格、组件规则、视觉约束一起交给下游工具让 Coding Agent 在生成页面时尽量遵守这些规则。这就是 Stitch 2.0 和 Agent 工作流发生关系的地方。再看 MCP。Stitch 的官方文档里提到可以通过 Model Context Protocol 连接 IDE 和 CLI。这意味着 Stitch 不只是停留在自己的设计画布里而是有机会接入开发者真实使用的工具环境。想象一个更完整的链路你在 Stitch 里用自然语言生成一个后台页面Stitch 根据当前设计生成 DESIGN.mdCoding Agent 读取这个设计上下文 然后在项目里生成对应的前端组件、页面结构甚至根据页面需要反推接口字段。这个流程现在可能还不会那么丝滑但方向已经很清楚了。过去设计到开发之间有一个很重的“翻译层”。设计师交付页面前端理解页面前端拆组件后端补接口接口字段对不上再沟通交互状态没讲清楚再改一轮。而当设计资产可以通过 DESIGN.md、MCP 这类形式进入 Agent 工作流之后设计稿就不再只是一个“视觉参考”而可能变成后续开发可以直接消费的上下文。这也是我认为 Stitch 2.0 最值得关注的地方。写在文后期待您的一键三连如果有什么问题或建议欢迎在评论区交流