高效 Vibe Coding 深度指南

一、Vibe Coding 的心智模型

你不是在写代码，你是在管理一个 AI 员工

传统开发：
  你：想需求 → 设计 → 写代码 → 测试 → 部署

Vibe Coding：
  你：想需求 → 描述需求 → Review AI 的代码 → 确认 → AI 测试 → AI 部署

你的价值不再是写代码，而是：

1. 判断 — 做什么、不做什么
2. 决策 — 技术方案选哪个
3. 审查 — AI 写的代码对不对
4. 纠偏 — AI 跑偏时拉回来

为什么"会写代码"的人反而 Vibe Coding 效果差

新手（代码能力弱）：
  → 给 AI 高自由度
  → AI 发挥正常
  → 结果 OK

老手（代码能力强）：
  → 忍不住告诉 AI 每一步怎么做
  → 变成"用嘴写代码"
  → 效率反而不如自己写

解法：给意图，不给步骤。让 AI 做实现层决策。

二、任务拆解的艺术

拆解原则：一次一个可验证的单元

# 差：太粗
"实现用户认证系统"

# 差：太细
"在 auth.ts 第 10 行添加一个 import"

# 好：可验证的单元
"实现用户注册接口，包含邮箱验证和密码加密"
→ 完成后可以跑测试验证

拆解示例

需求：构建一个博客系统

拆解：
1. 设计数据模型（User、Post、Comment、Tag）
2. 实现用户注册和登录
3. 实现文章 CRUD
4. 实现评论功能
5. 实现标签和分类
6. 实现搜索
7. 实现 RSS 输出
8. 添加管理后台

每个步骤都是可独立验证的。

依赖关系处理

步骤 1 和 2 有依赖（数据模型是基础）
步骤 3 依赖 2（需要认证）
步骤 4 依赖 3（评论关联文章）
步骤 5 和 6 可以并行
步骤 7 依赖 3（需要文章数据）
步骤 8 依赖前面所有

Claude Code 的 Task 系统可以追踪这些依赖。

三、对话策略

策略一：锚定上下文

# 每个对话开始时锚定
"我正在开发 src/services/order.ts 的订单模块，
参考 src/services/user.ts 的代码风格"

# 后续对话不需要重复说明
"给订单模块添加取消功能"
"给订单模块添加退款功能"

策略二：确认再继续

"实现用户注册接口"
# Claude 给出方案

"方案 OK，但密码加密用 bcrypt 而不是 argon2"
# Claude 修改

"好，现在实现"
# Claude 实现

"跑一下测试"
# Claude 跑测试

"提交代码"

每一步都确认，避免方向跑偏后大量返工。

策略三：用 /compact 管理上下文

# 完成一个子任务后
"好，用户注册完成了"
/compact

# 开始下一个任务
"现在实现登录功能"

策略四：话题切换用新对话

# 差：一个对话做所有事
"实现用户注册" → "实现文章" → "修这个 bug" → "写文档"
# 上下文越来越乱

# 好：不同话题不同对话
对话 1："实现用户注册"
对话 2："实现文章模块"
对话 3："修这个 bug"
对话 4："写文档"

四、Prompt 模板（实战版）

模板 1：功能实现

实现 [功能名称]

背景：[为什么需要这个功能，用户故事]

技术要求：
- [具体的技术约束]
- [性能要求]
- [安全要求]

接口设计：
- 输入：[输入格式]
- 输出：[输出格式]
- 错误：[错误处理方式]

参考：
- [类似功能的代码位置]
- [相关文档]

验收标准：
- [怎么算做完了]
- [怎么验证正确性]

模板 2：Bug 修复

Bug 描述：[什么现象]

环境：
- [操作系统/浏览器/版本]
- [什么条件下出现]
- [频率：总是/偶现/特定条件]

复现步骤：
1. [步骤 1]
2. [步骤 2]
3. [步骤 3]

预期行为：[应该怎样]
实际行为：[实际怎样]

相关代码：[文件路径和行号]

日志：
[粘贴相关日志]

已排查：
- [已经试过什么]
- [排除了什么可能]

请先分析原因，不要直接改代码。

模板 3：代码审查

审查 [文件/目录]

重点关注：
1. [安全问题]
2. [性能问题]
3. [逻辑错误]
4. [代码风格]

不要修改代码，只列出问题：
- 文件：行号
- 问题描述
- 严重程度：高/中/低
- 修复建议

