Vibe Coding 实战：用 Claude Code 高效编程的心法与技法

摸鱼同学

196人浏览 · 2026-06-19 10:45:00

摸鱼同学 · 2026-06-19 10:45:00 发布

Vibe Coding 实战：用 Claude Code 高效编程的心法与技法

你有 CLAUDE.md、有 Spec 文档、有 Memory——但 AI 写出来的代码还是不对。变量命名不是你想要的风格、函数拆分不是你想的粒度、架构选型不在你的预想范围内。问题出在哪？这篇文章不讲"项目怎么配置"（那是第 11 篇的内容），讲的是人和 AI 之间的那层互动——怎么描述需求、怎么纠偏、怎么推进到目标。以及一个现实中很少被提及的问题：当你用的是国产大模型，思维方式要做什么调整。

Vibe Coding 不是"用 AI 写代码"

先对齐一个认知。Vibe Coding 不是打开 Claude Code 说一句"帮我做个电商系统"，然后坐等奇迹。

Vibe Coding 的本质是：你把 AI 当作一个能写代码的高级同事，你用对话的方式引导它逐步逼近你脑海中的目标。你负责方向和质量，它负责实现和细节。

传统编程:  你 → 编译器 → 可运行程序
AI 编程:   你 → AI → 代码 → 你审阅 → AI 修改 → ... → 可运行程序

区别在于中间多了一个"你审阅 → AI 修改"的循环。
Vibe Coding 的效率取决于这个循环转得有多快、多准。

核心问题：为什么 AI 总不按你的心意来

这不是你的问题，也不是 AI 的问题。这是意图传递损耗。

你脑海中的想法（100%）
    │
    │  表达损耗 1: 你只能用自然语言描述，但代码是精确的逻辑
    ▼
你实际说出来的话（70%）
    │
    │  理解损耗 2: AI 用训练数据中的"平均理解"来解读你的话
    ▼
AI 理解到的意图（50%）
    │
    │  能力损耗 3: 国产模型在代码生成上的结构性理解弱于 Claude Opus
    ▼
AI 生成的代码（40%）

→ 你看到的不对，因为从你的想法到 AI 输出，中间损耗了 60%

Vibe Coding 的整篇文章，就是在说怎么减少这三层损耗。

心法一：先说"为什么"，再说"做什么"

这是最高杠杆的技巧。大多数人说：

❌ "帮我写一个缓存层"

AI 会怎么写？它猜——可能是 Redis、可能是内存 dict、可能是文件缓存。它有 10 种理解方式，它挑了最"平均"的那种。大概率不是你想要的。

✅ "用户登录后要频繁查询个人信息，每次查询都会打到数据库。
    我希望减少数据库压力，同时保证缓存数据和数据库的一致性。
    数据量不大（单用户 < 5KB），但并发高（峰值 5000 QPS）。
    帮我设计一个缓存方案。"

区别在于：前者给了 AI 一个填空题（只有一个答案但你没说是什么），后者给了 AI 一个应用题（有约束条件，AI 可以推导出最优解）。

给 AI 约束，它就少猜。AI 猜得越少，输出越接近你的预期。

实战：用约束引导 AI

差的描述（无约束，AI 自由发挥）:
  "帮我重构这个函数"
  → AI 可能改命名、拆函数、换算法——你不知道它会做什么

好的描述（有约束，AI 在框内发挥）:
  "帮我重构 getUserOrders 函数。约束:
   1. 保持函数签名不变（参数和返回值不变）
   2. 把 SQL 查询逻辑抽到单独的 repository 方法
   3. 错误处理用 try/except 而非 if/else 判断返回值
   4. 不要改变任何外部行为——现有测试必须全部通过"
  → AI 的发挥空间被框定，输出可控

心法二：用"示例"替代"描述"

自然语言描述抽象概念是低效的。给 AI 看一个例子，比写 500 字描述更准。

❌ 描述（模糊）:
  "我希望 API 返回的错误格式统一一点"

