leon7hao (@leon7hao)

很早之前就写过一篇关于 worktree 的 vibe coding 文章，我想可以再提一下。 大家肯定是因为希望并行地开发功能和修复才使用的 worktree。宝玉老师说可以在同一目录直接并行，这对于相对简单的情况是完全可以的。但是涉及稍微复杂的情况，这样反而丧失了并行带来的好处，不断破坏 Agent 的上下文。这就好似双向同步一样的灾难，Agent A 读取到了文件改动，再顺着改动重读一遍所有的调用，浪费更多的 token，之前的设计决策可能也会被一并推翻。何况 Agent 是有大概率出现细节遗漏，导致仓库同时存在不同的假设。墨菲定律告诉我们这一定会发生。 除了磁盘浪费多份之外，worktree 烦人的另外一点是一个分支只能被 checkout 绑定在一个目录。因为环境变量，端口，我相信很多人的习惯是在主目录进行测试。 所以我觉得最好的一种使用 worktree 的方案是结合 GitHub 或者其他 host，本地 clone 两份 git。测试用一份，开发用一份。worktree 只在开发 git 使用，测试通过 checkout 挨个分支进行测试和收尾。通过之后开发的对话连同 worktree 就可以一并 archive 回收掉。在 Lody 中可以无感地做到这些，archive 了对话，worktree 也就被自动回收。通过 PR 状态感知验收状态。 这样的好处是 - Agent 做的改动永远有留痕和备份，冲突是通过 merge 完整地解决，而不是边做边解冲突。 - 磁盘占用不会无限膨胀，而只和你的最大并发能力有关。 - 脑袋不需要有 worktree 的概念包袱，一个 git 命令不会也可以随便并行，只需要了解干完活把对话 archive 就行。也不用受 branch 已经 checkout 到 abc 目录的折磨。

踩坑了，之前进行 electron 打包体积瘦身时把语言文件都干掉了。结果在 windows 系统下如果没有语言文件，<input type=file> 会直接导致应用崩溃。

给 Lody 把 terminal 加上，简单的命令就不劳烦 Agent 浪费 token 了。 Lody 已经移除了邀请码机制，如果你需要移动端 remote control，需要团队共享 context，需要组合使用多种 code agent，那就试试 Lody AI 吧。