Vibe Coding 工程化指南：9 步前置流程告别 AI 屎山代码

AI 写代码越来越快，项目却越来越烂？ 问题不在 AI 强不强，而在于你有没有一套工程流程去驾驭它。这篇文章从 Git 版本控制到 Vibe Coding 9 步标准工作流，帮你彻底告别"AI 屎山代码"。

一、Vibe Coding 的真相：不是甩手掌柜

很多人对 Vibe Coding 有个误解：把需求丢给 AI，然后去喝咖啡，回来就能收代码。

现实是：项目推进特别快，但越往后代码越乱，慢慢变成屎山，越改越差，最终整个项目崩盘。

问题出在哪？不在 AI 的能力，而在于：

复制代码

❌ 错误认知：AI 写代码 → 我喝咖啡 → 项目完成
✅ 正确认知：构建工程流程 → 驾驭 AI → 持续可控地交付

这就是 Harness Engineering（挽具工程） 的核心思想 ------ 你需要给 AI 套上"挽具"，让它沿着你规划的道路跑，而不是横冲直撞。

前端工程化有 Vite，Vibe Coding 工程化也需要自己的"工具链"，而 Git 就是其中最基础的一环。

二、Git：Vibe Coding 的安全绳

在 Vibe Coding 中，Git 不仅是版本控制工具，更是你的安全绳 ------ AI 写崩了，随时能回退。

2.1 HEAD 指针：你在哪，它指哪

HEAD 是 Git 中最重要的概念之一，它指向当前所在的分支和版本：

markdown 复制代码

当前分支: main
HEAD → main → commit-3 (最新)
                   ↑
              你在这里

git log:
* commit-3  (HEAD -> main)  feat: 添加登录页面
* commit-2                  feat: 添加路由
* commit-1                  init project

每次 commit，HEAD 就向前移动一步。每次 reset，HEAD 就退回指定的位置。

2.2 git reset：时间机器

git reset 是回退到历史任意版本的命令，两个关键参数的区别：

参数	工作区	暂存区	适用场景
`--hard`	丢弃所有修改	丢弃所有修改	彻底回退，仓库变干净
`--soft`	保留修改	修改进入暂存区	回退版本但保留代码

--hard 场景：AI 把代码写崩了，彻底不要了

bash 复制代码

# AI 把整个项目改乱了，直接回到上一个干净版本
git reset --hard HEAD~1

# 效果：代码、暂存区全部回到 commit-2 的状态
# commit-3 的修改全部丢弃，仓库是干净的

--soft 场景：回退版本但保留 AI 生成的代码

bash 复制代码

# AI 生成了新功能，但 commit 信息写错了，想重新提交
git reset --soft HEAD~1

# 效果：HEAD 回到 commit-2
# 但 AI 生成的代码还在暂存区，可以直接重新 commit
git commit -m "feat: 正确的提交信息"

用一张图理解区别：

ini 复制代码

回退前：
  工作区: [AI修改的代码]  暂存区: [AI修改的代码]  HEAD → commit-3

--hard 回退后：
  工作区: [空]            暂存区: [空]            HEAD → commit-2
  （全部丢弃，干干净净）

--soft 回退后：
  工作区: [AI修改的代码]  暂存区: [AI修改的代码]  HEAD → commit-2
  （代码还在，只是版本指针退了）

2.3 暂存区与工作区的精细操作

除了 reset，还有两个常用命令用于精细控制：

bash 复制代码

# 将暂存区的文件移回工作区（取消 git add）
git restore --staged readme.md

# 效果：
# 暂存区: readme.md 被移除
# 工作区: readme.md 的修改仍然保留

# 丢弃工作区的修改（彻底放弃改动）
git checkout -- readme.md

# 效果：
# 工作区: readme.md 恢复到上次 commit 的状态
# 你的修改永远消失了，不可恢复！

Vibe Coding 中的 Git 策略 ：每次让 AI 做重要修改前，先 commit 一次。AI 写崩了就 reset --hard 回退，写得不错就继续。这就是"安全绳"的用法。

三、Vibe Coding 9 步标准工作流

这是整个文章的核心。9 个步骤分为三个阶段：定图纸 → 打地基 → 立规矩。

vbnet 复制代码

┌─────────────────────────────────────────────────────────┐
│                  Vibe Coding 前置流程                      │
│                                                         │
│  阶段一：定图纸（需求与设计）                                │
│    Step 1. 导需求                                        │
│    Step 2. 写 PRD                                        │
│    Step 3. 定视觉框架                                     │
│                                                         │
│  阶段二：打地基（技术与架构）                                │
│    Step 4. 明确边界和非功能需求                              │
│    Step 5. 锁定技术栈                                     │
│    Step 6. 出轻量架构草案                                  │
│                                                         │
│  阶段三：立规矩（规范与文档）                                │
│    Step 7. 固化成文档                                     │
│    Step 8. 定开发规范                                     │
│    Step 9. 搞好 Git 和质量阀门                              │
└─────────────────────────────────────────────────────────┘

