Vibe Coding 实测报告：我把 Google I/O 的 Demo 从头跑了一遍，记录每一个卡壳时刻

发布会上那个 Demo 我看了三遍，第三遍我决定自己跑一次。

Google I/O 上的 vibe coding 演示真的很好看——工程师用自然语言描述需求，Gemini 实时生成代码，Firebase Studio 一键部署，全程不到十分钟，台下掌声雷动，弹幕飘满"程序员要失业了"。

但我在发布会结束后做了一件事：打开终端，克隆官方示例项目，从零开始复现。

我不是要泼冷水。我只是想知道，那十分钟的 Demo 背后，有多少是剪辑过的，有多少是真实可复现的，又有多少坑是他们没展示出来的。

这篇文章是我的全程记录——不剪辑失败片段，不美化卡壳时刻。

---

测试环境说明

在开始之前，先交代清楚测试条件，方便你判断结论的适用范围：

• AI 工具链：Gemini 2.5 Pro（通过 API 接入）+ Firebase Studio（官方 IDE）
• 示例项目：Google I/O 官方推荐的全栈 Web App——一个带用户认证、数据库读写、实时更新功能的任务管理应用
• 评判维度：每个环节的实际耗时、卡壳次数、需要人工兜底的节点
• 我的背景：有三年全栈开发经验，熟悉 React + Node.js，对 Firebase 了解但不深入

这个背景很重要。如果你是完全的小白，结论可能更悲观；如果你是资深工程师，可能比我跑得更顺。

---

第一章：真的省了时间的三个环节

跑完整个项目，我承认：有几个环节，AI 的表现是真实的生产力提升，不是噱头。

① 脚手架初始化：30 分钟 → 3 分钟

这是 vibe coding 目前 ROI 最高的场景，没有之一。

我对 Gemini 说的原话是：

"帮我创建一个 React + Firebase 的全栈项目，需要用户认证、Firestore 数据库、Cloud Functions，用 TypeScript，加上 ESLint 和 Prettier 配置，环境变量用 .env.example 管理。"

三分钟之内，我得到了：

• 完整的目录结构（src/components、src/hooks、src/services 分层清晰）
• package.json 依赖已配置，版本号没有冲突
• .env.example 模板，变量命名规范
• Firebase 初始化文件，包含 Auth、Firestore、Functions 的标准接入代码
• ESLint + Prettier 配置文件，规则合理

传统方式做这些，我估计要 30 分钟——查文档、解决依赖版本冲突、手写配置文件，这些体力活加起来很磨人。AI 把这个过程压缩到了 3 分钟，而且生成的结构比我平时手写的还要规范。

⚠️ 以上耗时为我个人实测估算，不同熟练度的开发者会有差异，仅供参考。

文中测试用的 Gemini 2.5 Pro API，我走的是 [api.884819.xyz](https://api.884819.xyz) 的聚合接口——国内直连、按量计费，不用自己翻墙配代理，跑完整个示例项目的 token 消耗折合不到 5 块钱。如果你想自己复现今天的测试，这是目前我用过最省事的接入方式。新用户注册即送体验 token，国产模型（Deepseek/千问等）完全免费，没有月租。

② UI 组件：自然语言 → 可运行代码

我描述了一个任务卡片组件：

"一个任务卡片，显示任务标题、截止日期、优先级标签（高/中/低，用不同颜色区分）、完成状态复选框，点击卡片展开详情，支持 hover 状态。"

AI 生成的代码大概是这个样子：

// TaskCard.tsx - AI 生成版本（已简化展示）
interface TaskCardProps {
task: {
id: string;
title: string;
dueDate: Date;
priority: 'high' | 'medium' | 'low';
completed: boolean;
description?: string;
};
onToggle: (id: string) => void;
}

const priorityConfig = {
high: { label: '高优先级', className: 'bg-red-100 text-red-700' },
medium: { label: '中优先级', className: 'bg-yellow-100 text-yellow-700' },
low: { label: '低优先级', className: 'bg-green-100 text-green-700' },
};

export const TaskCard: React.FC = ({ task, onToggle }) => {
const [expanded, setExpanded] = useState(false);
const priority = priorityConfig[task.priority];

return (
className={rounded-lg border p-4 cursor-pointer transition-shadow hover:shadow-md ${

task.completed ? 'opacity-60' : ''
}}
onClick={() => setExpanded(!expanded)}
>

type="checkbox"

checked={task.completed}
onChange={(e) => {
e.stopPropagation();
onToggle(task.id);
}}
className="w-4 h-4"
/>
font-medium ${task.completed ? 'line-through' : ''}}>
{task.title}

ml-auto text-xs px-2 py-1 rounded-full ${priority.className}}>
{priority.label}


{/ 展开详情部分省略 /}

);
};

