Text-to-Prototype与D2C实战：从一句话到可交互原型的工程化工作流

一句话丢给 AI，它真能吐出一套能点、能跳转、能填表单的 App 原型？这个问题在过去一年里被问了无数遍，我自己也拿它当正经课题折腾了小半年。Text-to-Prototype，也就是文本生成原型，再到 D2C（Design to Code，设计转代码），这条链路听起来像是把产品经理、设计师、前端三个岗位一口气打包塞进一个输入框里。实际用下来，我的结论是：能画，但"能画"和"能用"之间隔着一整套工程化的工作流。这篇就把我踩过的坑、验证过的流程、以及那些文档里不会写的细节，一次性摊开讲清楚。

1. 先搞清楚 Text-to-Prototype 到底在生成什么

1.1 从一句话到界面，中间发生了什么

很多人对"一句话生成原型"的想象是：输入"做一个外卖 App 首页"，然后 AI 直接输出一个可以安装的 App。这个预期从一开始就偏了。目前主流方案生成的产物，本质上是结构化的界面描述，而不是可运行的应用程序。这个描述可能是一段 HTML+CSS，可能是一份 JSON 格式的组件树，也可能是某种设计工具能识别的图层结构。

理解这一点非常关键，因为它决定了你后续所有工作的方向。如果生成的是 HTML，那你拿到的是一个网页；如果生成的是组件树 JSON，那你拿到的是可以导入设计工具的素材；如果生成的是某种中间格式，那你还需要一层转换才能落地。

我实测过几种不同的输入粒度，效果差异极大：

结论很直接：AI 不是读心术，它只能把你描述清楚的东西画出来。你描述里没提的，它就自由发挥，而自由发挥的部分往往就是你需要返工的部分。

1.2 为什么"可交互"是个被夸大的词

标题里问"真能画出可交互界面吗"，我的答案是：能生成带交互的代码，但交互逻辑的完整度取决于你的描述精度和后续补全。

AI 生成的交互通常停留在几个层面：页面之间的跳转、按钮的点击态、简单的表单输入。再往深了走，比如"点击加入购物车后，购物车角标数字加一，同时弹出轻提示，3 秒后自动消失"，这种带状态联动和时序控制的交互，AI 基本生成不出来，或者生成出来的代码逻辑是错的。

原因也不复杂。交互逻辑涉及状态管理、事件流、异步处理，这些是程序逻辑而不是视觉描述。文本生成原型的强项在于把视觉结构翻译成代码结构，弱项恰恰在于业务逻辑。所以正确的用法是：让 AI 干它擅长的视觉骨架，逻辑部分自己补。

提示：把 Text-to-Prototype 当成"高级线框图生成器"来用，心态会稳很多。指望它一步到位产出可上线的交互，目前还不现实。

2. 工具选型：不同路线适合不同的人

2.1 三条主流技术路线对比

市面上能实现文本生成原型的方案，我大致归为三类，每类的原理和适用场景完全不同。

第一类是基于大语言模型直接生成代码。你给一段描述，模型直接输出 HTML/CSS/JS 或者 React/Vue 组件代码。这类方案灵活度最高，生成的是真代码，可以直接跑起来。缺点是代码质量参差不齐，复杂布局容易崩，需要你有一定的代码能力去修。

第二类是基于设计工具的插件或内置 AI。这类方案生成的是设计工具里的图层和组件，你拿到的是可编辑的设计稿。优点是产物规整、符合设计规范，缺点是它不生成代码，你还得走一遍 D2C 流程。

第三类是基于结构化中间格式。模型输出一份描述界面的 JSON 或 DSL，再由渲染引擎把它变成界面。这类方案的好处是可控性强，坏处是生态相对封闭，导出能力有限。

2.2 选型时我真正在意的三个指标

选工具的时候，宣传页上那些"支持多少种组件""生成速度多快"其实都是次要的。我踩坑之后总结出三个真正决定体验的指标。

第一是布局还原度。给它一个稍微复杂点的布局，比如"左中右三栏，中间自适应，两侧固定宽度，中间内容超出可滚动"，看它能不能正确理解 flex 或者 grid 的意图。很多工具在这种嵌套布局上直接翻车，生成一堆绝对定位，改都没法改。

