GitHub前创始人拿了a16z的1700万美元，做Agent时代的Git

你有没有想过，编程这件事情可能彻底变了？开发者正在从单纯使用AI工具，转向将AI视为构建软件的全新基础。这不是什么小调整，而是一场彻底的范式转变。想想看，那些我们一直习以为常的核心概念——版本控制、分支、代码审查，甚至"协作"的定义——都在因为AI agent驱动的工作流而被重新定义。更让我震惊的是，我们每天都在用的Git，其实是一个为20年前的邮件列表补丁工作流设计的工具，现在却要服务于人类开发者和一群AI agent同时工作的场景。

这就是为什么GitButler刚刚获得1700万美元A轮融资的消息让我停下来认真思考。这轮融资由a16z领投，Fly Ventures和A Capital继续跟进。更有意思的是，GitButler的CEO Scott Chacon是GitHub的联合创始人之一，他写过那本几乎每个开发者都读过的《Pro Git》。一个已经在版本控制领域取得巨大成功的人，为什么要回到创业赛道，重新思考这个看似已经"解决"的问题？他在公告中说得很直白："我们不是在构建一个'更好的Git'，我们是在构建软件构建方式的下一代基础设施。"这句话背后隐藏着对软件开发未来的深刻洞察。

PS：我的出海新书已经上架了，我特意申请了公众号读者专属的优惠链接，可以享受半价折扣，欢迎感兴趣的朋友购买。

同时我还特地建立了实名制的读者群，我会在群里定期解答一些问题和开展线上线下活动，欢迎购书的朋友实名制入群，大家一块交流，共同出海！

Git的20年困局：为邮件列表设计的工具

我发现很多人并不了解Git的历史背景。Git最初是Linux内核团队在2005年创建的，它的设计哲学深深植根于Unix传统。Scott在访谈中提到了一个有趣的细节：Git的核心团队从来没打算做一个用户友好的界面。他们遵循Unix哲学，构建了一系列底层的"管道命令"，每个命令做一件简单的事情，然后你可以用Perl脚本把它们串起来，做任何你想做的事情。这种设计思想在当时非常合理，因为他们假设只有Linux核心团队这样的技术专家会使用这个工具。

后来发生的事情大家都知道了。有个叫Pasquy的开发者写了一些Perl脚本，给Git包装了一个统一的用户界面，也就是我们现在用的CLI命令。这些脚本变得越来越流行，最终被合并到Git核心中，成为了所谓的"瓷器层"（porcelain）。有意思的是，这些命令从2005、2006年以来基本没有大的变化。它们最初是用Perl写的，后来被重写成C，但核心逻辑和用户界面几乎保持原样。Scott说他在2009年写《Pro Git》第一版时描述的那些命令，现在依然可以完全照搬使用。

这种稳定性在某种程度上是好事。Git团队非常重视向后兼容性，他们不愿意移除任何已存在的功能，担心会破坏现有工作流。但这也带来了一个根本问题：Git被设计时的核心假设，已经跟现在的软件开发实践严重脱节了。Git是为了通过邮件列表发送补丁而设计的。那个时代，开发者会在本地做一些修改，生成一个补丁文件，通过邮件发送给维护者，维护者审查后决定是否接受。整个流程是异步的、基于文本的、单线程的。

而现在呢？我们有持续集成、持续部署，有分布式团队实时协作，有代码审查工具，有各种自动化测试和部署流水线。更重要的是，现在有AI agent在大规模地写代码。Scott提到一个让我印象深刻的观察：我们现在正在教一群AI agent使用一个为邮件列表补丁设计的工具。这种错位感，就像是让一辆特斯拉走在为马车设计的道路上。

Git的Unix哲学设计带来了另一个问题：它试图用一套接口同时服务计算机和人类。如果你运行"git branch"，默认情况下你只会得到一个分支列表，没有任何用户界面。这是因为Git需要确保这个命令的输出既可以被人类阅读，也可以被其他程序解析。这种妥协导致了一个结果：Git对人类来说不够友好，对计算机程序来说也不够优化。虽然有些命令提供了"--porcelain"选项来输出机器可读的格式，但这不是标准做法，很多命令根本没有这个选项。

