软件是在提交之间完成的

对 DeltaDB 概念的反应

• 一些人认为 DeltaDB 的“每次提交之间的每一次操作”是 AI 代理和协作的自然底座，尤其适合那些本就把 LLM 当作主要编码伙伴的远程、代理密集型团队。
• 另一些人则把它看作侵入式的“代码键盘记录器”，会带来噪音、认知负担和审查负担，而相较于精心编写的提交和 PR 并没有明显收益。
• 也有人怀疑，它主要受益于 AI 训练和企业监控/审计需求，而不是日常的人类开发者。

提交与细粒度历史

• 一派重视频繁、粒度细小的提交和丰富历史，用于 git blame/bisect、调试以及理解演进过程。
• 另一派更喜欢经过激进清理、rebase 或 squash 后的历史，它讲述的是代码的“理论故事”，而不是实际走过的混乱路径。
• 许多人认为有用的单位是小而原子的提交或变更列表，而不是按按键级别的差异；他们把 DeltaDB 类比为记录每一张草稿纸或每一份草稿，而这些内容通常很少被回看。
• 也有人指出，现有工具（带频繁提交的 Git、--first-parent、Gerrit/Phabricator、jj）已经支持细粒度历史或类似自动保存的快照，而无需把一切都集中化。

AI 代理与编码工作流

• 一部分评论者已经大量使用 LLM，由代理编写大部分代码，人类负责引导和审查。对他们来说，把代理对话和代码演化放在同一个地方很有吸引力。
• 另一些人认为，正确答案是更好的文档、注释和 PR 描述，而不是回放代理聊天和中间差异。
• 有人担心，工具正在围绕代理重构，而不是围绕人类协作需求。

隐私、监控与工作场所控制

• 人们强烈不安于雇主拥有“提交之间的思考”完整记录，其中包括抱怨、困惑和临时秘密。
• 有人预测，AI 溯源日志、token/影响指标以及审计轨迹会被强制使用，并用于绩效评估、裁员和法律抗辩。

Zed 作为编辑器与平台

• 很多人称赞 Zed 速度快、极简、无干扰，并看重其当前可以关闭 AI 功能的能力。
• 另一些人担心它会转向“类似 Cursor”的代理中心工作流、臃肿化，以及对 Anthropic/OpenAI 的依赖；像 Gram 这样的分支被欢迎为“无 AI”的保险。

协作与 PR

• 有些人同意 PR 是一个较晚且粗粒度的协作点，但认为 DeltaDB 不是正确的修复方式；他们更希望更好地支持小改动、堆叠式/原子化审查以及多仓库工作流。
• 总体而言，没人一致认为按操作版本化能比改进现有 VCS 和审查实践更实质性地提升人类协作。