Vibe Coding 开发项目的基本范式先搞清一件事：Vibe Coding ≠ 乱Accept Andrej Kar

先搞清一件事：Vibe Coding ≠ 乱Accept

Andrej Karpathy 原话是 "fully give in to the vibes, embrace exponentials, and forget that the code even exists" ——说的是周末原型/探索阶段的极致体验。但真要把项目做靠谱，社区的共识已经收敛成了一个更成熟的范式：

你的角色从"打字员"变成了"产品经理 + 代码评审官" 。AI负责实现速度，你负责意图、边界和质量把关。

范式总览：The Review-Driven Loop

这是最核心的运行循环，每一步都别省：

① Spec（写清楚做什么） 
  → ② Context（把约束喂给AI，而非空洞指令）
    → ③ Generate（生成小步增量代码）
      → ④ Review（像审PR一样逐行看Diff ← 最关键的一步）
        → ⑤ Test（跑通验证）
          → ⑥ Commit（过了才入库，永远可回退）

任何一步跳过去，技术债就在悄悄累积。

Phase 1：项目初始化（工程规范前置）

这是 vibe coding 和传统"直接说帮我做个网站"最大的区别——先定规矩，再让AI进场。

1. 建一个 `CLAUDE.md`/ `AGENTS.md`（项目"宪法"）

放在项目根目录，所有AI工具都能读：

# Project: MyApp — 一个___SaaS/工具/游戏___

## Stack
Next.js 15 · TypeScript(strict) · Tailwind · Supabase(PostgreSQL)

## 目录约定
src/
  app/         → 路由页
  components/  → 可复用UI
  lib/         → 业务逻辑 & DB查询（DB不准在组件里查）
  types/       → TS类型集中管理

## 禁令
- 不许引入新第三方库（除非问我）
- 不许改 tsconfig / eslint 等基础设施
- 所有API输入走 Zod 校验
- 报错要有边界处理，不准 silent fail

## 启动命令
npm run dev / npm run test / npm run typecheck

有了这个文件，你之后每句 prompt 都不用重复背景，AI 会自觉对齐你的规范。

2. 目录结构早定，别让AI自由生长

AI 的天性是"当前任务最优解"而非"长期结构最优"——它会把逻辑堆进一个大文件、随便加新文件不按模式、混关注点。你要在生成大量代码前先把骨架钉死：

项目根/
├── AGENTS.md          ← AI的"入职手册"
├── PRD.md             ← 需求文档（哪怕一页纸）
├── src/
│   ├── components/    ← 按职责拆，不按技术类型硬套
│   ├── lib/           ← 纯逻辑（可测、无UI依赖）
│   ├── pages/ 或 app/
│   └── types/
├── tests/
└── prompts/           ← 把跑得好的prompt存下来复用

Phase 2：日常开发循环（增量，不要大爆炸）

❌ 错误姿势

"帮我做一个带登录、商品管理、购物车、支付的电商网站"

→ AI 会给你一坨过度设计 + 版本冲突 + 看不懂的代码。

✅ 正确姿势：Micro-Commits

每个 prompt 只做一个可独立验证的小任务：

① 先定 TypeScript 类型和 DB schema
② 写 GET /api/products 路由 + 单元测试
③ 写 products list 页面组件
④ 接 auth（login/logout）+ session 校验
⑤ 加购物车逻辑（先本地 state，再 persist）
...

每一步：生成 → 看 Diff → 跑测试 → 提交 → 下一个

Prompt 的黄金公式

[Context: 指向已有文件/模式] 
+ [What you want: 精确描述]
+ [Constraints: 不许XX，必须沿用了XX模式]
+ [Example: 参考已有的 XXX 文件]

弱 prompt：加个用户设置页

强 prompt：在 app/settings/page.tsx 建用户设置页，可改 displayName/email/avatarURL。复用现有 UserForm 模式（见 app/profile/page.tsx）。fetch user via getServerSession，update via PATCH /api/user。加 Zod schema，success 时调 sonner toast（见 lib/toast.ts）

Phase 3：质量底线（不做这些 = 定时炸弹）

底线	做法
永远看 Diff	`git add -p`交互式暂存，只 accept 你理解的改动；盯住"偷偷 import 了什么新包"
测试是护栏	理想模式：你写测试用例（精确规格），AI 填空让测试变绿
上下文管理	对话长了就 `/clear`开新会话，关键信息写进 AGENTS.md / progress.md，别让 AI 在熵增里变蠢
隔离环境	AI 有 Shell 权限时尤其危险——Docker 或临时环境里跑实验，炸了秒重置
安全红线	绝不硬编码密钥、review 所有 SQL/API 暴露面、AI 爱"画蛇添足"加依赖——每条新 `import`问一句 why

成熟度自检：你在 L1/L2/L3 哪一级？

L1 新手：复制 AI 代码不问 why → 技术债 + 安全洞，风险极高
L2 进阶：会 review diff、设约束上下文，但底层原理模糊 → 能跑但难维护
L3 专家：你定架构和边界，AI 当执行器 → AI 是杠杆，人是大脑

一句话总结范式

Vibe Coding 的范式不是"不写代码"，而是：规范前置 → 意图精确 → 增量交付 → Diff 审查 → 测试关门 → 频繁提交。 把 AI 当极快的实习生——你不会因为他敲得快就让代码直接上线，同理别因为 AI 快就跳过工程纪律。

如果你告诉我你准备用哪个工具栈（Cursor / Claude Code / Windsurf / Lovable 等）和项目类型（Web app / 小程序 / 数据工具 / 游戏…），我可以帮你把 AGENTS.md模板和第一轮任务拆解表直接落到你的场景里。

Vibe Coding 开发项目的基本范式