Vibe Coding 的“驾驭”指南：从“失控屎山”到“精准控制”

从“失控屎山”走向“精准驯服”：Vibe Coding 的“驾驶”指南

前言：Vibe Coding 的魔咒

这样的“过山车”，几乎每个尝试 Vibe Coding（氛围编程）的人都经历过：

• 初期：真爽！和 AI 聊上几句，功能马上出现，仿佛无所不能。
• 让 AI 改一下。中期却发现：嗯？怎么这里冒出了 Bug？
• 后期：修好一个地方，却弄坏了三个地方；代码越来越乱，逻辑彼此冲突。最终得到的，是一座全新的——屎山。

GPT-4、Claude 3.5 Sonnet 的聪明程度已经足够，所以问题并不是 AI 不够强。那么，问题究竟出在哪？

它其实更像一场“人机结对编程”的越野拉力赛，你却把 Vibe Coding 误解成了“甩手掌柜”式魔法。因此，单纯的代码能力已不够，你还需要工程化能力去驾驭 AI，也就是 Harness Engineering（ harness：驾驭/套索）。

为了让 AI 开发之旅摆脱失控，本文会带你搭建完整的 Vibe Coding 工作流；它所起的作用，就像 Vite 之于前端工程化。

一、 基础工具：Git 的“后悔药”与“时光机”

正式讨论 Vibe Coding 流程之前，必须先掌握版本控制的底层逻辑；AI生成的代码常会偏离目标，因此回退属于高频操作。

1. 你的“现在”位于何处？看 HEAD 指针

在 Git 的世界里，HEAD 是一个指针，它指向你当前所在的本地分支的最新提交（或者说，当前工作目录是基于哪个提交构建的）。

• 它是一个引用，并非文件夹——先理解这个指针。在 .git/HEAD 文件里，通常保存着 ref: refs/heads/main，表示它指向 main 分支。
• 分离 HEAD：如果你 git checkout 到一个具体的 commit hash，HEAD 就不再指向分支，而是直接指向提交，这就进入了“分离 HEAD”状态，此时任何修改都容易被丢弃，需谨慎。

2. git reset：保留记忆完成“穿越”

reset 移动 HEAD 指针的位置，靠的是 Vibe Coding 中最强的“反悔”工具，也就是这个命令。各种用法的核心差异，是对暂存区（Staging Area）和工作区（Working Directory）的处理方式。

# 回退到上一个提交，并丢弃所有本地修改（慎用！）git reset --hard HEAD^# 回退到上一个提交，但保留工作区的修改git reset --soft HEAD^

为了理解 --hard 和 --soft，我们需要引入 Git 的“三棵树” 概念（这也是面试高频题）：

1. 电脑上直接呈现的文件，就是工作区 (Working Directory)。
2. 暂存区 (Index/Staging Area)：git add 后存放的地方，准备打包提交。
3. 本地仓库 (Repository/HEAD)：git commit 后存储的永久快照。

解析 --soft 的妙用：执行 git reset --soft HEAD^ 后，你的代码修改还在工作区，并且被自动 git add 放回了暂存区。

3. git restore vs git checkout：精准执行“丢弃”

Git 2.23 引入了 restore 命令，专门用来撤销修改，因为它比 checkout 职责更单一。

# 1. 将文件从暂存区移除 (Unstage)，但保留工作区的修改# 等同于 git reset HEAD readme.mdgit restore --staged readme.md# 2. 丢弃工作区的修改 (危险！无法找回)# 等同于 git checkout -- readme.mdgit checkout -- readme.md

底层解析：git checkout -- readme.md 的本质是用暂存区（或 HEAD）中的同名文件覆盖工作区的文件。如果工作区的文件是新创建的且从未 add，Git 找不到该文件的索引记录，checkout 会报错或无法操作，此时只能手动删除。

二、 Vibe Coding 的“驾驶舱”建设

