Vibe Coding实战：自然语言驱动个人网站设计与迭代

Vibe Coding 正在成为开发者圈子里讨论热度很高的一种开发方式。它的核心不是让 AI 一次性写完整个项目，而是用自然语言描述需求、让 AI 生成代码、再通过检查、反馈、迭代不断逼近目标。个人网站恰好是 Vibe Coding 最容易出效果的项目类型：规模不大、结构清晰、没有复杂的业务逻辑，而且视觉设计本身就很适合用对话式反馈来打磨。下面从概念、工具、提示词、迭代流程、验证部署到常见问题排查，完整走一遍用 Vibe Coding 做出有设计感个人网站的过程。

1. Vibe Coding 的本质：从“写代码”变成“描述结果再验收”

1.1 一句话理解 Vibe Coding 的工作方式

Vibe Coding 可以理解为一种人机配合的开发方式：你用自然语言描述“我想做一个什么样的页面、希望它长什么样、有哪些部分、用什么技术栈”，AI 生成对应代码，你在浏览器里看效果，发现问题后用自然语言继续提修改意见。整个过程里，代码主要由 AI 产出，人的主要工作是定义目标、验收结果、控制方向。

这不是让 AI 代替你思考，而是把精力从“怎么写每一行代码”转移到“怎么描述清楚想要的结果”。实际项目中，同一个页面反复迭代十几轮很常见。每一次反馈都会缩小代码和预期之间的差距，做到后面你会发现，真正决定网站质量的已经不是 AI 的能力，而是你描述需求、判断方案、验收结果的能力。

1.2 Vibe Coding 和传统开发的差异

把传统手写代码和 Vibe Coding 放在一起对比，能更清楚看到各自的适用范围。

这个对比说明一个关键结论：Vibe Coding 的优势是快速产出可运行、可看的界面，代价是开发者必须承担检查、定位、修正的责任。你不能只负责提需求，然后把所有代码都当成黑盒。框架版本、依赖安全、数据格式、浏览器兼容这些问题，都不会因为代码由 AI 生成就自动消失。

1.3 个人网站为什么是 Vibe Coding 的最佳练习对象

个人网站具备几个非常适合 Vibe Coding 的特点。

第一，规模可控。一个典型的个人网站通常只有三到五个核心区块，不涉及复杂的事务、权限和并发逻辑，即使 AI 生成的结果不理想，重做的成本也不高。第二，视觉主观。个人网站的美感判断很依赖个人偏好，用自然语言描述“再留白一点”“标题再大一点”“颜色太跳了”非常自然，这种主观反馈恰好是对话式开发最擅长的。第三，反馈闭环快。本地起一个开发服务，改完立刻能看，视觉问题比逻辑问题更容易被识别和描述。

不过要提醒一句：Vibe Coding 适合个人网站，不代表所有网站都适合。需要强一致性的支付系统、需要精细权限控制的业务后台、需要严格数据校验的企业应用，不建议用这种方式从零生成。它的定位是“快速做出可用的界面和原型”，而不是替代严谨的工程流程。

2. 开工前先定设计目标和信息架构

2.1 个人网站通常包含哪些模块

很多人在第一轮提示词里只写“做一个好看的个人网站”，然后让 AI 自由发挥。这样得到的结果往往内容杂乱、结构失衡，因为 AI 并不知道哪些信息对你最重要。正确做法是先决定页面包含哪些模块。

个人网站常见的模块如下：

建议先选三到五个模块，不要贪多。首屏、作品、关于、联系是大多数个人网站的地基。先把这些模块排好顺序，再让 AI 按这个顺序生成页面，通常比让 AI 自己决定结构要稳定得多。

2.2 确定视觉风格：关键词、配色、字体、动效

设计感不是玄学，而是一组可描述、可验证的视觉规则。在开始写提示词之前，先把视觉方向拆成四个部分。

风格关键词决定整体气质。常见的有“极简”“杂志风”“粗野主义”“玻璃拟态”“复古终端”“日式留白”“渐变光效”。选一个主关键词，再配一个辅助关键词即可，不要堆太多。例如“极简 + 杂志排版”和“玻璃拟态 + 科技感”是完全不同的方向。

