1700万美元押注：下一代版本控制工具，Google和Mozilla已经在用了

上个月，Chris Wanstrath 拿到了 1700 万美元融资。

你可能在想，又是个什么 AI 创业项目？

不是。他在做一个版本控制工具，叫 jj（jujutsu，柔道）。

Chris Wanstrath 是 GitHub 的联合创始人。2008 年，他和另外三个程序员在旧金山租了间公寓，写出了 GitHub。十六年后，他重新回到代码编辑器前，开始写 jj。

这事儿本身就挺耐人寻味的——一个已经改变了全世界程序员工作方式的人，为什么要重新发明轮子？

答案藏在一句话里：jj 不是要干掉 Git，而是 Git 本该成为的样子。

程序员和 Git 的恩怨情仇

先承认一个事实：Git 很强。

它撑起了整个开源世界的协作，Linux 内核、Android、Chrome、Kubernetes，全跑在 Git 上。Linus Torvalds 当年用两周时间写出来的东西，统治了十五年。

但 Git 也很烦。

你有没有过这种经历：改了十几个文件，突然发现只想提交其中三个。于是你开始 git add -p，手动选择每个代码块。选到一半，脑子乱了。算了，干脆 git stash，重新来过。

或者这种：pull 代码，冲突了。整个工作流卡住。你得打开冲突文件，看 <<<< 和 >>>>，手动合。合着合着，心态崩了。

还有这种：提交了，推送了，发现错了。想撤回，但已经有人 pull 了。现在你得 git revert，祈祷别搞出更多混乱。

这些场景，每个程序员都经历过。Git 的设计逻辑是"先复杂，后灵活"，但大多数时候，我们只想简单点。

Chris Wanstrath 显然也有这种感觉。

jj 想解决的问题

jj 的理念听起来有点激进去：工作区即提交。

在 Git 里，你编辑代码，然后 git add 暂存，然后 git commit 提交。三步走。

在 jj 里，你编辑代码，就已经在提交了。每一个改动，自动成为一个"变更集"（change）。你不用管暂存区，不用管 staged/unstaged 的区别。

听起来危险？其实不然。jj 的每个操作都有完整的历史记录。你可以随时 jj undo 撤回任何一步。甚至可以在推送之后撤回——jj 会处理好同步的问题。

这意味着什么？你可以在任何时候尝试任何东西。错了？撤回就是。不用像 Git 那样，先备份分支，再小心翼翼地操作。

第二个理念：冲突不阻断工作流。

在 Git 里，冲突意味着你必须停下来，解决冲突，才能继续。

在 jj 里，冲突只是一个状态标记。你可以继续工作，继续提交，稍后再回来解决。多人可以同时编辑同一块代码，系统不会把你卡死。

这听起来像是个小改进，但对于大型团队协作来说，这是质变。

第三个理念：没有分支，只有变更集。

Git 的分支模型很强大，但也很容易搞乱。你创建了 feature-login，同事创建了 feature-login-v2，合并的时候，名字都分不清了。

jj 用"变更集"取代了分支。每个变更集有唯一 ID，可以相互依赖，可以随意重构依赖关系。你不用脑子记"这个分支是从哪个分支拉出来的"，系统替你记着。

Google 和 Mozilla 已经在用了

这些理念听起来不错，但真的能落地吗？

答案是：已经在落地了。

Google 正在全面替换内部的旧版代码协作工具。Piper 和 CitC，这两套 Google 用了多年的系统，正在对接 jj。Google 的工程师团队规模是万级的，能做出这个决策，说明 jj 不是玩具。

Mozilla Firefox 的仓库是 5.5GB，上万个分支。核心工程师已经在重度使用 jj 管理这个庞然大物。如果 jj 能搞定 Firefox 的复杂度，大多数项目都不在话下。

还有一个有意思的生态位：Gerrit。

Gerrit 是 Android AOSP 和 Chromium 用的代码审查系统。它天然契合 jj 的设计——提交-审查-合并的工作流，和 jj 的变更集模型几乎是对应关系。

为什么 AI 时代需要 jj

这是我最感兴趣的部分。

Chris Wanstrath 在融资公告里提到一句话：jj 是 AI 智能体的"因果记忆库"。

什么意思？

在 Git 里，提交历史是一串快照。你改了什么，Git 记录下来。但它不记录"为什么改"。

在 jj 里，每一个操作都有完整的因果链。你可以追溯到：这个变更集是基于哪个变更集，是为了解决什么冲突，经过了哪些审查。

对于人类来说，这可能只是"更清晰的历史"。但对于 AI 来说，这是可推理的上下文。

想象一个 AI 编程助手。它需要理解你的代码库，帮你做重构，帮你解决冲突。在 Git 里，它只能看到结果——一堆 diff。在 jj 里，它能看到整个决策过程——你为什么这样改，当时遇到了什么问题，是怎么解决的。

这种"因果记忆"，是 AI 智能体高效工作的前提。

Chris Wanstrath 押注的就是这个方向：未来的代码协作，不只是人跟人，还有 AI 跟 AI，人跟 AI。jj 的设计，天然适合这个场景。

现实点说，它还有短板

说了这么多好话，也得诚实面对现实。

jj 还在早期。部分命令的性能还在追赶 Git，尤其是 git blame 这种高频操作。GUI 和 IDE 集成还在起步阶段——VS Code、JetBrains 都还没有官方插件。如果你想用 jj，得接受在终端里敲命令。

另一个问题：学习成本。

jj 的理念和 Git 不太一样。你得"忘记"Git 的肌肉记忆，重新建立直觉。这需要时间。

我的建议是：别急着在生产环境迁移。在个人项目或小团队里试试，感受一下工作流的差异。等到工具链成熟了，再考虑大迁移。