分类： AI 开发 & 工具
-
记录将 wordpress-ai-translation-pipeline 从私有 GitHub 仓库切换为公共仓库的完整过程，包括敏感信息审计、生产环境信息与认证凭证的风险区分、双仓库方案取舍、MIT License 与第三方许可证说明补充、自动化测试、代码提交以及仓库可见性切换。最终在未重写 Git 历史、未删除标签、未强制推送的前提下，以最小改动完成公开发布。
-
在 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 资源和版本兼容性问题。
-
在持续优化 WordPress 中文技术文章英文翻译流程后，我将相关定制代码、测试脚本、问题分析和生产验证记录整理到 GitHub 私有仓库 wordpress-ai-translation-pipeline。本文记录了仓库创建、本地目录改名、远程绑定、main 分支与标签推送、路径修正、敏感信息审计以及 .gitignore 完善过程。GitHub 的引入让翻译优化工作从临时排查转向可追踪、可回退、可长期维护的工程流程，也标志着本阶段翻译质量优化工作告一段落。
-
在使用 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 适合承担已经明确的代码分析与部署任务，但是否修改某个插件、是否接受新方案、是否存在功能重复，仍需要人工判断。
-
本文记录了在 WordPress、Polylang 与 SlyTranslate 环境下，为 GLM 5.2 整篇翻译流程增加 Plaintext 智能判断的完整优化过程。通过结构占位、区块顺序校验、Code Block Pro 原样保护、最终正文精确写回及 SHA-256 校验，实现了自然语言 Plaintext 可翻译、URL 和代码保持不变，同时修复了 Gutenberg 编辑器中的无效区块提示。文章还记录了英文文章分类、系列与标签因多域名对象缓存未及时失效而未能在前台正确显示的问题。
-
在暂缓 OpenAI API 测试后，我改为在本地调用 Google Gemini，并使用与 GLM 5.2 相同的标题、摘要和正文样本进行 A/B 对比。测试发现，Gemini 3.5 Flash 的英文表达略显自然，但存在响应波动、技术语义扩展以及正文标题残留中文等问题；Gemini 3.1 Pro Preview 则因免费层级额度为 0，无法完成测试。综合翻译准确性、Gutenberg 结构完整性、接口稳定性、服务器网络和维护成本后，现阶段继续使用 GLM 5.2 作为 SlyTranslate 的生产翻译模型。
-
随着 AutoPoly、SlyTranslate、GLM 5.2、DeepSeek 等翻译测试不断积累，相关 ChatGPT 会话也逐渐分散。本文记录了为英文博客翻译质量优化创建独立 ChatGPT 项目的过程，包括“仅项目”与“默认”记忆模式的区别、历史会话迁移限制、项目指令配置，以及核心测试会话的整理方法。目前 DeepSeek 已完成对比测试，其翻译质量不如 GLM 5.2；下一阶段将考虑在本地测试 OpenAI，并评估质量提升是否足以支撑后续部署成本。