掌握油门（写代码）和刹车（回退）后，下一步是规划路线。这也是本文核心：开发开始前的 9 大步骤。

第一阶段：确定图纸（规划阶段）

不要上来就写代码，Vibe Coding 的 Prompt 不是聊天，而是需求沟通。

1. 导需求：像向朋友倾诉一样描述问题

不要使用专业 PRD 语言，应以自然、感性的方式向 AI 描述需求。

• 痛点：例如每天整理 Excel 表格汇总数据太累了，究竟是哪件事让你特别难受？
• 目标用户：例如不懂 SQL 的运营小白，谁会需要这个？
• 核心功能：它在你的理想中应该是什么样子？

思考深度：这一步不是让 AI 写代码，而是让 AI 建立业务上下文（Context）。没有上下文，AI 写的代码只是“语法正确的废话”，有上下文才是“解决问题的良药”。

2. 整理 PRD：给 AI 戴上“紧箍咒”

再让 AI 把刚才的对话整理为结构化 PRD.md。

关键动作：边界条件必须写死，并据此定义完成标准（Definition of Done, DoD）；只写“登陆功能”绝对不够。

为什么一定要这样做？缺少验收标准时，AI会默认采用最通用的逻辑，例如失败后弹出alert。代码增加以后，AI为了适配某个模糊逻辑会不断发散，最终让不同代码逻辑彼此矛盾。

3. 提前确定视觉：避免 UI 反复变化

让 AI 生成代码时，一个常见难题是：它为了修正按钮样式，可能重做整个布局，因为 React/Vue 的样式与 DOM 结构相互耦合。

措施：生成 DESIGN.md 之前，应在项目初期完成讨论并确定方案；素材可以是 2-3 个参考网站，也可以是 AI 生成的几种设计风格。

• 布局：采用左侧导航还是顶部导航？
• 风格：选择极简主义还是赛博朋克？
• 色彩：主色应该是什么？（例如：#00B4D8）

这样可以把 UI 决策提前完成。后续开发时，AI只需依照 DESIGN.md 的约束实现，不必继续创新，因为创新也意味着变数。

第二阶段：夯实地基（技术选型与架构）

图纸已经完成，现在开始打桩。

4. 决定“天花板”的条件：明确非功能需求（NFRs）

它能活多久由非功能需求决定，能做什么则由功能需求决定。四个维度若有任何一个没写清楚，返工必定会出现在后面。

• 安全性：需不需要防 SQL 注入和 HTTPS？其中有没有用户数据？
• 性能：首屏加载（LCP）要求定在多少？页面加载可接受的时长是几秒？
• 可用性：面向全球用户时要求99.99%，给自己用则是99% 可用性，属于哪一种？
• 成本：是否用得起 AI 大模型 API，取决于服务器预算是多少。

5. 固定技术栈：越标准越合适

适合的方案才是最好选择，因为环境配置最容易让 Vibe Coding 陷入折腾。

React + TypeScript + Tailwind CSS + Vite，是推荐栈。

• React：生态最完善，即使 AI 无法回答，社区中通常也能找到答案。
• 强制类型约束：TypeScript。JS 一旦交给 AI 写，很容易写成 any 大法，而 TS 可以约束 AI 自身，减少运行时 Bug。
• Tailwind CSS：Utility-first。AI 不需要理解复杂的 CSS 类名继承关系，直接在 className 里堆砌样式即可，极大降低 AI 理解 CSS 的复杂度。

进一步说，现在不少 AI 支持 claude.md 或 .cursorrules 文件。告诉 AI：“函数式组件和这个技术栈都必须使用。”为此，你要在项目根目录创建该文件。

6. 制定轻量架构草案：明确分层和模型

ARCH.md 必须由 AI 输出，哪怕只有 200 行；至于复杂的 UML 图，则不需要画。

• 目录结构：/components, /pages, /hooks, /utils, /services/api。
• 数据模型：用户表 User 包含哪些字段？文章表 Post 包含哪些字段？
• 组件依赖：哪些属于无状态的纯 UI 组件，哪些属于有状态的容器组件？

