Article
一、从简单的项目开始
上一篇（一）我们理清了基础概念——前端/后端/数据库的分工、框架和组件库、AI 工具选择，还简单提了一下 PRD 和 Vibe Coding 的核心技巧。
但概念终究是概念。
“道理我都懂，但打开电脑还是不知道第一步干什么。” 这种感觉太正常了。知道 HTML 是结构，不代表你能用它做出东西；知道 PRD 是项目说明书，不代表你会写。
所以这一篇，我们来讲讲实例。
本篇以一个真实项目 rico-md（Star 160 公众号排版编辑器 md.ricoui.com）为主线，从”为什么选这个项目”开始，讲到”怎么写 PRD”、“怎么用 PRD 控制 AI”、“怎么优化设计”，带你走完一个完整的 Vibe Coding 流程。
图：rico-md 编辑器界面
本篇不需要一次性看完，可以在看完每个大节后停下来消化，有条件的话打开项目对照着看。
先看一眼我们接下来要走的完整路线：
选技术栈 → Fork / 下载项目 → 写 PRD → 重构项目 → 分步开发 → DESIGN.md 优化设计 → 部署上线
图：从想法到上线的开发流程
每个环节都会展开讲。不着急，一步步来。
二、前置准备
在进入案例之前，有几件事需要提前准备好。
如果你已经有 GitHub 账号和基本操作经验，可以快速浏览本节后跳到第三节。
2.1 注册 GitHub
GitHub 是代码托管平台，可以理解成”代码的网盘”。你不需要精通 Git 命令，但需要有一个 GitHub 账号，用来：
- Fork（复制）别人的开源项目到自己的账号下，不用担心改坏原项目
- 保存你的修改，每次改动都有记录，随时可以回退
- 部署上线，很多部署平台可以直接读取 GitHub 仓库
注册很简单：打开 github.com，用邮箱注册即可。
2.2 Fork 项目
Fork 就是把别人的项目复制一份到你自己的账号下。之后的任何修改都是在你的副本上操作，不会影响原项目。
操作方式：打开项目页面 → 右上角点击 Fork → 确认即可。
2.3 下载项目到本地
最简单的方式：在项目页面点击绿色的 Code 按钮，选择 Download ZIP，解压到你想要的目录。
如果你熟悉 Git，也可以用命令行：
git clone https://github.com/你的用户名/rico-md.git
cd rico-md2.4 本地启动项目
rico-md 是纯前端项目，不需要安装任何依赖。三种启动方式任选：
方式一：让 AI 帮你启动
如果你用的是 TRAE / Qcoder 等 IDE，直接打开项目文件夹，然后对 AI 说”帮我把这个项目跑起来”，AI 会自动检测环境并启动。
方式二：用 IDE 插件 “Go Live”
在 IDE 插件面板找到 “Go Live”，安装后点击右下角启动即可。
方式三：命令行启动
./start.sh或用 Python：
python -m http.server 8080然后浏览器打开 http://localhost:8080。（Mac 自带 Python，Windows 去 python.org 下载安装）
2.5 选择 AI 编程工具
这一篇的操作演示中，我自己使用的是 VS Code + Codex/Claude Code 插件 的使用方式，但你可以选择任意 AI 工具——Cursor、Claude Code、TRAE、Kimi 都可以。核心流程是一样的：打开项目 → 描述需求 → AI 修改代码 → 查看效果。
选择一个你顺手的工具就好，工具之间的差异远没有”开始动手”这件事重要。
三、从案例认识技术栈
在正式动手之前，先用两个案例帮你建立对”技术栈”的直觉——从最简单的静态网页，到本篇的主线实战项目，感受一下不同复杂度的项目分别对应什么技术方案。
3.1 最简单的起点：一个静态网页
先看一个最简单的例子。
HTML+CSS+JS，这是最基础的网页技术组合。你发给豆包、Gemini、Kimi 等生成网页，大部分输出的就是这样的 HTML 页面，直接放到浏览器就可以打开。
这个单页是我用 Blender 做了一套开源图标，为了方便预览就顺带做了个网页，功能和目标很简单：展示和下载资产库。
- 访问：https://valentine.uiineed.com
- 仓库：https://github.com/ricocc/free-3d-valentines-assets
- 技术栈： HTML+CSS+JS, 自由落体效果使用 Matter.js 库
这个是以前我手写的，代码很简单。现在用 AI 的话，核心就是告诉 AI 你想要自由落体的效果，或者直接指定用 Matter.js 来开发，图片给它即可。这个页面有价值的是设计想法，这也是设计师的优势所在。
一个小经验： 如果你的需求只是一个好看的展示页面——无论视觉多复杂、交互多有意思，只要不涉及权限、内容管理、登录注册等数据处理——那么 HTML+CSS+JS 就是最适合你启动的第一版方案。先把想法变成一个能看的东西出来，比什么都重要。
3.2 本篇主线案例：rico-md 公众号排版编辑器
接下来进入本篇的重头戏。我会以 rico-md 这个真实项目为案例，带你走完一次完整的 Vibe Coding 流程。
- 在线地址：md.ricoui.com
- 仓库地址：github.com/ricocc/rico-md
rico-md 是一个面向微信公众号写作与排版的纯前端 Markdown 编辑器。它是我从花生的开源项目 huasheng_editor Fork 过来，然后通过 Vibe Coding 进行全面改造的。
当前开发完成的 rico-md 的核心功能：
- 编辑与预览：左侧 Markdown 编辑，右侧实时预览；支持桌面/iPad/手机预览模式切换
- 文档管理：多文档创建、切换、复制、删除；文档搜索；自动保存与状态显示
- 主题系统：20 套公众号正文主题（按风格分类）+ 16 套独立代码块主题
- 图片处理：粘贴/拖拽/上传 → Canvas 压缩 → IndexedDB 持久化 → 复制时自动转 Base64
- 公式渲染：预览用 KaTeX，复制到公众号时转 MathJax SVG
- 导出与复制：导出 Markdown / HTML；一键复制到公众号和 X
技术栈：Vue 3（CDN）+ markdown-it + highlight.js + IndexedDB + 原生 CSS
关键概念：IndexedDB（浏览器端本地数据库，存储大文件如图片）、img://（自定义图片协议，映射 IndexedDB 中的图片）、KaTeX / MathJax（公式渲染库，前者轻量适合预览，后者兼容公众号）
为什么选它做教程案例？ 因为它非常典型——从一个已有的开源项目出发，通过写 PRD 明确目标，用 AI 工具逐步改造，最终变成一个完全适合自己的工具。这恰好是大多数设计师接触 Vibe Coding 时最可能走的路径。
开发路径总览：
- 事前写 PRD（产品定位，核心功能，边界约束，体验要求，验收）
- 项目重构（按照开发原则拆分和重构项目）
- 分步增加功能页面和测试
- 优化设计和交互
3.3 为什么选择在旧项目基础上改造
回到技术栈选择的问题。当初我需要一个公众号排版工具，市面上的选择要么太复杂，要么功能不够。
花生的 huasheng_editor 刚好满足几个条件：
- 纯前端，零构建：CDN 引入 Vue，不需要安装 Node.js、不需要 npm install、不需要配置任何环境。双击
index.html或者用 Python 起一个本地服务器就能跑 - 单文件架构：虽然这意味着代码不够模块化，但对零基础来说，理解一个文件比理解几十个文件容易得多
- 功能方向对：Markdown 编辑 + 实时预览 + 一键复制到公众号，核心路径已经跑通
- 优化空间大：同样是 Vibe Coding 项目，优缺点明显，有很大的优化空间
选技术栈的第一步，不是找”最好的方案”，而是找”最合适的起点”。 花生的项目就是一个好起点——功能方向对、技术门槛低、可以立刻上手改。
四、实战改造：从 PRD 到功能开发
4.1 先认识项目文档：从 PRD.md 开始
在 Vibe Coding 里，文档的作用不是“写给自己看的说明书”，而是让 AI 快速理解项目状态、目标和边界。
对新手来说，最重要的一份文档是 PRD.md。
它主要解决三个问题：
| 文档 | 作用 |
|---|---|
| PRD.md | 说明项目要做什么、不做什么、做到什么程度 |
| DESIGN.md | 说明界面应该做成什么样 |
| CLAUDE.md / AGENTS.md | 可选，用来给特定 AI 工具补充项目上下文 |
如果你刚开始做项目，不需要一上来就准备很多文档。先写好 PRD.md 就够了。
随着项目变复杂，再补充其他文档：
- 使用 Claude Code，可以维护
CLAUDE.md - 使用 Codex 等 Agent 工具，可以维护
AGENTS.md - 做 UI 优化时，再补充
DESIGN.md
这些文档真正的价值在于：记录项目的真实状态。
当你开启新的 AI 对话时，它可以通过这些文档快速知道当前项目是什么、已经做了什么、哪些地方不能乱改。
4.2 打地基：先把项目结构理顺
花生的原版项目很简单，主要是一个 index.html 加一个 app.js。这对新手来说好理解，但功能一多，问题也很明显：所有逻辑都堆在一个文件里，AI 每次修改都要重新理解整段代码，后面很容易越改越乱。
所以起手不是加功能，而是先让 AI 做一次结构梳理。
你可以直接这样说：
遵循工程化最佳实践，对当前项目进行代码解耦重构。不要改变现有功能，只整理结构，让后续功能更容易维护。
重构后的重点不是“文件夹看起来更专业”，而是让每一类功能有自己的位置。
重构之后，我们得到现有项目优化后的结构：
├── index.html # 主页面（编辑器）
├── README.md
├── start.sh # 一键启动脚本
├── assets/
└── js/
├── core/
│ ├── config.js
│ ├── storage-adapter.js
│ ├── image-store.js
│ ├── image-compressor.js
│ ├── image-host-manager.js
│ └── markdown-utils.js
└── services/
└── content-transformers.js这一步做完后，AI 再修改功能时就更容易定位。比如要改图片上传，它会去找图片处理模块；要改主题面板，它会去看 UI 和样式文件，而不是每次都在一个大文件里乱翻。
而下面是我们最终开发完成的文件结构：
rico-md/
├── index.html # 主页面（编辑器）
├── about.html # 关于页面
├── README.md
├── start.sh # 一键启动脚本
├── assets/
│ ├── images/ # 图片资源
│ ├── scripts/
│ │ ├── main.js # 应用入口（状态管理、文档管理、交互）
│ │ ├── core/ # 核心模块
│ │ │ ├── image-compressor.js # 图片压缩
│ │ │ ├── image-store.js # IndexedDB 图片存储
│ │ │ ├── markdown-engine.js # Markdown 渲染引擎
│ │ │ ├── paste-handler.js # 粘贴处理
│ │ │ └── render-pipeline.js # 渲染流水线
│ │ ├── export/
│ │ │ └── clipboard-exporter.js # 复制到公众号
│ │ ├── storage/
│ │ │ └── preferences.js # 本地偏好存储
│ │ └── ui/
│ │ ├── code-themes.js # 代码块主题
│ │ ├── panel-manager.js # 面板管理
│ │ ├── theme-manager.js # 正文主题
│ │ └── toast.js # 提示组件
│ └── styles/
│ ├── base.css # 基础样式
│ ├── editor.css # 编辑器样式
│ ├── panel.css # 面板样式
│ └── themes/ # 主题定义文件
└── docs/ # 📄 项目文档（重点！）
├── PRD.md # 产品需求文档
├── CLAUDE.md # Claude 协作文档
├── AGENTS.md # AI 代理约束
└── CONTRIBUTING.md # 贡献指南这其实就是拆分组件的思维，不要觉得复杂，拆分和梳理是 AI 做的事，你只需要给明确的命令。
这一步我们做到了什么？把原来的单文件 app.js 拆分为 core/（核心模块）、export/（导出模块）、storage/（存储模块）、ui/（界面模块）等独立目录，每个模块职责清晰，AI 易读。
4.3 建立 PRD 文档
PRD 不需要写得像公司里的正式需求文档。对 Vibe Coding 来说，它的作用很直接：让 AI 知道这个项目是什么、现在做到哪一步、哪些地方不能乱改。
一份够用的 PRD，可以先包含这几个部分：
1. 产品定位
2. 核心能力
3. 技术实现说明
4. 产品约束
5. 关键体验要求
6. 实现边界
7. 验收标准
8. 迭代记录
9. Todo 与后续规划下面用 rico-md 的真实 PRD 拆开讲。你不用照抄格式，重点是理解每一部分解决什么问题。
第一步：产品定位——一句话说清楚”这个东西是什么”
## 1. 产品定位
Rico MD 是一个面向微信公众号写作与排版的纯前端 Markdown 编辑器。
核心目标有三件事：
1. 让用户能高效完成长文写作与排版。
2. 让预览结果尽量接近最终粘贴到公众号后台后的效果。
3. 在不依赖后端和构建系统的前提下，保证本地可用、可保存、可导出。
图：先用产品定位说清楚项目是什么、不做什么
这里最重要的不是句子写得多漂亮，而是把使用场景和技术边界说清楚。“面向微信公众号”限定了场景，“纯前端”“不依赖后端和构建系统”则告诉 AI：后续不要为了实现功能擅自引入服务端或构建流程。
关键技巧：产品定位里要包含”不做什么”的信息，这和”做什么”一样重要。
第二步：核心能力——列出当前已经有的功能
## 2. 当前核心能力
### 编辑与预览
- 左侧 Markdown 编辑，右侧实时预览
- 支持桌面 / 手机预览模式切换
- 支持常用工具栏操作：标题、加粗/斜体/下划线、链接、代码等
### 文档管理
- 多文档创建、切换、复制、删除
- 文档搜索、独立文档标题输入
- 自动保存与保存状态显示
- 本地持久化恢复
### 主题与排版
- 多套公众号正文主题（当前 20 套）
- 独立代码块主题（当前 16 套）
### 图片处理
- 支持粘贴、拖拽、上传图片
- 图片压缩后存入 IndexedDB
- 复制到公众号时自动转为 Base64
### 导出与复制
- 导出 Markdown / HTML
- 一键复制到公众号
图：核心能力只写当前已经实现的功能
这一节只写“现在已经有什么”，不要把未来计划混进去。AI 看到这些内容后，才能判断新需求和现有功能的关系，避免重复实现或改坏已有流程。
关键技巧：核心能力按模块分组，让 AI 能快速定位”这个功能属于哪个模块”。
第三步：产品约束——告诉 AI “哪些东西不能动”
## 3. 产品约束
- 纯前端静态项目，不引入后端
- 不依赖 Vite / Webpack / npm 构建链路
- 保持本地打开或静态服务器运行即可使用
- 保持现有本地存储与图片协议兼容：
- currentStyle、markdownInput、documents
- activeDocumentId、codeBlockSettings
- IndexedDB WechatEditorImages
- img:// 图片引用格式
图：产品约束要告诉 AI 哪些东西不能动
这一节是整个 PRD 中最重要的部分之一。
没有这节的话，AI 可能会在”优化图片处理”的时候顺便把存储方式从 IndexedDB 改成 localStorage，导致所有用户的图片丢失。或者为了”代码更规范”引入 Vite 构建系统，破坏了”双击打开就能用”的核心特性。
产品约束就是在告诉 AI：你可以自由发挥，但这条线不能越。
关键技巧：约束要写得具体，不要只说”保持简洁”，要说”不引入 Vite / Webpack / npm”。AI 需要的是明确的边界，不是模糊的原则。
第四步：实现边界——明确”现在不做”
## 4. 当前实现边界
本阶段不包含以下能力：
- 多人协作
- 云同步
- 历史版本 / 时间回退
- 图片资源管理面板
- AI 写作辅助
- 可视化公式编辑器
图：把当前不做的功能列出来，避免范围越做越大
这一节看起来是”不做清单”，但它和产品约束的作用不同，实现边界就是“现在不做”。这和产品约束不一样：产品约束通常是长期不能破坏的规则，实现边界只是当前阶段先不碰的范围。把“暂不做”写出来，能防止项目在 Vibe Coding 过程中越做越大。
关键技巧：把”暂不做”列出来，能有效防止项目在 Vibe Coding 过程中越做越大。
第五步：验收标准——做到什么程度才算完成
## 5. 验收标准
### 编辑与保存
- 文档创建、切换、删除、复制可正常工作
- 自动保存状态能正确显示 saving / saved / error
- 刷新页面后文档与当前状态能恢复
### 公式
- 复杂块级公式在预览中正常显示
- 复制到公众号后不出现重复 TeX / MathML 文本
- 长公式能横向滚动查看完整内容
### 代码块
- 切换不同代码主题时，背景和 token 颜色都发生变化
- 复制到公众号后代码块尽量保留高亮与横向滚动
### 图片与复制
- 图片粘贴、拖拽、上传后能正常预览
- 复制到公众号时图片能正常带出
- 表格、引用、列表在复制后保持基本结构
图：验收标准要写成每一条都能测试
验收标准是 PRD 中最容易被忽略的部分。很多人写 PRD 只写”做什么”，不写”怎么判断做完了”。
验收标准的核心原则：每一条都应该是可以测试的。 验收标准要写成能测试的句子。“公式显示正常”太模糊，“复杂块级公式在预览中正常显示”就更清楚。后者能直接变成测试动作，也方便 AI 在修改后生成自测清单。
关键技巧：验收标准按模块分组，每条用”能 + 具体动作”的句式，让 AI 知道该测什么。
第六步：后续方向——给未来留个路标
## 6. 后续方向
后续优先级建议：
1. 文档备份 / 恢复能力
2. 图片管理面板
3. 更稳定的公众号复制验证与回归测试
4. 自定义代码主题 / 自定义正文主题这一节不是给 AI 看的，主要是给自己看的——提醒自己项目下一步该往哪走。但 AI 看到它也有好处：当你在做当前阶段的任务时，AI 不会提前去实现后续方向里的东西，因为它知道那些是”下一步”的事。
4.4 用 PRD 控制 AI，不要直接开改
很多 Vibe Coding 项目失控，不是因为 AI 不会写代码，而是因为我们一开始没有把边界讲清楚。
我的习惯是：每次准备做一个功能，先更新 PRD，再让 AI 动手。
比如我要优化图片处理，不会直接说：
帮我优化图片功能。
我会先在 PRD 里补清楚：
- 这次要优化什么：粘贴、拖拽、上传、复制到公众号
- 哪些东西不能破坏：
img://协议、IndexedDB 存储、已有文档里的图片 - 怎么判断做完：上传后能预览，刷新后不丢失，复制到公众号时图片能带出
然后再对 AI 说：
阅读 PRD.md，按照图片处理相关要求执行。修改前先列 TODO，完成后按验收标准自测。
这样 AI 的工作会稳定很多。它不是只看你当前这一句话，而是会把 PRD 当成项目边界来参考。
五、用 DESIGN.md 进行设计优化
功能层面的问题在上面通过 PRD 解决了。
但还有一个问题：目前的 UI 很简陋，交互也不够好。 尤其是增加了很多新功能之后，原来的界面根本承载不了这么多内容，需要全面重新设计，要怎么办？
设计师 Vibe Coding 时有一个天然优势：你比 AI 更懂什么是好的体验。 但这个优势如果不通过某种方式传达给 AI，就发挥不出来。
所以我的习惯是分两步：
第一步是搭好布局结构。作为设计师，我会更倾向先自己规划布局，比如左右侧栏放置各种功能，导航放顶部，底部是状态信息，把框架搭好。当然你也可以完全利用设计 SKILLS 来做。
第二步才是视觉和交互。
你跟 AI 说”好看一点”或者”设计感强一点”，它可能完全不知道你在说什么。但如果你给它一份结构化的设计文档——定义了配色方案、排版规范、组件样式、交互模式——它就能按你的要求精确执行。
这就是 DESIGN.md 的作用。
顺便说一句，这一步我不喜欢用设计 SKILLS，因为我在体验过一些热门的设计 SKILLS 之后，觉得太模板了，远不如 DESIGN.md 那么自由。这可能是作为设计师自身的底气吧。
5.1 什么是 DESIGN.md
图：DESIGN.md 是把设计系统翻译成 AI 能理解的语言
DESIGN.md 是一份用设计语言（而非产品语言）写成的指导文档。它和 PRD 的区别很简单：
- PRD 管”做什么”——功能、流程、边界
- DESIGN.md 管”做成什么样”——视觉风格、配色、排版、交互
你可以把它理解为：把 Figma 里的设计系统，翻译成 AI 能理解的语言。
一份完整的 DESIGN.md 通常包含这些内容：
| 模块 | 内容 | 设计师的对应 |
|---|---|---|
| 视觉风格定位 | 极简 / 复古 / 科技感，一句话定义整体方向 | Figma 的 Moodboard |
| 颜色规范 | 主色、辅色、中性色、语义色，附具体色值 | Figma 的 Color Variables |
| 排版规范 | 字体、字号、行高、间距体系 | Figma 的 Typography Scale |
| 组件规范 | 按钮、卡片、表单、弹窗的状态和样式 | Figma 的 Component Library |
| 交互规范 | hover 效果、动画、反馈方式 | Figma 的 Prototype |
| 响应式策略 | 断点定义、不同设备下的布局调整 | Figma 的 Auto Layout |
| 可访问性要求 | 对比度、焦点状态、键盘操作 | WCAG 标准 |
| 约束边界 | 严格限制做什么与不做什么 | 设计边界 |
5.2 怎么生成 DESIGN.md
我自己做了一个工具 rico-skills/get-design-md，可以输入任意网站自动生成完整的设计系统文档，也可以在不同设计令牌格式之间转换（DESIGN.md、tokens.json、variables.css、theme.css）。有需要的可以试试。
当然你也可以完全手写。使用上很简单：把 DESIGN.md 放到项目根目录，然后对 AI 说：
使用 DESIGN.md 优化设计
如果你有安装设计类 SKILLS，记得要禁止它调用，会造成干扰。
执行后查看设计优化效果，再针对细节自己调整。完成后记得让 AI 生成项目最终的 DESIGN.md，保持文档和实际代码一致。
有了这份设计文档，AI 在修改 UI 时就不再是”凭感觉”调整，而是按照一套明确的规范来执行。比如我说”给设置面板加一个新的开关”，AI 会自动沿用 DESIGN.md 中定义的组件样式和交互方式，不需要我每次重复描述。
下面是优化后的页面，我自己只调整了一点细节
5.3 为什么推荐在 Vibe Coding 中使用 DESIGN.md
三个原因：
第一，AI 对结构化设计指令的理解远优于模糊描述。 “按钮要有悬停效果”不如”按钮 hover 时背景色从 #2d6dc3 变为 #0066ff，过渡时间 150ms”。
第二，设计师写的 DESIGN.md = 把 Figma 的设计系统翻译成 AI 能理解的语言。 你在 Figma 里做组件化、定义 Variables、整理设计系统时积累的能力，在这里直接有用武之地。
第三，一次写好，每次迭代都能复用。 DESIGN.md 不需要每次都重写。项目初期花时间定义好设计规范，后续所有的 AI 修改都会自动遵守，保持风格一致性。
设计师在 Vibe Coding 中的独特优势就是：你比 AI 更懂什么是好的体验。DESIGN.md 是你把这个优势转化为实际效果的工具。
5.4 验收检查清单
做完上面这些检查，就已经完成了一次完整的 Vibe Coding 项目改造。
功能验证：
- 所有 PRD 中列出的核心功能可以正常使用
- 文档创建、切换、保存、删除流程正常
- 主题切换即时生效
- 图片粘贴/拖拽/上传后能正常预览和复制
- 复制到公众号的结果与预览基本一致
UI / 交互检查：
- 桌面端布局正常（Chrome / Safari / Firefox）
- 移动端布局正常（浏览器 DevTools 模拟）
- 暗色模式下颜色和对比度正常
- 交互反馈清晰（保存状态、操作提示）
PRD 对照：
- 产品约束没有被违反（比如没有引入后端）
- 实现边界之外的功能没有被提前加入
- 验收标准中的每一条都通过了测试
从选技术栈、写 PRD、用 PRD 控制 AI、到设计优化和验收，整个流程都走了一遍。
六、部署上线、域名与成本
到这里，项目已经能在本地跑起来了。下一步就是部署上线，让别人也能通过一个网址访问。
6.1 什么叫部署上线
本地启动时，你访问的是 http://localhost:8080，这个地址只有你自己的电脑能打开。部署上线，就是把项目放到一个公开服务器上，让它变成类似这样的地址：
https://rico-md.vercel.app或者绑定自己的域名：
https://md.ricoui.com对纯前端项目来说，部署并不复杂。它本质上就是把 index.html、CSS、JS、图片这些静态文件上传到一个平台，平台帮你生成一个可以公开访问的网址。
6.2 一共要花多少钱
对于个人项目和练习项目，最低可以做到 0 成本。
部署平台一般都有免费额度，像 Vercel、Netlify、Cloudflare Pages、GitHub Pages 都可以免费部署静态站点。你不买域名也没关系，平台会给你一个默认二级域名，比如 xxx.vercel.app、xxx.netlify.app、xxx.pages.dev。
真正需要花钱的通常是域名。比如你想要 yourname.com 这种自己的地址，就需要去域名注册商购买。价格差异很大，普通域名一年几十到一两百元都很常见。
所以你可以这样理解：
- 只是自己练习、发给朋友看：用平台免费域名就够了
- 想长期展示作品、做个人品牌：再买一个自己的域名
- 想在国内稳定访问、商用或做正式业务：需要额外考虑备案、加速和合规问题
6.3 选哪个部署平台
常见选择可以先这样判断：
| 平台 | 适合什么项目 | 备注 |
|---|---|---|
| Vercel | react、Next.js 生态最佳 | 国内访问速度不佳 |
| Netlify | 静态网站、表单、文档站 | 国内访问正常 |
| Cloudflare Pages | 全球 CDN 的项目 | 赛博佛祖，免费额度最大 |
| GitHub Pages | 文档、简单 Demo、开源项目主页 | 最朴素，功能少但稳定 |
| EdgeOne Pages | 更关注国内访问体验 | 腾讯产品 |
图：常见免费部署平台可以先按访问地区和项目类型判断
本文为了让流程尽量简单，先用 Netlify 举例。原因很直接：登录、导入 GitHub 仓库、点部署，几分钟就能看到结果。
6.4 用 Netlify 部署 rico-md
假设你已经把项目 Fork 到自己的 GitHub 账号下，可以按这个流程走：
- 打开 netlify.com，用 GitHub 账号登录。
- 点击 Add New Project。
- 选择你的
rico-md仓库，点击 Import。 - 如果项目是纯 HTML/CSS/JS，不需要构建命令，可以保持默认设置。
- 点击 Deploy。
- 等部署完成，Netlify 会给你一个
*.netlify.app地址。
如果是 rico-md 这种零构建项目，重点是确认入口文件 index.html 在项目根目录，或者平台能正确找到它。部署成功后，把生成的网址发给别人，对方就能直接打开。
后面你每次把修改 push 到 GitHub，Netlify 通常会自动重新部署。也就是说，你不用每次手动上传文件。
6.5 绑定自己的域名
如果你已经有域名，可以在 Netlify 项目里这样做：
- 进入项目的 Settings。
- 找到 Domains。
- 输入你的域名，比如
md.yourname.com。 - 按照 Netlify 给出的提示去域名服务商那里配置 DNS。
- 等待解析生效，HTTPS 证书会自动配置。
这里不要被 A 记录、CNAME 这些词吓到。你只需要知道：
- 顶级域名，比如
yourname.com，通常按平台提示配置 A 记录 - 子域名，比如
md.yourname.com，通常配置 CNAME
具体填什么，以部署平台当时显示的提示为准。域名解析有时几分钟生效，有时要等久一点，别急着反复改。
6.6 上线前检查清单
部署成功不代表完全没问题。上线前自己走一遍，尤其是纯前端项目，很容易在路径和资源上出小问题。
- 首页能正常打开，不是 404
- CSS、JS、图片都能加载
- 页面刷新后不会白屏
- 移动端布局没有明显错位
- 图片上传、复制、导出等核心功能还能用
- README、PRD、DESIGN.md 里记录的使用方式是最新的
- 如果绑定了域名，
https://能正常访问
如果某些图片在本地能显示，上线后显示不了，优先检查路径。比如本地随手写的绝对路径、中文文件名、大小写不一致，都可能在线上出问题。
6.7 国内访问和备案
很多新手会问：为什么教程里常用 Vercel、Netlify、Cloudflare Pages 这些国外平台？
原因很简单：快。对练习项目、作品集 Demo、开源工具来说，它们不需要复杂服务器配置，也不需要你先学一遍运维。
但如果你的项目主要面向国内用户，情况就要认真一点。国内访问速度、稳定性、备案要求、域名接入方式，都可能影响上线方案。一般来说：
- 只是学习和作品展示：先用 Vercel / Netlify / Cloudflare Pages 足够
- 想要国内访问更稳定：可以再研究 EdgeOne Pages、国内云厂商静态托管、对象存储 + CDN
- 如果使用国内服务器、国内 CDN 或中国区加速能力，通常要关注 ICP 备案要求
这一篇先不把部署展开得太深。你只要完成一次部署，理解”本地项目 → GitHub 仓库 → 部署平台 → 公开网址”这条链路，就已经够用了。其他平台的部署方式，我们在下一篇再横向尝试。
七、核心心得
在结束之前，分享几个在实际 Vibe Coding 过程中总结的关键心得：
图：Vibe Coding 中最值得反复记住的四个经验
1. PRD 是控制 AI 方向的最有效工具。
写一份清楚的 PRD。PRD 让 AI 知道项目的全貌，而不是只盯着你当前这一句话，这是需要练习的能力。
2. 文档体系（PRD + DESIGN.md + CLAUDE.md）让 AI 更可控。
PRD 管”做什么”，DESIGN.md 管”做成什么样”，CLAUDE.md 告诉 AI “当前代码是什么样的”。三份文档配合使用，AI 几乎不会做出意料之外的修改。如果项目复杂，就进一步按照渐进式披露的思路来做。
3. 从简单项目开始，搭积木一样推进。
rico-md 从一个单文件项目开始，逐步模块化、逐步完善。每一个功能完成，检查通过，git 做好备份，再继续下一个功能的开发。
4. 让 AI 定期总结当前状态。
在长对话中，AI 的记忆会逐渐模糊。每隔几轮对话，让 AI “总结一下当前项目的状态和最近的改动”，能帮它重新对齐上下文。
八、附录：几个可以直接复制的 Prompt
下面这些提示词可以直接复制使用。你不需要一次性全用，按当前阶段挑一个就行。
// 明确身份和解释深度
我是一个没有开发基础的新手，请用适合设计师理解的方式解释。
如果涉及技术概念，请先用一句话解释它是什么，再告诉我为什么现在需要知道它。
遇到关键选择时，请给我 2-3 个方案，并说明推荐哪一个、为什么推荐。
// 选择技术栈
我想做一个项目，需求是：
1. [写你的项目目标]
2. [写核心功能]
3. [写是否需要登录、保存数据、后台管理]
4. [写是否只是展示页面，还是一个可长期使用的工具]
请帮我判断适合用什么技术栈。
要求：
- 优先考虑零基础可上手
- 不要一开始就引入过重的框架
- 说明哪些功能暂时不需要后端
- 给出推荐方案、备选方案和不推荐方案
// 生成 PRD
请根据下面的项目想法，帮我整理一份 PRD.md：
[粘贴你的项目想法]
PRD 需要包含：
1. 产品定位
2. 目标用户
3. 核心功能
4. 页面结构
5. 技术约束
6. 暂不做的功能
7. 验收标准
请注意：验收标准要写成可以逐条测试的清单。
// 按 PRD 拆任务
请阅读当前项目和 PRD.md，把开发任务拆成 TODO。
要求：
- 按优先级排序
- 每个任务说明要改哪些模块
- 标出高风险部分
- 不要直接改代码，先给我执行计划
// 执行前先出计划
在修改代码前，请先做三件事：
1. 阅读相关文件，确认当前实现方式
2. 给出修改计划
3. 明确不会改动的范围
等我确认后，再开始执行。
// 修改后自测
请根据 PRD.md 和本次修改内容，生成一份自测清单。
要求：
- 按功能、UI、数据、兼容性分组
- 每一条都能手动验证
- 如果有潜在风险，请告诉我优先检查哪里
// UI 设计优化
请基于当前页面做 UI 优化。
要求：
- 不改变核心功能
- 优先优化布局、层级、间距、对比度和交互反馈
- 不要使用模板化的花哨风格
- 输出前先说明整体设计方向
- 修改后检查桌面端和移动端是否有错位
// 生成 DESIGN.md
请根据当前项目的界面和样式，生成一份 DESIGN.md。
内容包括：
1. 视觉风格定位
2. 色彩规范
3. 排版规范
4. 组件规范
5. 交互规范
6. 响应式规则
7. 不应该破坏的设计约束
这份文档后续会作为 AI 修改 UI 的依据。
// 部署上线
请帮我检查这个项目是否适合部署到 Vercel。
要求：
- 判断是否需要构建命令
- 检查入口文件是否正确
- 提醒可能出错的资源路径
- 给出从 GitHub 到 Vercel 的部署步骤
- 如果绑定域名，说明 DNS 应该怎么按平台提示配置
// 总结当前项目状态
请总结当前项目状态，方便我开启新的 AI 对话继续开发。
总结内容包括：
1. 项目目标
2. 当前技术栈
3. 已完成功能
4. 最近一次修改
5. 重要约束
6. 下一步建议
7. 必须测试的场景九、最后
其实这一篇本来我是想把框架案例一起讲了，但是之前我遇到很多同学都是卡在基础的问题上，所以就再细化拆分了一下，再仔细一点掰开来讲。
所以这一篇我们做了一个项目改造案例：从选技术栈、建立文档体系、写 PRD、用 PRD 控制 AI、用 DESIGN.md 优化设计，到最后的验收。看似内容不少，实际上给 AI 的工作时间可能就几个小时。
不断在实践中积累经验。
下一篇（三），我们会再进阶一点，用 Astro + Tailwind 的现代框架来做个人作品集网站/Landing Page，以及涉及一下 React 和 Vue 相关的科普，然后对项目做横向对比，最后把项目部署上线。从零构建到部署，完成整个闭环。
有兴趣的话，可以先看看下面我特地开发的开源模板项目(都有中英文版本)：
- 给 Vibe Coding 开发的启动模板
https://github.com/ricocc/ricoui-astro-starter
- RicoUI SaaS 模板
https://github.com/ricocc/ricoui-saas-template
- RicoUI 个人网站模板
https://github.com/ricocc/ricoui-portfolio-zh
如果你在这个过程中做了自己的改造项目，或者有什么疑问，欢迎发给我看看——微信 rico-ui，或者在公众号 Rico 的设计漫想 留言。
我是 Rico，感谢阅读！
关注我的微信公众号，我在这里专注文字创作
