企业官网建设流程全解析

1. 从一句话到可交互界面，这条路到底走不走得通

前阵子跟几个做产品的老伙计吃饭，席间有人抛出一个问题：现在跟 AI 说一句“帮我做一个记账 App 的首页，顶部是总资产卡片，下面放最近三笔流水，右下角一个悬浮记账按钮”，它能不能直接给我吐出一个能点、能跳转、能演示的原型？当时桌上分成了两派，一派觉得这就是个噱头，生成的顶多是一张好看的静态图；另一派觉得已经能用了，至少能省掉画线框图那一步。我自己前后折腾了大概两个月，把市面上主流的几条技术路线都摸了一遍，结论是：能画出来，但“可交互”这三个字的含金量，取决于你对交互的定义，以及你选的工具链走到了哪一层。

这篇文章我想把 Text-to-Prototype（文本生成原型）和 D2C（Design to Code，设计转代码）这两条线彻底拆开讲清楚。前者解决的是“从零到一有东西看”，后者解决的是“从设计稿到能跑的代码”。很多人把这两件事混为一谈，以为一句话生成的就是最终代码，其实中间隔着好几道工序。我会从整体思路、核心技术点、实操流程、踩坑记录四个维度展开，把每个环节的参数选择、工具取舍、常见故障都讲透。不管你是产品经理、UI 设计师，还是想快速验证想法的独立开发者，看完应该都能上手跑一遍。

先说清楚适用边界。Text-to-Prototype 最适合的场景是早期概念验证和内部沟通——你有一个模糊的想法，需要快速变成看得见摸得着的东西，拿去跟团队或客户对齐。它不适合直接产出生产级代码，也不适合对交互细节要求极高的项目。D2C 则更适合设计稿已经定稿、需要批量转成前端代码的场景，能大幅压缩还原设计稿的工时。两者结合使用，才是目前比较务实的打法。

2. 整体设计与技术路线拆解

2.1 一句话生成原型，底层到底在干什么

当你输入“做一个电商商品详情页，顶部轮播图，中间价格和标题，底部加入购物车按钮”这句话时，AI 并不是凭空变出界面的。它背后至少跑了三层逻辑。第一层是意图解析，把自然语言拆解成结构化的界面描述，比如“轮播图”对应一个横向滑动的图片容器，“加入购物车按钮”对应一个固定在底部的操作栏。第二层是布局推理，根据常见的移动端设计规范，决定这些元素谁在上谁在下、间距多少、用什么对齐方式。第三层是代码生成，把布局描述翻译成 HTML/CSS 或者某个框架的组件代码。

这三层里，第一层和第二层是 Text-to-Prototype 的核心难点。因为自然语言是模糊的，而界面是精确的。你说“大一点的标题”，多大算大？你说“放下面”，是紧挨着还是留出间距？AI 需要靠训练数据里的常见模式来补全这些缺失信息。所以你会发现，同样一句话，不同工具生成的结果差异很大，因为它们的训练数据和默认设计规范不一样。

目前主流的技术实现有两种路径。一种是基于模板匹配，工具内部预置了大量常见页面模板（登录页、列表页、详情页、个人中心等），AI 把你的描述映射到最接近的模板上，再微调文案和图片。这种路径生成速度快、结构稳定，但灵活性差，遇到非常规布局就抓瞎。另一种是基于布局生成模型，直接预测每个元素的坐标、尺寸和层级关系，再渲染成界面。这种路径灵活度高，但容易出现元素重叠、对齐混乱的问题。

实操建议：如果你要做的是标准业务页面（表单、列表、详情），优先选模板匹配型工具，出图快且规整；如果你要做的是创意型页面（活动页、品牌展示页），选布局生成型工具，虽然需要手动调整，但不会被模板框死。

2.2 D2C 不是魔法，它解决的是还原度问题

D2C 的全称是 Design to Code，直译就是设计转代码。它的输入不是一句话，而是一份设计稿——通常是 Figma 或 Sketch 文件。输出是前端代码，比如 React 组件、Vue 组件或者纯 HTML/CSS。很多人以为 D2C 就是“一键导出代码”，但实际用下来，它更像是一个高精度的代码脚手架生成器。

