TREA从 UI 到可交付前端原型
本篇教程重点讲两个高频场景：
🌳
UI 重构与视觉优化：适合已有页面、截图、URL、HTML 片段，需要诊断问题并做改版方案。
UI 草图/线框/原型：适合只有 PRD、流程、用户故事，需要快速生成页面结构、关键流程和交付说明。
适合产品经理、设计师、前端工程师、个人开发者和团队负责人。
适用于 UI 重构、视觉优化、线框原型、可点击 HTML Demo 和设计系统沉淀等场景。
重点不是让 AI 替代设计或开发，而是把界面需求拆成可诊断、可讨论、可交付的工作流程，让产品、设计和前端更早对齐。
最后会给出一组可直接复制到 TraeWork Design 使用的 Prompt 模板。
40%
60%
一、先判断：你的界面需求属于哪一类
TraeWork Design 首页
图 1：TraeWork 的 Design 首页。开始前先准备好 PRD、截图、URL、字段表或现有代码中的至少一种材料。
💡
在进入 TraeWork Design 之前，不建议一上来就说"帮我设计一个页面"。更好的方式，是先判断自己手里的材料和目标。
根据手头材料和目标，可以选择以下四条路线：
•
UI 重构路线：已经有截图、URL、旧页面或 HTML 片段。重点不是重新发明一个页面，而是诊断现有问题，保留业务字段和核心流程，优化信息层级、布局密度、视觉统一性和可用性。
•
UI 草图/线框路线：只有 PRD、用户故事、业务流程或字段表。重点是把需求转成页面清单、跳转关系、关键状态、字段规则和交互分支，让产品、设计、前端能够在同一个界面模型上讨论。
•
可点击 HTML 原型路线：要做演示、前端验证或客户汇报。重点是明确要求可运行的页面和需要覆盖的状态，例如 hover、active、disabled、空态、加载和错误态；生成后仍要亲自打开验证。
•
设计系统与资产沉淀路线：团队已经有组件库、Figma 规范或品牌视觉。重点是把颜色、字号、间距、圆角、阴影、表格、筛选器、弹窗、按钮等规范变成可复用资产，减少每次生成页面时的风格漂移。
一个简单的判断表如下：
| | |
| | |
| | |
| | |
| | |
| | |
二、UI 重构：从"页面不好看"变成"问题可诊断、方案可验收"
UI 重构任务：需求与待办
图 2：示例重构任务中，左侧记录了输入的重构要求，右侧列出诊断、方案和文档等待办步骤。该截图不代表每个任务都会自动生成文件或预览。
UI 重构最常见的输入是旧页面截图、线上 URL、后台页面、平台首页、大屏、官网首屏或工具型单页。
很多人做 UI 重构时，会直接要求 AI "美化一下"。这类输入太泛，容易得到表面化结果：换个渐变、加几张卡片、调大标题、加阴影，但页面真正的问题没有被解决。
更有效的做法，是把任务拆成四步：
先诊断，再重画。诊断至少应覆盖信息架构、视觉层级、操作路径、组件一致性、阅读密度、状态完整性和响应式风险。
给出多套重构方案。通常建议至少三套：保守优化、结构重排、视觉焕新。保守优化适合快速上线；结构重排适合信息层级明显混乱的页面；视觉焕新适合官网、品牌页、大屏、产品展示页等更依赖视觉表达的场景。
每套方案说明关键组件和交互。比如表格筛选如何折叠，批量操作在哪里出现，详情是新页面还是抽屉，错误态如何反馈，空态是否提供引导操作。
输出验收清单。UI 重构不能只靠"感觉更好看"。它应该能被检查：首屏是否有主任务，按钮层级是否清晰，字段是否保留，页面状态是否完整，响应式是否覆盖，组件是否复用。
可以按下面的顺序组织一次重构任务：
提供现有页面截图、可访问的 URL、HTML 片段或项目目录中的一种材料。
补充产品类型，例如后台管理、平台、大屏、官网、移动端。
说明主要用户和关键任务，例如运营查数据、管理员审批、客服处理工单、管理者看经营指标。
让 Design 先输出诊断，再输出三套方案。
选择其中一套，继续细化布局、色彩、组件和状态；若当前界面提供画布入口，可在画布中继续调整。
如果要交给前端，补充组件清单、交互说明、token 建议和验收清单，并由前端评估实现成本。
UI 重构示例 Prompt
UI 重构验收清单
完成一版重构方案后，可以用下面这份清单检查：
| |
| |
| |
| |
| |
| |
| |
| |
三、UI 草图/线框：从 PRD 直接生成可讨论的页面骨架
设备告警管理：三种线框结构方案
图 3：告警管理线框的本地预览，展示三种结构方向及推荐方案。这是一次示例输出，不是固定模板。
UI 草图适合需求还没有进入高保真的阶段。这个阶段不要急着追求视觉效果，最重要的是把页面结构、流程分支和字段规则讲清楚。
产品经理、业务负责人或前端同学经常会给出一段长需求，例如：
"我们要做一个告警管理页面，支持查看告警列表、按设备/等级/状态筛选、批量处理、查看详情、转派负责人、记录处理日志，还要支持空态、无权限、加载失败。"
这段话里包含页面、字段、状态、权限和流程，但还没有形成界面结构。可以先要求工具把它整理成页面清单、线框结构和待确认项，再由团队补齐缺失信息。
建议 UI 草图阶段固定输出四类内容：
•
页面清单：包括有哪些页面、从哪里进入、页面之间如何跳转。比如首页、列表页、详情页、配置页、审批页、弹窗、抽屉、空态页。
•
每页线框：包括布局结构、信息层级、组件清单。这里不需要先追求精细视觉，但要说明顶部、侧边栏、筛选区、内容区、操作区、反馈区分别放什么。
•
关键流程：比如创建、编辑、审批、驳回、批量处理、异常回退。每个流程都要写清楚触发条件和结果。
•
字段规则：哪些字段展示，哪些字段可编辑，空值怎么展示，默认值是什么，是否必填，是否有权限限制。
在 TraeWork Design 中，可以按下面方式使用：
输入 PRD、流程说明、用户故事或字段表。
先要求输出页面清单和跳转关系。
再要求逐页生成线框结构。
然后补齐关键状态和异常分支。
最后再请求为选定页面生成高保真方案或可点击 HTML Demo，并检查实际输出是否覆盖关键状态。
UI 草图/线框 Prompt
代码块
Plain Text
是产品经理 + 交互设计师。
请把以下【需求文本】转译为可讨论、可评审、可交给前端实现的 UI 线框/原型。
【输入】
- 需求来源：{PRD / 用户故事 / 流程说明 / 业务字段}
- 产品类型：{后台管理 / SaaS / 数据看板 / 审批系统 / 告警平台}
- 关键页面：{首页 / 列表 / 详情 / 配置 / 审批 / 设置}
- 关键状态：{空态 / 加载 / 错误 / 权限不足 / 未绑定 / 未登录}
- 角色权限：{管理员 / 普通用户 / 只读用户 / 审批人}
UI 草图交付清单
| |
| |
| |
| |
| |
| |
四、承接前端：把视觉方案变成可点击 HTML 原型
页面产物、文件变更与本地预览入口
图 4：一次示例任务中显示了本地 Web 预览和文件变更。是否出现这些产物，取决于任务要求、运行环境和生成结果。
很多界面视觉需求最后都会落到前端。此时，仅有一张设计图还不够。前端更关心的是组件边界、交互状态、布局约束、响应式、假数据结构和异常状态。
可以把 Design 阶段当作前端原型的上游：先确认页面结构和视觉方向，再明确请求 HTML 原型。原型只用于讨论和验证，不能替代接口联调、可访问性检查和正式测试。
可点击 HTML 原型尤其适合这些页面：
BI 看板：需要看指标卡、图表、筛选、时间范围、图例和数据密度。
表单系统：需要验证填写、校验、禁用、错误提示、分步流程。
列表 + 详情：需要验证筛选、排序、分页、抽屉详情、批量操作。
工具型单页：需要验证输入、生成、预览、复制、下载等即时反馈。
💡
生成 HTML 原型时，要特别强调以下四点，否则前端仍然要补大量细节。
•
能直接打开运行：在 Prompt 中明确要求可以是一个 HTML 文件，也可以是 HTML + CSS + 原生 JS。原型阶段可以用假数据，但字段含义应与真实业务一致。
•
必须有交互状态：hover、active、disabled、empty state、loading、error 都应该体现。
•
必须有响应式：至少覆盖 375 宽移动端和 1440 宽桌面端。
•
少用"装饰性炫技"：后台、平台、工具类页面更看重信息效率，视觉要服务于扫描、比较、操作和重复使用。
可点击 HTML 原型 Prompt
代码块
Plain Text
是前端工程师，偏原型与交互实现。
请生成一个可点击 HTML 原型，用来演示以下页面。
【输入】
- 页面类型：{BI 看板 / 表单 / 列表+详情 / 工具型单页}
- 产品背景：{业务说明}
- 目标用户：{用户角色}
- 风格：{商务 / 科技 / 年轻化 / 克制专业}
- 参考：{链接 / 截图 / 设计方向}
- 关键交互：{筛选 / 切 tab / 抽屉 / 弹窗 / 分页 / 排序 / hover 状态}
【输出要求】
1. 产物为 1 个 HTML 文件，可直接打开运行。
2. CSS 可以内联，也可以独立，但要结构清晰。
五、设计系统：把一次界面优化沉淀成长期资产
Design 系统库：内置与自定义入口
图 5：Design 系统库展示了内置设计系统，并提供添加自定义设计系统的入口。是否能导入或复用现有资产，需要按当前版本实际能力确认。
如果每次都从零开始写 Prompt，页面很容易不一致。真正高效的方式，是把高频界面视觉需求沉淀成资产。
无论使用哪种设计工具，团队都值得至少沉淀三类资产：
•
Prompt 模板：比如 UI 重构模板、UI 草图模板、HTML 原型模板、BI 看板模板、表单模板、列表详情模板。模板的价值是让输入稳定，输出也更容易稳定。
•
Token 表：把颜色、字号、间距、圆角、阴影、边框、图标尺寸、表格密度、状态颜色整理成表。这样每次生成页面时，可以要求 Design 遵循同一套 token。
•
组件规则：比如按钮分几级，表格有哪些密度，筛选区何时折叠，抽屉宽度是多少，弹窗用于什么场景，空态是否提供主操作。这些规则越清楚，生成结果越接近团队真实产品。
可以用下面的 token schema 作为起点：
| |
| |
| |
| |
| |
| |
| |
设计系统沉淀 Prompt
代码块
Plain Text
请基于当前页面/设计稿，提取一份可复用的界面视觉规范。
【输出】
1. 主题 token：颜色、字号、间距、圆角、阴影、边框。
2. 组件规范：按钮、输入框、表格、筛选器、标签、弹窗、抽屉、分页。
3. 状态规范：hover、active、disabled、selected、empty、loading、error。
4. 命名规范：组件命名、token 命名、页面模块命名。
六、一个完整实战：后台告警列表从需求到原型
完整实战：可点击线框预览
图 6：本章案例的线框预览，右侧展示了三种结构方向和推荐方案。
假设我们要做一个「设备告警管理」页面，业务需求如下：
用户需要查看设备告警，支持按告警等级、设备类型、处理状态、时间范围筛选；支持批量确认、转派负责人、查看告警详情和处理日志；不同角色权限不同，普通用户只能查看和确认，管理员可以转派和关闭告警。
🎯
可以用多轮任务把需求逐步收敛，每一轮都经过业务、设计和前端的确认后再进入下一步。
第一轮，不要直接要高保真页面，而是生成页面 IA：
代码块
Plain Text
请把以下需求拆成页面清单、跳转关系和关键流程。
产品：设备告警管理
页面：告警列表、告警详情、处理记录、规则配置
角色：管理员、普通用户、只读用户
关键操作：筛选、批量确认、转派负责人、关闭告警、查看日志
请输出页面清单、流程分支、字段规则和异常状态。
第二轮，让 Design 生成线框：
代码块
Plain Text
请基于上一步页面清单，生成告警列表页线框。
要求包含顶部标题区、关键指标、筛选区、表格区、批量操作区、分页、右侧详情抽屉。
第三轮，做视觉重构：
代码块
Plain Text
请把告警列表页从线框升级为后台管理系统的高保真视觉方案。
风格要求：专业、清晰、适合高频操作。
重点优化：告警等级识别、状态扫描效率、批量处理路径、详情抽屉信息层级。
请输出保守优化版和信息效率版两套方案。
第四轮，承接前端原型：
代码块
Plain Text
请生成一个可点击 HTML 原型，演示告警列表页。
交互包括：筛选、切换状态 tab、打开详情抽屉、批量选择、禁用按钮状态、空态。
要求支持 375 和 1440 响应式，使用假数据，字段贴合设备告警业务。
当每一轮都经过业务、设计和前端的确认后，最终交付可以包含需求拆解、线框、视觉方案、状态说明和可点击原型，而不只是"一张好看的页面"。
不同角色：任务要求与待办
七、写给不同角色的使用建议
图 7：任务页会保留输入要求和待办步骤，便于团队在评审时追溯本次讨论的范围。实际协作方式仍取决于团队的评审流程。
不同角色在使用 Design 时，关注点和输入要求各有侧重：
•
产品经理：不要只把 PRD 丢给 Design。最好补充关键页面、用户角色、状态、权限、字段规则。这样生成结果会更像产品原型，而不是泛化界面。
•
设计师：不要只要求"高级感"。最好明确参考风格、品牌约束、组件库、token、禁用的视觉方向，以及是否需要保守版、创新版、效率版多方案对比。
•
前端工程师：不要只要静态图。最好要求 HTML 原型、交互状态、响应式、组件边界、假数据结构和失败反馈。这样更容易进入开发。
•
团队负责人：不要只追求单次生成效果。更值得做的是沉淀 Prompt、token、组件规则和验收清单，让团队每次处理界面视觉需求时都有统一方法。
八、最终可复制的总模板
总模板：重构 Prompt、待办与约束
图 8：总模板的作用是让每次输入都包含目标、状态、约束和可验收输出。
下面是一份适合大多数网页/界面视觉需求的总模板。可以根据场景删减。
代码块
Plain Text
是资深 UI/UX 设计师、产品交互设计师和前端原型工程师。
请基于以下材料，在 TraeWork Design「网页/界面视觉」场景下，完成界面方案设计。
【输入材料】
- 页面/需求来源：{截图 / URL / HTML / PRD / 用户故事 / 字段表}
- 产品类型：{后台管理 / SaaS / 大屏 / 官网 / 工具型单页 / 移动端}
小结
设计系统：内置与自定义入口
图 9：设计系统库可作为沉淀和查找规范的入口之一；是否能直接复用到生成结果，需要在实际任务中验证。
这套方法尤其适用于 UI 重构、UI 草图、可点击 HTML 原型和设计系统沉淀等高频需求。
它的正确用法不是一句"帮我美化页面"，而是把界面工作拆成可执行链路：先诊断问题，再生成方案；先画线框，再做视觉；先说明状态，再交给前端；先做一次页面，再沉淀模板和规范。
当把截图、PRD、字段表、组件约束和验收清单交给工具，并在每轮输出后做人工复核，它才能真正帮助产品、设计和前端更早对齐。