第 15 章

Vibe Coding 实践指南——什么时候该用，什么时候绝对别用

第15章：Vibe Coding 实践指南——什么时候该用，什么时候绝对别用

本章学习目标：准确定义 Vibe Coding 的边界，而不是盲目跟风或全盘否定；掌握 3 类适合 Vibe Coding 的场景和 5 类绝对不适合的场景；完整复现一个 15 分钟 Chrome 扩展的 Vibe Coding 过程，包括实际遇到的问题；掌握上生产前必须过的安全检查清单。

Vibe Coding 是什么

Andrej Karpathy（特斯拉前 AI 总监、OpenAI 联合创始人）于 2025 年 2 月提出这个术语：

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. I just see prompts, the AI responds, I run the code, it works or I complain and it fixes it. I don't read the code at all."

— Andrej Karpathy, February 2025

核心特征：你描述期望的结果，AI 写代码，你不读代码，只看运行结果是否符合预期。出了问题就描述现象让 AI 修，直到跑通为止。

这和"用 AI 辅助写代码"的区别在于：辅助写代码时你仍然读、审查、理解每一行；Vibe Coding 完全跳过这个步骤。这带来极高的速度，也带来你需要清楚认识的风险。

适合 Vibe Coding 的 3 类场景

场景 1：个人工具和脚本

只有你自己用，没有其他用户，没有安全要求，能跑就行。这是 Vibe Coding 最纯粹的用武之地。

典型例子：

把 200 个 CSV 文件合并并去重
批量重命名图片（按日期/尺寸/内容）
从 YouTube 视频下载字幕并整理成文档
监控某个网页变化并发邮件通知
把 Notion 导出的 Markdown 批量转成 HTML

Vibe Coding 30 分钟做出来，比花 3 小时手写更合理。代码烂不要紧，用完即弃。

场景 2：原型和概念验证

目的是验证想法是否可行，不是上生产。如果方向错了，所有代码扔掉；如果方向对了，你有时间重写。代码质量此时完全不重要，快速跑通才是目标。

典型例子： 黑客马拉松项目、产品演示 Demo、A/B 测试某个交互方案、验证某个 API 集成是否可行。

场景 3：非核心功能的 UI 和工具页

产品的 Admin 后台、内部运营工具、一次性数据迁移脚本、员工内部使用的报表页。这些地方出 bug 影响范围有限，而且通常有运营人员在场，问题能被快速发现和反馈。

绝对不适合 Vibe Coding 的 5 类场景

场景	具体原因	真实后果
支付和金融计算	AI 可能用浮点数处理金额（如 `0.1 + 0.2 === 0.30000000000000004`），可能搞错退款/扣费逻辑	账目错误、资金损失、用户投诉
用户认证和权限	AI 可能漏掉权限检查，比如只验证"已登录"但不验证"有权访问这条记录"	越权访问、数据泄露
数据加密/解密	AI 可能用已知不安全的算法（MD5 存密码、ECB 模式加密），因为旧代码在训练数据里更多	密码被彩虹表破解、加密形同虚设
高并发核心逻辑	AI 可能引入竞态条件——比如"先查后改"而不是原子操作——在低并发下测试正常，高并发下崩溃	数据不一致、生产环境崩溃
涉及法规的功能	AI 不了解你所在行业的合规要求（GDPR 数据删除、金融报告格式、医疗数据隔离）	合规风险、罚款

判断标准： 问自己——"如果这段代码出了 bug，最坏的结果是什么？"回答是"功能暂时不可用，重部署就好"→ 可以 Vibe。回答是"用户数据泄露""财务损失""合规违规"→ 必须认真写、认真审查。

实战：15分钟 Vibe Coding 一个 Chrome 扩展

目标： 一键把当前页面的 URL 和标题发送到 Telegram Bot。

Composer Prompt

创建一个 Chrome 扩展，功能：点击扩展图标时，
把当前标签页的 URL 和标题发送到 Telegram Bot。

Telegram Bot Token 和 Chat ID 在扩展的 Options 页面配置，
保存在 chrome.storage.sync 里。

需要的文件：
- manifest.json (Manifest V3，不需要 background service worker)
- popup.html + popup.js (显示"发送中..."和成功/失败状态)
- options.html + options.js (配置 Bot Token 和 Chat ID，有保存按钮)

发送逻辑：调用 Telegram Bot API
  POST https://api.telegram.org/bot{TOKEN}/sendMessage
  body: { chat_id, text: "标题\nURL" }

发送成功显示绿色"已发送"，失败显示红色错误原因（如 Token 无效）。
不需要图标文件，manifest 里的 icons 留空数组。

AI 在约 90 秒内生成了 4 个文件。以下是实际运行时遇到的问题和解决过程：

遇到的问题 1：popup.js 调用了 chrome.tabs 但没有权限

