Delta

为什么选择 Delta？

当难点从生成代码转向理解、审查和协调智能体改动时，Delta 的特色更明显。它以持久会话为工作单位，将对话、变化中的文件、评论、工具活动和审查状态连接起来，比只有最终差异和分离聊天记录更易追溯原因。

团队并行多个任务时尤其有用。提示词、中间修改、终端输出和反馈分散会增加审计难度，Delta 将它们放在同步的工作记录内。但采用它意味着转向会话优先流程，并非只安装补全或聊天扩展。

核心工作流程

典型流程从 Git 仓库和范围明确的任务会话开始。智能体默认在隔离的托管检出目录工作，不立即影响日常工作树。会话成为任务空间：提示引导实现，终端运行于同一目录，评论可指向对话或代码。

审查时，不仅看最终分支差异，还能结合产生改动的那轮对话查看、在原会话要求修订，或转到专门审查会话。接受后，通过本地 Git 远程或共享 origin 与 PR 流程回到普通仓库。

团队可共享同一会话，无需截图或粘贴聊天交接。参与者各有同步检出目录，可查看共同对话、代码历史、评论和活动。模型用量归属发送请求者，减少对单个人凭证的依赖。

适用场景

适合长时间重构、缺陷调查、依赖升级及多文件、多轮审查的功能开发。持久会话保留修改理由，避免仅压缩进提交消息或遗失在智能体记录中。

也适合并行实验。不同会话操作同一项目的隔离副本，减少互相覆盖工作状态。可一个会话实现，另建审查会话批准或要求修改，仍与原工作关联。

交接也是用途。代码状态和对话同步后，其他开发者可加入并查看过程，不必从 PR 说明重建上下文。中途换负责人，或审查者需要理解特殊实现选择时尤其有用。

同类工具对比

Cursor、Windsurf、Trae、Void、Zed 以编辑器为中心，将 AI 集成其中；Delta 则以会话为中心，文件视图、差异、终端、评论和智能体执行围绕会话工作展开。

只想要快速行内补全或熟悉编辑器内助手的用户，可能不太需要 Delta。多智能体、多审查者，或经常需要解释修改演变时，来源追踪和多人协作可能比单纯编辑体验更重要。

Zed 是最接近的比较对象，来自同一团队但主流程不同。Zed 仍是可运行智能体的编辑器，Delta 则是围绕对话和协作的独立应用。需要完整编辑界面时，也可在 Zed 打开 Delta 管理的目录。

配置建议

多数仓库应默认隔离智能体任务。只有明确希望直接修改当前工作树的小型受控任务，才使用原地检出。这样分开实验与已接受工作，完成后仍方便推回本地仓库。

模型配置可按任务分配：低价模型探索和总结，均衡模型常规实现，前沿模型规划与困难审查。托管模型应设月支出上限，BYOK 凭证应存于支持的环境或 Delta 配置位置，而非仓库。

共享时，除非有意全组织开放，否则会话默认保持私有。审查需看 CI 状态时接入 GitHub；开发服务器、监视器和长测试用后台终端，供多轮交互。有固定初始化步骤的仓库可用可执行 .agents/prepare 脚本，保持新目录环境一致。

迁移建议

Delta 不能直接替换 VS Code 配置或扩展包。项目必须用 Git，并按带独立工作树的持久会话组织任务。迁移团队应先从一个仓库、少量明确任务开始，不必一次搬走所有开发活动。

原有 Git 习惯可保留。Delta 不替换提交、分支、远程和 PR，只增加其间更细的历史。无远程仓库也可本地使用，但共享会话需协作者可访问的远程。Jujutsu 支持仍早期且不完整，不能默认等同 Git。

最大迁移决定是组织方式：哪些工作放入共享会话、如何审查、何时回归团队分支与 PR 流程。边界清晰时，Delta 的价值最大。