实战指南｜从 UI 到可交付前端原型

网页和界面视觉需求，最容易卡在两个地方。

第一个地方：是“看得出问题，但说不清怎么改”。比如一个后台页面信息太散、按钮太多、表格太挤、首屏没有重点，大家都觉得不好用，但讨论时往往停留在“再高级一点”“更清爽一点”“像某某产品一点”。

第二个地方：是“设计想法不能顺利交给前端”。产品写了 PRD，设计做了几版稿，前端接手时仍然要重新确认字段、状态、交互、响应式、组件复用和异常边界。界面视觉如果只停留在静态图，就很难真正进入交付链路。

TRAE Work 的 Design 模式可以用来组织这类工作：先讨论现有页面的问题，再梳理页面结构和线框，最后按需要补充前端原型说明或设计规范。把任务拆开，通常比一句“帮我美化页面”更容易得到可讨论的结果。

本篇教程重点讲两个高频场景：

适合产品经理、设计师、前端工程师、个人开发者和团队负责人。

适用于 UI 重构、视觉优化、线框原型、可点击 HTML Demo 和设计系统沉淀等场景。

重点不是让 AI 替代设计或开发，而是把界面需求拆成可诊断、可讨论、可交付的工作流程，让产品、设计和前端更早对齐。

最后会给出一组可直接复制到 TRAE Work Design 使用的 Prompt 模板。

一、先判断：你的界面需求属于哪一类

图 1：TRAE Work 的 Design 首页。开始前先准备好 PRD、截图、URL、字段表或现有代码中的至少一种材料。

在进入 TRAE Work Design 之前，不建议一上来就说“帮我设计一个页面”。

更好的方式，是先判断自己手里的材料和目标。

已经有截图、URL、旧页面或 HTML 片段，优先走「UI 重构」路线。重点不是重新发明一个页面，而是诊断现有问题，保留业务字段和核心流程，优化信息层级、布局密度、视觉统一性和可用性。

如果只有 PRD、用户故事、业务流程或字段表，优先走「UI 草图/线框」路线。重点是把需求转成页面清单、跳转关系、关键状态、字段规则和交互分支，让产品、设计、前端能够在同一个界面模型上讨论。

要做演示、前端验证或客户汇报，可以走「可点击 HTML 原型」路线。重点是明确要求可运行的页面和需要覆盖的状态，例如 hover、active、disabled、空态、加载和错误态；生成后仍要亲自打开验证。

团队已经有组件库、Figma 规范或品牌视觉的情况下，可以进一步走「设计系统与资产沉淀」路线。重点是把颜色、字号、间距、圆角、阴影、表格、筛选器、弹窗、按钮等规范变成可复用资产，减少每次生成页面时的风格漂移。

一个简单的判断表如下：

二、UI 重构：从“页面不好看”变成“问题可诊断、方案可验收”

图 2：示例重构任务中，左侧记录了输入的重构要求，右侧列出诊断、方案和文档等待办步骤。该截图不代表每个任务都会自动生成文件或预览。

UI 重构最常见的输入是旧页面截图、线上 URL、后台页面、平台首页、大屏、官网首屏或工具型单页。

很多人做 UI 重构时，会直接要求 AI “美化一下”。这类输入太泛，容易得到表面化结果：换个渐变、加几张卡片、调大标题、加阴影，但页面真正的问题没有被解决。更有效的做法，是把任务拆成四步。

第一步，先要求做诊断，而不是马上重画。诊断至少应覆盖信息架构、视觉层级、操作路径、组件一致性、阅读密度、状态完整性和响应式风险。

第二步，要求它给出多套重构方案。通常建议至少三套：保守优化、结构重排、视觉焕新。保守优化适合快速上线；结构重排适合信息层级明显混乱的页面；视觉焕新适合官网、品牌页、大屏、产品展示页等更依赖视觉表达的场景。

第三步，要求每套方案都说明关键组件和交互，而不是只描述风格。比如表格筛选如何折叠，批量操作在哪里出现，详情是新页面还是抽屉，错误态如何反馈，空态是否提供引导操作。

