陆家贤1. 项目概述与整体思路
1.1 为什么产品经理要亲手写HTML原型
很多产品经理一听到“写代码”三个字就头皮发麻，觉得那是研发的活，自己只要会画Axure、会写PRD就够了。但我在实际带项目的过程里发现，一个能亲手写HTML原型的产品经理，在团队里的话语权和推进效率完全是另一个量级。原因其实很朴素：原型是产品方案最直接的表达方式，而HTML原型是所有原型形态里最接近真实产品的。用Axure画的页面，研发拿到手里还要二次理解、二次翻译，最后实现出来的东西跟你的原始意图往往有偏差。但HTML原型本身就是网页，研发直接看源码、看样式、看交互，理解成本几乎为零。
HTML原型能做的事情远不止“画个页面”。你可以把真实的数据结构塞进去，用真实的接口字段来约束页面展示；你可以把完整的页面流转串起来，让测试提前熟悉业务流程；你甚至可以直接把它交给前端当开发底座，省掉一大半沟通成本。我团队里有一个产品经理就是靠这套方法，把需求评审会的争议率降低了差不多一半，因为大家讨论的是一个能点的、能跳转的、有真实数据的东西，而不是一堆静态线框图。
这套方法真正适合谁呢？三类人最值得学。第一类是天天跟Web产品打交道的产品经理，尤其是B端后台、中台、SaaS类的产品，这类产品页面重、逻辑多、表格表单密集，用HTML表达比Axure强太多；第二类是独立开发者或者创业团队里的多面手，一个人要干产品加设计的活，HTML原型能直接变成前端初稿；第三类是想转行做产品或者刚入行的新人，掌握这套技能会让你在简历和面试里多一个非常有辨识度的亮点。
1.2 一次成型、直达团队的交付链路
这篇博文要讲的不仅是“怎么画原型”，而是从0开始完整跑通一条流水线：在你的电脑上用IDE写HTML原型，通过Git管理版本，推送到GitHub，再开启GitHub Pages一键公网部署，最后把链接甩到团队群里，同事打开就能看到、就能用、就能评论。
这整条链路里我最有感触的一环其实是Git。很多产品经理对Git有天然的恐惧，觉得那是程序员的工具。但你换个角度想：原型文件要不要备份？要不要记录改了哪个版本？要不要让同事协同编辑？这些痛点恰恰就是Git解决的。你不用懂什么分支策略、什么rebase，只需要学会add、commit、push这几个动作，就已经能享受版本管理带来的巨大安全感。我见过太多产品经理的桌面放着“原型最终版v3.2(绝对不改).html”“原型最终版v3.3(再改是狗).html”这样的文件，说实话，看到那些文件名的时候我是真的心疼——那不是工作态度问题，是工具链缺失的问题。
而GitHub Pages这个部署方案，是我试过所有免费部署方式里最省心的。它不需要买服务器，不需要配Nginx，不需要知道什么是反向代理，你只需要把代码推到仓库里，在设置里开一个开关，几分钟之后就能得到一个公网可以访问的链接。相比之下，我之前试过用宝塔面板部署SpringBoot3和Vue3的项目，要配环境、要开端口、要处理跨域，折腾大半天。不是说宝塔方案不好，而是对于原型交付这个场景，GitHub Pages的轻量程度是无可替代的。
1.3 这篇手册你该怎么用
如果你是零基础，建议从第2章按顺序往后看，每一步都动手跟着做一遍。我写这篇东西的时候刻意用了“保姆级”的写法，每一条命令都是完整可复制的，你不需要理解背后的原理也能跑通。但我会尽量在关键位置解释一下“为什么这么做”，因为只有理解了底层逻辑，你遇到没见过的报错时才不会慌。
如果你已经有HTML基础，可以直接跳到第3章以后，重点关注IDE配置、Git操作和部署环节，这几块是真正拉开效率差距的地方。我跟你讲，同一个原型项目，用对了工具链的人半小时就能完成部署，用不对的人可能卡在某个报错上一整天——差别真的就这么大。
整个手册里我不搞任何云里雾里的概念，所有操作都在一个最简单的静态网页项目上展开。先写一个包含登录页、首页、列表页的迷你原型系统，然后一步步把它推到公网。这个过程走通了，以后你换任何项目都只是复用同样的流程而已。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 原型页面设计：从空白HTML到可交互的界面
2.1 HTML骨架：DOCTYPE和基础结构的含义
写HTML原型的第一步，当然是新建一个HTML文件。你可以用记事本写，也可以用IDE写，但内容上是一样的。我建议你对HTML的骨架结构有一个清晰的认知，因为你以后看任何网页源码，第一眼看到的就是这段结构，看不懂会很懵。
一个标准的HTML文件开头是<!DOCTYPE html>，这一行看起来像乱码，实际上是告诉浏览器“我这是一份现代HTML文档”。有了这一行，浏览器就会用标准模式来渲染页面，不会莫名其妙地出现各种布局错乱的兼容问题。紧接着的<html lang="zh-cn">标签声明了页面语言是简体中文，这对浏览器翻译、朗读辅助功能都有影响，原型虽然是给自己团队看的，但顺手写上没有任何坏处。
<head>标签里放的是页面的元信息，其中最关键的是<meta charset="utf-8">，这一行声明了文档编码是UTF-8。新手最容易踩的坑就是忘了这一行，导致页面上所有中文变成乱码，那画面真的非常酸爽。另外就是<title>标签，里面写的内容会显示在浏览器标签页上，原型页面一定要写清楚标题，比如“订单管理原型”，不然开十几个标签页的时候，你根本分不清哪个是哪个。
我顺手整理了一个最简骨架模板，直接复制就能用：
html复制<!DOCTYPE html>
<html lang="zh-cn">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>后台管理原型</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<!-- 页面内容写这里 -->
<script src="script.js"></script>
</body>
</html>
有几点需要对产品经理单独说明一下：<meta name="viewport">这一行是为了适配移动端，如果你做的是移动端H5原型，这一行非常重要，否则手机上看会字小得可怜；<link>是引入外部的CSS样式文件，<script>是引入外部的JavaScript文件。这三个文件各管一摊：HTML管内容、CSS管样子、JavaScript管动作，这就是前端开发里常说的“三层分离”。
2.2 三层分离：内容、样式与交互各司其职
我在带新人做原型的时候，发现最容易犯的错误就是把所有东西都堆在一个HTML文件里，样式写在标签上，交互逻辑也写在标签属性里。这样做不是不行，但一旦页面多了，维护起来就是一场灾难。说的搞笑一点，这相当于你租房不装修，把衣服全堆在客厅地板上——能住是能住，但想找一件衣服得把整个屋子翻个底朝天。
正确做法是坚持三层分离。HTML文件里只写页面结构和文本内容，比如一个按钮，就写上<button>保存</button>；它长什么样（蓝色背景、圆角、白字）由CSS决定；它点了之后触发什么动作（提交表单、弹出提示、跳转页面）由JavaScript决定。这样做的直接好处就是你改样式的时候不用在几百行HTML代码里翻来翻去，改交互的时候也不用担心破坏布局。
原型项目最精简的目录结构是这样的：
code复制prototype/
├── index.html # 登录页
├── dashboard.html # 首页/工作台
├── order-list.html # 列表页
├── css/
│ └── style.css # 全局样式
├── js/
│ └── common.js # 公共交互逻辑
└── assets/
├── logo.png # 图片资源
└── avatar.jpg
关于CSS和JavaScript的语法，产品经理不需要学得很深，但基础的东西要看得懂。CSS的基本结构是“选择器 + 花括号里的键值对”，比如button { background-color: #1890ff; color: #fff; border-radius: 4px; }，意思就是“所有button标签，背景色用#1890ff，文字颜色用白色，加4像素圆角”。JavaScript的基本能力就是“找到某个元素，给它绑一个事件”，比如点击按钮后弹出一个提示框，代码只需要三行：
javascript复制document.getElementById('saveBtn').addEventListener('click', function() {
alert('保存成功');
});
你不用纠结这三行代码的每一个细节，你只需要知道“id为saveBtn的按钮，在点击时会弹出提示”这个逻辑关系就够了。真要说起来，产品经理学HTML原型的重点根本不在于写代码，而在于用代码表达你的产品方案。代码只是你的表达工具，就像你可以用笔写字，也可以打字，关键是内容是什么。
2.3 本地预览：为什么双击HTML文件经常看不到效果
写好了HTML文件，想马上看看效果，很多人的第一反应是双击文件用浏览器打开。你会发现一个比较尴尬的情况：页面内容能显示，但样式好像没加载，图片也裂了，点击按钮也没反应。很多新手在这里就懵了，以为代码写错了，反复检查也找不到问题。
其实这个问题的根源在于浏览器的安全策略。当你用file://协议直接打开本地文件时，浏览器出于安全考虑，会限制很多事情：比如不能跨文件加载JavaScript模块，不能发起AJAX请求，某些CSS特性也会被限制。这就好比你在家里自己给自己发了一张通行证，到了小区门口保安根本不认。解决的办法是起一个本地HTTP服务，让浏览器通过http://localhost来访问你的页面。
对产品经理来说最友好的方案是用IDE里的Live Server插件，这个后面会详细讲。如果你现在想用最原始的方式快速验证，也可以在HTML文件所在目录打开终端，运行Python自带的一条命令：python -m http.server 8080，然后浏览器访问http://localhost:8080就能看到页面了。Mac和Linux系统自带Python3，Windows用户如果装了IDE一般也有Python环境。这个方法不需要安装任何额外工具，非常推荐应急用。
2.4 交互与数据：用模拟数据把原型做“真”
静态页面只能展示布局，还没有“原型”的感觉。真正的原型一定要能动：点按钮要响应，输入框要能填，列表要有数据。这里我不建议产品经理去整复杂的数据交互方案，什么写后台、连数据库都不需要，用最简单的“硬编码+本地模拟”就足够了。
列表页的数据很好处理。你直接在页面里放上一批写死的模拟数据，比如订单列表，就手写5-8行假的订单记录，字段跟真实系统对齐。这样做的好处特别明显：研发和测试看到的不再是空荡荡的表格，而是数据完整、有各种边界情况的页面。你甚至可以在模拟数据里故意留一条超长文本、一个空值、一项异常状态，提前暴露设计需要容错的地方。
表单页的交互可以用JavaScript做简单的按钮联动和校验。比如你做一个用户注册表单，可以要求“用户名不能为空”“密码长度不能少于6位”，这些校验逻辑用几行JavaScript就能完成。再高级一点，你可以用本地存储（localStorage）把填写的数据保存在浏览器里，刷新页面后数据还在，这样演示给领导看的时候流畅很多。
这里我建议产品经理们花点时间学一下HTML+CSS+JS的基础语法，不只是为了画原型，更是为了建立“网页是怎么跑起来的”这个心智模型。你要画一个登录页面，脑子里得清楚账密是怎么提交的、提交后由谁来验证、验证通过后怎么跳转，这些基础逻辑清楚了，画出来的原型才不悬浮。
3. IDE选型与本地开发环境搭建
3.1 常见IDE横向对比：从编辑器到全功能IDE
写HTML文件用什么工具？理论上记事本都可以，但实际项目中，一个好的IDE能帮你省掉大量的重复劳动。我试过市面上主流的几款，这里以一个“既要写代码又要当产品工具用”的角度做个对比。
Visual Studio Code（简称VS Code）是我目前的主力。它是免费开源的，插件生态极其丰富，启动速度快，内存占用在可接受范围内。做HTML原型这种轻量项目，VS Code完全够用，甚至可以说绰绰有余。它的内置终端可以直接敲Git命令，自带Git图形面板，改了什么文件一目了然。最加分的还是Live Server插件——装完之后，编辑器里右键一下，“Open with Live Server”，浏览器自动打开，而且只要你保存代码，页面就自动刷新。改样式、看效果，整个循环不超过一秒，这个体验是双击打开HTML文件完全没法比的。
如果你有JetBrains全家桶的授权，WebStorm也是很不错的选择。它对前端项目的代码提示、重构能力比VS Code更胜一筹，尤其适合项目规模大、文件多的场景。但WebStorm比较吃内存，我曾在16G内存的机器上跑过，开两个项目就有点喘不过气。而且它是收费软件，虽然功能强，但对只想画原型的 PM 来说，性能有点过剩了。
另外还有两个值得关注的选手：一个是C语言/嵌入式开发圈子常用的传统IDE，比如IAR Embedded Workbench和Eclipse IDE，它们各有各的适用领域，但做Web原型确实不太对口，除非你本来就在用它们做其他开发。另一个是现在很流行的一些AI原生IDE，比如Trae、Curious IDE等，它们把AI编程助手内置在编辑器里，写HTML的时候直接说一句“帮我写一个登录页”，代码就出来了。AI IDE对原型开发来说真的是效率神器，你可以疯狂地“借力”来画页面，但写出来的代码质量要注意检查。
我的建议很明确：如果你只打算学一个工具，选VS Code；如果你预算充足且机器配置够好，可以试WebStorm；如果你喜欢尝鲜而且愿意接受AI辅助编码，Trae这类AI IDE值得一试。工具这个东西说到底是为了提高效率，不要在工具选型上消耗太多决策精力。
3.2 VS Code必装插件：Live Server与基础配置
确定了VS Code之后，有几个插件是画HTML原型必须要装的，缺一个效率都会打折扣。
第一个当然是Live Server。这个插件的原理是在你本地起一个开发服务器，并监听文件变化。你保存代码的一瞬间，服务器会通过WebSocket通知浏览器刷新页面。它的好处不只是“自动刷新”这么简单——由于通过HTTP协议访问，前面说的file://协议带来的各种样式和交互问题都不存在了，页面表现跟真实部署上线后几乎一致。
第二个是Prettier，一个代码格式化工具。你写的HTML缩进可能乱七八糟，标签对不齐，保存的时候Prettier会自动帮你整理成整齐的格式。这个工具还有一层隐藏价值：代码格式统一了，你发给研发看的时候，研发会下意识觉得“这个PM挺专业的”，别问我为什么知道这个细节很重要。
第三个是ESLint，JavaScript代码检查工具。不过这个对纯原型开发是锦上添花，如果原型里没有太多JavaScript逻辑，可以先不装。另外还有一个在线的编辑器，国内有不少在线IDE和代码分享平台，比如Inscode AI IDE，可以在浏览器里直接写代码、预览效果，不用装任何本地环境，对电脑配置差或者临时应急很管用。不过它依赖网络，网络不稳定的时候体验会比较差。
装插件的位置在VS Code左侧边栏的扩展图标里，直接搜索插件名，点安装就完事了。安装完Live Server之后，在HTML文件上右键，选择“Open with Live Server”，浏览器就会自动打开一个http://127.0.0.1:5500/index.html的地址。注意这个地址的端口号不固定，由插件自动分配，不用管它，反正浏览器会自动打开。如果你电脑上有多个项目同时开着Live Server，端口会递增，这也属于正常情况。
3.3 终端基础：IDE里跑命令的正确姿势
在VS Code里，按快捷键Ctrl+`或者通过菜单“终端-新建终端”可以打开一个内置终端窗口。这个终端就是你的命令行面板，后续所有Git操作都可以在这里完成。很多产品经理第一次看到黑乎乎的窗口就发怵，其实你只需要记住别人给你的一条条命令，复制粘贴然后回车就行，不需要背什么命令语法。
需要注意一个小问题：在Windows系统上，VS Code默认的终端可能是PowerShell或者CMD，在Mac上则是自带的zsh。不同终端对命令的支持有一些细微差别，但跑Git命令基本都一样。如果你发现粘贴命令后报错，先看清楚终端标题栏显示的是PowerShell、CMD还是Bash，有些命令在不同终端环境下的写法略有差异。比如设置环境变量、切换目录这些操作，在PowerShell和Bash里的语法就完全不同。好在做原型不太涉及这些高级操作，我暂不展开。
环境搭建到这里就基本齐活了。你有了一个能写代码的编辑器，一个能实时预览的本地服务器，一个能敲命令的终端。下一步就是Git版本管理这块硬骨头了。
4. Git与GitHub：从本地文件到远程仓库
4.1 为什么产品经理也需要懂Git
在做原型的过程中，你会发现文件越来越多，改动越来越频繁，今天加了筛选功能，明天改了表单布局，后天又把登录页的样式推翻重来了。如果你的原型是“一堆文件散落在文件夹里”，最后大概率会陷入文件名已经无法概括内容变更的困境，比如“原型_v2_最终_改动版.html”“原型_v2_最终_改动版2_别改了.html”这种。
而Git的工作方式，是在一个项目目录里建立一个版本仓库，记录每一次文件改动。每次你改完一段工作、确定了“这个版本可以作为一个里程碑”，就执行一次提交（commit），相当于给当前所有文件拍了一张快照。以后任何时候，你都可以回退到任何一个历史快照，再也不用担心改坏了没得后悔。
Git是分布式的，意味着每个参与者的电脑上都有完整的版本历史。对产品团队的场景来说，这就意味着多个同事可以克隆同一个原型项目，各自修改，再合并到一起。虽然产品经理画原型一般是单兵作战，但有一个场景非常管用：UI设计师看了你的原型之后，想在上面调整一些视觉样式，他可以直接基于你的仓库修改，然后把改动推回来。你再看他的改动时，能清楚地看到“改了哪些文件、改了什么内容”，不会出现“他说改了但我不知道改了啥”的问题。
4.2 Git安装与首次配置：一步一步来
Git的使用分两步：先装客户端，再跑命令。Windows用户去Git官网下载安装包，一路默认下一步就行，唯一需要注意是安装过程中选择“调整PATH环境变量”时，选默认的“Git from the command line and also from 3rd-party software”，这样VS Code终端里才能直接用Git命令。Mac用户一般在终端输入git --version，系统会提示安装命令行开发者工具，按提示操作即可，或者直接安装第三方GUI工具。
装好之后先做一次全局配置，告诉Git“你是谁”，以后每次提交的时候Git会把这个信息一并记录。在终端里执行：
bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
我见过很多人跳过了这一步，后面提交代码时会报错，提示“Please tell me who you are”，其实就是没做这个配置。这两个命令里的名字和邮箱，建议用你注册GitHub时的信息，这样提交记录里会自动关联到你GitHub的账号，看起来更整齐。
如果你是Windows用户，后面在GitHub上提交代码时可能会反复弹出窗口让你输用户名密码，甚至让你选“达成的授权方式”。推荐的做法是用GitHub官方推出的命令行工具“GitHub CLI”来登录，一次授权搞定后续所有操作，比手动配SSH密钥简单太多。macOS里用brew install gh安装，Windows用官方安装包装，然后执行gh auth login，按提示在浏览器里授权一次就完事。
4.3 初始化仓库到首次推送：核心命令全解
现在假设你的原型项目已经写了一个初版，我们要把这个项目变成Git仓库。在VS Code里打开项目文件夹，打开终端，按顺序执行下面这些命令：
bash复制# 初始化仓库，把当前文件夹变成Git项目
git init
# 把当前文件夹下所有文件加入待提交区
git add .
# 提交，-m参数后面写的是本次提交的说明
git commit -m "初始化原型：登录页+首页+列表页"
# 将主分支改名为main，这是GitHub默认的推荐分支名
git branch -M main
到这里，本地仓库就算建好了。你已经能看到一条提交记录，如果想确认，可以执行git log --oneline，会列出所有历史提交。产品经理一定养成的习惯是：每完成一个功能节点的调整就提交一次，提交说明里写清楚“改了什么、为什么改”。哪怕以后不推送到GitHub，本地用这个习惯管理原型版本，都已经值回票价了。
接下来要跟GitHub建立连接。如果你没有GitHub账号，先去官网注册，用户名和密码要记住。注册时你会遇到一个经典的验证环节——可能需要识别验证码。这是正常流程，选择合适的选项点掉即可，不需要额外安装任何辅助工具。完成注册后，登录你的账号，在右上角加号里选择“New repository”，创建一个新仓库。仓库名建议跟项目名一致，比如pm-prototype，可见性可以选私有（Private）或公开（Public），原型项目不想被搜索引擎收录就选私有，想公开分享就选公开。创建时可以选择“Add a README file”，这样仓库会有一个初始说明文件，推荐加上。
仓库创建好之后，它会给出一段提示命令，大致是：
bash复制git remote add origin https://github.com/你的用户名/pm-prototype.git
git branch -M main
git push -u origin main
把这三行复制到终端里执行，你的代码就被推送到了GitHub。第一次执行git push的时候，GitHub可能会要求授权，按提示在浏览器登录账号并批准即可。推送成功之后，刷新GitHub仓库页面，你的HTML文件就已经躺在远程服务器上了。
4.4 GitHub仓库管理：常见浏览与下载方式
代码推送上去之后，你和团队同事都可以在GitHub网页上查看文件。点击仓库里的HTML文件，GitHub会直接渲染并显示文件内容，虽然不是特别美观，但确认文件是否正确上传非常方便。需要注意一点：GitHub网页上的代码查看器只是展示源码，不是预览页面效果。想看效果要部署成网站才行，这就引出了下一章的GitHub Pages。
另一种常见需求是下载别人的代码仓库。在GitHub仓库页面，点绿色“Code”按钮，选择“Download ZIP”就能把整个项目打包下载。不过这里要提醒一个常见的痛点：如果仓库文件很多很大，直接下载ZIP可能会很慢甚至经常失败，尤其是一些大型开源项目。这时候一个更可靠的方式是用Git命令来克隆整个仓库，命令是git clone 仓库地址。虽然第一次克隆也要下载全部数据，但在网络正常情况下，Git传输的稳定性通常比浏览器下载要好。
还有一个问题在团队内部经常会遇到：不是所有人都注册了GitHub账号，或者同事不想用Git。针对这种情况，最粗暴的方式是直接下载ZIP包发到群里，或者用网盘分享。但如果你想保持一条规范的协作流程，建议还是让大家各自注册账号，在仓库设置里增加协作者权限。GitHub免费版就支持给仓库添加协作者，数量限制对一般团队绰绰有余。
5. GitHub Pages公网部署：让原型一键上线
5.1 GitHub Pages的原理和核心优势
看到这里，你已经有了一个托管在GitHub上的原型仓库。但这一步只解决了“代码存起来”的问题，距离“公网访问”还差最后一步。GitHub Pages就是GitHub提供的一项免费静态网站托管服务，它会把你的仓库里某个分支、某个目录里的文件直接变成一个可以被公网访问的网站，网址格式类似于https://你的用户名.github.io/仓库名/。
这个服务的原理并不复杂：本质上是GitHub的服务器帮你跑了一个静态文件服务器，你上传HTML、CSS、JS文件，它按时提供访问。它不需要你配置任何后端环境，不需要买域名，也不需要备案。对于纯静态的HTML原型来说，这简直是量身定制的方案。产品经理做的原型页面恰好就是纯静态文件，不需要数据库、不需要登录鉴权（演示用的假登录除外），所以跟GitHub Pages是绝配。
它的另一大优势是免费且稳定。个人用户创建一个公开仓库然后开启Pages服务，流量和带宽都不收费。对于日常给团队评审、给领导汇报、甚至给客户做演示的场景，这个量级完全足够。你只需要在演示前确认页面能打开，完全不用担心服务挂掉这种问题。反观自己买服务器部署，不仅花钱还要操心运维，对原型交付来说完全是杀鸡用牛刀。
5.2 部署方式选择：三种路径对比
同一个目标——让原型上线公网——有三条路径可以实现，我一一对比，大家按自己的实际情况选。
第一条路径是用gh命令行自动发布，也是最推荐的方式。在GitHub CLI工具已经登录的情况下，执行一条命令gh repo create --source=. --public --push就能把本地仓库推送到GitHub并创建远程仓库。之后在仓库设置界面开启Pages，选择分支为main，保存后等一两分钟，公网链接就生效了。这个方式的优点是省事，缺点是你需要理解命令行的逻辑。
第二条路径是网页端手动操作，适合不习惯命令行的产品经理。代码推送成功后，登录GitHub，进入仓库页面，点击顶部的“Settings”，在左侧菜单里找到“Pages”，在“Branch”下拉框里选择main分支，点击“Save”，页面刷新后会出现一个“Your site is live at”的提示，里面就是你的公网地址。这条路径全程在图形界面完成，是我最推荐新手先尝试的。
第三条路径是用第三方静态托管平台。这个方案在很多场景下作为GitHub访问不便时的备用选项，值得了解。有一些提供静态网页托管的平台（比如Gitee Pages、Netlify、Vercel等）支持从GitHub仓库自动拉取代码并发布。其中Netlify是很多国外开发者都在用的方案，它支持连接你的GitHub仓库，检测到代码更新就自动触发构建和部署。这条路径的优势是构建过程更可控，还可以设置自定义域名、HTTPS证书等，但对纯原型交付来说功能有点溢出。
三条路径选哪条都行，我个人的建议是：自己用，追求效率，选第一条；帮同事演示、教学场景，选第二条，因为图形界面更加直观；后面做进阶版本演示且想要个性化域名，再考虑第三条。
5.3 从零到一：三条路径的实操步骤全解
先看第一条，命令行发布。前提是已经安装了gh工具并且通过了gh auth login授权。在你本地项目的根目录终端里：
bash复制# 创建远程仓库并推送代码
gh repo create pm-prototype --public --source=. --push
执行完后，命令会在GitHub上创建一个名为pm-prototype的公开仓库，同时把本地的Git记录推过去。这一步做完，其实你的远程仓库已经可用了。接下来的Pages开启步骤，因为gh命令本身按设置方式有不同参数细节，手册里先不展开，推荐方式是用网页端操作，也就是第二条路径。
第二条路径的完整步骤如下。进到GitHub仓库页面，依次执行：
- 点击“Settings”进入仓库设置；
- 左侧菜单找到“Pages”；
- 在“Source”区域的下拉框里选择“Deploy from a branch”，Branch下拉框选择
main，背后目录默认/ (root)，点击Save保存； - 页面顶部出现一个蓝色提示条，显示站点的制作进度；
- 刷新等1-2分钟，如果提示条变成绿色，说明部署完成，里面显示的就是你的公网访问链接；
- 把这个链接发给同事，用浏览器打开，就能看到和本地Live Server里一致的原型页面。
第三条路径以保存到桌面之类的场景来举例。假设你从GitHub仓库下载了一个开源项目，想要快速预览效果，可以直接用Netlify的Drop功能。打开Netlify官网，把整个文件夹拖到网站指定区域，它会自动帮你完成上传和部署，几秒后就能生成一个临时公网链接。这个方式不需要Git、不需要命令行，部署完还能绑定自定义域名，唯一的限制是免费版的构建次数和带宽有限制，但对原型演示足够。
5.4 部署后的预览与闭环验证
部署完成后，一定要做一轮完整的闭环验证，这个习惯我从做第一个在线原型时就养成了。首先检查页面在任何浏览器模式下能正常打开，建议用无痕模式/隐身模式打开链接，排除浏览器缓存的干扰。接着对照需求清单，逐一点击所有能点的按钮，确认交互逻辑没有因为部署环境变化而出错。最后用手机打开一次链接，确认移动端的显示效果是否可接受。
部署环境变化导致的问题，最常见的是两个：一个是资源文件的路径错误。如果你在HTML里引用了src="./assets/logo.png"这类相对路径，在GitHub Pages的仓库页目录下可能会失效。这时候需要把路径改成相对于项目根目录的形式，或者用/仓库名/前缀来引用。另一个是浏览器缓存问题，修改了代码后推送上去，用户浏览器可能还显示旧版本。解决办法是在样式或脚本文件后面加版本参数，比如style.css?v=2，每次改动就换数字，强制浏览器重新拉取。
还有一个细节：GitHub Pages的仓库名是用户名.github.io这种形式时，站点的访问根路径是https://用户名.github.io/，不需要带仓库名后缀。如果你的仓库名是普通项目名如pm-prototype，则访问路径是https://用户名.github.io/pm-prototype/。这个区别会影响你内部引用的路径计算，尤其是相对路径写法的开发同行们，很容易在这里栽跟头。
6. 常见问题与排查技巧实录
6.1 GitHub访问问题：最常见的情况与合法处理方式
在写这篇手册的过程中，GitHub访问问题是被问得最多的。访问GitHub官网时，页面上部分资源（尤其是图片、样式表）偶尔加载缓慢，或者打开很迟钝，这种情况在不同地区、不同运营商网络下都可能发生。造成问题的原因可能很复杂，包括国际网络环境、CDN节点调度等，但作为产品经理，你只需要关注两个核心影响：一是网页能不能打开、能不能完成注册和仓库操作，二是Git命令推送代码是否正常。
如果是网页能打开但偶尔缓慢，那不是致命问题，稍微等一下或者刷新几次通常就能继续操作。如果是你所在的网络环境对GitHub页面访问不稳定，导致网页动作频繁失败，我建议你优先尝试正常的技术手段排查：先检查自身的网络连接是否正常，重启路由器、换一个网络环境（比如用手机热点）试一下，或者参考官方文档做DNS排查。nslookup github.com这个命令可以查看DNS解析是否正常，帮你确认到底是网络问题还是DNS问题。
还有两个国内可以直接使用的替代方案值得了解。一个是Gitee（码云），这是国内最大的代码托管平台，界面和GitHub高度类似，支持从GitHub一键导入仓库，如果你的团队主力都在国内，把原型仓库放在Gitee上协作效率会高很多。另一个是GitCode等国内代码托管平台，提供的服务大同小异。这些平台同样支持Pages功能部署静态网页，只是具体的开启方式略有差异。
这里我要特别强调一个红线问题：不要在搜索引擎里搜索任何声称能“加速”或“突破”GitHub访问的工具，更不要下载和安装来路不明的“加速器”。这类工具通常来源不明、安全性毫无保障，轻则盗取你的账号密码，重则让你的电脑沦为矿机或肉鸡。你并不需要它们——正常网络环境下，注册、推送、开启Pages这些操作都能完成。万一遇到网络不稳定，换个时间再试一次往往就通了。宁可多花几分钟重试，也别拿账号安全开玩笑。
6.2 页面部署后样式全乱：路径和缓存排查
部署完原型，打开公网链接，发现页面跟本地长得完全不一样：背景色没了、图片裂了、字体不对。这个情况我在早期做项目时遇到过无数次，每一次的原因基本都在两类里。
第一类是路径问题。写代码时习惯用的是相对路径（比如./css/style.css），但在GitHub Pages里，你的项目是挂在/仓库名/这个子路径下的，浏览器解析相对路径时，会先拼上这个子路径，然后一路找下去。如果你的HTML在根目录而CSS在子目录，相对路径写法../很容易计算出错。排查方法是按F12打开浏览器开发者工具，切到“Console”和“Network”面板，看有哪些文件请求返回了404。看到404就说明路径不对，把HTML里的引用路径改为/仓库名/css/style.css这种绝对路径形式，或者用./开头并确认目录层级正确，问题就能解决。
第二类是缓存问题。浏览器会缓存CSS和JS文件，你修改了代码重新推送，但浏览器可能还在用旧版本。最直接的验证方式是在公网链接后面加上查询参数，比如?v=2，看到页面恢复就说明是缓存问题。长期的解决方案是每次改动后修改引用参数版本号，或者告诉同事强制刷新（Windows按Ctrl+F5，Mac按Cmd+Shift+R）。
6.3 本地页面正常但部署后页面空白：控制台查错法门
还有一种特别容易让人崩溃的情况：本地Live Server预览一切正常，部署到GitHub Pages后打开却是白屏。遇到这种情况，第一直觉不要怀疑部署步骤，而是打开浏览器的开发者工具看Console面板里的报错信息。
HTML原型最常见的白屏原因有三个。第一个是JavaScript报错中断了某个流程。比如你在页面上用了fetch请求一个不存在的本地JSON文件，这个请求在本地能正常返回但在Pages上的路径不对，浏览器就会在Console里报错。排查方法是逐个查看Console里的红色报错信息，把对应代码修正后重新部署。
第二个是ES6模块加载失败。如果你在HTML里用<script type="module">引入了JavaScript模块，那么这些文件必须通过HTTP协议加载，file://协议下会直接失败，部署到Pages上如果路径计算错了同样会失败。第三种是某些浏览器特性在HTTPS环境下被拦截。GitHub Pages默认启用HTTPS，如果你的代码里引用了http://开头的图片或外部资源，浏览器会将其拦截，导致页面看起来“缺东西”。这些报错信息在Console面板里都会明确提示，养成“先看Console再猜原因”的习惯，能节省大量排查时间。
6.4 其他部署方案对比：宝塔面板、Gitee Pages等
GitHub Pages虽然香，但不是银弹。有些场景下你需要考虑其他的部署方案，这里把主流的几个拉出来对比一下，免得你选错了路白折腾。
宝塔面板是目前国内使用非常广泛的服务器管理面板，之前的热搜词里也有“宝塔面板公网部署SpringBoot3+Vue3项目”。它的定位是完全不同的：你需要在云服务商买一台服务器，在服务器上安装宝塔面板，再通过面板部署Nginx、MySQL、Java等环境，最后把前端项目打包上传、配置站点。这一套流程跑通之后，你的原型可以拥有独立的公网IP和域名，也可以部署后端服务，做成一个真正能登录、能操作数据的完整系统。但代价就是你得懂服务器运维的基础知识：要管理安全性、配置SSL证书、备份数据库等，这对只是画原型的产品经理来说，投入产出比实在太低。一句话总结：原型部署用宝塔，跟开着卡车去买菜差不多。
Gitee Pages是Gitee（码云）推出的静态网站托管服务，操作路径跟GitHub Pages几乎一样，优点是访问速度快得多，毕竟服务器在国内。它的问题是审核更严格，而且免费版的Pages服务有实名认证的要求，有的用户可能受此限制。如果你在国内团队协作、GitHub访问始终不方便，把代码推到Gitee再开启Pages确实是一个很实际的替代方案。
另一个方案是用Netlify、Vercel这样的国际化平台。这类平台对纯静态网站的部署体验堪称完美：直接连接你的GitHub仓库，代码更新后自动构建和发布，自带CDN、HTTPS、自定义域名。但它们的缺点是界面全英文，而且国内访问不一定比GitHub Pages更快。你自己权衡，如果团队都在国外或你习惯英文界面，它们也是好选择。
6.5 实用小技巧：自动部署、文件管理与协作提示
最后分享几个我从实战中沉淀下来的小技巧，每一个看起来不起眼，但都实实在在帮我省下了时间。
第一，用GitHub Actions自动部署。GitHub Pages其实不止支持从main分支直接发布文件，还支持通过GitHub Actions来做自动化构建。什么意思呢？你可以在仓库里放一个工作流文件（.github/workflows/deploy.yml），在文件里定义“当代码推送到main分支时，自动执行指定命令然后发布到Pages”。这个能力对纯静态原型来说有点超前，但如果你在原型里用了构建工具（比如Vue.js、Sass），那就必须用Actions才能在Pages上跑出来。补一句，GitHub对自动构建有免费时长配额，个人免费版完全够用。
第二，把原型项目做成模板仓库。在GitHub上创建仓库时，有一个“Template repository”选项，开启后别人可以一键复制成一个新项目，自带你准备好的目录结构和基础样式。如果你所在的产品团队经常要新起原型项目，把公共组件、常用样式、目录骨架打好包做成模板，每个新项目直接套用，效率能提升一大截。
第三，给团队做演示时，把多个版本的原型放在同一个仓库的多个分支里。比如main分支放稳定版，dev分支放开发中版本。需要看旧版时，直接在分支之间切换，Git会自动帮你替换文件。这个操作在VS Code的源代码管理面板里点一下分支名就能切换，不需要记命令。比你在本地存一堆“最终版”“最终版2”文件夹干净一百倍。
第四，关于文件命名的经验。HTML原型的文件名尽量用英文小写加连字符，比如order-list.html、login.html，不要用中文文件名，也不要用大写字母。中文文件名在有些服务器上可能会编码出错，大写和混写在后期部署到Linux类环境时可能引起莫名其妙的404。这个习惯从第一天就养成，后面能少踩很多坑。
7. 实操复盘与推进建议
7.1 从原型到项目：给产品经理的额外能力建议
原型只是起点，不是终点。当你把HTML原型完整跑通之后，我强烈建议你往前再走两步。第一步是学一点响应式布局的概念。现在很多产品都有PC端和移动端两个形态，如果原型页面的布局只能固定宽度，后续做移动端适配就要重新画一遍。与其到时候重做，不如从一开始就用一套简单的响应式框架（比如Bootstrap或者Tailwind CSS）来打底。这些框架并不难学，只需要理解“栅格系统”和“断点”这两个概念，就能写出在手机和电脑上都能自适应展示的页面。
第二步是学会使用UI组件库。B端产品经理画原型时，最大的痛点是页面里的表格、表单、弹窗、下拉选择器这些组件画起来费时费力。如果你直接用现成的UI组件库（比如Ant Design、Element UI），把组件往页面里一放，改一改文字和字段，一个符合团队常用设计风格的原型页面十几分钟就能拼出来。这比在Axure里拖控件、写交互逻辑不知道快了多少倍。
我还想建议你多看一些优秀的开源项目。GitHub上有几万个产品经理可以直接参考的模板和项目，比如各式各样的后台管理系统模板。你在做方案遇到“这个页面该怎么设计”的卡点，去翻一翻同类开源产品，往往能找到现成的答案。注意不要把人家代码拿来直接用就好，毕竟你的目标是学思路，不是搬运。
7.2 我在实际使用中的几个心得
写到这里，这套方法我已经用了将近五年。每次带新人走完这一整条链路，我都能看到他们脸上的那种“打开新世界”的表情。说几个我在真实项目里沉淀下来的心得，供大家参考。
第一，HTML原型的关键不是“像”，而是“真”。很多产品经理把精力花在美化页面上，试图让原型看起来像一个完成品，这其实跑偏了。原型最重要的价值是验证逻辑、对齐认知，只要信息层级清楚、交互流程完整、数据边界可见，哪怕样式朴素一点，研发和测试也完全能看懂。相反，如果你花了一整天调阴影和圆角，反而容易让人把注意力放在视觉上，忽略了业务本身的漏洞。
第二，Git和GitHub这套工具，越早用越好。我刚开始做原型时也没用Git，总觉得“文件没多少，没必要”。等到有一次不小心覆盖了一个重要版本，才追悔莫及。从那以后我所有的原型项目都全程用Git管理。哪怕你还没有团队协作的需求，也可以把版本管理当作自己的时间胶囊，它记录的不只是文件，更是你产品方案演化思考的过程。
第三，公网部署的能力带来的不只是便利，还有影响力的提升。你做一个产品方案，别人还在发PDF、发截图，你直接甩一个链接，打开就能点、就能用，这个信息差本身就让你在评审中占据了主动。尤其在跨部门协作、客户演示、远程办公的场景下，一个稳定的公网链接比任何描述都更有说服力。有时候我也把这个链接直接发给研发做排期预估，研发打开页面点一遍功能，提交工时评估的效率明显比看文档高很多。
最后再分享一个很小的技巧：在HTML原型里加一个简单的导航页作为入口。把系统里所有页面列成一个目录，每个页面配一个链接，这样演示的时候不用挨个输入网址，打开导航页点一下就跳到对应页面。这个导航页还能承担“版本说明”的功能，把每次更新的核心内容和日期写在上面，团队打开链接最先看到的就是这一版“改了哪儿”。这个小改动成本只有十几分钟，但体验提升非常明显，强烈建议大家试试。
这一整套从IDE到GitHub公网部署的流程，归纳起来就是“一次搭建、一路复用”。第一次走通它你可能需要一个下午，但从第二天开始，你只需要在原地复用这套流程。工具链的意义从来都不是让你花更多时间在工具上，而是把工具花掉的时间，从未来的每一天里成千上万倍地赚回来。