分类： 智谱 AI
-
在完成 SlyTranslate 与智谱 GLM 5.2 的整篇翻译定制后，我进一步申请并接入 DeepSeek API，通过本地脚本对 glm-5.2 与 deepseek-v4-pro 进行了相同内容、相同提示词下的标题、摘要和正文翻译测试。结果显示，DeepSeek V4 Pro 的响应速度明显更快，但在信息完整性、技术表达和 Gutenberg 段落衔接方面，并未表现出稳定优于 GLM 5.2 的质量优势。考虑到现有 GLM 5.2 定制插件已经包含代码区块占位、HTML 与 Gutenberg 结构保护、整篇翻译和内容还原等完整处理流程，当前没有必要再为 DeepSeek 重复投入开发。后续若继续追求更高翻译质量，将优先在本地测试 OpenAI，确认其是否具备足够明显的优势，再决定是否解决阿里云杭州服务器访问 OpenAI API 的网络问题。
-
本文记录在 SlyTranslate + 智谱 GLM-5.2 一次性全文翻译方案基础上，继续优化 WordPress 技术文章英文质量的完整过程。通过关闭随机采样、修复标题与摘要未接收附加提示词的问题，并将标题、摘要、正文及目标语言规则内置到 MU Plugin，减少了后台重复配置。随后使用智谱官方 API 对深度思考与 GLM-4.7-FlashX 进行 A/B 测试，结果显示深度思考成本明显增加但质量提升不稳定，FlashX 虽然更快但准确性较低。最终确定以 GLM-5.2、关闭深度思考、关闭随机采样和内置多字段提示词作为当前稳定方案。
-
本文记录在 WordPress、Polylang 与 SlyTranslate 环境中，使用智谱 GLM-5.2 对包含大量 Gutenberg 区块和 Code Block Pro 代码块的技术长文进行正文单次翻译的完整排查过程。最初后台返回 invalid_translation_runaway_output，但执行轨迹显示正文其实只调用模型一次，并已成功保存英文文章。真正原因是自定义翻译完成后，SlyTranslate 原始 REST 回调又继续执行。通过将接管入口从 rest_request_before_callbacks 调整为 rest_dispatch_request，最终避免重复翻译，同时验证了 54 个代码块逐字一致、Gutenberg 结构完整、正文无中文漏译，翻译质量也明显优于原生分块流程。
-
本文记录了在 WordPress 中使用 SlyTranslate 接入智谱 GLM-5.2 翻译技术长文时，从连续 504 超时到最终成功生成英文文章的完整排障过程。经日志分析发现，主要问题分别是模型请求的 `max_tokens` 被限制为 256，导致大量译文以 `finish_reason=length` 被截断，以及 SlyTranslate 使用三倍字符长度判断失控生成，对中文翻译为英文产生误判。通过 MU Plugin 将 GLM-5.2 的最小输出上限调整为 1024、关闭思考模式，并将长文本增长阈值由 3 调整为 6 后，翻译任务在约 9 分钟内完成。最终生成的英文文章保留了全部 Gutenberg 区块顺序、图片、列表和 54 个 Code Block Pro 代码块，普通正文无中文残留，Polylang 关联及英文前台访问均正常。当前方案已经解决长文翻译的稳定性与结构完整性问题，但英文自然度和术语准确性仍有进一步优化空间。