本文的测试框架与核心结论参考了徐红兰文章的研究，文章原文如下：

AI 会取代UI吗？至少Stitch 现在还不行

一、全文速览图这两天，我认真测了下刷屏的 Google Stitch。

一、全文速览图

3分钟生成UI源文件！实测谷歌最新UI设计神器Google Stitch

大家好，我是言川。

想象这样一个场景：下午六点，设计师还在改稿。产品经理的消息又弹了出来：“这个登录页再出一版吧，要温暖友好一点。”

温暖友好？这个词怎么落地？

设计师打开 Google Stitch，输入一句“给我一个温暖友好的登录页面”。

几分钟后，三个方案摆在了眼前。乍一看，挺像那么回事。

但仔细一瞧，问题就来了：按钮圆角不一致，标题和副标题的间距有点怪，“温暖友好”的氛围是有了，可整体排版总觉得哪里不对劲。

改了三版，又花了20分钟微调。最后，还是得打开Figma，手动调整半小时才算交付。

这不是科幻，而是现实。Google Stitch确实能帮你快速出稿，但距离“一次生成就能用”，还有一段不短的路要走。

今年三月，Google Labs扔出了这枚冲击波。消息一出，Figma股价当天应声下跌8%。设计圈再次炸开了锅：设计师又要失业了吗？

经过三天、超过四十次的密集测试，并将Stitch放入真实的设计链路中反复验证，结论其实很清晰：它是目前顶级的方案发散工具，但还接不了严谨的落地设计。设计师不必过度焦虑，但必须正视它的存在。

二、它到底是什么？不是画图工具，是“AI原生设计画布”

先别急着焦虑，关键是要搞清楚这玩意儿到底是什么。

Google Stitch不是Midjourney那样的画图工具，也不是Figma的替代品。官方的定位很明确：AI原生的软件设计画布。

这到底是什么意思？

传统的UI设计，你得从一张空白画布开始，拖拽组件、调整间距、选择配色、搭建层级。一个首页，即便是熟练的设计师，也得花上半天时间。

Stitch的逻辑则完全不同：你说人话，它给你画。

输入“做一个健身追踪App的首页，深色主题，要有仪表盘、训练计划、数据图表，风格现代简约”。

47秒后，一个高保真原型就呈现在眼前。

这背后的核心概念叫做“氛围设计”（Vibe Design）——你只需要描述感觉、目标和氛围，无需纠结于圆角12px、间距24px或主色#3B82F6这些具体参数。AI会帮你把抽象的感觉转化为具体的界面。

说到氛围设计，就不得不提另一个概念：“氛围编程”（Vibe Coding）。

这个概念由Andrej Karpathy在2025年提出，指的是用自然语言编写代码，不是敲键盘，而是“说”出你想要的功能。Cursor、Claude Code等工具让这个概念火了起来。

氛围设计遵循同样的逻辑，只是场景从“说代码”换成了“说设计”。一个口述需求，AI写后端逻辑；一个口述界面，AI出钱I稿。设计与开发之间的边界正在变得模糊。Google甚至为Stitch设计了MCP集成，能够直接与Cursor、Claude Code等开发工具打通：

设计稿可以导出为DESIGN.md文件，开发工具直接读取，真正实现了从“氛围设计”到“氛围编程”的无缝衔接。

这才是真正令人兴奋的地方：不是某个工具要替代谁，而是整个创作流程正在被重新定义。

Stitch提供了三种模式，各有其用武之地：

三、实测环节：越自由越强，越约束越笨

光说不练假把式。为了模拟真实设计链路中的不同场景，我们设计了三组测试。

测试下来，发现了一个有趣的规律：Stitch的表现与你给出的约束成反比——给它的自由度越高，它表现越亮眼；约束越多，它反而显得越“笨拙”。

A组：纯文本生成，表现最亮眼

这组测试是网上最容易刷到、也最容易让人发出“哇塞”惊叹的部分：输入一段提示词，几秒钟出图。

我们分别测试了一个C端首页和一个B端工作台首页。

C端首页测试：

提示词：“设计一个健身App首页，深色主题，包含今日训练概览、卡路里消耗仪表盘、快速开始按钮和底部导航栏。风格现代简约。”

生成结果：整体氛围、模块关系、视觉节奏都相当顺畅。深色主题的渐变处理到位，仪表盘的环形进度条也呈现了出来，底部导航图标统一。第一眼看去，确实有“成熟App首页”的感觉。

B端工作台测试：

提示词：“设计一个健身后台管理系统，包含数据看板、会员管理、课程排期、支付流水等模块。左侧导航，右侧内容区。”

