![[截图 2：浏览器 Network 中直接请求 translate.yandex.net]](https://media.shuijingwanwq.com/2026/07/2-16-1024x568.png)
此前，我已经围绕 SlyTranslate 对 WordPress 中文技术文章的英文翻译流程做了多轮调整。
目前使用的生产方案是：
- SlyTranslate
- 智谱 GLM 5.2
- 自定义 MU 插件
- Gutenberg 区块与代码内容占位保护
- 标题、摘要和正文分别调用
- 正文尽量以整篇方式翻译，而不是拆成大量小段
在前一轮测试中，DeepSeek 的整体翻译质量没有超过 GLM 5.2，因此我暂时结束了 DeepSeek 方向。
接下来原本打算测试 OpenAI，但实际操作后发现，OpenAI API 与 ChatGPT Plus 是两套独立的计费系统。我目前使用的第三方订阅平台 WildAI 也明确回复：不支持 OpenAI API 充值，页面中的 Codex Credit 也不能作为通用 OpenAI API 额度。
因此，我暂时停止了 OpenAI 测试，改为先测试 SlyTranslate Connector 列表中同样支持的 Google Gemini。
这篇文章记录本次 Gemini API 本地测试、与 GLM 5.2 的翻译质量对比，以及最终为什么仍然保留 GLM 5.2 作为当前生产方案。
一、为什么先在本地测试 Gemini
我的 WordPress 生产服务器位于阿里云杭州。
此前在服务器上测试 Google 相关接口时，已经遇到过网络连接问题。因此，即使 Gemini 的翻译质量更高，也不能直接认定它适合作为生产方案。
这一轮测试只回答三个问题：
- Gemini 的英文翻译质量是否明显高于 GLM 5.2；
- Gemini 能否稳定保留 Gutenberg、HTML、域名和技术术语；
- 它的调用速度和成功率是否适合长文章翻译。
只有前三项表现明显更好，后续才值得继续研究杭州服务器的网络和部署问题。
为了避免一开始就把测试复杂化，这一轮没有安装 Google Connector，也没有直接进入 SlyTranslate，而是先通过本地脚本调用 Gemini API。
二、创建 Gemini API Key
我在 Google AI Studio 中创建了一个 Gemini API Key。
当前项目使用免费层级，不需要先绑定付费账户。
创建完成后，我先调用模型列表接口，确认当前项目能够看到哪些支持 generateContent 的模型。
本地返回的模型中包括：
gemini-2.5-flash
gemini-2.5-pro
gemini-3-flash-preview
gemini-3-pro-preview
gemini-3.1-flash-lite
gemini-3.1-pro-preview
gemini-3.5-flash
gemini-flash-latest
gemini-pro-latest
不过后续测试证明：
模型出现在
models.list返回结果中，并不代表当前项目一定拥有实际调用额度。
模型列表只能作为候选范围，最终仍然要通过真实的 generateContent 请求确认。
三、第一次调用 Gemini 3.5 Flash
第一轮我选择了：
gemini-3.5-flash
第一次请求返回：
UNAVAILABLE
This model is currently experiencing high demand.
这说明 API Key 和本地网络基本正常，但当时模型容量不足。
之后我又尝试了：
gemini-2.5-flash
虽然它仍然出现在模型列表中，但实际请求返回：
NOT_FOUND
This model models/gemini-2.5-flash is no longer available to new users.
Please update your code to use a newer model.
因此，本次项目不能继续使用 Gemini 2.5 Flash。
重新调用 Gemini 3.5 Flash 后，请求最终成功，得到的译文为：
In a multi-domain WordPress environment, even if the database has been updated, Redis Object Cache may still return stale objects. Therefore, you first need to confirm whether the cache keys are isolated by Host.
这段译文的技术含义和英文表达都没有明显问题。
四、一个容易忽略的 curl 重试问题
测试过程中还遇到了一个与 Gemini 本身无关的问题。
最初使用了：
curl --retry 4
当请求多次失败后再成功时，curl 可能会把前几次失败响应和最终成功响应连续输出。
变量中实际保存的内容可能类似：
{"error": {"code": 503}}
{"error": {"code": 503}}
{"candidates": [...]}
这不是一个合法的单一 JSON 文档，因此 Python 解析时会报错：
Extra data
解决方法是在 curl 中增加：
--fail
例如：
curl -sS \
--fail \
--retry 4 \
--retry-delay 8 \
...
这样，HTTP 错误响应不会继续写入标准输出，变量中只会保留最终成功的 JSON。
这个细节以后在测试其他支持重试的 API 时也值得注意。
五、建立相同条件的 A/B 测试
确认 Gemini API 可以调用后，我没有重新设计一套测试材料，而是直接复用了此前 GLM 5.2 与 DeepSeek 对比时的测试输入。
测试内容包括：
- 标题
- 摘要
- 正文片段
两组模型使用完全相同的：
- 中文原文
- 翻译提示词
- 字段顺序
- 最大输出 Token 上限
- 非流式请求
模型参数分别为：
GLM 5.2
do_sample=false
thinking={"type":"disabled"}
Gemini 3.5 Flash
temperature=0
thinkingLevel=minimal
需要说明的是，两个厂商的参数不能完全一一对应。
GLM 5.2 可以明确关闭思考，而 Gemini 的 minimal 只能理解为尽量减少思考消耗，不能简单视为完全相同的模式。
六、GLM 5.2 与 Gemini 3.5 Flash 的测试结果
本轮测试结果如下：
| 字段 | GLM 5.2 | Gemini 3.5 Flash |
|---|---|---|
| 标题 | 2.10 秒，1 次成功 | 24.97 秒，2 次成功 |
| 摘要 | 4.24 秒，1 次成功 | 57.68 秒，2 次成功 |
| 正文 | 9.11 秒，1 次成功 | 7.17 秒，1 次成功 |
GLM 三个字段都在第一次请求时成功。
Gemini 的正文速度比 GLM 更快，但标题和摘要第一次请求均失败，重试后才成功。
这说明 Gemini 并不是单纯地“速度更慢”。
它的问题主要是调用时间波动较大：
- 有时正文请求很快；
- 有时很短的标题也需要等待二十多秒；
- 摘要请求甚至接近一分钟。
对于偶尔手动调用，这种波动可能还能接受。
但在 SlyTranslate 中翻译一篇长文章时，标题、摘要、正文和其他字段可能需要连续发起多次请求。只要其中一个请求遇到容量不足，就可能导致超时或整次翻译中断。
七、标题对比
GLM 5.2 返回的标题是：
WordPress Polylang: Fixing Links That Still Point to the Chinese Site After English Subdomain Migration — Category Dropdown, Breadcrumbs, and Block Templates
Gemini 3.5 Flash 返回的是：
How to Fix WordPress Polylang Links Still Pointing to the Chinese Site After Migrating to an English Subdomain: Resolving Category Dropdowns, Breadcrumbs, and Block Templates
Gemini 的标题更接近英文教程文章常见的写法，使用了：
How to Fix...
整体读起来更自然。
不过它也明显更长：
- GLM：157 个字符
- Gemini：174 个字符
对于搜索结果标题和 WordPress 文章标题而言，Gemini 的版本略显冗长。
GLM 的版本更紧凑，也更接近我个人技术博客一贯克制、直接的风格。
八、摘要对比
Gemini 的摘要使用了：
This article documents the troubleshooting and resolution of an issue…
这类表达在英文技术文章中比较自然，整体组织也比 GLM 稍微流畅。
但是，Gemini 同样倾向于扩写：
- GLM 摘要：665 个字符
- Gemini 摘要：721 个字符
Gemini 的英文自然度略好，但它会把原本较直接的中文技术说明调整得更加正式。
这种处理方式并不一定错误，但容易让个人博客看起来更像经过统一包装的技术文档。
目前我的目标不是追求最正式的英文，而是在保持技术准确性的前提下，尽量接近人工重译，同时保留个人博客的真实感。
从这个角度看，GLM 的风格反而更贴近当前需求。
九、正文中的技术准确性差异
Gemini 在正文中写道：
the browser did not load the English category page, but instead redirected to:
这里使用了：
redirected to
但中文原文只是描述浏览器进入了错误地址，并没有确认服务端发生了 301 或 302 重定向。
在技术文章中，redirected 往往带有比较明确的 HTTP 重定向含义。
GLM 使用的是：
went to
或者：
did not visit the English category page
虽然表达没有 Gemini 那么精致，但没有额外推断具体的重定向机制。
这类差异看起来很小，却是技术翻译中非常重要的一点：
自然度不能以牺牲技术边界为代价。
十、Gemini 出现了中文标题残留
这轮测试中最明显的问题不是速度，而是结构内容完整性。
Gemini 返回的正文中，二级标题仍然保留为中文：
<!-- wp:heading -->
<h2 class="wp-block-heading">一、当前多域名结构</h2>
<!-- /wp:heading -->
GLM 5.2 则正常翻译为：
<!-- wp:heading -->
<h2 class="wp-block-heading">1. Current Multi-Domain Structure</h2>
<!-- /wp:heading -->
Gemini 正确保留了：
- Gutenberg 注释
- HTML 标签
class属性- 区块顺序
但标题中的自然语言没有被翻译。
这属于典型的“结构保留成功，但内容翻译遗漏”。
对于普通聊天翻译，这可能只是一个很小的问题。
但对于 SlyTranslate 的自动生产流程，正文中残留中文意味着文章不能直接发布，仍然需要人工逐段检查。
而当前优化自动翻译流程的核心目标，正是尽量减少这种人工审校成本。
十一、继续测试 Gemini 3.1 Pro Preview
考虑到 Flash 更偏向速度与成本，我又尝试了质量定位更高的：
gemini-3.1-pro-preview
测试仍然使用与 GLM 5.2 完全相同的标题、摘要和正文输入。
结果三个字段全部失败：
| 字段 | HTTP | 尝试次数 | 最终译文 |
|---|---|---|---|
| 标题 | 429 | 5 | 无 |
| 摘要 | 429 | 5 | 无 |
| 正文 | 429 | 5 | 无 |
因此，这一轮没有获得任何可以用于质量比较的 Gemini Pro 译文。
十二、429 不是普通的请求频率限制
进一步查看 Gemini 返回的原始错误后，原因非常明确：
Quota exceeded for metric:
generativelanguage.googleapis.com/generate_content_free_tier_input_token_count
limit: 0
model: gemini-3.1-pro
同时，请求次数额度也是：
limit: 0
model: gemini-3.1-pro
这意味着：
当前免费层级对 Gemini 3.1 Pro Preview 的请求额度和输入 Token 额度都是 0。
错误响应虽然提示稍后重试，但在额度本身为 0 的情况下，等待几十秒或者反复重试都没有意义。
只有启用 Google Cloud 付费结算后，才可能继续测试 Gemini 3.1 Pro Preview。
十三、为什么没有继续开通 Google 付费测试
从纯粹的模型评测角度看，继续测试 Gemini Pro 当然有价值。
但当前目标并不是收集尽可能多的模型结果，而是建立一个稳定、简单、可长期运行的 WordPress 翻译流程。
目前已经存在几个现实问题：
- Gemini 3.5 Flash 的自然度略好，但没有明显拉开差距；
- Gemini 出现了中文标题残留；
- API 请求稳定性弱于 GLM 5.2；
- Gemini Pro 需要先开通付费结算；
- 生产服务器位于阿里云杭州，访问 Google API 仍然存在网络问题；
- 即使本地测试质量更高，后续部署仍需要增加网络和运维复杂度。
为了测试一个尚未证明能够明显提升质量的模型，提前引入付款、网络代理和生产服务器改造，投入与收益并不匹配。
因此，本轮没有继续开通 Google 付费服务，也没有安装 Google Connector。
十四、当前阶段的最终结论
经过这轮测试，可以得到以下结论。
Gemini 3.5 Flash
优点：
- 英文表达略微更自然；
- 标题和摘要更接近常见英文技术文章风格；
- 正文单次请求速度有时很快；
- Gutenberg 与 HTML 主体结构基本能够保留。
问题：
- 标题和摘要请求均出现过重试；
- 响应时间波动明显；
- 会对原文作轻微扩写；
- 使用
redirected等词时可能扩大原文技术含义； - 正文中出现了未翻译的中文标题。
Gemini 3.1 Pro Preview
当前免费层级额度为 0，无法获得任何译文，因此暂时不能判断实际翻译质量。
GLM 5.2
GLM 的英文不一定在每个句子上都比 Gemini 更自然，但整体表现更加均衡：
- 技术边界更谨慎；
- 风格更克制；
- Gutenberg 结构保留更稳定；
- 本轮三个字段均生成完整译文；
- 大多数请求速度稳定；
- 已经能够在当前 SlyTranslate 和自定义 MU 插件流程中运行；
- 更适合部署在当前阿里云杭州生产环境。
十五、现阶段继续保留 GLM 5.2
这轮测试结束后，我没有把 Gemini 接入 SlyTranslate。
当前生产方案继续使用：
SlyTranslate
+
GLM 5.2
+
自定义 Gutenberg 与代码占位保护
+
整篇正文翻译
这并不意味着 Gemini 的英文能力一定低于 GLM。
更准确地说：
在当前 WordPress 技术博客、阿里云杭州服务器和低人工维护成本的约束下，Gemini 暂时没有表现出足够明显的综合优势。
未来如果 Google API 的付款、网络访问和模型额度条件发生变化，仍然可以重新测试 Gemini Pro。
但就现阶段而言，继续使用已经验证稳定的 GLM 5.2，比为了理论上的少量自然度提升引入更多复杂性更合适。
总结
这次测试最重要的收获并不是简单判断哪个模型“英文更好”。
真正需要比较的是：
- 技术准确性
- 英文自然度
- Gutenberg 结构完整性
- 长文章稳定性
- 请求速度
- 失败重试
- API 成本
- 服务器网络
- 后续维护成本
Gemini 3.5 Flash 在部分英文表达上略有优势，但出现了结构内容遗漏和请求波动。
Gemini 3.1 Pro Preview 在免费层级下完全没有可用额度。
综合考虑后，GLM 5.2 仍然是当前更适合长期生产的选择。
这次 Google 测试可以暂时告一段落。
需要长期技术维护或远程问题排查？
我是拥有 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