1. 别把“一句话生成界面”想得太简单：先说清楚它到底在做什么
我在团队里主要负责产品原型和前端落地稿的衔接，过去最烦的事情，不是画图，而是把脑海里的流程翻来覆去地讲给不同角色听。产品经理说“做个登录页”，设计师理解成“几个输入框加按钮”，开发拿到手又说“标注呢？跳转逻辑呢？”。现在大家都在聊 AI 生成 App 原型图，标题里那串英文缩写看起来唬人：Text-to-Prototype，文本生成原型；D2C，Design to Code，设计转代码。听起来像是一句话就能把 App 画出来，再一键变成能跑的代码。我最初也这么以为，但真正用下来发现，这条路没那么玄，但也确实能把原型和前端环节的重复劳动砍掉一大截。
先说结论：一句话能不能画出可交互界面？能，但不是“你随口说一句，它全自动搞定”的那种能。它更像你带着一个极其聪明的实习生，你把需求讲清楚，它十分钟内给你一版结构完整、交互连线都能点得动的原型稿。你再花半小时调整细节，比从空白画布开始画快非常多。而 D2C 则是把已经定稿的设计稿翻译成前端工程师能继续维护的代码，不是简单导出图片，而是生成结构清晰、样式可控、逻辑能对接的组件代码。
这篇文章我打算从实际项目里摸爬滚打的经验出发，把 Text-to-Prototype 和 D2C 这两段链路拆开讲透。会说明它们的核心原理、适用的场景、实际操作的步骤，以及我最常踩的坑。适合正在评估“AI 画原型到底靠不靠谱”的产品设计师，也适合想了解设计交付物如何更丝滑地转成代码的前端同学。
不过先提个醒：AI 生成原型不是取代设计，而是把“从无到有”的启动成本压低。理解这一点，你才不会对工具抱有不切实际的期待，才能真正用好它。
1.1 从文本到原型的“魔法”背后是大模型+组件库+规则引擎
很多人以为 Text-to-Prototype 是让 AI 直接画一张位图，就像文生图那样。其实不是。工程上更成熟的做法，是把你的文字描述解析成“页面结构树”，然后从内置的组件库里匹配对应的 UI 组件，再按照一套布局规则把它们排到画布上。
打个比方：你告诉它“登录页需要一个手机号输入框、一个获取验证码按钮、一个登录按钮”，它不是凭空画一个输入框的像素，而是从组件库中找到“输入框”组件，再设置它的状态、文案和校验规则。这个过程就像是有一个懂设计系统的助手，把你口头的要求翻译成一组组件的属性配置。
比较成熟的实现，一般会接一个经过微调的大语言模型，先把自然语言拆成“页面列表”“每个页面的元素”“元素之间的跳转关系”，再通过模板映射到具体组件。这里面有一个很关键的点：它生成的不是一张静态图，而是一个带图层、带约束、带交互热区的原型文件。这和直接生成 JPG 完全不是一个层级，因为它保留了可编辑性，你还能继续改。
我见过不少第一次用的人，输入一句“帮我做一个外卖点单 App”，结果生成出来一堆页面，但仔细看，页面之间的逻辑是断的，按钮点了没反应。原因在于，工具只能从你这句话里识别出“有哪些页面”，至于“页面之间怎么跳转”，你得单独说清楚，比如“从首页点击商品进入详情页，详情页点加入购物车回到首页并弹出提示”。这也是为什么我一直强调：文本生成原型，重点不在于“文本”，而在于你把交互信息结构化表达的能力。
1.2 你拿到的不只是一张图，而是“语义到布局”的映射关系
Text-to-Prototype 的核心价值，是帮你把“心里想的”快速转成“大家看得见的”。但这里面有一个重要的概念需要理解：AI 生成的结果，本质上是一种“语义到布局”的映射。它把你描述的业务语义（登录、注册、购物车、结算）映射到设计系统定义的布局模式（单列列表、卡片流、底部 Tab、表单分组）上。
举个例子，你说“首页要有商品列表”，AI 大概率给你一个“图片在上、标题在中间、价格在右下”的卡片列表。这个布局来自训练数据中的常见模式，不代表你的业务一定需要。所以你在评审生成结果时，不是看它“画得对不对”，而是看它“理解得准不准”。准的部分，是它读懂了“商品列表”这个语义；不准的部分，是没有体现出你的商品是重图片还是重文字，是双列还是单列，是瀑布流还是平铺。这些约束，需要你在描述时额外补充。
这也是很多教程不会告诉你的：文本生成原型，要当成“写需求文档”来做，而不是“发微信”。你给的信息越结构化，生成的界面越接近预期。我习惯用一个固定格式：
- 项目类型和平台（iOS App、Android App、小程序、后台管理端）
- 主要用户角色（普通用户、管理员、访客）
- 核心任务流（用户要完成哪些事，先后顺序）
- 页面清单（至少把主流程页面列出来）
- 关键交互（点击、滑动、长按之后发生什么）
- 视觉风格（简洁、明亮、品牌感强、偏数据展示）
这样做的好处是，AI 能在第一版就生成一个能评审的稿子，而不是一堆需要大改的骨架。拿我自己来说，同样是“做一个咖啡点单 App”，我试过两次输入。第一次是“帮我做个咖啡点单 App”，生成了首页、菜单、购物车、订单四个页面，但商品详情页缺失，购物车没有结算按钮。第二次我补了一句话：“用户从首页选择咖啡，进入详情页，选择杯型和温度，加入购物车，购物车页可调整数量并结算，结算后进入订单确认页。”这一次，生成结果不仅页面齐了，连详情页的选项组和购物车的“去结算”按钮都对齐了。
这件事给我最大的启发是：AI 在交互流程的理解上，远比视觉细节更依赖你的描述。你如果不说，它就按最通用的模板猜。猜的结果往往不够用，但你只要说出关键路径，它基本能还原出可用的交互框架。所以，把文本生成原型理解成一个“需求结构化”的过程，心态就对了。
2. 文本生成原型的正确打开方式：不是聊天，而是在写“结构化需求”
很多人用 Text-to-Prototype 感觉不好用，原因通常不是工具差，而是输入方式不对。他们把它当成聊天机器人，一句一句地往外蹦：“加个按钮”“按钮换个颜色”“再放个图片”。这种交互方式在修图软件里可以，但在原型生成里，反而容易把上下文搞乱。
我建议你把 AI 生成原型的过程，当成是在提交一份“结构化的需求说明”，一次把关键信息喂完整。因为大多数工具在生成时，是根据你当前会话里的全部信息重新生成或增量调整。你每说一句话，它都需要重新猜测你的意图，如果前面信息太碎，后面的猜测大概率会跑偏。
2.1 提示词怎么写，界面才不跑偏？
先给一个可以直接“抄作业”的模板，我实际用下来成功率很高：
请生成一个 [平台] 的 [产品类型]， 目标用户是 [人群]，他们最核心的任务是 [一句话任务]。 主要页面包括：[页面A]、[页面B]、[页面C]。 关键流程是：用户首先 [动作1]，然后 [动作2]，最后 [动作3]。 视觉风格： [关键词]，主色 [颜色]，字体希望 [风格]。 首屏需要特别突出 [核心元素]。
举个例子，我要做一个“小区住户报修”的 App 原型，就会写：
请生成一个 iOS App 的小区住户报修工具，目标用户是住在小区里的业主，他们最核心的任务是快速提交家里的漏水、电路故障并查看处理进度。 主要页面包括：首页（快捷报修入口、历史工单列表）、报修表单页、工单详情页、个人中心。 关键流程是：用户进入首页点击“快速报修”，填写问题描述并上传照片，提交后跳转到工单详情页，可以看到处理状态和维修人员联系方式。 视觉风格：简洁清爽，主色蓝色，以卡片式布局为主，首屏需要突出报修按钮。
这样一段输入，大多数主流文本生成原型工具都能给出比较靠谱的初稿。你会发现，它生成的首页会把“报修按钮”放在显眼位置，因为你在最后特别强调了这个需求。历史工单列表也会以卡片列表形式出现，符合常见的设计模式。
这里有个细节：尽量少用“好看”“大气”“高级”这些主观词。主观词没法映射到具体的组件参数上，AI 只能猜，猜的结果就是通用风格。想控制视觉，就给具体的方向：圆角大还是小、配色是暖色还是冷色、信息密度高还是低、图片占多大面积。把这些词换成设计参数：“卡片圆角 12px”“主色 #2F6BFF”“列表采用两列网格”“底部 Tab 栏有 4 个入口”。这样生成的界面才和你想要的接近。
2.2 交互逻辑怎么描述：状态、跳转、事件和反馈
文本生成原型的“交互”通常包括形式上的可点击跳转，还有状态变化和反馈。很多人只描述页面，不描述状态，结果生成的原型点着点着就断了。我总结了一个四要素写法：
- 事件：用户做了什么操作，比如“点击按钮”“下拉刷新”“左滑删除”。
- 跳转：操作之后进入哪个页面，或者停留在当前页面。
- 状态：页面当前处于什么模式，比如“空数据”“加载中”“登录后”“编辑中”。
- 反馈：系统给用户什么提示，比如“弹 Toast”“跳转到成功页”“按钮变灰不可点”。
举个例子，描述“登录页”时，你可以这样写：
登录页包含手机号输入框、验证码输入框和登录按钮。用户输入手机号并点击“获取验证码”后，按钮变为倒计时状态。登录按钮点击时校验输入，如果手机号格式错误，输入框下方显示红色提示文案。校验通过后，跳转到首页。
这段话里包含了事件（点击）、状态（倒计时、错误态）、跳转（跳转到首页）、反馈（提示文案）。AI 拿到这种描述，生成的可交互原型就会真正“能点”，而不是一堆静态页面。我见过有人生成原型后，发现“获取验证码”按钮点了没有任何反应，后来检查提示词，发现压根没提倒计时的事。这不能怪 AI，只能怪需求没说。
还有一个习惯我建议你养成：写完描述后，自己在心里按照“用户路径”走一遍。你走完发现某个环节缺失，比如“提交之后没有成功页”，那就先在提示词里补上，再让 AI 生成。这样能显著减少后期的返工。
2.3 让AI帮你完成“首稿”，把精力留给评审和迭代
我经常和团队里的设计师说：AI 生成原型最值得用的场景，是项目刚开始时那个“什么都还没有”的阶段。这时候你让 AI 出第一版，哪怕不太完美，也比空白画布强。因为它能给你一个具体的、可讨论的对象，而不是让会议停留在抽象概念里。
在这种用法下，你的角色从“执笔人”变成了“评审人”。我看到很多人困在细节里，非要让 AI 一次生成完美的图，结果来回改提示词花了一个小时。正确的姿势是：第一版生成后，快速浏览整体结构和关键流程，把明显不对的地方记下来，然后针对问题做增量修改。不要指望一次对话解决所有问题，你把它当成一个推进迭代的工具，效率立刻高很多。
举个例子，我让 AI 生成“个人中心”页面时，它默认给了一个头像、一个设置入口、一列功能菜单。但我们的业务需要突出“家庭住户认证状态”，我就追加一句：“在个人中心页顶部增加认证状态卡片，如果未认证，显示红色感叹号和去认证按钮，点击跳转认证流程。”AI 收到这个增量需求后，通常是保留原有布局，只增加我提到的部分。这种“基于上一版迭代”的方式，比我要求它重画更可控。
使用文本生成原型的最终目标，是让初稿时间压缩到原来的五分之一，然后你把省下来的时间投入到真正需要人判断的地方：信息架构是否合理，关键流程是否顺畅，业务约束是否被体现。这些才是原型设计的核心价值，而不是画几个矩形和圆角。
3. D2C：从设计稿到代码，链路比你想的更接近“可用”
如果你以为 Text-to-Prototype 只是给产品经理用的，那 D2C 才是真正让设计师和前端都盯着的环节。Design to Code，设计转代码，核心目标是让设计稿自动生成前端代码，减少人工切图和重复写样式的时间。这个领域最近两年变化很大，早期只能导出静态布局，现在已经开始生成能对接业务逻辑的组件代码。
我经常听到前端同事抱怨“设计稿只是张图，我们要重新写一遍布局”。实际上，D2C 工具的设计思路，就是尝试消除“图片到代码”之间的误解。它通过分析设计稿中的图层结构、约束方式、文本样式、自动布局属性，把它们翻译成 HTML/CSS 或特定框架的代码（比如小程序、React 或 Vue）。这个过程比想象中复杂，因为它需要理解“视觉层级”和“代码层级”的对应关系。
3.1 D2C工具到底在解什么题：不是切图，而是生成可维护的组件代码
先说一个常见的误解：D2C 不是把设计稿里的图层“切”出来，再打包成图片。它是把图层中的“布局信息”转成代码里的“结构”。设计稿里一个卡片是一个容器，容器内有图片、文本、按钮。在代码里，这个容器可能对应一个组件，图片是 image 标签，文本是 text 节点，按钮是可点击的交互元素。D2C 要做的就是把这些对应关系识别出来，并生成符合工程习惯的代码。
这里面最核心的技术点是“自动布局识别”。现在主流的设计软件都支持自动布局，也就是用约束关系来确定元素之间的间距和对齐方式。D2C 工具能否生成高质量代码，往往取决于设计稿的自动布局是否规范。如果设计稿里每个元素都是用绝对定位摆放的，间距全靠肉眼对齐，那 D2C 生成代码时就会是一堆嵌套的 position 绝对定位，维护起来非常痛苦。
我见过一个团队，设计稿画得很漂亮，但图层命名全是“矩形 1”“矩形 2”“文本 3”，自动布局也没怎么用。拿到 D2C 工具里一试，生成的代码结构混乱，前端同事完全没办法用。后来设计师花了两天把设计稿的图层命好名、把自动布局补全，再生成代码，质量明显上了一个台阶。所以 D2C 能不能用得好，一半取决于工具，另一半取决于设计稿本身的规范程度。
3.2 设计稿里常见的坑：自动布局、命名规范、样式token
如果你准备在项目里引入 D2C，我强烈建议先跟设计师对齐这三件事：
第一，所有容器尽量使用自动布局，而不是手动拖拽定位。自动布局定义了子元素的排列方向、间距和缩放规则，这些信息能够直接映射到 CSS 的 flex 或 grid。没有自动布局，工具就只能猜测元素之间的相对位置，生成结果自然不精准。
第二，图层命名要有意义。一个输入框的图层最好叫“phone_input/container”，而不是“Frame 78”。D2C 工具通常会根据图层名称生成代码变量名和类名。命名混乱会导致代码里出现一堆语义不清的变量，前端还得逐个修改，成本反而更高。
第三，颜色、字体、圆角、阴影等属性尽量使用样式 Token（设计变量）。比如把主色定义为 brand-primary，而不是每个地方直接写一个十六进制颜色值。这样生成的代码可以自动引用全局样式变量，而不是写死颜色。否则，前端拿到代码后还得忍着耐心，一个个颜色去匹配设计系统。
我不是说设计稿必须为了 D2C 做出很大牺牲，而是这些规范本身就是好设计的标配。即使不引入 D2C，图层命名清晰、自动布局合理、使用样式 Token，也会让设计和开发的协作顺畅很多。D2C 只是把这些规范的长期价值提前兑现了。
3.3 D2C输出的代码，拿到手后该改什么、不该改什么
说实话，目前 D2C 生成的代码，还没有到“一键上线”的程度。它更像是一个“可以用的初稿”，能帮你省掉 70% 的重复布局工作量，剩下的 30% 还是要人来处理。关键是你要知道哪些地方该继续“人肉”修改，哪些地方干脆别改。
我的经验是：布局结构、间距、字体大小、颜色这些视觉属性，D2C 生成得已经相当准确，直接保留就好。需要重点检查的是“交互状态”和“业务逻辑”。比如按钮的禁用态、列表的空数据态、网络加载失败态，设计稿里如果只画了默认态，D2C 当然不会生成对应的代码。这些需要前端手动补充。
另一个需要注意的地方是代码的可复用性。D2C 生成的组件，有时会把一个页面里所有元素都铺在一个大组件下，而没有拆分出“子组件”。如果你需要把某个卡片复用在其他页面，就得手动把它抽成一个独立组件。这个操作不复杂，但需要理解设计稿的结构。所以，不要天真地以为 D2C 能帮你直接生成可维护性完美的工程代码，它给你的是一个经过翻译的、结构可靠的初稿，仍然需要你以工程标准去整理。
在我实际使用中，比较顺畅的流程是：设计师完成界面稿并标注好自动布局，前端对 D2C 生成代码做一次“结构化梳理”——把重复区块抽成函数或组件，把网络请求和数据绑定加上，然后在真机上跑一遍。这样一轮下来，一个中等复杂度的页面，工作量能减少一半以上。
4. 一次真实流程复盘：用一句话做出一个可点击的登录流程
光讲原理容易飘，我来复盘一次我实际走通的完整过程。这个流程我用的输入非常简单，不是长篇大论，但关键信息都覆盖到了。项目背景是一个模拟的社区生活服务 App，需要先做一个“用户登录”的交互流程，验证交互方案是否顺畅。
4.1 需求描述（一句话+补充约束）
我先输入了这样一段话：
生成一个 App 登录流程：包含手机号输入框、验证码输入框、获取验证码按钮、登录按钮、用户协议勾选框。点击获取验证码后按钮开始倒计时 60 秒，点击登录时校验手机号和验证码，校验成功进入首页，失败则提示错误信息。页面风格干净现代，主色使用蓝色。
这段话不算长，但覆盖了平台（App）、页面元素、交互事件、状态变化、成功/失败分支。补充约束只有一处：风格干净现代，主色蓝色。信息量已经足够让一个成熟的生成工具给出骨架。
4.2 生成的界面结构说明与交互映射
生成的结果是三个页面：登录页、验证码发送中状态页（实际上仍停留在登录页）、登录成功后的首页。其中登录页的结构如下：
- 顶部是产品 Logo 和一个欢迎文案
- 中间是手机号输入框，下方是验证码输入框
- 验证码输入框右侧有一个“获取验证码”按钮
- 下方是登录按钮，默认灰色，输入合法后变为蓝色
- 底部是用户协议和隐私协议勾选区域
交互连线也自动建立起来了：点击“获取验证码”按钮，按钮变为倒计时文案“60s 后重发”，并出现一个 toast 提示“验证码已发送”；点击登录按钮时，如果输入框为空，下方会出现红色提示文案；如果填好并勾选协议，跳转到首页。
不得不承认，这个自动生成的流程基本符合我给的描述。尤其是协议勾选逻辑，我没有明确说“不勾选不能登录”，但工具很可能从训练数据中学习到了常见模式，默认加上了。这既是一个惊喜，也是一个提醒：要仔细审查 AI 自行补充的假设是否满足业务要求。比如说，如果你的业务允许游客跳过登录直接浏览首页，那这里自动生成的拦截逻辑就需要改。
4.3 人工微调的地方与最终效果
在这个流程里，我做了三处调整。
第一，默认生成的验证码按钮，倒计时结束后自动恢复为“获取验证码”，我希望改成“重新获取”，没有实际区别，但团队文案统一要求“重新获取”，所以改了文案。
第二，登录成功跳转首页后，我原本希望加一个“欢迎回来”的提示，AI 没生成，我在生成后的原型里手动加了一个轻提示。这一步说明 AI 不能理解你未明确表达的细节，你自己补成本不高的东西反而更快。
第三，协议内容默认只有文字链接，但我们的业务需要展示协议弹窗页面。我追加了一个描述，生成一个协议弹窗页并设置了点击事件。这里也没有重新生成整个流程，而是让 AI 在已有基础上新增页面和连线，效率非常高。
最终效果是，整个流程可以顺畅点到底，所有跳转和状态变化都符合预期。我当时粗略记了下时间，从输入需求到调整完成，大概花了二十分钟，其中大部分时间是在思考文案和补充协议弹窗内容，真正调整交互连线只花了五分钟。如果是以前用设计工具直接画，至少要两个小时，还不算沟通成本。
这次复盘想说明的其实是：Text-to-Prototype 的可用性比我预想的高，但它需要你用“做需求”的心态来输入，而不是“魔法棒一挥”。流程描述越明确，生成的交互就越没有歧义。你可以在拿到初稿后，像评审别人的原型一样去挑毛病，而不是把它当成最终结果。
5. 踩坑记录与排查技巧：这些坑，我建议你提前避开
任何一个工具，只有踩过坑才知道它的边界。我从几个不同的实际项目里总结了一些高频问题和排查思路，整理成速查表，希望能帮你少走弯路。
5.1 提示词地狱：AI经常漏掉某个页面怎么办
最典型的问题：你明明在提示词里写了“订单详情页”，生成结果却没有这个页面，或者生成了但没任何元素。原因通常是你的提示词里信息太密集，模型在输出时丢了部分内容，这种情况在大模型场景里很常见。
我的排查习惯是先看“页面清单”是否完整。如果一个对话里同时要生成五个以上页面，我会在提示词里用列表逐行写明：“页面1：首页，包含……；页面2：列表页，包含……”。这样比在一个长句子里描述更不容易漏。还有一种办法是分阶段生成：先让它生成页面清单，确认无误后，再让它按清单逐个生成页面。
如果生成结果已经出来了，但少了某个页面，不要重新开始对话。试着追加一句：“刚才的流程中还应该有一个订单详情页，它包含订单编号、商品列表、支付状态三个区块。请补充生成这个页面，并让首页商品列表点击跳转到这里。”多数工具支持这种增量追加。如果工具不支持增量追加，那就只能把它当成一个约束条件，后续重新生成时记得把页面列表单独提级强调。
5.2 交互连线乱跳：如何修复状态关系
另一个常见问题是交互连线画得不对：点击按钮本应跳转到详情页，结果跳到了个人中心；或者倒计时按钮没有在状态变化时更新。这类问题通常不是生成工具抽风，而是它对你描述中的“事件与动作”对应关系理解不够深。
我建议你在描述交互时，尽量使用“用户做什么——发生什么”的句式，避免一句话里混合多个动作。比如不要写“用户点击登录按钮和验证码按钮后，分别校验并跳转”。而是要写：
- 点击获取验证码按钮 -> 按钮进入倒计时
- 点击登录按钮 -> 校验输入，成功跳转首页，失败提示错误
这样工具会把注意力放在一对一的映射上。如果连线还是乱了，就在生成后的原型里手动调整热区或连接线。大多数原型工具都允许你手动修改交互连线，这一步的成本并不高。对我来说，能用人工修复解决的问题，都比重新和 AI 对话更可控。
5.3 代码生成结果与现有工程结构冲突的处理
D2C 的实际落地，最大的坑不是代码对不对，而是代码风格与现有工程不一致。比如你们的组件库有自己定义好的 Button，而 D2C 生成的是原生 button 标签；你们的样式方案用的是局部样式，而 D2C 生成的是内联样式。这些冲突如果靠人肉修改，工作量会很大。
我的经验是：在做 D2C 之前，先检查工具是否支持“自定义组件映射”。很多成熟的 D2C 工具允许你定义一套映射规则，比如“设计稿中的主按钮组件对应项目里的 PrimaryButton 组件”“主色变量对应 styles/colors.primary”等。提前配置好映射，生成的代码会符合你们团队的工程习惯，而不是还要二次重写。
如果映射配置不到位，还有一种兜底方案：先生成代码，然后跑一次批量替换。比如把内联样式中的颜色值替换成样式变量引用，把 class 名统一加上前缀。这个过程可以用脚本半自动化完成，但前提是你对生成代码的规律足够熟悉。我试过把生成代码做一次全局检查，总结出常见差异点，然后写了一个小脚本替代人工处理。之后每次生成都先过一遍脚本，省下不少时间。
最后提醒一句，D2C 生成代码不要直接合并到主干分支。先放在分支里，人工 review 一遍，重点检查是否有多余嵌套、是否有丢失的交互状态、是否有不合理的组件拆分。把 D2C 当成一个“自动化的第一版代码生成器”，而不是“最终代码的替代者”，你就不会对它产生不切实际的怨念了。
我个人在实际项目里折腾完这一整条链路后的体会是：Text-to-Prototype 适合在想法还没成形时快速搭出可交互的骨架，D2C 适合在界面定稿后把样式和布局快速翻译成工程代码。两者分开用，各有价值；串联起来用，能让一个小团队在没有专职设计师的情况下，从零做出一个能演示、能评审、能开发的完整流程。当然，工具不等于设计能力，也不等于代码水平。但它确实把我们从那些重复、低价值的劳动里解放出来了。剩下的事，才是真正需要你动脑去思考的：这个界面解决了什么问题，这条流程是不是足够顺。
最后再分享一个小技巧：如果你担心 AI 生成的页面缺少细节，可以故意在提示词里增加一个“异常场景”。比如“提交订单时如果优惠券已过期，要显示提示文案”。你会发现，AI 会为了应对这个异常场景，主动补充一个弹窗或提示区域。多给 AI 一些业务约束，它生成的界面就会更接近真实产品，而不是停留在花哨的演示稿阶段。这招我屡试不爽。
