企业官网建设流程全解析

在实际的网页设计、原型设计和 UI 设计项目里，AI 工具测评最常被问到的问题高度集中在几个点上：哪个模型能识别图片直接生成原型？原型还必须用 Axure 画吗？能不能让 AI 直接输出一套能运行的 HTML/CSS/JS 网页？这三个问题指向同一条工作流：把一张参考图、一句需求描述或一份旧稿，变成一套结构完整、风格统一、可以直接演示的设计产物。下面围绕这条工作流，先讲清楚 AI 介入设计的能力边界，再给出识图生成原型的模型判断方法和工具路径，然后对比 Axure 与 AI 生成的分工，最后用最小案例把一张图片变成网页，并补上验证清单、排错路径和可落地的最佳实践。

1. AI 介入设计流程后，原型和 UI 的工作方式发生了什么变化

1.1 传统原型设计与 AI 生成原型的本质区别

传统原型设计流程，通常可以概括为：产品经理把需求写成文档，设计师根据文档理解页面目标和用户路径，再用 Axure、Figma、Sketch 这类工具拖拽组件，绘制线框和高保真界面，最后把设计稿交付给前端开发。

这个过程里，最消耗时间的并不是“拖拽组件”本身，而是“需求到页面结构”的翻译过程。设计师要在心里完成一系列判断：这个页面放哪些模块，模块之间怎么排序，主操作放在哪里，用什么视觉层级表达优先级。比如一个后台管理页面，首先要判断侧边栏放哪些菜单、顶部栏放什么信息、内容区如何组织卡片，这些判断决定了后续所有设计细节。

AI 介入之后，变化最大的是这层“翻译”被自动化了。只要给模型足够清晰的需求描述，或者一张参考图，它就能直接输出页面结构、组件划分、视觉样式，甚至前端代码。从流程上看，AI 把“语义到视觉”的转换变成一次生成任务，这就是它比传统工具更快的地方。

但这不等于 AI 替代了设计师和产品经理。它替代的是“把已经想清楚的需求画出来”这个执行环节，并没有替代“需求是否合理、页面层级是否符合业务目标、交互链路是否顺畅”这些判断环节。判断力仍然是人的工作。

1.2 AI 能覆盖四个设计环节：需求梳理、低保真、高保真、前端代码

用表格整理 AI 在不同环节的参与方式：

这四层并不是必须全部交给 AI。实际项目里常见的是只取其中一层或两层：比如用 AI 生成低保真原型来快速对齐需求，产品确认后再用 Axure 或 Figma 细化；或者直接让 AI 生成高保真页面代码，省掉中间的手工建模环节。还有的团队只把 AI 用在需求梳理阶段，用对话方式快速列出页面清单，后续仍然走传统设计流程。

1.3 容易误判的 AI 能力边界

有两个容易误判的点。

第一，把 AI 当成“完整产品生成器”，以为给出一个模糊想法就能得到上线级产品。实际上一旦页面数量变多、交互分支变复杂，AI 就难以在一次对话里维持全局一致，需要拆分成多个子任务，并且要维护一份“设计约束文档”来避免风格漂移。一个十个页面的官网，靠一次提示词生成的概率很低，更现实的做法是分成首屏、列表、详情、表单多个子任务逐轮完成。

第二，把 AI 当成“必须一次成功”的工具，一次输出不满意就觉得不可用。正确的做法是把首轮生成当作草稿，通过多轮修改让模型逐步接近目标，这和使用 Axure 反复调稿的节奏是一样的。首轮生成的价值在于快速暴露方向和问题，而不是直接交付终稿。

2. 从图片需求到原型：识图生成原型的模型怎么选

2.1 多模态能力是“识图生原型”的基础

“哪个模型可以识别图片做原型设计”是产品经理和设计师问得最多的问题。要回答它，先要看模型理解图片的能力层级。

识别图片做原型，至少要求模型能看懂四层信息：

1. 布局结构：哪些区域是导航、内容区、侧边栏、页脚。
2. 组件类型：按钮、输入框、卡片、列表、弹窗。
3. 视觉风格：配色体系、圆角、阴影、字体层级、留白密度。
4. 文案层级：标题、正文、标签、按钮文字之间的关系。

这四层都属于多模态大模型的常规能力。当前主流的通用多模态对话模型基本都能做到。真正拉开差距的是细节还原度：能不能准确还原栅格比例，能不能把图片里的颜色提取成可用的 CSS 变量，能不能在转成代码后保持视觉接近。这些能力差异只有通过实际测试才能判断，不能只看宣传材料。

