![[截图 2：浏览器 Network 中直接请求 translate.yandex.net]](https://media.shuijingwanwq.com/2026/07/2-16-1024x568.png)
过去一段时间，我一直在优化 WordPress 中文技术文章的英文翻译流程。
最开始只是希望改善 SlyTranslate 的英文翻译质量，后来逐步涉及：
- GLM 5.2 整篇文章翻译；
- Gutenberg 区块结构保护；
- 代码块和行内代码占位；
- HTML 属性与图片
alt文本处理； - 占位符重复、遗漏和碰撞检测；
- 分类、标签、系列和特色图片同步；
- W3 Total Cache 与 Polylang 缓存兼容；
- 生产环境部署与回退验证；
- GLM、DeepSeek、Gemini、OpenAI 等模型的对比测试。
随着定制代码、测试脚本、问题分析和生产验证记录不断增加，原来的临时调试目录已经不适合继续承担长期维护任务。
这一次，我将整个项目整理后提交到了 GitHub 私有仓库。对当前阶段来说，这不仅是一次代码备份，也可以算作这一轮翻译质量优化工作的阶段性收尾。
一、为什么需要建立 GitHub 仓库
之前的项目目录名称是：
slytranslate-glm52-taxonomy-debug-2026-07-16
这个名称非常适合作为一次临时排查工作区，因为它明确记录了：
- 使用的翻译插件；
- 当前模型；
- 正在排查的分类同步问题；
- 项目建立日期。
但随着问题逐渐解决，项目内容已经不再局限于 GLM 5.2 或分类同步。
现在的代码实际上覆盖了一个更完整的 WordPress AI 翻译流程，包括翻译请求、内容保护、结果验证、分类同步和生产部署。继续沿用原来的临时目录名称，很容易让人误以为它只是一次已经结束的故障排查。
因此，我最终将仓库命名为：
wordpress-ai-translation-pipeline
本地目录也同步调整为：
/home/wangqiang/code/wordpress-ai-translation-pipeline
这个名称没有绑定某一个模型，也没有绑定具体日期。以后即使从 GLM 5.2 切换到 OpenAI、DeepSeek 或其他模型，也不需要再次更改项目名称。
二、为什么最终选择私有仓库
最初我考虑过将项目设置为公共仓库。
为了判断是否适合公开，我让 Codex 对整个 Git 仓库进行了一次只读敏感信息审计。审计范围包括：
- 当前工作区中的全部已跟踪文件；
- 未跟踪和忽略文件；
- 全部可达 Git 提交；
- 历史 Blob；
- 分支和标签；
- 提交作者信息；
- 图片、配置、文档和测试文件。
审计结果显示，仓库中没有发现：
- API Key；
- 阿里云 AccessKey；
- GitHub Token；
- SSH 私钥；
- 数据库密码；
- WordPress Salt；
- Cookie 或 Session；
- 真实公网 IP；
- 数据库备份和 SQL 文件。
从凭证安全角度看，结果是比较理想的。
但是，仓库中仍然包含一些真实的生产环境上下文，例如：
- 生产域名；
- WordPress 服务器目录；
- SSH 别名；
- 本地工作区路径；
- 真实文章、分类和系列 ID；
- 生产检查命令；
- 从已安装插件中收集的源码和验证材料。
这些内容并不等同于密码，也不能直接获得服务器权限，但如果要建立公共仓库，就需要进一步考虑：
- 是否脱敏历史提交；
- 是否重写全部 Git 历史；
- 第三方插件源码是否允许重新分发；
- 插件 Logo、翻译文件和宣传图片的许可证；
- 哪些文件应该改为补丁而不是完整源码。
继续处理这些问题并不是不可以，但对当前目标来说，维护成本已经明显偏高。
我的主要需求只是：
- 保存项目代码；
- 记录修改历史；
- 方便 Codex 持续维护；
- 明确生产环境对应的提交版本；
- 在出现新问题时能够快速比较和回退。
因此，最终选择私有仓库更加符合实际需要。
wordpress-ai-translation-pipeline 私有 GitHub 仓库三、创建空仓库，避免首次推送冲突
由于本地仓库已经包含：
main分支；- 10 多个历史提交；
- 4 个已有标签；
- 完整的本地 Git 历史；
所以在 GitHub 创建仓库时，我没有勾选：
Add a README file
Add .gitignore
Choose a license
GitHub 端保持为空，可以避免本地仓库首次推送时，因为远程存在一个额外初始化提交而产生分支冲突。
仓库创建完成后，在本地确认当前状态：
cd /home/wangqiang/code/wordpress-ai-translation-pipeline
git status --short --branch
git branch --show-current
git remote -v
当时的结果为：
## main
main
git remote -v 没有输出，说明本地仓库尚未绑定远程地址。
四、统一本地目录和 GitHub 仓库名称
在绑定远程仓库之前，我先将旧目录改名：
cd /home/wangqiang/code
mv \
slytranslate-glm52-taxonomy-debug-2026-07-16 \
wordpress-ai-translation-pipeline
然后进入新目录检查：
cd /home/wangqiang/code/wordpress-ai-translation-pipeline
pwd
git status --short --branch
git remote -v
输出为：
/home/wangqiang/code/wordpress-ai-translation-pipeline
## main
目录改名不会改变 Git 提交、标签或分支，因为 .git 目录仍然跟随项目一起移动。
不过，VS Code 和 Codex 原来打开的是旧工作区，因此目录改名后，还需要重新打开：
/home/wangqiang/code/wordpress-ai-translation-pipeline
五、绑定 GitHub 远程仓库
本地目录确认无误后，添加远程仓库：
git remote add origin https://github.com/用户名/wordpress-ai-translation-pipeline.git
git remote -v
检查结果应类似：
origin https://github.com/用户名/wordpress-ai-translation-pipeline.git (fetch)
origin https://github.com/用户名/wordpress-ai-translation-pipeline.git (push)
这一步只建立了远程关联，并没有上传任何内容。
六、首次推送 main 分支
接下来推送本地 main 分支：
git push -u origin main
首次推送共写入了 663 个对象，数据量约为 2.62 MiB。
推送完成后，本地 main 自动开始跟踪：
origin/main
这意味着以后在当前分支执行普通的 git push 和 git pull 时，Git 已经知道对应的远程分支。
main 分支首次推送到 GitHub 成功七、继续推送已有标签
除了提交历史，仓库中还存在 4 个标签：
analysis-baseline-2026-07-17
draft-only-candidate-2026-07-17
installed-baseline-2026-07-17
installed-series-baseline-2026-07-17
这些标签分别用于记录：
- 分析基线；
- 仅保存为草稿的候选版本；
- 生产安装源码基线；
- PublishPress Series 安装源码基线。
标签不会随着普通的分支推送自动全部上传，因此又单独执行：
git push origin --tags
4 个标签均成功创建到 GitHub 远程仓库。
八、验证本地和远程提交是否一致
首次推送完成后，我没有只根据命令返回的“成功”判断，而是再次执行了同步检查：
git fetch --prune --tags origin
git status --short --branch
echo "本地 main："
git rev-parse main
echo "远程 main："
git rev-parse origin/main
echo "标签："
git tag --list
当时本地和远程 main 得到完全相同的提交哈希：
d365b57244542989e2205f9a94eeb283d052f0eb
同时，4 个标签也都能够在本地正常列出。
这一步证明：
- 本地提交已经完整上传；
- 远程分支与本地没有差异；
- 标签没有遗漏；
- 当前工作区没有待提交修改。
main、远程 origin/main 和标签一致性检查九、修正仓库改名后遗留的旧路径
虽然目录已经改名，但项目文档中仍有 3 处引用旧工作区名称。
我使用精确搜索进行检查：
git grep -nF 'slytranslate-glm52-taxonomy-debug-2026-07-16' -- . \
|| echo "未发现旧目录名称引用"
结果显示，evidence/installed-sources.md 中仍记录了：
- 旧工作区路径；
- 旧 SlyTranslate 源码保存路径；
- 旧 MU Plugin 保存路径。
这些内容不是安全问题，但已经与当前目录不一致，因此将它们统一替换为：
wordpress-ai-translation-pipeline
修改完成后创建提交：
e29a3a9 docs: update workspace path after repository rename
并再次推送到 GitHub。
十、完善 .gitignore
仓库建立完成后，还有一个重要的收尾工作：完善 .gitignore。
原来的 .gitignore 只有：
/tmp/
/.agents/
/.codex/
*.log
*.tmp
这对于临时调试仓库基本够用，但作为长期维护项目，覆盖范围明显不足。
新的 .gitignore 增加了以下类别：
- 编辑器和系统文件；
.env和本地配置；wp-config.php；- 密钥和证书；
- 数据库导出文件；
- 日志和 API 原始响应；
- 备份文件；
- 编辑器临时文件；
- 压缩包；
- Python 运行文件和虚拟环境。
例如：
# Environment and local configuration
.env
.env.*
!.env.example
wp-config.php
wp-config-*.php
credentials.json
secrets.json
.secrets/
# Private keys and certificates
*.pem
*.key
*.p12
*.pfx
*.crt
*.cer
# Database dumps
*.sql
*.sql.gz
*.dump
*.sqlite
*.sqlite3
# Backups and temporary files
*.bak
*.bak-*
*.backup
*.orig
*.old
*.save
*.swp
*.swo
*~
*.tmp
这并不能替代人工审计，但可以降低以后误提交敏感配置、日志和备份文件的概率。
十一、取消跟踪三个历史备份文件
敏感信息审计还发现，仓库中存在三个已经被 Git 跟踪的备份文件：
TranslationValidator.php.bak-20260715-093756
TranslationValidator.php.bak-restore-original-20260715-101725
TranslationValidator.php.bak-runaway-ratio-2026-07-14-134954
这些文件本身没有发现凭证，但继续跟踪存在两个问题：
- 增加源码审计和比较范围；
- Codex 后续可能误判哪个文件才是当前有效版本。
因此，我使用 git rm --cached 将它们从 Git 索引中移除，同时保留本地文件。
提交后，Git 显示：
delete mode 100644
这里的 delete mode 只表示它们从 Git 仓库当前版本中删除，并不代表本地磁盘上的文件被删除。
随后又进行了验证：
git check-ignore -v 文件路径
三个文件均由以下规则匹配：
*.bak-*
同时，本地文件仍然存在。
本次修改形成提交：
32fd767 chore: expand gitignore and untrack backup files
.gitignore 正确忽略十二、为什么这可以算作阶段性收尾
这一次提交 GitHub，并不意味着 WordPress AI 翻译流程已经永远不需要修改。
未来仍然可能出现：
- 新的 Gutenberg 区块兼容问题；
- 新的占位符碰撞场景；
- 长文章输出不稳定；
- 模型接口发生变化；
- SlyTranslate 升级后内部接口变化；
- Polylang、PublishPress Series 或 W3 Total Cache 的兼容问题；
- OpenAI 或其他模型带来更好的翻译结果。
但与最初相比，现在已经建立了比较清晰的基础：
- 代码不再只保存在某个临时目录；
- 每次修复都有明确提交；
- 生产版本可以对应到具体 Commit；
- 关键分析节点通过标签保存；
- 本地目录与远程仓库名称统一；
- GitHub 保存完整历史；
.gitignore已覆盖常见敏感文件和运行产物；- 生产环境仍然坚持明确授权后再部署。
因此，这次工作更像是从“不断试错和临时修复”，进入了“可以长期维护和逐步迭代”的阶段。
十三、后续工作方式
后续比较适合继续采用以下流程：
发现翻译或同步问题
→ 在本地仓库中定位
→ Codex 修改代码
→ 离线验证
→ 检查 Git diff
→ 创建提交
→ 推送 GitHub
→ 明确授权后部署生产
→ 验证生产结果
GitHub 在这里并不负责自动部署，也不直接决定生产环境修改。
它主要承担的是：
- 代码版本管理；
- 修复记录保存；
- 变更审查；
- 稳定版本定位；
- 回退依据；
- 多个工作区之间的同步。
对于当前仍在持续调整的翻译系统，这种相对保守的方式，比直接配置 GitHub Actions 自动部署更稳妥。
十四、阶段总结
这一轮 WordPress 英文翻译质量优化，从最开始的模型选择，逐步扩展到了内容结构保护、占位符校验、分类同步、缓存问题和生产部署管理。
很多问题并不是简单修改一段提示词就能解决，而是需要模型、插件、WordPress 内容结构和缓存系统共同配合。
将项目提交到 GitHub 后，这些修改终于从一组分散的调试结果，变成了一个有历史、有版本、有边界的长期项目。
当前仓库仍然是私有仓库，也没有启用自动部署。对现阶段来说，这已经足够。
接下来没有必要继续为了理论上的小幅提升，不断扩大代码复杂度。更合理的方式是先让当前方案稳定运行，在真实文章翻译中继续观察，再根据明确出现的问题逐项修复。
从这个角度看，这次 GitHub 仓库初始化，确实可以看作这一阶段翻译质量优化工作的正式收尾。
需要长期技术维护或远程问题排查？
我是拥有 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
发表回复