Article

写给设计师的 Vibe Coding 零基础指南（一）：基础、框架、工具

更新于：2026-04-30 • 20 min read

在上一篇设计篇中，我们完成了从设计理念到 Figma 设计稿的全部工作。但设计稿终究只是静态的图片，如何让它变成真正可访问、可交互的网站？

以前，这意味着你要学 HTML、CSS、JavaScript，还要懂框架、打包工具、版本控制……光是这些名词就足以劝退大多数人。

但现在不一样了。

Vibe Coding 让“写代码”这件事发生了本质变化，你不再需要从零学习编程语言的语法，而是用自然语言描述你的需求，让 AI 帮你生成代码、调试问题、优化效果。

但是铺天盖地的 Vibe Coding 宣传，可能让大家错误的以为随便聊聊就能做一个产品，实际上这是有难度和需要学习相关基础的，只是在难度上，确实是从未过的简单了。

这篇开发篇（一），我们不急着写代码，而是夯实基础。

你不用先学成工程师，也不用背一堆定义。你只要先分清，每一层到底在管什么，第一次做产品时顺序就不会那么容易走反。

对于设计师来说，这件事可能比你想象的更加容易上手，因为你已经具备 Vibe Coding 所需的能力：

  • 你懂设计语言：布局、间距、颜色、字体——你用这些词汇描述需求，AI 就能理解
  • 你懂组件化思维：Figma 的变体、实例、自动布局，本质上就是前端开发的组件逻辑
  • 你知道你想要什么：设计稿已经画好了，你只需要把它描述出来

开发篇我们先把基础打牢：搞懂技术名词、理解前后端分工、选对 AI 工具、学会写 PRD，再掌握 Vibe Coding 技巧。

一、开发入门：需要知道的几件事

不少设计师第一次让 AI 帮自己做项目，心情通常是：很兴奋，然后很快困惑。

困惑的原因不难理解——你跟 AI 说”帮我做一个作品集网站”，它回复里可能同时冒出十几个你从没听过的词：前端、后端、API、数据库、部署、域名、环境变量……你还没来得及消化，AI 已经在推进下一步了。

更麻烦的是，如果你没有项目方案的思路，AI 大概率不会对你说”你先想清楚再动手”。你描述一个模糊的想法，它也会立刻给出完整方案。这种”有求必应”很容易让人产生错觉，觉得自己已经上路了，实际上连方向都还没确认。

所以这一节，我们不谈代码，先把这些基础概念用设计师能理解的方式理一遍。搞清楚每个词负责什么，后面动手时才不容易走偏。

1.1 网页的本质：三种语言

网页的本质由三种语言组成：

语言作用设计师的类比
HTML网页的结构和内容就像 Figma 里的图层结构
CSS网页的样式和外观就像 Figma 里的样式面板
JavaScript网页的交互和动效就像 Figma 里的原型交互

举个例子，你在 Figma 画了一个卡片组件：一个圆角矩形，里面有一张图片、一段标题文字、一个按钮。

在代码中：

  • HTML 定义「这里有一个卡片，里面有图片、标题、按钮」
  • CSS 定义「卡片是圆角的、有阴影、背景是白色、标题是 16px 加粗」
  • JavaScript 定义「点击按钮会发生什么」

这是最基础的一层。但你很快会发现，光知道这三种语言，还不够理解一个完整产品是怎么跑起来的。

1.2 前端、后端、数据库：三层各管什么

这是新手最容易缠在一起的三组词。它们总是同时出现，但其实各管各的事。

先说结论：前端管你给别人看到什么，后端管事情怎么在背后流动，数据库管产品记住什么。

前端：用户看到和操作的一切

你在浏览器里看到的每一个像素，都属于前端。

页面怎么排版、按钮多大、文字什么颜色、鼠标悬停有没有动效、点击之后跳不跳转——这些全是前端的范畴。换句话说，你在 Figma 里画的所有内容，最终都由前端负责呈现。

不少人对前端的印象停留在”把页面做漂亮”，这其实低估了它。视觉当然重要，但前端更核心的职责是把用户流程跑通。

作为设计师，前端是你最容易上手的部分。你在 Figma 里建立的那些习惯——组件化、间距规范、响应式布局——在前端开发里几乎都有对应的概念。你的设计经验在这里直接有用武之地。

后端：按钮背后的逻辑处理

用户在页面上点了一个按钮，接下来发生了什么？

如果只是跳个链接，前端自己就能搞定。但如果涉及”处理”——比如提交一份表单、请求 AI 生成一段文字、保存一条记录——这些事情就不是前端能独立完成的了。这时候就需要后端出场。

