Vibe Coding 驾驭指南：别让 AI 把你的项目写成屎山
不是 AI 不够强，是你还没学会驾驭它。
前言
Vibe Coding 这个概念在 2025 年彻底火了。
用自然语言跟 AI 对话，几分钟就能出一个能跑的 Demo，一小时就能搭出一个完整的项目原型------这种感觉就像开了外挂。但随着项目越做越大，一个诡异的现象出现了：
项目推进越快，代码越乱。改着改着，整个项目崩盘。
明明 AI 越来越强（Claude Opus、GPT-5 一个比一个猛），为什么产出质量反而在下降？
答案扎心但真实：
问题不在 AI 强不强，而在于你把活直接丢给 AI 就去喝咖啡了。
你需要一套工作流程去驾驭 AI。这就是今天要聊的核心------Harness Engineering（驾驭工程） 。
一、先搞懂 Git 基础------你的"后悔药"
在进入正题之前，先补齐几个 Git 核心操作。它们是 Vibe Coding 工作流中最重要的"安全网"。
1.1 HEAD 指针
HEAD 指向你当前所在的分支 和当前所在的版本。理解 HEAD，是理解所有 Git 回退操作的前提。
css
你在这 → HEAD → main 分支 → commit c31.2 git reset------时光机
css
git reset --hard <commit>
git reset --soft <commit>| 模式 | 工作区 | 暂存区 | 用途 |
|---|---|---|---|
--hard |
丢弃所有修改 | 清空 | 彻底回到某个版本，重新写 prompt |
--soft |
保留修改 | 修改进入暂存区 | 回退到某个版本，但保留你的局部修改 |
关键区别：
--hard：仓库干干净净，仿佛时间倒流。适合"这轮 AI 生成得太烂了，全部推倒重来"。--soft：回退版本但不丢代码。适合"方向对了但结构不对，我留着你写的东西，重新整理一下"。
1.3 暂存区与工作区的撤销
sql
# 把暂存区的文件撤回到工作区（取消 add，不丢内容）
git restore --staged readme.md
# 丢掉工作区的修改（恢复到上次 commit 的状态）
git checkout -- readme.md这两个命令让你能精细控制"AI 生成的内容哪些保留、哪些丢掉"，而不是每次都用 --hard 一刀切。
小结： 把 Git 当"后悔药"用------AI 每轮生成完，都先 commit 一个快照。下一轮不满意？随时回退，零成本试错。
二、Vibe Coding 的死穴：速度越快，死得越快
2.1 典型的 Vibe Coding 崩盘曲线
兴奋期（第1-3天）
↓ 疯狂加功能，一切顺利
膨胀期（第4-7天）
↓ 代码开始重复，组件之间耦合
混乱期（第7-10天）
↓ 改一个地方崩三个地方，prompt 越来越长
崩盘期（第10天+）
↓ 项目推倒重来，或直接放弃这不是你一个人的问题，这是 Vibe Coding 的系统性问题。
2.2 根本原因
AI 没有"全局观"。每一轮对话，它只看到你当前这个 prompt + 上下文窗口里的内容。它不知道：
- 三天前你定的架构边界在哪
- 上周你决定不做哪些功能
- 你的数据模型到底有几个字段
于是 AI 每一次生成，都在微小的发散。十轮二十轮下来，发散累积成偏移，偏移累积成失控。
但这不是 AI 的锅------这是你的项目管理出了问题。
三、Harness Engineering：真正的核心能力
前端工程化的核心是 Vite（工具链），AI 工程化的核心是 Harness（驾驭体系） 。
Harness Engineering 的核心思想：
arduino
你的角色不是"写代码的人"，而是"驾驭 AI 写代码的人"。
你的产出不是代码，而是一套让 AI 持续产出高质量代码的流程。就像一个 Formula 1 车队------车手（AI）再快，没有车队经理（你）制定策略、规划进站、监控数据，比赛一定崩。
四、Vibe Coding 标准工作流程
4.1 开发前的 9 个步骤
规划就是一切。
9 个步骤分为三个大阶段，层层递进：
🏗️ 第一阶段：定图纸
Step 1 ------ 导出需求（像聊天一样）
别急着写代码。先像跟朋友聊天一样，把下面这些东西全部讲给 AI 听：
- 痛点：足够痛吗？没被解决吗？有市场吗？
- 目标用户：谁在用？什么场景？
- 核心功能：你最理想的功能是什么样的？
不用追求严谨，不用追求信息量。先倒出来，让 AI 理解你要干什么。
Step 2 ------ 输出 PRD 文档，你来验收
让 AI 把上面的聊天内容整理成一份结构化的 PRD（产品需求文档） ，包括：
- 功能列表
- 用户流程
- 页面清单
关键动作：每个功能必须加上"验收标准"------到底做到什么程度才算完成？
反例：
❌ "实现登录功能"
正例：
✅ "实现登录功能：登录成功跳转到首页（或登录前的页面）；登录失败显示'用户名或密码错误'；连续失败 3 次锁定 15 分钟；支持记住密码 7 天"
没有边界，AI 会越来越发散。验收标准就是你的"篱笆"。
Step 3 ------ 提前定好视觉和页面框架
找 2-3 个参考网页，或让 AI 生成几种风格的方案。提前决定：
- 页面布局
- 每个页面包含哪些内容区块
- 整体风格：简约风？豪华风？暗黑模式？
输出为 DESIGN.md。
这一步的意义：避免 AI 在写功能逻辑的同时，把 UI 推倒重来。 功能和视觉解耦，各管各的。
🧱 第二阶段：打地基
Step 4 ------ 明确项目边界和非功能需求
问自己四个问题：
| 维度 | 要明确的 |
|---|---|
| 部署 | 本地跑？还是线上公开？ |
| 用户 | 用户量多少？有没有用户系统？涉及支付吗？ |
| 性能 | 首屏加载几秒？API 响应多快？ |
| 成本 | 服务器预算？API 调用费用上限？ |
安全、性能、可用性、成本------这四个非功能需求不写清楚，后面一定返工。
Step 5 ------ 锁定技术栈，越可验证越好
不要追新。适合的就是最好的。
推荐组合：React + TypeScript + Tailwind CSS选型原则：生态成熟、社区活跃、AI 训练数据充足。AI 对冷门框架的幻觉率远高于主流框架。
输出为 CLAUDE.md（或项目级的技术栈声明）。
Step 6 ------ 让 AI 出轻量架构草案
让 AI 给出：
- 目录结构：怎么分层？
- 核心模块：有哪些模块？各自的职责？
- 数据模型：实体关系？字段定义？
- 组件树：组件的层级和复用关系？
不需要 UML 图，不需要 50 页文档。轻量但完整即可。
📐 第三阶段：立规矩
Step 7 ------ 固化成文档
把前面的所有规划写成项目根目录下的 Markdown 文件：
objectivec
project-root/
├── PRD.md ← 产品需求文档
├── ARCH.md ← 系统架构文档
├── DESIGN.md ← 设计文档
├── Project.md ← 当前项目阶段文档（动态更新）
└── CLAUDE.md ← AI 的全局上下文/永久约束为什么这一步是所有步骤中最关键的？
现代的 AI Agent（Claude Code、Cursor、Codex 等）在和 LLM 交互时，都会读取项目根目录的约定文档作为系统级上下文。这些文档是：
- 🧠 全局记忆：AI 不会忘记三天前定的架构
- 🔒 永久约束：AI 每一轮生成的边界条件
- 📋 一致性保障：所有 AI agent 共享同一套规则
Step 8 ------ 定开发规范和建参考资料文件夹
- 代码规范：命名约定、文件组织、注释风格
- 错误处理规范：try-catch 模式、错误上报方式
- API 接口规范：RESTful 规范、请求/响应格式
- 参考样本：放一个"标准写法"的示例文件，AI 照猫画虎比凭空生成靠谱得多
go
project-root/
└── docs/
└── references/
├── api-example.md ← API 调用标准写法
├── component-example.md ← 组件标准写法
└── error-handling.md ← 错误处理标准写法Step 9 ------ 搞好 Git 和质量闸门
- 每轮 AI 生成 → commit 一个快照
- 不满意 →
git reset --hard回退 - 每次 push 前 → lint + 类型检查 + 测试通过
4.2 开发中的 5 个关键点
（原文在此处截断------以下为根据上下文和 Harness Engineering 理念的合理展开）
关键点 1：小步提交，频繁回滚
sql
每完成一个小功能 → git add + commit
下一轮生成不满意 → git reset --hard HEAD~1AI 生成代码不是线性的------它像掷骰子。小步快跑，降低每次试错的成本。
关键点 2：每次只让 AI 做一件事
arduino
❌ "帮我加上登录、注册、个人中心和设置页面"
✅ "现在只做登录页面，用户名+密码登录，按 PRD 第 3 节的验收标准来"Prompt 越长，AI 越容易发散。一次一件事，件件有着落。
关键点 3：始终参考文档
每次 Prompt 都带上：
参考项目根目录的 PRD.md、ARCH.md 和 DESIGN.md 中的约定让 AI 始终"戴着镣铐跳舞"------镣铐就是你的文档体系。
关键点 4：人工审核，不盲目信任
AI 生成的代码 = 初稿。你必须：
- 读懂核心逻辑（不需要逐行读，但关键路径要看）
- 跑起来验证
- 检查边界条件
你不审，就没人审。
关键点 5：持续更新 Project.md
Project.md 是你项目的"仪表盘"，动态记录：
- 当前在哪个阶段
- 哪些功能已完成
- 哪些在开发中
- 遇到了什么问题（给下一轮 AI 参考）
五、总结：一张图看清 Vibe Coding 工作流
markdown
Vibe Coding 标准工作流
┌──────────────────────────────────────────────────────────────┐
│ │
│ 第一阶段：定图纸 第二阶段：打地基 │
│ ┌──────────┐ ┌──────────┐ │
│ │ 1. 导需求 │──→ 2. PRD │ 4. 定边界 │──→ 5. 定技术栈 │
│ │ 3. 定视觉 │ │ 6. 出架构 │ │
│ └──────────┘ └──────────┘ │
│ │ │ │
│ └──────────┬─────────────────┘ │
│ ↓ │
│ 第三阶段：立规矩 │
│ ┌─────────────────────────────────────┐ │
│ │ 7. 文档固化 (PRD/ARCH/DESIGN/PROJECT)│ │
│ │ 8. 开发规范 + 参考资料 │ │
│ │ 9. Git 闸门 │ │
│ └─────────────────────────────────────┘ │
│ ↓ │
│ 进入开发迭代（5 个关键点） │
│ ┌─────────────────────────────────────┐ │
│ │ 小步提交 → 单任务 → 参考文档 → 审核 → 更新状态 │
│ └─────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────┘六、写在最后
Vibe Coding 时代的核心竞争力，不是你写代码有多快------因为 AI 永远比你快。
真正的核心竞争力是：
你能不能搭建一套流程，让 AI 持续、稳定、高质量地产出代码。
这就像工业革命------手工再精湛的工匠，也打不过掌握了流水线的人。AI 是蒸汽机，而 Harness Engineering 是你的流水线设计能力。
记住这两句话：
- 规划就是一切。 先定好图纸，再让 AI 施工。
- Git 是你的后悔药。 大胆试，快速回，零成本迭代。
别再直接把需求丢给 AI 然后等奇迹了。去写你的 PRD.md、ARCH.md、DESIGN.md 吧------那才是你作为 Vibe Coder 真正该写的代码。
📌 本文基于 Vibe Coding Harness 工具学习笔记整理
核心思想：Harness Engineering（驾驭工程）------不是让 AI 替你写代码，而是你驾驭 AI 写出好代码。