第四步，要求输出验收清单。UI 重构不能只靠“感觉更好看”。它应该能被检查：首屏是否有主任务，按钮层级是否清晰，字段是否保留，页面状态是否完整，响应式是否覆盖，组件是否复用。

可以按下面的顺序组织一次重构任务：

1. 提供现有页面截图、可访问的 URL、HTML 片段或项目目录中的一种材料。
2. 补充产品类型，例如后台管理、平台、大屏、官网、移动端。
3. 说明主要用户和关键任务，例如运营查数据、管理员审批、客服处理工单、管理者看经营指标。
4. 让 Design 先输出诊断，再输出三套方案。
5. 选择其中一套，继续细化布局、色彩、组件和状态；若当前界面提供画布入口，可在画布中继续调整。
6. 如果要交给前端，补充组件清单、交互说明、token 建议和验收清单，并由前端评估实现成本。

UI 重构示例 Prompt

是一名资深 UI/UX 设计师 + 前端架构顾问。
请基于我提供的【现有页面】做 UI 重构与视觉优化。

【输入】
- 页面来源：{URL / 截图 / HTML 片段}
- 产品类型：{后台管理 / 平台 / APP / 官网 / 大屏}
- 主要用户：{用户角色}
- 关键任务：{用户进入这个页面最想完成什么}
- 当前问题：{信息拥挤 / 层级混乱 / 风格陈旧 / 操作路径长 / 数据难读}

【目标】
1. 合并同类项：请识别可以收敛的模块、入口、按钮或重复信息。
2. 提升可用性：减少操作路径，优化信息层级，提升可读性。
3. 统一风格：基于 {参考风格 / 品牌规范 / 色板 / 字体 / 图标库} 输出视觉建议。

【输出要求】
请输出 3 套方案：
- 方案 A：保守优化，尽量复用现有布局与组件，适合快速上线。
- 方案 B：结构重排，重新组织信息架构与关键流程。
- 方案 C：视觉焕新，强化品牌感、视觉识别和高级感。

每套方案都必须包含：
1. 信息架构调整。
2. 页面布局说明。
3. 关键组件与交互。
4. 主题 token 建议：颜色、字号、间距、圆角、阴影。
5. 前端实现注意事项。
6. 验收清单。

【约束】
- 尺寸：{PC 1440 / 移动 375x812 / 大屏 1920x1080}
- 不改变业务字段含义。
- 优先复用现有组件。
- 新增交互必须说明触发条件、反馈方式和回退路径。

UI 重构验收清单

完成一版重构方案后，可以用下面这份清单检查：

三、UI 草图/线框：从 PRD 直接生成可讨论的页面骨架

图 3：告警管理线框的本地预览，展示三种结构方向及推荐方案。这是一次示例输出，不是固定模板。

UI 草图适合需求还没有进入高保真的阶段。这个阶段不要急着追求视觉效果，最重要的是把页面结构、流程分支和字段规则讲清楚。

产品经理、业务负责人或前端同学经常会给出一段长需求，例如：

“我们要做一个告警管理页面，支持查看告警列表、按设备/等级/状态筛选、批量处理、查看详情、转派负责人、记录处理日志，还要支持空态、无权限、加载失败。”

这段话里包含页面、字段、状态、权限和流程，但还没有形成界面结构。可以先要求工具把它整理成页面清单、线框结构和待确认项，再由团队补齐缺失信息。

建议 UI 草图阶段固定输出四类内容。

第一类是页面清单。包括有哪些页面、从哪里进入、页面之间如何跳转。比如首页、列表页、详情页、配置页、审批页、弹窗、抽屉、空态页。

第二类是每页线框。包括布局结构、信息层级、组件清单。这里不需要先追求精细视觉，但要说明顶部、侧边栏、筛选区、内容区、操作区、反馈区分别放什么。

第三类是关键流程。比如创建、编辑、审批、驳回、批量处理、异常回退。每个流程都要写清楚触发条件和结果。