后端负责的是接收前端的请求、执行处理逻辑、返回结果。前端告诉你”用户点了什么”，后端来决定”接下来该做什么”。

听起来很复杂？其实对于设计师做个人网站来说，后端往往只有几件事：接收请求、调用外部服务（比如 AI 接口）、把结果送回去。不需要一上来就想象一个庞大的系统。

一个简单的判断标准：如果你的网站只是展示内容（作品集、个人介绍），可能几乎不需要后端。如果你要加评论功能、AI 对话、用户登录这类”有动作”的功能，后端就开始发挥作用了。

注意区分后端和数据库——后端是”做事的人”，数据库是”记录本”。它们经常一起出现，但不是同一回事。

数据库：让产品拥有”记忆”

没有数据库的网站，每次刷新都像从零开始——你刚填完的信息没了，你刚才的操作也忘了。

数据库解决的就是这个问题：把需要保留的数据存下来，下次还能找回来。用户注册的账号、提交的留言、保存的草稿，这些都需要数据库来管理。

对于设计师做个人作品集来说，好消息是很多场景暂时用不上数据库。Astro 这类框架生成的是静态页面，内容直接写在代码里就行，刷新也不会丢。

但如果你将来想加功能——比如访客留言、AI 工具需要记住上一次的输入——那时候就需要引入数据库了。

一个实用建议：不用急着在第一天就搭数据库。先用写死的数据把页面和流程跑通，等确认哪些数据确实需要持久保存，再引入数据库也不迟。

一个例子串起来：从联系表单看三层配合

拿设计师网站常见的”联系表单”来串一遍，你会发现三层其实很好理解。

前端做的事：展示一个表单，包含姓名、邮箱、留言内容三个输入框，加一个”发送”按钮。用户填完后点击按钮，页面显示”发送成功”或”发送失败”。

用户点击”发送”之后，前端不会自己发邮件，它只是把用户填的信息打包，通过一条约定的通道（也就是 API）交给后端处理。

后端做的事：收到前端传来的信息后，先检查格式对不对（邮箱是不是合法的），然后调用邮件服务把消息发到你的邮箱。如果发送成功，告诉前端”成了”；如果失败，告诉前端原因。

数据库在这里干什么？如果你想把每条留言都存下来，方便以后在后台查看，那后端在发邮件的同时，也会把这条留言写进数据库。下次你打开后台，就能看到历史留言记录。

如果缺了后端，按钮点了没反应；如果缺了数据库，你永远只能靠邮箱查看留言。三层各司其职，少了哪一层，体验都会断。

这个例子的意义在于：当你听到”这个功能还不通”的时候，可以试着把它拆开看——是页面本身的问题，还是背后处理逻辑的问题，还是数据没存对。这种拆分思维，比记住一堆术语有用得多。

1.3 什么是框架和组件库？

框架是什么？

想象你要建一栋房子：

  • 从零开始 = 纯手写 HTML/CSS/JS（自己画图纸、买材料、打地基）
  • 框架 = 预制模块化建筑系统（已经做好承重结构、水电管线，你只需要拼接房间）

常用的前端框架（设计师只需要了解这些）：

框架特点设计师需要知道的
React最流行国外最流行
Vue易上手国内项目常用
Svelte轻量、性能好适合小项目
Astro专注内容网站，性能极快可混用框架
Next.js生态成熟适合复杂应用

组件库是什么？

组件库 = 设计师「组件面板 + 样式系统」的代码版。

在 Figma 里你有一个「按钮」组件，可以变体出主要、次要、禁用状态；在代码里也一样，只需要指定 variant=“primary” 即可。

常用的组件库：

组件库特点适合风格
shadcn/ui可定制程度高现代简洁
HeroUI功能丰富现代简洁
Radix UI无样式底层完全自定义
daisyUI轻量免费快速原型

设计师视角的类比:

设计概念代码概念
Figma 组件UI 组件（Button、Card）
Figma 变体Props
Figma 样式Tailwind 类
Figma 组件面板组件库
Figma 自动布局Flexbox / Grid

理解了这些，你就可以用 Figma 的思维去理解代码了。画设计稿时的「抽离公共组件」= 代码里的「封装复用组件」。

1.4 为什么选择 Astro + Tailwind？

我的开源模板使用 Astro 框架搭配 Tailwind CSS，原因很简单：

