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：提供整体覆盖（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 这个设计谈不上多惊艳，但它把"尊重用户已有的工作"做成了代码层面的机制，而不是靠模型自觉——经历过开头那种被覆盖的痛，才知道这有多重要。