AI Agent时代的新挑战：一个工作目录已经不够用了

当AI开始大规模参与编程时，Git的局限性变得更加明显。我自己最近也在尝试使用多个AI agent同时工作，发现Git的基本设计假设——一个开发者、一个分支、一个线性工作流——已经完全不适用了。现代开发者不是线性工作的。你可能同时运行多个agent，一个在修复UI bug，另一个在优化数据库查询，第三个在更新文档。但Git的索引系统在这种并行编辑下会崩溃，因为它假设你本地的工作副本代表的是对代码库的单一、原子性的修改。

传统的解决方案是使用worktree，也就是为每个并行任务创建代码库的多个副本。但这带来了新问题。如果你有五个agent同时工作，你就需要五个完整的工作目录副本。虽然Git在存储层面做了优化，但这仍然意味着大量的文件复制和磁盘空间占用。更重要的是，这些agent之间是完全隔离的，它们看不到彼此在做什么，直到它们各自完成并尝试合并时才会发现冲突。到那时候，解决冲突的成本已经非常高了。

GitButler提出的解决方案是并行分支（parallel branches）。这是一个让我眼前一亮的设计。并行分支就像普通分支，但你可以同时打开多个。你可以获得worktree的好处（逻辑隔离），但不需要复制所有文件。所有的agent都在同一个工作目录中操作，但它们的修改被分配到不同的虚拟分支中。Scott在访谈中描述了一个让我印象深刻的场景：他们让两个agent同时工作，这两个agent都想编辑同一个文件，但修改方式不兼容。结果是什么？一个agent自动把它的分支堆叠在另一个agent的分支之上，然后继续工作，提交到它自己的堆叠部分。这种智能的冲突处理，在传统Git工作流中几乎不可能实现。

我特别欣赏GitButler团队的一个实验，虽然最终他们没有采用。他们曾经尝试让多个agent之间有一个聊天频道，让它们可以互相沟通正在做什么。Scott说这个功能看起来超级酷，他们可以看到agent之间的对话，非常想把它发布出去。但经过大量测试后，他们发现这个功能其实没有帮助。Agent会自己发现有其他人在修改某个文件，会自动推断原因，然后调整自己的工作策略。它们不需要显式的通信，因为通信本身带来了开销，反而让整个过程变慢了。这个发现本身就很有启发性：我们不能简单地把人类的协作模式套用到agent身上，agent有自己的工作方式。

重新设计用户界面：为人类、为agent、为脚本

GitButler最近发布的CLI工具引起了我很大的兴趣。这不是一个简单的Git包装器，而是从根本上重新思考了命令行工具应该如何设计。Scott提到了一个有趣的观察：大约80%的开发者仍然使用命令行工具来操作Git，即使有各种GUI工具存在。原因很简单——大多数Git GUI只是把Git命令包装了一层图形界面，并没有增加太多功能，反而让操作变慢了。如果你知道要运行什么命令，直接敲命令往往更快。

但GitButler的CLI不一样。它针对不同的使用场景提供了不同的输出格式。如果你直接运行命令，它会给你优化过的、人类可读的输出，包括提示和建议。如果你加上"--json"参数，它会给你结构化的JSON数据，方便脚本解析。他们甚至在考虑添加"--markdown"选项，专门为agent优化输出格式，因为markdown格式更容易被注入到agent的上下文中。

更有意思的是，他们通过实际观察agent的行为来优化工具设计。他们发现，虽然提供了"--json"选项，但agent其实更喜欢使用人类可读的输出，然后自己通过管道传给jq或写Python脚本来提取需要的信息。另一个发现是，agent在运行任何修改性命令后，几乎总是会立即运行"git status"查看状态。所以GitButler团队直接在所有修改性命令中添加了"--status-after"选项，执行完操作后自动显示状态。这种设计在传统Unix哲学中是不会做的，对脚本编程也不太适合，但对agent来说却是完美的。