D2C 的核心技术点在于图层语义识别。设计稿里的图层命名往往很随意，比如“矩形 12”“编组 5”“Frame 238”。D2C 工具需要根据图层的位置、尺寸、样式、层级关系，推断出它到底是一个按钮、一个输入框，还是一个纯装饰性容器。这个推断过程直接决定了生成代码的质量。如果识别错了，生成的代码里就会出现一堆无意义的 div 嵌套，后期维护成本极高。

另一个关键技术点是样式提取与转换。设计稿里的颜色、字体、间距、圆角、阴影，需要被准确地转换成 CSS 属性。这里有个坑：设计工具里的“自动布局”和前端 Flexbox 并不是一一对应的。设计稿里两个元素间距 16px，可能是通过 padding 实现的，也可能是通过 margin 或者 gap 实现的。D2C 工具需要做出合理选择，否则生成的代码虽然视觉上看起来一样，但响应式行为会出问题。

2.3 两条路线怎么选，一张表说清楚

这张表是我自己用下来总结的，不一定全面，但能帮你快速判断该走哪条路。实际项目中，我通常建议先用 Text-to-Prototype 快速出几版概念图，跟相关方对齐方向；方向定了之后，设计师在 Figma 里细化，再用 D2C 转成代码给开发。这样整个链路比较顺，不会出现“AI 生成的原型没法细化”或者“设计稿转出来的代码没法用”的尴尬。

3. 核心细节解析与实操要点

3.1 提示词怎么写，决定了生成质量的上限

Text-to-Prototype 的提示词写法，跟平时跟人沟通需求完全不一样。你跟设计师说“做个简洁大气的首页”，他能理解；你跟 AI 说同样的话，它大概率给你生成一个平庸到不能再平庸的页面。因为“简洁大气”是主观审美，不是可执行的指令。你需要把审美翻译成具体的布局指令和样式参数。

我总结了一个提示词模板，实测下来生成质量明显提升。模板结构是：页面类型 + 区域划分 + 每个区域的内容和样式 + 交互说明。举个例子：

页面类型：移动端电商商品详情页 区域一（顶部）：轮播图，高度 375px，展示 3 张商品图，支持左右滑动 区域二（中部）：商品标题，字号 18px，加粗，最多两行；价格，字号 24px，红色，加粗 区域三（底部）：固定操作栏，包含“加入购物车”按钮，背景色 #FF5000，文字白色，圆角 24px 交互说明：点击轮播图可放大预览，点击加入购物车弹出确认提示

这样写出来的提示词，AI 能提取到明确的布局信息、尺寸信息、颜色信息和交互信息。生成的结果即使不完美，至少大方向是对的，手动调整的工作量会小很多。

注意：不要在一句话里塞太多页面。我试过让 AI 一次性生成“首页 + 分类页 + 购物车 + 个人中心”四个页面，结果每个页面都做得非常粗糙，元素缺失严重。正确的做法是一个页面一个页面地生成，最后再统一调整风格。

3.2 布局推理的常见陷阱与修正方法

即使提示词写得很清楚，AI 生成的布局还是经常出问题。我遇到最多的三种情况是：元素重叠、间距失控、层级混乱。元素重叠通常是因为 AI 对“绝对定位”和“流式布局”的理解不够，把本该上下排列的元素放到了同一层。间距失控是因为 AI 没有全局的间距系统概念，这里给 8px，那里给 20px，看起来就很乱。层级混乱则是 z-index 管理不当，导致弹窗被遮住、按钮点不到。

修正这些问题，不能靠反复重新生成，那样效率太低。我的做法是先生成再手动调整。大部分 Text-to-Prototype 工具都支持生成后拖拽编辑，你只需要把重叠的元素拉开、把间距统一成 8 的倍数、把需要置顶的元素层级调高就行。这个过程比从零画线框图快得多，通常五到十分钟就能调好一个页面。

