vibe‑coding 九阳神功之夯：Git 基础操作，AI 时代的刹车系统（附速查表）

系列顺序：夯（Git） → 抄 → 学 → 喂
这一篇先把“刹车系统”装上：你能看清改动、能随时回退，后面才敢放心让 AI 开大改。

AI 编程现在最大的坑不是“不会写”，而是：

写得太快
改得太多
炸了没后路
炸完你甚至不知道它到底改了哪些文件

所以我准备写一套 vibe‑coding 九阳神功：核心不是提示词，而是把 AI 变成“可控交付的队友”。

这套“九阳神功”我先定了九个字诀：

夯：Git 生存技能（刹车 / 保险 / 录像）
抄：拆解 yfge/orion、ai-shifu/ai-shifu 的优秀骨架，搭底盘
学：会组合技术栈、会裁决，不懂原理也能不翻车
喂：把 API 文档 / 资料结构化成可执行知识
规：让 AI 出计划 + tasks.md，按清单推进
验：多模型交叉验证，专治幻觉
测：Chrome MCP 自动测试，交付有证据
扩：扩展认知边界，但必须可验证
收：上线交付、监控回滚、复盘闭环

一句话：不是教你“让 AI 写代码”，是教你“带着 AI 把东西交付上线”。

本篇是这个系列的第一篇，希望你喜欢：）

你把 AI 当队友没问题，但要先接受一个现实：AI 很容易一脚油门，把项目开进沟里。

所以 vibe‑coding（边跟 AI 聊边写代码）的第一步，不是提示词，而是——先给自己装一套刹车系统：Git。

对小白来说，学习 Git 确实有一点门槛，但我想了想，还是决定把它放在第一篇里讲。

“夯”的意思就是打基础。把 Git 作为 vibe‑coding 的基础操作，我觉得再合适不过。

小白只看这里（10 分钟够用版）：你只需要会“看改动 + 打存档”

你完全可以不会 Git 的所有概念，但在 vibe‑coding 里你至少要会两件事：

1) 看 AI 改了什么（有没有越界）
2) 随时打存档（崩了能回去）

把下面这套流程贴在屏幕边，照做就够用：

0）先确认：你在一个 Git 仓库里

git status

如果提示不是 Git 仓库，那你大概率是在一个普通文件夹里（还没 git init / 也不是 git clone 出来的项目）。

1）AI 改完：先“看它改了啥”（最关键）

git status
git diff

你只需要看两件事：

它改了哪些文件（有没有改到不该动的目录）
它改了哪些行（有没有一眼看出“胡写/乱改”）

2）确认没问题：打一个“存档点”

git add .
git commit -m "chore: savepoint"

小白提示：不会写提交信息也没关系，先用 savepoint 保命；后面再学怎么写规范提交。

3）要让 AI 干“大活”：先开分支（隔离舱）

git switch -c feature/xxx

写崩了最简单的处理方式不是救火，而是：回主线 + 扔掉分支（主线不受影响）：

git switch main  # 有些项目叫 master
git branch -D feature/xxx

4）小白底线：不确定就别用 `--hard`

你后面会看到 git reset --hard。它很强，但也很危险：会直接丢掉未提交的改动。
你没 100% 确定之前，就别用。

小白词典（这篇里最常用的 6 个词）

仓库（repo）：一个被 Git 管起来的项目目录（里面有 .git）
工作区（working tree）：你眼前看到的文件
暂存（staged）：你“准备放进这次提交包里”的改动
提交（commit）：一个存档点（能回退）
历史（log）：存档点列表
分支（branch）：隔离舱（AI 大改先去分支里折腾）

你不需要把概念背下来，只要记住：Git 的目的就是让你随时能看清改动、随时能回到上一个稳定版本。

为什么 vibe‑coding 必须先学 Git？

在和 AI 协作时，Git 能解决三件最要命的事：

1）可回退：写崩了能救回来

每一次提交（commit），就是给项目打一个“存档点”。