✅ 示例（精确）:
  "所有 API 错误返回这个格式:
  ```json
  {
    "code": 40102,
    "message": "Token 已过期",
    "detail": "请重新登录获取新 Token",
    "trace_id": "a1b2c3d4"
  }

错误码规则: 4xxxx 客户端错误，5xxxx 服务端错误。"


**为什么示例比描述有效？** 因为 LLM 本质上是模式匹配引擎。你给它一个模式（示例），它照着生成；你给它一个描述，它要去"理解"描述然后"创造"一个实现——多了一步，就多一层损耗。

### 实战：贴代码比说话管用

当你对 AI 生成的代码不满意时，不要只说"不对"——**贴一段你觉得对的代码**：

👤 你: "不要用 for 循环，改成这样:
python active_users = [u for u in users if u.is_active] "

🤖 AI: [看到示例 → 匹配模式 → 后续所有遍历都用推导式]

对比:

👤 你: “不要用 for 循环，用列表推导式”
→ AI 知道概念，但可能写成 [u.is_active for u in users]（语义错误）
→ 或者写成 [u for u in users if u.is_active]（正确但不一定是你想要的变量名）

关键差异: 示例消除了"理解"这一步。AI 不需要理解"推导式"意味着什么，
它直接匹配你给的结构模板。


---

## 心法三：分步推进，不要跳跃

Vibe Coding 最容易犯的错误——一次性给太多要求。尤其是国产大模型，长指令的结构性理解不如 Claude Opus。

❌ 一次给太多:
“帮我做一个用户管理系统，包括注册、登录、角色权限、头像上传、
密码重置、邮箱验证。数据库用 PostgreSQL，缓存用 Redis，
前端用 React + Ant Design，后端用 FastAPI。”
→ AI 可能漏掉密码重置、可能前端和后端风格不一致
→ 出了问题你不知道是哪一步开始偏的

✅ 分步推进:
第1步: “先设计数据库表结构。用户表需要哪些字段？”
→ 审阅表结构 → 确认 → 下一步

第2步: “基于刚才确认的表结构，写 FastAPI 的注册接口。
入参: email + password + username，出参: user_id”
→ 审阅代码 → 确认 → 下一步

第3步: “注册接口通过。现在加邮箱验证逻辑。
注册时发验证邮件，用户点击链接后激活账号。”
→ …

每一步都基于上一步的确认结果往下走。
偏了最多偏一步，不会整个方向都歪。


### 分步的粒度怎么控制

太粗（一个需求包含多个独立功能）
→ AI 容易遗漏或混淆
→ 你审阅起来也累

太细（每个变量名都单独问）
→ 效率太低
→ AI 的上下文利用率也低

合适的粒度 = 一个"可独立验证"的功能单元
✅ “用户注册接口” ← 独立功能，写完就能 curl 测试
✅ “JWT Token 生成和验证” ← 独立功能，写完能单独跑测试
✅ “用户表 + 角色表 + 关联表” ← 数据库变更，能 migrate 验证

❌ “用户模块” ← 太粗，包含 10+ 个独立功能
❌ “用户的 email 字段加索引” ← 太细，一句话的事


---

## 心法四：发现偏了立刻纠正，不要"等会儿一起改"

这是 Vibe Coding 和传统开发最大的行为差异。

传统开发中，你写的代码有小问题，你会先 mark 一下，等这个功能写完再一起重构。但在 AI 编程中，**AI 的下一步是基于上一步的输出。上一步偏了，下一步会更偏**。

错误做法:
第 1 步: AI 写了个函数，命名风格不对 → 你觉得"小问题，先继续"
第 2 步: AI 基于这个函数写了调用代码 → 调用的变量名也不对
第 3 步: AI 基于调用代码写测试 → 测试里全是错的变量名
第 4 步: 你终于忍不住了 → 需要改 3 个文件 → 重新理解和调整

正确做法:
第 1 步: AI 写了个函数，命名风格不对 → 立即纠正
第 2 步: AI 已经被纠正过 → 后续调用代码命名正确 ✅
第 3 步: 测试代码命名正确 ✅

每次纠正的成本: 第 1 步纠正 = 一次交互
累积纠正的成本: 第 4 步纠正 = 三次交互 + 三次修改


**铁律：AI 输出后 30 秒内发现问题 → 立刻说，不要等。**

---

## 心法五：当 AI 反复犯同一个错——用规则锁定

如果纠正了 2-3 次 AI 还是犯同样的错，说明问题不在"这次对话"，而在"AI 的默认行为"。用 `/memory` 写入持久规则。

在 Claude Code 中：

👤: “记住：以后所有 Python 代码中的数据库操作都用 async/await”

或在 CLAUDE.md 中添加:

规则

所有数据库操作使用 async/await（SQLAlchemy async 模式）
函数超过 20 行拆分为多个小函数


**对于国产大模型特别注意**：DeepSeek、Qwen 等模型对英文命名和中文注释的混合理解不如 Claude Opus。如果你的项目是中英文混合（标识符英文 + 注释中文），建议：

```markdown
## 代码风格（国产模型适配）
- 注释和文档字符串使用中文
- 标识符（变量/函数/类名）使用英文
- 注释不要过长——超过 2 行的注释可以拆分为多行（国产模型对长中文注释的理解会衰减）
- 复杂逻辑的注释用"// Step 1: xxx, Step 2: xxx"的结构（比散文式注释更准确）

