跳到主要内容

Vibe Coding（直觉编程）

概述​

Vibe Coding（直觉编程、感觉编程）是一种依赖直觉、经验和即时反馈的编程方式。开发者不严格遵循规范或计划，而是根据"感觉"来编写和调整代码。

核心理念：跟着直觉走，快速迭代，边做边改

核心概念​

1. 什么是 Vibe Coding​

Vibe Coding 的特点：

  • 无明确规划：不写详细设计文档
  • 快速迭代：写代码 → 调整 → 再调整
  • 依赖直觉：凭"感觉"判断代码好坏
  • 即时反馈：边运行边修改
  • AI 辅助：用 AI 快速探索想法

2. Vibe Coding vs 传统编程​

维度传统编程Vibe Coding
规划详细设计即兴发挥
文档先写文档代码即文档
流程需求→设计→编码想法→代码→调整
测试先写测试后补测试
灵活性结构化高度灵活

Vibe Coding 的风格​

1. 探索式编程​

想法: "我想做一个简单的待办事项应用"
    ↓
快速原型: 用 AI 生成基础代码
    ↓
运行测试: 看看效果如何
    ↓
直觉调整: "这个颜色不好看，改一下"
    ↓
添加功能: "再加个分类功能"
    ↓
继续调整: "布局有点乱，重构一下"

2. 对话式编程​

开发者: "帮我做个登录页面"
    AI: [生成代码]
开发者: "颜色太深了"
    AI: [调整颜色]
开发者: "加个忘记密码链接"
    AI: [添加功能]
开发者: "这个位置不对"
    AI: [调整布局]
...

3. 试错式编程​

尝试1: [方案A] → 不行，太复杂
尝试2: [方案B] → 还是不对
尝试3: [方案C] → 感觉对了！
完善: [方案C改进] → 完成

Vibe Coding 的场景​

适合场景​

场景原因
原型开发快速验证想法
创意项目需要灵活探索
学习新技术边做边学
个人项目无需团队协作
黑客马拉松时间有限，求快

不适合场景​

场景原因
大型团队项目缺乏规范导致混乱
安全关键系统需要严格验证
长期维护项目技术债务积累
复杂业务系统需要详细设计

Vibe Coding + AI​

1. AI 作为"直觉放大器"​

开发者的直觉 → AI 快速实现 → 即时反馈 → 强化直觉
     ↑                                          ↓
     └────────────────────────────────────────┘
              持续迭代循环

2. 工具支持​

工具Vibe Coding 支持
Cursor快速生成、即时修改
Claude Code对话式开发
ClineVS Code 内的快速迭代
Replit浏览器内即时运行

3. 典型工作流​

# 1. 想到什么直接让 AI 做
claude-code "创建一个 React 待办组件"

# 2. 看着效果，凭直觉调整
claude-code "把按钮改成圆角，加个阴影"

# 3. 继续添加功能
claude-code "加个删除按钮，用红色"

# 4. 发现问题
claude-code "删除没反应，检查一下"

# 5. 重构调整
claude-code "代码有点乱，整理一下"

Vibe Coding 的技巧​

1. 快速原型​

第一步: 5分钟实现核心功能
第二步: 运行看看效果
第三步: 凭直觉调整
第四步: 继续添加
第五步: 随时重构

2. 最小可行产品​

不要一开始就想完整
先做最简单的能用的版本
然后逐步完善

3. 相信直觉​

"感觉这个颜色不对" → 改
"感觉逻辑有点复杂" → 简化
"感觉这里可以优化" → 优化

4. 拥抱不完美​

Vibe Coding 接受:
- 代码可能不够优雅
- 结构可能不够完美
- 测试可能不够完整
但重点是: 快速做出能用的东西

Vibe Coding vs Spec-Driven Development​

对比表​

维度Vibe CodingSpec-Driven Development
规划随性严格
文档代码即文档详细规范
灵活性极高中等
可维护性低高
团队协作困难容易
学习曲线低高
AI 参与度高高
适用规模小大

何时使用​

场景推荐
创意验证Vibe Coding
黑客马拉松Vibe Coding
个人项目Vibe Coding
团队项目Spec-Driven
企业级系统Spec-Driven
长期产品Spec-Driven

Vibe Coding 的最佳实践​

1. 保持代码整洁​

即使采用 Vibe Coding，也要：

- 定期重构
- 删除无用代码
- 保持一致的命名
- 添加必要注释

2. 使用 Git 分支​

main (稳定版本)
  ↑
feature/experiment (随意尝试)
  ↓
  实验成功了 → 合并到 main
  实验失败了 → 直接删除

3. 设置时间限制​

- 单次会话不超过 2 小时
- 避免陷入无休止的调整
- 定期回顾和整理

4. 记录重要决策​

即使不写详细文档，也要记录:
- 为什么选择这个方案
- 遇到的坑和解决方案
- 下次改进的方向

Vibe Coding 的风险​

1. 技术债务​

快速原型 → 技术债务积累
    ↓
如果不及时还债
    ↓
项目变得难以维护

2. 缺乏可追溯性​

"为什么这样写?"
"我也不知道，当时感觉这样对"

3. 团队协作困难​

"这个代码是什么意思?"
"我也不懂，是他凭感觉写的"

4. 难以复现​

"这个功能怎么实现的?"
"忘记了，当时随便写的"

混合策略​

Vibe + Spec​

最好的方式是结合两者：

┌─────────────────────────────────────────────────────────┐
│                 Vibe + Spec 混合策略                    │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  探索阶段 (Vibe)                                       │
│  ├── 快速原型                                           │
│  ├── 验证想法                                           │
│  └── 找到方向                                           │
│         ↓                                              │
│  稳定阶段 (Spec)                                       │
│  ├── 编写规范                                           │
│  ├── 重构代码                                           │
│  └── 添加测试                                           │
│         ↓                                              │
│  迭代循环                                               │
│                                                         │
└─────────────────────────────────────────────────────────┘

实践建议​

1. 个人项目: 多用 Vibe Coding
2. 团队项目: 核心用 Spec，边缘用 Vibe
3. 紧急需求: 先 Vibe 解决，后 Spec 规范
4. 创新探索: Vibe 先行，Spec 跟进

参考资源​

相关概念​

工具​

文档更新时间：2025 年 12 月

aizex
Aizex 合租面板
更好用的「GPT-5 x Claude」使用方式
亲测推荐