改崩了？退回上一个存档就行。
这在 vibe‑coding 里不是锦上添花，而是保命。

2）可重置：不满意就撤销（包括撤销提交）

你可以：

撤销“暂存”（git add）
撤销“提交”（git commit）

也就是说：你随时能按下 ESC。

3）可查看：它到底改了什么，一眼看明白

AI 最可怕的不是改错，而是悄悄改：

哪些文件动了？
改动范围有没有越界？
是否改到不该动的地方？

git diff 能直接告诉你：改动的内容和范围。

一句话总结：

Git = 你和 AI 协作时的录像 + 保险 + 刹车。

没有 Git 的 vibe‑coding，本质就是无刹车飙车。

二、安装 Git（Windows / macOS 小白版）

1）Windows 安装（推荐）

打开浏览器，搜索并进入 Git for Windows 官方下载页
下载并双击安装包
安装过程大部分选项保持默认即可，建议确认这一项：
- Use Git from the command line and also from 3rd-party software
安装完后打开 PowerShell 或 Git Bash，输入：

git --version

能看到版本号就说明安装成功。

2）macOS 安装（两种方式，择一即可）

方式 A：最省事（系统自动装）

打开终端，输入：

git --version

如果系统弹出提示安装 Command Line Tools，点“安装”即可。

方式 B：你已经装了 Homebrew 的情况下

brew install git
git --version

看到版本号就说明搞定。

三、先做一个最基础配置（姓名 / 邮箱）

这会写进你的提交记录里：

git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

检查是否生效：

git config --global --list

四、用一个 `notes.md` 贯穿：从 0 到会用 Git

我们用一个非常朴素的例子：
用 Git 管一个文档（需求说明 / 开发计划 / 学习笔记都行），叫：

notes.md

0）创建项目并初始化 Git 仓库

mkdir git-notes-demo
cd git-notes-demo
git init

看状态：

git status

会看到类似“当前没有要提交的内容”。

概念：仓库（repository）

git init 会在当前目录创建一个 .git 文件夹，从这一刻起，这个目录就变成了 Git 仓库。

1）创建 `notes.md`：Untracked（未跟踪）

创建文件：

macOS / Linux：

echo "# 我的笔记" > notes.md

Windows PowerShell：

"# 我的笔记" | Out-File -Encoding utf8 notes.md

查看状态：

git status

会看到：

Untracked files:
  notes.md

概念：Untracked（未跟踪）

文件已经存在
但 Git 还没开始管它

可以理解为：Git 还不知道这文件属于“版本控制范围”。

2）把文件纳入 Git 管控：Staged（暂存）

执行：

git add notes.md
git status

会看到：

Changes to be committed:
  new file: notes.md

概念：Staged（暂存区）

git add 不是提交，只是告诉 Git：

“这次提交准备把这些改动打包进去。”

3）提交（Commit）：给项目打一个“存档点”

执行：

git commit -m "docs: add notes"
git status

会看到：

working tree clean

概念：Commit（提交）

一次 commit = 一个版本点 / 存档点
vibe‑coding 的关键就是：小步提交，多打存档

查看历史：

git log --oneline

4）修改文件：Modified（已修改未暂存）

追加一行：

macOS / Linux：

echo "- 今天学会了 git init/add/commit" >> notes.md

Windows PowerShell：

"- 今天学会了 git init/add/commit" | Out-File -Append -Encoding utf8 notes.md

查看状态：

git status

会看到：

modified: notes.md

概念：Modified（已修改）

文件变了
但还没 git add
也就还没进入“这次提交的打包范围”

这时候你最应该做的一件事是：看差异。

git diff

你会看到具体新增 / 删除了哪些行。

这就是 vibe‑coding 的核心动作：
AI 改完 → 先 git diff 看它有没有越界。

5）再提交一次：小步提交

git add notes.md
git commit -m "docs: update notes"

到这一步，你已经走完一套最基础闭环。

