Codex 看到工作区已有改动怎么办？如何隔离未提交文件
真实问题：接手一个已经改过文件、但还没有提交的仓库时，Codex 很容易把“原有修改”误当成自己的任务结果。本文用可复查的基线和文件白名单，处理 Codex 接入项目后的边界问题。
适用场景：仓库能运行，但工作区不是干净状态
常见情况是，开发者先手动修改了配置，或者另一个自动化任务刚生成了一批文件，随后才把 Codex 接进来。此时直接执行“修复页面、更新接口、整理测试”很危险，因为同一个文件中可能同时包含三种内容：用户尚未提交的修改、Codex 本轮需要处理的修改，以及工具生成但尚未确认的临时文件。若没有区分，后续 diff 看起来像一大块，Review 也无法判断谁改了什么。
永沃云枢的实践是把“看见现状”和“允许改变”分开。Codex 可以读取完整工作区来理解上下文，但写入范围只接受任务列出的目录和文件。对于 AI 模型接口、CCSwitch 配置或 SEO 静态页，先记录状态，再决定是否触碰，不把“已有改动”当成可以顺手清理的对象。
操作步骤：建立基线、标注归属、限制写入
第一步运行只读命令，记录 git status --short、git diff --stat 和目标文件的摘要。没有 Git 时，可用文件修改时间、哈希或目录清单建立基线。第二步把结果写进任务记录，例如“开始前已有 seo/a.html 和 config/local.json 改动，本次不得覆盖 config/local.json”。第三步明确目标清单，不要只写“修改相关文件”，而要写出允许写入的路径。
第四步先读取目标文件，确认原有改动是否与本次任务相关。如果需要在同一文件继续修改，先把原有差异拆成“保留段”和“新增段”，再使用最小补丁。第五步每完成一个逻辑动作就检查一次状态，避免连续改十几个文件后才发现越界。第六步结束时分别查看基线前后的 diff，并把新增、修改、未触碰三类文件列出来。
如果使用 AI API 接入或模型调用管理脚本，也应把日志、缓存和测试输出排除在默认写入范围之外。不要因为某个测试失败就删除用户现有的临时文件；先判断它是否是任务输入、证据样本，还是确实可以重建的产物。
常见问题/避坑：不要用“清理工作区”代替确认
最危险的操作是先执行 reset、checkout、批量格式化或全目录重写，再开始分析。它们可能让工作区看起来干净，却丢失了尚未提交的真实需求。另一个误区是只看最终 diff，不看起始状态。若用户本来就有一百行修改，最终 diff 增加二十行并不能证明 Codex 只改了二十行。
FAQ：没有 Git 能不能使用 Codex？可以，但应在开始前导出文件清单和哈希，结束后再次计算并比较。FAQ：同一文件确实需要合并怎么办？先让用户或负责人确认原有改动意图，再按段落合并，并在验收记录中说明保留了哪些内容。FAQ：临时文件要不要纳入 diff？要先分类，涉及密钥、日志或用户数据的文件不能随意提交，也不能为了“整洁”直接删除。
排错路径：发现疑似误覆盖时怎么恢复判断
先停止继续写入，保存当前状态和命令输出。然后对照基线检查三个问题：原有文件是否被删除，原有段落是否被替换，新增文件是否超出白名单。若使用了格式化工具，再检查换行、编码和空白变化，避免把纯格式差异误判为业务修改。恢复时优先从版本控制、编辑器历史或备份中取回用户内容，不能凭模型记忆重写。
对 Codex 接入项目，验收标准应包括“原有未提交文件仍存在”“目标文件只出现任务相关差异”“未读取或输出密钥”“没有修改工作区外目录”。如果发现边界不清，宁可把任务拆成只读分析和受控修改两轮。AI 自动化办公也遵循同样原则：先识别输入资料，再生成结果，不要把原始附件覆盖成模型输出。
实际验收时还要关注“同名文件被重新生成”的情况。很多静态站点会由脚本输出 index.html，如果脚本模板旧于用户手动修复的版本，重新生成就会悄悄覆盖标题、统计脚本或 canonical。遇到这种文件，应先比较生成来源和现有页面，再决定是改模板还是只改当日目录。
检查清单
开始前是否保存了 status、diff 或哈希基线；是否列出原有改动文件；是否写明允许修改路径；是否使用最小补丁；是否在中途检查状态；是否对比起始和结束差异；是否保留用户修改；是否检查编码、密钥和临时文件；是否写明未完成事项。满足这些条件，Codex 才真正成为可控的开发者 AI 调用工具，而不是一个会替你重置工作区的黑盒。