还有一个技巧是给 AI 设定全局约束。在提示词开头加上“使用 8px 基础间距系统，主色调用 #1890FF，圆角统一 8px”，这样生成出来的页面风格会更统一，后期调整的工作量也会减少。这个技巧是我从一个做设计系统的朋友那里学来的，亲测有效。

3.3 D2C 转换前的设计稿整理规范

D2C 工具再智能，也架不住设计稿本身乱七八糟。如果你拿一份图层命名混乱、样式随意覆盖、组件没有复用设计稿去转代码，出来的结果一定是灾难。所以在转换之前，必须对设计稿做一轮整理。这一步很多人会忽略，但它直接决定了 D2C 的成败。

整理规范我列了五条，按重要性排序。第一，图层命名要语义化。把“矩形 12”改成“btn-submit”，把“编组 5”改成“card-container”。这样 D2C 工具才能准确识别元素类型。第二，使用自动布局。Figma 的 Auto Layout 和前端 Flexbox 是对应的，用了自动布局的图层，转出来的代码结构会清晰很多。第三，颜色和字体样式要统一。不要这里用 #1890FF，那里用 #1890FE，尽量引用样式库里的变量。第四，组件要复用。同一个按钮在多个页面出现，应该做成组件实例，这样转出来的代码也会是同一个组件。第五，隐藏不需要转换的图层。装饰性元素、参考线、标注图层，在转换前隐藏掉，避免生成冗余代码。

实操心得：我通常会在设计稿整理完之后，先转一个页面看看效果。如果这个页面的代码结构合理、类名语义化、样式没有明显错误，再批量转其他页面。如果第一个页面就问题很多，说明设计稿还需要继续整理，不要急着往下走。

3.4 生成代码的可用性评估标准

D2C 生成的代码，不能直接用“能不能跑”来判断好坏。能跑只是最低要求，真正要关注的是可维护性和可扩展性。我一般从四个维度评估：结构是否清晰、类名是否有意义、样式是否可覆盖、组件是否可复用。

结构清晰指的是 DOM 层级不要太深，不要出现五层以上的无意义嵌套。类名有意义指的是不要出现“div-1”“container-2”这种，而是“product-card”“price-tag”这种一看就懂的。样式可覆盖指的是生成的 CSS 不要用太多 !important，不要写死太多绝对值，方便后期调整。组件可复用指的是重复出现的 UI 元素应该被抽成组件，而不是复制粘贴多份代码。

如果生成的代码在这四个维度上表现都不错，那它就可以作为开发的基础，开发只需要接入数据和业务逻辑就行。如果表现很差，那还不如让开发照着设计稿手写，至少代码质量可控。所以 D2C 的价值不在于“替代开发”，而在于“减少开发在还原设计稿上的重复劳动”。

4. 完整实操流程与关键环节实现

4.1 从零开始跑通一条 Text-to-Prototype 链路

我拿一个真实的小项目来演示。需求是做一个“健身打卡”App 的首页，包含今日运动数据卡片、打卡按钮、最近七天打卡记录。我用的工具是一个在线原型生成平台，具体名字就不说了，避免广告嫌疑，操作逻辑都差不多。

第一步，打开工具，选择“移动端页面”类型，输入提示词。我的提示词是这样写的：

移动端健身打卡 App 首页 顶部：用户头像和昵称，右侧一个设置图标 中部：今日运动数据卡片，包含步数、卡路里、运动时长三个指标，横向排列 中部下方：一个圆形打卡按钮，直径 80px，主色 #FF6B35，文字“打卡” 底部：最近七天打卡记录，横向排列七个圆形图标，已打卡的填充主色，未打卡的灰色描边 整体风格：圆角卡片，浅灰色背景 #F5F5F5，卡片白色带轻微阴影

第二步，点击生成。等待大概十到十五秒，工具会输出一个可交互的原型页面。这时候不要急着满意或失望，先检查三件事：元素有没有缺失、布局有没有明显错位、交互能不能点。我这次生成的结果，三个指标卡片挤在了一起，打卡按钮偏到了左上角，七天记录只显示了五天。问题不少，但整体框架是对的。