阶段一：定图纸

Step 1：导需求 ------ 像聊天一样把痛点讲清楚

先别写代码，先跟 AI 聊天，把以下内容全部讲清楚：

痛点：足够痛、没解决、有市场
目标用户：谁会用这个产品
使用场景：在什么情况下用
核心功能：理想中的功能是什么

不用追求严谨，就像跟朋友聊天一样把想法倒出来。

Step 2：写 PRD ------ 没有验收标准，AI 必然发散

让 AI 把需求整理成结构化的 PRD.md（产品需求文档），包含：

功能列表
用户流程
页面清单

最关键的一点 ：每个功能都要补上验收标准（边界）。

markdown 复制代码

❌ 模糊的描述：
   "用户可以登录"

✅ 有验收标准的描述：
   "用户登录功能：
    - 登录成功 → 跳转到首页
    - 密码错误 → 提示'密码错误，请重试'
    - 账号不存在 → 提示'账号未注册'
    - 网络超时 → 提示'网络异常，请稍后重试'
    - 连续错误 5 次 → 锁定账号 30 分钟"

没有验收标准，AI 会写得越来越发散，最终功能无限膨胀。

Step 3：定视觉框架 ------ 不让 AI 边写逻辑边推导 UI

找 2-3 个参考网站，或者让 AI 生成几种风格方案，提前确定：

网页布局（导航栏在哪、侧边栏有没有）
页面内容清单
整体风格（简约风 vs 豪华风）

输出 DESIGN.md。

为什么要提前定？ 如果不提前定，AI 会一边写功能逻辑，一边把 UI 推翻重来，导致代码反复重构。

阶段二：打地基

Step 4：明确边界和非功能需求

四个非功能性需求必须写清楚，否则一定返工：

需求维度	要回答的问题	示例
安全	有没有用户数据？支付？	用户数据加密存储，支付走第三方
性能	用户量多少？响应时间上限？	首屏加载 < 2s，支持 1000 并发
可用性	本地跑还是线上公开？	线上公开，SLA 99.9%
成本	服务器/API 预算上限？	月成本 < 500 元

Step 5：锁定技术栈 ------ 越可验证越好

适合的就是最好的，不要追新：

复制代码

推荐技术栈（可验证、社区成熟）：
├── 框架：React + TypeScript
├── 样式：TailwindCSS
├── 构建：Vite
├── 状态：Zustand / Context API
└── 部署：Vercel / Netlify

输出 CLAUDE.md，让 AI 在整个开发过程中始终知道技术栈是什么。

为什么强调"可验证"？ AI 对最新框架可能存在幻觉，选择成熟稳定的技术栈，AI 生成的代码更可靠，出问题也更容易查到解决方案。

Step 6：出轻量架构草案

让 AI 产出架构设计，包括：

目录结构：怎么分层（pages / components / hooks / utils / api）
核心模块：有哪些功能模块，模块间怎么交互
数据模型：核心实体长什么样（TypeScript Interface）
组件清单：有哪些可复用组件

bash 复制代码

src/
├── pages/          # 页面组件
│   ├── Home/
│   ├── Login/
│   └── Dashboard/
├── components/     # 通用组件
│   ├── Button/
│   └── Modal/
├── hooks/          # 自定义 Hooks
├── utils/          # 工具函数
├── api/            # API 请求层
├── types/          # TypeScript 类型定义
└── stores/         # 状态管理

阶段三：立规矩

Step 7：固化成文档 ------ AI 的全局上下文

把前面的所有成果写成项目根目录下的文档，这些文档是 AI 的永久约束：

文档	作用	内容
`PRD.md`	产品需求文档	功能列表、用户流程、验收标准
`ARCH.md`	系统架构文档	目录结构、模块划分、数据模型
`DESIGN.md`	设计规范	页面布局、视觉风格、组件规范
`CLAUDE.md`	技术栈约束	框架、库、版本、编码规范
`Project.md`	当前项目阶段	已完成功能、待办事项、已知问题

这些文档就是 AI 的"全局上下文"。每次跟 AI 对话时，它会读取这些文档，确保开发方向不偏。

Step 8：定开发规范和参考资料

提前定好规范，避免 AI 每次写法都不一样：

代码规范：命名风格、文件组织、注释格式
错误处理：统一错误处理模式（try-catch / Result 模式）
API 接口：RESTful 规范、请求/响应格式
参考资料：给 AI 一个样本代码作为参考

typescript 复制代码

// 统一的 API 响应格式
interface ApiResponse<T> {
  code: number;       // 0 成功，非 0 失败
  message: string;    // 提示信息
  data: T;            // 业务数据
}

// 统一的错误处理
try {
  const res = await api.login(params);
  if (res.code !== 0) {
    toast.error(res.message);
    return;
  }
  // 处理成功逻辑
} catch (err) {
  toast.error('网络异常，请稍后重试');
}

Step 9：搞好 Git 和质量阀门