五、最小“救命操作”：撤销与回退（小白够用版）

1）撤销 add：不想把这个改动提交了

如果你已经 git add，但反悔了：

git reset notes.md

效果：

文件还在、改动还在
只是不再处于“待提交”的状态

2）回退最近一次提交（保留改动）：常用

刚 git commit 完发现写错了 / 不该提交：

git reset --mixed HEAD~1

效果：

最后一次 commit 被撤销
文件改动还在
你可以重新修改、重新 add 再 commit

这就是“可重置”的核心用法。

3）彻底丢弃改动（慎用）

如果你确定不要这些改动：

git reset --hard

⚠️ 新手慎用：
它会丢掉你当前未提交的所有改动。
手一抖就是“删库式后悔”。

六、vibe‑coding 的“手规”：记住这 4 步就够了

每次让 AI 开始大改之前，按这个流程来：

先看状态
```
git status
```
改完先看差异
```
git diff
```
小步提交
```
git add .
git commit -m "..."
```
不对就撤
- 撤提交：git reset ...
- 实在不行：git reset --hard（确认真的不要再用）

当你掌握这套“刹车系统”后，AI 才会真正变成你的效率倍增器，而不是不定时炸弹。

不过到这里还有个容易误会的点：小步提交解决的是“可回退”，但不一定解决“别污染主线”。

如果只是改一两个文件、改完你能立刻验证：用 git diff + 小步提交就够了。
但只要是那种“AI 可能会改很多、你也不确定改到哪”的任务（比如重构、改目录结构、升级依赖、批量改配置），光靠提交当存档还不够安全——你需要一个隔离舱，把风险关在主线之外。

七、为什么 vibe‑coding 一定要用分支？

一句话：分支是 AI 大改时的“隔离舱”。

把分支这件事想清楚，你就会发现它和上一节是同一套体系：

上一节的“手规”解决的是：怎么稳稳地改（看 diff、小步提交、随时能撤）。
分支解决的是：在哪儿改更安全（先在隔离舱里折腾，确认可用再带回主线）。

你可以把 main（或 master）理解成：

稳定可用的主线路

每次让 AI 干一坨大的（重构 / 新功能 / 改目录结构），都在一个新分支里做：

改崩了？直接丢掉分支，主线毫发无损
改得不错？合并回 main，成为稳定版本的一部分
改得太多？可以在分支里拆成多个小 commit，慢慢审

没分支：AI 一脚油门踩在主线上。
有分支：AI 在隔离舱里翻车，你在外面喝茶。

八、分支的核心概念（小白版）

main：主分支，默认认为“能交付 / 能跑 / 相对稳定”
feature/xxx：功能分支（或修复分支），用来做某个具体任务
merge（合并）：把功能分支的成果合回 main
删分支：功能完成 / 不要了 / AI 写崩了 → 直接扔掉隔离舱

九、用 `notes.md` 演示分支操作（从创建到合并）

确保你在项目目录里：git-notes-demo。

1）看看你当前在哪个分支

git branch

会看到类似：

* main

星号表示你当前所在分支。

2）创建并切换到新分支（最常用）

我们模拟“AI 要大改文档结构”，先开个分支：

git switch -c feature/restructure-notes

解释一下：

switch = 切换分支
-c = create，创建并切换

再确认：

git branch

会看到星号在新分支上。

3）在分支里修改文件 + 小步提交

随便加几行（模拟 AI 大改）：

macOS / Linux：

echo "" >> notes.md
echo "## 结构调整" >> notes.md
echo "- 目标：让笔记更清晰" >> notes.md

Windows PowerShell：

"" | Out-File -Append -Encoding utf8 notes.md
"## 结构调整" | Out-File -Append -Encoding utf8 notes.md
"- 目标：让笔记更清晰" | Out-File -Append -Encoding utf8 notes.md

先看差异（这一步非常关键）：

git diff

确认没问题再提交：

git add notes.md
git commit -m "docs: restructure notes"

