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 开发之旅摆脱失控，需要一套如同 Vite 之于前端工程化的完整 Vibe Coding 工作流，本文将带你构建它。

一、 基础工具：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 里最强的“反悔”工具。各种方式之间的核心差别，在于对暂存区（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“反复横跳”：先把视觉定下来

由于 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。直接把样式堆在 className 里即可，复杂的 CSS 类名继承关系不再需要 AI 理解，由此可大幅削减 AI 理解 CSS 时面对的复杂度。

进一步来说，如今许多 AI 支持 claude.md 或 .cursorrules 文件。这个文件应创建在项目根目录，并用于要求 AI：“这个技术栈和函数式组件，你都必须使用。”

6. 制定轻量级架构草案：分层与模型

复杂的 UML 图可以不画，但必须要求 AI 输出一份 ARCH.md，即使内容只有200行也不能省略。

• 目录结构：/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）避免 AI 因滥用 Context 而造成无限渲染，不要采用全局状态（Redux/Zustand）。
3. 契约先行 (Contract First)：先让 AI 把 API 的，再写 UI types.ts 定义完成，随后由 UI 层直接调用类型。
4. 日志埋点：要求 AI 在支付、登录等关键路径中加入 console.log 或简单日志，以便调试黑盒逻辑。
5. 小步快跑，频繁提交：每完成一个功能点（即使它有点丑），立刻 git commit。方便随时 reset --hard 回到上一个“虽不完美但可用”的状态。

总结：“烈马”与“骑手”的共舞，正是 Vibe Coding

由 AI 驱动的增量式开发，才是 Vibe Coding，而非魔法。

• 底层逻辑：上下文工程（Context Engineering）是它的依托。AI 输出的代码能否得到控制，取决于你喂入的上下文（PRD, ARCH）是否足够精准。
• 本质：你不是在写代码，你是在做架构决策和质量验收。Git 是你的“缰绳”，文档是你的“地图”，质量闸门是你的“马鞍”。

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

（完）

点赞、收藏、评论，欢迎喜欢硬核且实用的 Vibe Coding 指南的你参与；“如何在 Cursor 中配置 .cursorrules 文件”的底层逻辑，我们下期再深入探讨！