撰文：Techub News 整理
在 a16z 最新的深度对话中，GitHub 联合创始人、《Pro Git》作者 Scott Chacon 分享了他为何在功成名就后重返创业战场，创立 Git Butler。他认为，AI 代理（Agent）的崛起正在暴露 Git 等经典开发者工具的局限性，并从根本上改变着软件开发的协作方式。这场对话不仅关乎工具的重构，更关乎在 AI 时代，开发者核心能力与团队协作模式的演变。
重返战场：为何要“重建”Git？
Scott Chacon 的职业生涯与 Git 和 GitHub 紧密相连。在离开 GitHub 并经历了一次语言学习创业后，他发现自己钟爱的 Git 工具生态“自离开后几乎没有改变”。当他被邀请为《Pro Git》撰写第三版时，他感到困惑：“为什么要更新？它几乎一模一样。”这种停滞激发了他的思考：如果抛开历史包袱，从零开始设计，一个吸收了近二十年经验教训的版本控制工具应该是什么样子？
Git Butler 并非要彻底重写 Git 的底层数据存储或传输协议——Scott 认为这些部分“非常稳固、聪明”。他的目标直指“用户界面”，旨在为 Git 注入“品味”和现代易用性。他强调，Git 最初遵循 Unix 哲学，设计了一组基础的“管道”命令，预期用户会用 Perl 脚本将其组合成所需功能。然而，一个名为“Pasquy”的人编写了一些 Perl 脚本作为用户界面（即后来的“瓷器”命令），因其便利性而被广泛采用并最终并入 Git 核心。这导致了一个结果：Git 的命令行界面（CLI）试图同时服务人类和机器，但“对人类不够友好，对机器也并非都那么理想”。
更重要的是，Git 项目极度强调向后兼容，几乎从不移除旧功能。这使得 CLI 界面成为一个“弗兰肯斯坦”式的混合体——功能强大且快速，但缺乏统一的设计愿景和演进路径。Scott 认为，现在是重新思考的绝佳时机，尤其是在 AI 代理开始参与编码工作流的2026 年 4 月。
为 AI 代理优化：从 CLI 到“人格化”界面
Git Butler 的起点是一个图形界面（GUI），但 Scott 很快意识到，AI 代理无法直接使用 GUI。这促使他们开发了命令行工具。关键在于，他们开始将 AI 代理视为一个独特的“用户人格”，并为其量身定制交互方式。
传统 Unix 哲学追求工具的输出能被其他程序管道化使用，但这往往不是人类阅读的最佳格式。Git Butler 的 CLI 尝试同时满足两者：默认输出为人类优化（提供提示等），增加 --json 标志输出机器可解析的 JSON，甚至考虑推出 --markdown 格式，因为 AI 代理更擅长处理此类结构化文本以注入上下文。
Scott 分享了一个有趣的发现：他们原以为代理会喜欢 JSON 格式，但观察后发现，代理有时更愿意获取人类可读的输出，然后自己用 JQ 或 Python 脚本提取所需数据。更常见的是，代理在执行一个变更命令后，会立即运行 status 命令查看状态。于是，Git Butler 在所有可变命令后自动附加状态输出。“这类优化你永远不会为脚本编写或 Unix 哲学而做，人类也不需要，但代理确实想要。”Scott 总结道，理解并服务于这个新“用户人格”的需求，是一个尚未被充分探索的全新用户体验问题集。
并行分支：让多个代理协同工作的新范式
随着多代理工作流的出现，传统 Git 工作模式的局限性凸显。常见的解决方案是使用“工作树”，即为每个代理创建代码库的独立副本。但这带来了隔离与协作的矛盾：代理彼此看不见对方的工作，直到合并时可能产生冲突。
Git Butler 引入了“并行分支”的概念。它允许在单一工作目录上同时开展多个分支的工作。代理可以看到彼此对文件的修改，并在此基础上进行叠加，从而避免冲突。Scott 描述了一个生动的场景：当两个代理试图修改同一文件时，其中一个可以将其分支“堆叠”在另一个之上，然后继续在属于自己的堆叠部分提交。这实现了逻辑上的分支隔离与物理上的工作目录共享。
他们甚至尝试过为并行工作的代理建立一个聊天频道，让它们实时沟通。虽然这个“非常酷”的功能最终因代理能自行观察并协调而显得“并无帮助”未被采用，但它揭示了未来团队协作的潜力：代理可以利用其“ downtime ”与其他团队的代理沟通，提前协调可能的影响，减少人类开发者事后解决合并冲突的开销。“这始终是软件开发中的一个痛点，”Scott 指出，“而代理没有这个问题。”
代码审查与协作的未来：从 PR 到“写作能力”
Scott 对当前基于拉取请求（PR）的代码审查流程提出了质疑。他认为 PR 催生了“提交垃圾”——因为审查和合并关注的是分支整体，而非单个提交信息。他更怀念邮件列表时代的补丁审查模式，那时良好的提交信息本身就是 PR 描述。
随着 AI 生成代码的比例增加，审查的本质可能发生变化。Scott 提出一个尖锐的问题：“如果你问几乎任何软件开发者，当你做代码审查时，你真的会阅读整个 PR 吗？你会逐行思考、拉下来测试、然后在每一行留下有价值的反馈吗？” 他认为，未来审查可能变得更本地化、更基于补丁，并且可以由代理辅助执行——代理可以拉取代码、运行测试、定位问题，然后给人类开发者一个简短的待审查清单。
这引出了 Scott 对 AI 时代开发者核心能力的判断：沟通和写作能力将成为新的超能力。当“如何实现”的成本因 AI 而降低，“要实现什么”以及“为何要这么做”就变得至关重要。能够清晰描述需求、撰写规格说明、促成团队共识的开发者，将成为未来最高效的产品创造者。“所有因为可以跟机器打交道而不是跟人打交道而被工程学吸引的人，现在发现工程学终究还是一门关于人的学科。”他略带调侃地说道。
Scott 以自身为例，他花费大量时间撰写概念验证和规格说明，然后让 AI 去实现，再根据结果调整规格。这种快速迭代“展示与讲述”的能力，比单纯说服他人阅读一份文档要强大得多。
元数据、数据膨胀与工具的终极形态
AI 工作流带来了海量的新数据：每次交互的提示、代理的“思考”日志、决策过程等。Scott 认为，为这些元数据（如对话记录）建立版本控制系统至关重要，但这也成为一个“大数据问题”。即使在小项目上，存储所有上下文也会迅速导致数据膨胀。Git Butler 正在尝试利用 Git 中一些处理大型仓库（如 Chrome）的特性来构建可扩展的元数据系统。
Scott 喜欢思考工具的“逻辑终点”。对于语言学习，终点是拥有一个实时、精准、具备文化背景的人类翻译——但这依然不是完美的交流。对于编码代理，终点可能是“拥有一个你所知的最优秀的工程师，他能停止时间，想工作多久就工作多久，然后时间恢复，你就得到了解决方案”。
当接近这个终点时，核心问题将不再是“如何生成代码”，而是“如何管理这些无限的时间与智力资源”、“如何确定要构建什么”以及“如何确保最终产物令你满意”。工具的角色将从代码生成器，转向帮助人类厘清目标、协调意图和评估结果的大脑扩展器。
Scott Chacon 的思考超越了简单的工具优化，指向了 AI 深度融入开发生命周期后，人机协作范式与团队组织结构的深刻变革。Git Butler 是他对这一未来的第一次具体押注，而这场变革，才2026 年 4 月开始。