加载扩展后，点击图标弹出窗口但立刻报错：Error: 'tabs' permission required。反馈给 AI："报错：tabs permission required。" AI 立刻在 manifest.json 的 permissions 数组里加了 "tabs"，重新加载扩展后解决。

遇到的问题 2：Manifest V3 不支持 remote code execution

AI 最初生成的 popup.js 里有 eval() 调用，Manifest V3 的 Content Security Policy 禁止这个。反馈给 AI，AI 把 eval() 替换成了正常的 JSON.parse()，问题解决。

// popup.js — AI 生成，经过两次修复
document.addEventListener('DOMContentLoaded', async () => {
  const status = document.getElementById('status')

  // 获取当前标签页信息
  const [tab] = await chrome.tabs.query({ active: true, currentWindow: true })

  // 从 storage 读取配置
  const { botToken, chatId } = await chrome.storage.sync.get(['botToken', 'chatId'])

  if (!botToken || !chatId) {
    status.textContent = '请先在设置页配置 Bot Token 和 Chat ID'
    status.style.color = '#f87171'
    return
  }

  status.textContent = '发送中...'
  status.style.color = '#a0aec0'

  try {
    const res = await fetch(
      `https://api.telegram.org/bot${botToken}/sendMessage`,
      {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
          chat_id: chatId,
          text: `${tab.title}\n${tab.url}`
        })
      }
    )

    const data = await res.json()

    if (data.ok) {
      status.textContent = '已发送'
      status.style.color = '#86efac'
    } else {
      status.textContent = `发送失败：${data.description}`
      status.style.color = '#f87171'
    }
  } catch (err) {
    status.textContent = `网络错误：${err.message}`
    status.style.color = '#f87171'
  }
})

时间线： 0:00 开始写 Prompt → 1:30 AI 生成完毕 → 2:00 加载扩展发现权限报错 → 2:30 反馈给 AI 修复 → 3:00 发现 eval() 报错 → 3:30 反馈修复 → 4:00 功能跑通 → 4:00–15:00 Code Review 和手动安全检查。

Code Review 发现了什么： AI 的实现整体是安全的——没有 XSS 风险（所有输出都是 textContent，不是 innerHTML），没有硬编码密钥，配置存在 chrome.storage.sync 里。唯一的轻微问题是错误信息直接展示了 API 返回的 description，可能包含敏感信息，但对个人工具来说可接受。

Vibe 到生产的检查清单

Vibe Coding 的输出要进生产，必须过这个清单：

安全（必须全部通过）：

无硬编码密钥：代码里没有 API Key、密码、Token、私钥
SQL 参数化：所有数据库查询用参数化语句，没有字符串拼接 SQL
用户输入验证：所有来自用户的输入都经过长度/格式/类型校验
无危险输出：没有 eval()，没有 innerHTML = 用户输入
认证检查：需要登录的接口在服务端验证了身份，不依赖客户端传来的 user_id

数据（必须）：

金额用整数：涉及金钱的计算用整数（分），不用浮点数（元）
重要操作有事务：多步骤写操作（扣库存+创建订单）包裹在数据库事务里

性能（建议）：

无 N+1 查询：没有在循环里查数据库
大列表有分页：返回列表的接口有 limit/offset 或 cursor 分页
错误有日志：catch 块里有 console.error 或 logger

混合策略：按风险级别决定方式

代码层次	推荐策略	示例
核心业务逻辑	手写 + AI 代码补全辅助	支付流程、权限系统、数据加密
功能模块	AI 生成框架，人工审查后接受	用户设置页、通知系统、搜索功能
工具函数	Vibe + 单元测试验证	日期格式化、数据转换、文本处理
UI 组件	纯 Vibe，看结果对不对	Loading spinner、Modal、表单组件
脚本/工具	纯 Vibe，跑通就行	数据迁移脚本、构建辅助工具

本章要点

Vibe Coding 的核心判断标准是风险，不是技术复杂度。 一个技术复杂的数据处理脚本可以 Vibe，一个简单的权限检查函数不能 Vibe——因为前者出错影响面小，后者出错影响用户数据安全。
5 类绝对不能 Vibe 的场景： 支付金融计算、用户认证权限、数据加密解密、高并发核心路径、涉及法规的功能。这 5 类出了问题，后果不是"功能暂时不可用"，而是财务损失、数据泄露或合规风险。
Vibe Coding 是工具加速器，不是学习捷径。 用 AI 直接生成代码而不理解，六个月后你面对这段代码还是一脸茫然。学习期间：先自己想方案，再看 AI 的方案，对比差异，理解原因。
Code Review 要在功能跑通后，不是之前。 Vibe 阶段先验证行为，行为对了再读代码——这是正确的顺序。
上生产前的安全检查不可省略： 无硬编码密钥、SQL 参数化、输入验证、无 eval()/innerHTML 注入、服务端认证检查。这 5 条是最低门槛，AI 不会主动提醒你全部做到。

本章评分

4.8 / 5 (16 评分)