第四类是字段规则。哪些字段展示，哪些字段可编辑，空值怎么展示，默认值是什么，是否必填，是否有权限限制。

在 TRAE Work Design 中，可以按下面方式使用：

1. 输入 PRD、流程说明、用户故事或字段表。
2. 先要求输出页面清单和跳转关系。
3. 再要求逐页生成线框结构。
4. 然后补齐关键状态和异常分支。
5. 最后再请求为选定页面生成高保真方案或可点击 HTML Demo，并检查实际输出是否覆盖关键状态。

UI 草图/线框 Prompt

是产品经理 + 交互设计师。
请把以下【需求文本】转译为可讨论、可评审、可交给前端实现的 UI 线框/原型。

【输入】
- 需求来源：{PRD / 用户故事 / 流程说明 / 业务字段}
- 产品类型：{后台管理 / SaaS / 数据看板 / 审批系统 / 告警平台}
- 关键页面：{首页 / 列表 / 详情 / 配置 / 审批 / 设置}
- 关键状态：{空态 / 加载 / 错误 / 权限不足 / 未绑定 / 未登录}
- 角色权限：{管理员 / 普通用户 / 只读用户 / 审批人}

【输出】
1. 页面清单：列出所有页面、入口和跳转关系。
2. 每页线框：说明布局结构、信息层级和组件清单。
3. 关键流程：用步骤描述主流程和分支流程。
4. 字段规则：标注展示、可编辑、为空展示、默认值、必填和权限限制。
5. 异常状态：说明空态、错误态、加载态、权限不足和禁用态。
6. 前端交付说明：列出组件、数据字段、交互事件和待确认问题。

【约束】
- 先线框后高保真。
- 不虚构业务字段；缺失信息列为待确认项。
- 所有交互都要写明触发条件、反馈和结果。
- 如果当前版本提供画布或预览入口，请说明如何在其中继续调整；否则输出可供评审的结构说明。

UI 草图交付清单

四、承接前端：把视觉方案变成可点击 HTML 原型

图 4：一次示例任务中显示了本地 Web 预览和文件变更。是否出现这些产物，取决于任务要求、运行环境和生成结果。

很多界面视觉需求最后都会落到前端。此时，仅有一张设计图还不够。前端更关心的是组件边界、交互状态、布局约束、响应式、假数据结构和异常状态。

可以把 Design 阶段当作前端原型的上游：先确认页面结构和视觉方向，再明确请求 HTML 原型。原型只用于讨论和验证，不能替代接口联调、可访问性检查和正式测试。

可点击 HTML 原型尤其适合这些页面：

1. BI 看板：需要看指标卡、图表、筛选、时间范围、图例和数据密度。
2. 表单系统：需要验证填写、校验、禁用、错误提示、分步流程。
3. 列表 + 详情：需要验证筛选、排序、分页、抽屉详情、批量操作。
4. 工具型单页：需要验证输入、生成、预览、复制、下载等即时反馈。

生成 HTML 原型时，要特别强调四点。

第一，在 Prompt 中明确要求能直接打开运行。可以是一个 HTML 文件，也可以是 HTML + CSS + 原生 JS。原型阶段可以用假数据，但字段含义应与真实业务一致。

第二，必须有交互状态。hover、active、disabled、empty state、loading、error 都应该体现，否则前端仍然要补大量细节。

第三，必须有响应式。至少覆盖 375 宽移动端和 1440 宽桌面端。

第四，必须少用“装饰性炫技”。后台、平台、工具类页面更看重信息效率，视觉要服务于扫描、比较、操作和重复使用。

可点击 HTML 原型 Prompt

是前端工程师，偏原型与交互实现。
请生成一个可点击 HTML 原型，用来演示以下页面。

【输入】
- 页面类型：{BI 看板 / 表单 / 列表+详情 / 工具型单页}
- 产品背景：{业务说明}
- 目标用户：{用户角色}
- 风格：{商务 / 科技 / 年轻化 / 克制专业}
- 参考：{链接 / 截图 / 设计方向}
- 关键交互：{筛选 / 切 tab / 抽屉 / 弹窗 / 分页 / 排序 / hover 状态}