他们还在探索如何通过输出给agent提供更多上下文信息。比如，在命令输出中包含"如果你想做这个，运行这个命令"的提示。这不是给人类看的，因为人类会觉得啰嗦，但对agent来说，这种额外的上下文可以帮助它更快地决定下一步该做什么。Scott说这是一个非常有趣的UX问题，因为我们必须把agent当作一种新的"用户画像"来对待，而它的需求和行为模式跟人类完全不同。

软件开发的本质变化：从写代码到写规格说明

在访谈中，Scott提到了一个让我深思的观点：未来最优秀的软件工程师，可能不是那些代码写得最好的人，而是那些最会沟通、最会写作、最会描述的人。这听起来可能有点反直觉，毕竟我们很多人当初选择编程就是因为可以跟机器打交道，而不是跟人打交道。但仔细想想，这个趋势是完全合理的。

当AI agent可以高效地生成代码时，瓶颈不再是实现细节，而是你能不能清楚地描述你想要什么。Scott分享了他自己的工作流程：他现在大部分时间都在写规格说明，详细描述一个功能应该如何工作。每当有一个设计决策需要做时，他就让AI根据规格说明实现，然后测试结果。如果有问题，他就回去修改规格说明，告诉AI重新实现。这个循环可以非常快速地进行，因为他不需要自己手写所有的实现代码。

这种工作方式的美妙之处在于，你可以随时做"展示和讨论"（show and tell）。传统上，如果你想验证一个想法，你需要写一个详细的技术文档，然后说服团队成员阅读并提供反馈。但文档再详细，也不如一个可以运行的原型直观。现在，你可以快速生成一个原型，让团队成员实际体验，然后基于反馈迅速迭代。这大大加快了从想法到验证的周期。

但这也带来了新的挑战。团队协作的瓶颈从"能不能实现这个功能"变成了"我们能不能就想要什么达成共识"。Scott说，很多开发者，特别是那些自认为很聪明的开发者，觉得他们不需要解释自己在做什么，代码本身就是最好的文档。但在AI时代，这种态度行不通了。你必须能够清晰地表达你的意图，能够写出让团队成员和AI都能理解的规格说明。写作能力，成为了新的超级能力。

这让我想到代码审查的未来。Scott提出了一个尖锐的问题：如果你诚实地问大多数软件工程师，在做代码审查时，你真的会仔细读完整个PR吗？会逐行思考逻辑吗？会把代码拉到本地测试吗？还是只是粗略浏览一下，确认看起来没有明显问题，然后就批准了？大多数人会选择后者。这不是因为开发者不负责任，而是因为彻底的代码审查成本太高，而收益往往不够明显。

AI agent在这方面可能会改变游戏规则。Agent非常擅长仔细审查每一行代码，运行测试，检查潜在问题。它们不会累，不会厌烦，可以保持一致的审查标准。这样，人类审查者就可以专注于高层次的问题：这个改动是否符合产品方向？是否解决了用户的真实需求？架构设计是否合理？而具体的实现细节、语法问题、潜在bug，可以交给AI来检查。

PR和Issue：20年没变的协作模式该进化了

GitHub的Pull Request机制已经成为开源协作的标准模式，但Scott认为这个模式存在根本性问题。PR是基于分支的审查，不是基于补丁的审查。这导致了大量的"提交垃圾"——那些"哎呀，修复了一个小bug"、"忘记添加这个文件了"之类的提交信息。因为在PR模式下，重要的是整个分支，而不是单个提交。所以没人真正关心提交信息的质量，PR描述才是关键，而PR描述并不存储在Git历史中，合并后通常就丢失了。

在邮件列表时代，这不是问题。每个补丁都有一个精心编写的提交信息，因为那就是你的PR描述。审查是基于补丁的，补丁的质量和提交信息的质量直接相关。但在GitHub时代，我们失去了这种约束。Scott认为，未来的代码审查应该回归到基于补丁的模式，但要结合现代工具的优势。审查应该是本地的，你可以实际运行代码、测试功能。Agent可以帮你运行各种测试，标记潜在问题，你只需要关注那些真正需要人类判断的部分。