视觉还原度大概 80%——主要交互逻辑正确，样式需要微调，但作为起点完全够用。这个组件如果手写，我估计要 45 分钟；AI 生成加上我的微调，8 分钟搞定。

③ CRUD 路由：模式化代码的天堂

数据库读写、API 路由这类高度模式化的代码，是 AI 目前最擅长的领域。

我让 AI 生成 Firestore 的任务 CRUD 接口，它给出的 Cloud Functions 代码几乎零错误——增删改查逻辑完整，错误处理有基本框架，类型定义也到位。

查文档、写样板、处理 SDK 版本差异——这些过去最让我头疼的体力活，AI 全包了。

---

第二章：必须自己兜底的三个环节

说完省时的部分，该说说让我真正皱眉头的地方了。

① 边界条件：主路径没问题，异常处理是筛子

AI 生成的 CRUD 代码，主路径跑得很顺。但我跑测试的时候，第一个错误在 20 分钟内就出现了：

FirebaseError: Missing or insufficient permissions.

原因是 AI 生成的 Firestore 安全规则没有处理"用户只能访问自己的数据"这个场景——它写了认证检查，但忘了加用户 ID 的匹配校验。

更麻烦的是，我把报错贴给 AI 让它修复，它给了我这个：

// AI 建议的"修复"——实际上是个安全漏洞
allow read, write: if request.auth != null;

这个规则的意思是：只要登录了，就能读写所有数据。它修复了报错，但引入了一个更大的安全漏洞——任何登录用户都能看到别人的任务。

这不是 AI 犯蠢，这是它的工作方式决定的：它优化的是"让代码跑通"，不是"让代码安全"。边界条件、安全约束、业务规则——这些需要你自己盯着。

正确的规则应该是：

// 人工修正版本
allow read, write: if request.auth != null
&& request.auth.uid == resource.data.userId;

一行代码的差距，但背后是完全不同的安全模型。

② 跨文件上下文：超过 10 个文件就开始"失忆"

这是我踩到的最深的坑，也是目前 vibe coding 最大的工程化天花板。

项目跑到第三天，文件数超过了 15 个。我让 AI 修改 taskService.ts 里的数据格式（把 dueDate 从 string 改成 Date 对象），它改完了，代码也能编译。

但两小时后，我发现 TaskCard.tsx 渲染出来的日期全是 Invalid Date。

原因是：TaskCard.tsx 里有一段格式化日期的代码，依赖的是 dueDate 是字符串的假设。AI 改了数据源，但没有同步更新消费这个数据的组件——因为它在修改 taskService.ts 的时候，已经"忘了" TaskCard.tsx 里有这段逻辑。

这个 Bug 我花了将近一个小时才定位到。

// taskService.ts 修改后（AI 做的）
interface Task {
dueDate: Date; // 从 string 改成了 Date
}

// TaskCard.tsx 里没被更新的代码（AI 忘了）
const formattedDate = new Date(task.dueDate).toLocaleDateString();
// 当 task.dueDate 已经是 Date 对象时，new Date(Date) 行为不一致
// 导致在某些浏览器出现 Invalid Date

这个问题在小项目里可以靠人工审查兜底，但随着项目规模增长，这种隐性耦合会越来越多，越来越难追踪。