【输出要求】
1. 产物为 1 个 HTML 文件，可直接打开运行。
2. CSS 可以内联，也可以独立，但要结构清晰。
3. 使用原生 JS 实现基础点击交互。
4. 可以使用假数据，但字段要贴合业务。
5. 必须包含 hover、active、disabled、empty state。
6. 至少支持 375 和 1440 两档响应式。
7. 页面需要体现真实信息密度，不要做成营销落地页。

【前端约束】
- 尽量使用语义化 HTML。
- 组件边界清晰，便于后续拆成前端组件。
- 不使用复杂依赖，除非明确说明用途。
- 交互失败或无数据时要有反馈。

五、设计系统：把一次界面优化沉淀成长期资产

图 5：Design 系统库展示了内置设计系统，并提供添加自定义设计系统的入口。是否能导入或复用现有资产，需要按当前版本实际能力确认。

如果每次都从零开始写 Prompt，页面很容易不一致。真正高效的方式，是把高频界面视觉需求沉淀成资产。

无论使用哪种设计工具，团队都值得至少沉淀三类资产。

第一类是 Prompt 模板。比如 UI 重构模板、UI 草图模板、HTML 原型模板、BI 看板模板、表单模板、列表详情模板。模板的价值是让输入稳定，输出也更容易稳定。

第二类是 token 表。把颜色、字号、间距、圆角、阴影、边框、图标尺寸、表格密度、状态颜色整理成表。这样每次生成页面时，可以要求 Design 遵循同一套 token。

第三类是组件规则。比如按钮分几级，表格有哪些密度，筛选区何时折叠，抽屉宽度是多少，弹窗用于什么场景，空态是否提供主操作。这些规则越清楚，生成结果越接近团队真实产品。

可以用下面的 token schema 作为起点：

设计系统沉淀 Prompt

请基于当前页面/设计稿，提取一份可复用的界面视觉规范。

【输出】
1. 主题 token：颜色、字号、间距、圆角、阴影、边框。
2. 组件规范：按钮、输入框、表格、筛选器、标签、弹窗、抽屉、分页。
3. 状态规范：hover、active、disabled、selected、empty、loading、error。
4. 命名规范：组件命名、token 命名、页面模块命名。
5. 迁移建议：如何把旧页面逐步迁移到这套规范。

【要求】
- 输出为表格。
- 标注哪些是现有样式，哪些是建议新增。
- 给出前端可使用的 CSS 变量命名建议。

六、一个完整实战：后台告警列表从需求到原型

图 6：本章案例的线框预览，右侧展示了三种结构方向和推荐方案。

假设我们要做一个「设备告警管理」页面，业务需求如下：

用户需要查看设备告警，支持按告警等级、设备类型、处理状态、时间范围筛选；支持批量确认、转派负责人、查看告警详情和处理日志；不同角色权限不同，普通用户只能查看和确认，管理员可以转派和关闭告警。

可以用多轮任务把需求逐步收敛：

第一轮，不要直接要高保真页面，而是生成页面 IA：

请把以下需求拆成页面清单、跳转关系和关键流程。
产品：设备告警管理
页面：告警列表、告警详情、处理记录、规则配置
角色：管理员、普通用户、只读用户
关键操作：筛选、批量确认、转派负责人、关闭告警、查看日志
请输出页面清单、流程分支、字段规则和异常状态。

第二轮，让 Design 生成线框：

请基于上一步页面清单，生成告警列表页线框。
要求包含顶部标题区、关键指标、筛选区、表格区、批量操作区、分页、右侧详情抽屉。
请标注每个区域的组件、字段、交互和状态。

第三轮，做视觉重构：

请把告警列表页从线框升级为后台管理系统的高保真视觉方案。
风格要求：专业、清晰、适合高频操作。
重点优化：告警等级识别、状态扫描效率、批量处理路径、详情抽屉信息层级。
请输出保守优化版和信息效率版两套方案。