4）合并回 main（把成果带回主线）

切回主分支：

git switch main

把分支合并进来：

git merge feature/restructure-notes

此时 main 就拥有了你在分支上的改动。

5）删除分支（合并后清理）

git branch -d feature/restructure-notes

-d 是安全删除：如果你没合并，它会提示你，防止误删成果。

十、AI 写崩了怎么办？（分支的爽点来了）

这才是 vibe‑coding 用分支的最大价值：写崩了直接扔，不用救火。

场景：你在分支里让 AI 改了一大坨，发现方向完全不对。

你只需要：

回主线（回到安全区）
```
git switch main
```
把那个分支删掉（连人带车拖走）
```
git branch -D feature/restructure-notes
```

-D 是强制删除：适合“写崩了、确定不要了”的场景。

主线干干净净，心态也干干净净。

十一、合并冲突是啥？小白怎么处理？

你可能会遇到 merge conflict（合并冲突），意思是：

main 和分支都改了同一段内容，Git 不知道听谁的。

小白先记住处理原则：

打开冲突文件，找到这些标记：
```
<<<<<<<
=======
>>>>>>>
```
根据需要选择保留哪一段，或者把二者手动合成你想要的内容
改好后：
```
git add 冲突文件
git commit
```

冲突不可怕，可怕的是你不看 git diff 就直接 merge。

十二、认知底线：这些命令 AI 能替你敲，但后果你自己扛

在 vibe‑coding 场景里，你完全可以这么干：

“帮我开一个 feature 分支，改完后小步提交，最后合并回 main。”

Claude / GPT / Codex 都能很熟练地写出一长串 Git 命令，比你敲得快多了。

但问题是：

AI 会执行命令，而你要为结果负责。

典型翻车方式：

AI 来一句 reset --hard，你一周的改动没了（你还以为只是“撤销一下”）
AI 在 main 上直接改，改崩了你压根没隔离舱（你还以为它“会自己小心”）
AI 提交了一大坨改动，你不知道是哪一块引入了 bug（你还以为“能跑就行”）

所以，这里是 vibe‑coding 的底线：

你可以不了解框架细节，
但你一定要会用 Git，至少要搞懂：
diff / commit / branch / reset / revert 分别在改什么。

因为 Git 管的不是代码本身，Git 管的是你的后路。

你不需要死记硬背命令，但要清楚每个动作的意义：

diff：看 AI 到底改了什么（有没有越界）
commit：打存档点（可回退）
branch：隔离大改（可丢弃）
reset / revert：撤销错误（保命）

十三、速查表（建议直接收藏）

A. 基础流程（每天都用）

你要做的事	命令	它在干什么
初始化仓库	`git init`	把当前目录变成 Git 项目
看当前状态	`git status`	哪些文件改了 / 暂存了 / 没跟踪
看改了什么	`git diff`	具体改动内容（AI 是否越界）
准备提交	`git add 文件` / `git add .`	把改动放进“待提交包”
提交存档	`git commit -m "..."`	生成一个可回退的版本点
看提交历史	`git log --oneline`	查看提交记录（存档点列表）

B. 分支（AI 大改之前必做）

你要做的事	命令	它在干什么
查看分支列表	`git branch`	看当前有哪些分支、你在哪个上
创建并切到新分支	`git switch -c feature/xxx`	建隔离舱，避免污染 main
切回主分支	`git switch main`	回到安全线
合并分支到 main	`git merge feature/xxx`	把隔离舱成果带回主线
删除已合并的分支	`git branch -d feature/xxx`	安全清理分支
强制删除（写崩了）	`git branch -D feature/xxx`	直接扔掉隔离舱

C. 撤销与回退（救命按钮）

