Codex 与 Claude Code 的文件编辑

在 AI 编程助手真正进入日常开发之后，一个很容易被忽略但非常关键的问题是：它们到底是怎样编辑文件的？

表面上看，Claude Code 和 Codex 都能“读代码、改代码、跑命令、修问题”。但在本文写作时观察到的工具形态里，两者表达修改的方式不同：Codex 以补丁描述变更；Claude Code 以精确文本替换或完整写入表达变更。客户端会演进，下面讨论的是这两种编辑模型，而不是对任何版本做永久承诺。

这种差异不仅影响工具调用方式，也会影响修改的可控性、diff 的清晰度、失败时的排查路径，以及开发者对 AI 改动的信任感。

Codex：以 apply_patch 为核心的补丁式编辑

Codex 编辑文件时，核心工具是 apply_patch。它接收类似统一 diff 的补丁文本，用来新增、删除、更新或移动文件。

典型结构是：

*** Begin Patch
*** Update File: path/to/file.ext
@@
-旧内容
+新内容
*** End Patch

这种方式的特点是：修改天然以“差异”为中心。Codex 不是简单地说“把某个字符串替换成另一个字符串”，而是用补丁表达“这里发生了什么变化”。这让它非常适合中小规模的精确修改，比如改一段函数、补一个测试、调整一项配置，或者新增一个文件。

从开发者视角看，apply_patch 的优势在于它和 Git diff 的心智模型非常接近。修改前后的内容被并列呈现，哪些行被删除、哪些行被新增，一眼就能看出来。这种形式天然鼓励“最小 diff”：只改和任务相关的内容，不做无关格式化，也不进行大范围重构。

不过，补丁式编辑也有自己的要求。patch 必须包含足够的上下文，否则可能匹配不到目标位置，或者在相似代码较多的文件里产生歧义。如果文件中包含中文、Tab、特殊缩进或不可见字符，patch 也可能因为上下文不完全一致而失败。这时 Codex 通常会先通过命令重新定位内容，再生成更精确的补丁。

因此，Codex 的常见工作流是：先用 rg、rg --files、Get-Content、Get-ChildItem 等 shell 命令理解项目结构和代码上下文，再用 apply_patch 做精确修改。必要时再运行格式化、测试或服务命令来验证结果。

这套流程很像一个命令行开发者的日常操作：先搜索、再阅读、再打补丁，最后验证。

Claude Code：以 Edit 和 Write 为核心的文本编辑模型

Claude Code 的文件编辑方式更明确地区分了两类操作：局部修改和完整写入。

它主要使用两个工具：Edit 和 Write。

Edit 用于精确字符串替换：提供文件路径、原始字符串和新字符串。实际工作流通常应先读取文件，并让 old_string 与文件内容完全一致，包括缩进、空格和换行。不同版本对“先读后改”的具体强制方式可能不同，但它始终是一条值得遵守的编辑纪律。

这意味着 Claude Code 的局部编辑不是基于“补丁块”，而是基于“精确文本匹配”。它会先读取文件，确认原文，然后用一段完整的旧文本替换成一段新文本。

这种方式的优点是直观、严格、可控。只要 old_string 是唯一的，替换行为就非常明确。它也天然鼓励 AI 在修改之前先看原文件，而不是凭记忆或推测直接动手。

但它的约束也很明显：原字符串必须完全匹配。如果文件里有多个相同片段，就需要确保唯一性，或者显式使用 replace_all。如果缩进、换行、Tab 或特殊字符没有处理好，替换就会失败。对于复杂文件，Claude Code 可能需要借助 cat -A、PowerShell 脚本或其他命令来确认不可见字符和精确格式。

Write 则用于创建新文件或完整覆盖已有文件。创建新文件时比较直接；完整覆盖已有文件前应先读取原内容，因为这类操作最容易制造大 diff 或覆盖用户工作。

