vibe‑coding 九阳神功之:Git 基础操作,AI 时代的刹车系统(附速查表)

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

  • • 写得太快

  • • 改得太多

  • • 炸了没后路

  • • 炸完你甚至不知道它到底改了哪些文件

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

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

  • • :Git 生存技能(刹车 / 保险 / 录像)

  • • :拆解优秀项目的优秀骨架,搭底盘

  • • :会组合技术栈、会裁决,不懂原理也能不翻车

  • • :把 API 文档 / 资料结构化成可执行知识

  • • :让 AI 出计划 + tasks.md,按清单推进

  • • :多模型交叉验证,专治幻觉

  • • :Chrome MCP 自动测试,交付有证据

  • • :扩展认知边界,但必须可验证

  • • :上线交付、监控回滚、复盘闭环

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

本篇是这个系列的第一篇,希望你喜欢:)


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

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

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

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


为什么 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 安装(推荐)

  1. 1. 打开浏览器,搜索并进入 Git for Windows 官方下载页

  2. 2. 下载并双击安装包

  3. 3. 安装过程大部分选项保持默认即可,建议确认这一项:

  • • Use Git from the command line and also from 3rd-party software

  • 4. 安装完后打开 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 开始大改之前,按这个流程来:

    1. 1. 先看状态

      git status
    2. 2. 改完先看差异

      git diff
    3. 3. 小步提交

      git add .
      git commit -m "..."
    4. 4. 不对就撤

    • • 撤提交: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 改了一大坨,发现方向完全不对。

    你只需要:

    1. 1. 回主线(回到安全区)

      git switch main
    2. 2. 把那个分支删掉(连人带车拖走)

      git branch -D feature/restructure-notes

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

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


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

    你可能会遇到 merge conflict(合并冲突),意思是:

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

    小白先记住处理原则:

    1. 1. 打开冲突文件,找到这些标记:

      <<<<<<<
      =======
      >>>>>>>
    2. 2. 根据需要选择保留哪一段,或者把二者手动合成你想要的内容

    3. 3. 改好后:

      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 动手前:

    1. 1. 先开分支(建隔离舱)

      git switch -c feature/xxx
    2. 2. AI 改完先看

      git status
      git diff
    3. 3. 小步提交,多打存档

      git add .
      git commit -m "..."
    4. 4. 确认没问题再合回主线

      git switch main
      git merge feature/xxx
    5. 5. 写崩 / 不想要:回主线 + 删分支

      git switch main
      git branch -D feature/xxx

    结尾:先保命,再提速

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

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

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

Logo

汇聚全球AI编程工具,助力开发者即刻编程。

更多推荐