![[截图 2：浏览器 Network 中直接请求 translate.yandex.net]](https://media.shuijingwanwq.com/2026/07/2-16-1024x568.png)
在完成 SlyTranslate 与智谱 GLM 5.2 的定制接入后，我原本认为，现阶段的自动翻译质量已经接近一个比较实用的水平。
GLM 5.2 不仅可以处理文章标题、摘要和正文，在经过插件定制后，还能够一次性翻译完整的 Gutenberg 文章，并配合代码区块占位、HTML 结构保护和译文还原等处理，基本满足我的 WordPress 英文站发布流程。
不过，在决定长期使用 GLM 5.2 之前，我还是希望再测试一个国内具有代表性的大模型：DeepSeek。
这次测试的目标并不是立即替换 GLM 5.2，而是确认：
- DeepSeek API 是否可以正常接入；
- DeepSeek 与 GLM 5.2 的基础翻译质量有多大差异；
- 是否值得继续为 DeepSeek 开发整篇文章翻译功能；
- 如果国内模型的提升空间已经有限，下一步是否应该测试 OpenAI 等国外模型。
一、为什么还要测试 DeepSeek
在国内大模型中，我目前实际接触和考虑的主要候选就是智谱与 DeepSeek。
GLM 5.2 已经在当前 WordPress 翻译流程中正常运行，但只测试一个模型，很难判断当前结果究竟已经足够好，还是仍然存在明显的替代空间。
DeepSeek 有几个值得测试的理由：
- API 接入方式相对标准；
- 国内服务器通常可以直接访问；
- 模型响应速度和调用成本可能具有优势；
- 如果翻译质量更好，也可以按照 GLM 5.2 的方案继续定制插件。
因此，我决定申请 DeepSeek API，并使用完全相同的测试内容，与 GLM 5.2 进行一次基础对比。
二、申请 DeepSeek API
首先进入 DeepSeek 开放平台，注册并登录账号。
随后在 API Keys 页面创建一个新的密钥，名称设置为：
SlyTranslate-DeepSeek-Test
API Key 创建后只会完整显示一次，因此需要在创建时妥善保存。
需要注意的是，不应将完整 API Key 发送到聊天记录、截图或日志中。后续测试脚本也应通过隐藏输入或环境变量读取密钥，避免将其直接写入代码。
三、充值测试余额
DeepSeek API 按照 Token 用量计费。新创建的账号如果没有可用余额，调用 API 时可能因为余额不足而失败。
由于这次只进行少量标题、摘要和正文测试，因此我先充值了 10 元，没有投入更多金额。
对于这种模型验证测试，先进行小额充值更加合理。只有确认模型质量和实际使用方式符合要求后，才有必要继续增加余额。
四、在 SlyTranslate 中接入 DeepSeek
当前 SlyTranslate 已经通过 Any LLM Provider 接入了智谱 API，因此不需要覆盖原来的 GLM 配置，可以新增一个独立的 Provider。
在 WordPress 后台进入：
SlyTranslate → Settings → AI Providers → Any LLM
点击：
Add provider
然后选择 DeepSeek 预设。
系统自动填写的 API 地址为：
https://api.deepseek.com/v1
填写 DeepSeek API Key 后，连接测试成功，SlyTranslate 可以识别出 DeepSeek 模型。
这说明 DeepSeek API 已经可以在当前 WordPress 服务器中正常连接。
五、为什么不能直接在 WordPress 后台进行公平对比
最初我考虑直接在 SlyTranslate 中分别选择 GLM 5.2 和 DeepSeek，然后翻译同一篇文章。
但实际操作后发现，这种对比并不公平。
当前的执行方式是：
- 选择 GLM 5.2 时，会触发已经定制的整篇文章一次性翻译功能；
- 选择 DeepSeek 时，只能使用 SlyTranslate 默认的分块翻译方式。
这样产生的结果不只是模型之间的差异，还混入了翻译流程的差异：
- GLM 5.2 可以获得完整文章上下文；
- DeepSeek 每次只能看到一部分内容；
- 分块后更容易出现术语不一致；
- 前后段落的指代和衔接可能丢失；
- 标题、摘要和正文的整体语气也可能不统一。
因此，直接比较 WordPress 后台生成的最终文章，无法判断差异究竟来自模型，还是来自整篇翻译与分块翻译的实现方式。
如果 DeepSeek 的基础翻译质量确实更好，后续同样可以为它定制整篇翻译功能。当前只能分块翻译，并不是模型本身的能力限制，而是现有插件尚未为它实现同样的处理流程。
六、使用本地脚本进行基础 A/B 测试
为了让两个模型接收到相同的内容，我在之前 GLM 测试脚本的基础上，增加了 DeepSeek 支持。
测试脚本分别调用：
glm-5.2
和：
deepseek-v4-pro
两者使用相同的：
- 中文原文；
- 翻译提示词；
- 标题、摘要和正文测试字段；
- HTML 与 Gutenberg 结构保护要求；
- 输出长度设置；
- 代码、域名和产品名保留规则。
运行命令如下：
cd /home/wangqiang/下载/glm-deepseek-translation-ab-test-2026-07-15
python3 glm_deepseek_translation_ab_test.py
脚本运行时会分别要求输入：
- 智谱 API Key；
- DeepSeek API Key。
输入内容不会在终端中显示，也不会被写入测试结果。
七、API 调用结果
本次测试中，两个模型的全部请求都成功返回 HTTP 200。
实际耗时如下：
| 测试内容 | GLM 5.2 | DeepSeek V4 Pro |
|---|---|---|
| 标题 | 1.73 秒 | 1.53 秒 |
| 摘要 | 4.16 秒 | 2.28 秒 |
| 正文 | 5.63 秒 | 3.68 秒 |
输出字符数量如下：
| 测试内容 | GLM 5.2 | DeepSeek V4 Pro |
|---|---|---|
| 标题 | 163 | 146 |
| 摘要 | 686 | 627 |
| 正文 | 1542 | 1524 |
从速度来看，DeepSeek 在本次三个测试项目中均快于 GLM 5.2，尤其是摘要和正文，响应时间差异比较明显。
不过，对于文章翻译来说，响应速度并不是唯一标准。只要整篇翻译能够在可接受时间内完成，准确性、上下文完整性和格式稳定性通常更加重要。
八、翻译质量对比
1. 标题
GLM 5.2 的标题信息更加完整，保留了 WordPress、Polylang、英文子域名迁移、完整修复以及具体问题范围。
DeepSeek 的标题更加简洁，但省略了部分原文信息。
对于普通内容标题，简洁可能是优点；但对于技术博客来说，标题中包含明确的平台、插件和问题范围，有助于读者快速判断文章是否与自己的问题有关。
因此，本轮标题翻译中，GLM 5.2 的准确性和信息完整度更好。
2. 摘要
DeepSeek 的摘要句子更短，整体阅读节奏更加轻松。
GLM 5.2 的摘要稍长，但对原文中的故障原因、缓存状态和处理过程保留得更加完整。
也就是说：
- DeepSeek 更偏向重新组织和压缩内容；
- GLM 5.2 更偏向忠实保留原文信息。
对于技术博客摘要，我更看重事实准确性，因此 GLM 5.2 仍然稍占优势。
3. 正文
两个模型都能够保留基本的 HTML 与 Gutenberg 结构，也没有错误翻译域名、命令和插件名称。
但 DeepSeek 的正文中出现了一些段落衔接问题。
例如，一个独立的 Gutenberg 段落以小写的 which 开头：
<p>which ultimately returned a 404.</p>
这句话必须依赖上一个段落才能成立。由于 Gutenberg 会把它作为独立段落保存，中间如果插入截图、代码块或引用，这个句子就会显得不完整。
GLM 5.2 对应的处理是：
<p>This ultimately returned a 404.</p>
即使文章区块之间插入其他内容，这句话仍然能够独立成立。
此外，DeepSeek 还有少量直译式表达和指代不够清楚的问题。GLM 5.2 的正文语气相对更稳定，也更适合技术故障排查类文章。
九、为什么没有继续进行完整长文测试
理论上，更完整的测试方式，是让 GLM 5.2 和 DeepSeek 对同一篇完整 Gutenberg 长文进行一次性翻译。
但当前定制插件已经完成了大量围绕 WordPress 内容结构的处理，包括：
- 代码区块解析；
- 代码内容占位；
- Gutenberg 区块结构保护；
- HTML 标签保护；
- 标题、摘要和正文分别处理；
- 超长内容和输出长度控制；
- 占位符恢复；
- 输出完整性检查；
- API 异常和超时处理。
如果要在本地实现完全公平的长文对比，就需要把这些处理逻辑重新移植到测试脚本中。
这已经不再是简单地调用两个 API，而是在本地重新复制一套 WordPress 翻译插件的核心流程。
如果 DeepSeek 在短文本测试中已经表现出明显的质量优势，那么继续投入时间进行完整长文测试仍然具有价值。
但从当前结果来看，DeepSeek 的主要优势是速度更快，翻译质量并没有明显、稳定地超过 GLM 5.2。
为了验证一个尚不确定的结果，再投入大量时间移植整套插件功能，性价比并不高。
因此，这轮测试到这里停止，是一个更符合实际投入与收益的选择。
十、当前结论
本次测试可以得到几个比较明确的结论。
DeepSeek 的优势
- API 可以正常接入；
- 国内服务器访问没有明显障碍；
- 响应速度比 GLM 5.2 更快；
- Gutenberg 和 HTML 基础结构能够正常保留；
- 可以作为备用模型继续保留。
GLM 5.2 的优势
- 标题信息更加完整；
- 摘要对原文事实保留得更加充分；
- 正文段落衔接更加稳定；
- 技术文章语气更自然；
- 已经完成整篇文章翻译的插件定制；
- 已经集成代码区块占位和结构恢复机制。
综合来看，DeepSeek V4 Pro 在本轮测试中没有表现出足以替换 GLM 5.2 的翻译质量优势。
因此，当前生产环境继续使用 GLM 5.2，更符合实际投入与收益。
DeepSeek Provider 和剩余 API 余额可以继续保留。后续如果 DeepSeek 推出明显更强的新模型，或者 SlyTranslate 原生增加更加完善的整篇文章保护功能，再重新测试也不迟。
十一、下一轮可能测试 OpenAI
在测试完 GLM 5.2 和 DeepSeek 后，我目前的感受是：
国内具有代表性的模型已经达到了比较实用的翻译水平，但如果还想获得更加明显的质量提升，下一步可能需要考虑国外模型。
其中最值得测试的仍然是 OpenAI。
不过，这里存在一个现实问题：我的 WordPress 服务器位于阿里云杭州，目前服务器无法直接访问部分国外 AI API。
此前测试 Gemini 时，杭州服务器访问 Google API 就出现了连接超时。OpenAI API 也可能面临类似的网络问题。
因此，下一步更合理的方式，不是立即修改 WordPress 插件，而是先在本地电脑中进行 OpenAI 与 GLM 5.2 的相同内容测试。
测试流程可以是：
- 在本地调用 OpenAI API；
- 使用与 GLM 5.2 相同的标题、摘要和正文；
- 比较翻译准确性、自然度和技术表达；
- 确认 OpenAI 是否存在明显的质量优势；
- 只有在质量确实更高时，再研究杭州阿里云服务器的访问方案。
如果最终差异只是略好一点，就没有必要为了网络接入、代理稳定性和服务器维护复杂度更换方案。
只有在 OpenAI 的翻译质量明显领先时，解决服务器连接问题才具有实际价值。
十二、总结
这次 DeepSeek 测试并没有带来一个“立即替换 GLM 5.2”的结论，但测试本身仍然有价值。
它至少证明了：
- DeepSeek API 可以正常接入；
- DeepSeek 的响应速度确实更快；
- 两个国内模型都已经具备较好的基础翻译能力；
- 当前决定最终翻译效果的，不只是模型本身，还有插件的结构保护、上下文处理和内容还原机制；
- 在没有明显质量提升的情况下，不值得为另一个模型重复开发整套定制功能。
现阶段，我会继续保留 GLM 5.2 作为 SlyTranslate 的生产翻译模型。
DeepSeek 则继续作为备用 Provider 保留。
下一步如果继续追求翻译质量提升，将优先在本地测试 OpenAI。只有确认它的翻译质量确实明显高于 GLM 5.2，才会进一步研究如何解决阿里云杭州服务器访问 OpenAI API 的问题。
需要长期技术维护或远程问题排查？
我是拥有 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