企业官网建设流程全解析

一句话丢给 AI，它真能吐出一套能点、能跳转、能填表单的界面原型吗？这个问题在过去一年里被反复讨论，我自己也拿它当日常工具用了大半年，从最初的新鲜感，到中间被各种"看起来很美"的截图骗过，再到慢慢摸清楚它的能力边界。Text-to-Prototype（文本生成原型）和 D2C（Design to Code，设计转代码）这两条路线，本质上解决的是同一个痛点的两端：一端是"我脑子里有个想法，怎么最快变成能看的东西"，另一端是"我手里有张设计稿，怎么最快变成能跑的代码"。前者面向产品经理、创业者、独立开发者，后者面向前端和设计团队。这篇文章不吹不黑，把我踩过的坑、验证过的流程、以及那些文档里不会写的细节，一次性讲清楚。

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

很多人第一次用这类工具，输入"做一个外卖 App 的首页"，然后期待一个完整的、能下单的 App。结果拿到的是一个静态页面，点按钮没反应，于是得出结论"这玩意儿不行"。问题出在预期错位——你得先明白它生成的到底是什么层级的东西。

1.1 从"文本"到"界面"中间隔了几层翻译

Text-to-Prototype 的完整链路，粗略拆开是这样的：自然语言 → 意图解析 → 页面结构树 → 组件映射 → 样式生成 → 可交互逻辑。每一层都可能丢信息。

自然语言本身是模糊的。"做一个简洁的登录页"这句话里，"简洁"是主观的，AI 只能根据训练数据里的常见模式去猜。它猜出来的可能是居中卡片式，也可能是全屏渐变式，取决于模型见过的样本分布。这就是为什么同一个提示词，不同工具、甚至同一工具不同时间跑出来的结果差异很大。

页面结构树这一步，AI 要把"登录页"翻译成"一个容器，里面有一个标题、两个输入框、一个按钮、一个辅助链接"。这个翻译过程决定了布局的骨架。我实测下来，结构树的合理性比样式好看与否重要得多——样式可以改，结构歪了就得推倒重来。

组件映射是最容易出问题的一环。AI 知道"这里要一个输入框"，但它不一定知道这个输入框在你的设计系统里对应哪个组件。如果它直接生成原生 HTML 的<input>，而你的项目用的是自研组件库，那后面接入的时候就得全部替换。这是 Text-to-Prototype 落地到真实项目时最大的摩擦点。

1.2 静态原型、可交互原型、可运行代码是三回事

这三个概念经常被混为一谈，但它们的成本和用途完全不同。

大部分 Text-to-Prototype 工具默认产出的是第二类——可交互原型。它能做到点击按钮跳转到下一个页面，能弹出模态框，能在几个预设状态之间切换。但它不会帮你写后端接口，不会处理登录态，不会做数据持久化。

我见过不少团队拿着可交互原型直接当成品交付，结果在真实数据接入时发现整个状态管理是散的，改起来比重新写还累。所以从第一天起就要清楚：原型是用来"验证想法"的，不是用来"省掉开发"的。

1.3 为什么"一句话生成"的宣传容易让人误判

宣传语里的"一句话"，通常指的是"一句话描述 + 大量隐含上下文"。工具背后默认了一堆东西：移动端优先、Material Design 或 iOS 风格、常见的导航模式、标准的间距体系。当你说的那句话恰好落在它的舒适区里，效果惊艳；一旦偏离，质量断崖式下跌。

举个例子，输入"做一个电商首页"，出来的大概率是顶部搜索栏 + 轮播图 + 分类图标网格 + 商品瀑布流。这个组合是训练数据里的高频模式，AI 闭着眼都能拼出来。但如果你输入"做一个面向视障用户的电商首页"，它可能还是给你那套标准布局，因为"无障碍"这个约束在它的生成逻辑里权重很低。

所以正确的用法不是"一句话丢进去等结果"，而是"一句话定方向，再用多轮对话补约束"。这一点后面会详细讲。

