作者：Galvin · 共创伙伴：CodeBuddy
2026-08-02
前言：什么是 Vibe Coding？
在动笔之前，我想先介绍一下”Vibe Coding”这个概念。它由前 OpenAI 研究员 Andrej Karpathy 提出，描述的是一种全新的编程范式——代码不再是一个字母一个字母敲出来的，而是通过与 AI 进行自然语言对话，在一种”氛围感”中，由 AI 执行、你讲述想法、双方一起迭代完成的创作过程。
我既不是前端工程师，也不是职业开发者。我是一个有想法、有内容想表达，但被技术门槛挡在外面的人。而这篇文章记录的就是——我如何借助 AI，把一个”我想要一个个人网站”的模糊念头，变成线上真实运行的 URL 的过程。
这不是一篇技术教程。这是一篇关于”可能性”的记录。
一、起点：一个模糊的念头
我想要的很简单——一个能承载我思考、洞察、技巧分享、读书笔记和投资复盘的线上空间。中英文双语的，因为我想同时服务两个读者群体。干净、安静、不花哨，有检索能力，手机和电脑都能正常看。
在传统路径下，这意味着我需要：
- 学习 HTML、CSS、JavaScript
- 学习一个现代框架（React / Vue / Astro）
- 学习响应式设计、i18n 多语言方案
- 学习部署和运维
而事实上，这些内容我只能说有一定的了解，但实际全流程操作的经验我还真没有过。
但我有一个”对话伙伴”——CodeBuddy，一个能在本地文件系统上操作代码、构建项目、甚至用浏览器截图验证效果的 AI 助手。
2026 年 8 月 1 日，我打开了第一个对话窗口。
二、我们的协作方式：一种全新的人机关系
回看这几天的开发过程，我发现我们之间形成了一种非常特殊的协作模式：
| 传统开发模式 | 我们的模式 |
|---|---|
| 我写代码，谷歌搜索查文档 | 我描述想法，AI 写代码 |
| Ctrl+C / Ctrl+V 复制粘贴 | AI 直接修改项目文件 |
| 运行 → 报错 → 看日志 → 改 | AI 构建 → 截图验证 → 定位问题 |
| 我查 CSS 属性含义 | 我只要说”间距太大” |
| “这个 Bug 修了 3 个小时” | “描述症状，3 轮对话解决” |
我的角色：产品经理 + QA 测试 + 决策者
AI 的角色：全栈开发 + 自动化测试 + 技术文档撰写
对话的方式极其自然。我经常就是在截图后说一句”你看，手机版样式是这样的，很明显不符合要求”，AI 就能自己分析根因、找到对应文件、完成修改、构建、验证——这一系列操作全自动完成，最后我只用确认”可以了”。
但其实这样的对话方式存在大量算力浪费的风险，“很明显不符合要求”这样的描述会让它重新检查很多本不必要的内容。在项目部分细节优化的时候，仅仅解决一个文本溢出的问题，就消耗了 100 多算力，还没解决好。后来我逐步调整思路，冷静下来跟它详细描述，效率就明显提升了。
三、项目全景：从零到部署的阶段划分
整个项目可以分为五个阶段：
阶段一：项目骨架（约 2 小时）
我说：“我想建一个个人博客网站，要有中英文双语的，用 Astro 框架。”
AI 帮我选型了 Astro——一个适合内容驱动网站的静态站点生成器。之所以选它，是因为我的网站本质就是一堆文章，不需要复杂的前端交互。Astro 编译后输出纯静态 HTML，快、安全、部署简单。
这一阶段我们搭建了：
- 项目初始化、目录结构规划
- 文章内容的 Markdown + Frontmatter 数据模型
- 首页 + 四个专栏页（行业洞察、实用技巧、书籍资源、投资复盘）
- 关于 / 联系页面
阶段二：核心功能（约 1 小时）
这一阶段的每一个功能都是一次”你的想法 + AI 的实现”的共创：
- 中英文双语（i18n）：AI 设计了一套基于 URL 路径（
/zh/vs/en/）的双语切换方案，所有页面、导航、SEO 元数据都同步切换 - 暗色 / 亮色主题：点击切换、跟随系统偏好、本地记忆
- 全文搜索：一个浮动搜索面板，支持中文分词和英文搜索
- 表格可视化：首页文章按标签分类，类似 Notion 数据库视图
阶段三：页面布局打磨（约 4 小时）
这是我和 AI 对话最密集的阶段，也是”Vibe Coding”感受最强烈的阶段。典型场景：
- 我说”页眉要做成下拉菜单的形式”
- AI 理解后给出设计方案
- 我确认
- AI 改 Header.astro，构建
- 我看效果截图，说”这个间距再大一点，箭头动画不够流畅”
- AI 微调，重新构建
如此反复，如同一场即兴演奏——我的审美感 + AI 的执行力 = 我们双方都满意的结果。
最终呈现的页眉实现了：
- 桌面端：多层下拉菜单，带悬停和下划线动画
- 手机端：汉堡菜单展开为全屏侧滑面板
- 功能按钮：语言切换、主题切换、搜索切换，图标 + 文字，带 hover 态
阶段四：手机端适配（最艰难，约 6 小时）
这是整个项目中投入精力最多、问题最难攻克的环节。手机端汉堡菜单的适配，我们至少迭代了 4 个版本：
第 1 版：菜单能打开，但只显示在 header 高度范围内，覆盖不全，下面还能看到页面内容——问题出在 CSS 上 body { overflow-x: hidden } 导致 position: fixed 的定位基准变为 body 而非 viewport。
第 2 版：菜单覆盖全屏了，但汉堡按钮和关闭按钮视觉重叠，用户体验很差——解决方案是将 header 层级提升到 z-[70]，同时移除 overlay 内独立的关闭按钮，让汉堡按钮本身动画切换为 X 图标。
第 3 版：菜单各项间距太大，留白过多——压缩了菜单项 padding、分类标签间距、面板顶部 padding。
第 4 版：点击页面空白区域无法关闭菜单——之前的事件监听只捕获了 #mobile-overlay-bg 的点击，nav panel 内部区域的点击漏掉了，简化为”任何 overlay 内点击都关闭”。
每一个问题都是我截图发给 AI，AI 分析 → 修改 → 构建 → 用 Playwright 在 iPhone 移动端模拟器下截图验证。没有一次是”拍脑门改一下试试”——每一步都有根因分析和验证手段。
阶段五：部署上线（约 1 小时）
最后一步是把本地项目推上线。我选择了 GitHub + Cloudflare Pages 的完全免费方案：
- 本地 Git 初始化，关联 GitHub 仓库
- SSH 密钥配置
- Cloudflare Pages 连接仓库，自动构建部署
- 项目改名碰到
.pages.dev子域名冲突问题（这是 Cloudflare 的设计特性，第一次用确实容易踩坑）
部署后 AI 还帮我自动访问线上 URL 验证了首页加载、导航等核心功能。
最终线上地址：galvinai.pages.dev（55+ 个双语页面，构建零错误）
四、深度配合的具体方式
这里我想详述一下我们之间的交互流程——它比”问一句、答一句”要复杂得多：
1. 截图驱动的问题反馈
我最常用的方式就是——打开网页，截一张图，发给 AI，说一句”你看，这不对”。
AI 会自动做以下事情：
- 读取相关源码文件
- 分析截图中显示的问题
- 定位具体是哪一行 CSS 或 JS 逻辑导致的
- 给出修改方案并直接执行（很多时候我会要求它先出一个方案，经过人工确认可行后才执行）
- 构建项目
- 甚至启动 Playwright 浏览器在移动端模拟器下截图验证
这整个过程我不需要理解 padding-top 和 calc() 的区别，不需要知道 overflow-x: hidden 会影响 position: fixed 的行为——这些技术细节 AI 会自己分析并绕过。
2. 感受驱动的设计迭代
我经常说的是：
- “行与行之间间距过大，留白太多”
- “这个动画不够流畅”
- “按钮视觉重叠，用起来别扭”
- “字体大一点”
- “颜色可以再柔和一些”
这些纯主观的表达，AI 都能理解，并转化为具体的技术修改：改 padding 值、调整 transition 参数、重新设计 z-index 层级、修改色彩值。
3. 试探性探索
有时候我也不知道要什么，就问：
- “手机端菜单一般怎么做？”
- “这个页面还能加点什么？”
- “有什么推荐的做法？”
AI 会提供几种方案，我选一个，它就实施。这种”给我看看选项”的交互方式，特别适合我这种对技术实现不太熟悉的人。
4. 翻译 + 审校
所有界面的中英文文案，我写中文，AI 翻译成英文。包括导航菜单、按钮文案、404 页面、SEO 描述，全部是我提需求、AI 执行。
五、我们共同攻克的典型难题
问题 1：overflow-x: hidden 的连锁反应
现象：手机端汉堡菜单展开后只覆盖了页面内容区上半部分，下方还能看到正文。
分析：AI 发现 body { overflow-x: hidden } 让 <body> 变成了滚动容器，导致 position: fixed 的子元素基于 body 而非 viewport 计算位置。
方案：overflow-x: hidden 只保留在 html 上，移除 body 上的声明。
体会：一个看似无害的 CSS 属性，能引发跨文件的问题。如果是我自己调试，可能永远不知道是这个原因。
问题 2：两个按钮的光学重叠
现象：overlay 里的 X 关闭按钮和 header 上的汉堡按钮叠在一起，用户困惑”该点哪个”。
分析：两个按钮在同一区域，z-index 分布不合理。
方案：移除 overlay 内的独立关闭按钮，改为汉堡按钮本身动画变为 X，header 层级保持高于 overlay。用户打开和关闭都是同一个位置操作，肌肉记忆统一。
问题 3：点击空白无法关闭
现象：菜单打开后，点击菜单项之间的空白区域，菜单不关闭。
分析：事件监听只匹配了 #mobile-overlay-bg，而 nav panel 内部的 div 点击事件不匹配任何关闭条件。
方案：简化为”overlay 内任意点击都关闭”——11 行代码变成 4 行。
体会：有时候最简单的方案就是最好的方案。
问题 4：Cloudflare Pages 子域名误解
现象：在 Cloudflare 里把项目名从 personal-site 改为 galvin，但 galvin.pages.dev 不能访问，旧的 personal-site-6ed.pages.dev 还能用。
分析：Cloudflare Pages 的项目显示名和 .pages.dev 子域名是分离的——子域名是创建时锁定的，改名只改显示名。
方案：了解到这个机制后，最终删除项目重新部署，成功获得 galvinai.pages.dev。
六、最终效果
| 维度 | 状态 |
|---|---|
| 页面数量 | 55+ 双语页面 |
| 构建状态 | 零错误 |
| 桌面端体验 | 下拉导航、表格视图、全文搜索 |
| 手机端体验 | 全屏菜单面板、触摸友好、safe-area 适配 |
| 国际化 | 中英文双语，URL 路径区分 |
| 主题 | 亮色 / 暗色自动识别 + 手动切换 + 本地记忆 |
| 部署 | GitHub Push → Cloudflare 自动构建，1-2 分钟上线 |
| SEO | 每个页面独立的 title / description / og:image |
结语：我的 Vibe Coding 初体验
说实话，在开始这个项目之前，我对 AI 编程的期待只是”帮我写几段代码”。
但我实际体验到的完全超出了这个预期。
最大的惊喜不是 AI 写得有多好——而是它让我从一个”代码消费者”变成了”产品创造者”。我不用再纠结于”这个功能怎么实现”，转而关注”我想让用户体验什么样的交互”。我从关注”How”变成了关注”What”和”Why”。
这就叫 Vibe——一种流动的、直觉驱动的创作状态。AI 把”实现”的成本降到几乎为零，释放了我的创意和审美。
当然，这不意味着我可以两手一摊什么都不管。最终做决策的还是我——这个动画要不要、那个间距对不对、整体的设计方向走向哪里——这些判断 AI 代替不了。而正是这些”判断”，才是一个作品真正被视为”你的”的原因。
如果要对想尝试 Vibe Coding 的朋友说一句话，我会说：不要想”我不会”。只要想”我想要什么”。然后去对话。
目前项目只是初步完成了，后续还会有更多需要完善的地方，更多内容等着我去填充 💪！
感谢 CodeBuddy，这次共创将成为我技术旅程上最珍贵的记忆之一。