三个开发者同时改同一套代码，合并冲突能吵到半夜。有人用GitHub Issues加Git工作树，让Claude Code（Anthropic推出的AI编程工具）实现了真正的并行开发。

这套系统到底解决了什么

打开网易新闻 查看精彩图片

核心痛点很实在：AI编程工具跑任务时，一个代理（agent）干活，其他代理只能干等。代码库被锁死，效率直接砍半。

作者的设计是把每个任务拆成独立的Git工作树（worktree）。每个代理拿到自己的代码沙盒，互不干扰。改完再合并，冲突在源头就被隔离了。

原文提到这能「显著加速整体开发生命周期」。不是空话——并行意味着多个功能点同时推进，而不是排队。

GitHub Issues在这里的角色

不是拿来记bug的。作者把它当成任务分发中枢。

每个Issue对应一个工作树分支，Claude Code读取Issue描述自动理解任务边界。状态流转直接在Issue里跟踪，省去了额外项目管理工具。

这套设计天生适合开源。外部贡献者提Issue，维护者分配工作树，AI代理或人类开发者认领执行。流程是通的。

为什么偏偏是Git工作树

普通分支切换要来回stash，工作树让多个分支同时存在磁盘不同目录。每个代理进自己的目录，像进了独立房间。

这比容器轻量，比克隆仓库省空间。原文强调「减少合并冲突」——因为冲突在本地工作树阶段就能暴露，而不是等到push之后。

对AI代理尤其友好。它们不擅长处理「当前分支是什么」这种上下文状态，物理隔离消灭了这个问题。

这套玩法的边界

作者没提的是：工作树多了，磁盘IO和内存压力怎么算？十个代理同时编译，笔记本风扇会不会起飞？

还有，AI代理的代码风格差异怎么统一。工作树隔离了冲突，但没隔离「这写的什么鬼」的代码审查成本。

不过原文的定位很明确：这是给复杂AI项目用的，不是Hello World。瓶颈在协调效率，不在单机性能。

值得盯着的后续

这套系统被设计成「开源贡献的理想候选」。如果社区接过去，可能长出更成熟的代理编排层——比如自动分配工作树、冲突预测、甚至代理之间的代码评审。

现在的版本是基础设施。真正的产品化，要看有没有人把GitHub Issues替换成更智能的任务调度，或者把工作树管理封装成Claude Code的插件。

毕竟，让AI程序员并行干活是第一步。让它们知道自己该干什么、干完了怎么交接，才是硬骨头。

好消息是，Git工作树2007年就有了，GitHub Issues 2011年上线。老工具的新用法，往往比新工具更稳。