DeepSeek Harness 试用发现：AI 会不会覆盖你手动改的文件？

本文首发于 栏轩·阁欢迎访问阅读原文获取更好的阅读体验。一、一次意外的拒绝和一段惨痛回忆试用 DeepSeek Harness以下简称 DSH时我让它用 write 命令不读文件凭记忆直接覆盖写入一个文件结果它拒绝了Error: cannot write ...: file changed since it was read — re-read the file, then retry翻译过来就是“这个文件在我上次读取之后被改过了请先重新读取再试。”看到这个报错我愣了一下——紧接着想起的是在 Claude Code 里的几次惨痛经历我手动改好的内容在 AI 下一次写入时被悄悄覆盖等我发现时已经找不回来了。文件是我最重要的资产却被 AI 在不经意间冲掉那种感觉非常恼火。而这一次DSH 选择了拦下来文件被改过它就不允许 AI 基于过期的记忆直接覆盖而是要求先重新读取。二、背后的机制版本守卫查了源码DSH 的文件系统带有一套观察策略每次读取文件会记录一个版本写入时带着这个版本做比对类似并发编程里的 CAS 机制文件被外部改动版本对不上→拒绝写入要求重读。说白了DSH 不允许 AI 基于过期的记忆覆盖一个已经被改过的文件。整体覆盖write是最危险的操作——它可能把用户手动改的内容整个抹掉所以 DSH 在这里专门设了防线连报错信息都附了恢复指引“re-read the file, then retry”。三、对比测试四个工具只有 DSH 拦下来为了验证这是不是 DSH 独有我用完全相同的指令“用 write 命令不读文件凭记忆直接写”实测了几个主流工具工具整体覆盖写入实测结果Claude Code有无守卫✅ 直接写入成功覆盖了文件Trae有无守卫✅ 直接写入成功覆盖了文件Codex没有 write 指令只有编辑类工具 未发生覆盖——它根本没有整体覆盖这条路径DeepSeek Harness有带版本守卫❌ 拒绝写入提示先重读同一个指令四种结果。有意思的是各家的防覆盖思路完全不同Claude Code / Trae提供整体覆盖write但不设守卫——最危险用户手动修改可能被直接冲掉Codex压根不提供 write 指令只有精准编辑工具如 apply_patch / str_replace从工具集上规避了整体覆盖这个操作DSH提供 write但带版本守卫文件被外部改过就拒绝。四、客观的边界Claude / Trae 并非完全没有保护它们的 edit 工具要求字符串精确匹配内容对不上也会报错但它们的write 没有版本守卫——整体覆盖畅通无阻这正是我被覆盖几次的原因。Codex 靠没有覆盖工具来防覆盖它只有编辑类工具没有整体写入路径所以天然不会覆盖代价是没有 write 能力的便捷性。DSH 的守卫也有局限edit 因为要先读文件做字符串匹配几乎不会触发这个保护观察状态也不跨会话会话恢复后需要重新读取。所以准确的说法是只有 DSH 在整体覆盖这条最危险的路径上设了代码层面的守卫而 Claude Code、Trae 是有 write 但不管Codex 是干脆不给你 write。五、我的感受DSH 这个设计谈不上多惊艳但它把尊重用户已有的工作做成了代码层面的机制而不是靠模型自觉——经历过开头那种被覆盖的痛才知道这有多重要。