第二是组件语义化程度。生成的是<div>套<div>，还是<button>、<input>、<nav>这种语义化标签。前者你后续维护想死，后者至少还能读。语义化程度直接决定了生成代码的"可维护寿命"。

第三是导出与二次编辑能力。生成的产物能不能导出成标准格式，能不能在别的工具里继续编辑。有些工具生成的东西只能在它自己的环境里改，一旦想迁移就全废了。这个坑我在早期项目里吃过一次，后来选型第一件事就是测导出。

注意：不要被"一键生成完整 App"这种宣传语带偏。任何声称一句话生成完整应用的方案，实际交付的都是一个需要大量返工的半成品。

3. 实操流程：从一句话到可交互原型的完整链路

3.1 描述词的写法决定了 80% 的成败

这一节是我最想强调的。同样的工具，描述词写得好和写得烂，产出质量能差出三倍。我总结了一套"分层描述法"，实测下来稳定性最高。

第一层是页面骨架：这个页面由哪几个大区块组成，从上到下或者从左到右的顺序是什么。比如"顶部导航栏、中部内容区、底部标签栏"。

第二层是区块内部结构：每个大区块里有什么。比如"顶部导航栏左侧是返回图标，中间是标题文字，右侧是分享图标"。

第三层是组件细节：每个组件的具体属性。比如"商品卡片包含正方形图片、两行标题、红色价格文字、灰色销量文字"。

第四层是交互与状态：哪些元素可点击，点击后发生什么。比如"点击商品卡片跳转到详情页"。

我做过对比测试，只写第一层的产出，返工率大概 70%；写到第三层的产出，返工率降到 30% 左右；写到第四层的，返工率能压到 15% 以内。多花五分钟写描述，能省半小时返工，这笔账很划算。

示例描述词（可直接套用）： 页面：商品列表页 骨架：顶部搜索栏 + 中部商品网格 + 底部标签栏 搜索栏：左侧返回图标，中间输入框占位文字"搜索商品"，右侧筛选图标 商品网格：两列，每张卡片包含正方形商品图、两行标题、价格、销量 底部标签栏：首页、分类、购物车、我的，当前选中首页 交互：点击卡片跳转详情页，点击购物车图标跳转购物车页

3.2 生成后的第一轮处理：别急着改，先跑起来

拿到生成结果后，很多人的第一反应是打开代码开始改。我的建议是先原封不动跑起来看效果。原因是你得先知道它的基线水平在哪，哪些是它做对的，哪些是做错的，改的时候才有针对性。

跑起来之后，我会做一次"三色标记"：绿色是直接能用的，黄色是改改能用的，红色是必须重写的。这个动作花不了几分钟，但能让你对工作量有个准确预估。我见过太多人上来就埋头改，改到一半发现整个布局思路是错的，只能推倒重来。

第一轮处理里，布局问题优先于样式问题。布局错了，样式改得再漂亮也是白搭。布局对了，样式问题都是小修小补。判断布局对不对，就看它用的是不是正常的文档流或者 flex/grid，如果满屏绝对定位，那基本可以判定布局需要重构。

3.3 从原型到可交互：补全逻辑的正确姿势

AI 生成的交互通常是"骨架级"的，比如按钮有onclick但里面是空的，或者跳转链接是#。补全逻辑的时候，我建议按这个顺序来。

先补导航跳转，这是最简单也最影响体验的部分。把所有的占位链接换成真实的路由跳转，页面之间能来回走通了，原型就有了"活"的感觉。

再补状态联动。比如购物车角标、表单校验、列表筛选，这些涉及数据变化的部分。这部分建议用最朴素的方式实现，别一上来就上状态管理库，原型阶段没必要。

最后补异步与反馈。比如提交表单后的加载态、成功提示、失败重试。这部分是原型的"最后一公里"，补上之后演示效果会好很多。

实操心得：补逻辑的时候，把 AI 生成的代码当成"别人写的代码"来对待，先读懂再改。直接在上面乱改，很容易把原本正确的结构改坏。

4. D2C：设计稿转代码这条路的真实体验

4.1 D2C 和 Text-to-Prototype 的本质区别

