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 生成开发者修改和验收控制粒度每一行都可精确控制通过提示词和反馈间接控制迭代速度修改一个布局通常要改多处代码一次反馈就能触发整体调整风险位置逻辑复杂时容易出错代码质量、可维护性、安全隐患容易被忽视适合场景复杂业务、强一致、高并发系统原型、个人站、落地页、内部工具这个对比说明一个关键结论Vibe Coding 的优势是快速产出可运行、可看的界面代价是开发者必须承担检查、定位、修正的责任。你不能只负责提需求然后把所有代码都当成黑盒。框架版本、依赖安全、数据格式、浏览器兼容这些问题都不会因为代码由 AI 生成就自动消失。1.3 个人网站为什么是 Vibe Coding 的最佳练习对象个人网站具备几个非常适合 Vibe Coding 的特点。第一规模可控。一个典型的个人网站通常只有三到五个核心区块不涉及复杂的事务、权限和并发逻辑即使 AI 生成的结果不理想重做的成本也不高。第二视觉主观。个人网站的美感判断很依赖个人偏好用自然语言描述“再留白一点”“标题再大一点”“颜色太跳了”非常自然这种主观反馈恰好是对话式开发最擅长的。第三反馈闭环快。本地起一个开发服务改完立刻能看视觉问题比逻辑问题更容易被识别和描述。不过要提醒一句Vibe Coding 适合个人网站不代表所有网站都适合。需要强一致性的支付系统、需要精细权限控制的业务后台、需要严格数据校验的企业应用不建议用这种方式从零生成。它的定位是“快速做出可用的界面和原型”而不是替代严谨的工程流程。2. 开工前先定设计目标和信息架构2.1 个人网站通常包含哪些模块很多人在第一轮提示词里只写“做一个好看的个人网站”然后让 AI 自由发挥。这样得到的结果往往内容杂乱、结构失衡因为 AI 并不知道哪些信息对你最重要。正确做法是先决定页面包含哪些模块。个人网站常见的模块如下模块作用优先级Hero 首屏名字、一句话介绍、视觉焦点高作品集 / 项目展示做过的事情个人网站的核心支撑高关于我个人背景、技能、经历中博客 / 文章沉淀内容持续更新中联系方式邮箱、社交链接、联系按钮高技能 / 服务列出能力范围或可提供的服务低建议先选三到五个模块不要贪多。首屏、作品、关于、联系是大多数个人网站的地基。先把这些模块排好顺序再让 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 -vNode.js 版本以当前项目要求为准常见的前端项目建议使用 LTS 版本。版本过低时依赖安装和构建过程可能报错。初始化项目时最常用的方式是使用官方脚手架。以 Next.js 为例npx create-next-applatest 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 默认生成的页面里背景、卡片、边框、按钮、链接往往各有各的颜色加在一起就失去了层次。控制颜色最有效的办法是给自己定一个小色板。色彩角色作用建议数量主色品牌标识、标题、核心按钮1 个辅助色次要元素、标签、边框1 到 2 个文字色正文、标题文字2 个深色 灰色背景色页面和区块背景1 到 2 个确定色板后在提示词里明确声明全文只使用这些颜色其它颜色一律从它们衍生。这句话能避免 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后控制台是否有红色报错网络面板里是否有明显请求失败。第二层是内容检查所有文字是否是你自己准备的资料链接是否指向正确地址社交图标点击后是否正确跳转。第三层是视觉检查在桌面、平板、手机三种宽度下分别浏览确认没有横向滚动条、文字没有重叠、图片没有变形。一个容易被忽略的动作是强制刷新。迭代多次后浏览器缓存可能让你看到的还是旧版本。快捷键CtrlShiftRWindows或CmdShiftRMac可以跳过缓存重新加载排查“我改了但看不到变化”问题时先做这一步。6.2 响应式检查清单响应式是个人网站最常出问题的地方。下面的清单可以作为每次改完布局后的固定检查项目。视口宽度检查重点375px手机导航是否折叠、网格是否单列、触控目标是否不小于 44px768px平板网格是否两列、卡片是否等宽、文字是否可读1280px 以上桌面内容最大宽度是否限制、留白是否均衡、Hero 是否醒目除了宽度还要检查横向滚动。可以把浏览器窗口拖到很窄然后水平拖动页面看看是否有内容把页面撑出屏幕。常见原因是代码块、大图、长表格缺少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 过程中会遇到一些比较固定的问题。整理成速查表方便遇到现象时直接对照。问题现象常见原因排查动作处理建议AI 总是不按提示词改提示词里的约束太多或前后矛盾检查本轮是否只要求改一类问题拆分成小步骤一次反馈只聚焦一个维度修改后页面没变化浏览器缓存、热更新失效、改错文件强制刷新确认改动落在哪个文件重启开发服务确认文件路径正确样式不生效或串样式CSS 类名冲突、全局样式覆盖局部样式打开 DevTools 检查元素的计算样式要求 AI 使用 CSS Modules 或加强选择器约束图片不显示图片路径错误、文件名大小写不匹配查看网络面板的图片请求状态确认静态资源目录和引用路径一致本地正常部署后 404部署平台未识别路由或输出目录配置错误查看构建日志和平台的路由配置按平台文档确认框架识别和构建输出目录页面加载很慢图片未压缩、字体外链过多、JS 包过大用 Lighthouse 检测性能压缩图片、限制自定义字体、移除未使用依赖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 的核心能力不是把需求说清楚而是在每一次迭代中保持对结果的判断力把所有代码最终变成自己能解释、能修改、能维护的东西。