它想改的不是编辑器，是评审这一步

Delta 的出发点很具体：智能体生成代码的量上来了，需要互相评审的 diff 越滚越大。把大 diff 拆成栈式分支只是让导航更容易，评审者真正缺的是决策背后的上下文——更小的 diff 提供不了「为什么这里用 Mutex 而不是 RwLock」。

所以它的协作方式不依赖提交与推送：把队友邀请进你与智能体的对话后，对方能看到同一批 worktree，并在自己机器上继续操作，也可以直接向同一个智能体追问。你下线后，队友能接着在原来的位置往下做。

一条低风险的试用路径

  • 挑一个非敏感的小仓库，别从核心业务仓库开始；
  • 先用网页版跑通流程，不装客户端，省掉环境问题；
  • 在一条线程里修一个小 issue，任务完成后把线程分享给一位队友；
  • 让队友用评审子线程看改动：它会带着原始智能体的上下文引导，且拿到父线程 worktree 的隔离副本，可以放心在里面试改动；
  • 确认合并方式与 Git 的关系（官方说明它与 Git 兼容），保证随时能回到原有流程。

客户端覆盖 macOS、Linux、Windows，也有网页版，线程可以用移动浏览器跟进。具体的安装包与入口以 zed.dev/delta 上的当前说明为准，公开测试阶段功能变化较快。

铺开前要先定的三件事

第一是范围：哪些仓库允许共享会话与工作树。会话共享意味着队友能看到你的工作树与会话历史，敏感仓库需要单独评估。第二是权限：谁能邀请谁、评审子线程能否直接改动主工作树，需要一条明确的规则。第三是退出路径：它与 Git 兼容，因此迁移不是单向的，这一点在说服团队时比功能清单更有用。

还有一个现实问题值得先想清楚：这套流程成立的前提是队友愿意进入你的会话。如果团队以人工小步提交为主，评审单元从 diff 变成线程带来的收益有限，迁移成本反而要先付。

把评审挂回原始会话，等于把「为什么这么改」当成产出的一部分——这比把 diff 切得更碎更接近评审的本来目的。