从工具选择上看，Claude Code 的逻辑非常清晰：修改几行用 Edit，创建新文件用 Write，整个文件需要重写时也用 Write，但覆盖前必须先 Read。多处相同字符串替换则可以用 Edit 搭配 replace_all。

两种方式的本质差异

Codex 的 apply_patch 更偏向“补丁思维”。它描述的是文件的变更片段，强调修改前后的差异。Claude Code 的 Edit / Write 更偏向“文本编辑思维”。它强调先读取文件，再对具体字符串或完整内容进行修改。

这会带来几个明显差异。

第一，Codex 的修改更像 Git diff。它的输出天然适合审查，开发者可以直接看到增删行。Claude Code 的修改更像编辑器操作，重点在于“把这段精确文本替换成那段文本”。

第二，Claude Code 对“先读后改”的要求更强。Edit 和覆盖模式下的 Write 都要求先读取文件。这降低了凭空修改的风险，也让编辑过程更依赖当前文件的真实内容。

第三，Codex 在处理多文件、小范围修改时很自然。一个 patch 可以同时更新多个文件，也可以新增、删除、移动文件。Claude Code 虽然也能处理多文件，但在心智模型上更偏向逐个文件读取、逐个位置替换。

第四，失败模式不同。Codex 的 patch 可能因为上下文不足或上下文变化而失败；Claude Code 的 Edit 可能因为 old_string 不唯一或不完全匹配而失败。两者都依赖精确上下文，只是表达上下文的方式不同。

哪种方式更好？

这个问题没有绝对答案，更多取决于任务类型。

如果是小到中等规模的代码修改，尤其是需要清晰 diff 的场景，Codex 的 apply_patch 很有优势。它天然贴近代码审查流程，适合做局部函数修改、测试补充、配置调整和跨文件小改动。

如果是非常强调“先看原文再精确替换”的场景，Claude Code 的 Edit 会显得更稳。它强制要求读取文件，要求旧文本精确匹配，这让修改行为更保守，也更容易避免误改。

如果是新建文件，两者都能很好完成。Codex 可以通过 Add File 表达新增文件；Claude Code 可以直接用 Write 创建文件。

如果是重写整个文件，Claude Code 的 Write 更直接，但也更需要谨慎，因为全文件覆盖很容易制造较大的 diff。Codex 也可以通过 patch 完成大范围修改，但 patch 太大时可读性会下降。

共同点：真正重要的是编辑纪律

虽然工具模型不同，但 Claude Code 和 Codex 在编辑原则上有很多共同点。

无论工具是否显式强制，它们都应遵循同一套编辑纪律：先理解上下文，再做最小变更；不主动做无关重构或格式化；未经明确授权不执行 git reset --hard 等破坏性命令；把工作区已有修改视为用户资产，而不是可随意覆盖的临时状态。

这说明，AI 编程助手的可靠性并不只取决于模型能力，也取决于它的编辑纪律。

一个好的 AI 编程助手，不应该只是“能把代码改对”，还应该让开发者清楚地看到它改了哪里、为什么改、有没有越界、是否保留了用户已有工作。

结语

Claude Code 和 Codex 的文件编辑方式，代表了两种不同的工程取向。

Codex 通过 apply_patch 把修改表达成补丁，更接近 Git diff 和命令行开发者的工作方式。Claude Code 通过 Edit 和 Write 把修改拆成精确替换和完整写入，更接近一个严格的文本编辑器模型。

前者强调 diff 表达，后者强调读取后的精确匹配。前者适合补丁式、多文件的小步修改，后者适合保守、明确、可控的文本替换。

但无论是哪种方式，真正决定体验的并不是工具名字，而是背后的原则：先读后改、最小变更、避免无关格式化、尊重用户改动、谨慎执行命令。

当我们评估一个 AI 编程助手时，不妨少问一句“它能不能改代码”，多问一句：“同一个改动，它能否说明前提、给出可审查的 diff，并在失败时清楚暴露原因？”这比工具名称更能说明它是否适合真实工程工作流。