Codex 修改配置文件时怎么只改必要差异？
Codex 很适合帮团队维护配置，但配置文件的风险不在“能不能改”，而在它是否重排了键、删掉注释、覆盖默认值或顺手改了无关字段。处理 YAML、JSON、env 和站点配置时，最重要的是差异边界。
适用场景：配置文件比业务代码更容易误伤
配置文件常常同时服务多个入口：开发者 AI 调用要读模型名，AI 自动化办公要读任务开关，CCSwitch 配置要读 Base URL 和 profile，站点首页还可能读同一个 JSON 或环境变量。一次看似简单的格式化，可能让注释丢失、键顺序变化，甚至触发默认值覆盖。历史上很多事故不是因为参数写错，而是因为工具把未提交字段清空。
因此，Codex 接入配置维护时，应先把“允许修改什么”写成白名单。比如只允许改 ai_api.timeout_ms，不允许重排 providers；只允许新增一个 model alias，不允许改默认 profile；只允许更新首页资讯卡片，不允许碰注册、邮件和站名。
操作步骤：先基线，再最小 diff
第一步，保存当前基线，用只读命令列出目标文件和关键字段：rg "timeout_ms|base_url|model|profile|home_content" .。第二步，让 Codex 说明计划修改的字段、原因和验收方式。计划里必须有“不修改项”，例如不动 Key、不动注册开关、不动支付配置。第三步，编辑时优先使用结构化解析器；如果文件含注释或特殊顺序，不能简单读成对象再整体序列化，因为很多 JSON/YAML 工具会删除注释或重排键。
第四步，看 diff，而不是只看页面是否能跑。diff 里如果出现大量空格、换行或排序变化，应退回并改用局部编辑。第五步，针对 AI API 接入做一次样本请求，针对 CCSwitch 配置做一次 profile 命中检查，针对 AI 自动化办公做一次 dry-run，确认行为和预期一致。
排错路径：发现多余差异先停下来
如果 diff 里出现无关字段，先判断是不是格式化造成的。若只是行尾变化，也要避免提交，因为下一次审计会看不清真正改动。若出现默认值被写入，说明编辑工具可能做了全量保存。若注释消失，说明解析方式不适合这个文件。此时不要继续叠加修改，应该回到基线，改用更小的补丁。
模型调用管理配置还要额外检查优先级。env、命令行参数、用户 profile、服务端配置可能同时存在。修改一个文件不代表最终生效，验收必须打印最终读取值。Codex 可以帮助列出配置来源，但最终是否改动全局配置，应由维护者确认。
常见问题/避坑
不要把“格式化顺手做了”当作小事。配置 diff 一旦膨胀，回滚和复盘都会困难。不要把注释删除，因为注释里常写着供应商限制、成本提醒和上线前提。不要把敏感 Key 放进文章、截图或日志。不要让 Codex 为了通过测试而改动更大的默认配置，这类修复短期有效，长期难查。
检查清单：交付前看边界是否干净
检查这些项：目标文件在白名单内；diff 只包含必要字段；注释和顺序没有无关变化；禁改字段未出现；AI 模型接口样本请求成功；CCSwitch profile 命中正确；AI 自动化办公 dry-run 没有写入真实数据；日志不含敏感 Key；回滚步骤写清楚；站内说明链接到 Codex 安装专题、AI API 接入专题、CCSwitch 配置专题 和 AI 自动化办公专题。
配置变更的质量，取决于它能不能被复查。只改必要差异，比一次性“整理漂亮”更适合生产维护。
验收样本：配置变更必须能解释给后来的人
建议在每次配置改动旁边留一份短记录，写清修改前值、修改后值、触发原因、影响入口和回滚方式。比如 AI API 接入只改 timeout，就说明它影响哪个接口、失败表现是什么、样本请求如何验证；CCSwitch 配置只改 profile，就说明哪些开发者 AI 调用会命中新 profile，哪些后台任务保持不变。
如果配置文件服务 AI 自动化办公，还要用 dry-run 证明不会写入真实业务数据。若 Codex 生成的 diff 里出现大段排序变化，应先停止交付，重新用局部编辑生成补丁。好的配置变更不是看起来整齐，而是后来的人打开 diff 时，能在三分钟内看懂为什么改、改了哪里、没有改哪里。
遇到多环境配置时，还要把开发、测试、预发、正式分开验收。Codex 可以先生成对照表，列出每个环境的配置来源、是否允许修改、验收命令和负责人。只有目标环境的字段发生变化，其他环境保持原样，才算真正符合最小差异原则。
如果必须迁移配置格式，建议拆成两次提交：第一次只做无行为变化的格式迁移，第二次再改业务字段。把格式变化和功能变化混在一起，会让 AI 模型接口、CCSwitch 配置和自动化任务的回归问题很难定位。