6.1 为什么项目创建之后要立刻接上 Git

面向经管学生、研究者与从业者的 AI 智能体设计教材

6.1 配图

6.1 为什么项目创建之后要立刻接上 Git

Git 是变更边界

项目目录解决文件秩序，任务说明书解决规划秩序，而 Git 解决的是变更秩序。边界一旦缺失，后面的 Skill、子代理、Hooks 和评估都会失去落点。

在 AI 协作里，Git 至少承担四个角色：

角色	作用
记录	把改动从聊天过程转成可检查的版本节点
审阅	让人围绕 diff 和提交点做判断
回退	让试错可以收住，而不是越补越乱
交接	让后续会话、队友或未来的自己知道这一轮做过什么

如果只把 Git 当成最后顺手提交一下，这一章就会失去意义。对本书的工作流来说，Git 是项目推进中的基础设施。

为什么 AI 协作更早需要版本控制

传统手写流程中，一次只改一两个地方，还能勉强靠记忆维持边界。AI 介入后，常见情况会变成这样：

• 一轮会话同时改 4 到 8 个文件
• 模型顺手补注释、改标题、修格式、调整目录
• 你一边让它写内容，一边又让它跑检查和修补

速度提升本身没有问题，问题在于边界会更快消失。于是就会出现三种常见失控：

1. 当前目标和顺手修改混在一起，后面难以拆开。
2. diff 太大，只能整包粗看，人工审阅失效。
3. 出错时没有明确落点，只能靠聊天记录追溯。

Git 的作用，就是把这团正在发生的变化压缩成一组可比较、可回退、可交接的版本点。

先建立最小工作流

这一章先讲最常用、最值得立刻做起来的一条路径：

1. 初始化仓库
2. 看当前改动
3. 挑出本次提交范围
4. 提交到本地历史
5. 检查历史和回退点

只要这一条链先跑通，后面的分支、Worktree、PR、CI 才有稳定基础。

本章判断标准

学完这一章后，读者至少要能独立完成一次本地提交，并清楚知道：这一版改了什么、为什么提交、如果失败退到哪里。