Astro 的核心优势：岛屿架构——只有需要交互的部分才会加载 JavaScript，其余都是静态 HTML。所以首屏加载极快、SEO 友好，非常适合个人作品集。

Astro 的另一个优势：框架无关性——你可以在同一个项目里混用 React、Vue 或纯 HTML + Tailwind，想加 3D 交互时再引入 React 就行。

Tailwind CSS：最适合 AI 的 CSS 方案——传统 CSS 需要命名和分离文件，而 Tailwind 把样式直接写在 HTML 里，AI 看一眼就能懂。它的设计令牌也和 Figma Variables 完美对应（p-6 对应 spacing/24），改配色时只需要替换配置即可。

1.5 网站做好了怎么上线：服务器、部署、域名

你在自己电脑上预览网站，一切正常，但是截至目前你的网站还只活在你自己的电脑里。

要让它对外可访问，需要搞清楚三件事：

  • 服务器就是一台永远在线、对外提供访问的电脑。你的网站文件需要放在上面，别人才有可能访问到。常见的平台有 Cloudflare、Vercel、Netlify，提供不同额度的免费方案。
  • 部署是把你的代码从本地电脑搬到服务器的过程，并确保它在服务器上正确运行。这一步相当于”发布上线”。
  • 域名是你给别人看的网址，比如 yourname.com。没有域名，别人只能用一串不太好记的公网 IP 地址来访问，域名让这件事更友好。

三者之间的关系可以这样理解：服务器是”空间”，部署是”搬进去”，域名是”贴上门牌”。缺了任何一步，别人都打不开你的网站。

一个最简单直接的流程，Github（上传代码）-> Cloudflare（绑定 github）-> 一键部署上线（可访问） ->（可选）绑定域名（Cloudflare 购买域名）

二、AI 编程工具推荐

AI 编程的核心是 模型 + 工具 的组合。模型是大脑，负责理解你的描述；工具是手脚，负责实际修改文件、运行命令。

IDE 与 CLI 的区别

IDE（图形界面工具）像一个熟悉的代码编辑器（类似带 AI 的 VS Code），有窗口、侧边栏，看得见文件结构，操作直观。代表：Cursor。

CLI（命令行工具）像终端窗口，只用文字对话，简单专注，灵活性高，能自动处理更多任务。代表：Claude Code、Codex。

两者都能让 AI 直接操作你的项目文件。我经常把它们一起用。

主流工具

  • Cursor：图形界面 IDE，适合边看 Figma 边让 AI 生成组件。
  • Claude Code：命令行工具，理解复杂需求强，适合调整整个模块。
  • Codex（OpenAI）：轻量 Agent，能自主执行任务和调试。
  • Gemini（Google）：免费额度高，适合快速尝试。
  • Kimi，CodeBuddy，TRAE，Qcoder：国产，免费额度大，零基础友好。

我的建议

如果你想完全免费上手，优先选择国产 IDE，比如 TRAE（国内版）和 Qcoder 等。这些工具免费额度比较大，中文支持好，各种模式也很适合设计师直接用自然语言描述 Figma 风格，几乎不需要配置。

如果你能接受小额付费，想获得更好的使用体验，IDE 可以考虑 Cursor 或者 TRAE 国际版。Cursor 的编辑器操作最流畅；TRAE 国际版在模型访问和稳定性上也有提升。

如果预算有限，但又想保持较高性价比，CLI 工具可以优先接入国内各大模型，比如 Kimi、GLM、Qwen 等。这些模型价格便宜，新用户优惠力度大，日常调整颜色、替换字体、实现简单交互已经足够。

截至我写这篇文章时，如果你追求更强的项目级能力，不太在意成本，那可以直接上 Claude Code 或 Codex。它们在理解复杂需求、多文件重构和项目级调整上表现更稳。

我的实际感受：大多数设计师刚开始时，用 TRAE 国内版或 Kimi 就能快速把模板跑起来，看到效果后再决定要不要升级。有能力的直接上 Claude Code 会带来更好的体验以及尽可能少的再修改，减少过程中的内耗，上顶配是个省时省心的决策。

三、产品需求文档 (PRD)

先理清楚需求，再做事，这是 Vibe Coding 里最重要的一步。

PRD（Product Requirements Document）原本指产品需求文档。在 Vibe Coding 里，它也是给 AI 的「项目说明书」：把你的想法翻译成结构化的要求，让 AI 少走弯路，减少反复迭代。

很多人第一次用 AI 做项目，会直接说「帮我做一个网站」或者「帮我做一个工具」。AI 当然会开始写，但它很可能不知道你真正想要什么：给谁用、重点功能是什么、哪些地方不能乱改、最终做到什么程度才算完成。