生成结果：左侧导航层级清晰，右侧数据看板的图表组件有模有样。虽然部分排版细节还略显粗糙，但“后台管理系统的气质”已经出来了。

这组测试说明了什么？

当Stitch拥有完全自由的发挥空间时，它能快速将抽象需求视觉化。无论是C端还是B端，都能给出“70分起步”的方案——不完美，但足以作为讨论的起点。

这也是为什么那些演示视频看起来都很厉害：它们大多使用的就是这种无约束场景。

B组：给原型约束，它开始“变笨”了

这组测试最为关键，因为它更接近真实的工作场景。

在真实项目中，设计师往往不是从零开始。产品经理会给出原型图，业务方会提供字段表，技术团队会提出约束条件——设计师的核心任务是在这些既定框架下，把页面真正设计好。

我们做了什么？将A组生成的高保真页面，抽取其布局结构，制作成低保真原型图，再喂给Stitch，让它根据这个原型重新生成设计。

问题立刻暴露无遗：

先看C端页面。

首页信息密度不均匀：头部信息展示过于密集甚至出现遮挡，下方内容则较为分散，导致阅读困难。页面一致性较差：部分数据字体过小，背景对比度低，不同页面间样式颜色不一致，影响了可读性。中文支持有限：即便提供了全中文需求说明和低保真原型，生成结果仍出现中英文混杂，需要多次二次处理才能完成。

问题不在于它“不会做”，而在于它只能把原型“做出来”，却做不到把原型真正“设计好”。

再看B端页面，问题更加明显。

它没有根据低保真原型与需求文档进行合理设计，例如导航区出现了左侧导航与顶部导航的重叠，主要功能按钮被放在了页面左下角，这不符合用户常识。几个模块之间的布局关系，只是简单的豆腐块堆砌，卡片+卡片+卡片，像极了UI新手，完全没有进行信息层级的优化。面对稍微复杂一点的产品需求，其能力基本失效，只会把PRD中的功能点逐条映射成UI元素，完全不会进行产品需求的拆解、信息分层和交互路径收敛……基本不具备用户体验设计的能力。

需要指出的是，这次喂给它的原型已经是相对规整的版本了。真实项目中的原型往往更混乱、更零碎、信息密度更高。如果把那种原型丢进去，效果只会更不理想。

关键洞察：

一旦进入“有结构约束”的阶段，Stitch的能力便明显下降。它不再像一个会主动思考的设计师，更像一个机械执行的工具。

从“设计”退化成“执行”，这是质的差距。

C组：高保真参考下，完成度回升

我们又换了个思路：拿A组里已经生成的高保真页面作为参考，让它在此基础上进行重新设计。

上方为重新设计前，下方为重新设计后，结果比B组要好看很多。

无论是C端还是B端，Stitch都能较好地保持页面的整体气质、视觉统一性和完整度。配色协调，组件风格统一，布局也较为合理。

但问题同样明显：它更像是在“重绘”，而不是“重构”。

什么是重绘？你给它一个成熟的界面，它换个配色、调个间距，输出一个风格相近的新版本。

什么是重构？理解业务逻辑，判断信息优先级，重新组织页面结构。

Stitch目前能做到前者，但做不到后者。它会“模仿得像”，但不一定“理解得透”。

此外，在导出至Figma后，图标等方面会出现一些问题，例如面性信息消失，完全变成线性图标等。下图左侧为Figma设计稿，右侧为Stitch生成页面。

一个有趣的补充发现：其原型理解能力与从零到一生成能力之间的差距非常明显。

前面几组测试越来越让人确信：Stitch不太擅长从原型出发，稳定地输出成熟页面。

然而，当我们换个任务——不是“根据原型做设计”，而是“尽量复刻已有设计稿”时，它的表现却出乎意料地差。

我们拿了一张成熟的B端商家后台首页截图，让它进行复刻。

结果令人失望：

布局结构的还原度很低，组件层级混乱，间距和对齐完全不符合规范。更糟糕的是，复刻出来的页面无法直接使用，图层没有分好，图标和文字导出至Figma后出现部分适应性问题，完全无法投入实际使用。

这件事特别有意思。它说明Stitch不仅不擅长“理解原型”，甚至连“模仿已有设计”都做得很差。

换句话说，它目前更像一个低效的页面生成或复刻工具，而不是一个成熟的原型到设计稿的转换工具。这样的能力可能只适用于非常简单的场景，比如快速模仿某个设计或数字化纸质草图，但在实际应用中几乎没有什么价值。

三组测试总结：

