把 Codex 给的补丁应用到新代码前，怎样检查基线已经漂移

Codex 给出补丁之后，目标文件可能又被其他人改过。此时把聊天里的补丁直接落盘，会把“补丁针对哪个版本”这个问题推迟到冲突发生以后。更稳的交付应带上生成时基线、目标文件摘要和补丁本身；应用前先做不写入的预检。

一份补丁，两份基线

演示文件有 limit=10 和 mode='safe' 两行，补丁只把上限改为二十。第一份基线保留原文，预期检查通过。第二份基线将同一上下文改成 limit=30，预期检查失败。它模拟的是基线已经漂移，而不是补丁语法错误。两种原因需要不同处置，不能都归结为“AI 没写对”。

附件在临时目录运行 git apply --check，检查前后对目标文件和补丁分别计算摘要。无论通过还是失败，文件字节都应保持一致。这一条很关键：工具退出码为零仅表示预检允许应用，不应顺便产生工作区修改。示例没有在当前项目应用任何补丁。

基线证据要覆盖未提交修改

提交编号能定位已提交快照，但不能代表工作区所有字节。生成补丁时如果文件已经有未提交改动，只记提交编号就会丢失真实上下文。因此报告还要记录涉及路径的内容摘要，必要时保存可审查的工作区补丁。共享证据前先清除密钥和个人数据，但不能用脱敏后的文件摘要冒充原始生成输入。

预检失败时保留命令、退出码和错误位置，再核对当前文件。不要为了让检查变绿，直接扩大忽略空白或上下文容忍范围。确实需要重新定位补丁时，应从新基线重新生成，并重新阅读最终差异；它属于一次新的变更审查。

能应用与行为正确分开记录

反例是补丁只替换一个仍然存在的变量名，检查通过，但该变量在新版本已不再控制实际限额。文本匹配没有能力判断业务语义。预检通过后仍需检查变更目标、运行相关测试，并核对实际执行入口。报告可以同时出现“可应用：是，行为验证：待运行”，这比一个总的成功标志准确。

三方应用或其他合并机制有各自的前提，不能从本文两个夹具推导它们总能修复漂移。Git 官方文档说明 --check 的职责是检查补丁是否可应用及检测错误；本文利用这一只读阶段提前暴露版本差异。

收件人最终应看到原基线通过、冲突基线失败、两次字节未变三项证据。若出现两份都通过，要先检查是否真的改到了补丁上下文；若两份都失败，要检查补丁行数、换行和路径层级。不要只保留符合预期的一次运行记录。

配套文件与依据

本文的合成输入和参考结果可下载独立样本 a004.json，离线检查器 a004.py与样本放在同一目录后运行。检查器不调用模型接口。 使用 Python 3.12 或兼容版本，将上述文件下载到同一目录，执行 python a004.py。 此项还需本机可调用 Git；操作仅发生在自动创建的临时目录。 同篇运行还需要：a004-change.patch，请一并下载。

一手资料1；一手资料2。资料核对日期：2026-10-24。