Appearance
PRD转Figma设计落地全流程及开发环境搭建手册
适用场景：完成 Node.js、Figma、Chrome 插件、OpenAI Codex Desktop、Codex Skills 以及本地
server.js服务的安装与验证。
📌 方案价值
本流程推荐将 PRD 先转换为可运行的 HTML 页面，再通过 Chrome 插件复制到 Figma 中编辑。
| 对比项 | PRD 转 HTML 再到 Figma | PRD 转图片再到 Figma |
|---|---|---|
| 产品美化度 | 产品设计美观度略低 | 产品设计更加美观 |
| 可编辑性 | 页面结构、文字、组件更容易被 Figma 识别为可编辑元素 | 通常是一整张图片，进入 Figma 后难以逐层编辑 |
| 交互验证 | 可在浏览器中先验证按钮、弹窗、筛选、表单等交互 | 图片只能展示静态效果，无法验证真实交互 |
| 信息还原 | 能更好保留页面层级、布局、文本和组件关系 | 容易丢失结构信息，只保留视觉结果 |
| 多页面支持 | 可按业务流程生成多个独立 HTML 页面，再分别导入 Figma | 多页面通常需要生成多张图片，管理和修改成本更高 |
| 修改效率 | 修改需求后可调整 HTML，再重新复制到 Figma | 图片修改通常需要重新生成整张图 |
| 评审体验 | 产品、设计、研发都可以在浏览器中先体验接近真实页面的效果 | 更适合快速看视觉方向，不适合评审流程细节 |
| 适用场景 | 产品原型、后台系统、管理台、业务流程页、交互验证 | 概念图、视觉氛围图、一次性展示图 |
| 主要缺点 | 需要 Node.js、本地服务和插件配合，前期环境稍复杂 | 生成快、门槛低，但后续编辑和复用能力弱 |
| token消耗 | 低 | 高 |
| 额外费用 | 无 | 插件收费,免费有次数限制 |
1. 优先用「PRD → HTML → Figma」的情况
- 目标：在 Figma 中持续迭代设计稿、对齐产品逻辑、输出可落地的高保真原型
- 典型场景
- 后台系统、管理平台、业务流程页等结构复杂、交互多的产品原型
- 需要和研发评审交互逻辑（按钮、弹窗、表单校验、筛选联动等）
- 后续需要反复修改、复用组件，避免每次改动都要重新生成
- 跨角色协作（产品 / 设计 / 研发都需要体验接近真实的页面效果）
- 额外优势补充
- 保留了文本、组件、层级的可编辑性，设计师可以直接在 Figma 里调整样式、做设计规范，不用从零开始搭建页面结构
- 浏览器端可提前验证交互，减少后续研发阶段的逻辑返工
2. 用「PRD → 图片 → Figma」的情况
- 目标：快速输出视觉方向稿、一次性展示概念，不需要后续深度编辑
- 典型场景
- 早期概念图、视觉氛围稿、品牌风格方向稿
- 临时体视觉方向，不涉及细节评审
- 多方案快速对比（比如同时出 2-3 个不同风格的视觉概念）
- 额外优势补充
- 上手门槛极低，不需要搭建环境、安装插件，几分钟就能生成结果
- 适合快速出稿，满足 “先看个大概” 的沟通需求
总结：两种方案并非互斥关系，而是可以根据项目阶段灵活选择、互相辅助的工具。 在概念探索期，可通过「PRD 转图片」快速出稿、对齐方向；进入评审与迭代阶段后，再通过「PRD 转 HTML」实现可编辑、可交互的落地协作，二者结合能兼顾效率与可维护性，最大化流程价值。
文档信息
| 项目 | 内容 |
|---|---|
| 作者 | 雷真 |
| 创建日期 | 2026-05-19 |
| 最后更新 | 2026-05-19 |
环境清单
| 序号 | 工具 / 环境 | 用途 | 安装状态 |
|---|---|---|---|
| 1 | Node.js | 运行本地 JavaScript 服务 | 待安装 |
| 2 | Figma | 编辑可视化设计稿 | 待安装 |
| 3 | Chrome 插件 | 将网页复制为 Figma 可编辑设计稿 | 待安装 |
| 4 | OpenAI Codex Desktop | 桌面端 AI 编程助手 | 待安装 |
| 5 | Codex Skills | 扩展 Codex 的专项处理能力 | 待了解 |
| 6 | server.js | 启动本地页面服务 | 待配置 |
目录
- 1. 安装 Node.js
- 2. 安装 Figma
- 3. 安装 Chrome 插件
- 4. 安装 OpenAI Codex Desktop
- 5. 下载并运行 server.js
- 6. 验证环境并使用 Figma 插件
- 7. 在 Codex 中使用 Skills
- 8. 常见问题
1. 安装 Node.js
下载地址
安装步骤
- 打开上方链接，进入 Node.js 下载页面。
- 根据操作系统选择对应安装包，推荐安装 LTS 版本。
- Windows：下载
.msi安装包。 - macOS：下载
.pkg安装包。
- Windows：下载
- 运行安装包，并按照安装向导完成安装。
- 安装完成后，打开终端或命令提示符，执行以下命令验证安装结果：
bash
node -v
npm -v验证结果
如果命令行显示 Node.js 和 npm 的版本号，说明安装成功。
2. 安装 Figma
下载地址
安装步骤
- 打开 Figma 官网。
- 点击页面右上角的 Download 按钮。
- 根据操作系统下载对应桌面客户端。
- Windows：下载
.exe安装包。 - macOS：下载
.dmg安装包。
- Windows：下载
- 运行安装包，并按照安装向导完成安装。
- 安装完成后启动 Figma，可以登录账号使用，也可以直接使用 Web 版本。
提示：Figma 桌面端不是必须安装，也可以直接通过 Figma 网页版 使用。
3. 安装 Chrome 插件
插件信息
| 项目 | 内容 |
|---|---|
| 插件名称 | Copy web to Figma |
| 插件说明 | 复制网页为 Figma 可编辑设计稿，无需安装 Figma 插件 |
| 安装地址 | Chrome 应用商店页面 |
安装步骤
- 点击上方链接，进入 Chrome 应用商店的插件页面。
- 点击 添加至 Chrome。
- 在弹出确认框中点击 添加扩展程序。
- 安装完成后，插件图标会出现在 Chrome 浏览器右上角的扩展程序栏中。
4. 安装 OpenAI Codex Desktop
下载地址
工具概述
OpenAI Codex Desktop 是 OpenAI 推出的桌面端 AI 编程助手应用，提供原生桌面体验，支持 Windows 和 macOS 系统，可用于理解代码、编写代码、修复 Bug 和协作处理项目。
安装步骤
- 打开 OpenAI Codex 官网。
- 点击页面中的 Download for Desktop 或 下载桌面端 按钮。
- 根据操作系统选择对应版本。
- Windows：下载
.exe或.msi安装包。 - macOS：下载
.dmg安装包。
- Windows：下载
- 运行安装包，并按照安装向导完成安装。
- 启动 Codex Desktop 应用。
基本使用
登录账号
- 首次启动时，使用 OpenAI 账号登录。
- 如果没有账号，可点击注册按钮创建新账号。
新建对话
- 点击 New Chat 或 新建对话，开始新的编程任务。
处理设计＆编程任务
- 在对话框中输入编程问题或需求。
- 可以粘贴需求或者代码片段，让 Codex 解释、修改或补全。
- 支持多轮对话，可继续追问或要求调整代码。
项目协作
- 可以将整个项目文件夹拖入窗口。
- Codex 会分析项目结构，并提供针对性的代码帮助。
注意事项
- 使用 Codex Desktop 需要 OpenAI 账号，可通过 OpenAI 官网 注册。
- 部分高级功能可能需要付费订阅。
- 首次使用需要网络连接进行账号认证。
5. 下载并运行 server.js
前提条件
请先完成 1. 安装 Node.js。
下载文件
| 项目 | 内容 |
|---|---|
| 文件名称 | server.js |
| 下载地址 | https://proto.aiteyixia.cn/download/server.zip |
下载完成后，解压 server.zip 文件。
放置文件
将 server.js 放入你的 Codex 工程目录中，例如：
text
D:\my-project最终目录示例：
text
D:\my-project\server.js运行服务
打开终端或命令提示符，进入项目目录：
bash
cd D:\my-project运行 server.js：
bash
node server.js验证服务
打开浏览器访问：
text
http://localhost:端口号如果页面可以正常显示，说明本地服务运行成功。具体端口号以 server.js 中的配置为准。
6. 验证环境并使用 Figma 插件
前提条件
请确认以下环境均已完成安装或配置：
- Node.js 已安装。
- Figma 已安装，或可正常打开 Figma 网页版。
- Chrome 插件 Copy web to Figma 已安装。
server.js已下载并放入项目目录。
操作流程
启动本地服务
打开终端，进入项目目录，并运行：
bashnode server.js访问本地页面
打开浏览器，访问本地服务地址：
texthttp://localhost:端口号确认页面可以正常显示。
使用 Copy web to Figma 插件
- 在浏览器中打开需要复制的网页。
- 点击浏览器右上角扩展栏中的 Copy web to Figma 插件图标。
- 插件会将网页内容复制为 Figma 可编辑设计稿。
- 复制完成后，打开 Figma 编辑页面并粘贴。
选择 Figma 使用方式
使用方式 说明 Figma 桌面端 已安装本地客户端时，可使用桌面端编辑 Figma 网页端 未安装客户端时，可直接在浏览器中编辑
7. 在 Codex 中使用 Skills
什么是 Skills
Skills 是 Codex 中的专项能力扩展，用于让 Codex 按照特定工作流处理任务。例如：前端页面设计、文档处理、表格处理、演示文稿制作、图片生成、浏览器自动化等。
当你的需求匹配某个 Skill 时，Codex 会优先使用对应 Skill 的规则和工具完成任务，让输出更稳定、更符合场景要求。
常见使用方式
| 使用方式 | 示例 |
|---|---|
| 直接描述任务 | 帮我美化这个网页界面 |
| 指定 Skill 名称 | 使用 frontend-design skill 优化这个页面 |
| 指定输出类型 | 把这份内容整理成 Word 文档 |
| 指定处理目标 | 用浏览器打开 localhost:3000 并检查页面效果 |
使用步骤
打开 Codex Desktop
- 启动 Codex Desktop，并确认已登录 OpenAI 账号。
打开项目目录
- 将当前项目文件夹拖入 Codex。
- 或在 Codex 中选择需要处理的项目目录。
输入明确需求
- 说明要处理的文件、目标和期望结果。
- 如果知道 Skill 名称，可以直接在提示词中写出 Skill 名称。
让 Codex 执行任务
- Codex 会根据任务类型读取相关文件。
- 如果任务匹配某个 Skill，Codex 会按照该 Skill 的工作流处理。
查看并确认结果
- 检查 Codex 修改的文件、生成的文档或运行结果。
- 如果不满意，可以继续输入调整要求，例如“标题再简洁一点”或“表格样式再正式一些”。
推荐提示词
text
使用 frontend-design skill，帮我优化首页 UI，保持现有功能不变。text
使用 documents skill，把这份 Markdown 整理成正式的 Word 文档。text
使用 browser skill，打开本地页面并检查按钮是否可以正常点击。text
使用 spreadsheets skill，分析这个 Excel 表格并生成汇总图表。产品经理生成 HTML 专用提示词
当产品经理需要让 Codex 根据需求文档、原型描述或功能说明生成 HTML 页面时，可以将以下内容保存为完整的 SKILL.md：
markdown
---
name: product-html-prototype
description: 根据产品需求、PRD、功能说明、用户流程或原型描述生成完整、可直接运行的 HTML 原型。适用于产品经理需要在不搭建后端的情况下，生成真实前端页面或交互原型，用于产品评审、需求沟通或早期 UI 验证。
---
# 产品 HTML 原型生成
## 目标
根据产品需求生成一个完整、可直接运行的 HTML 页面。
输出结果应帮助产品经理评审业务流程、沟通需求、验证早期交互想法。生成内容应是真实产品界面，而不是营销宣传页。
## 输入内容
用户可能提供以下任意一种内容：
- 产品需求文档
- 功能说明
- 页面结构
- 用户流程
- 原型备注
- 截图说明
- 粗略产品想法
如果信息不完整，应基于常见产品逻辑做合理补全，并在完成后说明做了哪些假设。
## 生成要求
1. 只生成前端页面，不要求后端服务。
2. 使用 HTML、CSS 和 JavaScript 实现。
3. 代码结构清晰，便于后续修改。
4. 页面应符合真实产品使用场景，不要只做静态展示。
5. 优先展示核心业务流程和关键交互。
6. UI 风格应简洁、专业、易读，适合产品评审。
7. 如果需求中包含表单、列表、筛选、弹窗、状态切换、标签页、表格或流程操作，需要实现可用的交互效果。
8. 页面需要同时适配桌面端和移动端。
9. 避免只有占位内容的页面，必要时使用真实感示例数据。
10. 除非用户明确要求，否则不要添加后端接口调用。
## 工作流程
1. 阅读产品需求，识别主要用户目标。
2. 提取页面区域、数据对象、页面状态和交互行为。
3. 推断缺失但必要的 UI 细节。
4. 默认生成一个包含 HTML、CSS 和 JavaScript 的完整 HTML 文件，除非用户要求拆分文件。
5. 确认关键交互可以在浏览器本地运行。
6. 总结生成的页面区域、交互能力和产品假设。
## UI 设计建议
- 优先使用产品工具型布局，不要使用宣传页布局。
- 如果页面用于运营、审核、看板或管理场景，应采用信息密度较高但结构清晰的布局。
- 使用常见控件，例如按钮、标签页、筛选器、表格、表单、弹窗、菜单、开关和状态标签。
- 保持清晰的信息层级、合理间距、可读字体和足够的颜色对比度。
- 避免加入与产品任务无关的装饰性区域。
## 输出格式
需要输出：
1. 生成的 HTML 文件或完整代码。
2. 页面区域说明。
3. 已实现的交互说明。
4. 因需求信息不完整而做出的假设列表。
5. 多页面独立 html，不要单页全塞
## 用户提示词模板
```text
使用 product-html-prototype skill，基于以下产品需求生成一个可直接运行的 HTML 页面。
产品需求：
【在这里粘贴产品需求、功能说明、页面结构或原型描述】
输出要求：
- 生成完整 HTML 文件。
- 保持页面在桌面端和移动端都能正常查看。
- 完成后说明生成了哪些页面区域和交互能力。
```英文版：
markdown
---
name: product-html-prototype
description: Generate complete, runnable HTML prototypes from product requirements, PRDs, feature descriptions, user flows, or prototype notes. Use when a product manager needs a realistic front-end page or interactive prototype for product review, requirement communication, or early UI validation without building a backend.
---
# Product HTML Prototype
## Goal
Generate a complete, directly runnable HTML page from product requirements.
The output should help product managers review business flows, communicate requirements, and validate early interaction ideas. The generated result should be a realistic product interface, not a marketing landing page.
## Input
The user may provide any of the following:
- Product requirement document
- Feature description
- Page structure
- User flow
- Prototype notes
- Screenshot explanation
- Rough product idea
If the information is incomplete, make reasonable additions based on common product logic and explain the assumptions after completion.
## Requirements
1. Generate front-end pages only. Do not require a backend service.
2. Use HTML, CSS, and JavaScript.
3. Keep the code structure clear and easy to modify.
4. The page should match a realistic product use case, not just a static display.
5. Prioritize the core business flow and key interactions.
6. The UI style should be clean, professional, readable, and suitable for product review.
7. If the requirement includes forms, lists, filters, dialogs, status changes, tabs, tables, or workflow actions, implement usable interactions.
8. The page should work on both desktop and mobile screens.
9. Avoid placeholder-only pages. Use realistic sample data when needed.
10. Do not add backend API calls unless the user explicitly asks for them.
## Workflow
1. Read the product requirements and identify the main user goal.
2. Extract page sections, data objects, page states, and interaction behaviors.
3. Infer missing but necessary UI details.
4. By default, generate one complete HTML file containing HTML, CSS, and JavaScript unless the user asks for separated files.
5. Confirm that key interactions can run locally in a browser.
6. Summarize the generated page sections, interaction capabilities, and product assumptions.
## UI Design Guidance
- Prefer product-tool layouts over marketing layouts.
- If the page is for operations, review, dashboards, or management scenarios, use a dense but well-organized layout.
- Use familiar controls such as buttons, tabs, filters, tables, forms, dialogs, menus, switches, and status labels.
- Keep a clear information hierarchy, reasonable spacing, readable typography, and sufficient color contrast.
- Avoid decorative areas that do not support the product task.
## Output Format
Provide:
1. The generated HTML file or complete code.
2. A description of the implemented interactions.
3. A list of assumptions made because the requirement information was incomplete.
4. For multi-page products, generate separate independent HTML files for each page instead of cramming everything into one single page.
## User Prompt Template
```text
Use the product-html-prototype skill to generate a directly runnable HTML page based on the following product requirements.
Product requirements:
【Paste the product requirements, feature description, page structure, or prototype notes here】
Output requirements:
- Generate a complete HTML file.
- For multi-page products, generate separate independent HTML files instead of putting everything into one page.
- Keep the page usable on both desktop and mobile screens.
- After completion, explain which page sections and interaction capabilities were generated.
```Skill 顶部说明格式
每个 Skill 通常会在顶部提供一段元信息，用于说明 Skill 的名称、用途和触发场景。常见格式如下：
yaml
name: product-html-prototype
description: 根据产品需求、PRD、功能说明、用户流程或原型描述生成完整、可直接运行的 HTML 原型。适用于产品经理需要在不搭建后端的情况下，生成真实前端页面或交互原型，用于产品评审、需求沟通或早期 UI 验证。字段说明：
| 字段 | 说明 |
|---|---|
name | Skill 的唯一名称，通常使用英文小写和短横线 |
description | Skill 的用途说明，Codex 会根据这段描述判断什么时候使用该 Skill |
如果需要编写自定义 Skill，建议在 description 中明确写出：
- 这个 Skill 解决什么问题。
- 什么场景下应该使用。
- 什么场景下不应该使用。
- 使用时是否需要遵循特定流程或输出格式。
注意事项
- 提示词越明确，Codex 越容易选择正确的 Skill。
- 如果你不确定该用哪个 Skill，可以直接说明目标，让 Codex 自动判断。
- 如果当前环境没有安装对应 Skill，Codex 会提示无法使用，或建议安装相关 Skill。
- Skills 适合处理有明确类型的任务，例如网页、文档、表格、演示文稿、图片、浏览器检查等。
- 中英文版任选一种即可。
- https://github.com/nacker/product-html-prototype.git
8. 常见问题
端口被占用
如果运行 server.js 时出现以下报错：
text
EADDRINUSE说明端口已被其他程序占用。可以修改 server.js 中的端口号，或关闭占用该端口的程序后重新运行。
缺少模块
如果出现类似以下报错：
text
Cannot find module xxx说明缺少依赖模块。可以在项目目录中执行：
bash
npm install xxx将 xxx 替换为报错中提示的模块名称。
页面无法打开
请依次检查：
node server.js是否仍在运行。- 浏览器访问的端口号是否与
server.js配置一致。 - 防火墙或安全软件是否拦截了本地服务。
- 当前终端所在目录是否包含
server.js文件。