一句话概括：Stitch最擅长的，是在没有太多约束的时候，快速把设计方向跑出来。

四、对不同角色的价值：谁最该用？

产品经理：杀手级应用

这可能是Stitch价值最高的用户群体。

产品经理最大的痛点在于：如何把脑子里的想法快速变成可以被感知的形态。过去要么画线框图（低保真，沟通成本高），要么等设计师出图（高保真，等待成本高）。

Stitch提供了第三条路：10分钟内，产出一个视觉完整度相当高的界面，可以直接拿来与设计师、开发、业务方沟通。

尤其是其草图转UI的功能——在白板讨论会上画出的布局，当场就能变成高保真界面，效率提升是质的跨越。

设计师：正视但不焦虑

客观地说，Stitch对UI设计师的冲击是真实存在的。

一个产品经理借助Stitch，在设计师出图之前就能拿出一个“差不多的方案”——这势必会改变产品与设计之间的协作方式。

但这个冲击更多集中在初级、重复性的工作层面：标准化页面、常见布局、规范组件套用……这些工作Stitch确实做得越来越好。

而设计师真正的价值所在——品牌一致性、用户情感体验、细节打磨、设计系统建设——这些恰恰是Stitch目前完全无法触及的领域。

设计师应该做的，是把从Stitch这类工具中“省出来的时间”，投入到它做不了的事情上。

前端工程师：影响有边界

Stitch生成的代码，可以减少一部分页面还原的工作量。

但工程师的核心价值在于：性能优化、工程架构、复杂交互逻辑、代码可维护性……这些都不是Stitch能替代的。

更可能的未来是：前端工程师的工作重心，会从“编写UI代码”逐渐转向“审查AI生成的代码并做工程化处理”。

独立开发者/一人公司：效率放大器

如果你是一个人在做产品，Stitch是一个巨大的效率放大器。

不需要雇佣UI设计师，不需要漫长等待，你的产品想法可以以极低的成本快速变成可以展示的界面。结合“氛围编程”工具，一个人可以在极短的时间内，跑通从界面设计到功能实现的完整链路。

五、设计师的未来：不只是焦虑

说到这里，回归开头的问题：设计师该慌吗？

目前的答案是：不必焦虑，但必须正视。

角色转变不可避免

设计师的角色正在从“手工实现者”转向“质量把关者”，从“画图的人”转向“设计策略制定者”。

标准化页面、常见布局、规范组件套用——这些工作AI确实做得还不错。但AI做不了的还有很多：如何通过细节调整塑造品牌独特的联想性，如何在整体流程中带动用户的情感体验，如何进行整体架构的细节打磨和设计系统建设。

而这些，才是设计师未来的核心竞争力。

设计师该学什么？

提示词工程： 如何与AI高效对话，如何将抽象需求转化为具体描述。未来这可能是一门必修课。

设计系统思维： 将规范转化为可复用的资产，而不是每次都从头开始。Stitch的DESIGN.md功能正是为此设计的。

产品思维： 理解业务，而不仅仅是执行界面。知道“为什么设计”，比知道“怎么设计”更重要。

跨界能力： 懂点代码，懂点数据，懂点商业。能力边界越宽，被替代的可能性就越低。

或许可能出现的新职业：

“提示词设计师”： 专门优化AI设计输出的人。他们不画图，而是“指导AI画图”。

“设计系统架构师”： 管理跨项目的设计规范，将品牌语言转化为AI可读的格式。

“AI设计审核师”： 把关AI生成的质量，在AI输出和最终交付之间架起桥梁。

这些职业现在或许还不常见，但三五年后，很可能成为行业标配。

行动建议

现在就去体验Stitch，别等它成熟了再学。 工具会不断演变，但“会用工具的人比不会用的人更强”这个规律不会变。趁现在免费，趁它还处于Labs阶段，赶紧熟悉它。

把省下的时间投入AI做不了的事情上。 创意、策略、用户洞察、品牌建设——这些是AI暂时无法触及的领域，也是设计师构建护城河的关键。

把自己从“画图工具人”升级成“设计决策者”。 目标不是执行需求，而是定义方向；不是画界面，而是解决问题。

最后，有一点是确定的：Stitch所代表的方向是不可逆的。从“想法”到“界面”的距离会越来越短，从“描述”到“代码”的门槛会越来越低。

这不是某一个工具的问题，而是整个设计和开发工作方式正在发生的结构性变化。

就像当年Axure让产品经理可以自己制作原型一样，Stitch可能正在做同样的事情——让设计师的表达和实现能力再向前跨越一步。

这一步，值得迈出。