PRD 解决的就是这个问题。

你可以把它理解成一张「项目地图」。它不需要写得像公司文档那么正式，但至少要把方向、边界和验收标准说清楚。尤其是零基础做项目时，PRD 能帮你避免一个很常见的问题：做着做着，AI 越改越偏，你自己也忘了最开始到底想做什么。

如果你的工具支持 plan 模式，也可以先让 AI 帮你一起完善 PRD。先聊清楚方案，再让它动手写代码，这一步会省掉后面大量返工。

零基础写 PRD 的 3 步：

  1. 在项目根目录新建一个 PROJECT_PRD.md 文件。
  2. 复制下面的通用模板，替换成你自己的内容。
  3. 以后每次让 AI 修改时，都说：“参考根目录的 PROJECT_PRD.md，按里面的要求帮我实现……”

通用 PRD 模板（直接复制使用）：

# 项目 PRD

## 项目概述
这个项目要做什么？
一句话说清楚目标，比如：做一个个人网站、一个作品管理工具、一个 AI 小工具、一个活动落地页。

## 目标用户
谁会使用它？
- 主要用户：
- 他们现在遇到的问题：
- 这个项目要帮他们解决什么：

## 核心功能
先列最重要的 3-5 个功能，不要一开始写太多。
- 功能 1：
- 功能 2：
- 功能 3：

## 页面 / 模块结构
这个项目大概由哪些页面或模块组成？
- 页面 / 模块 1：
- 页面 / 模块 2：
- 页面 / 模块 3：

## 设计与体验要求
希望它看起来和用起来是什么感觉？
- 视觉风格：
- 字体 / 色彩 / 间距偏好：
- 需要适配的设备：桌面端 / 手机端 / 平板
- 参考设计稿、截图或链接：

## 技术约束
有哪些已经确定或不希望改动的地方？
- 技术栈：
- 不要改动的文件 / 路由 / 组件：
- 优先使用的组件库或样式方案：

## 素材与数据
项目会用到哪些内容？
- 图片 / 图标 / 视频：
- 文案：
- 示例数据：
- 需要接入的外部服务：

## 验收标准
做到什么程度才算完成？
- 手机端和桌面端都能正常浏览
- 核心流程可以跑通
- 视觉效果接近设计稿或参考图
- 没有明显报错和布局错位

## 暂不做的事情
哪些需求先不做，避免项目变复杂？
- 暂不做：
- 以后再考虑：

有了 PRD 后，你后面的每次对话都可以围绕它展开。比如：

请先阅读 PROJECT_PRD.md，然后帮我实现首页第一屏。不要改动 PRD 里写明暂不做的功能。

这样 AI 就不会只盯着你当前这一句话，而是会把整个项目目标、设计要求和边界一起考虑进去。对 Vibe Coding 来说，这比单独写一个漂亮 Prompt 更重要。

四、Vibe Coding 简单技巧

4.1 Vibe Coding 的核心理念

传统的编程学习路径是：先学语法，再理解概念，最后练习写代码。

Vibe Coding 的路径是：描述需求 → AI 生成代码 → 运行看效果 → 迭代调整 → 完成。

关键在于：你不需要先学会再做事。你可以在做事的过程中，慢慢理解代码。

4.2 让 AI 帮你搞定一切环境配置

很多人看不懂环境配置（安装 Node.js、配置 npm 等）。现在你可以直接告诉 AI：

把这个项目跑起来

AI 会自动检测环境、安装依赖、启动开发服务器，并告诉你访问地址。你只需要一个意图，剩下的事 AI 帮你完成。

4.3 上下文管理：让 AI 理解你的意图

不要说：“帮我改一下首页”

要说：“我想修改首页 Hero 区域的布局。现在是左文右图，我想改成上下结构：上面是标题和简介，下面是头像图片。”

上下文四个要素：

  1. 目标（你想达成什么效果）
  2. 现状（当前是什么样子）
  3. 素材（设计稿、截图、参考链接）
  4. 约束（技术栈、设计规范、不希望改动的地方）

4.4 模型搭配和迭代对话

AI 的能力由模型决定。实际开发时我常用模型搭配：

  • 用 Claude Code 或 Codex 梳理需求文档、精细调整和多文件重构（理解力更强）
  • 简单需求和代码编写可以使用 glm、minimax 等性价比较高的模型完成，设计到架构和方案，模型越好在后面越省事。

