深色模式
2.4 给 AI 改代码备一颗后悔药：Git 极简认知
上一篇我们讲了校园内网里的门牌号：localhost 是自己访问自己，局域网 IP 才是同事访问你的地址。
到这一步，排座系统已经越来越像一个真正的校园 Web 项目了。
自己电脑能打开。
同事电脑也能访问。
数据还能保存。
听起来很美。
但新的风险也来了：你开始放心让 AI 继续改功能。
比如你对 Coding Agent 说：
text
请帮我给排座系统增加班级轮换功能。
支持七年级 1 班、2 班、3 班分别保存自己的座位表。
切换班级时自动加载对应座位。AI 很快动手。它可能同时改了前端页面、后端接口、数据库字段和若干配置文件。
结果新功能看起来加上了，旧的“保存座位表”却突然失灵。你想回到昨天那个还能用的版本，却发现自己根本不知道 AI 改了哪些文件。
这时候，你就需要给代码备一颗“后悔药”。
这颗后悔药叫 Git。
Git 不是程序员的神秘仪式
很多老师第一次听到 Git，会本能地觉得它离自己很远。
好像那是职业程序员、开源项目和大公司团队才会用的东西。
但在 Vibe Coding 里，Git 最先解决的不是团队协作问题，而是一个非常朴素的问题：
text
AI 改坏了，我能不能回到上一个能用的状态？如果没有 Git，你的项目就像一份不断被覆盖的 Word 文档。
每次 AI 修改，都是直接在原文件上改。改对了当然好，改错了就很难说清楚哪里变了。你可能只能靠记忆、聊天记录和肉眼对比一点点找。
有了 Git，项目就像可以随时存档的游戏。
每当你完成一个可用的小阶段，就保存一个存档点。后面即使 AI 把功能改坏，你也知道曾经有一个版本是能打开、能保存、能验收的。
一次提交就是一个存档点
Git 里有很多专业词，但这一篇只需要先认几个最小概念。
| 你可以这样理解 | Git 里的说法 | 对老师有什么用 |
|---|---|---|
| 这个项目被 Git 管起来了 | 仓库 / Repository | 项目开始有历史记录 |
| AI 改过哪些文件 | 改动 / Changes | 知道变化发生在哪里 |
| 保存一个可回到的节点 | 提交 / Commit | 留下一个项目存档点 |
| 过去每次存档的记录 | 历史 / History | 能看见项目怎么一步步变化 |
| 回到之前能用的状态 | 回退 / Restore / Revert | AI 改坏时有退路 |
你不需要现在就记住所有命令。
先抓住一个核心动作：提交不是写作文，而是给项目留下一个可回到的检查点。
比如排座系统可以这样存档：
- 页面能打开，提交一次。
- 座位阵列能显示，提交一次。
- 学生能放进座位，提交一次。
- 座位表能保存，提交一次。
- 刷新后数据还在，提交一次。
- 同事电脑能访问，提交一次。
这样做的好处是，项目每往前走一小步，都有一个安全落点。
不要等全部完成才提交
很多新手最容易犯的错误，是等项目全部做完才想到 Git。
这就像老师等整本教案写完、公开课上完、评课结束后，才第一次保存文档。
太晚了。
Git 最有价值的地方，恰恰在项目还没完全成型的时候。
因为 Vibe Coding 的开发过程通常不是一次写完，而是一轮一轮让 AI 修改：
text
先生成基础页面。
再补保存接口。
再加班级切换。
再优化座位颜色。
再处理重复占座。
再让同事访问。每一轮都可能成功，也都可能带来副作用。
所以更稳的节奏是：
text
小功能完成 -> 自己验收 -> 没问题 -> 提交一次不是“AI 写完就提交”，也不是“页面漂亮就提交”。
而是要等你确认这个小阶段真的可用，再把它存下来。
Git 特别适合保护 AI 修改
人自己写代码时，通常知道刚才改了哪里。
但 Coding Agent 不一样。
它很可能为了完成一个需求，同时动到很多地方。比如你只是让它“增加班级轮换”，它可能会：
- 修改前端班级选择框。
- 增加后端保存接口参数。
- 调整数据库里的座位表结构。
- 改动页面加载逻辑。
- 顺手整理某个工具函数。
这些改动未必错，但你需要看见它们。
Git 的价值就在这里：它能告诉你，项目和上一次存档相比，到底发生了什么变化。
你不一定要自己逐行读懂所有代码，但至少可以让 AI 帮你解释：
text
请根据当前 Git 改动，告诉我这次你改了哪些文件。
按“前端、后端、数据库、配置”分类说明。
只解释和本次需求有关的改动。
如果有超出需求的改动，请单独列出来。这比盲目信任 AI 要稳得多。
Git 和 GitHub 不是一回事
这里还要顺手拆一个常见误会。
Git 和 GitHub 不是一回事。
Git 是版本控制工具，负责记录你本地项目的改动历史。
GitHub、Gitee 这类平台，更像是把代码仓库放到网上或团队空间里的地方。
对这本小册来说，最开始你不需要急着研究远程仓库、开源协作和 Pull Request。
先把本机项目保护起来，就已经很有价值。
校园里的很多小工具，第一阶段只要做到：
text
本地项目有 Git 仓库。
每个可用小成果都有提交。
AI 大改之前先看状态。
AI 大改之后先看差异。
确认没问题再提交。这就够你避开很多坑。
可以这样要求 Coding Agent
以后你让 AI 修改项目时，可以加上几句保护性要求。
比如：
text
修改前，请先检查当前 Git 状态，并告诉我有没有未提交改动。
这次只实现“班级切换后加载对应座位表”。
不要顺手重构无关页面。
修改完成后，请列出改动文件，并说明每个文件为什么要改。
我验收通过后，再帮我提交。这段话的重点不是“显得专业”。
它是在给 AI 画边界。
你告诉它：先看现状，再动手；只做这次需求；做完要解释；验收后再提交。
这就是老师在 AI 时代很重要的一种能力：不是自己写每一行代码，而是会保护项目的稳定节奏。
想继续查，可以认这些词
这一篇先不讲 Git 命令。你只需要先认清这些词，后面实战篇会真正动手。
| 本文里的说法 | 专业技术名词 | 可以按需了解什么 |
|---|---|---|
| 项目被 Git 管起来 | Git 仓库 / Repository | 初始化仓库、项目历史 |
| AI 改过的内容 | 工作区改动 / Working Tree Changes | 哪些文件被新增、修改或删除 |
| 保存一个存档点 | 提交 / Commit | 提交信息、提交粒度 |
| 查看这次改了哪里 | 差异 / Diff | 修改前后对比 |
| 过去的存档记录 | 提交历史 / Commit History | 项目演变过程 |
| 回到之前能用的版本 | 回退 / Restore / Revert | 改坏后的恢复方式 |
| 把仓库放到平台上 | 远程仓库 / Remote Repository | GitHub、Gitee，后续可按需了解 |
先把后悔药放进工具箱
到这里，你不需要马上成为 Git 高手。
你只需要建立一个底线习惯：
text
凡是准备让 AI 大改项目，先确认有没有可回退的版本。
凡是完成一个可验收的小功能，就提交一次。这样，AI 就不再是一个让你紧张的“黑箱施工队”。
它可以大胆改，你也有办法看见改了什么、判断是否合适，并在必要时回到上一个稳定状态。
不过，代码有后悔药还不够。
校园 Web 项目真正进入使用现场时，还会遇到更现实的问题：学生数据放在哪里？谁能看，谁能改？页面能打开，算不算真的完成？
下一篇，我们继续补上数据、安全与验收的最小认知。
封面