2. 提示词写得好不好，决定了原型的下限

我一开始也觉得提示词这东西玄乎，直到我把同一个需求用三种写法跑了一遍，出来的结果差距大到像换了三个工具。提示词不是玄学，它是在给 AI 划定搜索空间。

2.1 把"感觉"翻译成"约束"的具体方法

"做一个好看的页面"是无效提示。"做一个以卡片为主、圆角 12px、主色为深蓝、信息密度中等、首屏展示 4 个卡片的移动端页面"才是有效提示。

区别在于，前者是形容词，后者是参数。AI 对形容词的理解依赖训练数据的统计偏好，对参数的理解则直接映射到生成规则。你给的参数越具体，它自由发挥的空间越小，结果越可控。

我总结了一个把模糊需求转成具体约束的模板，实测很好用：

• 平台：移动端 / 桌面端 / 平板，具体到宽度区间
• 布局：单列 / 双列 / 网格，主内容区占比
• 组件：需要哪些具体组件，按优先级排列
• 风格：圆角大小、阴影层级、主色和辅助色
• 状态：需要展示哪些状态（空、加载、错误、正常）
• 交互：哪些元素可点击，点击后发生什么

把这六项填满，再丢给工具，出来的东西基本能直接用。空着任何一项，AI 就会用它的默认值填，而默认值往往不是你想要的。

2.2 多轮对话比一次性长提示更有效

一次性写 500 字的提示词，不如分 5 轮、每轮 100 字。原因是 AI 在单次生成时对提示词的处理是有损的，太长的提示词后半段权重会被稀释。而多轮对话里，每一轮的输出都成了下一轮的上下文，信息是累积的。

我的实际操作流程是这样的：

1. 第一轮：只给平台和核心功能，让它出一个粗框架
2. 第二轮：针对框架里不满意的部分，指出具体问题让它改
3. 第三轮：补充视觉约束，调整配色和间距
4. 第四轮：补充交互，指定哪些元素可点击、跳转到哪
5. 第五轮：补充边界状态，空数据、加载中、报错

每一轮只改一个维度，这样出问题时你能定位到是哪一轮引入的。如果一次性全改，最后效果不对，你根本不知道是哪个约束没生效。

提示：多轮对话时，不要用"再好看一点""再专业一点"这种反馈。要说"把卡片间距从 8px 改成 16px""把主按钮从描边改成填充"。具体的修改指令，AI 的执行准确率远高于模糊评价。

2.3 那些让生成质量翻倍的隐藏约束

有几个约束，工具文档里很少提，但加上之后效果提升明显。

信息密度约束。明确告诉 AI"首屏不超过 5 个信息块"，它会主动做减法。不加这个约束，它倾向于把所有能想到的元素都塞进去，导致页面拥挤。

层级约束。指定"主标题 24px、副标题 16px、正文 14px、辅助文字 12px"，字号层级一旦固定，整个页面的视觉秩序就出来了。AI 默认的字号层级经常是乱的。

对齐约束。明确"所有内容左对齐，边距 16px"，比让它自由发挥要整齐得多。AI 在自由布局时容易产生 1-2px 的随机偏移，肉眼看着别扭但说不上哪里不对。

组件复用约束。告诉它"所有卡片使用同一套样式"，它会尽量复用。不指定的话，它可能给每个卡片生成略微不同的样式，后期统一起来很痛苦。

这些约束本质上是在替 AI 做设计决策。你做得越多，它越像个执行者；你做得越少，它越像个碰运气的实习生。

3. D2C 这条路，比 Text-to-Prototype 更接近生产

如果说 Text-to-Prototype 是"从零到一"，那 D2C 就是"从一到一百"。它的输入不是文字，而是设计稿，输出是代码。这条路走通了，对研发效率的提升是实打实的。

3.1 设计稿到代码的转换，卡在哪几个环节