国产大模型特有注意事项

使用 DeepSeek / Qwen / Moonshot 等国产模型作为 Claude Code 后端时，有几个 Claude Opus 用户不必担心的点：

1. 长上下文中后半段的指令容易被忽略

Claude Opus: 200K Token 上下文内，各位置的指令权重基本一致
国产模型: 超过 ~64K Token 后，中间偏后的指令权重明显下降

应对策略:
  → 最重要的约束写在最前面（不是最后面）
  → 复杂任务拆成多次短对话（每次 < 30 轮）
  → 定期 /compact 清理上下文

2. 对英文代码 + 中文说明的混合理解有边界

✅ 国产模型擅长:
  - 用中文描述需求，生成英文代码
  - 用中文理解代码逻辑，给出中文解释

⚠️ 国产模型弱项:
  - 英文代码中夹复杂的中文注释 → 可能只理解中文部分，忽略代码细节
  - 长篇中文 spec 文档 → AI 可能只关注前面的中文需求，忽略后面的代码模板

应对策略:
  → 关键代码模板用英文注释，让 AI 的注意力同时落在代码和注释上
  → 中文 spec 文档配合英文代码示例（而非纯中文描述）

3. 结构性输出不如 Claude Opus 精准

Claude Opus 擅长:
  "帮我生成一个标准 REST API 项目结构，包含 auth、users、orders 三个模块"
  → 输出完整且内部一致的项目结构

国产模型:
  同样 prompt → 可能缺目录、模块命名不一致、import 路径错误

应对策略:
  → 给 AI 一个目录结构的模板，让它填充而非创造:
    "按照这个目录结构填充:
     src/
     ├── modules/
     │   ├── [模块名]/
     │   │   ├── __init__.py
     │   │   ├── routes.py      # 路由定义
     │   │   ├── service.py     # 业务逻辑
     │   │   └── models.py      # 数据模型"
  → 需要生成多个文件时，一个一个来（不要要求 AI 一次生成整个项目）

4. 创造性任务稍弱，但遵循模板很强

国产模型的优势: 给定明确模板 → 严格遵循 → 输出质量高
国产模型的劣势: 没有模板 → 自由发挥 → 可能偏离预期

利用这个特点:
  → 不要期望 AI "想出最佳方案"——你给出方案框架，AI 填充
  → 架构决策你来做，代码实现 AI 来做
  → 先写一个示例文件（golden sample），让 AI 照着风格写其余文件

实战工作流：一个功能从想法到完成

以"给博客系统加全文搜索"为例：

第1步：对齐目标（5 分钟）

👤: "我想给博客加全文搜索功能。目前有约 200 篇文章存储在 Markdown 文件中。
    用户场景：在搜索框输入关键词 → 返回包含该关键词的文章列表，
    列表显示文章标题 + 匹配的摘要片段 + 发布日期。
    搜索体验要好——不能每次搜都全量扫描 200 个文件。"

🤖: "理解了。有几个方案：
     A. 构建时生成搜索索引 JSON，前端加载后纯前端搜索（简单，适合 200 篇）
     B. 用 SQLite FTS5 做全文索引（需要后端，搜索更精准）
     C. 用 Elasticsearch（功能最强，但太重了）
     考虑到 200 篇文章的规模，推荐方案 A 或 B。你倾向哪个？"

👤: "方案 B。文章会持续增加，SQLite FTS5 够用了。"

🤖: "OK。实现步骤：
     1. 数据库添加 FTS5 虚拟表
     2. 文章保存时自动更新索引
     3. 搜索 API 接口（GET /api/search?q=xxx）
     4. 前端搜索框 + 结果展示"

这一步的关键：不要说"帮我加搜索"，要说场景 + 约束 + 规模。AI 才能给出合适的方案。

第2步：逐步实现（每个步骤 5-15 分钟）

👤: "先做第1步。在 models.py 中添加 FTS5 表。我现有的文章表是 articles，
     字段是 id, title, content, created_at。"
     
🤖: [生成代码]

👤: "索引应该包含 title + content，content 权重更高。改一下。"

🤖: [修改代码]

👤: "可以。接下来第2步——文章保存时更新索引。文章保存逻辑在 
     services/post_service.py 的 create_post 和 update_post 方法中。"
     
🤖: [读取文件 → 理解现有逻辑 → 添加索引更新代码]

👤: "create_post 的逻辑对了。但 update_post 需要先删旧索引再插入新索引。
     你的代码直接 insert 了，会重复。"

