AI 帮我写好代码,原好的功能却崩了:Vibe Coding 时代的必修课

这两年随着 AI 编程工具爆火，身边越来越多完全没写过代码的朋友，开始自己手搓小工具、做自动化流程、甚至搭建属于自己的独立网站。

这种“只要会说话就能做出产品”的 Vibe Coding 体验确实很爽，但很多人自学到一定阶段，就会撞上同一面墙：

你叫 AI 帮你在原有的工具上加一个新功能，它代码写得飞快，加完你一跑，发现原来好好的地方居然被它改坏了。

最折磨人的是，你想让它退回到昨天那个还能正常跑的版本，却发现根本找不到昨天的版本在哪。你只能一遍遍叫它“改回去”，改到最后，连你自己都不确定现在屏幕上这一版到底是第几种尝试。

如果运气好没出问题，你又会碰到第二个尴尬：做出来的东西全在自己电脑里，想找朋友帮忙看一眼，只能把整个文件夹打包压缩发送过去。

这些让新手抓狂的破事，其实写程式的人早就被烦了几十年。而最终收敛出来用来解决这个问题的终极工具，叫 Git。

不怕改坏的秘诀：把每次提交变成你的物理存档点

很多人容易把 Git 和 GitHub 混为一谈。

其实 Git 就像跑在你本地电脑里的记账本，负责把你每一次对代码的改动记录下来——谁在什么时候把哪几行改成了什么。有了这本账，你可以随时回到任何一个时间点，或者直接把档案恢复到那个正常运行的状态。

而 GitHub，则是一个让你把这本本地账本连同项目文件，一起推送到云端保存的网站。

在 Git 的逻辑里，最重要的一个动作叫 Commit（提交）。与其翻译成复杂的术语，不如把它想成“盖章”。

这是你自己挑选的时间点，跟账本说：“这一版我测试过了，它是能跑通的，帮我盖个章记下来。”你每盖一次章，在未来遇到突发状况时就多了一条随时能退回的退路。

尤其现在让 AI 帮我们写代码，它一次动的东西比手工写的要多得多，更需要建立极其密集的存档点。哪怕一天 Commit 几十次都没关系，因为这件事本身在本地是没有额外成本的。

给 AI 开一条独立通道，试错成本直接归零

当你需要让 AI 去改动一个核心结构或者做大调整时，最聪明的方式不是直接让它在主线上乱动，而是开一个 Branch（分支）。

分支白话来说，就是在主线之外插出一条平行宇宙。

你在分支上把整个项目拆掉重写，主线都完全不知情，也不会被影响。让 AI 在分支上大胆尝试，如果试完发现不行，你只需要把这条分支整条扔掉，主线依然干净如初。

当 AI 在分支上搞定且确认无误后，你再把成果合并（Merge）回主线。这样一来，叫 AI 动大功能从“一把输赢的赌博”，直接变成了“零成本的实验”。

如果是在线上合作或者让独立的 Coding Agent 帮你在后台干活，最标准的安全防线叫 PR（Pull Request）。

它相当于 AI 办好事情后向你提交一张单子：“我改好了，申请合并进主线。”

在 PR 的审核界面上，代码改动会用最清晰的 绿字（新增） 和 红字（删减） 标示出来。你不需要懂几千行复杂逻辑，只需要扫一眼绿字是不是你预期的那些，红字有没有被 AI 顺手拿掉不该动的东西。

看懂了这些，你才算真正拿到了给 AI 当老板的指挥权。

💡 桌面工具备查福利

第一次接触命令行和版本控制，难免记不住那些容易敲错的指令。

我整理了一份 《Vibe Coding 必备 Git & GitHub 指令速查手册 PDF》，里面把今天聊到的 git init、git status、git commit、git checkout -b 等核心操作打包成了单页速查图表，支持放在桌面随时查阅避坑。

在公众号后台私信回复 “网盘”，即可直接获取下载链接。

聊聊你的看法

你在用 AI 帮自己写代码、做自动化工具或搭网站的时候，有没有遇到过“本以为加个小功能，结果 AI 顺手把原本好的功能改坏”的崩溃瞬间？

你当时是怎么拯救那个项目的？欢迎在评论区分享你的踩坑经历，我们一起探讨更优雅的自动化交付方式！