EP25 · 为什么所有 AI 编程工具的第一步,都是先装 Git

楔子：奇怪的共同点

不管你用的是 Claude Code、OpenClaw、GitHub Copilot，还是这里正在运行的 Hermes Agent——装它们之前，系统都会提示你：先装 Git。

没有例外。

这不是巧合。背后藏着一个看似简单、但很少有人说清楚的问题：

Git 到底给 AI 编程工具提供了什么？

1. Git 是 AI 输出结果的"落笔机制"

AI 生成代码，最难的事不是"写出来"，而是"写进去"。

你让 AI 写了一段 300 行的函数，它跑通了、看起来没问题——然后呢？这段代码存在哪里？怎么交给别人？怎么确保它不会被下次对话覆盖？

没有 Git 的 AI，输出只能停留在"屏幕上的文字"。

git commit 做了一件极其精确的事：把变更变成一个不可变的快照单元。AI 每完成一个功能模块，一次 commit；这个 commit 不会消失，不会被覆盖，不会因为上下文窗口用尽而被遗忘。

没有 commit，就没有"落笔"。

AI 生成的内容永远悬在空中，这是 Agent 工作流的第一个缺口。

人类程序员开分支，通常是因为需要并发开发。

但对 AI Agent 来说，分支的真正意义完全不同——它是一个可以随便写、随便试、不会被追责的空间。

开一个 agent/experiment-1 分支，AI 可以放心地重构、删改、写烂代码，不用担心破坏主分支的稳定。实验完了，结果好，merge；结果差，删掉分支重来。

没有分支的 AI，只剩两条路：要么直接在主分支上改（危险），要么把每次实验结果存成文件（混乱）。

分支给了 AI 一张干净的草稿纸，用完可以扔，不影响正式稿。

代码被 AI 改坏了，是常见的事。

Prompt 理解偏了一点，AI 在一个关键文件里写了一个微妙的 bug——这种错误用肉眼看不出来，但运行时才会爆炸。

Git 的价值在这里体现得最清楚：任何一个 commit，都是一个可完整回退的版本。

git checkout <hash> → AI 立刻回到上一个稳定状态，不需要手动恢复文件，不需要靠"记忆"去猜测哪里出了问题。

上下文窗口不够大、文档不完整、代码太旧——这些问题在 Git 的历史记录面前都不存在。项目历史上每一个状态，都被精确记录在案。

这是比"给 AI 加内存"更可靠的记忆方案。

一个人类程序员和一个 AI Agent 协作，边界怎么划？

答案是：PR（Pull Request）和 merge。

AI 在分支上完成任务，发起 PR；人类 review，决定是否合并。这是人类给 AI 划定的唯一合法出口——AI 不能绕过 PR 直接 push 到 main。

这个流程不是限制，是保护。

它确保 AI 的输出必须经过人类审批才能进入正式代码库。对 AI 来说，这是外部约束；对人类来说，这是安全边界。

Git 的 commit、branch、PR、review、merge——这套语言定义了"人和 AI 怎么共同维护一个项目"。

现在已经在发生的事情：

工程师们开始注意到，有些 commit 的 message 写着 Claude Code: refactor authentication 或者 Agent: summarize PR #412。

GitHub 的 commit 历史里，开始出现 AI 的"签名"。

这带来一个值得思考的问题：当 AI 可以在 commit 历史里留下自己的思维路径，commit message 作为"人类意图记录"的权威性，还能维持多久？

人类写的 commit message 是意图记录，AI 写的 commit message 是执行记录。

两者混在一起，项目历史正在变成人机混合书写的文本。

2005 年，Linus Torvalds 设计 Git，是为了解决分布式代码协作问题。

二十年过去，Git 成为几乎所有 AI 编程工具的底层依赖，不是因为它有多 AI，而是因为它提供了一套最小完备的代码管理协议：

原子写入、历史快照、实验空间、人类协作边界。

这些能力，恰好是 AI Agent 在编程任务中最需要的。

Git 不是为 AI 设计的。

但它是目前 AI 编程工具能够正常工作的那块地基。

AI钳能觉醒｜日期：2026-05-18｜地点：杭州