Zed DeltaDB
Zed 新的 DeltaDB 功能旨在记录每一次代码变更，并将其与 AI agent 对话关联起来，实际上是在 Git 旁边创建一层细粒度、可协作的“本地历史”。评论者意见分化：一些人认为它对多人开发和 agent 辅助工作流、在提交之间轻松回退，以及未来模型训练都很有价值；另一些人则担心隐私、微观管理以及功能范围膨胀，会以牺牲修复基础编辑器稳定性和 UX 问题为代价。讨论也反映出对 VC 驱动优先级的普遍不安，以及核心开发工具与 AI 中心工作流日益缠绕的趋势。
DeltaDB 的目标
- 定位为 Git 之上的一层，而不是 Git 的替代品。
- 跟踪提交之间细粒度的“增量”，并将每次变更与产生它的 agent 或对话关联起来。
- 基于 Zed 现有的 CRDT/多人协作工作；面向协作式和 agent 化工作流，包括在运行中分支以及加入实时工作。
被认为的用处
- 支持者将其类比为 JetBrains/VS Code 的“本地历史”，但功能更丰富且可共享：可在提交之间轻松回滚、恢复错误，并从代码追溯到产生它的对话。
- 有些人认为这对调试复杂的 agent 会话或多人、多 agent 协作很有帮助。
- 也有人认为它很小众：在多年的工作中，他们很少需要这种级别的历史记录，更倾向于频繁的 Git 提交或像 Jujutsu 快照这样的工具。
AI/Agent 工作流 vs “只是一个编辑器”
- 许多人喜欢 Zed 基于 ACP 与外部 agent 的集成（Codex、Claude Code、OMP、OpenRouter），并将 DeltaDB 视为“agent-native”工作流的自然延伸。
- 相当一部分人希望 Zed 专注于成为一个快速、稳定的编辑器（修 bug、LSP 稳定性、SSH/WSL、UI 打磨），而不是复杂的 AI/VCS 功能。
- 一些用户因不稳定、性能问题或缺少“基础”功能而放弃了 Zed，并认为 DeltaDB 的优先级分配不当。
隐私、监控与管理担忧
- 强烈反感永久记录每一次对话和类似按键级别的变更。
- 担心它会助长微观管理（把“糟糕的 prompt 质量”当作绩效指标）以及事件复盘时重放 agent 聊天记录。
- 也有人担心它会事实上一下变成老板监控软件或未来模型的训练数据；另一些人指出，企业 AI 工具和间谍软件已经存在类似风险。
Git、JJ 和其他比较
- 多条评论认为，Git 加上更好的 UX、频繁提交，或者 Jujutsu 快照，已经覆盖了大部分需求。
- 有人建议 Zed 可以依托 JJ，或与现有工具集成，而不是发明新的基础设施。
- 对一些人来说，自托管很重要；他们对一个不能自托管的、类似 VCS 的系统持怀疑态度。
商业与战略担忧
- 很多人把 DeltaDB 和 AI 功能与 VC 压力联系起来：纯编辑器很难变现；AI 工作流更容易卖。
- 担心同时维护 IDE 和 VCS 级系统会分散精力，尤其是在当前 bug 积压和平台支持不均衡的情况下。