Internal survey session, 2026-04-21
GPT-Image-2 的 UI mockup 生成能力在社交媒体上引发大量讨论，但一张静态图片本身的商业价值有限。真正的问题是：AI 正在改变 UI 设计的哪些成本结构？哪些环节已经被改变，哪些还没有？市场上十几款产品各自切的是哪一段？
本文先从设计工作流中的具体场景出发，提炼出三个驱动成本的底层机制，然后用这三个机制作为坐标系去理解 AI 工具的解题思路和竞争格局。
场景一：一个创始人告诉设计师”我想要更高级的感觉，参考 tessellate2d.com 那种”。设计师打开参考网站看了一遍，觉得理解了，花三天做出高保真设计稿。创始人看了说”不是这个意思，我要的是那种深色背景的科技感，不是这种扁平的企业感”。三天白费，从头来。问题出在哪？不是设计师能力不够，而是”高级感”这三个字能承载的信息量太少了。创始人脑子里有一个具体的画面，但语言无法精确传达这个画面，只能传达一个模糊的方向。设计师基于这个模糊方向去做了一个具体的实现，两者之间的偏差只有在实现完成之后才暴露。
场景二：设计师在 Figma 中花了两天做好了一个落地页的高保真设计，整体方向获得了认可。但在评审时，产品经理指着 hero section 说”这里我希望有一个从下往上渐入的动画，数字部分要有计数滚动效果”。设计师没法在 Figma 里展示这个效果，只能用文字标注”scroll-triggered fade-in, counter animation”。两周后前端开发者实现出来，动画的速度、缓动曲线、触发时机都和产品经理想象的不一样。又一轮修改。问题在于：Figma 只能表达静态画面，动态行为没有低成本的表达方式，只能等到代码写完才能看到真实效果。
场景三：高保真设计通过评审，进入开发阶段。设计稿里有一组
glassmorphism 卡片（半透明背景 + backdrop-blur），在 Figma 中用 blur
滤镜模拟。前端开发者需要把这个视觉效果翻译成
CSS：background: rgba(255,255,255,0.04); backdrop-filter: blur(20px); border: 1px solid rgba(255,255,255,0.08)。Figma
描述的是”这个东西长什么样”，代码描述的是”怎么让浏览器画出这个东西”。两种语言之间的翻译需要开发者手动完成，每个组件都要翻译一遍。
场景四：网站上线后，创始人看着实际效果说”整体氛围其实不太对，我觉得应该更暗一些，文字层次要更分明”。这是一个方向性的调整，但在代码层面意味着改几十个颜色值、调整十几处间距和字体大小。如果这个反馈发生在 moodboard 阶段，改方向只需要换几张参考图。但同样的反馈发生在代码阶段，成本大了两个数量级。
这些场景看起来各不相同，但背后有共同的驱动力。UI 设计工作流之所以贵、之所以慢、之所以容易返工，归根结底是三个机制在起作用。
机制 A：格式转换的手工性。
设计过程是一条从模糊到精确的路径：脑中的感觉 → 文字描述 → moodboard → 线框图 → 高保真设计 → 可交互原型 → 生产代码。每一步都是一次格式转换，每次转换需要专门的人用专门的工具做手工翻译。moodboard 不能自动变成 Figma 文件，Figma 文件不能自动变成代码。场景三就是这个机制的典型体现：设计师用 Figma 的视觉语言描述了一个效果，开发者需要手动翻译成代码语言。每次翻译都引入延迟（等人排期）、损耗（信息在翻译中丢失）和偏差（两个人对同一个视觉效果的理解不同）。
机制 B：保真度和可修改性的反相关。
表达得越精确的东西，修改起来越贵。一句”我想要暗色科技感”可以瞬间改成”我想要暖色学术感”，但一个花了三天做的 Figma 设计稿做同样的调整需要再花两天，一个已经上线的网站做同样的调整可能需要一周。场景一和场景四都是这个机制在作用：设计意图需要到高保真阶段才能被验证（因为”感觉”只有看到具体画面才知道对不对），但高保真的东西改起来很贵。这制造了一个两难：不做高保真就无法确认方向，做了高保真又面临方向性返工的风险。
这个机制是整个设计工作流中最根本的张力。传统做法是用分阶段交付来管理风险（先低保真确认方向，再高保真细化），但代价是流程变长、每个阶段之间都有翻译成本（回到机制 A）。
机制 C：跨介质沟通的带宽限制。
设计师、产品经理、创始人、开发者之间需要传递设计意图，但每种沟通介质都有带宽天花板。语言能传达意图和方向，但不能传达具体的视觉效果（场景一：“高级感”三个字对不同人意味着完全不同的画面）。静态图能传达视觉，但不能传达动态行为（场景二：Figma 无法表达 scroll animation 的时序和缓动）。可交互原型能传达行为，但生产成本高到大多数团队只在关键节点才做。没有一种介质能同时做到低成本、高保真和完整表达。
场景二同时体现了机制 B 和机制 C：产品经理想要的滚动动画，在 Figma 中无法表达（机制 C 的带宽限制），只有等代码写完才能验证（机制 B 的高保真才能确认），而代码阶段的修改成本很高（机制 B 的修改代价）。
三个机制不是独立的，它们构成了一个互锁的三角：解决任何一个机制都会把压力转移到另外两个上。
具体来说：
你想解决机制 C（说不清楚意图）→ 就得用高保真介质来表达 → 触发机制 B（高保真的东西改不起）。场景一里，如果创始人能拿出一张精确的视觉参考图而不是说”高级感”三个字，沟通问题就解决了。但这张图本身需要花时间做出来，做出来之后改方向又很贵。
你想解决机制 B（让高保真也能改）→ 要么做多个版本平行探索 → 触发机制 A（每个版本都要手工转换一遍，成本线性增长）。场景四里，如果要同时试三个配色方向再选最好的，就得把三套从设计到代码的流程各走一遍。
你想解决机制 A（自动化转换，跳过中间格式直接到代码）→ 代码是最难沟通修改意图的介质 → 触发机制 C（怎么跟开发者说清楚”我想要的滚动效果”？）。场景二里，即使 AI 能直接生成代码跳过 Figma，产品经理想要的动画效果仍然只能等代码跑起来才能验证。
三个机制互相强化，把设计团队困在一个成本陷阱里：花大量时间在翻译、等待和返工上，真正用于探索和创造的时间比例很低。理解了这个陷阱的结构，就能理解为什么 AI 工具们各自选择了不同的切入点，以及为什么没有一个工具能同时解决所有问题。
这是 AI 进展最显著的一个机制。两条路径在同时推进。
第一条路径是自动化翻译：保留原有的格式阶梯，但让阶梯之间的翻译自动化。Builder.io / Visual Copilot 的 component mapping 机制（把 Figma 组件映射到代码库中已有的真实组件）和 Figma MCP Server（让 Claude Code 直接读取 Figma 设计文件的色值、间距、组件结构）已经把 Figma→代码的翻译工作量减少了 30-60%。Figma 自己的 Make 功能也在做同样的事。对于有成熟 design system 的团队，翻译损耗已经从主要瓶颈降级为次要问题。
第二条路径更激进：跳过中间格式。Vercel v0、Bolt.new、Lovable 直接从自然语言生成可部署的代码，完全绕过了 Figma 设计稿和交互原型这两个中间阶段。Claude Code 同样可以从文字描述直接生成前端代码（我们的 QuackTech Innovation 网站——1530 行 HTML/CSS/JS，含 glassmorphism、粒子动画、scroll animation——就是 Claude Code 一次性生成的）。对于展示类网站，这条路径已经成熟可用。
局限在哪： 自动化翻译依赖 Figma 文件的组织规范程度，没有 design system 的团队获益有限。跳过中间格式的路径在展示类页面上效果好（Bolt.new 的 landing page 成功率 92%），但在复杂应用上成功率显著下降（复杂 SaaS 降到 31%），因为复杂应用的信息量超出了自然语言能精确传达的范围。
没有 AI 工具直接解决了这个机制（它接近物理定律级别的约束），但有两种间接缓解的方式。
第一种是让高保真变便宜。Google Stitch 的无限画布可以一次 prompt 生成五个方向的高保真 UI，让探索成本的边际递减趋近于零。v0 和 Bolt.new 能在分钟内生成一个高保真页面。当高保真的生产成本降到足够低时，同时做三个方向不再需要三倍时间，保真度-灵活性的两难就松动了。
第二种是创造新的保真度位置。GPT-Image-2 通过 ChatGPT 多轮对话，可以生成视觉保真度很高的 UI mockup 图片，同时保持极低的修改成本（对话中说一句”蓝色太亮了”就行）。这在传统的 spectrum 上创造了一个以前不存在的位置：高视觉保真、低修改成本、零可执行性。设计意图可以在这个位置上反复迭代，直到方向确认，再一步跳到代码实现。
局限在哪： 生产成本下降不等于修改成本下降。一个 AI 生成的高保真页面，方向不对时最经济的做法往往是推倒重来而不是在已有基础上改，因为 AI 目前更擅长从零生成，不太擅长保持整体一致性的同时做局部深度修改。对于已经积累了大量业务逻辑的项目，推倒重来不是选项，AI 需要的能力是保持 90% 不变、精确改 10%，这在代码层面比图像层面更难。
这是三个机制中 AI 进展最小的一个，也因此可能是下一个高价值切入点。
两个子问题在这个机制下特别突出。
第一个是动态行为的表达。scroll animation、page transition、hover microinteraction、loading skeleton 在整个设计流程中都没有低成本的表达方式。设计师在 Figma 中只能用静态帧暗示”这里应该有一个渐入动画”，产品经理只能用”我想要那种丝滑的感觉”来描述期望。实际效果只有等代码写完才能看到。Framer AI 的动画支持是这个方向上做得最好的，但它的适用范围严格限于网站，动画复杂度上限有限。Claude Code 可以生成动效代码，但前提是你能用语言精确描述想要的效果，而大部分人做不到。
第二个是模糊反馈到精确修改的转译。设计评审中大量的反馈是感觉层面的（“这里太密了”“不够透气”“整体氛围不太对”），但修改需要在像素或代码层面执行（间距从 16px 改为 24px，背景色从 #0a0e1a 改为 #0d1225）。这个从模糊到精确的转译完全依赖设计师的理解力和经验。AI 工具在这里几乎没有存在感。
为什么难： 机制 C 的难度在于它和机制 B 互锁。动态行为之所以难以沟通，不仅因为缺少表达介质（机制 C），还因为唯一能完整表达动态行为的介质（可运行的代码）修改成本很高（机制 B）。要打破这个互锁，需要一种既低成本又能传达动态行为的新介质，目前还没有出现。
| 机制 | AI 进展 | 代表产品 |
|---|---|---|
| A. 格式转换的手工性 | 大幅削弱 | Builder.io（自动翻译）、v0/Bolt.new/Lovable（跳过中间格式）、Claude Code |
| B. 保真度-可修改性反相关 | 间接缓解 | Google Stitch（高保真变便宜）、GPT-Image-2（创造新的保真度位置） |
| C. 跨介质沟通带宽 | 几乎未触碰 | Framer AI（有限的动画支持） |
一句话概括：AI 在 2026 年 4 月主要解决了生产端的效率问题（做得更快了、翻译更省了），但沟通端的问题（怎么说清楚想要什么、怎么把模糊反馈变成精确修改）进展有限。
市场上十几款 AI 设计工具看起来各做各的，但用上面的三角结构去看，它们其实在回答同一个问题：设计工作流会怎么演化？ 每家的答案不同，这些答案可以归为三种赌注。
Figma AI 和 Builder.io 代表了这个方向。它们的共同假设是：设计的核心价值在于品味判断和系统性思考，这些能力短期内 AI 做不到。AI 的角色是接管执行劳动（搭建布局、翻译成代码），让设计师专注在它们做不到的事情上。
这个赌注在三角中的位置很清楚：主要攻克机制 A（自动化翻译）。Figma 的 First Draft 把空白画布到初稿的时间从小时压缩到分钟，Make 把设计稿到代码的翻译自动化。Builder.io 的 Visual Copilot 做得更精准：component mapping 机制能把 Figma 组件映射到代码库中已有的真实组件，而不是重新生成。Fusion 1.0 甚至可以直接从 Slack/Jira ticket 生成 PR。
这个赌注的隐含代价是：它不改变三角的结构，只是让三角的某些边变短。设计师仍然需要在 Figma 中做高保真设计（机制 B 不变），团队仍然通过静态设计稿沟通意图（机制 C 不变）。如果这个赌注对了，Figma 的护城河会进一步加深。如果 AI 最终能做出足够好的品味判断，这条路就会被绕过。
Vercel v0（600 万开发者，$42M ARR）、Bolt.new 和 Lovable 代表了一个更激进的判断：对于大量场景，设计阶段本身是不必要的。组件系统（shadcn/ui + Tailwind）的审美质量已经足够高，开发者用自然语言描述需求就能直接得到质量可用的界面。
这个赌注在三角中的位置：直接消除机制 A（不需要翻译，因为根本没有设计文件），同时绕过机制 B（没有高保真设计稿，也就不存在修改成本高的问题）。代价是把所有压力转移到了机制 C 上：你只能用自然语言描述你想要的东西，如果描述不精确，生成的结果就不对，而你修改的方式还是用自然语言描述一遍。
三个产品面向不同人群：v0 面向 React 开发者（code-first，技术栈锁定在 React + Next.js），Bolt.new 面向全栈需求（浏览器内编译运行，前后端+数据库），Lovable 面向非技术创始人（conversation-first，Supabase 深度集成）。它们共享的局限是视觉趋同：生成的界面都长差不多（蓝色强调色、Inter 字体、侧边栏布局），适合功能性界面，不适合需要品牌差异化的产品。解决的是功能可用性问题，不是视觉辨识度问题。
这个赌注还有一个成功率的边界。Bolt.new 在 landing page 上的成功率是 92%，但在复杂 SaaS 应用上降到 31%。自然语言能精确传达的信息量存在上限，超过这个上限（多状态、多屏、复杂交互），跳过设计阶段的代价就开始显现。
这个赌注最激进。它认为设计和开发之间的分工本身就是历史遗留问题，在 AI 时代应该被消除。
Claude Design 是这个方向上平台意图最清晰的产品。Claude Design 在 2026 年 4 月 17 日上线，表面定位是让没有设计能力的人（founder、PM、GTM 团队）获得第一个视觉表达。但它和 Claude Code 之间的 handoff bundle 机制暴露了更大的意图：从想法到原型（Design）到实现（Code）到协作（Cowork），Anthropic 正在构建一条全部留在自己平台内的完整通道。Mike Krieger 在 Claude Design 发布三天前辞去 Figma 董事会职务，这个时间点不是巧合。
Claude Design 在三角中的位置很独特。它不是在攻克某一个机制，而是在试图让三角本身变得不相关：如果从想法到可运行产品只需要一轮对话，那么格式转换（机制 A）不存在了，高保真的修改成本（机制 B）也不再是瓶颈（因为重新生成比修改更便宜），沟通带宽限制（机制 C）被 AI 的理解能力部分吸收了。这条路能走多远取决于 AI 的设计判断力能提升到什么程度，但方向是明确的。
Framer AI 从另一个角度消除设计-开发边界：让设计师在同一个环境中完成高保真设计和代码发布，产出物直接就是线上网站。画布接近 Figma 的自由度，动画和交互是一等公民。它是唯一一个认真对待机制 C 的产品（动画可以在设计环境中直接预览和调整），但适用范围严格限于网站。
Google Stitch 则从探索成本入手。它的 Vibe Design 概念让高保真探索的边际成本趋近于零：一次 prompt 生成五个方向，用语音输入做实时调整，Annotate 功能允许直接在生成的 UI 上画圈标注让 AI 修改。完全免费（每月 550 次生成），支持七种框架代码导出。它的战略逻辑和 Claude Design 类似（用设计入口引流到 Google 开发生态），但作为 Labs 实验产品，长期稳定性存疑。
GPT-Image-2 不属于上面任何一个赌注，因为它本身不是设计工具。它输出的是图片，不是代码、不是 Figma 文件、不是可交互原型。但在三角结构中，它做了一件别人做不到的事：在高保真视觉表达和低修改成本之间创造了一个新的平衡点。
关键在于 ChatGPT 的多轮编辑能力。用户生成一张 UI mockup 后，可以用画笔或矩形工具选中局部区域，用自然语言描述修改（“把这个按钮的颜色改成蓝色”“左边加一列导航栏”），模型只动选中部分，保持其余内容一致。整个过程是增量的：不需要每次重新描述整个画面的构图和风格，只描述变化。这更接近在 Figma 中操作的心智模型，只是交互介质从鼠标拖拽变成了自然语言+区域选择。
Gemini 的图像模型（Nano Banana Pro）也支持多轮编辑，但在两个维度上落后于 ChatGPT。第一是迭代一致性：ChatGPT 在多轮编辑中对面部和细节的保持更稳定，Gemini 连续编辑多轮后更容易出现漂移。第二是速度：GPT-Image-2 单张生成通常 10-25 秒，Nano Banana Pro 约 20-40 秒，在需要几十次迭代的设计探索场景中这个差距被放大。
这个能力的意义在于：过去一个视觉方向可能只能尝试 3-5 个变体（因为每个变体要么从头 prompt、要么在 Figma 中手动修改），现在同样时间可以跑 20-30 个，筛选面更宽，决策质量更高。Figma、Canva、Adobe 已经在集成 GPT-Image-2 的 API，说明行业判断这种能力足以嵌入生产工具链。
GPT-Image-2 的战略意义不在于自身，而在于它和下游工具的衔接。如果 Claude Code 能从一张视觉方向图直接生成风格一致的网页，那 GPT-Image-2 + Claude Code 就构成了一条从脑中感觉直接跳到生产代码的两步通道，完全绕过 Figma 和原型。这条通道对展示类网站已经可行。
三种赌注分别覆盖了三角的不同部分，但有一个区域几乎没有人在做：机制 C 中难度最高的两个子问题，动态行为的设计和模糊反馈的转译。
目前没有一种低成本的方式让非开发者精确表达”我想要这种滚动动画”。也没有一种工具能把”这里太密了”这种感觉层面的反馈自动转化为间距 16px→24px 的精确修改。这两个问题之所以难，是因为它们卡在机制 B 和 C 的互锁点上：唯一能完整表达动态行为的介质（可运行的代码）修改成本很高，而低成本的介质（语言、图片）又无法传达动态行为。
谁能在这个互锁点上找到突破，谁就切入了一个目前没有竞争的市场。
contexts/survey_sessions/20260421_gpt_image2_ui_mockup_landscape.mdadhoc_jobs/heyu_research/company_website/docs/design_spec.mdadhoc_jobs/heyu_research/company_website/src/index.html