场景	命令	结果
`add` 之后反悔（不丢改动）	`git reset 文件`	取消暂存，改动还在
撤销最近一次 commit（保留改动）	`git reset --mixed HEAD~1`	commit 没了，文件还是改过的
撤销最近一次 commit + 丢弃改动（慎用）	`git reset --hard HEAD~1`	直接回到上一版本
丢弃当前未提交的改动（慎用）	`git reset --hard`	把工作区未提交的改动全扔掉
已经推到远端，又想撤销（更安全）	`git revert HEAD`	生成“反向提交”，不改历史，只把效果反掉

小白记一句话：

不确定就别用 --hard。
--hard 就是“删库级手滑按钮”。

D. vibe‑coding 标准动作（贴在屏幕边都行）

每次让 AI 动手前：

先开分支（建隔离舱）
```
git switch -c feature/xxx
```
AI 改完先看
```
git status
git diff
```
小步提交，多打存档
```
git add .
git commit -m "..."
```
确认没问题再合回主线
```
git switch main
git merge feature/xxx
```

写崩 / 不想要：回主线 + 删分支

git switch main
git branch -D feature/xxx

结尾：先保命，再提速

你完全可以让 AI 帮你敲 Git 命令，甚至帮你自动化整个流程。
但你必须清楚：每个命令正在对你的项目做什么。

AI 不会替你承担“改崩了”的后果。
Git，才是你在 AI 时代还能稳稳交付的底牌。

有了这套 Git + 分支的“刹车系统”，
我们才敢开始下一步：让 AI 帮你抄骨架、搭底盘，再谈提速。

vibe‑coding 九阳神功之夯：Git 基础操作，AI 时代的刹车系统（附速查表）

小白只看这里（10 分钟够用版）：你只需要会“看改动 + 打存档”

0）先确认：你在一个 Git 仓库里

1）AI 改完：先“看它改了啥”（最关键）

2）确认没问题：打一个“存档点”

3）要让 AI 干“大活”：先开分支（隔离舱）

4）小白底线：不确定就别用 --hard

小白词典（这篇里最常用的 6 个词）

为什么 vibe‑coding 必须先学 Git？

1）可回退：写崩了能救回来

2）可重置：不满意就撤销（包括撤销提交）

3）可查看：它到底改了什么，一眼看明白

二、安装 Git（Windows / macOS 小白版）

1）Windows 安装（推荐）

2）macOS 安装（两种方式，择一即可）

三、先做一个最基础配置（姓名 / 邮箱）

四、用一个 notes.md 贯穿：从 0 到会用 Git

0）创建项目并初始化 Git 仓库

1）创建 notes.md：Untracked（未跟踪）

2）把文件纳入 Git 管控：Staged（暂存）

3）提交（Commit）：给项目打一个“存档点”

4）修改文件：Modified（已修改未暂存）

5）再提交一次：小步提交

五、最小“救命操作”：撤销与回退（小白够用版）

1）撤销 add：不想把这个改动提交了

2）回退最近一次提交（保留改动）：常用

3）彻底丢弃改动（慎用）

六、vibe‑coding 的“手规”：记住这 4 步就够了

七、为什么 vibe‑coding 一定要用分支？

八、分支的核心概念（小白版）

九、用 notes.md 演示分支操作（从创建到合并）

1）看看你当前在哪个分支

2）创建并切换到新分支（最常用）

3）在分支里修改文件 + 小步提交

4）合并回 main（把成果带回主线）

5）删除分支（合并后清理）

十、AI 写崩了怎么办？（分支的爽点来了）

十一、合并冲突是啥？小白怎么处理？

十二、认知底线：这些命令 AI 能替你敲，但后果你自己扛

十三、速查表（建议直接收藏）

A. 基础流程（每天都用）

B. 分支（AI 大改之前必做）

C. 撤销与回退（救命按钮）

D. vibe‑coding 标准动作（贴在屏幕边都行）

结尾：先保命，再提速

4）小白底线：不确定就别用 `--hard`

四、用一个 `notes.md` 贯穿：从 0 到会用 Git

1）创建 `notes.md`：Untracked（未跟踪）

九、用 `notes.md` 演示分支操作（从创建到合并）