第三步，手动调整。把三个指标卡片拉开，均匀分布；把打卡按钮拖到页面中央偏下位置；补上缺失的两天记录。调整过程中，工具会实时显示元素的对齐参考线，跟设计软件的操作体验类似。整个过程花了大概八分钟，页面就调得比较顺眼了。

第四步，导出和分享。大部分工具支持导出为图片、PDF 或者一个可分享的链接。我通常导出分享链接，发给相关方看，他们可以直接在手机上打开，点击按钮有简单的反馈效果。这个链接的有效期一般是七天到三十天，足够完成一轮沟通。

4.2 D2C 转换的完整操作与参数配置

D2C 的流程比 Text-to-Prototype 要复杂一些，因为它涉及设计稿的准备和代码的导出。我以 Figma 转 React 组件为例，把完整流程走一遍。

首先，在设计稿里选中要转换的页面或组件。这里有个细节：不要全选整个画板，而是选中你需要转换的具体 Frame。全选会导致生成大量你不需要的代码，比如背景、参考线、标注。选中之后，打开 D2C 插件，通常会在右侧面板出现配置选项。

配置选项里最重要的三个参数是：框架类型、样式方案、组件粒度。框架类型选 React、Vue 还是纯 HTML，取决于你的项目技术栈。样式方案选 CSS Modules、Styled Components 还是 Tailwind，取决于团队习惯。组件粒度选“按图层”还是“按语义”，按图层会生成更多细碎组件，按语义会合并一些相关元素。我一般选“按语义”，生成的代码更简洁。

配置好之后点击转换，插件会花几秒到几十秒处理，然后给出代码预览。预览界面通常分两栏，左边是设计稿，右边是代码。你可以对照着看哪些地方识别对了，哪些地方识别错了。识别错误的地方可以手动修正，比如把一个被识别成图片的图层改成按钮，把一个被识别成容器的图层改成文本。

确认无误后，点击导出，代码会以文件形式下载下来，或者直接推送到你的代码仓库。我通常先导出到本地，跑一遍看看有没有语法错误，再决定要不要合并到项目里。

4.3 参数计算：间距、字号、颜色的转换逻辑

D2C 转换过程中，设计稿的数值到 CSS 的数值并不是简单的一一对应。这里涉及一个单位换算的问题。设计稿通常以 px 为单位，但前端可能需要 rem、em 或者 vw。如果 D2C 工具没有处理好这个换算，生成的代码在不同屏幕上显示效果会不一致。

我的做法是，在转换前先确认设计稿的基准宽度。移动端通常是 375px 或 390px，桌面端通常是 1440px。然后根据基准宽度计算根字号。比如基准宽度 375px，根字号设为 16px，那么设计稿里 32px 的间距，转换成 rem 就是 2rem。这个换算过程，好的 D2C 工具会自动完成，但你需要检查它用的基准值对不对。

颜色的转换相对简单，但要注意透明度的处理。设计稿里一个颜色可能是 #000000 加 50% 透明度，转换成 CSS 应该是 rgba(0,0,0,0.5) 或者 #00000080。有些工具会直接输出 #808080，虽然视觉上接近，但叠加在其他颜色上时效果会不一样。这个细节在浅色背景上不明显，在深色背景或图片上就会暴露出来。

字号的转换要注意行高。设计稿里字号 16px、行高 24px，转换成 CSS 应该是 font-size: 16px; line-height: 1.5。如果工具只输出了 font-size，没有输出 line-height，文字的行间距就会跟设计稿不一致。这个问题很常见，我每次转换完都会检查一遍行高。

4.4 交互逻辑的补全与接入

Text-to-Prototype 生成的交互通常是页面跳转和简单动效，比如点击按钮跳转到另一个页面、点击卡片展开详情。这些交互在原型阶段够用，但离真实可用的 App 还差得远。D2C 生成的代码则通常只有静态结构和样式，没有任何交互逻辑。所以无论走哪条路，交互逻辑都需要后期补全。