配色决定第一眼印象。建议指定主色、辅助色、文字色三类颜色，最少三个色值，最多控制在五个。字体决定传达的质感。标题字体和正文字体要分开，标题可以更有个性，正文要保证可读性。动效决定交互层次。建议先明确“少动效”还是“中等动效”，之后再加细节。

2.3 把设计目标写成第一版提示词

设计目标想清楚后，需要翻译成 AI 能理解的结构化提示词。一个有效的第一轮提示词至少包含六类信息：技术栈、页面结构、视觉风格、具体色值、动效程度、本轮边界。

用 Next.js 和 Tailwind CSS 开发一个个人作品集首页。 页面包含五个部分：顶部导航、Hero 首屏、精选作品网格、关于我、联系方式。 技术栈限定为 Next.js App Router + Tailwind CSS，不引入额外的 UI 组件库。 视觉风格：极简、大留白、杂志感。 背景色 #F4F1EA，正文文字色 #1F1E1D，强调色 #C8553D。 Hero 标题需要特别醒目。 先只实现桌面端布局，移动端适配放到下一轮。

注意这里写到了“本轮边界”。很多人忽略这一点，结果 AI 在同一轮里既做布局又做适配又加动画，改动太多，出了问题很难定位。把迭代拆成小步，每一轮只解决一类问题，是 Vibe Coding 最重要的控制手段。

3. 工具与开发环境准备

3.1 AI 编程助手怎么选

市面上的 AI 编程助手各有侧重。常见的有 Cursor、GitHub Copilot，以及通义灵码、文心快码等国内产品；一些通用对话模型配合手动粘贴代码也能完成类似工作。选择时不要只看宣传，要结合自己实际的工作流验证四个能力。

需要特别说明一点：不同平台和生态都有对应的 AI 编程辅助工具，使用前要确认它对目标技术栈的熟悉程度。比如在鸿蒙应用开发场景里，如果要用 AI 辅助生成 ArkTS 代码，就要确认助手是否支持该语言和对应框架；在 Web 前端场景里，也要确认模型对 Next.js、Astro 这类框架的掌握情况。原理相通，但模型对特定技术栈的熟悉度会影响产出质量。

3.2 本地环境检查与项目初始化

无论用哪个 AI 助手，本地都需要一个能运行项目的基础环境。先检查 Node.js 和包管理器是否安装。

node -v npm -v

Node.js 版本以当前项目要求为准，常见的前端项目建议使用 LTS 版本。版本过低时，依赖安装和构建过程可能报错。

初始化项目时，最常用的方式是使用官方脚手架。以 Next.js 为例：

npx create-next-app@latest my-portfolio cd my-portfolio npm run dev

执行后终端会询问 TypeScript、ESLint、Tailwind CSS 等选项。学习阶段建议按默认开启这些功能，因为它们能让代码质量下限更高。启动成功后，浏览器访问http://localhost:3000，看到默认页面就说明环境已经打通。

如果你不需要 React 的复杂能力，也可以选择 Astro、Vite 或纯 HTML 单页。个人网站选型建议是：想写文章、做内容站优先考虑 Astro；想要更自由的组件化开发考虑 Next.js；只想快速做一个小页面用 Vite 加 Vue 或 React 都行。工具只是手段，关键是能把页面跑起来。

3.3 推荐项目结构和文件职责

项目初始化完成后，目录结构会因框架不同而略有差异。以 Next.js App Router 项目为例，一个干净的起点大致如下：

my-portfolio/ app/ layout.tsx # 全局布局、导航、页脚 page.tsx # 首页入口，负责组合各区块 globals.css # 全局样式、CSS 变量 components/ Hero.tsx # 首屏区块 ProjectGrid.tsx # 作品网格 About.tsx # 关于我 Contact.tsx # 联系方式 public/ images/ # 静态图片资源 package.json

这个结构的核心思想是把页面拆成独立组件。这样做的好处是，AI 在后续迭代时只需要修改某一个组件文件，不会因为所有代码堆在一个文件里而反复出现上下文混乱。你可以在提示词里直接指定“修改 components/Hero.tsx”，AI 的改动能更精准地落在对应区域。

4. 三轮迭代打磨首页：从骨架到细节

4.1 第一轮：生成完整页面骨架

第一轮的目标不是把设计做到位，而是先让页面所有模块出现、结构完整。把第 2.3 节的提示词交给 AI 后，你会得到一个可以在浏览器里运行的页面。此时不要急着挑样式毛病，先按这个顺序检查：页面是否能运行、模块是否齐全、区块顺序是否符合预期、关键文字内容是否正确。