最后一步，建立质量保障机制：

bash 复制代码

# 初始化 Git 仓库
git init

# .gitignore 排除不需要追踪的文件
node_modules/
dist/
.env
.DS_Store

# 每个功能完成后立即 commit
git add .
git commit -m "feat: 完成用户登录功能（含验收标准）"

质量阀门包括：

提交前检查：AI 生成的代码是否满足验收标准
分支策略：main 分支保持可用，feature 分支开发新功能
回退机制：每个功能点 commit 一次，出问题能精准回退

四、9 步流程速查表

阶段	步骤	产出物	核心原则
定图纸	1. 导需求	聊天记录	痛点足够痛
定图纸	2. 写 PRD	PRD.md	每个功能有验收标准
定图纸	3. 定视觉	DESIGN.md	不让 AI 边写逻辑边改 UI
打地基	4. 明边界	非功能需求清单	安全/性能/可用性/成本
打地基	5. 锁技术栈	CLAUDE.md	越可验证越好
打地基	6. 出架构	架构草案	目录分层 + 数据模型
立规矩	7. 固文档	多个 .md 文件	AI 的全局上下文
立规矩	8. 定规范	代码规范 + 样本	统一写法
立规矩	9. 搞 Git	Git 仓库 + 策略	每个功能点一次 commit

五、开发中的关键原则

9 步前置流程完成后，进入实际开发阶段。以下是开发中需要持续遵守的原则：

5.1 规划伴随全程

9 步流程不是一次性做完就扔了。每开发一个新功能模块，都需要：

更新 PRD.md 中该功能的验收标准
更新 ARCH.md 中的模块和数据模型
更新 Project.md 中的当前进度

5.2 小步快跑，频繁提交

sql 复制代码

❌ 错误做法：
   让 AI 一次性写完整个项目 → 测试 → 发现全是 bug → 无法定位

✅ 正确做法：
   功能点 1 → commit → 测试 → ✅
   功能点 2 → commit → 测试 → ✅
   功能点 3 → commit → 测试 → ❌ → reset --hard 回退到功能点 2
   重新让 AI 写功能点 3 → commit → 测试 → ✅

5.3 始终以文档为准

当 AI 的输出与文档冲突时，以文档为准。如果需求确实变了，先改文档，再改代码。

markdown 复制代码

需求变更流程：
   1. 更新 PRD.md（改验收标准）
   2. 更新 ARCH.md（改架构）
   3. 让 AI 基于新文档重新实现
   4. commit

六、知识图谱

yaml 复制代码

Vibe Coding 工程化
├── Git 版本控制
│   ├── HEAD 指针：指向当前版本
│   ├── reset --hard：彻底回退（丢弃修改）
│   ├── reset --soft：版本回退（保留修改到暂存区）
│   ├── restore --staged：暂存区 → 工作区
│   └── checkout --：丢弃工作区修改
│
├── 前置 9 步流程
│   ├── 阶段一：定图纸
│   │   ├── Step 1: 导需求（痛点/用户/场景/功能）
│   │   ├── Step 2: 写 PRD（含验收标准）
│   │   └── Step 3: 定视觉框架（DESIGN.md）
│   │
│   ├── 阶段二：打地基
│   │   ├── Step 4: 非功能需求（安全/性能/可用性/成本）
│   │   ├── Step 5: 锁技术栈（CLAUDE.md）
│   │   └── Step 6: 架构草案（目录/模块/数据模型）
│   │
│   └── 阶段三：立规矩
│       ├── Step 7: 固化文档（PRD/ARCH/DESIGN/CLAUDE/Project）
│       ├── Step 8: 开发规范（代码/错误处理/API/样本）
│       └── Step 9: Git + 质量阀门
│
└── 开发中原则
    ├── 规划伴随全程（文档持续更新）
    ├── 小步快跑（频繁 commit）
    └── 文档为准（需求变更先改文档）

七、总结

Vibe Coding 的核心不是"让 AI 写代码"，而是"用工程流程驾驭 AI"。

Git 是安全绳 ------ reset --hard 回退崩盘，reset --soft 保留代码重新提交
9 步前置流程 ------ 定图纸（需求/PRD/视觉）→ 打地基（边界/技术栈/架构）→ 立规矩（文档/规范/Git）
验收标准是刹车片 ------ 没有验收标准，AI 必然发散
文档是全局上下文 ------ PRD.md / ARCH.md / CLAUDE.md 是 AI 的永久约束
小步快跑 ------ 每个功能点 commit 一次，出问题能精准回退

AI 是千里马，但你得先套上挽具。没有挽具的千里马，跑得越快，离目标越远。

系列文章推荐：

《Harness Engineering 深度解析：从 Prompt 到确定性交付的 AI 工程化革命》------ 理解挽具工程的全局视角
《别让 AI 写屎山代码！Vibe Coding 三步法》------ 开发中的具体编码策略
《MCP 协议深度解析：AI 界的 USB-C》------ AI 工具接入的标准化方案