2.2 用四组测试快速判断模型的设计能力

与其看宣传，不如做一组固定测试。准备四张图片，分别测试不同能力：

这套测试不复杂，但能筛掉“只能看图说话、不能做工程化输出”的模型。测试结果要结合自己的设计场景判断，没有统一的最优答案，因为不同模型对不同版式的图片表现差异很大。同一个模型，处理电商首页可能很好，处理数据大屏可能就很差，所以测试图片最好从自己的真实项目里选。

2.3 两类工具路径：通用对话模型与垂直设计工具

从工具类型上看，识图生成原型有两条常见路径。

第一条是通用多模态对话模型配合提示词使用。用户上传参考图，输入需求描述，模型直接输出页面结构和代码。优点是灵活，能处理各种复杂度，适合需求还不确定、需要反复讨论的早期阶段；缺点是需要自己控制输出格式，页面多了以后需要手动拆分任务，生成结果的工程化程度也取决于使用者能不能写出好的提示词。

第二条是垂直设计工具内置的 AI 能力。这类工具往往已经封装好设计规范、组件库和生成流程，用户导入图片或输入需求后，能直接生成可编辑的设计稿。优点是生成结果更接近设计工具的工作方式，修改成本低；缺点是通常依赖特定平台，定制能力和自由度受平台限制。

选择时不需要二选一。常见组合是：先用通用对话模型整理需求、生成页面结构和初版代码，再用垂直设计工具精修视觉、补齐组件。两者不是竞争关系，而是分别承担工作流里不同的环节。

3. 还需要 Axure 吗？AI 生成原型与 Axure 的分工

3.1 AI 可以直接生成原型的场景

“请问原型还需要用 Axure 来设计吗？直接可以用 AI 来生成吗？”这个问题没有统一答案，取决于原型的用途。

如果原型用于以下场景，AI 直接生成是可行的：

• 信息型页面：官网首页、活动页、落地页、博客页。这类页面以内容展示为主，交互简单，AI 生成的结构和视觉基本能直接使用。个人博客网页设计、HTML5 网页设计作业这类任务，AI 完全可以胜任。
• 快速验证想法的草稿：产品团队内部讨论时，用 AI 快速输出不同方案对比，比手动画线框更高效。比如同时生成深色主题和浅色主题两个版本，团队一眼就能看出方向差异。
• 演示和教学：需要给客户、学生或评审看一个功能概念时，AI 生成的可交互 HTML 页面比静态线框更有说服力，观众可以直接点击按钮、滚动页面、体验交互反馈。

3.2 Axure 仍然不可替代的场景

Axure 的价值并不在于“画页面”，而在于“表达复杂交互逻辑和状态”。以下场景里，Axure 仍然是更稳妥的选择：

• 复杂状态流转：多角色权限、条件分支、动态面板、数据集交互。Axure 可以精确表达“什么条件下显示什么内容”，文字描述型的 AI 生成很难一次到位。比如一个审批流程，需要区分普通用户、审批人、管理员三种角色看到的不同页面状态，AI 生成时很容易把状态混在一起。
• 团队交付规范：很多团队依赖 Axure 的标注、注释、PRD 联动和版本管理，这些流程一旦建立，切换到 AI 生成的成本会很高。Axure 里可以直接给元件写交互说明，评审时也有一套成熟的演示方式。
• 安全与数据合规要求：某些企业对项目文件的存储位置、访问权限有严格要求，AI 生成往往需要上传材料和远程处理，这种情况下需要先确认是否允许将业务信息提供给外部服务，再决定是否使用。

3.3 推荐混合工作流

实际项目里更推荐混合工作流，而不是二选一：

1. 用 AI 从需求文本或参考图生成初版原型和页面代码，用来快速对齐页面范围和视觉方向。
2. 产品经理和设计师评审初稿，圈定需要保留或调整的信息架构。
3. 复杂交互用 Axure 补齐，输出可点击的流程演示和状态说明。
4. 前端以 AI 生成的 HTML/CSS/JS 为基础代码，按项目技术栈迁移。

举一个具体例子：一个后台数据管理模块，先用 AI 根据一段需求描述生成列表页、筛选区、详情抽屉的 HTML 结构，产品确认页面范围和字段后，再在 Axure 里补充“无数据状态”“加载失败状态”“权限不足拦截”这些异常分支。前端开发拿到 AI 初稿后，把它迁移到团队的前端框架里，替换真实的接口和组件库。这个流程里，AI 负责生成主体，Axure 负责补充状态，人负责评审和决策。