第四轮，承接前端原型：

请生成一个可点击 HTML 原型，演示告警列表页。
交互包括：筛选、切换状态 tab、打开详情抽屉、批量选择、禁用按钮状态、空态。
要求支持 375 和 1440 响应式，使用假数据，字段贴合设备告警业务。

当每一轮都经过业务、设计和前端的确认后，最终交付可以包含需求拆解、线框、视觉方案、状态说明和可点击原型，而不只是“一张好看的页面”。

七、写给不同角色的使用建议

图 7：任务页会保留输入要求和待办步骤，便于团队在评审时追溯本次讨论的范围。实际协作方式仍取决于团队的评审流程。

如果是产品经理，不要只把 PRD 丢给 Design。最好补充关键页面、用户角色、状态、权限、字段规则。这样生成结果会更像产品原型，而不是泛化界面。

如果是设计师，不要只要求“高级感”。最好明确参考风格、品牌约束、组件库、token、禁用的视觉方向，以及是否需要保守版、创新版、效率版多方案对比。

如果是前端工程师，不要只要静态图。最好要求 HTML 原型、交互状态、响应式、组件边界、假数据结构和失败反馈。这样更容易进入开发。

如果是团队负责人，不要只追求单次生成效果。更值得做的是沉淀 Prompt、token、组件规则和验收清单，让团队每次处理界面视觉需求时都有统一方法。

八、最终可复制的总模板

图 8：总模板的作用是让每次输入都包含目标、状态、约束和可验收输出。

下面是一份适合大多数网页/界面视觉需求的总模板。可以根据场景删减。

是资深 UI/UX 设计师、产品交互设计师和前端原型工程师。
请基于以下材料，在 TRAE Work Design「网页/界面视觉」场景下，完成界面方案设计。

【输入材料】
- 页面/需求来源：{截图 / URL / HTML / PRD / 用户故事 / 字段表}
- 产品类型：{后台管理 / SaaS / 大屏 / 官网 / 工具型单页 / 移动端}
- 目标用户：{用户角色}
- 关键任务：{用户进入页面要完成什么}
- 现有问题或设计目标：{问题/目标}
- 参考风格或设计约束：{品牌 / 色板 / 组件库 / 竞品 / 禁用方向}

【请先判断任务类型】
1. 如果是已有页面，请先做 UI 诊断和重构建议。
2. 如果是需求文本，请先生成页面清单、线框和关键流程。
3. 如果要承接前端，请继续生成可点击 HTML 原型方案。

【输出内容】
1. 需求理解：用简短语言复述页面目标和用户任务。
2. 信息架构：页面模块、层级、入口和跳转关系。
3. 方案设计：至少给出保守优化版和结构优化版。
4. 关键组件：列出导航、筛选、表格、卡片、表单、弹窗、抽屉、分页等组件。
5. 交互状态：hover、active、disabled、empty、loading、error、permission denied。
6. 主题 token：颜色、字号、间距、圆角、阴影、边框。
7. 前端交付：组件边界、假数据字段、响应式策略、实现注意事项。
8. 验收清单：列出可以逐项检查的标准。

【约束】
- 不改变业务字段含义。
- 不虚构核心业务规则，缺失信息列为待确认项。
- 优先复用现有组件和设计规范。
- 后台/平台/工具类页面优先保证信息效率，不做过度装饰。
- 至少考虑 375 和 1440 两档响应式。

小结

图 9：设计系统库可作为沉淀和查找规范的入口之一；是否能直接复用到生成结果，需要在实际任务中验证。

这套方法尤其适用于 UI 重构、UI 草图、可点击 HTML 原型和设计系统沉淀等高频需求。

它的正确用法不是一句“帮我美化页面”，而是把界面工作拆成可执行链路：先诊断问题，再生成方案；先画线框，再做视觉；先说明状态，再交给前端；先做一次页面，再沉淀模板和规范。

当把截图、PRD、字段表、组件约束和验收清单交给工具，并在每轮输出后做人工复核，它才能真正帮助产品、设计和前端更早对齐。