模板 4：重构

重构 [文件/模块]

当前问题：
- [为什么要重构]

重构要求：
- [保持什么不变]
- [改变什么]
- [验证标准]

分步执行：
1. 先分析现有代码
2. 给出重构方案
3. 等我确认后再改
4. 每改一步都跑测试

模板 5：性能优化

优化 [函数/模块]

当前性能：
- [具体数据：响应时间、内存使用等]

目标性能：
- [具体目标]

约束：
- [不能改变什么]
- [可以引入什么]

请：
1. 分析性能瓶颈
2. 提出优化方案
3. 分析每个方案的 trade-off
4. 实现最优方案
5. 验证优化效果

五、团队协作模式

共享 CLAUDE.md

# 项目级 CLAUDE.md 提交到 Git
git add CLAUDE.md
git commit -m "docs: add Claude Code project configuration"

# 团队成员 pull 后自动生效
git pull
# Claude Code 自动读取 CLAUDE.md

共享 Skills

# Skills 目录提交到 Git
git add .claude/skills/
git commit -m "feat: add team custom skills"

# 团队成员都能使用
# 在 Claude Code 中输入 /skill-name

共享 MCP 配置

// .claude/settings.json（项目级）
{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "${DATABASE_URL}"]
    }
  }
}

注意：敏感信息用环境变量，不要提交 token 到 Git。

PR 规范

## PR 描述

### 改动内容
[描述做了什么]

### AI 辅助
- 使用 Claude Code 生成基础代码
- 人工 Review 了所有改动
- 测试通过

### 测试
- [ ] 单元测试通过
- [ ] 集成测试通过
- [ ] 手动测试通过

Code Review 重点

当 Review AI 生成的代码时，重点看：

1. 边界条件 — AI 容易忽略空值、溢出、并发
2. 错误处理 — AI 可能用 catch-all 而不是精确捕获
3. 安全 — AI 可能引入注入、XSS 等漏洞
4. 性能 — AI 可能用简单但慢的实现
5. 业务逻辑 — AI 可能误解需求

六、质量保证

测试策略

# 让 AI 先写测试
"为这个函数写单元测试，覆盖：
- 正常输入
- 边界条件
- 异常输入
- 并发场景"

# 确认测试覆盖了关键场景
# 然后让 AI 实现代码使测试通过

代码审查清单

每次 AI 生成代码后检查：

□ 函数签名是否正确
□ 错误处理是否完整
□ 边界条件是否处理
□ 是否有安全隐患
□ 性能是否可接受
□ 代码风格是否一致
□ 是否有不必要的复杂度
□ 测试是否覆盖

自动化检查

// .claude/settings.json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npx tsc --noEmit 2>&1 | head -10; npx eslint $CLAUDE_FILE_PATH 2>&1 | head -10; true"
          }
        ]
      }
    ]
  }
}

七、常见反模式与解法

反模式 1：大爆炸式开发

# 症状
"帮我做一个完整的电商系统"

# 问题
- AI 生成大量代码，质量不可控
- 无法逐步验证
- 出问题不知道从哪改

# 解法
拆成小任务，每个任务独立验证：
1. 数据模型
2. 用户模块
3. 商品模块
4. 订单模块
5. 支付模块

反模式 2：不检查就提交

# 症状
AI 改完了 → git add . → git push → 出问题

# 问题
- AI 也会犯错
- 边界条件可能没处理
- 可能引入安全漏洞

# 解法
每次 AI 改完：
1. 看 diff
2. 跑测试
3. 确认无误再提交

反模式 3：过度依赖 AI 决策

# 症状
"你觉得应该用什么数据库？" → AI 说 MongoDB → 直接用

# 问题
AI 不了解你的业务场景、团队能力、运维环境

# 解法
让 AI 分析选项，你做决定：
"分析 PostgreSQL vs MongoDB 对我的场景的优劣"
→ 你根据分析结果决定

反模式 4：一个对话做所有事

# 症状
一个对话从需求分析到部署，上下文几千行

# 问题
- 上下文过长，AI 质量下降
- 无法 /compact 保留关键信息
- 容易混乱

# 解法
分阶段对话：
1. 需求分析（对话 1）
2. 设计方案（对话 2）
3. 实现（对话 3-N，每个子任务一个对话）
4. 测试（对话 N+1）
5. 部署（对话 N+2）

反模式 5：不写 CLAUDE.md

