Vibe Coding 实战

Vibe Coding 不是"我描述需求 AI 写完我合并"。在生产环境里，它是一种以自然语言为主输入、但保留工程纪律的协作方式——AI 出第一稿，工程师做约束、验证、和重构决策。

如果你只在 toy demo 里用过 vibe coding，先把 Vibe Coding 全流程 SOP 完整跑一遍。本章假设你已经了解基础流程，重点讲生产里怎么不踩坑。

4 种场景的决策矩阵

判断标准：这段代码出错的爆炸半径有多大。半径小 → vibe；半径大 → 手写或至少 line-by-line review。

给 vibe 输出加 quality gate

直接 merge AI 写的代码是事故的开始。最低限度装这 5 道闸：

1. Type check 必须过 - tsc --noEmit 是最便宜的 sanity check，AI 经常编出不存在的 import
2. 新代码必须有 test - prompt 里写死 "implement and add unit tests in same PR"，没 test 的实现拒收
3. PR diff 行数限制 - 单 PR +400/-200 行硬上限，超过强制拆分。AI 一次生成 800 行没人能 review
4. Lint + format 自动跑 - pre-commit hook 接 husky + lint-staged，AI 写出来的 indentation/quote style 经常不一致
5. 关键路径加 e2e - auth flow / 支付 / 数据迁移这类，e2e test 必须覆盖一条 happy path

# .github/workflows/vibe-gate.yml 示例
- name: Type check
  run: bun run type-check
- name: Test coverage
  run: bun test --coverage
  # PR 内新增文件 coverage 必须 ≥ 80%
- name: PR size guard
  uses: CodelyTV/pr-size-labeler@v1
  with:
    xl_max_size: '600'  # 超过 600 行直接 block

Code review 的 vibe 模式

人写代码 review 看"对不对"，AI 写代码 review 看 3 件事：

1. Hallucination - 引用的 function / API 真的存在吗？AI 经常编造 lodash.deepMerge、React.useDeferredQuery 这类不存在的东西
2. Pattern drift - 是否绕开了 codebase 已有的 utility？比如项目有 useApi() hook，AI 写出了原始 fetch(...)
3. Over-engineering - 加了不必要的抽象层、提前优化、unused interface。AI 倾向于"完整"，但项目要的是"够用"

实操：reviewer 在 PR description 里看到 "Generated with Claude Code" 就启动 vibe 模式 review，比平时多花 30% 时间。

失败案例：JR Academy 真实事故

事故 1：AI 生成的 migration 删错字段

某次让 Claude Code "remove unused legacy_user_id field from User schema"。AI 写了 mongoose migration 直接 unset 字段。问题：production 还有 200K 用户的 legacy 系统在读这个字段做对账。Migration 跑完对账系统挂掉。

教训：所有 destructive 数据库操作必须人写，AI 顶多给伪代码参考。

事故 2：AI"修复"了一个 race condition，但用了错误模式

PR 描述写"fix race condition in order creation by adding mutex"。Reviewer approve。生产部署后 throughput 降 80%，因为 AI 加的是 process-level mutex，但服务跑 4 个 pod，根本没起隔离作用。

教训：concurrency / distributed system 的修复 review 必须 line-by-line，不能信 PR description。

长期可持续的 vibe 节奏

• 每天前 30 分钟手写 - 保持对 codebase 的肌肉记忆，否则三个月后你看不懂自己的项目
• 复杂任务先白板 - 想清楚架构再让 AI 实现细节，不要让 AI 帮你想架构
• 每周回看一个 AI PR - 重读自己 merge 的 AI 代码，理解每行在做什么。是否有过度工程？是否有更好的写法？
• 保留手写关键模块的能力 - auth / billing / 核心算法这些，公司活命的代码，必须每行你自己理解

下一步

• AI Rules 配置实战 — 把 quality gate 沉淀进项目规则
• AI Coding 工作流 — 三种工具的分工
• Claude Code Examples — 实战 prompt 模式