4. 从设计图到网页：AI 生成 HTML/CSS/JS 的最小流程

4.1 准备材料与提示词模板

要让 AI 把设计图变成网页，准备工作比想象中简单，但有三样材料不能缺：

1. 一张参考图，可以是截图、扫描的手绘稿或竞品页面。
2. 一段需求描述，说明页面用途、目标用户、关键操作。
3. 一组风格约束，包括配色偏好、字体感受、页面宽度和响应式要求。

提示词模板如下：

请把这张图片转换成一套可运行的 HTML/CSS/JS 页面。 页面用途：个人作品集首页，用于展示设计项目和作品案例。 目标用户：招聘方、潜在客户。 关键操作：查看项目列表、点击进入项目详情、通过表单联系本人。 技术栈：原生 HTML + CSS + JavaScript，不引入构建工具和框架。 视觉要求：从图片中提取主色、强调色、圆角风格，保持颜色和间距统一。 响应式要求：桌面端项目卡片三列，平板两列，手机单列。 输出要求：先给出页面信息架构，再输出完整代码，CSS 和 JS 分文件。

提示词的作用相当于需求文档。写得越具体，模型的输出越可控。尤其是“先给出页面信息架构，再输出代码”这句话，能避免模型一上来就堆代码，导致结构不合理。

建议每次生成的提示词都保存到项目文档里。后续修改、复现或交给其他成员评审时，能知道当前版本是基于什么需求生成的，避免出现“改了几轮后不知道当初为什么这么设计”的情况。

4.2 让 AI 识别图片并输出网页代码

具体操作步骤：

1. 打开支持图片理解的多模态对话模型。
2. 上传参考图片，可以把手绘草图或现有界面截图作为输入。
3. 粘贴上面的提示词模板，按实际情况修改页面用途、关键操作和视觉要求。
4. 让模型先输出页面结构，确认无误后再要求生成完整代码。
5. 将代码分别保存为 index.html、style.css、script.js。

以下是一次典型输出的信息架构示例：

页面：个人作品集首页 - 导航区：Logo、项目、文章、关于、联系 - 首屏区：姓名、一句话简介、主 CTA、个人头像 - 项目区：项目卡片列表（图片、标题、标签、年份） - 文章区：最近三篇文章标题列表 - 关于区：个人简介和核心技能 - 页脚区：社交链接、版权信息

把这部分先列出来，目的是检查页面结构是否覆盖需求。如果模型漏掉了“联系表单”或“项目详情入口”，在生成代码之前就要求补充，比代码生成后再返工成本低得多。

4.3 本地运行与验证

代码生成后，需要本地运行验证。推荐两个方式：

第一种，直接双击 index.html 用浏览器打开。适合纯静态页面，大多数情况都能正常显示，但 JavaScript 模块写法的文件协议受限，某些场景下会报跨域或加载错误。

第二种，使用 VS Code 安装 Live Server 插件，在项目文件夹上右键选择 Open with Live Server。这样会启动一个本地静态服务，能避免部分路径和模块加载问题。

运行后需要做的验证不只是“页面能显示”，还要检查交互是否可用。点击导航是否能滚动到对应区块，移动端菜单是否能展开，表单提交时有没有反馈，项目卡片的 hover 效果是否正常。这些都要逐项过一遍，不能只看首屏是否美观。

4.4 关键参数：设计变量与响应式断点

AI 生成的前端代码里，最值得关注的是一组设计变量。把它们集中放在 CSS 根变量中，是保持页面风格一致的重要手段。

