gaoqiongxie 来源: Andrej Karpathy 2026 年 viral 演讲 + 社区最佳实践 + Anthropic 官方安全建议
发布时间: 2026-08
理念: "让 AI 帮你把想法吹成气球，但你自己决定它该飞向哪里。"
🌊 Vibe Coding — 自然语言驱动开发实战
把模糊的想法通过自然语言快速转化为可运行代码，再用结构化审查和重构把它从「一次性原型」变成「可维护的实现」。
什么时候用 Vibe Coding
| 场景 | 适合吗 | 说明 |
|---|---|---|
| 快速验证一个产品想法 | ✅ 非常适合 | 30 分钟出可点击原型 |
| 探索新技术/新库 | ✅ 适合 | 降低试错成本 |
| 内部工具/脚本 | ✅ 适合 | 快速解决自己的痛点 |
| 核心支付/安全模块 | ❌ 不适合 | 需要严格设计、审计和测试 |
| 大型架构重构 | ⚠️ 部分适合 | 先 vibe 出草案，再逐步工程化 |
一句话：Vibe Coding 是「第一版代码生成器」，不是「最后一版代码替代品」。
核心工作流：Vibe → Verify → Vulcanize
意图描述 (Vibe)
│
▼
快速原型 (Generate)
│
▼
护栏检查 (Guardrail)
│
▼
结构化审查 (Review)
│
▼
重构固化 (Vulcanize)
│
▼
交付 / 沉淀记忆
Step 1：意图描述（Vibe）
用一句话说清楚你要什么，而不是怎么实现：
❌ 差例子："用 React useState 写一个计数器组件"
✅ 好例子："做一个番茄钟，25 分钟倒计时，能暂停和重置，显示当前状态"
意图描述模板：
我要做一个 [产品/工具]，让 [目标用户] 能够 [核心动作]。
关键约束：
- 必须支持 [功能 A]
- 最好支持 [功能 B]
- 绝对不能 [风险点 X]
Step 2：快速原型（Generate）
让 AI 根据意图生成第一版代码。此阶段不纠结完美，目标是：
- 跑起来
- 核心流程通
- 验证可行性
建议一次只生成一个垂直切片：
- 先做「倒计时 + 开始/暂停」
- 再做「任务记录」
- 最后做「数据统计」
Step 3：护栏检查（Guardrail）
每次生成后强制过一遍检查清单：
| 检查项 | 问题 |
|---|---|
| 安全 | 有没有硬编码密钥、SQL 注入、XSS、越权漏洞？ |
| 正确性 | 边界条件处理了吗？空状态、错误状态呢？ |
| 可维护性 | 变量命名清楚吗？有没有魔法数字？ |
| 依赖 | 引入了不必要的包吗？版本锁定了吗？ |
| 测试 | 至少有一个 happy path 能手动跑通吗？ |
触发词："先检查一下这版代码的安全和边界问题"。
Step 4：结构化审查（Review）
激活 quality-gate 或 frontend-code-review / backend-change-flow，对 vibe 出的代码做正式审查：
输入："对刚才生成的代码跑一遍质量门控"
重点关注：
- 类型安全
- 错误处理
- 性能热点
- 可访问性（前端）
- 边界条件
Step 5：重构固化（Vulcanize）
把原型代码改造为生产可接受的代码：
| 原型代码 | 重构后 |
|---|---|
| 所有逻辑写在一个文件 | 按职责拆分模块 |
| 硬编码配置 | 提取为常量/环境变量 |
| 内联样式 | 组件化 + 设计 tokens |
| 无错误处理 | 统一错误边界/Result 类型 |
| 无测试 | 补核心单元测试 |
重构原则：
- 一次只改一个维度
- 每次重构后运行测试
- 保留 vibe 阶段的语义，优化的是结构
Vibe Coding 安全守则
| ✅ 要做 | ❌ 不要做 |
|---|---|
| 在独立分支或 worktree 中 vibe | 直接在 main 分支生成核心模块 |
生成后立即运行 security-audit |
把生成的代码直接部署到生产 |
| 对写操作要求人工确认 | 让 AI 自动执行删除/转账/发邮件 |
| 把关键配置放在环境变量 | 把密钥写进 AI 生成的代码 |
| 小步快跑，频繁验证 | 一次性让 AI 写 1000 行再检查 |
使用示例
示例 1：30 分钟做一个番茄钟 Web 应用
用户：帮我 vibe 一个番茄钟网页应用
AI:
1. 意图确认：25 分钟倒计时 + 开始/暂停/重置 + 状态显示
2. 生成单文件 HTML + CSS + JS 原型
3. 护栏检查：无外部依赖、无敏感信息、边界条件 OK
4. 审查：激活 frontend-code-review 检查可访问性和语义化
5. 重构：拆分为 Timer / Controls / Status 三个组件
6. 交付：输出可部署的 index.html
示例 2：把 vibe 出的代码工程化
用户：刚才生成的这个 Python 脚本，帮我改得像人写的
AI（调用 stop-slop + opinionated-engineer）:
1. 去除 AI 填充语和过度注释
2. 添加类型注解
3. 把全局变量改为函数参数
4. 添加错误处理和日志
5. 写出 pytest 单元测试
示例 3：Vibe + MCP 联动
用户：我想做一个能查询我项目 Issue 的 AI 助手
AI:
1. Vibe 阶段：快速生成一个 CLI 原型
2. 接入 mcp-builder：把 GitHub Issues API 封装为 MCP Tool
3. 测试：在 Claude Code 中通过自然语言查询 Issue
4. 固化：补充错误处理、分页、缓存
快速入口
"vibe 一个 xxx" → 从想法到可运行原型
"帮我把这个想法变成代码" → 意图澄清 + 快速生成
"检查一下刚才生成的代码" → 护栏检查
"这版代码太 AI 了" → 调用 stop-slop 去 AI 味
"把原型改得像工程代码" → 重构固化 + opinionated-engineer
"vibe 完怎么保证质量" → Vibe → Verify → Vulcanize 全流程
与其他 Skill 的关系
| Skill | 关系 | 协作场景 |
|---|---|---|
| stop-slop | 重构伙伴 | 去除 vibe 生成代码中的 AI 味和套话 |
| opinionated-engineer | 工程化伙伴 | 强制类型安全、错误处理、生产级标准 |
| quality-gate | 质量保障 | 对 vibe 出的代码跑提交前五维检查 |
| frontend-code-review | 前端审查 | vibe 出的前端代码做结构化 review |
| backend-change-flow | 后端审查 | vibe 出的后端代码按变更流程对齐 |
| security-audit | 安全审查 | 识别生成代码中的常见漏洞 |
| mcp-builder | 能力扩展 | 把 vibe 出的原型封装成 MCP Tool 供 AI 调用 |
| solo-parallel-dev | 工作模式 | 在独立 worktree 中 vibe，避免污染主分支 |
最佳实践链：
brainstorming（头脑风暴需求）
→ vibe-coding（快速原型）
→ security-audit（安全检查）
→ quality-gate（质量门控）
→ stop-slop + opinionated-engineer（重构固化）
→ testing-patterns（补测试）
→ create-pr（生成 PR）
一句话原则
Vibe Coding 的终点不是「代码生成」，而是「快速验证想法」。真正值钱的不是第一版代码，而是你在验证过程中搞清楚的需求和约束。