第一轮生成结果常见的现象是：布局能用但很粗糙，配色接近提示词但不完全准确，文字内容是 AI 编出来的示例。这些都很正常。文字内容后面要自己替换，配色细节可以在第二轮通过更明确的色值修正。第一轮最重要的验证是“骨架成立”，也就是五大模块都出现在页面上，并且能滚动浏览。

4.2 第二轮：修正布局和视觉密度

骨架建立后，第二轮集中处理布局和视觉密度。反馈提示词要尽量给出具体值，而不是模糊的“再好看一点”。

Hero 标题换成衬线字体并加大到 96px，首屏下方加一个小箭头提示滚动。 项目网格改为三列，卡片间距统一为 32px。 导航栏固定顶部，滚动后背景变成半透明。 所有 section 的垂直内边距统一为 96px。

这段提示词有几个特点值得学习。每一项都针对单一目标：字体字号、网格列数、导航行为、区块间距。每一项都给出了可验证的数值或行为，例如“三列”“32px”“96px”。这样 AI 修改完后，你可以立刻检查这些数值是否生效，而不是凭感觉判断“好不好看”。

这里也解释了为什么“再大气一点”“更有质感”这类反馈效果差。它们描述的是感受，不是方案。AI 生成代码时无法理解“大气”和具体 CSS 属性之间的映射。你需要在感受背后找到对应的技术参数：可能是字号、间距、留白、字体、颜色对比度中的一项或几项。

4.3 第三轮：补齐响应式和动效

桌面端视觉稳定后，第三轮再处理响应式和动效。移动端适配和信息架构不同，它涉及大量媒体查询和布局变化，如果和前面的视觉调整混在一起，很容易让 AI 改坏已有的效果。

增加移动端适配：768px 以下项目网格变为一列， Hero 标题降到 48px，导航折叠为汉堡菜单。 作品卡片加悬停上浮效果，持续 200ms。 滚动进入视口时，项目卡片以轻微上移动画出现， 并支持 prefers-reduced-motion 媒体查询。

动效方面的要求也要具体。直接说“加一些动画”会得到不可控的结果；说“悬停上浮，持续 200ms”就变成了一个明确的约束。动画时长、触发方式、是否尊重系统减弱动效偏好，这些都属于细节控制。很多 AI 生成的动画没有处理prefers-reduced-motion，视觉障碍用户会因此感到不适，这一步通常需要人工提醒 AI 补上。

4.4 迭代时的反馈句式模板

迭代了几轮后，可以沉淀一套自己的反馈句式。常用的有五种。

修改式：把 X 从 A 改成 B。例如“把作品卡片圆角从 12px 改成 4px”。新增式：在 X 区域增加 Y。例如“在 Hero 下方增加一行社交链接图标”。删除式：删除 X，不要显示。例如“删除页脚里多余的版权声明文案”。检查式：列出当前页面存在布局风险的区域。例如“列出在 768px 宽度下可能溢出的组件”。约束式：不要使用 X，保持 Y。例如“不要使用字体加载服务，保持系统字体栈”。

这些句式的作用是把模糊的意图翻译成 AI 更容易执行的操作。反馈越具体，迭代效率越高。越早建立这个习惯，Vibe Coding 的可控性就越强。

5. 用提示词控制设计细节的四个维度

5.1 色彩系统

个人网站“显乱”最常见的原因是颜色太多。AI 默认生成的页面里，背景、卡片、边框、按钮、链接往往各有各的颜色，加在一起就失去了层次。控制颜色最有效的办法是给自己定一个小色板。

确定色板后，在提示词里明确声明：全文只使用这些颜色，其它颜色一律从它们衍生。这句话能避免 AI 在各个组件里自由发挥。例如“主色为 #C8553D，文字色为 #1F1E1D 和 #6B6B6B，背景色为 #F4F1EA，其它颜色不要使用”。

5.2 字体与排版

字体是设计感的重要组成部分，但对中文网站来说要权衡性能和可读性。从外部字体服务加载中文字体会明显拖慢首屏速度，因为中文字体文件体积大。比较稳妥的做法是：标题使用自定义字体或衬线字体，正文使用系统字体栈。