迭代对话是 Vibe Coding 的精髓。不要指望一次就完美，而是通过多轮「反馈 → 调整」逐步逼近目标。每改一次，都把 PRD 发给 AI，让它记住整体风格。

4.5 善用 Skills、MCP、Agents

等你开始频繁用 AI 改项目时，会遇到三个进阶词：Skills、MCP、Agents。它们听起来很技术，但可以先用一句话理解：

Skill 是经验包，MCP 是连接器，Agent 是执行者。

能力是什么解决什么问题什么时候用
Skill可复用的专业流程少重复解释偏好反复做同类任务时
MCP外部工具连接器让 AI 读取更多上下文需要接入 Figma、浏览器、文档等资料时
Agent / Subagent独立处理子任务的 AI拆分复杂任务文件多、步骤多、需要并行检查时

不同工具的叫法不完全一样。比如 Claude Code 里更常见的是 Subagents 或 Agent teams，有些工具会直接叫 Agents、子任务、工作流，意思都接近：把一个大任务拆开，让 AI 按角色去处理。

举个设计师最容易理解的场景：你已经有一份 Figma 首页设计稿，想把它变成网站首页。

第一步，你可以先用普通对话让 AI 按设计稿搭出页面结构。这个阶段不用急着上进阶功能，先让页面看得见、跑得起来。

第二步，如果你发现自己总是在重复强调「按钮要有 hover 状态」「间距用 8px 体系」「移动端不要挤在一起」，就可以考虑用 Skill。它相当于把你的设计检查清单变成一套固定工作方式，以后每次优化页面都能复用。

第三步，如果 AI 需要读 Figma 文件、查浏览器里的真实渲染效果，或者读取某个外部文档，这时候就轮到 MCP。它不是让 AI 变聪明，而是让 AI 能拿到更多现场信息。

第四步，如果页面已经比较复杂，你想同时检查导航、作品卡片、移动端布局和性能问题，就可以让 Agent / Subagent 分头处理。它们像临时拉出来的几个助手，每个人负责一个方向，最后再汇总到主任务里。

所以不要把这些功能想得太玄。它们不是第一天必须掌握的东西，但等你开始反复改页面、接外部资料、处理多文件项目时，会明显提升效率。

五、建议的开发顺序

概念都清楚了，接下来该动手了。但顺序很重要——很多新手失败不是因为能力不够，而是因为步骤搞反了。

推荐的路径：

  1. 确认技术方案。技术方案确定，后续可以沿着方向一路跑通，大方向错了，意味着一切都得重来。
  2. 先做页面和交互。把设计稿变成可见、可点击的页面。这一步能帮你验证”用户流程到底顺不顺”。
  3. 用假数据先跑通。不要急着对接真实服务，先用写死的内容把整个流程走一遍。
  4. 再接入后端逻辑。页面跑通之后，你才清楚后端到底需要处理什么。
  5. 按需加数据库。等确定哪些数据需要持久保存了，再引入数据库。
  6. 部署上线。让网站真正对外可访问。
  7. 最后打磨细节：绑域名、配密钥、加日志，把”能用”变成”稳当”。

这个顺序看起来很基础，但能有效避免”做到一半推翻重来”的情况。先让最短的一条路跑通，再逐步完善。

六、提前实操：让模板跑起来

理论讲完了，下一篇我们会深入每个模块的具体实现。这里先给你一个最简单的起步方式：

一句话启动项目

开源模板地址：

打开你选择的工具（用 TRAE 或 Kimi），下载我的开源模板，然后输入：

帮我把这个项目跑起来。

AI 会自动检查 Node.js、安装依赖、启动开发服务器，并告诉你本地访问地址。

最后

这篇开发篇我们讲了很多基础概念：前端/后端/数据库的分工、框架和组件库、服务器/部署/域名、以及 AI 工具选择，以及简单提了一下 PRD 写法和 Vibe Coding 核心技巧等概念。

核心观念：

  • 概念先行，动手在后。搞清楚每层在做什么，比急着写代码更重要。
  • AI 是你的编程伙伴，不是工具。你可以和它讨论方案，让它给你建议。
  • 先跑起来，再优化。完美是迭代出来的，不是设计出来的。
  • 设计师的组件化思维是 Vibe Coding 的天然优势。

在下一篇文章中，我们直接进入实操，以我开源的网站模板为例，聊聊个人在 Vibe Coding 中的一些经验，以及视觉实现、容易踩的坑、如何部署上线等内容。

我是 Rico， 感谢阅读！

关注我的微信公众号，我在这里专注文字创作

微信公众号