很多人把这两个概念混在一起，其实它们的输入完全不同。Text-to-Prototype 的输入是文字描述，D2C 的输入是设计稿。前者是从零生成，后者是从已有设计还原。

这个区别决定了它们的适用场景。如果你手上已经有设计师做好的稿子，那 D2C 是更靠谱的选择，因为设计稿本身就是精确的，转换过程只是"翻译"而不是"创作"。如果你手上什么都没有，只有一个想法，那 Text-to-Prototype 更适合做快速验证。

D2C 的核心价值在于消除设计到开发之间的手工还原成本。传统流程里，前端要对着设计稿一个像素一个像素地量，现在工具能自动读取设计稿的图层信息、间距、颜色、字体，直接生成对应的代码。理论上能省掉大量重复劳动。

4.2 D2C 转换质量的几个关键影响因素

实测下来，D2C 的转换质量受几个因素影响很大，这些因素往往被忽略。

图层命名规范程度。设计稿里图层叫"矩形 1""编组 23"，转换出来的代码类名就是一堆无意义的字符串。如果图层命名规范，比如"search-bar""product-card"，转换出来的代码可读性会好很多。这一点值得跟设计师提前对齐。

自动布局的使用情况。设计工具里的自动布局功能，对应到代码里就是 flex 布局。用了自动布局的图层，转换出来的代码结构清晰；没用自动布局、全靠手动摆放的，转换出来就是一堆绝对定位。

组件化程度。设计稿里如果用了组件和实例，转换工具能识别出复用关系，生成可复用的代码组件。如果全是散图层，那转换出来就是一堆重复代码。

4.3 D2C 产物落地的三个必经步骤

D2C 生成的代码不能直接用，这是我反复验证过的结论。它需要经过三个步骤的处理才能进项目。

第一步是结构清理。转换工具生成的 DOM 结构往往有多余的嵌套，比如为了还原某个视觉效果套了好几层 div。这些冗余结构要手动拍平，否则会影响性能和可维护性。

第二步是样式归一。生成的样式往往是内联的或者散落的，需要整理成项目的样式规范，比如统一用 CSS 变量、统一间距单位、统一颜色命名。

第三步是逻辑接入。D2C 只负责视觉，交互逻辑还是得自己写。这一步和 Text-to-Prototype 的逻辑补全是一样的思路。

注意：D2C 的定位是"减少重复劳动"，不是"替代前端"。把它当成一个高级的切图工具，期望值就对了。

5. 常见问题与排查技巧实录

5.1 生成结果"看起来对但用起来不对"怎么办

这是最常见的问题。生成的原型乍一看挺像那么回事，但一交互就露馅：点击没反应、跳转乱套、布局在真机上错位。

排查这类问题，我有一套固定流程。先看控制台报错，很多时候是生成的代码里有语法错误或者引用了不存在的资源。再看事件绑定，检查按钮的点击事件是不是真的绑上了，还是只是个装饰。最后看响应式表现，把窗口拉窄或者用真机预览，看布局会不会崩。

我遇到过最典型的一次，是生成的卡片列表在桌面端看着正常，一到移动端就横向溢出。查下来是生成代码里写死了宽度，没有用相对单位。这种问题在生成阶段很难避免，只能靠测试发现。

5.2 生成代码"改不动"的困境

有时候生成的代码结构极其混乱，你想改一个小地方，牵一发而动全身。这种情况我的建议是不要硬改，重写局部。

具体做法是：把出问题的那个区块单独拎出来，用生成工具重新生成一次，这次描述词写得更细。或者干脆手写这个区块，因为手写一个结构清晰的区块，往往比修复一个结构混乱的区块更快。

这个判断标准很简单：如果你改一个地方需要动三个以上的文件或者超过二十行代码，那就说明这个结构本身有问题，重写比修复划算。

5.3 常见问题速查表

5.4 几个我踩过的坑

第一个坑是过度信任生成结果。早期我拿到生成的原型，觉得差不多就直接拿去演示，结果现场点击跳转失败，非常尴尬。后来我养成了习惯，任何原型在演示前必须完整走一遍所有交互路径。

第二个坑是描述词写得太抽象。比如写"做一个好看的首页"，"好看"这个词对 AI 来说毫无意义。后来我改成具体的布局和组件描述，产出质量立刻上了一个台阶。

