1. 当设计稿开始自己写代码AI 生成 UI 到底改变了什么Runway Solaris 发布之后我身边的前端群里炸了锅。有人兴奋地说“以后不用写 CSS 了”也有人冷笑“又一个玩具”。我花了整整两周时间把 Solaris 生成的各种 UI 界面往真实项目里塞踩了一堆坑也摸出了一些门道。这篇文章不吹不黑就聊一件事AI 生成 UI 的工程边界到底在哪里以及前端工作流该怎么接。先说结论Solaris 这类工具生成的 UI 代码能直接用吗能但仅限于特定场景。它更像一个“超级草图工具”而不是“前端工程师替代品”。你如果指望它一键生成生产级代码那大概率会失望但如果你把它当成一个“从想法到可交互原型”的加速器它会让你爽到飞起。关键词里有个词叫AIcoding这个词最近特别火。我的理解是AI 不是在“写代码”而是在“生成代码候选”。这两者有本质区别。写代码意味着理解业务逻辑、边界条件、异常处理生成代码候选意味着根据模式匹配输出一个“看起来像那么回事”的东西。前端工程师的价值恰恰在于把“候选”变成“产品”。所以这篇文章适合谁看如果你是前端工程师想知道怎么把 AI 生成 UI 融入现有工作流那这篇就是写给你的。如果你是产品经理或设计师想了解 AI 生成 UI 的能力边界也能从中得到一些参考。如果你是完全的新手建议先补一下 HTML/CSS 基础不然看后面的实操部分会有点吃力。我接下来会从几个维度拆解Solaris 生成 UI 的底层逻辑是什么、它擅长什么不擅长什么、怎么把它接入真实项目、以及我踩过的那些坑。每一部分都会给出具体的操作步骤和判断依据不玩虚的。2. Solaris 生成 UI 的底层逻辑它到底在“想”什么2.1 从提示词到界面一条被压缩的链路传统的前端开发链路是这样的需求文档 → 设计稿 → 切图 → 写 HTML 结构 → 写 CSS 样式 → 写 JS 交互 → 联调 → 测试 → 上线。这条链路里每一步都有信息损耗尤其是“设计稿到代码”这一步经常出现“设计说这样开发说那样”的扯皮。Solaris 做的事情是把这条链路压缩成提示词 → 界面代码。你输入“一个电商商品详情页顶部有轮播图中间是商品信息底部有加入购物车按钮”它直接输出一段 HTML CSS 部分 JS。听起来很美好但这里有个关键问题它怎么知道“轮播图”该用什么组件“加入购物车”按钮该用什么颜色我翻了一些技术资料结合自己的使用体验Solaris 的底层大概是这样工作的它有一个经过大量 UI 数据训练的多模态模型能理解自然语言描述和视觉布局之间的关系。当你输入提示词时它会在内部“想象”出一个界面布局然后把这个布局映射成代码。这个映射过程依赖于它训练时见过的海量 UI 模式——比如“轮播图”通常是一个div包裹多个img配合overflow: hidden和transform: translateX。但问题来了它见过的模式是“平均模式”不是“你的项目模式”。你的项目可能用 React Tailwind也可能用 Vue Element Plus还可能用原生 HTML 自定义 CSS 变量。Solaris 默认输出的代码往往是“通用模式”——用最基础的 HTML 和 CSS不依赖任何框架。这就导致一个尴尬的局面生成的代码能跑但跟你的项目风格完全不搭。2.2 为什么它生成的代码总是“差一口气”我拿 Solaris 生成了一个登录页面提示词是“一个简洁的登录页面包含邮箱输入框、密码输入框、登录按钮、忘记密码链接”。它输出的代码大概长这样div classlogin-container h2登录/h2 input typeemail placeholder邮箱 / input typepassword placeholder密码 / button登录/button a href#忘记密码/a /div.login-container { width: 300px; margin: 100px auto; padding: 20px; border: 1px solid #ccc; border-radius: 8px; } input { width: 100%; padding: 10px; margin-bottom: 10px; border: 1px solid #ddd; border-radius: 4px; } button { width: 100%; padding: 10px; background-color: #007bff; color: white; border: none; border-radius: 4px; }这段代码有问题吗没有。它能跑能看能用。但如果你把它放进一个用 Tailwind CSS 的项目里你会想死——因为你的项目里所有样式都是classNamew-full px-4 py-2 border rounded突然冒出来一个.login-container维护起来就是灾难。这就是AI 生成 UI 的第一个工程边界它不理解你的项目上下文。它不知道你用什么框架、什么样式方案、什么组件库。它只能输出“通用代码”而“通用代码”在真实项目里往往意味着“需要大量改造的代码”。2.3 提示词的质量决定生成结果的上限我做了个对比实验同一个登录页面用两种不同的提示词让 Solaris 生成。提示词 A“生成一个登录页面。”提示词 B“生成一个登录页面使用 React 函数组件样式用 Tailwind CSS包含邮箱和密码输入框登录按钮在底部按钮颜色用蓝色系整体风格偏商务简洁。”结果差异巨大。提示词 A 生成的代码是纯 HTML CSS没有任何框架痕迹。提示词 B 生成的代码是 React 组件用了className而不是class样式也基本符合 Tailwind 的写法。这说明一个关键点Solaris 的生成质量高度依赖提示词的精确度。你给的信息越具体它生成的代码越接近你的预期。但这里有个悖论如果你能把提示词写得足够具体说明你已经对界面有了清晰的规划那你自己写代码可能也花不了多少时间。AI 生成 UI 的价值在于“快速探索可能性”而不是“精确执行”。我个人的经验是用 Solaris 做“第一版草图”然后手动改造。不要指望它一步到位而是把它当成一个“能生成代码的草图工具”。你先用提示词生成一个大概的界面看看布局和交互是否合理然后基于这个草图用你的项目技术栈重写一遍。这个过程比从零开始写要快得多尤其是当你对某个界面布局没有头绪的时候。3. 哪些场景能直接接、哪些必须人工兜底3.1 适合 AI 生成 UI 的三类场景经过两周的实测我总结出三类场景Solaris 生成的代码可以直接用或者只需要少量修改。第一类内部工具和后台管理页面。这类页面的特点是功能优先样式要求不高迭代速度快。比如一个数据看板、一个表单页面、一个列表页面。Solaris 生成的代码虽然不够精致但基本功能都有你只需要调整一下颜色和间距就能直接上线。我试过用它生成一个“用户管理后台”的页面包含搜索栏、表格、分页器生成结果大概有 70% 可以直接用剩下的 30% 是调整表格列宽和分页器的样式。第二类原型验证和 Demo 展示。当你需要快速做一个可交互的原型给老板或客户看时Solaris 是神器。你不需要写任何代码只需要输入提示词就能得到一个能点击、能输入的界面。虽然代码质量一般但演示效果足够了。我试过用它生成一个“移动端电商首页”包含轮播图、商品列表、底部导航栏整个过程不到 5 分钟。如果手动写至少需要半天。第三类静态页面和营销落地页。这类页面的特点是结构简单交互少主要是展示信息。Solaris 生成的代码基本能满足需求你只需要替换一下文案和图片调整一下配色就能直接部署。我试过用它生成一个“产品介绍页”包含标题、副标题、特性列表、CTA 按钮生成结果直接能用我只改了文案和按钮链接。3.2 必须人工兜底的四种情况但有些场景Solaris 生成的代码绝对不能直接用必须人工重写或深度改造。第一种涉及复杂状态管理的页面。比如一个多步骤表单、一个购物车、一个实时聊天界面。这些页面的核心逻辑是状态管理而 Solaris 生成的代码往往只有静态结构没有状态逻辑。你如果直接用它生成的代码会发现点击按钮没反应输入框不能联动。我试过用它生成一个“多步骤注册表单”它只生成了三个独立的表单页面但没有步骤切换逻辑也没有表单验证。这部分必须自己写。第二种需要与后端 API 交互的页面。Solaris 生成的代码里数据都是硬编码的。比如一个商品列表它会生成一堆静态的div里面写着“商品名称”“商品价格”。但真实项目里这些数据需要从 API 获取还需要处理加载状态、错误状态、空状态。这些逻辑 Solaris 不会帮你写你必须自己补上。第三种对性能要求极高的页面。Solaris 生成的代码往往不够优化。比如它可能会生成大量的嵌套div或者使用一些性能较差的 CSS 属性。对于首屏加载时间要求极高的页面比如电商首页、新闻详情页直接使用生成的代码可能会导致性能问题。你需要手动优化 DOM 结构、减少重绘重排、使用懒加载等。第四种需要严格遵循设计系统的页面。如果你的公司有完整的设计系统比如特定的颜色变量、字体大小、间距规范、组件库Solaris 生成的代码几乎不可能完全符合。它不知道你的设计系统里“主色”是#1a73e8还是#007bff也不知道你的按钮圆角是4px还是8px。你需要手动把生成的代码“翻译”成设计系统的语言。3.3 一个判断标准改造成本是否低于重写成本我总结了一个简单的判断标准如果改造 Solaris 生成的代码所需的时间超过了从零开始写的时间那就直接重写。这个标准听起来很废话但实际操作中很容易被忽略。很多人看到 AI 生成了代码就觉得“不用白不用”结果花了大量时间改造最后发现还不如自己写。我的经验是对于简单的静态页面改造时间通常是重写时间的 30% 到 50%值得改造。对于复杂的交互页面改造时间可能超过重写时间的 80%甚至更多这时候直接重写更划算。你可以先花 5 分钟评估一下生成的代码看看结构是否合理、样式是否可复用、逻辑是否完整然后再决定是改造还是重写。4. 把 Solaris 接入现有前端工作流的具体步骤4.1 第一步建立“生成-评估-改造”的流水线不要把 Solaris 当成一个“一键生成”的工具而是把它当成一个“代码候选生成器”。你需要建立一条流水线生成 → 评估 → 改造 → 集成。生成阶段用精确的提示词让 Solaris 生成代码。提示词里要包含页面类型、布局结构、关键组件、样式风格、技术栈偏好。比如“生成一个 React 函数组件使用 Tailwind CSS包含顶部导航栏、左侧侧边栏、右侧内容区整体风格偏暗色系”。评估阶段拿到生成的代码后不要急着往项目里塞。先花几分钟评估结构是否合理样式是否可复用逻辑是否完整有没有明显的性能问题我通常会打开浏览器的开发者工具看看 DOM 结构是否过于嵌套CSS 是否有冗余。改造阶段根据评估结果决定是改造还是重写。如果改造重点做三件事替换样式方案比如把普通 CSS 改成 Tailwind、补充状态逻辑比如表单验证、API 调用、适配设计系统比如替换颜色变量、字体大小。集成阶段把改造后的代码集成到项目中。注意检查是否有命名冲突、样式污染、依赖缺失等问题。我通常会先在一个独立的分支上集成跑一遍测试确认没问题后再合并。4.2 第二步用“组件级提示词”替代“页面级提示词”我一开始用 Solaris 的时候喜欢输入“生成一个完整的电商首页”。结果生成的代码又长又乱改造起来非常痛苦。后来我改变策略用“组件级提示词”替代“页面级提示词”。比如我不再输入“生成一个电商首页”而是分多次输入“生成一个轮播图组件包含三张图片自动播放底部有指示点”“生成一个商品卡片组件包含图片、标题、价格、加入购物车按钮”“生成一个底部导航栏组件包含首页、分类、购物车、我的四个图标”。这样做的好处是每个组件都是独立的改造起来更灵活。你可以只改造你不满意的组件保留你满意的组件。而且组件级代码更容易复用你可以在多个页面里使用同一个组件。我试过用这种方式生成一个“移动端电商首页”整个过程大概花了 20 分钟生成了 5 个组件改造了其中 3 个最终效果比一次性生成整个页面好得多。4.3 第三步建立“提示词模板库”提高复用率如果你经常用 Solaris 生成 UI建议建立一个“提示词模板库”。把常用的提示词结构保存下来下次直接套用。比如表单页面模板“生成一个 [页面类型] 表单包含 [字段列表]使用 [技术栈]样式风格 [风格描述]按钮在 [位置]包含 [验证规则]。”列表页面模板“生成一个 [页面类型] 列表包含 [列名列表]使用 [技术栈]支持 [排序/筛选/分页]样式风格 [风格描述]。”详情页面模板“生成一个 [页面类型] 详情页包含 [信息区块列表]使用 [技术栈]布局为 [布局描述]样式风格 [风格描述]。”我建了一个简单的 Markdown 文件把这些模板存起来每次用的时候直接复制粘贴改几个关键词就行。这样能大幅提高生成效率也能保证生成结果的一致性。4.4 第四步把生成的代码纳入版本控制这一点很重要但很容易被忽略。AI 生成的代码也应该纳入版本控制。我见过有人直接把生成的代码复制到项目里改完之后就忘了原始版本是什么。结果后来想对比一下 AI 生成的版本和改造后的版本发现找不到了。我的做法是在项目里建一个ai-generated目录把 Solaris 生成的原始代码放在里面然后改造后的代码放在正常的目录里。这样你可以随时对比也可以随时回滚。而且如果以后 Solaris 升级了你可以重新生成一遍看看新版本是否更好。另外建议在提交信息里注明“AI 生成”或“AI 辅助”方便以后追溯。这不是为了“甩锅”而是为了在代码审查时让审查者知道这部分代码的来源从而更有针对性地审查。5. 实测中遇到的五个坑和对应的解法5.1 坑一生成的 CSS 类名冲突Solaris 生成的 CSS 类名往往是通用的比如.container、.header、.button。如果你直接把这些代码放进项目里很容易和现有的类名冲突。我试过把一个生成的登录页面放进项目里结果发现.container这个类名已经被全局样式占用了导致登录页面的布局完全乱掉。解法在改造阶段给生成的 CSS 类名加上前缀。比如把.container改成.login-container把.button改成.login-button。或者更好的做法是直接把普通 CSS 转换成 CSS Modules 或 Tailwind从根本上避免类名冲突。5.2 坑二生成的 HTML 结构过于嵌套Solaris 生成的 HTML 结构往往有很多层嵌套的div。比如一个简单的按钮它可能会生成divdivbutton点击/button/div/div。这种结构不仅冗余还会影响性能尤其是在列表渲染时。解法在改造阶段手动简化 DOM 结构。把不必要的div去掉只保留必要的语义化标签。比如上面的例子直接改成button点击/button就行。我通常会用一个简单的规则来判断如果一个div没有class、没有id、没有事件绑定那它大概率是多余的。5.3 坑三生成的交互逻辑不完整Solaris 生成的代码里交互逻辑往往只有“表面功夫”。比如一个轮播图它可能只生成了静态的图片没有自动播放、没有切换动画、没有指示点联动。你如果直接用它生成的代码会发现轮播图根本不能动。解法在改造阶段补充完整的交互逻辑。对于轮播图你需要加上setInterval实现自动播放加上transform实现切换动画加上事件监听实现指示点联动。这部分没有捷径只能自己写。我的建议是把 Solaris 生成的代码当成“静态结构”交互逻辑全部自己实现。5.4 坑四生成的代码不符合无障碍规范Solaris 生成的代码往往忽略无障碍规范。比如图片没有alt属性按钮没有aria-label表单输入框没有关联的label。如果你直接上线可能会被无障碍检测工具扣分也会影响真实用户的使用体验。解法在改造阶段补充无障碍属性。给所有图片加上alt给所有按钮加上aria-label给所有表单输入框加上关联的label。我通常会用一个简单的检查清单来确保无障碍合规图片有alt吗按钮有aria-label吗表单有label吗键盘能操作吗屏幕阅读器能读吗5.5 坑五生成的代码有安全风险这一点最容易被忽略但也最重要。Solaris 生成的代码里可能会包含一些不安全的内容。比如它可能会生成innerHTML直接插入用户输入或者生成eval执行动态代码。如果你直接上线可能会导致 XSS 攻击。解法在改造阶段审查所有涉及用户输入的地方。确保使用textContent而不是innerHTML确保对用户输入进行转义确保不使用eval和Function构造函数。我通常会用一个简单的规则来检查如果代码里出现了innerHTML、eval、document.write就重点审查。6. 前端工程师在 AI 生成 UI 时代的位置6.1 从“写代码的人”变成“审代码的人”我用了两周 Solaris 之后最大的感受是我的工作重心从“写代码”变成了“审代码”。以前我花 80% 的时间写代码20% 的时间审查和调试。现在反过来了我花 20% 的时间生成代码80% 的时间审查、改造、集成。这个转变意味着什么意味着前端工程师的核心竞争力不再是“能写多少行代码”而是“能判断代码的好坏”。你需要知道什么样的代码是好的什么样的代码是坏的什么样的代码能直接用什么样的代码必须重写。这种判断力来自于你对前端工程化的理解来自于你踩过的坑来自于你对业务场景的熟悉程度。6.2 提示词工程是新的“切图”技能以前前端工程师需要会“切图”把设计稿切成 HTML 和 CSS。现在前端工程师需要会“写提示词”把需求描述成 AI 能理解的提示词。这听起来很简单但实际上需要很强的抽象能力和表达能力。一个好的提示词需要包含页面类型、布局结构、关键组件、样式风格、技术栈偏好、交互逻辑、边界条件。你需要把模糊的需求翻译成精确的描述。这个能力其实和以前“把设计稿翻译成代码”的能力是一脉相承的只是输入和输出变了。6.3 工程化能力决定 AI 生成 UI 的上限我越来越觉得AI 生成 UI 的上限不是由 AI 决定的而是由前端工程化水平决定的。如果你的项目有完善的组件库、设计系统、代码规范、测试体系那 AI 生成的代码很容易接入。如果你的项目是一堆意大利面条式的代码那 AI 生成的代码只会让情况更糟。所以与其担心 AI 会不会取代前端工程师不如花时间提升自己的工程化能力。把组件库建好把设计系统建好把代码规范建好把测试体系建好。这样无论 AI 生成什么代码你都能快速接入、快速改造、快速上线。6.4 一个真实的体会AI 不会让你失业但会让你重新定义工作我用了两周 Solaris没有觉得自己的工作被取代了反而觉得自己的工作变得更有意思了。以前我花大量时间写重复的代码现在我可以把时间花在更有价值的事情上优化性能、提升无障碍体验、设计更好的组件 API、解决更复杂的业务问题。AI 生成 UI 不是终点而是一个新的起点。它把前端工程师从重复劳动中解放出来让我们可以专注于真正需要人类智慧的事情。如果你还在犹豫要不要拥抱 AI 生成 UI我的建议是先试两周看看它到底能做什么、不能做什么。然后你会发现它不是一个威胁而是一个工具。工具本身没有好坏关键在于你怎么用它。最后分享一个小技巧我每次用 Solaris 生成代码之前都会先问自己一个问题——“如果我自己写这段代码需要多长时间”如果答案是“不到 10 分钟”那我就自己写不用 AI。如果答案是“超过 30 分钟”那我就用 AI 生成然后改造。这个简单的判断标准帮我节省了大量时间也避免了“为了用 AI 而用 AI”的陷阱。