别被 Google I/O 骗了：我用 Vibe Coding 写了一个真项目，发现全是官方没演的坑

“AI 给我生成了 200 行代码，我盯着终端的报错信息看了 40 分钟，最后发现问题出在我的需求描述里。”

如果你最近关注科技圈，一定被 Vibe Coding（氛围感编程） 这个词刷屏了。这个由前特斯拉 AI 总监 Andrej Karpathy 炒热的词，在近期的 Google I/O 大会上被彻底推上了主角位置。

在 Google 的演示里，开发者只需要像产品经理一样动动嘴，AI 就能在几分钟内把一个复杂的应用搭建出来。你不需要懂 git，不需要懂 npm install，甚至不需要懂什么是 async/await。你只需要负责“指点江山”，剩下的交给 AI。

但现实真的有这么美好吗？

为了验证 Vibe Coding 是通往人人皆可编程的“银弹”，还是又一个被资本包装出来的“PPT 概念”，我决定亲自下场。不用官方精心准备的玩具 Demo，而是用真实的开发环境，去写一个真正需要接入外部 API 的实用工具。

结果是，我确实把东西做出来了，但也踩了一脚的泥。

---

一、 Google 为什么力推 Vibe Coding？

在聊我的踩坑经历之前，我们先得厘清一个概念：Vibe Coding 和我们之前用的 AI 辅助编程（比如 Copilot 自动补全）有什么区别？

传统的 AI 辅助编程，你是司机，AI 是副驾驶的导航员。你写一行，它猜下一行。你必须懂代码，才能判断它写得对不对。

而 Vibe Coding 的逻辑是：AI 是司机，你是坐在后座指路的乘客。

+-------------------------------------------------------------+
|                     Vibe Coding 工作流                      |
+-------------------------------------------------------------+

|   [ 用户 ] --( 描述意图 / 提需求 )--> [ AI 代理 (Agent) ]    |
|      ^                                     |                |
|      |                                   ( 生成/修改代码 )  |
|      |                                     v                |
|   [ 运行结果 ] <--( 浏览器/终端运行 )-- [ 运行环境 ]        |

+-------------------------------------------------------------+

你描述意图，AI 负责生成完整的代码并尝试运行，你只负责看结果是不是你想要的，然后用自然语言继续微调。

Google 如此大力推崇这个概念，核心目的就是为了推广其围绕 Gemini 展开的开发者生态（如 Project IDX 和 Jules）。他们试图向世界证明：有了足够聪明的长文本大模型，编程的门槛已经被降到了“只要会说话就能写软件”的程度。

但这套逻辑里隐藏了一个致命的假设：AI 永远能完美理解你的意图，且开发环境永远不会报错。

---

二、实验设定：一个「真实但不复杂」的 Demo 目标

为了不让这次测试变成“Hello World”式的过家家，我设计了一个具有一定复杂度的任务：

* 项目名称：GitHub 个人仓库数据可视化看板

* 核心功能：

1. 用户输入 GitHub 用户名，调用 GitHub API 获取其公开仓库列表。

2. 过滤掉 Fork 的仓库，只保留原创项目。

3. 使用 Chart.js 绘制两个图表：一个是“仓库语言分布比例（饼图）”，另一个是“Top 5 热门项目 Star 走势（条形图）”。

4. 界面要干净现代，支持响应式。

* 工具链：Gemini 3 Pro + Project IDX。

* 难点：涉及第三方 API 鉴权、异步数据处理、图表库的生命周期管理、以及前端布局。

这个任务非常典型，是很多初学者或非技术人员想写来自己用的工具，也是企业内部小工具的缩影。

---

三、全流程实录：160分钟的爱与痛

我记录了整个开发过程的真实耗时与卡点，以下是无滤镜的实操记录。

Step 1：提示词起草与首次生成

我给 Gemini 3 Pro 下达了第一条指令：

“帮我写一个单页网页，输入 GitHub 用户名后，能用 Chart.js 展示这个用户的仓库语言比例和 Star 最多的前5个项目。界面要用 Tailwind CSS 显得现代一些。”