③ 性能调优：能跑但不够好

AI 给我生成的 Dockerfile 可以用，但有几个明显的优化点它没考虑：

• 没有多阶段构建，镜像体积偏大
• node_modules 没有利用 Docker 层缓存，每次构建都要重新安装依赖
• Firebase Hosting 的缓存策略用的是默认值，静态资源没有设置长期缓存头

这些不是致命问题，但在生产环境里，冷启动时间和缓存命中率直接影响用户体验。AI 给的建议停留在"能跑"的层面，"跑好"需要你自己有经验判断。

---

第三章：一张图看懂你该在哪里信任 AI

跑完整个项目，我把开发链路划分成了三个区域：

┌─────────────────────────────────────────────────────────────────┐
│                    开发链路三色图                                 │
├─────────────────┬───────────────────┬───────────────────────────┤
│  🟢 AI 主导区   │  🟡 AI 辅助/人审核 │  🔴 人主导区              │
├─────────────────┼───────────────────┼───────────────────────────┤
│ • 项目脚手架    │ • UI 组件生成      │ • 安全规则设计             │
│ • 依赖配置      │ • 数据库 Schema    │ • 边界条件处理             │
│ • 环境变量模板  │ • API 路由框架     │ • 跨文件重构               │
│ • 样板代码      │ • 错误处理框架     │ • 性能调优策略             │
│ • 类型定义      │ • 测试用例生成     │ • 部署架构决策             │
│ • 文档注释      │ • 代码审查建议     │ • 数据一致性保证           │
└─────────────────┴───────────────────┴───────────────────────────┘

闭眼用，省时 90%    用了要审，省时 50%    AI 只是参考，别全信

这张图是我跑完整个项目之后最想留下来的东西。

---

第四章：给不同阶段读者的操作建议

如果你是小白

脚手架、样板代码、类型定义——这些地方 AI 几乎不会让你失望。先在这里建立信心，感受真实的效率提升，再慢慢进入黄色区域。

不要一上来就让 AI 帮你设计整个系统架构——那是红色区域，你还没有足够的判断力来审核 AI 的输出。

如果你是中级开发者

你有足够的经验判断 AI 给的代码是否正确，但可能还没有形成"每次都审"的习惯。建立一个检查清单：

• 安全规则有没有用户隔离？
• 异常处理覆盖了哪些情况？
• 这个修改会不会影响其他文件？

养成这个习惯，黄色区域的效率提升是真实的 50%+。

如果你是进阶用户

vibe coding 真正的价值是：用极低的成本验证一个想法是否可行。从零到一个能演示的原型，AI 可以帮你把时间从两周压缩到两天。

但从原型到生产，从两天到可维护的代码库——这段路程，AI 帮不了你太多。工程设计、架构决策、技术债管理，这些还是你的主场。

---

最后：校准期望值，是你现在就能做的事

我跑完这个项目之后，对 vibe coding 的判断是：

它不是魔法，也不是骗局。它是一把有射程限制的枪——在射程内，它比你快；超出射程，它会打到自己人。

发布会 Demo 展示的是绿色区域的极致表现，它没有展示黄色区域的审核成本，也没有展示红色区域的人工兜底。这不是欺骗，只是营销的正常逻辑。

你现在能做的事：把这张三色图打印出来，贴在显示器旁边。下次用 AI 写代码的时候，先问自己：这个任务在哪个区域？

这一个问题，能帮你避免 80% 的踩坑。

---

这次我测的是"从零到跑通"的阶段。但还有一个问题我没答：当项目从 Demo 规模长到真实生产规模，vibe coding 的这张三色图会怎么变？绿色区域会扩大，还是红色区域会反噬？

>

下一篇，我会用一个实际上线了 3 个月的产品来回答这个问题——哪些 AI 写的代码后来成了技术债，哪些意外地撑住了生产压力。那篇文章可能会颠覆你今天读完这篇之后的判断。

---

#VibeCoding #AI编程 #Gemini #Google #前端开发 #AI工具 #8848AI #程序员