:root { --color-primary: #1a73e8; --color-accent: #ff7043; --color-bg: #f8f9fa; --color-surface: #ffffff; --color-text: #212529; --color-text-secondary: #6c757d; --radius-sm: 4px; --radius-md: 8px; --radius-lg: 16px; --space-unit: 8px; --font-size-base: 16px; --font-size-title: 28px; --breakpoint-md: 768px; --breakpoint-lg: 1024px; }

这些变量的含义如下：

调整参数时要注意：不要只看单个变量的效果。比如只把主色改了，但辅助色、背景色、文字色没有同步调整，页面看起来仍然是分裂的。建议把颜色、间距、圆角当成一组整体变量统一修改。

5. 个人博客与作品集网页：一个完整的 AI 辅助设计实战

5.1 需求拆解与信息架构

个人博客网页设计是相对容易用 AI 跑通的场景，原因是页面数量少、交互不复杂、视觉表达空间大。即使如此，动手前也建议先拆一下需求。

一个常见的个人博客信息架构可以拆成：

全局：导航、页脚 页面一：首页，包含首屏、最新项目、最新文章 页面二：项目列表页，包含筛选和项目卡片 页面三：项目详情页，包含背景、图片、技术栈、链接 页面四：文章列表页，包含文章标题、摘要、日期 页面五：关于页，包含个人介绍、技能、联系方式

拆完之后不需要把这些都交给 AI 一次生成。更好的做法是先从首页开始，跑通结构、风格、代码质量，再复制到其他页面，逐步调整。首页的信息架构是所有页面的锚点，它定了，其他页面的导航和视觉风格也就跟着定了。

5.2 第一轮：用提示词生成首屏结构

第一轮的目标只有一个：把首页首屏的结构和视觉方向确定下来。提示词可以这样组织：

请设计一个个人作品集首页的首屏区域，包括导航、开场文案、主按钮和个人头像。 风格要求：简洁、有设计感，参考北欧风格网站的留白和字体排版。 配色：以深色背景为主，配一个高亮强调色。 输出：HTML 结构和对应 CSS，不要写交互逻辑。

如果拿不准风格描述，也可以直接给模型一个具体的视觉参考关键词，例如“科幻题材的暗色工业感网页设计，深色背景、冷色调、细线框”，模型会按这个方向组织配色和排版。风格关键词描述得越准确，输出越接近预期。

为什么要分轮而不是一次要全部？因为首屏是关键视觉锚点，先确定它，后面的项目区、文章区、页脚都围绕它延展。首屏风格定不下来，生成再多内容也要返工。

5.3 第二轮：补充组件、交互与响应式

首屏通过评审后，再让 AI 补充下面的区块和交互。常见的个人博客交互包括：移动端菜单开关、回到顶部按钮、滚动时导航栏背景变化、项目卡片的淡入动画。

示例 JavaScript 片段：

// 移动端菜单开关 const menuToggle = document.querySelector('.menu-toggle'); const navMenu = document.querySelector('.nav-menu'); menuToggle.addEventListener('click', () => { navMenu.classList.toggle('is-open'); }); // 回到顶部按钮 const backToTop = document.querySelector('.back-to-top'); window.addEventListener('scroll', () => { backToTop.style.display = window.scrollY > 400 ? 'block' : 'none'; }); backToTop.addEventListener('click', () => { window.scrollTo({ top: 0, behavior: 'smooth' }); });

这段代码用在个人博客页面里很常见。生成之后要手动检查事件绑定对应的元素是否存在、类名是否一致，避免出现“监听器绑了，但页面里没有这个按钮”的情况。ChatGPT 这类模型生成的代码经常出现组件类名和 JS 选择器不一致的问题，这是需要人工审查的地方。

5.4 第三轮：设计 token 沉淀与风格统一

页面区块多了之后，最容易出现的问题是风格漂移：前半段是圆角大、阴影重、颜色鲜艳的卡片，后半段变成直角、无阴影、低饱和的列表。解决方式是把设计约束收敛成一组 token，在每一轮生成时附上。

实际做法是建立一份 design-tokens.json，记录颜色、间距、圆角、字体层级等约束：

{ "colors": { "primary": "#1a73e8", "accent": "#ff7043", "background": "#f8f9fa", "surface": "#ffffff", "text": "#212529", "textSecondary": "#6c757d" }, "spacing": { "xs": "4px", "sm": "8px", "md": "16px", "lg": "24px", "xl": "48px" }, "radius": { "sm": "4px", "md": "8px", "lg": "16px" }, "typography": { "h1": "32px/1.3", "h2": "24px/1.4", "body": "16px/1.6", "caption": "14px/1.5" } }

每轮让 AI 生成新区块时，都把这份 JSON 粘贴到提示词里，要求代码中的颜色、间距、圆角必须从 token 取值。这样即使模型多次生成，视觉的一致性也能基本保持。

6. 效果验证：判断 AI 生成的设计稿是否合格

6.1 功能维度验证清单

AI 生成的设计稿不能只看好不好看，先验证功能是否完整。以个人博客首页为例，建议逐项检查：

• 导航里是否有项目、文章、关于、联系四个入口，且都能到达对应区域或页面。
• 是否包含“查看项目详情”的入口，点击后是否有跳转或详情区域。
• 联系表单是否有姓名、邮箱、留言字段，提交后是否有反馈。
• 页面是否有明显的死链接或空按钮。

功能验证要在浏览器里实际操作，不要只在代码里看。很多生成结果会出现“视觉上有按钮，但按钮没有绑定任何事件”的问题，这种问题只有点击过后才会暴露。

6.2 视觉维度检查项

视觉检查重点关注一致性，而不是“好不好看”这种主观判断：

• 主色是否只使用一个色值，而不是相近色反复出现。
• 标题、正文、次要文字的字号层级是否清楚，是否出现五六个不同字号的情况。
• 区块间距是否统一，是否出现某个区块上下留白明显异常。
• 图片是否用了占位图，实际项目是否替换成真实素材。
• 在 1366 和 1920 两个常见桌面宽度下，首屏是否出现大面积空白或拥挤。

每个检查项出现问题，都要回到提示词或设计 token 里找原因，而不是在生成结果上临时修补。比如某个按钮颜色异常，优先检查它是不是没有使用 --color-primary 变量，而是直接写死了另一个色值。

6.3 代码维度审查点

如果 AI 的输出包含 HTML/CSS/JS 代码，建议做一轮基础审查：

• 是否使用语义化标签，比如 nav、main、section、footer，而不是一堆 div。
• CSS 是否集中在样式表里，是否存在大量行内 style。
• 是否有多余的重复样式，比如同一个按钮样式写了两遍。
• JavaScript 是否有语法错误，控制台是否有报错。
• 图片路径是否正确，字体是否依赖了无法离线的外部资源。

注意：不要只验证页面能打开，还要验证输入、输出、异常分支和交互反馈是否符合预期。这个原则对 AI 生成的前端代码同样适用，而且更重要，因为生成代码的质量不稳定。

这轮审查不需要多深，目的是把问题控制在交付之前。如果打算把 AI 生成的代码作为项目基础，还应该补上注释、目录结构、变量命名规范这些工程化内容。

7. 常见问题与排查路径

7.1 AI 生成的页面布局错乱

现象：页面元素重叠、超出宽度、区块顺序错乱。

可能原因：

• 提示词里没有说明页面宽度和响应式要求，模型默认使用绝对宽度。
• 图片参考图的版式比例没有交代，模型按原比例输出。
• 使用了弹性布局但没有设置换行和宽度约束。

检查方式：打开浏览器开发者工具，查看元素的盒模型和宽度；检查组件的 flex 或 grid 属性，确认是否有 min-width 或 flex-wrap 缺失。

处理建议：在提示词中明确“页面宽度 1200px 居中，桌面三列、平板两列、手机单列”；要求模型输出时统一使用设计变量中的断点值；生成后手动检查容器宽度，补上 overflow 控制和响应式媒体查询。

7.2 识别图片后生成的原型缺少关键页面

现象：AI 识别了一张完整的后台界面截图，但生成的代码只有局部区块，缺少侧边栏、顶栏或弹窗。

可能原因：

• 图片分辨率不足，模型没有读全。
• 提示词没有说“完整还原整张图的全部模块”。
• 模型为了简化输出，自动丢弃了它认为不重要的区域。

检查方式：先让模型用文字描述“这张图里有哪些区域”，比对图片确认是否漏项；检查生成的页面结构里是否包含原图所有可见模块。

处理建议：上传前把图片裁剪到主体区域，避免背景干扰；提示词中明确“不要省略任何可见模块，包括弹窗和提示信息”；生成后再人工核对一遍，发现漏项就要求模型补充，不要直接接受简化结果。

7.3 设计风格不统一，像拼接的组件

现象：同一个页面里按钮有几种不同的圆角、颜色和阴影，字体大小层级混乱。

可能原因：

• 多轮生成没有共享设计变量。
• 每轮提示词里的风格描述不一致。
• 首轮生成的 token 没有固定下来，后续生成各自取值。

检查方式：搜索代码里出现的所有颜色值、圆角值、字号值，看是否超过预期数量；对比各轮生成结果的 CSS 根变量是否一致。

处理建议：建立 design-tokens.json，每轮生成都粘贴到提示词里；风格描述写成固定短语，例如“简洁、多留白、圆角 8px、主色 #1a73e8”；生成完成后做一次统一替换，把不一致的取值收敛到 token。

7.4 生成代码在移动端显示异常

现象：桌面端正常，手机端出现横向滚动条、文字过大、按钮太小。

可能原因：

• 没有设置 viewport 标签。
• 使用固定像素宽度，没有媒体查询。
• 字体和按钮尺寸没有适配触屏。

检查方式：打开 index.html，检查 head 中是否有 viewport meta；用浏览器开发者工具的移动端模拟，分别在 375、768、1024 宽度下检查。

处理建议：提示词里固定要求“包含 viewport 标签、使用相对单位、包含移动端菜单”；生成后手动检查关键断点下的布局；按钮最小高度建议不小于 44px，适配手指点击。

用表格汇总排错清单：

8. 适合设计师和产品经理的 AI 设计最佳实践

8.1 把提示词当作需求文档来写

AI 设计任务能不能做好，很大程度取决于提示词的质量。不要只写“帮我设计一个页面”，要写清楚页面用途、目标用户、关键操作、视觉约束、输出格式。

一个稳定的提示词结构是：

1. 角色与目标：希望模型扮演什么角色，完成什么产物。
2. 输入材料：参考图、旧稿、文案素材。
3. 需求细节：页面清单、功能点、主流程。
4. 风格约束：配色、圆角、间距、字体、参考风格。
5. 技术约束：技术栈、是否响应式、代码组织方式。
6. 输出格式：先结构后代码，分文件还是单文件。

每次生成的提示词建议保存下来，作为项目设计过程文档的一部分。这不仅是给 AI 看的，也是给团队看的需求说明。

8.2 先定设计变量，再让 AI 出稿

不要边生成边改颜色。第一步先把主色、辅色、背景色、文字色、圆角、间距、字体层级定下来，然后让 AI 在生成任何区块时都从这套变量取值。

这样可以避免最常见的多轮生成问题：风格漂移。设计变量相当于给模型一个“视觉宪法”，每一轮的输出都受它约束。没有这套约束，AI 每轮生成都是一次新的自由发挥，页面自然像拼接出来的。

8.3 区分学习环境与生产环境

学习环境里，AI 生成页面可以怎么快怎么来：用官方示例、直接改提示词、反复生成对比效果。目的是理解 AI 的能力边界和提示词对结果的影响。这个阶段不用太在意工程规范，重点是跑通“需求到页面”的链路。

到了生产环境，限制条件会增加：

• 代码必须进入团队的项目仓库，符合已有的目录结构和命名规范。
• 生成内容需要经过代码审查，不能直接把 AI 输出合并到主干。
• 视觉稿需要经过设计评审，确认品牌和可访问性符合要求。
• 涉及用户数据或公司业务信息的材料，要先确认是否允许上传到外部 AI 服务。

生产环境不要把 AI 当作免检通道，它只是比人工手写更快的起点。生成结果仍然要走正常的评审、测试、发布流程。

8.4 可复用的 AI 设计任务清单

每次接到一个设计任务，可以按下面的清单走：

• [ ] 用文字拆解需求，列出页面清单和关键操作。
• [ ] 选择合适的路径：通用对话模型还是垂直设计工具。
• [ ] 收集参考图、品牌素材和风格参考，整理成输入材料。
• [ ] 按“角色、输入、需求、风格、技术、输出”写提示词。
• [ ] 首轮只生成结构，不追求完整代码。
• [ ] 检查信息架构是否覆盖需求，缺了什么先补结构。
• [ ] 用设计 token 约束后续所有轮次生成。
• [ ] 在桌面和移动断点下验证页面表现。
• [ ] 审查语义化标签、样式集中度、脚本报错。
• [ ] 交付前替换占位图，补真实文案。
• [ ] 存档提示词、设计 token 和生成版本，方便回溯。

这份清单同样适用于团队协作：把清单作为交付验收的一部分，能有效降低 AI 生成质量不稳定带来的返工。

AI 工具测评做得再多，最终还是要落到一条能稳定复用的工作流上。对设计师和产品经理来说，AI 真正改变的不是“要不要画原型”这个问题，而是把更多人从重复的绘制工作中解放出来，把时间留给需求判断和体验决策。下一步最值得做的两件事，一件是整理一套属于自己的提示词模板和设计 token，另一件是补上 HTML/CSS 和基础 JavaScript 知识，因为只有当你能读懂、审查、修改 AI 生成的代码时，它才是可用的设计外挂，而不是一个黑盒。