GitHub联合创始人Scott Chacon吐槽：停滞20年的Git，已难适应AI时代

“Git的用户界面已经停滞20年，完全适配不了AI coding agent的需求。”这句话出自GitHub联合创始人Scott Chacon，是在顶级风投a16z的「AI + a16z」播客中抛出的一个尖锐判断。

这期播客由a16z合伙人Matt Bornstein对话Scott Chacon（他现任GitButler的CEO），他们深度拆解了Git的历史局限、AI时代版本控制工具的重构方向，以及未来开发者的核心能力转向。无论你是一线开发者、AI工具从业者，还是技术工作流演化的观察者，这些观点都可能带来新的启发。

Git的先天错位：从内核专属工具到全民工具的尴尬

Git从诞生起就带着明确的基因局限。2005年，它专为Linux内核团队打造，是基于Unix原语设计的“底层plumbing命令”。它的本质是供开发者用自定义脚本包裹的工具，从一开始就没考虑过要适配大众开发者的使用场景。

同年，一位志愿者开发的Perl统一界面被纳入Git核心。但自那以后，这个命令行界面几乎没有发生过实质性的变化，至今已停滞了整整20年。Scott直言不讳：“Git的UI就是个‘科学怪人’——没有统一的设计愿景，被严格的向后兼容性死死绑定，从一开始就不是为现代人类或AI agent打造的。”

Git的UI是缺乏统一设计的“科学怪人”产品，被严格的向后兼容性绑定。它既要满足Linux内核开发者的原始需求，又要兼容20年积累下来的所有用户习惯，这使得它根本无法快速适配AI时代涌现出的新场景。

扪心自问，你有没有过被 git rebase、git cherry-pick 这些复杂命令绕晕，浪费大量调试时间的经历？

GitButler：给人类和AI双适配的“新外壳”

Scott创立GitButler的核心逻辑非常清晰：Git的底层数据存储、增量压缩和网络协议仍是行业顶尖水准，这部分无需重写；真正需要重构的是用户界面，要让它能同时适配人类开发者和AI coding agent。

GitButler的核心是在不改动Git底层的前提下，实现多分支共享同一工作目录的并行开发。它不同于Git传统的单头模型，允许多个分支在同一工作目录下运行。这样一来，AI coding agent能实时感知到彼此的修改，动态调整分支堆叠的逻辑，从而从根源上减少合并冲突的发生。

针对不同用户，GitButler设计了三类差异化的界面：给普通开发者的拖拽式变基GUI，大幅降低Git操作的学习门槛；给高级开发者的交互式TUI，兼顾操作效率与自定义灵活性；给AI agent的则是优化版CLI。这个优化版CLI支持JSON或Markdown格式输出，还会在执行可变命令后自动返回状态信息，减少了AI反复执行 git status 的冗余操作。

Scott补充了一个有趣的观察：“我们试过让AI agent之间直接聊天，但发现完全没必要——它们能通过检测文件修改自动调整工作内容，不需要额外的沟通成本。”这意味着AI之间的协同可能并不需要复杂的对话机制，仅通过共享工作目录的实时状态就能高效配合，这大幅降低了协作成本。

AI时代，代码审查从“看代码”转向“看逻辑”

随着AI coding agent接管越来越多的代码实现工作，传统的代码审查模式正在逐渐失效。Scott指出，现在很多团队的PR（拉取请求）审查只是走个流程，存在严重的“commit slop”问题——即提交上来的代码充满小错误、未经打磨，非常粗糙。这背后的核心原因在于，PR这种基于分支的协作设计，在AI时代已经显得有些过时。

AI coding agent有能力逐行测试它写的每一段代码，这使得基于补丁（patch）的精细审查，可能比基于整个分支的PR审查更具效率。Scott提出了一个值得深思的观点：未来顶级开发者的核心能力将是写作，而非单纯编码。因为AI能够近乎完美地执行清晰、明确的需求，而把模糊的产品需求转化为可供AI执行的详细说明，才是当前开发流程中真正的瓶颈。

他进一步强调：“未来开发者的价值不再是写代码，而是写清楚‘为什么要写这段代码’——产品愿景、团队共识、需求背后的逻辑，这些‘为什么’的部分，才是AI无法替代的核心竞争力。”这意味着开发者的角色需要从“代码执行者”转向“需求定义者”和“逻辑梳理者”，这无疑对文字表达和抽象思维能力提出了更高要求。关于AI如何改变开发工作流的更多思考，你可以在开发者广场看到更多讨论。

AI coding agent的正确打开方式：从并行到协同

目前，多数团队对AI coding agent的使用存在一个明显误区：他们让多个AI在独立的工作树（worktree）里并行执行任务，这实际上完全浪费了AI潜在的协同能力。

Scott认为，AI coding agent的正确打开方式应该是让它们共享同一工作目录，实时感知彼此的修改并动态调整自己的工作内容。AI coding agent最大的瓶颈往往不是其编码能力，而是人类能否提供清晰、可执行的需求说明——像Linear这类偏重描述性、较为模糊的工单系统，根本无法给AI提供足够的执行依据，最终产出的代码也常常不符合预期。

另一个关键方向是元数据的收集与绑定：将提示词、聊天记录、决策日志等上下文信息，和代码本身绑定存储。这样能让AI和人类都更清晰地理解某段代码的来龙去脉。有趣的是，Git现有的一些大仓库（monorepo）管理工具，恰好能帮助这类元数据实现规模化的存储与追溯。

你所在的团队，现在是让AI各自为战，还是已经探索出一些有效的协同模式了？

下一个“GitHub”：不会是代码托管的复制品

作为GitHub的联合创始人，Scott对老东家的现状有着清醒的认知。GitHub庞大的用户体量是它的核心护城河，但同时也成了转型的沉重包袱——它被严格的向后兼容性和亿万用户的现有习惯所绑定，很难像创业公司一样快速调整，以适应AI时代的新需求。

他判断，下一个“GitHub”绝不会是GitHub的简单复制品，就像当年GitHub和它之前的SourceForge也完全不同一样。新的开发者平台不会再以代码托管为核心，而是会围绕开发者工作流中的新痛点展开：比如聚焦于提升“人类+AI”的协作效率、优化需求说明的写作工具，或是深度整合AI原生的开发工具。

Scott坦言：“GitHub的庞大规模让它很难快速试错和转向，但像GitButler这样的创业公司能更灵活地快速迭代，抓住AI时代的工具空白。”这意味着，AI时代的开源与协作平台，竞争焦点将更偏向于解决“人类+AI”如何高效协同这一核心命题，而非单纯的代码存储与托管服务。

结语：AI时代，工具的本质是解放人类核心能力

这期对话的核心，是在AI开始重构开发者工作流的当下，促使我们重新审视那些已被视为“理所当然”的经典工具。Git的底层依然强大，但其界面的重构已刻不容缓；AI coding agent不应被看作人类开发者的替代者，而应是解放人类、让其转向更高价值工作的伙伴。

无论是Git长达20年的界面停滞，还是GitButler正在进行的创新尝试，其本质都是工具对用户需求的动态适配——当用户从单一的Linux内核开发者，变成了“人类+AI”的复合体，工具的形态自然也需要发生彻底的改变。