![[截图 2：浏览器 Network 中直接请求 translate.yandex.net]](https://media.shuijingwanwq.com/2026/07/2-16-1024x568.png)
此前，我已经完成了 SlyTranslate 与智谱 GLM-5.2 的接入，并通过自定义 MU Plugin，将 WordPress 技术文章的正文改为一次性发送给大模型翻译。
相关的前期记录可以参考：
完成一次性全文翻译后，整体翻译质量已经明显好于早期的分块翻译方案，但与 ChatGPT Plus 直接重译相比，英文标题、摘要和正文中仍然会出现一些问题，例如：
- 标题沿用中文语序，连续堆叠多个名词；
- 摘要信息过于密集，句子偏长；
- 普通链接偶尔被错误概括为重定向；
WordPress English site等表达带有轻微的中式英语痕迹；- 个别段落虽然语法正确，但不像自然的英文技术博客。
因此，我继续从以下三个方向进行测试：
- 优化模型请求参数；
- 将翻译提示词内置到代码；
- 测试深度思考及其他模型。
一、先明确当前实际的翻译流程
在早期排查过程中，SlyTranslate 曾经将正文拆分成大量请求，因此旧日志中出现过接近 89 次模型调用的记录。
但当前实现已经发生变化。
现行的自定义 MU Plugin 为：
wp-content/mu-plugins/swq-glm52-translation-tuning.php
它会拦截 SlyTranslate 的翻译 REST 请求，并使用自定义流程处理文章：
- 标题作为一个短字段翻译；
- 摘要作为一个短字段翻译；
- 正文经过代码保护后，一次性发送给 GLM-5.2；
- 所有字段翻译成功后，再统一写入英文文章；
- 正文翻译阶段只允许发出一次模型请求，重试和分块回退会被阻止。
因此，当前一次完整翻译通常只产生少量 API 请求，而不是几十次请求。
这也意味着，后续评估提示词长度、翻译耗时和 API 成本时，不能再使用旧流程中的 89 次请求作为依据。
二、关闭随机采样
智谱 API 支持通过 do_sample 控制是否使用随机采样。
对于技术文章翻译，我更需要的是：
- 术语稳定；
- 表达可复现；
- 同一概念尽量使用同一种英文；
- 避免不同请求随机选择不同的近义词。
因此，在请求正式编码为 JSON 之前增加：
$body['thinking'] = [ 'type' => 'disabled' ];
$body['do_sample'] = false;
关闭采样后，翻译结果会更加稳定，但它主要改善的是一致性和可重复性，并不能自动消除中文语序和机器翻译腔。
三、发现 Additional Instructions 只影响正文
最初，我在 SlyTranslate 后台填写了一套较完整的 Additional Instructions，其中包含：
- 保留 Gutenberg 区块结构；
- 保护 HTML、URL、命令、路径和文件名；
- 保护
SWQBLOCK与SWQINLINE占位符； - 避免中文语序；
- 使用自然的英文技术写作方式；
- 不增加原文中不存在的事实和结论。
重新翻译后，正文有所改善，但标题几乎没有变化。
最开始我怀疑标题可能走了 SlyTranslate 原始插件的独立翻译流程。继续检查当前 MU Plugin 后，才发现真正的问题在这里：
$prompt = self::build_field_prompt( '', $field );
build_field_prompt() 虽然支持接收 Additional Instructions，但调用时传入的是空字符串。
与此同时，正文调用的是：
self::translate_full_content(
$source,
$target_language,
$resolved_source_language,
$additional_prompt,
$post_id,
$article_title,
$article_excerpt
);
也就是说：
Additional Instructions 被传给了正文，却没有传给标题和摘要。
修复后，短字段调用调整为：
$translated = self::translate_field_value(
$source,
$target_language,
$resolved_source_language,
$field,
$id,
$post_id,
$additional_prompt
);
函数参数同步增加：
private static function translate_field_value(
string $source,
string $to,
string $from,
string $field,
string $unit_id,
int $post_id,
string $additional_prompt
)
并将提示词构造改为：
$prompt = self::build_field_prompt(
$additional_prompt,
$field
);
修复后，标题从原来的：
WordPress Polylang English Subdomain Migration Links Still Pointing to Chinese Site...
改善为：
WordPress Polylang English Subdomain Migration: Links Still Pointing to Chinese Site...
虽然还不是最理想的英文标题，但已经证明 Additional Instructions 开始影响标题翻译。
四、将稳定提示词内置到 MU Plugin
继续使用后台 Additional Instructions 存在几个问题：
- 每次翻译前都需要复制粘贴；
- 输入框只保留有限长度的内容；
- 标题、摘要和正文需要不同的规则；
- 未来翻译到其他目标语言时，不能强制套用英文写作要求；
- 提示词散落在后台，不利于长期维护。
因此，我将稳定的翻译规则直接内置到 MU Plugin 中，并保留后台 Additional Instructions 作为可选的临时补充。
新版实现增加了以下方法：
build_field_prompt()
build_content_prompt()
build_target_language_field_rules()
build_target_language_content_rules()
标题、摘要和正文分别使用不同的规则。
英文标题规则
重点要求模型：
- 避免中文语序；
- 避免连续堆叠多个名词；
- 避免不自然的
-ing标题片段； - 明确时间、原因、问题和结果之间的关系；
- 不把“完整修复”改写成泛泛的“使用指南”；
- 不增加原文中不存在的夸张结论。
英文摘要规则
重点要求模型：
- 使用 2～4 个清晰句子；
- 概括问题、主要原因和最终解决方式；
- 避免把所有信息塞进一个超长句子；
- 不使用空泛、行政化的表达；
- 不把普通链接、重定向、缓存和数据库记录混为一谈。
英文正文规则
正文继续保留现有的一次性翻译机制，并强调：
- 保留作者第一人称视角；
- 保留排障顺序和实操记录风格；
- 使用清晰的主语和直接动词；
- 保持技术术语一致；
- 避免逐字翻译和中文句式；
- 不增加、删除、合并或调整 Gutenberg 区块。
其他目标语言
代码不会将英文规则强制应用到所有语言。
目标语言会先进行规范化。例如：
en
en-US
en_US
都会识别为英文。
暂时没有专用规则的语言，会使用通用技术翻译规则作为回退，以后还可以继续增加日文等语言的专用规则。
完成内置提示词后，后台 Additional Instructions 可以保持为空。现行完整 MU Plugin 已经统一包含模型参数、字段提示词、正文提示词、占位符保护和验证逻辑。
五、内置提示词后的实际翻译结果
使用同一篇中文文章重新翻译，耗时约为：
1.36 分钟
新的英文标题为：
Fixing Links That Still Point to the Chinese Site After a WordPress Polylang English Subdomain Migration: A Complete Guide for Category Dropdowns, Breadcrumbs, and Block Templates
相比最初的标题，已经明显改善：
- 标题主干更加清楚；
- “链接仍指向中文站”成为主要问题；
- 不再完全按照中文标题顺序堆叠名词。
不过仍存在一些小问题：
WordPress Polylang English Subdomain Migration依然略显拥挤；- 原文是“完整修复”，模型写成了
A Complete Guide，含义有轻微偏移。
摘要和正文也达到了可以直接发布的水平，但仍然存在一些较轻的模型翻译痕迹，例如：
the WordPress English site
更自然的表达可能是：
the English version of the WordPress site
还有：
After selecting the Browser category, the browser...
同一句中同时出现分类名称 Browser 和普通名词 browser，语法没有错误，但阅读体验不够理想。
这说明提示词优化已经带来了实际改善，但继续不断增加细碎规则，收益可能已经开始下降。
六、测试 GLM-5.2 深度思考
下一步，我尝试启用 GLM-5.2 的深度思考：
$body['thinking'] = [ 'type' => 'enabled' ];
$body['reasoning_effort'] = 'high';
$body['do_sample'] = false;
在 WordPress 中直接测试时，摘要翻译返回：
{
"code": "swq_field_translation_failed",
"message": "Field translation failed: field=excerpt, unit_id=excerpt, reason=invalid_translation_assistant_reply. Diagnostic: /tmp/swq-glm52-field-error-summary.json",
"data": null
}
HTTP 响应为：
500
这说明当前 SlyTranslate 或 Provider 的响应适配层，不能直接正确处理 Thinking 模式返回的数据结构。
但如果继续修改适配层，就可能需要：
- 增加原始响应日志；
- 兼容
reasoning_content； - 调整 Provider 的响应映射；
- 继续在生产环境中反复触发错误。
为了避免不断修改生产代码，我改为直接在本地电脑上调用智谱官方 API，进行独立 A/B 测试。
七、在本地直接测试深度思考
测试使用完全相同的：
- 中文标题；
- 中文摘要；
- Gutenberg 正文样本；
- 提示词；
- GLM-5.2；
do_sample=false。
唯一变量是：
thinking=disabled
与：
thinking=enabled
reasoning_effort=high
测试结果如下：
| 配置 | 标题耗时 | 摘要耗时 | 正文耗时 | 总 Tokens |
|---|---|---|---|---|
| 关闭思考 | 2.23 秒 | 4.14 秒 | 5.68 秒 | 1,604 |
| 深度思考 high | 15.61 秒 | 3.48 秒 | 28.46 秒 | 4,157 |
深度思考的总耗时约为关闭思考的 3.95 倍，Token 使用量约为 2.59 倍。
质量方面：
- 标题：关闭思考版本更直接；
- 摘要：深度思考版本略有改善；
- 正文：互有优劣，没有稳定提升。
深度思考虽然改善了部分句子，但也引入了新的问题，例如：
- 标题主干变得更长；
Chinese primary domain不如Chinese main domain自然；but instead loaded:表达生硬；- 将编号
1.改成了I.； inspection, fixing, and verification不够自然。
最终结论是：
深度思考可以正常运行，但对当前技术博客翻译的提升并不稳定，不值得承担接近 4 倍的耗时、额外 Token 成本和适配层维护成本。
八、对比 GLM-4.7-FlashX
为了判断剩余问题是否已经接近 GLM-5.2 的模型能力上限，我又在本地直接测试了 GLM-4.7-FlashX。
两款模型都使用：
thinking=disabled
do_sample=false
相同提示词
相同输入
测试结果：
| 模型 | 标题耗时 | 摘要耗时 | 正文耗时 | 总 Tokens |
|---|---|---|---|---|
| GLM-5.2 | 1.54 秒 | 3.45 秒 | 5.94 秒 | 1,609 |
| GLM-4.7-FlashX | 0.75 秒 | 2.15 秒 | 4.45 秒 | 1,583 |
GLM-4.7-FlashX 的总耗时大约减少了三分之一，但 Token 使用量只减少了约 1.6%。
质量上，GLM-4.7-FlashX 的问题更加明显。
例如标题将单数的英文子域名写成：
English Subdomains
并将“仍指向中文站”泛化成：
Broken Links
摘要中还出现了：
fixed links
verifying the source site
这些表达没有准确体现“固定链接”和“在源站验证”的技术含义。
正文则出现过去时和现在时混用：
After migrating...
are accessible
I discovered
does not access
returns
相比之下，GLM-5.2 更能维持技术事实、时态和上下文的一致性。
因此，GLM-4.7-FlashX 虽然速度更快，但不适合作为当前生产翻译模型。
九、当前最终配置
经过这一轮测试，当前生产环境暂时固定为：
$body['thinking'] = [ 'type' => 'disabled' ];
$body['do_sample'] = false;
模型继续使用：
glm-5.2
同时保留：
- 标题、摘要、正文的内置专用提示词；
- 按目标语言选择提示策略；
- 后台 Additional Instructions 作为可选补充；
- 正文一次性翻译；
- Gutenberg 与 HTML 结构验证；
SWQBLOCK与SWQINLINE占位符保护；- 只允许一次正文模型请求；
- 600 秒超时；
- 32768 最大输出 Tokens；
- 翻译失败时不写入半成品文章。
十、下一步计划
经过提示词、参数、深度思考和智谱模型之间的测试后，GLM-5.2 已经可以作为当前方案的稳定基线。
继续针对 GLM-5.2 增加更多细碎提示词，预计很难再带来明显提升，反而可能出现：
- 规则之间相互干扰；
- 某些句子改善，另一些句子退步；
- 提示词越来越难以维护；
- 模型为了遵守规则而变得更加保守。
后续如果要继续提升翻译质量，更有价值的方向是使用同样的本地 A/B 测试方式，对比其他模型。
我准备申请 DeepSeek API Key，并使用完全相同的：
- 中文标题；
- 中文摘要；
- Gutenberg 正文样本；
- 内置提示词；
- 关闭思考；
- 关闭随机采样；
进行公平对比。
只有当其他模型在技术准确性、英文自然度、结构保护和长文稳定性方面明显超过 GLM-5.2，才有必要继续修改生产环境的模型兼容逻辑。
总结
这一轮优化最重要的收获，并不是找到一个可以让翻译质量突然大幅提升的参数，而是逐步明确了每一层的作用边界：
do_sample=false主要提升稳定性；- 提示词可以改善标题和正文组织，但不能完全突破模型能力上限；
- 标题、摘要和正文需要不同的提示策略；
- 稳定提示词更适合内置到代码，而不是每次手动粘贴；
- 深度思考的翻译收益不稳定；
- 更快的模型不一定更准确；
- 模型能力与 WordPress 适配问题应该分开测试；
- 本地直接调用官方 API，比在生产环境中反复修改代码更适合做模型实验。
目前，GLM-5.2、关闭深度思考、关闭随机采样，并配合内置的多字段提示词，是这套 SlyTranslate 自动翻译方案中相对稳定、均衡且可以实际使用的配置。
需要长期技术维护或远程问题排查？
我是拥有 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