撰文：Leo
你有没有想过，编程这件事情可能彻底变了？开发者正在从单纯使用 AI 工具，转向将 AI 视为构建软件的全新基础。这不是什么小调整，而是一场彻底的范式转变。想想看，那些我们一直习以为常的核心概念——版本控制、分支、代码审查，甚至"协作"的定义——都在因为 AI agent 驱动的工作流而被重新定义。更让我震惊的是，我们每天都在用的 Git，其实是一个为 20 年前的邮件列表补丁工作流设计的工具，现在却要服务于人类开发者和一群 AI agent 同时工作的场景。
这就是为什么 GitButler 刚刚获得 1700 万美元 A 轮融资的消息让我停下来认真思考。这轮融资由 a16z 领投，Fly Ventures 和 A Capital 继续跟进。更有意思的是，GitButler 的 CEO Scott Chacon 是 GitHub 的联合创始人之一，他写过那本几乎每个开发者都读过的《Pro Git》。一个已经在版本控制领域取得巨大成功的人，为什么要回到创业赛道，重新思考这个看似已经"解决"的问题？他在公告中说得很直白："我们不是在构建一个'更好的 Git'，我们是在构建软件构建方式的下一代基础设施。"这句话背后隐藏着对软件开发未来的深刻洞察。
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 试图帮助我们回归的方向。
