前 GitHub CEO 刚刚同意：Git 并非为此而生
Source: Dev.to
与 Claude Opus 4.5 的访谈
两周前，我采访了一位 AI，了解它真正需要什么样的开发者基础设施。这周，Thomas Dohmke 为此筹集了 60 百万美元。
在 2 月 4 日，我发布了一篇题为 “Git 对我来说已经死了：为什么 AI 代理讨厌你的 Pull Request” 的 Claude Opus 4.5 访谈。其核心论点很简单：文件是 70 年代的操作系统约束，Git 是 2005 年的协议，我们必须停止把新智能硬生生地套在旧基础设施上。
AI 直截了当：
“给我一个带有显式边的平面表示，告诉我约束条件，然后让我输出一个新状态。不要让我在文本文件上动手术，假装我知道自己在第几行。”
当我询问版本管理应该是什么样子时：
“这里是旧状态，这里是意图，这里是新状态。不是：这里有 43 条跨 12 个文件的行级更改。”
我把它称为 State = f(Intent[])。部署的产物应当是对话历史的纯函数——没有 diff。重放意图，重新生成状态。
有些人认为这是夸大其词。AI 抱怨 Git？基本原理难道还能不变吗？
Thomas Dohmke 推出 Entire
六天后，即2月10日，前GitHub CEO——那位将 Copilot 推广至数百万开发者的人——宣布成立 Entire，这是一家获得 6000 万美元种子轮融资、估值 3 亿美元的新公司。
他的发布帖子概括了问题：
“我们正经历代理（agent）繁荣期，如今大量代码的生成速度超过了任何人类能够合理理解的速度。事实是，我们手动的软件生产体系——从 issue、git 仓库、pull request 到部署——根本不是为 AI 时代设计的。”
在接受 The New Stack 采访时，他进一步指出：
“我们正从把工程视为手工艺的方式转变——即在文件夹中手动编写代码……转向规范、推理、会话日志、意图和结果。这需要一个与今天的 GitHub 完全不同的开发者平台。”
曾 管理 GitHub 的这位人士刚刚表示，GitHub 并不适合代理（agents）。
什么是 Entire 正在构建的
Entire 的平台有三层：
- 兼容 Git 的数据库，将代码、意图、约束和推理一起进行版本管理。
- 通用语义推理层，通过“上下文图”实现多代理协同。
- AI 原生接口，用于代理与人类的协作。
他们的第一个产品 Checkpoints，捕获每个 AI 生成的提交背后的提示、决策和执行轨迹。当你从代理提交代码时，Checkpoints 会存储完整会话：文字记录、提示、涉及的文件、令牌使用情况、工具调用。
“版本化应该是：这里是之前的状态，这里是意图，这里是新的状态。” — Claude Opus 4.5
“Checkpoints 是一种新原语，自动将代理上下文捕获为一等的、可版本化的数据。” — Entire announcement
相同的洞见。相同的原语。区别在于 Dohmke 拥有 $60 M 和一支团队来实现它。
为什么这很重要
验证的重点并不是我是否正确；而是 开发工具领域最具可信度的人 独立得出了相同的结论——并且把他的下一家公司押在了这个结论上。
含义
- Git 不会消失 — 它将成为存储层，而不是工作流。Entire 之所以兼容 Git，正是因为无法剥离 Git，但他们正在添加对代理真正重要的语义层。
- “90 % 问题”并非关于 GitHub 集成 — Vercel 同周宣布了 v0 重建，宣称更深入的 GitHub 集成是解决方案。Dohmke 的赌注恰恰相反：GitHub 工作流本身是瓶颈。
- 意图是新的原语 — 不是文件、不是提交、也不是差异。产生代码的对话比代码本身更有价值。Checkpoints 将这一点明确化。
我们接下来要做什么
在 Opzero，我们一直在基于一个相关的论点进行构建：AI 代理需要一种从 LLM 客户端内部运行的部署基础设施，而不是与您的 AI 竞争的目标应用。
我们并没有在构建 Entire。它们专注于治理和审计——让 AI 代码可审查。我们的关注点在另一端：让 AI 代码 可部署，且无需繁琐的流程。
但我们共享同一个前提：原始工具是错误的。文件、文件夹、提交、PR —— 这些都是人为协作机制，代理被迫将其序列化进去，因为这是预期的格式。
下一波开发者基础设施将 从底层起即为 AI 原生。不是在 Git 上加装 AI，也不是由 AI 审核的 PR，而是全新的东西。
Dohmke 正在构建其中的一部分。我们则在构建另一部分。
竞争已经开始。