工作区本来就有修改，怎样让 Codex 只提交本次任务

工作区已有修改时，让 Codex 只提交本次任务，需要把提交范围落实到暂存区。文件名单只是第一层保护，同一文件的两个变化块仍可能来自不同任务。先记录基线，再按块选择，最后阅读暂存差异；这比在提交后凭记忆拆分容易得多。下面使用一个独立演练仓库，不建议在正在工作的文件上试错。

用一个文件制造两类变化

建立 demo.txt，上半段是标题，下半段是计算说明，中间留几行不变内容并提交为基线。先改标题，代表用户已有工作；再改下半段，代表此次任务。两处距离要足够远，让 Git 通常能显示成两个变化块。此时整文件暂存会把两项一起收进去。

git diff -- demo.txt
git add -p -- demo.txt
git diff --cached -- demo.txt
git diff -- demo.txt

git add -p 会逐块询问。目标块选 y，用户已有块选 n；块太大时可尝试交互菜单里的拆分选项。菜单以终端当时显示为准，不要连续输入一串预想答案。暂存完成后，第三条命令应只显示任务变化，第四条应仍显示已有变化。这两份输出同时成立，才证明划分结果符合预期。

两处变化挤在同一块时

先用交互拆分；无法再拆时，只有真正理解补丁语法的人才考虑编辑补丁。编辑的是索引要接收的差异，并不等于修改磁盘源码。删错上下文会导致应用失败，误改增删行则可能把暂存区变成一个从未在磁盘上测试过的版本。

更稳妥的做法是在另一个临时工作目录中重做这一个小改动，得到独立补丁，再由熟悉代码的人核对；也可以把两个意图拆到不同函数或位置后重新审查。这里不提供“自动根据作者拆块”的承诺，因为 Git 普通差异没有这类作者归属信息。

提交前填写下面的演练记录：

检查对象	期望	证据
原有标题变化	留在工作区	普通 diff 中可见
此次说明变化	进入索引	cached diff 中可见
无关文件	不进入索引	暂存名称清单不含它
暂存版本	可独立通过相关检查	独立目录验证记录

如果开始前索引就有内容，不要把它当作空白画布。先记下那些内容属于谁、是否允许一起提交；无法确认就暂停提交动作，但仍可以完成本次文件修改和差异说明。

验证对象必须和提交对象相同

一个常见错位是测试跑的是完整工作区，提交却只有部分块。被留下的用户变化可能恰好修复了测试，于是暂存版本单独取出就失败。对于这种依赖关系，应该在临时目录检出基线并应用本次补丁，运行相关检查。不要为验证而在共享目录切来切去或清空未提交工作。

向 Codex 交代任务时，可以写：“开始前记录已有差异；只处理日期校验；不得把标题变化放入提交；提交前展示暂存差异，说明是否独立验证。”这些是工程约定，不是官方提供的自动隔离开关。检查阶段结束后，再按项目规则决定由谁执行提交。

常见问题

只写明文件路径够吗？ 不够，同一个文件里的旧变化仍可能被整文件暂存带入。

暂存错了能纠正吗？ 可以调整索引，但先保存当前暂存差异，并确认不会误动别人已经暂存的块。

能直接把工作区全部藏起来吗？ 在多人或多工具共享环境中应谨慎，藏起与恢复都会改变现场；独立目录验证通常更可控。

继续处理相关问题

相关入口：Codex 远程压缩报错分流。

官方依据与核对日期

核对日：2026-10-23。Git add 交互暂存：patch 模式允许交互选择变化块进入索引；Git diff 暂存比较：cached 可用于审查即将提交的差异。文中的流程、阈值和合成数据属于工程示例，不能代替当前账号、文件或运行环境的验收。