🤖: "你说得对，修正：在 update_post 中先 DELETE FROM fts_index WHERE post_id = ?，
     再 INSERT。"
     
...（以此类推，第 3、4 步）

第3步：发现问题立刻修

👤: "搜索接口返回的摘要片段，高亮一下匹配的关键词。"

🤖: [生成代码] 
    snippet = "...<mark>{keyword}</mark>..."

👤: "不要用 <mark> 标签，前端用的不是 HTML。换成 {{keyword}} 双花括号包裹。
     另外摘要长度截取 150 字符，不要 200。"

🤖: [立即修正] 
    snippet = "...{{{{keyword}}}}..."[:150]

第4步：完成后复盘

👤: "复盘一下全文搜索这个功能。有什么可以沉淀的？"

🤖: "两点建议：
     1. FTS5 索引更新的逻辑（DELETE + INSERT）可以提取为工具函数 
        rebuild_fts_index(post_id)，后续其他模块也可能用到
     2. 搜索摘要生成逻辑可以写为 Skill，以后任何搜索功能都能复用"

👤: "好。把 rebuild_fts_index 加到 CLAUDE.md 的代码模板里。
     搜索摘要的 Skill 也生成一个。"

常见死胡同及脱困方法

死胡同 1：AI 不断绕圈子

症状: 你说"不对"，AI 改了；你说"还是不对"，AI 改回去；来回 3 轮没有进展。

脱困: 
  不要继续描述"怎么样不对"。
  换一种方式——贴代码。
  "我要的是这样的：
   ```python
   [你期望的代码]

请按照这个风格重写。

死胡同 2：AI 生成的代码能跑，但架构方向错了

症状: 功能实现了，但你发现这个实现方式和项目其他部分格格不入。

脱困:
  不要在 AI 的代码上修修补补。
  重置：/clear → 重新描述需求 → 这次加上架构约束。
  "用 Repository 模式实现数据访问层，不要在 Service 层直接写 SQL。
   参考 src/modules/users/repository.py 的风格。"


### 死胡同 3：国产模型在复杂逻辑上反复出错


症状: 一个复杂的业务流程，AI 实现了 3 次都漏掉某些边界条件。

脱困:
  把复杂逻辑拆成多个简单函数，让 AI 逐个实现：
  "这个订单创建流程太复杂了。我们拆开：
   1. 先写 validate_order_input —— 只做输入校验
   2. 再写 calculate_order_price —— 只算价格
   3. 再写 reserve_inventory —— 只锁库存
   4. 最后写 create_order —— 调用以上三个函数"
  
  国产模型擅长"一个函数做一件事"——给它单一职责，输出质量明显提升。

死胡同 4：你不确定要实现成什么样

症状: 你只知道"大概要做一个什么东西"，具体怎么设计还不清楚。
      但你让 AI 开始写了。

脱困:
  不要写代码。先对话。
  "我想做 XXX，但不确定怎么设计。帮我分析几种方案的优劣。"
  → AI 给出方案 A/B/C → 你选一个 → 有了清晰方向 → 再开始写代码。

  这个阶段用便宜的模型（DeepSeek），探索阶段不需要最强推理能力。

提速清单

□ 每次对话开始前，确认 CLAUDE.md 是最新的（至少每周检查一次）
□ 用"为什么 + 约束"开头，不用"帮我做 XXX"开头
□ 给 AI 看示例代码，而不是用自然语言描述期望的输出格式
□ 功能拆成"可独立验证"的单元（写完能测试）
□ 发现输出不对，30 秒内纠正，不要等
□ 同一个错误纠正 2-3 次 → 写进 CLAUDE.md
□ 复杂逻辑拆成多个单一职责小函数
□ 用国产模型时，最重要的约束放最前面
□ /clear 定期清理，不在一场对话里堆太多话题
□ 对话超过 20 轮还没解决 → 可能是方向问题，停下来重新对齐

总结

Vibe Coding 不是玄学，是一套可以刻意练习的技能。

心法:
  1. 说为什么 + 给约束 → 减少 AI 猜测
  2. 用示例替代描述 → 消除理解损耗
  3. 分步推进 → 偏了最多偏一步
  4. 发现偏了立即纠正 → 不让错误累积
  5. 同一个错误反复出现 → 写进规则锁定

国产模型特别要注意:
  → 约束放前面，不是后面
  → 给模板让 AI 填充，不让 AI 从零创造
  → 复杂逻辑拆成简单函数，每个函数单一职责
  → 重要决策你做，代码实现 AI 做

最终公式:
  好的输出 = 清晰的约束 × 准确的示例 × 及时的反馈 × 合适的模型策略