产品经理手写HTML原型：从IDE到GitHub Pages公网部署全流程

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操作和部署环节，这几块是真正拉开效率差距的地方。我跟你讲，同一个原型项目，用对了工具链的人半小时就能完成部署，用不对的人可能卡在某个报错上一整天——差别真的就这么大。

整个手册里我不搞任何云里雾里的概念，所有操作都在一个最简单的静态网页项目上展开。先写一个包含登录页、首页、列表页的迷你原型系统，然后一步步把它推到公网。这个过程走通了，以后你换任何项目都只是复用同样的流程而已。

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像素圆角”。Jav