月度归档： 2026 年 7 月
-
从历史文章摘要为空、文章列表重复显示 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 个。本文记录完整排查过程，并总结多语言数据维护脚本在缓存、运行上下文、统计验证和幂等性方面的实践经验。
-
将 media、en 和 admin 拆出 EdgeOne 后，我使用 BOCE、中国成都移动宽带和 WebPageTest，对中文站、英文站及媒体图片进行了实际性能测试。结果显示，中文站继续使用 EdgeOne 后，在中国大陆和海外均保持良好性能；英文站通过 Cloudflare 在新加坡和美国的首屏表现稳定，但中国大陆移动、联通线路访问明显较慢；media 图片资源是当前架构中波动最明显的部分。综合成本、性能与后台稳定性来看，现有分层架构仍值得保留，但需要继续关注 Cloudflare 在中国大陆线路中的稳定性及图片对 LCP 的影响。
-
EdgeOne 个人版每月包含 50GB 安全加速流量和 300 万次安全加速请求。套餐启用几天后，我根据实际消耗速度判断，现有额度无法支撑完整计费周期，因此陆续将 media、en 和 admin 三个域名迁出 EdgeOne，只保留中文主站 www。本文根据迁移前后的真实流量与请求数据，按加量包实际消耗比例估算月度成本。结果显示，当前过渡周期预计成本约为 26.2 元；拆分完成后的稳定月度成本约为 22.2 元；如果三个域名都未迁出，月度成本约为 49.6 元。此次拆分预计可将 EdgeOne 长期成本降低约 55%，每月节省约 27.4 元。
-
在使用 SlyTranslate 调用 GLM 5.2 进行 WordPress 整篇文章翻译时，模型重复生成了相邻段落，导致同一个 SWQINLINE 占位符出现两次，并触发 swq_full_article_token_validation_failed。排查确认严格 Token 校验器工作正常，问题并非响应截断或插件逻辑错误。通过完善全文翻译提示词，进一步约束段落唯一性、占位符格式、六位编号及前导零保留后，文章 19445 重新翻译成功。现阶段继续采用“提示词降低错误概率、占位符保护结构、严格校验阻止错误结果”的方案。
-
在排查 SlyTranslate、GLM-5.2、Polylang、PublishPress Series 与 W3 Total Cache 之间的兼容问题时，传统的“生成命令—手动执行—复制结果—继续分析”方式逐渐变得低效，长时间会话也开始造成浏览器卡顿。本文结合真实的 WordPress 生产环境修复过程，记录如何将源码读取、Hook 定位、最小 Diff、PHP 测试、SHA256 校验、文件备份、原子部署、现有数据修复和回滚验证交给 Codex 执行，同时由人工控制修改范围、架构方向和生产风险。实践表明，Codex 适合承担已经明确的代码分析与部署任务，但是否修改某个插件、是否接受新方案、是否存在功能重复，仍需要人工判断。
-
在完成 SlyTranslate 与智谱 GLM-5.2 的 WordPress 长文章整篇翻译定制后，英文正文虽然能够正常生成，但实际发布流程仍出现分类、标签、PublishPress Series、Series 部分编号和特色图片未正确迁移等问题。本文根据真实测试过程，记录如何将新英文译文由自动发布调整为草稿，利用 Polylang 将中文 Taxonomy 关系迁移到已建立的英文分类、标签和 Series，并让 PublishPress Series 在人工发布时自动生成顺序编号。同时还修复了 GLM 压缩保护 Token 前导零以及英文特色图片缺失的问题。最终，新英文草稿已经能够保留 Gutenberg 结构，并自动关联正确的分类、标签、Series 和特色图片。中文语言切换器及多域名 Object Cache 失效问题则留待后续单独处理。
-
本文记录了在 WordPress、Polylang 与 SlyTranslate 环境下，为 GLM 5.2 整篇翻译流程增加 Plaintext 智能判断的完整优化过程。通过结构占位、区块顺序校验、Code Block Pro 原样保护、最终正文精确写回及 SHA-256 校验，实现了自然语言 Plaintext 可翻译、URL 和代码保持不变，同时修复了 Gutenberg 编辑器中的无效区块提示。文章还记录了英文文章分类、系列与标签因多域名对象缓存未及时失效而未能在前台正确显示的问题。