什么是 Vibe Coding
由 Andrej Karpathy 于 2025 年 2 月提出的编程范式：用自然语言描述需求，让 AI 生成代码，开发者以结果验收而非逐行审阅。Simon Willison 进一步区分：若能解释、测试并审阅每行代码，则属于传统软件开发，而非真正的 vibe coding。
核心用法
1. 意图先行
模糊提示导致模糊输出。明确问题定义、完成标准与技术约束后再启动 AI。例如将"做一个社交 App"细化为"文本帖子（280 字）、关注用户、时间线 feed、点赞评论，技术栈 React + Tailwind + Supabase"。
2. 规则文件（Rules Files）
在 .cursorrules、.cursor/rules/ 或 CLAUDE.md 中持久化团队规范，避免每次重复上下文。
3. Research-Plan-Implement 工作流
在规划阶段发现误解的成本，远低于级联错误的调试。
- Research：让 AI 先探索现有代码结构
- Plan：输出待修改文件及变更清单
- Implement：确认计划后再执行
4. 干预时机
- 放任：脚手架、UI 组件、创意探索
- 必须干预：认证、支付、数据处理等安全敏感区域
- 必审：数据库 Schema、API 权限、用户数据处理
5. 约束锚定
通过显式边界控制输出："少于 50 行"、"仅输出修改的函数"、"只改动支付流，不动认证"。
6. 测试闭环
AI 代码常"看起来完美"但暗藏 bug。每次变更后：跑测试、手动验证、检查控制台、覆盖主路径与边界条件。
7. 错误处理 Karpathy 技巧
直接粘贴错误信息不加注释，AI 通常能修复；若 2-3 次失败，改描述期望行为而非继续追问错误。
显著优点
- 极速原型：周末即可完成可用 MVP
- 降低门槛：非专业开发者也能产出功能代码
- 探索成本低：快速验证产品假设
- experienced 开发者倍增器：架构能力 + AI 产出 = 超级效率
局限性与风险
| 维度 | 风险 |
|------|------|
| 可维护性 | 生成代码难以长期维护，技术债累积快 |
| 安全 | AI 对权限边界、注入防护理解有限，易产漏洞 |
| 性能 | 缺乏深层优化意识，复杂场景易出性能瓶颈 |
| 合规 | 金融、医疗等强监管领域不适用 |
| 认知依赖 | 开发者可能丧失代码理解能力，形成"黑箱依赖" |
适合人群
- 需要快速验证想法的产品经理/独立开发者
- 有架构判断力、能识别 AI 产出差错的资深工程师
- 内部工具、周末项目、学习场景
不适合场景
安全关键代码、性能关键系统、强合规领域、需长期演进的生产级系统。
核心原则
> "The best vibe coders understand architecture, spot bad AI output, and know when to intervene."
不懂代码的人，不该用 vibe coding 做生产系统。