D2C 的链路是：设计文件 → 图层解析 → 组件识别 → 布局还原 → 代码生成 → 工程接入。听起来顺理成章，但每一环都有坑。

图层解析阶段，设计稿里的图层命名直接决定识别质量。一个叫"矩形 123"的图层和一个叫"btn-primary"的图层，AI 对它们的处理完全不同。前者只能靠视觉特征猜，后者直接就能映射到按钮组件。所以设计团队如果想让 D2C 跑得顺，图层命名规范是前提。

组件识别阶段，最大的问题是"视觉相同但语义不同"。两个看起来一模一样的卡片，一个是商品卡，一个是文章卡，AI 从视觉上分不出来。这时候就需要设计稿里带标注，或者人工在生成后修正。

布局还原阶段，绝对定位和弹性布局的取舍是个老大难。设计稿里所有元素都是绝对坐标，但代码里我们希望用 Flex 或 Grid。AI 要做的转换是"把视觉上的相对关系翻译成布局规则"。这一步做得好不好，直接决定生成的代码能不能维护。

代码生成阶段，输出的是原生 CSS 还是 Tailwind，是 React 还是 Vue，是内联样式还是样式文件，这些都要提前配置。默认输出往往是最通用的那种，接入项目时还得二次加工。

3.2 生成的代码能直接进项目吗

直接说结论：能进，但不能直接用。

我拿一个中等复杂度的页面做过测试，D2C 生成的代码大概能覆盖 70% 的结构和 60% 的样式。剩下的 30% 结构问题主要是组件拆分不合理——它可能把整个页面生成一个巨大的组件，而不是拆成可复用的子组件。剩下的 40% 样式问题主要是响应式和状态样式缺失。

所以正确的接入姿势是：

1. 用 D2C 生成初版代码，作为起点
2. 人工拆分组件，把重复结构抽出来
3. 替换成项目里的组件库组件
4. 补充响应式断点和状态样式
5. 接入真实数据和事件处理

这个过程比从零写快多少？我的体感是，一个中等页面从 4 小时缩短到 1.5 小时左右。省下来的时间主要在"搭结构"和"调基础样式"上，而"业务逻辑"和"边界处理"还是得自己来。

3.3 什么类型的页面适合走 D2C

不是所有页面都适合。我按适配度排了个序：

规律很明显：视觉权重越高、逻辑权重越低的页面，D2C 越划算。反过来，交互复杂的页面，生成的代码反而是负担，因为你要花时间理解它生成的逻辑再改。

4. 实测中那些让人抓狂的细节问题

前面讲的是方法论，这一节讲实操中真实遇到的坑。这些问题在官方文档里基本找不到，但每一个都能让你卡半天。

4.1 生成结果的"像素级漂移"

AI 生成的界面，经常出现"看着差不多但就是不对"的情况。具体表现是：间距忽大忽小、对齐差几个像素、字号层级混乱。

我排查了很久，发现根源在于 AI 生成样式时用的是"近似值"而不是"精确值"。它可能觉得 15px 和 16px 差不多，就随机选一个。单看一个元素没问题，整页看下来就乱了。

解决办法是生成后统一做一次"样式归一化"：把所有间距收敛到 4 的倍数，字号收敛到固定层级，圆角统一。这一步手动做很烦，但可以用脚本批量处理。我写过一个简单的处理逻辑，把生成代码里的间距值全部 round 到最近的 4 的倍数，效果立竿见影。

4.2 交互逻辑的"假实现"

Text-to-Prototype 生成的交互，很多是"假"的。点击按钮跳转，跳转是实现了，但跳转的目标页面是个空壳。表单能填，但提交按钮点了没反应。弹窗能弹，但关闭逻辑时灵时不灵。

这不是 bug，是设计如此。原型工具的重点在"展示流程"，不在"实现逻辑"。但如果你没意识到这一点，拿去给客户演示，客户一点提交发现没反应，场面就很尴尬。

