适用场景
这篇适合 Codex 在远程容器、Windows 本地目录、服务器工作目录之间协作时使用。典型表现是本地看到文件已改，线上页面还是旧版本；远程工作区测试通过，本机 diff 却没有变化；或者同步脚本上传了整个目录，却遗漏了数据库首页内容。前一天如果刚做过变更基线，可以先对照 Codex 改代码前要留什么基线，再回头查今天的路径。
永沃云枢在 https://ai.jn83.com 持续整理 Codex 接入、AI API 接入、AI 模型接口、CCSwitch 配置、开发者 AI 调用和模型调用管理经验。本篇不是讲某个同步工具，而是把“文件到底在哪个目录被改了”先查清楚。
先把三类路径写清楚
第一类是 Codex 当前工作目录，第二类是本地仓库目录，第三类是线上服务读取的目录。不要只看文件名相同就认为是同一份文件。静态 SEO 页面常见路径是本地 seo 目录、远程 /opt/sub2api/seo、容器内挂载目录三层，任意一层没同步都会导致验收错位。
操作时让 Codex 输出 pwd、目标文件绝对路径、修改时间和文件哈希。Windows 上还要注意大小写、盘符和符号链接；Linux 服务器上要注意容器卷挂载和反向代理实际根目录。这个动作和 Codex 同时看多个仓库时怎么定边界 的思路一致，先定边界再谈修改。
操作步骤
第一步，列出本次应改文件清单，按“文章页、栏目页、sitemap、robots、首页 SQL、外发稿、推送 URL”分组。第二步，在每个文件写入后立即读取前几行和关键标题，确认内容不是旧模板。第三步，运行同步脚本前检查它的上传范围，不要让 Codex 只改了本地，却把旧的远程目录重新覆盖回来。
第四步，线上验证要绕过缓存。请求 URL 后加时间戳参数，并检查标题、slug、canonical、JSON-LD 和正文中的关键句。第五步，数据库首页内容单独验收，因为它不一定随静态文件上传。首页卡片应能看到最新 4 篇文章，不能只在 Codex 实操与 AI 资讯栏目页 中出现。
如果任务还包含 AI API 接入或 CCSwitch 配置，最好把配置文件和内容文件分开验收。配置文件需要确认生效进程，内容文件需要确认页面响应。两者混在一起排查时，很容易把代理、缓存和文件不同步都叫作“部署没成功”。
常见问题和避坑
第一个坑是只看 git diff，不看生成物。静态页面、站点地图和首页 SQL 可能由脚本生成，脚本没跑或跑错日期时，diff 很干净但线上不会更新。第二个坑是同步脚本成功不等于服务读取成功，反向代理、容器卷和缓存都可能还在读旧文件。
第三个坑是把远程测试结果写进本地验收。Codex 在远程工作区跑通后，如果本地仓库没有同样改动，下一次部署会回退。第四个坑是中文编码只在本地浏览器正常，线上响应头或文件实际字节不对。静态页面乱码排查可以参考 Codex 生成静态 SEO 页面后中文乱码怎么办。
检查清单
- 是否记录 Codex 当前工作目录、本地仓库目录和远程发布目录。
- 是否确认 4 类核心文件：文章页、栏目页、sitemap、首页内容。
- 是否检查同步脚本上传范围和远程目标路径。
- 是否用线上 200 响应、标题、slug 和正文关键句做验收。
- 是否保留回滚点和本次 publish URL 清单。
合格的验收结论不应只写“已同步”，而应能说明哪个文件从哪个路径同步到哪个路径，并给出线上可访问证据。后续在 https://ai.jn83.com 做 Codex 接入或 AI 自动化办公页面维护时，这份记录能减少重复排查。
复盘补充：把同步证据写成一张小表
实际执行时，可以把证据表放在任务记录末尾：第一列写本地文件，第二列写远程文件，第三列写线上 URL，第四列写验证方式。比如文章页看标题和 canonical，栏目页看最新 4 篇排序，sitemap 看 loc 和 lastmod，首页看卡片标题和 slug。这样下一次 Codex 继续维护时，不需要重新猜哪些文件属于发布链路。
还有一个细节是区分“已上传”和“已生效”。上传成功只说明文件到了服务器，已生效还要看服务是否重新加载、缓存是否命中旧版本、数据库首页是否应用了新 SQL。把这两个状态拆开写，排查会更快，也能避免把搜索引擎没有抓取误判成页面没有发布。