补全交互逻辑有两种方式。一种是在原型工具里配置，大部分 Text-to-Prototype 工具支持设置点击事件、页面跳转、弹窗显示等简单交互。这种方式不需要写代码，适合产品经理和设计师。另一种是在生成的代码里手写，D2C 输出的代码通常是一个纯展示组件，你需要自己接入状态管理、事件处理、接口调用。这种方式适合开发人员。

我的建议是，原型阶段用第一种方式，快速验证交互流程是否顺畅；开发阶段用第二种方式，把原型里的交互逻辑翻译成真实代码。两者之间的衔接，靠的是交互说明文档。在原型里标注清楚每个可点击元素的预期行为，开发照着实现就行。

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

5.1 Text-to-Prototype 生成结果不符合预期怎么办

这是最高频的问题。你输入了一段描述，生成出来的东西跟你想的完全不一样。遇到这种情况，不要急着重写提示词，先做三步排查。

第一步，检查提示词里有没有歧义。比如“放一个按钮”，AI 不知道放哪里、多大、什么颜色。改成“页面底部固定一个宽度 100% 的橙色按钮，文字白色”，生成结果就会准确很多。第二步，检查工具是否支持你描述的元素。有些工具不支持轮播图、地图、图表等复杂组件，你描述得再清楚它也生成不出来。这时候要么换工具，要么用图片占位。第三步，检查是不是一次生成了太多内容。前面说过，一个页面一个页面地生成，成功率远高于一次性生成多个页面。

如果三步都排查了还是不行，那就换一种表达方式。把“顶部放一个轮播图”改成“页面最上方是一个可以左右滑动的图片区域，高度 200px”，把抽象描述改成具体描述。我试过很多次，同样的需求换一种说法，生成质量会有明显差异。

5.2 D2C 转换后代码跑不起来怎么排查

D2C 生成的代码跑不起来，通常不是代码本身有语法错误，而是依赖缺失或环境不匹配。排查顺序我一般是这样的：先看控制台报什么错，如果是“找不到模块”，那就是依赖没装；如果是“样式不生效”，那就是样式方案配置不对；如果是“组件未定义”，那就是组件引入路径错了。

依赖问题最好解决，看报错信息里缺什么就装什么。样式问题稍微麻烦一点，需要检查 D2C 工具用的样式方案跟你项目的是否一致。比如工具生成的是 CSS Modules，你项目用的是 Tailwind，那就需要手动转换。组件引入路径问题通常是大小写不一致或者相对路径算错了，改一下 import 语句就行。

还有一种情况是生成的代码用了浏览器不支持的语法，比如可选链操作符或者空值合并运算符。这在现代浏览器里没问题，但在一些旧环境里会报错。解决办法是用 Babel 转译，或者手动改成兼容写法。

5.3 常见问题速查表

这张表是我自己踩坑踩出来的，基本上覆盖了八成以上的常见问题。遇到新问题的时候，先对照这张表排查，大部分情况都能找到方向。

5.4 几个容易被忽略的细节

第一个细节是图片资源的处理。Text-to-Prototype 生成的页面里，图片通常是占位图或者从图库随机拉的。D2C 转换时，设计稿里的图片会被导出成单独的文件，你需要手动上传到 CDN 或者放到项目的静态资源目录。如果忘了这一步，页面上的图片就是裂的。

第二个细节是响应式适配。原型工具生成的页面通常是固定宽度的，D2C 生成的代码也往往只适配了设计稿的基准宽度。如果你需要适配不同尺寸的屏幕，需要手动添加媒体查询或者使用弹性布局。这个工作量不小，建议在项目初期就规划好。

第三个细节是字体版权。设计稿里用的字体，不一定有 Web 授权。D2C 转换时，工具会把字体名称写进 CSS，但如果用户设备上没有这个字体，就会回退到系统默认字体，视觉效果会打折扣。商用项目要特别注意这一点，提前确认字体授权或者换成免费可商用字体。

6. 工具选型与组合打法