我的做法是，在演示前把所有"假交互"标注出来，要么补上简单的反馈（比如点击后弹个 toast 说"演示环境"），要么在演示时主动说明。别让假交互变成信任危机。

4.3 多轮修改后的"上下文污染"

多轮对话改到后面，AI 会"忘记"前面的约束。比如第一轮你说了主色是蓝色，改到第五轮它可能给你生成个绿色的按钮。这是因为对话历史太长，早期约束的权重被稀释了。

应对方法是：每隔几轮，把核心约束重新声明一遍。或者更彻底一点，把当前确认好的版本"冻结"，后续修改基于冻结版本做，而不是在长对话里继续改。

我现在的习惯是，每确认一个稳定版本就导出一次，后续大改直接基于导出文件重新开始，而不是在对话里无限迭代。这样虽然麻烦一点，但可控性强得多。

5. 把 AI 生成的原型接进真实工作流

工具本身不是目的，能不能嵌进团队的工作流才是关键。我试过几种接入方式，说说哪种最顺。

5.1 产品评审阶段怎么用

产品评审最怕的是"对着文字描述想象界面"，十个人能想象出十个版本。用 Text-to-Prototype 快速生成几个方案，评审时对着具体界面对齐，效率提升明显。

我的流程是：需求文档出来后，先用 AI 生成 2-3 个不同方向的方案（比如一个信息密集版、一个简洁版），评审时让各方选方向。选定方向后再细化，而不是一开始就纠结细节。

这样做的好处是，把"方向性讨论"和"细节讨论"分开了。方向没定就抠细节，是最浪费时间的。

5.2 设计到开发的交接怎么减少扯皮

设计和开发扯皮，很多时候是因为设计稿里的"理想状态"和开发实现的"现实状态"有差距。D2C 在这里能起到一个"翻译"的作用。

让开发用 D2C 生成一版代码，再和设计稿对比，差异点一目了然。是间距问题、字体问题还是布局问题，对着代码说比对着设计稿说清楚得多。设计也能看到"我的设计转成代码大概长这样"，对可实现性有更直观的认知。

我参与过的一个项目，交接阶段用 D2C 生成初版代码作为"共同语言"，扯皮时间大概减少了一半。不是说工具多神，而是它提供了一个具体的、可讨论的对象。

5.3 独立开发者的效率杠杆

对独立开发者来说，这套东西的价值更大。一个人要兼顾产品、设计、开发，每个环节都想省时间。Text-to-Prototype 帮你快速验证想法，D2C 帮你快速搭出界面，你只需要专注在业务逻辑上。

我自己的做法是：想法阶段用 Text-to-Prototype 出可交互原型，自己点一遍确认流程通不通；确认后导出设计，用 D2C 生成代码骨架；然后在骨架上填业务逻辑。整个从想法到可运行 Demo 的周期，从原来的两三天压缩到半天左右。

但要注意，这个流程适合"验证型"项目，不适合"长期维护型"项目。快速搭出来的代码，如果后续要长期迭代，该重构还是得重构。别把"快"当成"省"。

6. 关于能力边界，说几句实在话

用了这么久，我对这类工具的态度从"惊艳"变成了"务实"。它确实能省时间，但省的是特定环节的时间，不是全部。

它擅长的是：把模糊想法快速具象化、把重复性布局快速搭出来、把设计稿快速转成代码骨架。它不擅长的是：理解复杂业务逻辑、处理边界状态、生成可长期维护的代码结构。

所以正确的定位是"加速器"而不是"替代品"。它加速的是从 0 到 0.6 的过程，剩下的 0.4 还是得人来。想清楚这一点，用起来就不会有落差。

还有一个容易被忽略的点：AI 生成的东西，你得有能力判断好坏。如果你自己不懂布局、不懂组件设计、不懂代码结构，AI 给你一版烂代码你也看不出来。工具越强，对使用者的判断力要求反而越高。这是我在实际使用中最深的体会——它放大的是你的能力，而不是替代你的能力。