:root { --font-title: "Georgia", "Noto Serif SC", "Source Han Serif SC", serif; --font-body: -apple-system, BlinkMacSystemFont, "Segoe UI", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", sans-serif; }

字号和行高可以直接写进提示词。正文 16px 到 18px、行高 1.6 到 1.8 是比较稳妥的阅读配置；标题可以按层级从 32px 到 96px 逐级放大。给出行号和行高后，AI 生成的正文排版质量会稳定很多。

5.3 动效与交互反馈

动效应该服务于交互反馈，而不是装饰。悬停、点击、滚动进入视口是三个最常见的动效场景。悬停反馈通常用于按钮、卡片、链接，时间控制在 150ms 到 250ms；滚动进入视口的动画建议控制在 300ms 到 500ms，位移不要太大，否则会显得拖沓。

@media (prefers-reduced-motion: reduce) { *, *::before, *::after { animation-duration: 0.01ms !important; animation-iteration-count: 1 !important; transition-duration: 0.01ms !important; scroll-behavior: auto !important; } }

这段代码是动效设计里的一个基础保险。它让偏好减少动态效果的用户直接关闭动画，避免眩晕和不适。在提示词里要求 AI 加上这个媒体查询，比后面自己手动补要省事得多。

5.4 图片、留白和间距

设计感很多时候不是来自复杂的视觉元素，而是来自留白和间距的一致性。先把间距系统定下来，比如基础单位 8px，区块间距 96px，卡片间距 32px。这个系统可以直接写进提示词，AI 生成的页面就不会出现“有的地方挤在一起、有的地方空一大片”的问题。

图片方面，个人网站往往被忽视的是体积。建议要求 AI 使用next/image或等效的懒加载方案，图片统一放在public/images目录，并给每张图片加上合理的alt文本。原图导出时压缩成 WebP 或 AVIF 格式，首屏加载速度会有明显提升。不要直接在页面上引一个几十 MB 的 JPG 原图。

6. 本地验证、构建与部署上线

6.1 本地运行与视觉验证

开发服务跑起来以后，验证不能只看“页面在不在”。建议按三层来检查。

第一层是运行检查：浏览器打开http://localhost:3000后，控制台是否有红色报错，网络面板里是否有明显请求失败。第二层是内容检查：所有文字是否是你自己准备的资料，链接是否指向正确地址，社交图标点击后是否正确跳转。第三层是视觉检查：在桌面、平板、手机三种宽度下分别浏览，确认没有横向滚动条、文字没有重叠、图片没有变形。

一个容易被忽略的动作是强制刷新。迭代多次后，浏览器缓存可能让你看到的还是旧版本。快捷键Ctrl+Shift+R（Windows）或Cmd+Shift+R（Mac）可以跳过缓存重新加载，排查“我改了但看不到变化”问题时先做这一步。

6.2 响应式检查清单

响应式是个人网站最常出问题的地方。下面的清单可以作为每次改完布局后的固定检查项目。

除了宽度，还要检查横向滚动。可以把浏览器窗口拖到很窄，然后水平拖动页面，看看是否有内容把页面撑出屏幕。常见原因是代码块、大图、长表格缺少max-width: 100%处理。这个问题在移动端非常明显，一旦发现要让 AI 全局处理，而不是只改某一个组件。

6.3 构建产物与托管平台部署

本地验证通过后，需要执行生产构建，确认项目能正常产出部署产物。

npm run build npm run start

构建阶段能发现类型错误、静态生成问题和依赖缺失。构建成功的项目，再进入部署环节。常见的前端托管平台包括 Vercel、Netlify、Cloudflare Pages，它们都支持从 Git 仓库自动部署。连接仓库后，平台会自动识别项目框架，读取构建命令和输出目录。

学习环境和生产环境的差异在这里体现出来。学习阶段部署到免费托管平台即可，不需要关心服务器配置；生产环境则需要额外考虑自定义域名、HTTPS 证书、环境变量管理、部署失败回滚、访问日志和监控。个人网站虽然简单，但一旦要正式对外展示，这些都不能省略。部署后要访问正式域名验证一遍，不要只在本地确认过就结束。

7. Vibe Coding 常见问题与排查路径

7.1 常见问题速查表

Vibe Coding 过程中会遇到一些比较固定的问题。整理成速查表，方便遇到现象时直接对照。

7.2 从现象倒推根因的排查顺序

遇到问题不要急着让 AI 重新生成整个页面。按下面的顺序排查，大多数问题能更快定位。

先查输入：提示词里是否遗漏了关键约束，或本轮要求是否和上一轮冲突。再查本地：文件是否保存、开发服务是否还在运行、改动是否真的写进了目标文件。然后查运行：打开浏览器控制台，看有没有 JavaScript 报错和请求失败。接着查构建：执行npm run build，确认没有类型错误或静态生成错误。最后查部署：检查部署平台的构建日志、框架识别、输出目录和环境变量。

这个顺序从“成本最低”的检查开始，逐步深入到链路后端。大多数 Vibe Coding 翻车现场，其实都卡在前两步：要么是提示词要求不明确，要么是本地文件没改对。

7.3 三个典型翻车场景

翻车场景一：AI 生成了大量“包装代码”。很多助手会额外创建不必要的工具函数、配置文件、类型定义。代码量膨胀后，后续修改的上下文越来越乱，AI 的改动精度也越来越低。解决办法是在提示词里加一句“只实现最小可运行版本，不要创建额外抽象层”。

翻车场景二：设计元素堆砌。一个页面里既有大面积渐变，又有玻璃拟态，又有动画特效，还叠加了多种字体。设计感的核心是克制，而不是堆料。遇到这种情况，减少风格关键词，统一色板，把动画只保留在交互反馈场景里。

翻车场景三：把密钥和敏感信息写进代码。AI 可能在示例代码里加上 API Key、数据库地址等占位内容，也可能帮你在配置里写死某个真实密钥。个人项目里一旦密钥推到公开仓库，就会成为安全隐患。生产环境必须使用环境变量管理敏感配置，并把.env加入.gitignore。

8. 从能用到好用：检查清单与边界意识

8.1 Vibe Coding 提示词检查清单

每次写提示词之前，过一遍下面的清单，能显著提高生成质量。

• 是否明确技术栈和框架版本约束。
• 是否列出页面全部模块及其顺序。
• 是否指定主色、辅助色、文字色等具体色值。
• 是否指定字体、字号、行高、间距等排版参数。
• 是否说明本轮优化的边界，避免一次改太多。
• 是否列出禁止事项，比如“不要引入 UI 组件库”“不要使用外部字体服务”。
• 是否在代码修改完成后主动要求 AI 检查控制台报错和响应式布局。

把这套清单保存到一个固定的文档里，之后每次使用 AI 辅助开发都能复用。比你每次重新组织语言要稳定得多。

8.2 哪些环节必须自己把关

AI 能生成页面，但不能替你负责工程质量。下面几个环节必须人工把关。

依赖安全：AI 引入的 npm 包要确认是否存在、是否被维护、是否需要额外权限。敏感信息：密钥、令牌、内部地址不能出现在代码仓库里。无障碍：图片有没有alt文本、按钮有没有可识别的名称、键盘能否完成所有操作。浏览器兼容：在 Chrome、Safari、Firefox 里分别看一遍，不能只在某一个浏览器上确认通过。SEO 基础信息：页面标题、描述、结构化数据要自己检查。

生产环境还要额外考虑日志、错误边界、性能监控和回滚方案。个人网站虽然没有企业级复杂度，但“部署了就不管”和“部署后能观察、能回滚”是两种完全不同的工程水平。

8.3 下一步扩展方向

首页稳定后，可以让网站向三个方向扩展。内容方向：增加博客文章列表和文章详情页，接入 Markdown 或 CMS，让内容更新不再依赖改代码。体验方向：实现暗色模式、多语言切换，这些都很适合继续用提示词迭代，但要注意每加一个功能都回到“小步验证”的节奏。运营方向：补充 SEO 元信息、站点地图、Open Graph 分享图，让链接粘贴到社交平台时有完整预览。

如果要在其它技术生态里继续实践 Vibe Coding，思路同样适用：先确认 AI 助手对目标语言和框架的熟悉度，再从最小页面开始，用同样的“定义结构、描述视觉、小步迭代、检查验证”流程推进。用 Vibe Coding 的核心能力不是把需求说清楚，而是在每一次迭代中保持对结果的判断力，把所有代码最终变成自己能解释、能修改、能维护的东西。