拒绝单线程！Git Worktrees让你像大佬一样多任务推进AI编程

在传统的AI辅助编程中，开发者50%的时间在等待AI响应或代码运行结果。简单小脚本让Claude写当然没问题，但真正容易翻车的是复杂任务。哪怕你是菜鸟开发者，也能通过这种「双机博弈」得到大师级的架构设计。要用好CLAUDE.md文件，别让AI的智商随着Session结束就清零。

仍然在一个对话框当中不停地死磕那所谓的AI，等着它出现错误，然后进行修改，接着再次测试，如此反复不断地循环？那些顶级的开发者事实上早就已经开始运用并行工作流了，效率之间的差距就是通过这样的方式被拉开的。他们并非比你更具备耐心，而是运用工具思维将工作方式进行了彻底的重新构建。

在传统AI辅助编程当中，开发者存在50%的时间用于等待AI作出响应，或者说等待代码运行产生结果，这样一种守着屏幕去等待回应的方式，从本质上来说跟二十年前并无差别。

位于顶级水平的开发者Boris所采取的做法呈现出一种简洁的状态，那便是直接去拉取三至五个Git工作目录，针对每一个工作目录都运行一项独立的任务。如此一来，你便无需将分支、改动以及聊天记录全部混杂在一起。

于同一仓库之中，存在多个工作目录，所有的分支共用同一.git 文件夹，那么便可以于相同的一份历史当中拉出多个目录，并且在切换任务之时相互之间不存在干扰。

每一条独立会话皆与一个目录相绑定，如此一来上下文更为洁净，进行改动时也更易于回收。其中一个负责运行耗时测试，一个前往追踪程序漏洞，另一个开展重构工作，而调度以及验收的职责则全由你承担。

单一的简单脚本不存在问题，然而一旦复杂任务中的需求数量增多，并且所涉及的依赖关系变得繁杂起来，那么AI便会开始出现偏离正轨的情况。Boris团队拥有一条严格的准则，那就是在面对复杂任务时要首先进入计划模式。

处于计划模式之时，先集中精力去规划，而后再一次性予以执行。如此这般进行的益处在于，能将模糊的需求首先梳理清晰，而非使AI一边猜测一边撰写，最终陷入反复修改的困境之中。

使一个人工智能承担起做出计划，完成实现的任务，让另一个人工一心专注于利用毫无杂质的上下文去扮演审查者角色，专门紧盯着边界的条件，错误出现时的处理方式以及代码呈现出的风格。

将审查意见重新丢回到让首个AI去修改。这样一种流程，即先进行计划而后执行，先是实现接着再复核，能够使得生成的内容质量显著得以提升，就连菜鸟也能够获得大师级的架构设计。

一次坑你已作过一回解释，二次仍需解释，那就应由流程助你记录下来。用.md文档记载代码风格、目录约定、常用指令以及你已踩过的坑。

被纠正过一回的错误，别仅仅留存于聊天记录当中，要直接促使它将经验补充进.md。下一次开展新的会话时，AI便不会如同刚开始入职的新人那样从零点起步。

仍于Slack接收到Bug，前往CI检查日志，而后返回IDE修改代码？MCP协议能够使你减少作为人肉搬运工的情况，将上下文直接贯通。

在Slack里进行讨论，你毫无必要去复制信息而再解释一番。关于日志，在CI这里，你同样不需截屏拼图这么做。使得AI去读取相关的上下文内容，并且调用对应的工具，进而把能够落地实施的改动呈现回来。

当您将.md撰写完成时，把工作目录开启，将Plan Mode予以运用，AI便不会每次都如同新人那般从零基础起步前行。平庸平常的开发者在与AI进行交流对话，然而顶级优秀的开发者正在训练一支庞大的队伍。您的那款AI今日是否仍然处于一种未加修饰的状态呢？