UI开发这份活儿，干过的人都知道，最烦的不是业务逻辑，而是把一张像素级的设计稿一点一点翻译成HTML/CSS。坐标、间距、字号、圆角，一个像素不对，视觉那边就能盯你一整天。哪怕有设计稿标注和设计软件导出的标准，实际写起来依然是一堆体力活。正因如此，UI2Code——也就是把UI设计稿自动转换为前端代码——才能在这么多AI方向里一直保持超高的关注度。
我最近花了大把时间在折腾这个方向，尤其是论文标题里那个很长的概念："Test-time Scalable Interactive UI-to-Code Generation"。拆开看，“Test-time Scalable”是测试时可扩展，“Interactive”是交互式，“UI-to-Code”就是界面到代码。这串词放在一起翻译成人话就是：用视觉语言模型，在推理阶段投入更多计算资源，并且允许人类参与修改，把一张设计稿逐步变成一份能跑的前端代码。
听起来挺绕，但实际做完一轮之后你会发现，这个词组里每一个限定词都不是白给的。这篇文章我就沿着这个思路，把我复现、理解、踩坑的过程完整写下来。内容会覆盖几个部分：这类工具到底解决了什么问题、标题里三个关键词的技术含义、我自己搭的一套可复现工作流、以及实测中频繁踩到的坑。无论是刚接触AI前端的同学，还是已经在用代码生成工具的老手，应该都能从里面找到点有用的东西。
1. UI2Code到底在解决什么问题：先看清设计稿到代码的那条长链路
要说清UI2Code的价值，得先看看没有它之前，前端工程师拿到一份设计稿之后要经历什么。
1.1 从设计稿到代码的漫长链路
设计稿本身只是一张位图，或者说是一张带标注信息的图片。工程师拿到它之后，脑子得经历一次"翻译"：先扫一眼页面结构，判断哪块是顶部导航、哪块是内容区、哪块是侧边栏；然后看间距、字号、颜色，判断不同的模块应该用什么层级关系；接着还要考虑组件复用，比如同一个按钮在三个地方出现了，是不是应该提成一个公共组件。
这些判断对于人来说是直觉，但对自动化工具来说极其困难。传统设计稿转代码的方案可以分几个阶段看。
早期市面上有一批基于规则的工具，比如把设计稿里的切片资源导出、按图层顺序生成嵌套div。它们能处理"线框图"级别的简单页面，但遇到稍微真实一点的界面就崩了。原因很简单：设计稿的图层顺序和最终DOM结构不是一回事。视觉上并列的两个按钮，在设计稿的图层里可能是同一个组的子元素；视觉上嵌套的卡片，图层结构里却可能是散的。规则只能处理最表面的情况。
后来出现过基于模板匹配的方案，内置一堆常见组件模板，比如导航栏、轮播图、表单，然后去图片里找相似区域套模板。这种方案对"长得和模板一样"的页面还行，页面一复杂、组件一变体，模板库就变成拖累。维护模板的成本越高，方案的普适性就越差。
再往后就是现在这类基于视觉语言模型（VLM）的方案。VLM能同时理解图像和产生文本代码，这一步是质的飞跃。因为模型不再靠"规则"或"模板"去猜结构，而是像人一样看图，把看到的布局、间距、颜色、组件关系综合成一段语义丰富的代码。
这一阶段为什么能落地，核心原因是多模态大模型在视觉理解能力上确实有肉眼可见的进步。模型不再只识别"图片里有一个按钮"，而是能理解"这个按钮在页面右上角、与左侧输入框垂直居中对齐、颜色是主题色、带圆角阴影"。这种结构化理解能力，才是UI2Code能从玩具走向实用工具的底气。
1.2 为什么UI2Code值得专门投入
有人可能会问，现在前端组件库这么成熟，手写代码也没有那么慢了，为什么还要做UI2Code？
我的看法是，它省的不是"敲字符"的时间，而是"视觉转结构"的决策时间。写一个页面的CSS也许只要半小时，但判断"这个区块应该用什么语义标签、这个间距是24还是32、这个字体层级应该对应哪个token"，这些决策在每个页面上都要重新做一遍，极其消耗精力。UI2Code的价值在于把这些决策从"每次手写"变成"AI初稿 + 人工微调"。
尤其是碰到下面这几类场景，UI2Code的收益会特别明显：
- 原型验证阶段：产品经理草草画了一版流程图，需要快速变成可点击的HTML原型，UI2Code几分钟就能出初稿。
- 老项目换肤：有一套设计系统，要把旧的表格页面批量改成新视觉，UI2Code可以基于设计稿重新生成，省去一个一个div去调样式。
- 设计评审阶段：设计师想看动态效果，但又不想等开发排期，用UI2Code先把静态版本跑起来，评审效率会高很多。
- 无障碍改造：很多设计稿对对比度、焦点样式考虑不全，UI2Code可以在提示词里带上无障碍要求，让生成的代码天然带上规范。
我这次复现这个方向，目标不是做一个生产级的商业插件，而是把"Test-time Scalable Interactive UI-to-Code"这个概念真正跑通一遍，验证它在实际工作流里能做到什么水平、在哪些地方还靠不住。
2. 拆解标题里的三个关键词：Test-time、Scalable、Interactive
这篇论文标题值得逐词拆解，因为每一个词都对应着一个具体的工程选择。
2.1 Test-time Scalable：把"测试时算力"当提效资源
先说"Test-time Scalable"。这个词组翻译过来叫"测试时可扩展"，指的是模型在推理阶段可以动态增加计算量，而不是固定一次前向传播就直接输出结果。
传统深度学习里，训练阶段可以砸大量算力，推理阶段通常是越快越好。但大语言模型时代，这个观念被扭转了。推理时多给模型几次"思考"的机会、多生成几个候选、多做几步自校正，答案的质量能显著提升。OpenAI的o1系列是这种思路的典型代表，它把推理时的计算量当成了可以按需购买的资源。
UI2Code领域引入这个概念非常自然。因为"设计稿到代码"本身是一个高难度的生成任务，一次生成就直接完美几乎不可能。如果模型输出一份代码之后停下来，用户只能要么接受残次品，要么自己手改。但Test-time Scalable的思路是：让模型不过早停止，而是把"生成草稿→检查问题→修正代码"这整个循环也作为推理的一部分，甚至可以让模型生成多个版本，再用评分函数挑出最优结果。
打个比方，这就好比找人帮你翻译一篇文章。传统方案是找个翻译，一句"翻好了"交给你，错了他不管。而Test-time Scalable的意思是，你雇佣的翻译不仅翻译，还会在交稿前自己读一遍，把不通顺的句子改掉，甚至可以翻三版让你挑。人还是同一个人，但因为花的时间多了、成本高了，交付质量完全不一样。
在我的复现里，Test-time Scalable具体实现成三步：候选生成、反馈评分、迭代修正。第一步，用同一个提示词生成多个代码版本，这些版本彼此之间因为采样温度的随机性会有差异。第二步，设计一个评分函数，把每个版本渲染成截图，和原设计稿做像素级、结构级对比，挑出最接近的设计稿或最有可读性的代码。第三步，把"上一版的代码 + 评分员指出的问题"再次交给模型，让它针对性修改。
这个思路的代价也很明显——计算成本变高了。原本一次生成只要一次推理，现在可能要十几次推理才能产出最终版本。但在UI开发场景下，这个成本往往可以接受，因为人力的边际成本更高。你让高级前端工程师花一小时调样式，和让模型花十几轮推理自动调，前者用钱，后者用电，电通常比工资便宜。
2.2 Interactive：从一次性生成变成人和模型一起调代码
第二个关键词是"Interactive"，交互式。这一点的意义在于承认了一个事实：UI2Code的最优姿势不是"替代开发者"，而是"配合开发者"。
早期的代码生成工具，包括很多流行的大模型插件，交互方式基本是"用户输入描述→模型输出代码→用户复制到编辑器→发现问题→重新描述→重新生成"。这个循环有一种断裂感。因为用户在第二轮描述时，往往要花很大力气把上一版代码里的问题讲清楚，而模型并不知道它上一轮生成了什么，或者知道了但没真正理解具体哪个位置有问题。
真正的交互式UI2Code应该做到的是：用户能看到一个实时预览，直接点击预览中的某个区域，说"这个按钮往左移一点"，或者"这个区块背景色换一下"。模型拿到的是"当前的代码快照 + 局部截图 + 用户的具体修改指令"，然后只针对这个局部做修改，而不是整页重新生成。
我这次搭的Demo里，交互层是这么做的：生成的第一版代码会立刻渲染成预览页面，预览页面上每一个DOM节点都注册了点击事件。点击任何一个元素，前端会收集这段元素对应的外圈HTML、生成的截图坐标、CSS类名，然后把这些拼成一个"修改请求"。后端收到请求后，把当前完整代码、元素上下文与用户指令组合成提示词，送给模型，让模型只输出修改后的完整文件。用户不需要懂代码，只需要对着页面点一点、说一句话，就能完成一次修改。
这种交互方式的技术含量并不高，但体验差距巨大。非交互式的工具用起来像"抛硬币"，你描述一次需求，得到一版代码，不满意又抛一次。交互式工具用起来像"带着实习生做项目"，生成初稿是实习生干的，你在旁边指点哪里改、怎么改，最终产出的代码是你们共同完成的。
2.3 Visual Language Model：为什么UI2Code必须依赖多模态模型
第三个关键词给的是技术底座：Visual Language Model，视觉语言模型。UI2Code本质上是一个图像到代码的翻译任务，那么"看"的能力就不是加分项，而是必选项。
视觉语言模型的核心结构是视觉编码器 + 语言模型。图像先被切成patch，视觉编码器把每个patch转成特征向量，再和文本token一起送进语言模型做交叉注意力计算。听起来复杂，但实际效果就是：模型既能"看"图，又能"说"话。
为什么不能用传统的OCR模型加规则提取？因为UI设计稿不是纯文字。它包含大量非结构化信息：组件的嵌套关系、视觉上的空白区域、圆角、阴影、色彩渐变、图标与文字的排列方式。这些信息要转化为代码里的div层级、flex布局、padding、margin，就需要模型具备对"空间结构"的理解能力。普通OCR是把图像变成文字，而UI2Code需要把图像变成"结构"，这是维度的差异。
实测下来，当前主流的开源VLM模型在UI理解上有一个共性特点：对小规模布局的识别准确率很高，比如两三个按钮加一个输入框的搜索栏，模型能一次写对。但随着页面元素增多、嵌套层级加深，模型的视觉注意力会开始分散。最好的解决办法是预先对设计稿做区域划分，把大图拆成小图，逐个区域生成再合并。这其实也印证了"交互式、可扩展"的必要性：模型单次能力有上限，但通过迭代、拆分、反馈，能把能力上限撑高。
3. 搭建一套可复现的UI2Code工作流：从环境到交互闭环
光讲概念没用，我这次完整搭了一套可复现的环境，下面把每个环节记录下来。这套东西技术栈不复杂，核心就是用视觉语言模型做生成，外加一段交互相应脚本做调度。
3.1 环境和模型准备：选一个视觉语言能力扎实的VLM
先说环境。我的做法是Python后端加Node.js前端预览，Python负责调用模型、解析输出、管理多轮对话状态，Node.js负责把生成的HTML渲染成可交互预览页。如果你只是想快速验证，完全可以只用Python一个脚本跑通生成与修改，预览环节用浏览器打开生成的HTML文件就行。
模型选择上，我用的一个思路是：不要盲目追求最强模型，而是要选一个视觉理解稳妥、输出代码格式稳定的开源视觉语言模型。我这次实测用的是国内社区可以直接访问的某开源多模态模型系列，参数量不大，但视觉编码器表现扎实，尤其对UI这类高密度结构化图像的细节捕捉比通用模型好。如果你的环境能调用商业闭源模型，效果会更稳，但成本也会上来。我建议第一次跑通流程时先用开源模型，等确认交互流程没问题，再切换到更强的模型。
依赖层面用到的核心库有：图像处理库（用于设计稿预处理）、多模态推理库（用于加载模型和生成）、以及基础的HTTP服务框架。命令大致长这样：
pip install pillow torch transformers flasktorch和transformers那套加载模型的流程，只要是接触过大模型的同学应该都不陌生。加载模型时注意显存占用，7B级别模型用半精度加载大概需要8GB显存左右，如果你只有单张入门级显卡，可以把图像分辨率调低一点，减少输入token数。
3.2 输入预处理：设计稿不是直接丢给模型就完事
很多人第一次用UI2Code，顺手就把设计稿原图丢给模型，产出的代码经常结构一塌糊涂。我踩了几次坑之后总结出一个经验：设计稿喂给模型之前，预处理步骤至少决定了一半的成败。
第一件要做的事是统一输入格式。把不同来源的设计稿（PNG、JPEG、导出的PDF截图）全部转成RGB模式的PNG，尺寸调整到模型输入要求范围内的合适大小。注意，不要直接等比例压到很小，否则间距和文字细节会糊成一片。我的经验是先看设计稿原始宽度。如果宽度超过1400像素，那就先等比缩放到1400以内，并把高度裁切到合理范围。设计稿底部如果有空白或标注区，直接裁掉，让模型把所有注意力放在真正的UI区域。
第二件要做的事是添加辅助信息。纯粹一张设计稿，模型能理解，但对间距的具体像素值、对齐关系，它只能靠"目测"。如果能在预处理时把设计稿叠一层坐标网格线，或者把关键组件的区域用彩色框标出来，模型的空间判断准确率会提升一个档次。我写了一个简单的标注脚本，可以在设计稿的四边标记像素坐标刻度，或者在每个视觉区块上画一个半透明边框。这种"半标注"输入在实际生成中效果拔群。
第三件要注意的事是背景清理。很多设计稿的图层会有杂色背景、装饰性纹理，模型会把它们当成真实UI元素一起"转码"。我一般会在预处理阶段先做一次背景去除或纯色化处理。当然，如果你生成的目标是保留设计稿背景氛围的营销页，那就另当别论。
3.3 提示词架构：生成可维护代码的提示词模板
提示词设计是我这次花时间最多的一环。UI2Code的提示词不能像聊天那样随口一说，它需要把你的工程规范、代码偏好、约束信息全部表达清楚。
我最终沉淀了一套模板，每次生成时套用。这套模板包含五个部分：角色设定、输入描述、目标要求、代码约束、负面指令。
角色设定要让模型进入专业前端工程师的状态。输入描述会把预处理后的设计稿信息填进去，包括设计稿宽高比、主色调、页面用途。目标要求明确说明"输出一个完整的单文件HTML，内联CSS，可直接用浏览器打开预览"。代码约束是最重要的，我会规定使用语义化标签、类名以模块开头命名、布局优先使用Flex或Grid、禁止使用绝对定位做整体布局。负面指令用来堵死常见雷区，比如"不要生成无关的装饰性内容"、"不要把图片写成占位符"。
实际提示词结构大概长这样：
你是资深前端开发工程师，请根据我提供的设计稿图片，生成一份可运行的HTML页面。 设计稿信息： - 页面宽度：1280px - 页面类型：数据可视化看板 - 主色调：深蓝底、白色文字 要求： 1. 输出完整单文件HTML，使用内联CSS，不依赖任何外部框架。 2. 使用语义化标签：header/main/section/aside/footer。 3. 类名使用BEM风格，如.dashboard-card__title。 4. 布局优先使用Flexbox与Grid，禁止用position: absolute堆叠来实现整体布局。 5. 栅格系统用CSS Grid实现，列数参考设计稿。 6. 字体使用系统默认字体栈，大小保留设计稿的比例关系。 7. 图片元素用占位图路径，但要保留正确的尺寸、圆角、阴影参数。 禁止事项： - 不要生成设计稿不存在的元素。 - 不要用表格布局。 - 不要省略间距和圆角参数。 - 不要引入JavaScript文件，除非交互需要。这个模板跑出来的代码，比我一开始只写一句"帮我把这张图转成网页"要规整得多。尤其是负面指令，几乎每一个都对应着真实踩过的坑。比如"不要用绝对定位"，是因为模型在压力下容易把元素全部铺在一个容器里用top/left定坐标，这样的代码没法维护。加上负面指令之后，模型会更倾向于用flex/grid表达空间关系。
3.4 交互式迭代闭环：把一轮生成变成多轮修版
到这里，单一的生成流程已经跑通了。接下来就是把"Test-time Scalable"和"Interactive"结合起来，做成一个能多轮修正的交互闭环。
我的实现方案不复杂，核心是一个多轮会话状态机。Python后端维护一个session列表，每个session保存当前完整代码、当前设计稿、历史修改记录。交互流程这样流转：
第一轮：用户上传设计稿，后端调用模型生成初始代码，返回给前端，渲染预览。
第二轮及以后：用户点击预览中的某个元素，输入修改指令。前端收集点击元素的DOM信息，连同指令发给后端。后端把这段信息拼接成一个"局部修改请求"，和前一轮的完整代码一起作为提示词输入。模型输出新的完整代码，更新session状态，返回新预览。
第三轮、第四轮同理。每一轮模型都能看到上一版代码和用户反馈，所以它是"基于当前结果做迭代"，而不是"重新瞎编一版"。我在提示词里专门加了一个固定段：用户修改指令、上一版完整代码、目标局部元素。这三段信息缺一不可。
为了降低每次全量重生成的成本，我后来加了一个启发式策略：如果用户修改的只是样式细节，比如改颜色、改间距，我就让模型只输出一段CSS覆盖层，而不是重新生成整个HTML。但如果用户改了结构布局，那还是得整页重新生成。按用户指令里是否包含"移动""删除""添加"这类结构动词来判断走哪条路。
整套闭环跑下来，最直观的感受是：生成的初稿质量决定了后面要迭代几轮。初稿如果达到70分的水平，三轮交互之内能改到90分以上；初稿如果只有30分，那往往说明模型对设计稿理解错了，这时候继续在错误的代码上打补丁是浪费时间，不如调整提示词或预处理方式重新生成。
4. 踩坑实录：从结构错乱到样式漂移的排查方案
有些问题，只有真实跑过一遍才会遇到。我整理了实测中踩过的四个高频问题，每个都附上排查思路和解决方案。
4.1 布局模型理解错误，左右结构变成上下结构
这是我最常碰到的问题之一。设计稿里明明是一个左侧导航加右侧内容区的经典后台布局，模型生成的代码却把导航放在内容区上面，变成了上下顺序。
第一次遇到时我还以为是提示词没写清楚。后来排查发现根源在于视觉编码器对"空间并列关系"的感知不稳定。当导航和内容区分界处的背景色非常接近、缺少强对比分割线时，模型很容易把它们判断成一个连续的纵向区块。
解决办法有几个方向。最粗暴但有效的，是预处理时给设计稿加上辅助分割线：在左右区块的边界处画一条很浅的参考线，模型就能捕捉到这个分界。另一个办法是把布局结构显式写进提示词，告诉模型"这个页面是左右布局，左侧固定宽度240px，右侧为自适应内容区"。如果模型本身对齐理解能力弱，靠提示词约束可以强行纠正它的判断。
后来我甚至试过一个思路：把设计稿按视觉区块切成多张小图，每张图单独描述布局类型，再把这些描述整合成完整提示词。效果确实更好，但实现成本高，适合对生成质量要求苛刻的场景。
4.2 视觉还原准但样式毛躁，像素级细节对不上
布局结构对了，但样式毛躁是另一类高频问题。比如设计稿中卡片之间的间隙是32px，模型生成的是30px；标题字号是28px，模型生成的是26px；两个按钮之间的对齐差了两个像素。
这类问题的本质是VLM对精确数值的感知有天然下限。它能看出"这里有空隙"，但空隙是多少px，它只能估算个大概。估算误差在±10%以内其实是模型在当前视觉分辨率下的正常水平。
解决思路不是追求像素级精确，而是让代码在"比例关系"上正确。我会在提示词里要求模型输出CSS使用相对单位和变量，比如间距用clamp()或CSS自定义属性定义，整页通过一个根font-size控制缩放比例。这样即使模型估算的像素数有偏差，修改时只需要改几个变量，整体比例不会崩。
还有一个心得是：不要指望模型一次做到像素级完美，那是设计师和工程师之间反复核对的结果。让模型保证"结构合理、比例协调、命名规范"，剩下的数值微调交给人工，这个分工最现实。
4.3 多轮修版的代码漂移问题
交互式迭代最大的隐患不是初稿质量，而是"代码漂移"。什么意思呢？第一轮生成的代码很好，你让它把侧边栏改成深色，它把整页的按钮都改成了深色；你让它把标题字号加大，它顺手把间距也全部改了。
这个问题的根源是模型在生成时倾向于"整体一致性"。它认为按钮在页面里应该风格一致，所以当你修改某一块时，它会默认把所有按钮都联动改掉。对于生成代码来说，这种全局一致性有时候是优点，但在渐进式修改时却是灾难，因为你永远不知道哪一部分会被悄悄改掉。
我最终找到的解法是引入"补丁模式"。每一轮修改时，不再让模型输出完整代码，而是让它输出一段"修改说明 + 目标diff"。具体来说，提示词变成："基于上一版代码，只针对用户提到的元素做修改，输出修改后的完整代码。注意保持其他部分与上一版完全一致。"同时在提示词后面附上"上一版完整代码"与"用户修改指令"。
如果模型还是出现漂移，我的兜底策略是维护版本快照。每一轮修改前把当前代码存一份git版本，如果修改结果不满意，可以直接回滚。这个策略在真实开发中也同样适用，毕竟AI生成的代码出bug是常态，能快速回到上一个稳定版本比什么都重要。
4.4 推理成本和多候选生成
Test-time Scalable听起来很美好，但实际算下来成本确实不低。我试过用同一份设计稿生成5个候选版本，每个版本调用一次完整模型推理，然后人工挑一个最好的。一轮操作下来，显存占用高位运行，生成时间也明显拉长。
一个比较务实的降本策略是分级生成。第一轮先用低分辨率设计稿快速生成一个"结构草稿"。等确认页面结构没问题后，再用高分辨率设计稿让模型补全样式细节。结构草稿阶段可以关掉一些采样随机性，让模型输出更稳定；样式补全阶段可以提高温度，让模型在细节上有更多变化。
另外要善用模型的缓存机制。多轮交互时，设计稿的图像特征在第一轮推理时已经计算过了，如果框架支持缓存视觉编码器的输出，后续每一轮修改就只需要重新计算文本部分，能省掉可观的算力。我用的推理框架里，手动把视觉特征缓存到磁盘，多轮交互的响应速度能提升一倍以上。
推理成本这件事，本质上是在"生成质量"和"金钱时间"之间做预算。我自己定的基线是：日常验证用1次生成加2轮修改，不跑候选集合；只有给正式场景做演示时才跑5个候选并用评分函数自动选优。这么分配下来，月均算力成本控制在一个可控范围内，产出质量也够用。
5. 一些实际操作中的细节与个人建议
前面几章把原理、工作流和常见问题都说完了。这一章写几个我这次复现之后留下的个人体会，算是对这套方法的一个补充。
5.1 关于提示词：好的提示词不是一次写成的
你可能觉得提示词模板就是一次性写出来的，其实不是。我上面的模板经历了至少三版迭代。第一版只写了角色和输出格式，结果模型生成了一堆语义标签不规范、类名乱掉的代码。第二版加了负面指令和CSS约束，效果好了不少，但还是会出现为凑效果而添加不存在元素的问题。第三版才加入了设计稿的元信息描述，比如页面类型、主色调，让模型从逻辑上更懂这个页面。
提示词迭代的正确姿势应该是：先跑一个任务，把模型在代码里犯的"结构性错误"记录下来，再去提示词里找对应的漏洞，补上相应的约束。如果生成结果还是一团糟，先别急着加句子，而是去看看是不是输入图像本身有问题。
5.2 关于交互式设计：人的反馈粒度要尽量小
在交互式UI2Code里，人的反馈质量是决定迭代轮次的另一个变量。用户如果说"这个页面不太好看"，模型完全不知道怎么改，只能瞎猜。但如果用户说"这个卡片区域的文字对齐改成左对齐，间距加大到12px"，模型就能精准命中。
我后来在前端做了一件事：把用户的自由输入框改成"指令模板 + 自由补充"的形式。系统提供几个常见操作按钮，比如"修改间距""修改颜色""调整对齐方式""删除元素"，用户点击后自动生成一条带参数占位的指令模板，然后只需要填写具体数值。这种引导式的交互方式，表面上限制了用户的自由度，实际上大大降低了沟通成本，减少了模型误解指令的概率。
5.3 关于最终交付：AI生成代码不能直接上生产
最后说一点很多人不爱听的实话。无论UI2Code工具发展到什么程度，AI生成的代码都不建议未经review直接上生产。我实测下来，生成代码在视觉还原度上可以做得很好，但在工程层面经常有隐患：比如没有考虑边界状态、缺少响应式断点、没做无障碍语义、没有性能优化。
所以我把这个工作流定位成"设计稿到初稿的高效转换器"，而不是"设计稿到生产的全自动流水线"。它最大的价值是把你从零到一搭建页面的时间大幅压缩，但代码review、可访问性检查、响应式适配、性能优化，这些活是需要真人工程师来兜底的。理解了这层边界，你就不会对AI生成结果有不切实际的期望，反而能更好地利用它的优势。
我现在的工作习惯是：任何UI开发任务，先让模型出一版结构完整的代码，然后我花5分钟review、改掉明显的问题，再进正常开发流程。相比以前纯手写节省三分之一到一半的时间。这个比例以后可能会继续提升，但"人机协作"的模式，大概率会是相当长时间里UI开发的常态。