第三个坑是忽略导出格式。有一次用某个工具做了半天，最后发现导出格式不兼容，只能截图重做。现在我选工具第一件事就是测导出，导出不通的工具直接放弃。

实操心得：把每次生成的结果和描述词都存下来，形成自己的"描述词-结果"对照库。用久了你会发现，某些描述词写法就是比其他写法效果好，这个经验是任何文档都给不了的。

6. 这套工作流真正适合谁

6.1 产品经理：快速验证想法的最优解

对产品经理来说，Text-to-Prototype 最大的价值是把想法变成可点击的东西。以前要等设计师排期，现在自己花十分钟就能出一个能演示的原型，拿去跟团队对齐或者做用户测试，效率提升非常明显。

但要注意，产品经理用这套流程，重点应该放在"结构"和"流程"上，而不是"视觉"。别纠结按钮圆角是 4px 还是 8px，那是设计师的活。你要验证的是"这个流程顺不顺""用户能不能找到入口"。

6.2 设计师：把重复劳动交给工具

设计师用 D2C 的价值在于省掉标注和切图的环节。以前做完设计稿还要写标注文档、导出切图，现在工具能自动完成这部分。省下来的时间可以花在更有价值的创意工作上。

不过设计师要注意，D2C 对设计稿的规范性要求很高。图层命名、自动布局、组件化，这些习惯得提前养成，否则转换质量会很差。

6.3 前端：把它当成"起手式"而不是"替代品"

前端用这套工具，心态要摆正。它生成的是初稿，不是成品。你可以用它快速搭出页面骨架，然后在这个骨架上补逻辑、调细节。它帮你省掉的是从零写结构的时间，而不是全部开发时间。

我自己的用法是：新项目起步阶段，用生成工具快速搭出主要页面的骨架，然后逐个页面精修。这样比从空白文件开始写快很多，尤其是那些布局规整的后台页面。

6.4 独立开发者：一个人干三个人的活

对独立开发者来说，这套工作流的价值最大。你一个人要兼顾产品、设计、开发，时间根本不够用。用 Text-to-Prototype 快速出原型验证方向，用 D2C 快速还原设计，能把有限的精力集中在核心逻辑上。

我认识的一个独立开发者，用这套流程把一个小工具从想法到上线的时间压缩到了两周。他的做法是：先用文本生成原型验证核心流程，跑通之后再精修视觉，最后补全业务逻辑。整个过程没有设计师参与，全靠工具补位。

7. 我对这条链路的一些真实判断

7.1 它改变了什么，没改变什么

这套工作流真正改变的，是从想法到可视化的速度。以前一个想法要变成能看的东西，中间隔着设计、切图、开发好几道工序，现在这个链条被压缩了。这是实打实的效率提升。

它没有改变的，是产品思考的深度和工程实现的复杂度。工具能帮你画出界面，但画不出好的产品逻辑；能帮你生成代码，但生成不了健壮的架构。这两件事还是得靠人。

所以我的判断是：这套工具会淘汰掉那些纯粹的"执行型"工作，比如机械地切图、机械地还原设计稿。但它不会淘汰"思考型"的工作，反而会让思考的价值更突出。因为当执行变快了，瓶颈就转移到了"想清楚要做什么"上。

7.2 给想入坑的人几句实在话

如果你刚开始接触这条链路，我的建议是从最小的场景开始。别一上来就想生成一个完整的 App，先从一个页面、一个组件开始，把描述词写法、生成质量、返工流程都摸清楚，再逐步扩大范围。

另外，别追求一步到位。生成-修改-再生成，这个循环是常态。接受这个循环，把它当成工作流的一部分，心态会好很多。我见过太多人因为第一次生成结果不理想就放弃了，其实多迭代两轮，结果往往能接受。

最后，保持对生成结果的怀疑。AI 生成的东西，看起来越顺眼，越要仔细检查。它很擅长生成"看起来对"的东西，但"看起来对"和"真的对"之间，往往就差那么一两个隐藏的 bug。这个坑，我踩过不止一次。

这套东西还在快速演进，今天不好用的功能，可能下个月就变好用了。所以别急着下结论说它行或者不行，保持关注，保持动手试，比什么都强。