![[截图 2：浏览器 Network 中直接请求 translate.yandex.net]](https://media.shuijingwanwq.com/2026/07/2-16.png)
![[截图 2：浏览器 Network 中直接请求 translate.yandex.net]](https://media.shuijingwanwq.com/2026/07/2-16-1024x568.png)
最近我一直在测试 WordPress 多语言文章的自动翻译流程。
目前我的博客使用的是：
WordPress
Polylang
AutoPoly - AI Translation For Polylang
我之前已经用 AutoPoly 免费版做过一些测试。它可以比较稳定地完成这些事情：
创建英文文章
保留 Polylang 关联
保留 Gutenberg 区块结构
保留图片、链接、代码块
不会明显破坏 WordPress 文章结构
从“创建英文副本”和“保留结构”的角度看，AutoPoly 免费版是可用的。
但是，真正的问题在于：
AutoPoly 免费版使用 Yandex Translate 后，正文翻译质量并不理想。
一开始我以为主要原因是 Yandex Translate 本身不如 ChatGPT。但进一步抓包和对比后，我发现问题可能没有这么简单。
参考：Chrome Built-in AI、Yandex Translate、ChatGPT Plus 翻译质量对比：我为什么决定重点英文文章改用 ChatGPT Plus
这篇文章记录一下我的验证过程，以及目前对后续翻译流程的判断。
![[截图 1：AutoPoly 自动翻译进度条界面]](https://www.shuijingwanwq.com/wp-content/uploads/2026/07/1-16-1024x536.png)
一、我最初的怀疑：AutoPoly 可能不是整篇文章翻译
我现在手动处理英文文章时，通常是把完整的 WordPress 代码编辑器内容交给 ChatGPT，然后明确要求：
保留 Gutenberg 区块结构
保留 HTML 标签
保留短代码
保留图片占位
保留代码块
代码块中的内容默认不要翻译
产品名、插件名、命令、路径、域名、URL 不要翻译
技术术语使用自然英文
不要机器翻译腔
适合海外技术读者阅读
这种方式本质上不是简单翻译，而是“整篇技术博客的英文重写”。
但 AutoPoly 的自动翻译界面有一个百分比进度条。这个细节让我开始怀疑：
它可能不是把整篇 WordPress 代码编辑器内容一次性发给翻译服务，而是先拆成一段一段、一个区块一个区块，再分别翻译。
如果是这样，即使把翻译引擎从 Yandex 换成 OpenAI，最终质量也未必能达到我现在直接用 ChatGPT Plus 整篇处理的效果。
二、抓包验证：AutoPoly 免费版确实是前端请求 Yandex
为了验证这个判断，我在浏览器开发者工具中打开 Network 面板，然后用 AutoPoly 免费版执行一次 Yandex 自动翻译。
筛选 yandex 后，可以看到浏览器直接请求了：
https://translate.yandex.net/api/v1/tr.json/translate
请求中还有这些参数：
srv=tr-url-widget
lang=zh-en
format=html
callback=...
这说明 AutoPoly 免费版使用 Yandex 时，并不是 WordPress 后端代请求 Yandex，而是：
浏览器前端 → translate.yandex.net
也就是说，免费版的 Yandex 翻译更接近一种前端 Widget/JSONP 调用方式。
![[截图 2：浏览器 Network 中直接请求 translate.yandex.net]](https://www.shuijingwanwq.com/wp-content/uploads/2026/07/2-16-1024x568.png)
三、关键证据：它不是整篇文章，而是 text 数组分片翻译
其中一个请求的数据大致如下：
{
"text": [
"每次修改规则或域名配置后，EdgeOne 可能会显示：",
"这时立刻测试，结果可能不稳定。",
"【图29：域名配置处于部署中状态】",
"之前我一度以为 HTML 缓存必须开启“强制缓存”才能命中。后来等域名和规则全部变成“已生效”后，再次测试发现：",
"所以现在的最终结论是：",
"这比强制缓存开启更稳。",
"十九、用 curl 验证 EdgeOne 缓存是否生效",
"配置完成后，我用 curl 做了几组测试。"
],
"lang": "zh-en",
"format": "html"
}
这个请求非常关键。
它说明 AutoPoly 并没有把完整文章内容作为一篇文章提交给 Yandex，而是把文章拆成多个 text 项，然后分批提交。
因此，更准确的结论是：
AutoPoly 免费版不是严格“一段一次请求”，而是将文章内容拆成多个标题、段落、列表项、说明文字等文本片段，再通过 text 数组批量提交给 Yandex 翻译。
这也解释了为什么它有百分比进度条。
这个进度条很可能对应的是：
已处理片段数 / 总片段数
或者：
已完成批次数 / 总批次数
而不是整篇文章级别的翻译进度。
四、AutoPoly 翻译结果的问题：正文翻译偏机械
从最终结果看，AutoPoly 免费版使用 Yandex Translate 后，正文翻译明显有机器翻译腔。
例如中文原文：
说明 _ga 这类统计 Cookie 不影响普通访客命中 HTML 缓存。
AutoPoly/Yandex 结果类似：
Description _ga Such statistical cookies do not affect ordinary visitors from hitting the HTML cache.
这个英文就很不自然。
更自然的技术博客表达应该是：
This shows that analytics cookies such as _ga do not prevent regular visitors from hitting the HTML cache.
问题不只是某个单词翻错，而是句子缺少上下文重写。
类似“结果：”“说明：”“这一步完成后”“最终结论是”这类中文技术博客里常见的表达，如果按片段单独翻译，很容易变成生硬的英文。
五、但 AutoPoly 保留代码块中的中文，反而符合预期
一开始我看到 AutoPoly 翻译结果里还有大量中文，以为这是严重问题。
但后面仔细看了一下，这些中文主要集中在 Plaintext 或类似代码块中。
比如：
同一个 www 主域名
同一个 /en/ 英文目录
统一 EdgeOne 加速
普通访客 HTML HIT
静态资源 HIT
后台、登录页、REST API、已登录用户安全绕过缓存
这类内容在我的 WordPress 文章中通常是代码块、配置块或命令块。
按照我现在的翻译规则：
代码块中的内容默认不要翻译。
所以 AutoPoly 没有翻译这些块，反而是符合预期的。
也就是说，AutoPoly 免费版在结构保护上有一个优点：
它更保守，不容易把代码块、配置块、路径、命令直接翻坏。
这对技术博客很重要。
六、再对比 Yandex 网页版 Quick translation
为了进一步验证，我又把整篇正文放到 Yandex 网页版里做了一次翻译。
这次没有登录，使用的是 Yandex 的 Quick translation。
从结果看，Yandex 网页版整篇翻译有一个优势：
普通正文的连贯性略好于 AutoPoly 免费版。
比如它会更倾向于把整篇正文连续处理，而不是像 AutoPoly 那样明显按片段翻译。
但它也有一个很大的问题：
Yandex 网页版会把代码块、配置块、说明块里的中文也翻译掉。
比如原本应该保留的配置说明、结构块、路径说明，都被它当成普通正文翻译了。
这不符合我的需求。
![[截图 3：Yandex 网页版 Quick translation 翻译整篇正文]](https://www.shuijingwanwq.com/wp-content/uploads/2026/07/3-15-1024x567.png)
七、Yandex 网页版的问题：整篇翻译不等于可发布
Yandex 网页版整篇翻译虽然比 AutoPoly 的正文稍微自然一点，但它仍然不能作为正式英文博客发布稿。
主要问题有几个。
第一，它会翻译不该翻译的代码块和配置块。
对普通文章来说，这可能不是问题；但对 WordPress 技术博客来说，这很危险。
第二，它容易破坏技术结构。
例如原本是这样的链路说明：
用户浏览器
↓ HTTPS
EdgeOne 边缘节点
↓ HTTPS 回源
阿里云 ECS / Nginx / WordPress
机器翻译后可能会变成重复的 HTTPS HTTPS，整体结构变得很奇怪。
第三，Quick translation 对长文本有输入限制。
我这次测试时，页面左下角可以看到文本已经超过限制：
14469 / 10000
这意味着对于长文章，Yandex 网页版并不是一个稳定的整篇处理方案。即使它能显示部分结果，也可能存在截断、遗漏或复制不完整的问题。
第四，英文仍然是机器翻译腔。
比如：
Cloudflare Free is not completely unavailable.
这个表达虽然能看懂，但不像一篇自然的英文技术博客。
更自然的表达可能是：
Cloudflare Free is not unusable.
或者：
Cloudflare Free still works in some scenarios.
这就是机器翻译和人工重写之间的差异。
八、这次对比后的真实结论
这次测试后，我对 AutoPoly 和 Yandex 网页版的判断变得更清晰了。
AutoPoly 免费版的优势是：
能创建英文文章
能保留 Polylang 关联
能保护 Gutenberg 结构
能保留代码块、图片、链接
不容易把代码块内容误翻译
适合批量生成英文初稿
AutoPoly 免费版的问题是：
正文翻译质量一般
片段级翻译痕迹明显
英文表达生硬
上下文衔接不足
不适合作为高质量英文技术博客终稿
Yandex 网页版 Quick translation 的优势是：
普通正文翻译略连贯
整篇上下文感略好于 AutoPoly 免费版
适合作为对照测试
Yandex 网页版的问题是：
会翻译代码块和配置块
可能破坏技术结构
长文本有输入限制
不适合作为 WordPress 技术文章发布流程
所以这次不能简单得出“Yandex 网页版比 AutoPoly 好”这个结论。
更准确的结论应该是：
Yandex 网页版在普通正文翻译上略好一些，但不适合处理包含代码块、配置块和 Gutenberg 结构的 WordPress 技术文章。AutoPoly 免费版结构保护更好，但正文翻译质量不够高。
九、关于 AutoPoly Pro：我现在最担心的点
AutoPoly Pro 支持更多 AI Translation Providers，比如 OpenAI、Gemini、DeepL 等。
理论上，如果把 Yandex 换成 OpenAI，句子质量肯定会提升。
但是我现在不确定的是：
AutoPoly Pro 使用 OpenAI 时，是否仍然是按 Gutenberg block / 段落 / 字段进行分片翻译？
如果它仍然是分片翻译，那么即使 provider 换成 OpenAI，也可能只是把每个片段翻译得更好，而不是从整篇文章层面进行英文重写。
这两者差别很大。
分片翻译更像：
第 1 段 → 翻译
第 2 段 → 翻译
第 3 段 → 翻译
标题 → 翻译
列表项 → 翻译
图片说明 → 翻译
整篇重写更像：
理解整篇文章主题
判断读者是谁
统一术语
统一语气
保留代码块
重写正文表达
优化标题和小标题
让文章适合海外技术读者阅读
我的文章显然更需要后者。
尤其是最近这些内容：
Cloudflare / EdgeOne / CDN 迁移
WordPress 缓存规则
VPN 自建与商业 VPN 对比
Codex 学习与开发者变现
联盟营销实践
SEO 流量恢复
这些文章不只是翻译，还涉及个人经验、技术判断、商业化表达和读者信任感。
因此，如果 AutoPoly Pro 仍然是 block-level translation，那么它即使接入 OpenAI，也很可能达不到我现在 ChatGPT Plus 整篇处理的质量。
十、目前的决策：AutoPoly 不能替代 ChatGPT 整篇重译
基于这次验证，我现在的阶段性结论是：
AutoPoly 免费版可以作为结构复制和批量初稿工具。
AutoPoly Pro 是否值得购买，还需要进一步验证。
Yandex 不适合作为正式英文博客翻译方案。
Yandex 网页版 Quick translation 不适合我的 WordPress 技术博客流程。
高价值文章仍然应该继续使用 ChatGPT Plus 整篇重译。
对于我的博客来说，后续可能会分成几类处理。
第一类，高价值新文章。
比如 VPN、CDN、Codex、联盟营销、SEO、WordPress 技术排查类文章。
这类文章继续使用：
完整中文 WordPress 代码编辑器内容
→ ChatGPT Plus 整篇英文重译
→ 人工检查
→ 发布英文版
第二类，低价值历史文章。
这类文章可以考虑：
AutoPoly 批量创建英文副本
→ 自动翻译生成初稿
→ 简单检查
→ 发布或暂缓发布
第三类，复杂代码块文章。
这类文章最好不要交给 Yandex 网页版整篇翻译，因为它可能会把代码块、配置块也翻译掉。
十一、后续可能研究：把 ChatGPT Plus 流程自动化
这次验证也让我产生了一个新的方向：
与其纠结 AutoPoly Pro 是否能达到 ChatGPT 的质量，不如研究如何把现有的 ChatGPT Plus 翻译流程自动化。
目前我理想中的流程是：
从 WordPress 获取中文文章代码编辑器内容
→ 自动提交给 ChatGPT
→ 按我固定的英文重译规则处理
→ 返回英文标题、slug、meta description、摘要、正文
→ 人工确认后写入 WordPress 英文文章
这里可以探索几种方式：
ChatGPT 代理
浏览器自动化
WordPress REST API
半自动复制粘贴流程
本地脚本辅助
当然，这里面还有很多问题需要处理。
比如：
如何稳定保留 Gutenberg 区块结构
如何避免代码块被翻译
如何处理超长文章
如何自动生成英文 slug
如何保留图片占位
如何和 Polylang 英文文章关联
如何避免误覆盖已有文章
但从翻译质量角度看，这条路线可能比直接购买 AutoPoly Pro 更值得研究。
因为我现在已经比较确定：
对我的高价值技术博客来说，真正有价值的不是“自动翻译”，而是“按固定规则进行整篇英文技术博客重写”。
结论
这次测试解决了我之前的一个疑问。
AutoPoly 免费版使用 Yandex Translate 时，确实不是把整篇文章作为完整上下文一次性翻译，而是把文章拆成多个文本片段后分批提交给 Yandex。
这种方式有利于保留 WordPress/Gutenberg 结构，也能避免部分代码块被错误翻译。
但它的代价是：
上下文不足
正文生硬
术语和语气不够统一
英文读者阅读体验一般
Yandex 网页版 Quick translation 虽然在普通正文连贯性上略好，但它会翻译代码块和配置块，也有长文本限制，因此同样不适合作为我的正式英文博客流程。
所以目前我的判断是：
AutoPoly 可以作为 WordPress 多语言结构工具和低价值历史文章初稿工具，但不能替代 ChatGPT Plus 的整篇英文重译流程。
至于 AutoPoly Pro 是否值得购买，关键不在于它是否支持 OpenAI，而在于：
它使用 OpenAI 时，是否仍然是分片翻译？
是否允许自定义 prompt？
是否能明确排除代码块？
是否能基于整篇文章上下文重写？
是否能显著减少人工修改成本？
在这些问题没有验证清楚之前，我不会把 AutoPoly Pro 当成最终英文翻译方案。
接下来更值得研究的方向，可能是：
如何把我现在已经验证有效的 ChatGPT Plus 整篇翻译流程，进一步自动化。
需要长期技术维护或远程问题排查？
我是拥有 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
评论
2 条对“从 AutoPoly 到 Yandex 网页版：一次 WordPress 英文自动翻译质量验证”的回复
[…] […]
[…] From AutoPoly to the Yandex Web Version: A WordPress English Auto-Translation Quality Test […]