1. 从一句话到可交互界面这条路到底走不走得通前阵子跟几个做产品的老伙计吃饭席间有人抛出一个问题现在跟 AI 说一句“帮我画一个外卖点单的 App 首页”它真能吐出一个能点、能跳转、能填表单的界面吗桌上瞬间分成两派一派觉得这就是个高级线框生成器另一派觉得 D2C 那套东西早就跑通了差的只是最后一公里。我回家之后花了大概两周时间把市面上主流的几条技术路线都摸了一遍从纯文本生成原型到设计稿转代码踩了不少坑也摸出了一些门道。这篇文章就把我这两周折腾出来的东西完整拆开讲从底层原理到实操步骤再到那些文档里不会写的避坑经验尽量一次说透。先说结论省得你看到一半发现方向不对。Text-to-Prototype文本生成原型和D2CDesign to Code设计转代码是两条不同的路前者是“无中生有”后者是“有中做优”。一句话生成可交互界面在特定约束下是成立的但如果你期待的是直接生成能上线的生产级代码那目前还差得远。它更适合的场景是快速验证、早期沟通、以及把设计师从重复劳动里解放出来。适合谁看产品经理、独立开发者、前端工程师、UI 设计师以及所有想用 AI 提效但又不想被忽悠的人。我这两周的核心工作流是这样的先用文本生成工具快速出原型确认交互逻辑没问题之后再把设计稿导入 D2C 工具生成代码骨架最后手工补齐业务逻辑和状态管理。整个链路跑下来效率提升大概在 40% 到 60% 之间具体取决于页面复杂度。下面我把每个环节拆开讲包括我为什么这么选、参数怎么调、以及哪些地方 AI 会给你挖坑。2. 文本生成原型的底层逻辑与方案选型2.1 一句话生成界面的三种技术路线目前市面上能实现“一句话生成界面”的方案底层基本逃不出这三种路线我分别试过各有各的脾气。第一种是基于模板匹配的生成。你输入一句话系统先做意图识别和实体抽取然后从预置的组件库里拼装页面。比如你说“外卖首页”它识别出“外卖”这个领域然后调出对应的模板把轮播图、分类入口、商家列表这些组件按固定布局摆上去。这种方案的好处是稳定、可控、生成速度快坏处是灵活性差你说“外卖首页但要突出折扣标签”它可能就懵了。我实测下来这类工具适合做标准化程度高的页面比如电商详情页、后台管理表单。第二种是基于大语言模型直接生成代码。你给模型一段描述它直接输出 HTML、CSS 和 JavaScript或者输出 React、Vue 的组件代码。这种方案灵活度最高理论上你说什么它都能画但问题也很明显生成结果不稳定同样的描述跑两次可能得到完全不同的布局而且经常出现样式错位、组件重叠、交互逻辑缺失的情况。我试过让模型生成一个带底部导航栏的页面结果它把导航栏写成了绝对定位内容区直接被盖住这种坑你得自己填。第三种是基于多模态模型的截图转代码。你先给模型一张设计稿截图或者手绘草图它识别出里面的元素和布局然后生成对应的代码。这条路其实更接近 D2C 的范畴但因为它也能接受文本描述作为补充所以有时候被归到 Text-to-Prototype 里。我实测下来这种方案的准确率比纯文本生成高不少因为模型有视觉参考不会凭空想象布局。提示如果你追求的是“能跑起来”而不是“能上线”优先选第一种或第三种。纯文本生成代码那条路目前更适合做灵感发散不适合做交付。2.2 为什么我最终选了“文本生成 截图转代码”的组合拳我一开始也想过一条路走到黑要么全用文本生成要么全用截图转代码。但实际跑下来发现这两者其实是互补的。文本生成适合做从零到一的探索你脑子里只有一个模糊的想法用文字描述出来让 AI 给你几个方案快速试错。截图转代码适合做从一到十的细化你已经有了明确的设计稿需要把它变成可维护的代码。我的具体做法是先用文本生成工具跑出三到五个不同风格的首页方案截长图保存。然后挑一个最接近预期的在 Figma 里做一轮手工调整把布局、间距、配色定下来。最后把调整后的设计稿导入 D2C 工具生成代码骨架。这样做的好处是文本生成阶段帮你打开了思路截图转代码阶段保证了代码质量中间的手工调整环节则把 AI 的“幻觉”过滤掉了。这里有个关键决策点什么时候该用文本生成什么时候该切换到截图转代码。我的经验是当你对页面结构还没有明确想法时用文本生成当你已经能画出线框图时直接上截图转代码。判断标准很简单如果你能用语言把布局描述清楚比如“顶部是搜索栏下面是横向滚动的分类图标再下面是纵向的商家列表”那文本生成就够了。如果你发现描述起来很费劲比如“这个卡片要稍微往上叠一点阴影要柔和但有层次感”那就别为难文字了直接画出来让 AI 识别。2.3 工具选型的几个硬指标我前后试了七八个工具筛选标准主要看这几个维度。生成速度方面文本生成类工具普遍在 10 到 30 秒之间截图转代码类工具因为要做视觉识别通常要 30 秒到 1 分钟。代码质量方面我主要看生成的代码有没有语义化的标签、样式是不是用 Flex 或 Grid 布局、有没有把样式和结构分离。有些工具生成的代码全是绝对定位这种代码后期根本没法维护直接 pass。可编辑性是我最看重的一点。好的工具应该允许你在生成结果上继续调整而不是每次修改都要重新生成一遍。我试过某个工具改一个按钮颜色都要重新输入一遍描述这种体验简直灾难。导出格式也很关键至少要支持导出 HTML/CSS 和主流框架的组件代码比如 React、Vue。如果你团队用的是 Flutter 或 SwiftUI那还得看工具支不支持。下面这张表是我对几类工具的综合对比你可以根据自己的场景对号入座。工具类型生成速度代码质量可编辑性适用场景模板匹配类快10秒内高结构规整中等受模板限制标准化页面、后台表单大模型直接生成中等15-30秒不稳定需人工修正高可对话调整灵感发散、早期验证截图转代码类较慢30-60秒较高依赖设计稿质量高支持图层调整设计稿交付、还原度要求高注意不管选哪类工具生成结果都必须经过人工审查。我见过太多人直接把 AI 生成的代码提交上去结果线上出现样式错乱、点击事件失效的问题。AI 是助手不是背锅侠。3. 核心细节拆解从描述到界面的关键环节3.1 描述词怎么写AI 才能听懂很多人觉得“一句话生成界面”就是随便说一句话然后等着奇迹发生。我一开始也这么想结果生成出来的东西跟我想的完全不是一回事。后来我总结了一套描述词的写法核心原则是结构清晰、层次分明、约束明确。不要写“帮我画一个好看的电商首页”这种描述太模糊AI 只能靠猜。你应该写成“生成一个移动端电商首页宽度 375px顶部是搜索栏高度 44px背景色浅灰。搜索栏下方是横向滚动的分类导航每个分类图标 48x48px间距 16px。再下方是纵向的商品列表每个商品卡片包含图片、标题、价格卡片间距 12px。” 你看这样描述之后AI 生成的结果就靠谱多了。我习惯把描述分成三个层次。第一层是布局结构说清楚页面从上到下有哪些区块每个区块的高度或者比例是多少。第二层是组件细节说清楚每个区块里有哪些元素元素的尺寸、间距、对齐方式。第三层是交互行为说清楚点击、滑动、输入这些操作会触发什么效果。这三层写清楚AI 基本能还原出七八成。还有一个技巧是用类比。如果你想要一个“类似某主流社交软件那种卡片式布局”可以直接这么说AI 对常见产品的布局模式是有认知的。但注意不要提具体品牌名说“主流社交软件”就够了。我试过用这种方式描述生成结果的还原度比纯参数描述还要高。3.2 布局还原的难点Flex 还是 GridAI 生成界面时布局方式的选择直接影响后期可维护性。我观察下来大部分工具默认用 Flexbox少数会用 CSS Grid。这两种方式各有适用场景你得心里有数。Flexbox 适合一维布局比如横向排列的导航栏、纵向排列的列表。它的优势是弹性好元素可以根据容器大小自动伸缩。但如果你用它来做二维布局比如同时控制行和列就会写出一堆嵌套的 flex 容器代码又臭又长。CSS Grid 适合二维布局比如仪表盘、图片墙这种需要同时控制行和列的场景。它的代码更简洁但兼容性在某些老设备上稍微差一点。我实测下来AI 生成移动端页面时用 Flexbox 的情况占八成以上这其实是对的因为移动端大部分布局都是一维的。但如果你发现 AI 用了一堆绝对定位来做布局那就要警惕了。绝对定位的代码在响应式场景下基本没法用屏幕宽度一变元素就全乱了。遇到这种情况我一般会手动把绝对定位改成 Flex 布局虽然费点时间但后期省心。提示生成代码后先搜一下position: absolute出现的次数。如果超过三处建议重新生成或者手动重构。绝对定位只适合做悬浮按钮、角标这种脱离文档流的元素。3.3 交互逻辑的补全AI 能做什么不能做什么文本生成原型最让人兴奋的一点是“可交互”但这里有个巨大的坑AI 生成的交互大部分是视觉层面的反馈比如点击按钮变色、弹窗出现但业务逻辑层面的交互比如表单验证、数据请求、状态管理它基本不管。我举个例子。我让 AI 生成一个登录页面它确实生成了输入框、按钮点击按钮也有按压效果。但当我输入错误的邮箱格式时它没有任何提示。当我点击登录按钮时它只是把按钮文字变成了“登录中”然后就没有然后了。真正的登录逻辑包括调用接口、处理 token、跳转页面这些都得我自己写。所以我的做法是把 AI 生成的交互分成两类来处理。一类是纯 UI 交互比如按钮的 hover 效果、弹窗的显示隐藏、轮播图的自动播放这些 AI 生成的基本能用我稍微调一下就行。另一类是业务交互比如表单提交、数据加载、页面跳转这些我只让 AI 生成占位逻辑比如一个空的函数体然后自己往里填真实逻辑。这样既利用了 AI 的效率又保证了功能的完整性。还有一个细节是状态管理。AI 生成的代码通常用组件内部的 state 来管理状态这在简单页面里没问题但页面一复杂状态多了之后就会乱。我的经验是如果页面状态超过五个就手动引入状态管理库把 AI 生成的状态逻辑迁移过去。这一步虽然麻烦但后期调试的时候你会感谢自己。3.4 设计稿转代码的还原度控制从设计稿转代码还原度是核心指标。我实测下来影响还原度的因素主要有三个设计稿的规范程度、工具的识别能力、人工调整的精细度。设计稿越规范还原度越高。什么叫规范图层命名清晰不要有一堆“矩形 1”“编组 23”这种默认命名。组件要复用同一个按钮在不同页面应该是同一个组件实例而不是复制粘贴出来的。间距要用统一的栅格系统比如 8px 的倍数。我试过用一份命名混乱的设计稿去转代码结果生成的代码里全是无意义的类名后期根本没法维护。工具的识别能力方面我主要看它能不能正确识别自动布局、组件变体、样式变量这些高级特性。有些工具只能识别静态图层遇到自动布局就歇菜了生成的代码全是固定宽高响应式直接废掉。我目前用的工具对自动布局的支持还不错能生成 Flex 布局的代码但组件变体识别得还不够准需要手动调整。人工调整的精细度这个就看你的耐心了。AI 生成的代码通常能达到 80% 到 90% 的还原度剩下的 10% 到 20% 需要你手动调。我一般会重点检查这几个地方间距是否一致、字体大小和行高是否匹配、颜色值是否准确、圆角和阴影是否还原。这些细节看起来不起眼但堆在一起就会让页面显得“差点意思”。4. 完整实操流程从一句话到可运行的原型4.1 环境准备与工具链搭建在开始之前你需要把工具链准备好。我目前的工作流涉及三个核心工具一个文本生成原型的工具、一个设计工具、一个 D2C 工具。文本生成工具我选的是支持对话式调整的那种因为一次生成很难满意需要反复微调。设计工具用主流的矢量设计软件就行关键是支持自动布局和组件系统。D2C 工具我选的是对自动布局支持比较好的生成代码的质量明显高出一截。除了这三个核心工具还有几个辅助工具值得提一下。代码格式化工具AI 生成的代码缩进和换行经常是乱的用 Prettier 跑一遍会舒服很多。浏览器开发者工具用来实时调试生成的页面改样式、看布局、查报错都靠它。版本控制工具每次生成的结果都提交一下方便对比不同版本的效果也方便回滚。环境搭建这块没什么特别的坑唯一要注意的是工具之间的兼容性。比如你从文本生成工具导出的设计稿能不能顺利导入 D2C 工具这个要提前试一下。我遇到过导出的文件格式不兼容的情况折腾了半天才发现是版本问题。所以建议你在正式开工之前先用一个简单的页面跑通整个链路确认工具之间能顺畅衔接。4.2 第一步用文本描述生成初版原型打开文本生成工具输入你的描述。我以“外卖点单首页”为例描述词是这样的生成一个移动端外卖点单首页宽度 375px。 顶部是状态栏占位高度 44px背景色 #FFFFFF。 下方是搜索栏高度 44px左右内边距 16px圆角 22px背景色 #F5F5F5占位文字“搜索商家或菜品”。 搜索栏下方是横向滚动的分类导航高度 80px每个分类包含图标和文字图标 48x48px文字 12px间距 24px。 分类导航下方是纵向的商家列表每个商家卡片包含店铺图片宽度 100%高度 120px圆角 8px、店铺名称16px加粗、评分和月售信息12px灰色、配送费和距离12px灰色。 卡片间距 12px页面左右内边距 16px。输入之后等大概 20 秒工具会生成一个初版页面。我实测下来第一次生成的结果通常只能打 60 分布局大方向是对的但细节上有很多问题比如分类导航的图标大小不一致、商家卡片的图片比例不对、间距忽大忽小。这时候不要急着重写描述先用工具自带的对话功能针对具体问题逐个调整。比如我会说“分类导航的图标改成统一 48x48px间距改成 24px。” 工具会重新生成这一部分。然后再接着说“商家卡片的图片高度改成 120px圆角改成 8px。” 就这样一轮一轮调大概调个五六轮页面就能达到 80 分左右的水平。这个过程听起来繁琐但比你自己从头画快多了而且你是在做“选择题”而不是“填空题”心理负担小很多。4.3 第二步在设计工具里做精细调整文本生成工具出来的结果直接拿去转代码还是太粗糙。我一般会把它导出成图片或者设计文件导入到设计工具里做一轮精细调整。这一步的核心目的是统一设计规范把 AI 生成的那些不一致的间距、颜色、字体全部对齐到一套标准上。我通常会先建一套设计变量比如主色、辅色、文字颜色、背景色、边框色然后建一套间距变量比如 4px、8px、12px、16px、24px、32px。然后把 AI 生成的页面里的元素逐个应用这些变量。这个过程有点像“整理房间”把乱七八糟的东西归位。整理完之后页面会清爽很多而且后期改起来也方便改一个变量所有引用它的地方都会跟着变。这一步还有一个重要任务是补全交互状态。AI 生成的页面通常只有默认状态没有 hover、active、disabled 这些状态。我会在设计工具里把这些状态补上比如按钮的 hover 状态颜色深一点输入框的 focus 状态边框亮一点。这些状态在转代码的时候会被识别出来生成对应的 CSS 伪类省得你后期手动写。提示设计工具里的图层命名一定要规范。我习惯用“区块-组件-状态”的格式比如“header-search-default”“card-shop-hover”。这样转代码的时候生成的类名也会比较语义化后期维护轻松很多。4.4 第三步D2C 工具生成代码骨架设计稿调整好之后导入 D2C 工具。导入的时候要注意选择正确的框架和样式方案。我一般选 React CSS Modules因为团队用的是这套。如果你用的是 Vue就选 Vue Scoped CSS。样式方案我建议选 CSS Modules 或者 Tailwind不要选内联样式内联样式后期没法复用改起来很痛苦。导入之后工具会花大概 30 秒到 1 分钟做识别和生成。生成结果通常包含三部分组件结构、样式代码、静态资源。组件结构方面工具会把设计稿里的每个区块识别成独立的组件比如 Header、SearchBar、CategoryNav、ShopList。这个粒度我觉得刚刚好不会太粗也不会太细。样式代码方面工具会生成对应的 CSS包括布局、颜色、字体、间距。静态资源方面工具会把设计稿里的图片导出成文件并在代码里引用。生成之后我建议先跑一遍看看效果。把代码复制到项目里启动开发服务器在浏览器里打开。这时候你通常会看到页面能显示但有一些细节跟设计稿对不上。比如某个卡片的阴影太深了某个文字的行高不对某个图标的尺寸偏了。这些都是正常的接下来就是人工修正的环节。4.5 第四步手工补全业务逻辑与状态管理代码骨架有了接下来就是往里填业务逻辑。这一步是 AI 目前最不擅长的也是你作为开发者最值钱的地方。我一般会按这个顺序来补先补数据层。定义好接口的数据结构写好请求函数。比如商家列表的接口返回什么字段每个字段是什么类型这些都要先定下来。然后写一个 mock 数据让页面能先跑起来不用等后端接口。再补状态层。用状态管理库或者组件内部的 state管理页面的数据。比如商家列表的数据、加载状态、错误状态、分页信息。我习惯用 React Query 或者 SWR 来管理服务端状态用 Zustand 或者 Context 来管理客户端状态。这样职责清晰后期调试也方便。然后补交互层。把点击、滑动、输入这些事件处理函数写好。比如点击商家卡片跳转到详情页下拉刷新重新请求数据搜索框输入时触发搜索建议。这些逻辑 AI 生成不了得你自己写。最后补边界情况。加载中的骨架屏、请求失败的提示、空数据的占位图、网络异常的兜底。这些细节决定了产品的完成度也是区分“能用”和“好用”的关键。4.6 第五步响应式适配与多端预览页面在 375px 宽度下跑通了接下来要适配不同尺寸的屏幕。我一般会重点测这几个宽度320px小屏手机、375px主流手机、414px大屏手机、768px平板。适配的核心原则是用相对单位代替固定单位比如用百分比或者 vw 代替 px用 rem 或者 em 代替 px。AI 生成的代码里固定像素值通常比较多需要手动改成相对单位。我一般会把容器的宽度改成 100%把字体大小改成 rem把间距改成百分比或者 clamp 函数。这样页面在不同屏幕下都能自适应不会出现内容溢出或者留白过大的情况。多端预览方面我建议至少在真机上跑一遍。模拟器跟真机的渲染效果还是有差异的尤其是字体渲染和滚动行为。我遇到过在模拟器上好好的到真机上文字被截断的情况。所以别偷懒真机测一下花不了几分钟。5. 常见问题与排查技巧实录5.1 生成结果与预期不符怎么办这是最常见的问题几乎每次生成都会遇到。我的排查思路是这样的先看描述词有没有歧义再看工具的识别能力有没有边界最后看是不是需要换个方案。描述词歧义是最常见的原因。比如你说“生成一个卡片列表”AI 可能理解成横向排列的卡片也可能理解成纵向排列的。这时候你要把描述改得更具体比如“生成一个纵向排列的卡片列表每个卡片占满容器宽度”。我踩过的坑是用了“稍微”“大概”“差不多”这种模糊词汇AI 对这些词的理解跟人不一样它可能会给你一个完全偏离的结果。工具的识别能力边界这个需要你慢慢摸清楚。每个工具都有自己擅长的领域和不擅长的领域。比如有的工具擅长生成移动端页面但生成桌面端页面就一塌糊涂。有的工具对中文描述的理解比较好对英文描述反而差一些。我的建议是先用几个简单的页面测试一下工具的能力边界心里有数之后再正式开工。如果描述词没问题工具也在能力范围内但结果还是不对那就考虑换个方案。比如文本生成搞不定的试试截图转代码。截图转代码搞不定的试试手工画。别在一个工具上死磕时间成本划不来。5.2 代码跑不起来或样式错乱AI 生成的代码跑不起来通常有几个原因。依赖缺失是最常见的生成的代码引用了某个库但你没有安装。这时候看控制台的报错信息缺什么装什么就行。语法错误也比较常见AI 偶尔会生成一些不合法的 JavaScript 或者 CSS比如少了一个括号或者用了一个不存在的属性。这种错误通常编辑器会标红仔细找一下就能发现。样式错乱的原因就比较多了。类名冲突是一个AI 生成的类名可能跟你项目里已有的类名重复了导致样式被覆盖。解决办法是给生成的类名加一个前缀比如ai-或者项目缩写。样式优先级问题也是一个AI 生成的样式可能被全局样式覆盖了或者被更具体的选择器覆盖了。这时候用浏览器的开发者工具看一下计算后的样式找到是哪个规则生效了然后调整优先级。还有一个坑是盒模型不一致。AI 生成的代码可能用了content-box而你项目里全局设置了border-box导致元素的实际尺寸跟预期不符。这种问题比较隐蔽需要你在开发者工具里仔细看盒模型图。5.3 交互失效的排查思路交互失效通常分两种情况事件没绑定上或者事件绑定了但逻辑不对。事件没绑定上可能是选择器写错了或者元素还没渲染出来就绑定了事件。我一般会在事件处理函数里加一个console.log看看点击的时候有没有输出。如果没有输出那就是事件没绑上。这时候检查一下选择器或者改用事件委托的方式绑定。事件绑定了但逻辑不对这个就要看具体代码了。比如点击按钮应该跳转页面但实际没跳可能是跳转的 URL 写错了或者路由配置有问题。我习惯用断点调试在关键位置打上断点一步一步看代码的执行流程很快就能定位到问题。还有一个常见问题是状态更新了但页面没重新渲染。这在 React 里通常是直接修改了 state 而没有用 setState在 Vue 里通常是修改了对象属性但没有触发响应式。解决办法是用正确的 API 更新状态或者用forceUpdate强制刷新不推荐治标不治本。5.4 常见问题速查表下面这张表是我这两周踩坑的总结你可以收藏起来遇到问题的时候对照着排查。问题现象可能原因排查方法解决方案生成结果与描述不符描述词有歧义检查描述词是否具体改用更精确的描述避免模糊词汇代码跑不起来依赖缺失或语法错误看控制台报错安装缺失依赖修正语法错误样式错乱类名冲突或优先级问题开发者工具看计算样式加类名前缀调整选择器优先级交互失效事件未绑定或逻辑错误加 console.log 或断点调试检查选择器修正事件处理逻辑页面不重新渲染状态更新方式不对检查 state 更新代码用正确的 API 更新状态响应式失效用了固定像素值检查代码中的 px 单位改成百分比、rem 或 vw还原度不够设计稿不规范检查图层命名和组件复用整理设计稿统一设计变量注意这张表里的问题我几乎每个都遇到过至少一次。最耗时的不是解决问题本身而是定位问题。所以我的建议是每做完一个页面都花几分钟做一次自查把常见问题过一遍能省下大量后期调试的时间。5.5 几个让我印象深刻的坑第一个坑是字体渲染差异。AI 生成的代码里用了某个字体但你的设备上没有安装浏览器就回退到了默认字体导致文字宽度和行高全变了布局也跟着乱。解决办法是用 Web Font或者用系统字体栈。我现在的做法是在设计阶段就用系统字体栈避免依赖特定字体。第二个坑是图片比例问题。AI 生成的代码里图片容器的高度是固定的但图片的实际比例可能跟容器不匹配导致图片被拉伸或者裁剪。解决办法是用object-fit: cover让图片自适应容器同时给容器设置一个合理的宽高比。第三个坑是滚动穿透。弹窗打开的时候背景页面还能滚动体验很差。解决办法是在弹窗打开时给 body 加一个overflow: hidden关闭时再恢复。这个坑我在移动端遇到过好几次尤其是 iOS 上滚动穿透特别明显。第四个坑是安全区域适配。在全面屏手机上底部导航栏可能会被 Home Indicator 挡住。解决办法是用env(safe-area-inset-bottom)给底部留出安全距离。这个细节很容易被忽略但用户一眼就能看出来。6. 我对这套工作流的真实体会这两周折腾下来我最大的感受是AI 生成原型这件事已经从“玩具”变成了“工具”。一年前我试过类似的工具生成结果基本没法用现在虽然还有各种问题但已经能帮我省下大量重复劳动了。尤其是从零到一那个阶段以前我要花半天时间画线框图现在跟 AI 聊十分钟就能出三五个方案效率提升是实打实的。但我也要泼一盆冷水别指望 AI 能替你思考。它不知道你的用户是谁不知道你的业务逻辑是什么不知道你的技术栈有什么约束。它只能根据你的描述生成一个“看起来像那么回事”的界面。真正的产品决策、交互设计、代码架构还是得你自己来。AI 是放大器不是替代品。你越清楚自己要什么它就越能帮到你。如果你也想试试这套工作流我的建议是从一个小页面开始比如登录页或者个人中心页。跑通整个链路之后再逐步应用到更复杂的页面上。别一上来就搞首页首页的复杂度太高容易受挫。另外多准备几套描述词模板针对不同类型的页面用不同的模板能省下不少调描述词的时间。最后分享一个小技巧把 AI 生成的结果当成“草稿”而不是“成品”。你的心态会放松很多也不会因为生成结果不完美而焦虑。草稿嘛本来就是用来改的。改着改着你就发现页面成型了而且比你自己从头画快得多。这个心态转变是我这两周最大的收获。