![[截图 2：浏览器 Network 中直接请求 translate.yandex.net]](https://media.shuijingwanwq.com/2026/07/2-16-1024x568.png)
最近一段时间，我一直在优化 WordPress 中文技术文章的英文翻译流程。
这套流程已经不再只是简单调用大模型，而是逐渐加入了不少站点专用逻辑，例如：
- 使用 SlyTranslate 作为翻译入口；
- 使用智谱 GLM 处理整篇文章；
- 保留 Gutenberg 区块结构；
- 保护代码块、短代码、HTML、URL 和文件路径；
- 校验占位符是否完整；
- 同步 Polylang 中英文文章关系；
- 修复英文特色图片附件和
alt文本； - 增加自动化测试和生产验证记录。
此前，我已经将这些代码和排查记录整理到了一个私有 GitHub 仓库：
wordpress-ai-translation-pipeline
随着翻译流程逐渐稳定，我开始考虑是否可以把这个仓库切换为公共仓库，既作为阶段性归档，也方便其他使用 WordPress、Polylang 和 AI 翻译工具的人参考。
不过，真正执行之前，我还是先进行了一次完整的敏感信息审计。
一、为什么没有直接把仓库改成 Public
将 GitHub 仓库从 Private 切换为 Public，本身只需要一个命令。
真正需要考虑的是：仓库公开后，不只是当前文件可以被访问，Git 提交历史、标签以及已经删除的旧文件也可能被恢复。
因此，这次审计覆盖了：
- 当前工作区；
- 所有已跟踪文件；
- 未跟踪和被忽略文件；
- 全部 Git 提交历史；
- 全部标签；
- 历史中已经删除的文件；
- 提交消息；
- 第三方插件源码；
- GitHub 仓库元数据；
- 常见 API Key、Token、Cookie、Nonce、密码和私钥格式。
审计时，仓库共有 524 个已跟踪文件，工作区处于干净状态。
审计最终没有发现以下内容：
- API Key；
- GitHub Token；
- OpenAI、智谱、DeepSeek 等模型服务密钥；
- 阿里云、Cloudflare、EdgeOne 认证信息；
- SSH 私钥；
- 数据库用户名和密码；
- WordPress salts；
- Cookie；
WP_ADMIN_COOKIE；WP_REST_NONCE；- Authorization Header；
- OAuth client secret；
- webhook secret。
也就是说，仓库中没有发现能够直接获得系统访问权限的认证信息。
二、第一次审计结论有些过于保守
虽然没有发现实际凭证，但第一次审计仍然给出了比较谨慎的结论：
当前仓库不适合直接公开，建议新建脱敏公共仓库。
主要原因包括：
- Git 历史中存在真实生产目录；
- 存在
ssh aliyun这样的 SSH 别名； - 保存了真实域名、文章 ID、附件 ID；
- 包含生产部署和排查命令；
- 保存了 SlyTranslate 和 PublishPress Series 的安装态源码；
- 还没有 README、LICENSE 和第三方许可证说明。
从严格的企业安全审计角度看，这样的判断并没有问题。
但结合我的实际情况，我认为这个标准有些过高。
例如：
ssh aliyun
这里只是我本地 ~/.ssh/config 中定义的别名。
仓库中没有对应的服务器 IP、密码或私钥。其他人在自己的电脑上执行这个命令，也无法连接到我的服务器。
同样，下面这样的服务器目录：
/data/wwwroot/www.shuijingwanwq.com
以及真实域名、文章 ID、附件 ID，本身也不是认证信息。
这些内容在我的技术博客中已经大量公开，用于说明真实的排查过程。为了切换公共仓库而全部替换成 example.com 或虚构 ID，不但工作量很大，也会降低排查记录的真实性。
安全不能依赖隐藏一个 SSH 别名、WordPress 路径或文章 ID。
真正需要保护的，仍然是：
- 密钥；
- 密码；
- Cookie；
- Nonce；
- 私钥；
- 数据库导出；
- 可以直接获得系统权限的认证值。
本次审计没有发现这些内容，因此我决定不再进行大规模脱敏，也不创建第二个公共仓库。
三、为什么没有采用“双仓库”方案
最初考虑过保留现有私有仓库，再新建一个脱敏公共仓库。
结构大致如下：
私有仓库
↓ 单向导出
公共仓库
这种方式从安全隔离角度看比较清晰，但也会带来新的维护问题：
- 哪个仓库才是权威版本；
- 私有仓库修改后，公共仓库是否及时同步；
- 公共仓库收到 Pull Request 后如何反向合并；
- 导出脚本是否遗漏文件；
- 两个仓库是否会逐渐分叉；
- 每次发布是否都要重复进行脱敏。
即使设计成单向镜像，仍然需要长期维护一套导出机制。
当前这个仓库本身规模不大，且没有发现实际凭证。为了理论上的风险降低，再引入第二个仓库和同步脚本，反而不符合我一直坚持的原则：
不要为了小幅提升，引入大量额外代码、复杂流程和长期维护成本。
因此，最终决定继续使用现有仓库，只做公开前最必要的补充。
四、最终采用的最小改动方案
最后确定的方案很简单：
- 保留现有仓库和全部 Git 历史；
- 不删除真实域名、目录和文章 ID；
- 不删除第三方源码快照；
- 不执行
git filter-repo； - 不重写提交历史；
- 不删除或重建标签；
- 不强制推送；
- 新增 README；
- 新增 MIT License；
- 新增第三方许可证说明；
- 再进行一次实际凭证扫描；
- 测试通过后直接切换为 Public。
这次只新增了三个文件：
README.md
LICENSE
THIRD_PARTY_NOTICES.md
没有修改任何 PHP、JavaScript、Shell、测试或生产配置代码。
五、README 如何说明仓库定位
新增的 README.md 采用中文为主、英文简要说明的结构。
README 中明确说明，这不是一个可以安装后直接适配所有 WordPress 网站的通用插件，而是一套来源于真实生产环境的站点专用实现。
仓库主要记录：
- SlyTranslate 调用流程；
- GLM 翻译质量优化；
- Gutenberg 区块保护；
- HTML 和占位符处理；
- 代码块、URL 和路径保护；
- Polylang 文章及媒体关系；
- 英文特色图片与
alt同步； - 自动化测试；
- 生产验证和问题排查记录。
README 还对主要目录进行了说明：
swq-glm52-translation-tuning.php
当前站点使用的 MU 插件调优实现。
sources/
保存部分已安装第三方插件的源码快照，用于差异分析和复现。
patch/
保存补丁、测试和验证工具。
archive/
保存历史候选版本或未发布方案。
evidence/
保存真实生产排查和部署证据。
README 中也明确提醒：
- 使用前应在测试环境验证；
- 不要提交真实 API Key；
- 不要提交 Cookie 和 Nonce；
- 不要提交
wp-config.php； - 不要提交数据库密码或数据库导出；
- 仓库中的真实域名、目录和文章 ID不等同于认证凭证。
六、原创代码采用 MIT License
我最终选择为原创内容使用 MIT License。
版权行如下：
Copyright (c) 2026 Qiang Wang
MIT License 对使用限制很少，其他人可以：
- 使用；
- 复制；
- 修改；
- 合并；
- 发布；
- 分发；
- 再授权；
- 商业使用。
对我来说，这个仓库的主要价值是记录真实的技术实现和排查过程。
别人拿去参考、修改，甚至用于自己的商业项目，我都可以接受，因此没有必要选择限制更多的许可证。
七、第三方代码不能简单统一声明为 MIT
仓库中还保存了两个第三方插件的安装态源码：
sources/slytranslate-installed/
sources/publishpress-series-installed/
它们并不是我的原创代码，因此不能因为仓库根目录增加了 MIT License，就把这些第三方文件重新授权为 MIT。
为此，新增了：
THIRD_PARTY_NOTICES.md
其中记录了当前识别到的第三方项目和许可证。
SlyTranslate
仓库中保存的版本为：
SlyTranslate 1.9.0
插件头信息包括：
Author: Timon Först
License: MIT
PublishPress Series
仓库中保存的版本为：
PublishPress Series Free 3.1.2
插件头声明为：
GPLv3
部分代码注释中同时提到了：
GPLv2 or later
这次没有自行解释两种声明之间的关系，只是在第三方通知中如实记录。
vendor、翻译文件、图片及其他 bundled 组件，继续遵循各自原有许可证。
顶层 MIT License 只适用于我有权授权的原创代码和文档，不会覆盖或替代第三方组件自身的许可证。
八、公开前再次扫描实际凭证
新增文档后，又执行了一次最终凭证扫描。
这次仍然覆盖：
- 当前完整工作树；
- 全部 Git 历史；
- 全部标签；
- 提交消息。
重点扫描：
- 私钥头；
- 常见 GitHub Token；
- OpenAI、智谱、DeepSeek 等 API Key；
- Authorization Bearer；
- Authorization Basic；
- Cookie；
- 数据库密码；
- WordPress salts；
- Nonce；
- OAuth client secret；
- webhook secret；
- URL 中嵌入的用户名和密码。
最终结果仍然是零命中。
这次扫描不再把以下内容当作秘密：
- 域名；
- 服务器目录；
- SSH 别名；
- 文章 ID；
- 附件 ID；
- SHA-256；
- 不包含认证值的部署命令。
这种分类更符合我的实际使用场景，也避免了把“生产环境信息”和“认证凭证”混为一谈。
九、公开前运行 62 项测试
虽然本次只增加了文档，没有修改代码，但在提交之前，仍然运行了现有的特色图片同步测试：
bash patch/run-featured-image-tests.sh
测试结果：
62 tests, 0 failures
Featured-image tests passed
PHP 语法检查和 Git diff 检查也全部通过。
这一步主要是为了确认，公开仓库准备过程没有意外修改现有代码，也没有破坏此前完成的特色图片附件和英文 alt 同步逻辑。
十、提交并推送公开仓库文档
本次提交信息为：
docs: 增加公共仓库说明与 MIT 许可证
完整提交哈希：
585b41873c3c81d14eca236935337d860a13079b
该提交只包含三个新增文件，共 127 行：
README.md
LICENSE
THIRD_PARTY_NOTICES.md
推送结果：
52d9b94..585b418 main -> main
本次使用普通推送：
git push origin main
没有强制推送，也没有重写任何历史。
十一、使用 GitHub CLI 切换仓库可见性
原计划执行：
gh repo edit shuijingwan/wordpress-ai-translation-pipeline \
--visibility public \
--accept-visibility-change-consequences
但当前安装的 gh 版本并不支持：
--accept-visibility-change-consequences
第一次执行在参数解析阶段直接失败，因此没有对仓库产生任何修改。
随后使用当前版本支持的命令：
gh repo edit shuijingwan/wordpress-ai-translation-pipeline \
--visibility public
执行成功后，再次读取仓库状态：
{
"visibility": "PUBLIC",
"isPrivate": false,
"defaultBranchRef": {
"name": "main"
}
}
GitHub 也已经识别到许可证：
MIT License
key: mit
十二、最终公开地址
仓库现在已经正式公开：
https://github.com/shuijingwan/wordpress-ai-translation-pipeline
最终状态：
## main...origin/main
工作区干净，本地分支与远程分支一致。
本次没有进行以下操作：
- 没有重写 Git 历史；
- 没有删除或重建标签；
- 没有强制推送；
- 没有删除第三方源码；
- 没有替换真实域名和路径；
- 没有修改现有代码；
- 没有访问生产服务器；
- 没有修改数据库；
- 没有重新执行文章翻译；
- 没有进行生产部署。
十三、这次公开过程中最重要的判断
这次经历让我重新区分了两类经常被混在一起的信息。
第一类是环境信息：
- 域名；
- 文件路径；
- SSH 别名；
- 文章 ID；
- 附件 ID；
- 插件目录；
- 部署步骤。
第二类是认证信息：
- API Key；
- 密码；
- 私钥；
- Cookie；
- Nonce；
- Access Token；
- 数据库凭证。
环境信息可能帮助别人理解服务器结构，但不能直接提供访问权限。
认证信息则可能直接导致系统被访问，必须严格避免进入 Git 仓库。
如果把所有生产环境细节都当作秘密，最终往往需要大量脱敏、历史重写、双仓库同步和额外维护流程。对于一个以真实技术实践为主要内容的个人项目来说，这种成本未必值得。
更合适的做法是：
重点保护真正能够获得系统权限的认证信息，同时接受真实技术记录中存在域名、路径和资源 ID。
十四、阶段性总结
这个仓库最初只是为了保存 SlyTranslate 和 GLM 翻译优化代码，后来逐渐加入了：
- 整篇翻译；
- Gutenberg 结构保护；
- 占位符校验；
- 代码块保护；
- 英文摘要处理；
- Polylang 映射；
- 英文特色图片附件；
alt同步；- 自动化测试；
- 生产排查证据。
将仓库从私有切换为公共，也算是这轮 WordPress AI 翻译质量优化工作的又一次阶段性收尾。
最终方案没有追求理论上的最高安全隔离，而是在确认不存在实际凭证后，只补充了必要的 README、MIT License 和第三方声明。
没有建立第二个仓库，没有维护同步脚本，也没有重写历史。
对我来说，这种做法更简单、更稳定，也更适合长期维护。
需要长期技术维护或远程问题排查？
我是拥有 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
发表回复