还有一个有趣的观点是关于团队间沟通的。Scott说，软件开发中一直做得不好的事情是团队间的实时沟通。如果你在修改某个文件，我也在修改同一个文件，我们通常要到最后合并时才会发现冲突，然后其中一个人要承担100%的合并工作。但如果我们能够实时知道对方在做什么呢？对人类来说，这种实时沟通的开销可能太大，会打断工作流程。但对agent来说，这不是问题。Agent可以用它们的空闲时间互相沟通，了解团队中其他人（或其他agent）在做什么，提前发现潜在冲突，或者主动调整工作策略避免冲突。

GitButler正在探索的元数据系统也很有意思。他们想要能够把对话记录、agent的思考过程、相关的上下文信息附加到提交或分支上。Git目前对这种元数据的支持非常有限。这些信息可能非常有价值，可以帮助理解为什么做出某个决策，代码背后的思考过程是什么。但这也带来了一个大数据问题。Scott提到，即使只是保存文本，这些元数据的规模也会快速膨胀。他们不得不利用Git中一些大型仓库（如Chrome或Microsoft Office团队使用的）的技术，来处理这种规模的数据。

我对这场变革的思考

看完GitButler的故事和Scott的访谈，我有一些深刻的感受。软件开发正在经历一场根本性的范式转变，而版本控制系统作为软件开发的基础设施，必须随之演进。Git的设计理念在20年前是先进的，但现在已经成为限制。我们需要的不是"更好的Git"，而是为现代工作流和AI时代重新设计的基础设施。

让我特别有共鸣的是Scott关于"逻辑终点"的思考。他说，在做语言学习创业时，很多人看到实时翻译技术就说语言学习已死。但他反驳说，即使有完美的翻译器，双方都需要戴着翻译器，而且这种沟通体验远不如直接用同一种语言交流。他曾经在日本带着翻译工作了一周，翻译很优秀，但这种体验仍然不好，你不会想用这种方式建立深度关系或开展复杂合作。对于编程也是一样。AI agent变得再强大，它们也不能完全替代人类的判断、创造力和沟通能力。

关于GitHub的未来，我觉得Scott的观点很中肯。GitHub最大的优势是用户基数，最大的劣势是作为大公司很难快速转向。现在整个行业都在探索什么是"下一个GitHub"，但Scott指出，这个问题本身可能问错了。GitHub本身就不是任何东西的"下一个"，它创造了一种全新的协作模式。同样，未来可能会出现一种完全不同的、我们现在还想象不到的协作模式。

我认为GitButler的价值不仅在于它提供的具体功能，更在于它代表的思考方式。他们在质疑那些我们习以为常的假设：为什么一次只能在一个分支上工作？为什么提交必须是线性的？为什么agent和人类要使用同样的界面？为什么协作必须通过PR和issue进行？这种从第一性原理出发的思考，正是我们在这个快速变化的时代最需要的。

我也意识到，作为开发者，我们需要培养新的技能。写清晰的规格说明、有效地沟通想法、理解AI agent的工作方式——这些可能比单纯的编码能力更重要。这对很多开发者来说可能是个挑战，特别是那些选择编程就是为了避免跟人打交道的人。但这也是一个机会，让我们从低层次的实现细节中解放出来，专注于更有创造性的工作：定义问题、设计解决方案、做出权衡决策。

GitButler的1700万美元融资只是一个开始。我相信未来几年，我们会看到更多重新思考软件开发基础设施的尝试。版本控制、代码审查、项目管理、测试、部署——这些工具都是在AI之前的时代设计的，都需要重新审视。那些能够率先适应新范式的开发者和团队，将在这场变革中获得巨大优势。

最终，软件开发会变成一个更加关注沟通、协作和决策的工作，而不是关注语法和实现细节。这听起来可能让一些传统程序员不安，但我认为这是一件好事。它让编程变得更加接近解决问题的本质，而不是被技术细节所困扰。当我们不再需要记住复杂的Git命令，不再需要手动解决合并冲突，不再需要花大量时间写重复性代码时，我们就可以把精力投入到真正重要的事情上：理解用户需求、设计优雅的解决方案、创造有价值的产品。这才是软件开发的核心，也是GitButler试图帮助我们回归的方向。