6.1 Text-to-Prototype 工具的选型维度

市面上的 Text-to-Prototype 工具越来越多，选型的时候不要只看生成效果，还要看这几个维度：导出格式、编辑能力、协作功能、价格。导出格式决定了你能不能把生成的结果用到后续流程里，支持导出 HTML 或 Figma 文件的工具，衔接性更好。编辑能力决定了你调整生成结果的效率，支持拖拽编辑和图层管理的工具，比只能重新生成的工具好用得多。协作功能决定了团队能不能一起看、一起改，支持评论和分享链接的工具，沟通成本更低。价格就不用说了，按需选择。

我个人的选型优先级是：编辑能力 > 导出格式 > 协作功能 > 价格。因为生成结果几乎不可能一次到位，编辑能力直接决定了你的后续工作量。导出格式排第二，是因为它决定了这个工具能不能融入你现有的工作流。

6.2 D2C 工具的选型与组合策略

D2C 工具的选型，核心看识别准确率和代码质量。识别准确率高的工具，生成的代码结构清晰、类名语义化，后期维护成本低。代码质量高的工具，生成的代码符合前端规范，不会出现一堆 hack 写法。这两个指标很难从官网介绍里看出来，最好的办法是拿一份真实的设计稿去试用，对比几个工具的生成结果。

组合策略上，我推荐Text-to-Prototype 工具 + 设计工具 + D2C 工具的三件套。先用 Text-to-Prototype 快速出概念图，导入设计工具细化，再用 D2C 转成代码。这样每个环节都用到了最合适的工具，整体效率最高。如果团队规模小，也可以只用 Text-to-Prototype 工具 + D2C 工具，跳过设计工具，但前提是 Text-to-Prototype 工具支持导出可编辑的设计文件。

6.3 什么情况下不该用 AI 生成原型

虽然这篇文章一直在讲 AI 生成原型的好处，但有些情况我是不建议用的。第一，对交互细节要求极高的项目。比如金融类 App 的转账流程，每一步的校验、提示、动画都有严格规范，AI 生成的交互太粗糙，后期改的成本比从头做还高。第二，品牌调性极强的项目。比如奢侈品官网，对视觉的要求非常苛刻，AI 生成的页面很难达到那个水准。第三，涉及复杂业务逻辑的项目。比如后台管理系统，页面之间的数据流转、权限控制、状态管理非常复杂，AI 生成的静态页面意义不大。

这些情况下，老老实实让设计师画图、开发手写代码，反而更快。AI 生成原型的价值在于快速验证和沟通对齐，不在于替代专业设计开发。认清这个边界，才能用好这个工具。

7. 我个人在实际操作中的几点体会

折腾了两个月，最大的体会是：AI 生成原型的上限取决于你的描述能力，下限取决于你的调整耐心。同样一个工具，有人用起来觉得鸡肋，有人用起来觉得真香，差别就在这两点。描述能力可以练，多写几次就知道什么样的提示词出图效果好。调整耐心则需要心态上的转变，不要指望一次生成就完美，把它当成一个帮你完成 60% 工作的助手，剩下的 40% 自己补上。

另一个体会是，D2C 的价值被很多人低估了。大家讨论 AI 生成界面的时候，目光都集中在 Text-to-Prototype 上，觉得一句话生成页面很酷。但实际工作中，D2C 带来的效率提升更实在。设计师定稿之后，开发用 D2C 转代码，能省掉大量还原设计稿的时间，而且还原度比手写更高。这个价值在迭代频繁的项目里尤其明显。

最后分享一个小技巧：把常用的提示词模板和 D2C 配置保存下来。Text-to-Prototype 的提示词，按页面类型整理成模板，下次直接改文案就行。D2C 的配置，按项目技术栈保存成预设，下次一键加载。这些准备工作花不了多少时间，但能让你每次使用的启动成本降到最低。我现在手机备忘录里存了十几套提示词模板，覆盖了列表页、详情页、表单页、个人中心等常见类型，用的时候直接复制粘贴，效率比每次现写高得多。