AI 响应极快，不到 10 秒就生成了一份包含 HTML、CSS 和 JavaScript 的单文件代码。

但我一运行，页面直接白屏。打开控制台一看，报错信息赫然在目：

Uncaught ReferenceError: Chart is not defined 原因分析：AI 把 Chart.js 的 CDN 链接放在了页面底部，而初始化图表的 JS 代码却写在了前面。这是非常低级的顺序错误。

💡 实验中途发现的一个细节：Gemini 在处理需要频繁修改和调试的代码时，如果直接在网页端复制粘贴会非常繁琐。我切换到了通过 [api.884819.xyz](https://api.884819.xyz) 调用的方案。这个平台支持直接用 OpenAI 标准格式调用各种主流模型，对 Vibe Coding 这种需要频繁切换模型（比如从 Gemini 切换到 DeepSeek R1 寻找不同解法）的场景非常方便。

平台不需要邮箱验证，用用户名和密码就能快速注册。新用户注册即送体验token。 而且里面的国产模型完全免费，没有月租和订阅限制，全部按量付费，非常适合开发者折腾。

* 本步耗时：25 分钟（主要花在调试提示词和解决首次生成的低级错误上）

* 死亡风险评级：⭐⭐☆☆☆（容易解决，但很消磨耐心）

---

Step 2：环境与依赖的“鬼打墙”

在解决了加载顺序后，我遇到了第二个大坑：GitHub API 的 Rate Limit（限流）。

因为没有配置 GitHub Token，我点了几次查询后，API 直接返回了 403 错误。我要求 AI：“帮我加一个配置 GitHub Personal Access Token 的输入框，并在请求头里带上它。”

AI 爽快地答应了，并重构了代码。然而，重构后的代码在 Project IDX 预览时，直接报了以下错误：

TypeError: Cannot read properties of null (reading 'getContext')
at updateCharts (index.html:84:38)
at async fetchUserData (index.html:56:13)

这个报错非常经典。AI 修改了 HTML 结构，把放进了一个默认隐藏的 div 里。当 JS 尝试去获取这个 Canvas 元素并初始化 Chart.js 时，DOM 节点还没被渲染出来。

以下是当时的代码对比：

// AI 生成的错误代码
function updateCharts(data) {
  const ctx = document.getElementById('langChart').getContext('2d'); 
  // 此时 canvas 元素因为 parent 处于 display:none 状态，返回了 null
+   new Chart(ctx, { ... });
}

// 我被迫手动接管修改后的代码
function updateCharts(data) {
+   const canvas = document.getElementById('langChart');
+   if (!canvas) return; // 增加防御性编程，防止崩溃
+   const ctx = canvas.getContext('2d');
new Chart(ctx, { ... });
}

* 本步耗时：45 分钟

* 死亡风险评级：⭐⭐⭐⭐☆（不懂 DOM 加载机制的非程序员，在这里会陷入死循环，因为你不知道怎么向 AI 描述这个隐蔽的 DOM Bug）

---

Step 3：功能迭代时的“老年痴呆”

当基本功能跑通后，我希望加入一个新功能：“过滤掉所有 Fork 的仓库，并且点击图表柱状图时，能直接在新标签页打开对应的 GitHub 仓库链接。”

这是 Vibe Coding 最容易让人崩溃的阶段。

随着对话进入第 3 轮，Gemini 开始表现出“顾此失彼”的症状。它确实实现了点击跳转的功能，但在这个过程中，它悄悄把我上一轮让它加的 API Token 逻辑给删掉了，回退到了无 Token 版本的请求。

我不得不反复对它说：“请保留刚才的 Token 输入框，不要删掉它！”

* 本步耗时：60 分钟

* 死亡风险评级：⭐⭐⭐☆☆（AI 开始绕圈子，生成的代码改了 A 坏了 B）

---

Step 4：最后一公里，人工接管

最后，虽然核心逻辑通了，但页面的 UI 极其简陋，且没有做任何异常处理（比如输入不存在的用户名时，页面会无限加载转圈）。

我放弃了继续用自然语言折腾 AI，决定自己动手：

1. 手动写了 CSS，把图表容器做成了响应式网格布局。

2. 加上了 try...catch 逻辑，在请求失败时弹出友好的提示框。

3. 把 API Token 存入浏览器的 localStorage，避免用户每次刷新都要重新输入。

* 本步耗时：30 分钟

* 死亡风险评级：⭐⭐⭐⭐☆（如果完全不碰代码，这个产品将永远停留在“能跑但不好用”的半成品状态）

---

实验数据复盘

---

四、最容易死在哪一步？归因分析

通过这次实操，我发现 Vibe Coding 存在一个巨大的认知偏差。

Google 在 I/O 大会的 Keynote 上演示时，通常会使用类似下面的流程：

[ 需求描述 ] ───> [ AI 瞬间生成 ] ───> [ 完美运行 ]

但现实中，真实的 Vibe Coding 流程其实是这样的：

[ 需求描述 ]
│
▼
[ AI 首次生成 ] ───> ( 报错：依赖缺失/版本冲突 )
│
▼
[ 调整提示词 ] ───> ( 报错：DOM 未加载/逻辑冲突 ) ───> [ 陷入死循环 (高危死亡点) ]
│
▼
[ 手动 Debug ] ───> [ 最终勉强运行 ]

死亡率最高的地方，根本不是写代码，而是“环境配置”和“隐性 Bug 的定位”。

在 Google 的 Demo 里，底层的 Project IDX 环境是完全预配置好的，API 也是 mock 好的。但现实中，当你接入真实的 GitHub API、遇到跨域（CORS）问题、或是遇到 CSS 样式被覆盖时，AI 很难通过简单的截图或错误日志直接定位问题。

对于完全不懂代码的初学者，一旦遇到 Step 2 这种“代码看起来没问题，但就是跑不起来”的 DOM 渲染时序问题，除了放弃别无选择。因为你连如何向 AI 提问的专业术语都不知道。

---

五、给不同段位读者的实操建议

Vibe Coding 不是骗局，但它绝对不是“不用学编程”的借口。相反，它对人的“架构设计能力”和“Debug 敏感度”提出了更高的要求。

💡 避坑检查清单（建议收藏）

1. [ ] 从最小可行性（MVP）开始：不要一次性给 AI 输入 5 个需求，一次只做一个功能。

2. [ ] 保持环境干净：尽量使用单文件或模块化清晰的结构，方便 AI 理解。

3. [ ] 做好版本控制：AI 每生成一个能跑的版本，立刻 git commit。相信我，它下一秒就会把这个版本改坏。

4. [ ] 显式声明依赖：在 Prompt 里明确指定库的版本和加载顺序，减少 AI 犯低级错误的机会。

5. [ ] 准备好接管：当一个 Bug 调试了 3 轮对话还没解决，立刻停止对话，手动看一眼代码。

针对不同人群的建议：

* 小白用户：不要指望用 Vibe Coding 直接写大型应用。把它当成你的“超级草稿纸”。用它来快速生成一个 HTML 页面或一段算法，然后去理解它是怎么运行的。

* 中级用户：学会识别 AI 开始“胡言乱语”的信号。一旦发现 AI 开始遗忘之前的设定，说明上下文窗口已经过载或被污染，此时应该开一个新对话，把当前的代码贴给它，并重新简述规则。

* 进阶用户：Vibe Coding 的真正价值是极速原型验证。用它在 10 分钟内验证一个想法是否可行，如果可行，立刻转入正规的工程化开发，不要让 AI 决定你的系统架构。

---

下一篇我想测的问题是：

Vibe Coding 做出来的 Demo，代码质量到底有多烂？

我找了一位工作了 10 年的资深后端工程师，让他 Code Review AI 帮我生成的这段代码——

他的第一反应是：“这玩意居然能跑？但凡并发超过 10，你的服务器就炸了。”

→ 如果你也好奇「能跑」和「能用」之间到底差了多少个重构期，关注 8848AI，我们下周见。

本文由8848AI原创，转载请注明出处。关注8848AI，带你从零开始学AI。

#VibeCoding #GoogleIO #Gemini #人工智能 #编程教程 #8848AI #AI学习