日期: 2026年7月20日
-
在 VS Code 中打开新项目并使用 Codex 时，右侧面板持续停留在加载状态，随后变成灰色空白页面。排查确认 Codex CLI、账号登录和本地扩展文件均正常，真正的异常集中在 VS Code Webview 资源加载层，大量本地 JavaScript 模块出现 insufficient resources 和 net::ERR_FAILED。清理 Service Worker、Cache、Code Cache、CachedData、GPUCache，重新安装及回退 Codex 扩展版本后，问题仍未解决。最终暂时改用 Codex CLI 推进项目，等待官方后续修复。
-
为了让 Codex 能够在完成代码修改、离线测试和 Git commit 后直接推送到 GitHub，我在 Ubuntu 中安装并配置了 GitHub CLI。通过 gh auth login 完成浏览器设备授权和两步验证后，再使用 gh auth setup-git 将 GitHub CLI 配置为 Git 的 HTTPS 凭据助手。最终，Codex 成功将本地提交推送到 GitHub，并验证本地 HEAD 与 origin/main 完全一致。本文记录了完整配置过程、安全边界，以及自动推送与生产部署之间需要保持的明确区分。
-
在将本地翻译项目目录重命名后，VS Code 中的 Codex 聊天窗口一直停留在加载状态。排查过程中，通过重新打开工作区、查看 Codex 输出日志和 VS Code 开发人员工具，确认 Codex 后端能够正常启动，但 Webview 中的多个 JavaScript 模块出现 net::ERR_FAILED，主入口模块也无法完成动态加载。最终将 VS Code 从 1.127.0 升级到 1.129.1 后，Codex 恢复正常。本文记录完整排查过程，并说明如何区分项目路径、扩展后端、Webview 资源和版本兼容性问题。
-
从历史文章摘要为空、文章列表重复显示 Post Views 以及 Yoast SEO 元描述不够准确的问题出发，我逐步梳理了 WordPress AI 翻译工程的下一阶段计划。后续将先盘点经典编辑器、SyntaxHighlighter Evolved、Gutenberg 和 Code Block Pro 等历史内容格式，再使用 GLM-4.7 小规模测试并批量补齐中文 post_excerpt，随后重新覆盖翻译历史英文文章。整个流程将通过 Codex 与 GitHub 管理，并持续评估不同模型的翻译质量、稳定性、速度、API 成本及部署可行性。
-
随着“WP 博客多语言化实操”系列文章增至 38 篇，我将其中以 AI 模型评测、翻译质量优化、代码保护和自动化流程为主的内容，拆分到新系列“WordPress AI 翻译工程实战”。本次共迁移 16 篇中文文章及对应的 16 篇英文文章，并确认通过文章列表按发布时间依次快速编辑后，PublishPress Series 会自动从 1 开始连续排序，无需手动调整。迁移完成后，还清理了 www 与 en 域名下的 W3 Total Cache 页面缓存和对象缓存。
-
在持续优化 WordPress 中文技术文章英文翻译流程后，我将相关定制代码、测试脚本、问题分析和生产验证记录整理到 GitHub 私有仓库 wordpress-ai-translation-pipeline。本文记录了仓库创建、本地目录改名、远程绑定、main 分支与标签推送、路径修正、敏感信息审计以及 .gitignore 完善过程。GitHub 的引入让翻译优化工作从临时排查转向可追踪、可回退、可长期维护的工程流程，也标志着本阶段翻译质量优化工作告一段落。
-
一份用于同步 Polylang 中英文标签的批处理脚本，长期存在 WordPress 后台标签总数与脚本读取结果不一致的问题。此前两次排查分别修复了 Polylang 翻译关系缓存残留和动态分页导致的数据集变化，但问题仍会复发。最终通过对比 WP-CLI 与直接 PHP 执行环境，确认根因是 get_terms() 命中了持久化的旧 WP_Term_Query 查询缓存。脚本在源标签查询中加入 ‘cache_results’ => false 后，终于从旧的 8915 个标签恢复为正确的 8928 个。本文记录完整排查过程，并总结多语言数据维护脚本在缓存、运行上下文、统计验证和幂等性方面的实践经验。