# 症状
每次对话都要重复解释项目背景

# 问题
浪费 token，AI 每次从零开始理解

# 解法
花 30 分钟写好 CLAUDE.md，永久受益

反模式 6：用自然语言描述代码

# 症状
"在那个函数里加一个判断，如果大于 100 就返回错误"

# 问题
- 不精确
- AI 可能理解错位置
- 容易遗漏上下文

# 解法
"在 src/services/order.ts 的 createOrder 函数中，
添加金额上限校验：如果 amount > 100，抛出 AppError('金额超出限制')"

八、效率度量

对比传统开发

任务：实现一个 CRUD API（5 个接口）

传统开发：
- 写代码：2 小时
- 写测试：1 小时
- 调试：0.5 小时
- 总计：3.5 小时

Vibe Coding：
- 描述需求：10 分钟
- Review 代码：20 分钟
- 修改调整：10 分钟
- 总计：40 分钟

效率提升：约 5 倍

什么时候 Vibe Coding 不高效

1. 简单修改（改个变量名）→ 直接改更快
2. 高度定制（底层性能优化）→ 自己写更可控
3. 学习阶段（理解原理）→ 需要自己动手
4. 调试复杂 bug → 需要人类直觉

最佳使用场景

✅ CRUD 接口开发
✅ 模板代码生成
✅ 代码重构
✅ 测试生成
✅ 文档编写
✅ 代码审查
✅ 技术调研
✅ 脚本编写

九、实战场景速查

场景：接手陌生项目

# 差：直接让 AI 读所有文件
"帮我理解这个项目"
→ 消耗 200k+ tokens

# 好：分步探索
1. "读 README，用一句话告诉我这个项目做什么"
2. "列出 src/ 的目录结构，只看第一层"
3. "读 src/ 的入口文件，告诉我数据怎么流转的"
4. "找到 API 路由文件，列出所有接口"
5. "找到数据库 schema，告诉我有哪些表"

每步消耗 2-5k tokens，总计 15-25k

场景：紧急修复线上 Bug

# 差：慌乱中给模糊指令
"线上出 bug 了，快帮我修"

# 好：给精确信息
"线上 bug：
- 现象：用户下单后库存没减少
- 复现：下单商品 ID=123，下单后查 inventory 表，数量没变
- 相关代码：src/services/order.ts 的 createOrder 函数
- 最近改动：昨天改了下单逻辑（commit abc123）
- 期望：下单后 inventory.quantity 应该减 1

先分析原因，不要直接改代码"

场景：代码审查别人的 PR

# 差：让 AI 审查所有改动
"审查 PR #42"
→ 读取 30 个文件，消耗大量 token

# 好：分层审查
1. "列出 PR #42 改了哪些文件"（2k tokens）
2. "重点审查 src/api/ 下的改动，关注安全和错误处理"（30k tokens）
3. "审查 src/services/ 下的改动，关注业务逻辑"（30k tokens）
4. "看看有没有遗漏的测试"（10k tokens）

总计 72k tokens，比一次审查 300k 省了 76%

场景：批量重构

# 差：一次说清楚所有改动
"把项目中所有的 var 改成 const/let"
→ AI 可能改错，改了不该改的

# 好：分模块处理
1. "列出 src/utils/ 中所有用了 var 的文件"
2. "把 src/utils/string.ts 中的 var 改成 const/let"
3. "跑测试确认没有破坏"
4. 继续下一个文件...

每步可控，出错容易回滚

场景：写技术方案文档

# 差：让 AI 自由发挥
"帮我写一个技术方案"
→ AI 不知道你的约束，写出来不可用

# 好：给框架和约束
"写技术方案，格式：

## 背景
[为什么要做]

## 方案对比
至少 3 个方案，每个列出：
- 优点
- 缺点
- 实现复杂度
- 预估工时

## 推荐方案
- 为什么选这个
- 风险点
- 回滚方案

## 实施计划
- 分几步
- 每步的验收标准

场景：[你的具体场景]
约束：[你的具体约束]"

场景：日常开发中的快速问答

# 差：进入交互模式问简单问题
claude
> TypeScript 怎么做类型断言？
→ 消耗 10k tokens（含对话开销）

# 好：用 Headless 模式
claude -p "TypeScript 中 as 和 satisfies 的区别，给一个例子"
→ 消耗 3k tokens

# 更好：查文档
# 简单问题直接查文档或搜索引擎，不浪费 AI 额度