在排查 SlyTranslate、智谱 GLM-5.2、Polylang、PublishPress Series 和 W3 Total Cache 之间的兼容问题时，我最初一直使用一种比较传统的协作方式：
- ChatGPT 给出一组命令；
- 我复制到服务器执行；
- 将输出复制回浏览器；
- ChatGPT 根据结果再给出下一组命令；
- 继续重复。
对于单个、明确的小问题，这种方式没有太大问题。
但当排查范围逐渐涉及以下内容时，效率开始明显下降：
- WordPress 插件源码；
- 自定义 MU Plugin；
- Gutenberg 保护 Token；
- Polylang 分类、标签和文章关联；
- PublishPress Series 生命周期；
- W3TC Object Cache；
- Redis 中按 Host 隔离的对象缓存；
- W3TC Page Cache；
- Cloudflare 与 EdgeOne；
- 本地 Git 项目；
- 生产服务器部署与回滚。
随着会话越来越长，浏览器开始频繁提示页面卡顿。每次复制数十行甚至上百行 Shell、PHP 和诊断结果，不但效率低，也容易把当前真正需要处理的目标带偏。
这次实际排查中，我开始将更适合自动执行的工作交给 Codex，并逐渐形成了一套更适合 WordPress 生产环境的协作方式。
本文记录的重点不是如何使用某一个具体模型，而是：
如何让 Codex 承担源码读取、差异比较、测试、部署和验证工作，同时保留人工对生产风险、修改范围和最终方案的控制。
一、为什么普通对话式排查开始变得低效
这次排查最初的目标，是解决 SlyTranslate 调用 GLM-5.2 翻译 WordPress 长文章时出现的数据同步问题。
实际问题包括：
- 英文分类没有正确关联；
- 英文标签缺失；
- PublishPress Series 没有关联；
- Series 部分编号错误；
- 特色图片没有迁移；
- GLM 修改了 Gutenberg 保护 Token；
- 英文前台读取到旧的对象缓存；
- 中文文章语言切换器没有及时出现。
如果每次只检查一个值，命令可能很短。
例如：
get_post_meta(19519, "_series_part_38462", true)
但真正需要判断问题时，往往要同时比较：
数据库原始值
admin Host 下的 WordPress 运行时值
www Host 下的运行时值
en Host 下的运行时值
W3TC Page Cache 中的 HTML
Cloudflare 或 EdgeOne 返回的公网 HTML
单独复制一条命令并不困难，困难的是需要不断重复以下流程：
提出假设
↓
生成命令
↓
人工复制
↓
执行
↓
复制输出
↓
重新解释
↓
生成下一组命令
当一次排查持续数小时后，浏览器会话本身也开始成为负担。
二、哪些工作更适合交给 Codex
这次实践中，我发现以下工作特别适合交给 Codex：
- 读取本地 Git 项目；
- 通过 SSH 读取生产服务器文件；
- 比较本地候选文件与生产文件；
- 搜索指定 Hook、函数和缓存组；
- 运行 PHP 语法检查；
- 执行定向测试；
- 输出最小 Diff；
- 计算 SHA256；
- 生成精确部署命令；
- 部署前备份；
- 原子替换生产文件；
- 部署后验证版本与文件哈希；
- 清理只针对一个文章 ID 的缓存；
- 删除尚未部署的错误候选文件。
不适合直接交给 Codex自行决定的内容包括：
- 是否应该修改翻译插件还是缓存插件；
- 是否应该接受某种架构方向；
- 是否允许修改数据库；
- 是否允许全站清缓存；
- 一个测试结果是否足以代表长期方案；
- 当前应该继续排查，还是暂时保留问题；
- 是否应该部署一个新的 MU Plugin。
也就是说，Codex 适合执行和验证，但生产架构方向仍然需要人工控制。
三、为 Codex 提供明确的工作边界
如果只对 Codex 说：
帮我修复这个 WordPress Bug
它可能会提出范围过大的方案，例如：
- 新增另一个 MU Plugin；
- 修改多个现有文件；
- 清理整个 Redis；
- 执行 W3TC Purge All；
- 同时处理 Page Cache 和 CDN；
- 修改数据库中的文章关系。
在生产网站中，这种模糊任务风险很高。
这次逐渐形成的指令结构通常包括以下部分：
目标
已确认事实
允许读取的文件
允许修改的文件
禁止修改的内容
测试要求
部署要求
回滚要求
最终报告格式
例如，在修复特色图片迁移问题时，任务被限定为：
只修复英文译文未迁移特色图片的问题。
允许：
- 修改自定义 GLM 翻译 MU Plugin；
- 使用 set_post_thumbnail()；
- 为现有测试文章补上特色图片。
禁止：
- 修改正文；
- 修改文章状态；
- 修改分类、标签和 Series；
- 修改 Polylang 关系；
- 清理缓存；
- 修改 SlyTranslate 插件源码。
这种限制让 Codex 更容易生成范围较小、可以验证和回滚的补丁。
四、先只读分析，再允许写操作
在生产环境中，我没有让 Codex 一开始就修改文件。
更稳妥的流程是：
第一阶段：只读分析
↓
第二阶段：查看 Diff 和测试结果
↓
第三阶段：人工批准
↓
第四阶段：部署
↓
第五阶段：验证
例如，GLM-5.2 在翻译文章时返回了以下错误：
{
"code": "swq_full_article_token_validation_failed",
"message": "Protected token validation failed: expected=628, actual=627, fixed_order=no. Diagnostic: /tmp/swq-glm52-token-validation-summary.json",
"data": null
}
Codex 首先只读检查：
- 诊断文件；
- 原始文章内容；
- 保护 Token 列表；
- GLM 返回 Token；
- 校验函数；
- 令牌恢复函数。
最终定位到：
预期：
SWQSTRUCT000018END
实际：
SWQSTRUCT00018END
也就是 GLM 将连续前导零压缩了一个。
在这个阶段，Codex 没有修改任何文件，也没有重新调用 GLM API。
五、让 Codex 输出最小 Diff，而不是直接覆盖文件
定位问题后，下一步不是立即部署，而是先查看最小修改内容。
这次 Token 修复的核心方案是：
在严格校验前增加一次有限规范化。
仅当畸形 Token：
- 只能唯一对应一个缺失 Token；
- 类型相同；
- 数字值相同；
- 不存在重复或歧义；
- 修复后顺序仍正确；
才允许补回完整 Token。
之后继续执行原有严格校验。
测试结果包括：
PASS: zero contraction is repaired
PASS: correct token remains unchanged
PASS: ambiguous candidates fail
PASS: duplicate token fails
PASS: wrong fixed order fails
这比简单地放宽正则或跳过校验安全得多。
Codex 同时给出：
- 文件版本变化；
- 最小 Diff；
- PHP 语法检查；
- 单元测试结果；
- 候选文件 SHA256；
- 精确部署命令；
- 回滚方法。
六、使用 SHA256 防止部署错误文件
本次部署中，候选文件和生产文件都使用 SHA256 进行确认。
例如：
候选 SHA256：
405eb681ae8e71c2a0e3148361ea2ec53f61dbaacf84f5b287876aa98da8a22c
部署前会同时验证：
- 当前生产文件是否仍是预期旧版本；
- 上传到服务器的临时文件是否与本地候选一致；
- PHP 语法是否通过；
- 权限和所有者是否与原文件一致。
典型流程为：
本地候选文件
↓
上传到临时路径
↓
验证候选 SHA256
↓
PHP 语法检查
↓
备份生产文件
↓
继承原文件权限
↓
原子替换
↓
再次验证生产 SHA256
这样可以避免以下问题：
- 本地文件后来被意外修改；
- 上传不完整；
- 覆盖错文件；
- 部署时生产文件已经被其他操作修改；
- 权限错误导致 WordPress 无法加载 MU Plugin。
七、生产文件使用临时路径和原子替换
本次没有直接将文件覆盖到最终路径。
而是先上传到：
wp-content/mu-plugins/.swq-glm52-translation-tuning-2026.07.17.15.deploy.tmp
验证完成后，再使用 mv 替换正式文件：
mv -f "$STAGE" "$MU"
在同一文件系统中，mv 可以减少 WordPress 请求读取到半写入 PHP 文件的风险。
正式替换前还会备份原文件，例如：
/root/swq-glm52-translation-tuning-20260717-xxxxxx.php
如果部署后出现问题，可以快速恢复备份文件。
这比直接使用编辑器在生产文件中逐行修改更容易控制。
八、Codex 也可以执行精确的现有数据修复
修复特色图片迁移 Bug 后，还需要为已经生成的英文文章补上特色图片。
只读检查结果为：
中文文章：19429
特色图片 attachment：19437
英文文章：19522
特色图片：空
Codex 部署新版本后，只调用新增的特色图片同步方法处理这一对文章。
同时记录修复前后的：
- 文章状态；
- 正文 Hash；
- 分类；
- 标签；
- Series；
- Polylang 关系。
验证逻辑为：
目标特色图片应变为 19437
其他数据必须完全不变
实际检查包括：
source_thumbnail=19437
target_thumbnail=19437
unrelated_data_unchanged=yes
这种验证方式比只查看后台是否出现图片更可靠，因为它同时证明了补图操作没有误改文章其他数据。
九、不是 Codex 提出的每个方案都应该部署
这次排查中，Codex 曾根据跨 Host Object Cache 问题生成一个新的候选 MU Plugin：
swq-cross-host-publish-cache-invalidation.php
该候选方案准备在文章发布后，通过带 HMAC 的 Loopback 请求清理目标 Host 的对象缓存。
从实现角度看，这个方案有完整的：
- Host 白名单；
- Timestamp；
- HMAC-SHA256；
- Nonce；
- 防重放；
- 发布 Hook；
- Shutdown 延迟执行。
但在准备部署前，我重新考虑了当前已有环境。
网站此前已经存在一个用于处理 W3TC 与 Polylang 多域名缓存的 MU Plugin。继续新增另一个跨 Host 插件，可能造成：
- 功能重复；
- Hook 重复触发；
- 缓存清理范围重叠；
- 后续难以判断哪个插件真正生效；
- 故障时回滚路径变复杂。
因此最终没有部署这个新插件。
Codex 随后删除了本地两个未部署候选文件：
patch/swq-cross-host-publish-cache-invalidation.php
patch/cross-host-publish-cache-tests.php
生产环境没有发生对应修改。
这个过程说明：
Codex 能够快速生成技术上可行的实现，但是否符合现有架构，仍然需要人工判断。
十、使用 Codex 时仍需防止任务目标漂移
这次排查过程中也出现过目标漂移。
例如，原本希望尽快完成：
- 分类；
- 标签；
- Series；
- 特色图片；
- 新文章完整验证。
但在处理某篇中文文章语言切换器时，任务一度被拆分成：
- 只修中文语言切换器；
- 单独处理英文 Series；
- 再检查面包屑；
- 再考虑 Yoast 主分类。
这些问题虽然都是真实问题，但并不是当时最优先的目标。
当浏览器已经卡顿、会话很长时，如果继续为每个局部现象生成新的长指令，反而会降低整体效率。
后来重新明确目标：
先让新英文文章完整生成并正常发布，再把中文语言切换器和跨 Host 缓存作为后续独立任务。
这次经验说明，使用 Codex 不仅要限定文件和命令范围，还要限定业务目标。
十一、一次性批准比每个步骤反复确认更高效
Codex 在执行服务器写操作前，会先展示完整命令并等待批准。
这里通常不一定会出现单独的图形按钮，直接在对话中回复：
批准执行。
即可继续。
为了避免反复确认，我通常要求：
写操作前只展示一次完整命令并等待批准。
批准后一次完成备份、部署、验证和必要的数据修复。
不要每一个小步骤再次等待。
这样既保留了生产写操作前的人工确认，也避免每个 cp、mv、php -l 都单独询问。
十二、Codex 与普通 ChatGPT 对话的分工
经过这次实践，我逐渐形成了以下分工。
ChatGPT 更适合
- 梳理现象；
- 判断优先级；
- 区分翻译 Bug、缓存 Bug 和插件生命周期问题；
- 决定是否应该继续修改；
- 设计验证标准；
- 整理博客和阶段结论；
- 阻止范围过大的方案。
Codex 更适合
- 读取代码；
- 搜索 Hook；
- 比较文件；
- 运行测试；
- 输出 Diff；
- 管理本地 Git；
- 通过 SSH 验证生产环境；
- 生成和执行部署命令；
- 检查 SHA256；
- 完成精确修复；
- 删除未采用的候选文件。
这两者不是相互替代，而是适合不同阶段。
十三、适合 WordPress 生产环境的 Codex 工作流
结合本次实际过程，可以整理出以下工作流。
1. 明确一个具体问题
例如：
英文译文没有特色图片
而不是：
英文文章不正常
2. 提供已确认事实
例如：
中文文章 ID：19429
英文文章 ID：19522
中文特色图片 ID：19437
英文特色图片：空
3. 限定允许修改的文件
例如：
只允许修改：
swq-glm52-translation-tuning.php
4. 明确禁止项
例如：
禁止修改数据库
禁止清理 Redis
禁止修改 SlyTranslate 源码
禁止修改分类、标签和 Series
5. 先只读分析
要求 Codex 先输出：
- 根因；
- 修改位置；
- 最小 Diff；
- 测试计划。
6. 运行测试
至少包括：
- PHP 语法；
- 正常场景；
- 异常场景；
- 不应被覆盖的数据；
- 回归测试。
7. 校验候选文件
记录：
- 版本号；
- SHA256；
- Git 状态。
8. 部署前备份
备份到明确路径，并记录实际文件名。
9. 原子替换
先上传临时文件，再替换正式文件。
10. 部署后立即验证
确认：
- 文件版本；
- SHA256；
- WordPress 是否正常加载；
- 目标文章数据；
- 未关联数据是否保持不变。
11. 准备回滚
回滚命令必须在部署前就明确，而不是出错后临时编写。
十四、这次实际提升了哪些效率
使用 Codex 后，最明显的变化并不是“命令变少了”，而是人工复制工作明显减少。
以前需要手动完成：
复制命令
执行
复制输出
回到浏览器
继续生成命令
改用 Codex 后，可以在一次任务中完成：
读取代码
↓
远程读取生产环境
↓
定位问题
↓
生成补丁
↓
运行测试
↓
展示 Diff
↓
等待批准
↓
部署
↓
验证
↓
报告结果
人工主要负责：
- 给出目标；
- 审查方案；
- 批准写操作；
- 判断最终结果是否符合业务预期。
对于涉及多个文件、多个 Host 和生产部署的 WordPress 问题，这种方式更加适合。
十五、需要注意的风险
Codex 并不能自动保证所有方案都是正确的。
这次实际出现过以下风险：
- 方案范围扩大；
- 重复创建缓存插件；
- 将缓存问题错误地塞进翻译插件；
- 只修复当前文章，没有覆盖未来流程；
- 过度关注局部页面，而偏离分类、标签和 Series 的主目标；
- 自动化测试通过，但架构上可能与现有插件重复。
因此，使用 Codex 时仍然需要遵守：
一次只解决一个明确问题
先读后写
最小修改
生产部署前备份
部署后立即验证
始终保留回滚路径
十六、本次最终完成的工作
通过 ChatGPT 与 Codex 配合，本轮实际完成了：
- 将新英文译文由自动发布改为草稿；
- 修复分类关系迁移；
- 修复标签关系迁移；
- 修复 PublishPress Series 关系迁移；
- 恢复草稿发布时的 Series 自动编号；
- 修复 GLM 压缩保护 Token 前导零的问题；
- 增加严格且有限的 Token 规范化；
- 修复特色图片迁移；
- 为已有英文文章补齐特色图片；
- 精确修复单篇英文文章的 Object Cache 和 Page Cache；
- 撤销未采用的跨 Host 缓存插件候选方案；
- 保留现有生产插件和数据库不受额外影响。
其中，中文文章语言切换器和多 Host Object Cache 的长期兼容问题仍然保留为后续任务，没有为了“全部解决”继续扩大修改范围。
十七、阶段性结论
Codex 最有价值的地方，并不是代替人工做技术判断，而是将已经明确的技术任务执行得更完整。
在 WordPress 生产环境中，它尤其适合：
- 代码分析；
- 小范围补丁；
- 测试；
- 文件校验；
- 部署；
- 回滚；
- 精确验证。
但以下决定仍然需要人工完成：
- 当前最重要的问题是什么；
- 修改应该属于哪个插件；
- 是否存在功能重复；
- 是否值得部署；
- 是否应当暂缓某个问题；
- 是否已经达到可以上线的标准。
这次实践后，我更倾向于采用以下协作方式：
ChatGPT 帮助判断方向和整理证据
↓
Codex 完成代码、测试和部署
↓
人工审查修改范围并批准
↓
生产环境立即验证
对于长时间、跨多个缓存层和插件的 WordPress 排查，这种方式比不断在浏览器和终端之间复制命令更加高效，也更容易保留完整的审查和回滚记录。
需要长期技术维护或远程问题排查？
我是拥有 15+ 年经验的 PHP / Go 后端工程师，长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。
如果你的项目遇到以下情况，可以先从一次小问题排查开始合作：
- ✅ PHP / Laravel / Yii2 老项目无人维护
- ✅ Go / Gin 后端接口需要排查或优化
- ✅ WordPress 网站访问慢、报错或插件冲突
- ✅ Nginx / MySQL / Redis / Linux 服务器异常
- ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
- ✅ 需要长期远程技术支持或兼职维护
更多介绍请查看：关于我 & 合作
微信：13980074657
邮箱：shuijingwanwq@gmail.com
Telegram：@shuijingwan
GitHub：https://github.com/shuijingwan
发表回复