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

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

前言：Vibe Coding 的魔咒

只要你尝试过 Vibe Coding（氛围编程），大概都坐过这样一趟“过山车”：

• 初期：太爽了！只需和 AI 聊上几句，功能便做好了，仿佛自己无所不能。
• 中期：咦？这里怎么冒出一个 Bug？交给 AI 改改。
• 后期：每改一个地方，就有三个地方出错。逻辑开始互相打架，代码也越来越乱。到最后，你收获了一座全新的——屎山。

GPT-4、Claude 3.5 Sonnet 已经足够聪明，所以问题并不是 AI 不够强。那究竟错在何处？

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

为了让 AI 开发之旅摆脱失控，本文会带你搭建完整的 Vibe Coding 工作流，其作用正如 Vite 对前端工程化的推动。

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

AI 生成的代码经常跑偏，使回退成为高频操作。因此，版本控制的底层逻辑必须先精通，再正式讨论 Vibe Coding 流程。

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 中成为最强“反悔”工具的原因。各种用法之间，关键差异落在工作区（Working Directory）与暂存区（Staging Area）的处理方式上。

# 回退到上一个提交，并丢弃所有本地修改（慎用！）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 “反复横跳”：预先确定视觉

由于 React/Vue 的样式和 DOM 结构存在耦合，AI 生成代码时可能只为修一个按钮样式，就把整个布局推倒重来，这最让人头疼。

措施：先在项目初期准备 2-3 个参考网站，也可以请 AI 产出几种设计风格；待讨论并确定后，再形成一份 DESIGN.md。

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

这么做能把 UI 决策提前完成。进入后续开发后，AI 只要遵循 DESIGN.md 的约束进行实现，无须再“创新”，因为创新就意味着变数。

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

图纸已经完成，接下来就要开始打桩。

4. “天花板”由非功能需求（NFRs）决定

功能需求决定产品能做什么，非功能需求则决定它能生存多久。只要这四个维度没有说明白，后续返工就不可避免。

• 安全性：先判断有无用户数据，再确定 HTTPS 和防 SQL 注入是否需要。
• 性能：明确可接受的页面加载秒数，以及首屏加载（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 直接堆在 className 里，由此不必理解复杂的 CSS 类名继承关系，AI 理解 CSS 时面对的复杂度也会极大降低。

进一步说，现在不少 AI 已经支持 claude.md 或 .cursorrules 文件。告诉 AI “你必须使用这个技术栈，且必须使用函数式组件。”之前，需要先把该文件创建在项目根目录。

6. 轻量架构草案：明确分层与模型

哪怕只有 200 行，一份由 AI 输出的 ARCH.md 也不可缺少；复杂的 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: '' }。
• Restful 规范：把路由设计原则交代给 AI。

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）为防止 Context 被 AI 滥用并造成无限渲染，不要采用全局状态（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，而非魔法。

• 代码输出能否受控，取决于你给 AI 的上下文（PRD, ARCH）有多精准；其底层依据正是上下文工程（Context Engineering）。
• 本质：你不是在写代码，你是在做架构决策和质量验收。Git 是你的“缰绳”，文档是你的“地图”，质量闸门是你的“马鞍”。

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

（完）

点赞、收藏、评论，是你喜欢这份硬核实用 Vibe Coding 指南的最好回应！“如何在 Cursor 中配置 .cursorrules 文件”的底层逻辑，我们下期再深入探讨。