第三阶段：建立规矩（开发规范与持久化）

地基完成后必须建立规矩，否则工人（AI）就会随意行动。

7. 固化为文档：建立 AI 的“永久记忆”

RAG（检索增强生成） 或 长上下文（Long Context），构成了现在 Agent 交互的核心机制。为此，几个永不删除的全局上下文文件需要维护在项目根目录：

my-project/├── PRD.md# 产品需求（告诉 AI 在做什么）├── DESIGN.md # 设计系统（告诉 AI 长什么样）├── ARCH.md # 系统架构（告诉 AI 怎么组织代码）├── PROJECT.md# 当前进度（告诉 AI 做到哪一步了，下一步干什么）└── .cursorrules# IDE 级别规则

解析：每次开启新对话时，必须手动把这几个文件拖拽给 AI（或通过 IDE 插件自动加载）。这能保证即使 AI 的上文窗口丢失，它也能迅速恢复对项目的全局认知。

8. 规定开发规范并准备参考资料

向 AI 提供样本作为参照，可以明显改善代码质量。

• 代码规范：给出一段自己满意的组件代码，并要求 AI 让所有组件都采用相同风格。
• 例如以下方式：错误处理时统一 API 返回格式。{ code: 0, data: {}, msg: '' }。
• 向 AI 交代路由设计原则：Restful 规范。

9. 配置 Git 与质量闸门（Quality Gate）

这是最后一道物理防线：AI提交代码以前，静态检查必须通过。

• Pre-commit Hook：使用 husky + lint-staged。
• 流程：AI 生成代码 -> 运行 eslint --fix -> 运行 prettier -> 自动修复格式 -> 若仍存在 Error，则阻止提交；AI 修复完成后方可提交。

命令示例：

// package.json{"lint-staged": {"*.{js,jsx,ts,tsx}": ["eslint --fix", "prettier --write"]}}

这样做能让 AI 学会在提交前自我审查格式问题，减少 Code Review 的噪音。

三、 5 个开发“定海神针”的简要概括

受篇幅限制，这里对笔记提到的开发中 5 个关键点作进一步归纳，帮助你形成完整思维导图：

1. 单一职责原则 (SRP)：一件事对应一个组件。若 AI 产出的大组件达到 500 行，应立即要求它进行拆分。
2. 状态管理下沉：可以采用局部状态（useState）为防 AI 滥用 Context 而造成无限渲染，别用全局状态（Redux/Zustand）。
3. 先让 AI 把 API 的处理完，再写 UI：契约先行 (Contract First) types.ts 定义完成，再由 UI 层直接调用类型。
4. 日志埋点：要求 AI 在支付、登录等关键路径加入 console.log 或简单日志，以便调试黑盒逻辑。
5. 小步快跑，频繁提交：每完成一个功能点（即使它有点丑），立刻 git commit。方便随时 reset --hard 回到上一个“虽不完美但可用”的状态。

总结：“烈马”与“骑手”共同构成 Vibe Coding 这场共舞

由 AI 驱动的增量式开发，才是 Vibe Coding 的本质；它并不是魔法。

• 上下文工程（Context Engineering）是底层逻辑：对上下文（PRD, ARCH）的投喂越精准，AI 生成的代码就越可控。
• 本质：你不是在写代码，你是在做架构决策和质量验收。Git 是你的“缰绳”，文档是你的“地图”，质量闸门是你的“马鞍”。

在 AI 编程时代，愿这份“驾驶指南”助你把野马驯服，成为真正能驾驭代码的骑手，别沦为让屎山吞噬的“铲屎官”。

（完）

点赞、收藏、评论，是你喜欢这类硬核且实用的 Vibe Coding 指南时可以给出的反馈。下期我们会把“如何在 Cursor 中配置 .cursorrules 文件”的底层逻辑讲深讲透！