![[截图 2：浏览器 Network 中直接请求 translate.yandex.net]](https://media.shuijingwanwq.com/2026/07/2-16-1024x568.png)
最近，我刚刚将一部分与 AI 翻译质量有关的文章，从“WP 博客多语言化实操”系列迁移到了新的“WordPress AI 翻译工程实战”系列。
完成系列拆分后，我也开始重新思考一个更长期的问题：
在 SlyTranslate + GLM 5.2 已经能够完成整篇技术文章翻译之后，下一阶段真正值得投入时间的工作是什么？
最初，我只是注意到部分历史文章的摘要为空。但继续检查后，我发现这并不是一个孤立的小问题，而是与历史文章格式、SEO 元描述、英文文章重译、其他语言扩展以及自动化脚本管理相互关联。
最终，我整理出了下一阶段的一组工作计划：
- 盘点历史中文文章的编辑器和代码格式；
- 识别经典编辑器、SyntaxHighlighter Evolved 和 Code Block Pro；
- 使用 GLM-4.7 批量生成中文摘要；
- 将摘要写入 WordPress 的
post_excerpt； - 改善文章列表和 Yoast SEO 元描述；
- 重新覆盖翻译历史英文文章；
- 评估是否增加其他语言；
- 继续优化 SlyTranslate 的全文翻译流程；
- 使用 Codex 和 GitHub 管理相关脚本；
- 比较不同模型的质量、速度和 API 成本。
这篇文章主要记录，我是如何从一个看似简单的“摘要为空”问题，逐步得出这套计划的。
一、最初的问题：大量历史文章没有摘要
我的 WordPress 博客中存在大量早期中文文章，这些文章的摘要字段一直为空。
在文章列表页面中，当 post_excerpt 没有内容时，WordPress 会自动从正文开头截取一段文字作为摘要。
表面上看，这种默认行为可以避免文章列表完全没有简介，但实际使用中出现了两个问题。
第一个问题是，文章正文开头通常包含浏览量组件。
因此，在文章列表中会同时显示：
- 主题或插件单独输出的
Post Views； - WordPress 从正文开头自动截取出来的
Post Views。
最终，一个文章条目中可能出现两次浏览量信息。
第二个问题是 Yoast SEO 的元描述。
当前元描述虽然没有包含浏览量，但因为摘要为空，Yoast SEO 实际使用的是正文开头的一部分内容。例如：
<meta name="description" content="最近我开始重新重视博客的英文流量。 我的博客目前是基于： WordPress Polylang AutoPoly - AI Translation For Polylang AutoPoly 免费版中的 Chrome Built-in AI 来实现中文文章自动翻译成英文。" />
这段内容并不是完全错误，但它只是正文开头的机械截取，并不一定能够准确概括文章解决的问题、采用的方法和最终结果。
因此，最初的目标很明确：
为历史中文文章补齐正式摘要。
二、为什么不能只解决中文文章列表的问题
如果只是为了消除文章列表中的重复 Post Views，也可以通过主题模板或 CSS 临时隐藏一处内容。
但这种处理只能解决表面现象，不能解决摘要字段本身为空的问题。
正式补齐 post_excerpt 后，可以同时改善：
- 中文文章归档页面；
- 分类和标签页面；
- 站内搜索结果；
- RSS 输出；
- Yoast SEO 元描述；
- 社交平台分享摘要；
- 后续英文和其他语言翻译。
尤其是我后续计划重新覆盖翻译历史英文文章。
如果中文文章本身没有摘要，那么重新翻译时，英文文章的摘要仍然会为空。英文文章列表和英文元描述中，也会继续出现相同的问题。
因此，中文摘要并不是一个只服务于中文站点的字段，而应该成为后续多语言内容生产的基础数据。
三、为什么考虑使用 GLM-4.7，而不是继续使用 GLM 5.2
当前 SlyTranslate 的整篇技术文章翻译主要使用 GLM 5.2。
经过多轮定制后，GLM 5.2 已经能够处理：
- Gutenberg 区块；
- HTML 标签；
- 短代码；
- Code Block Pro；
- Plaintext 区域；
- 行内代码；
- 长文章占位符；
- 标题、摘要和正文统一翻译。
但生成摘要与整篇文章翻译不同。
摘要任务通常只需要输出一段较短的中文文本，不涉及：
- Gutenberg 结构还原；
- 几百个占位符验证；
- 代码块恢复；
- 长文结构一致性；
- 大量英文技术表达。
它的核心要求是：
- 准确概括文章；
- 不添加原文不存在的信息；
- 语言自然；
- 长度稳定；
- 批量执行成本可控。
因此，我认为摘要生成没有必要默认使用成本和能力都更高的 GLM 5.2。
我目前还有 GLM-4.7 的模型资源包，可以优先用于这类相对简单、输出较短的任务。
初步计划是：
model: glm-4.7
thinking: disabled
这样既能利用现有资源包，也能将 GLM 5.2 继续保留给更复杂的整篇技术文章翻译。
当然，这只是当前计划，并不是永久决定。
后续仍然需要通过实际样本比较：
- 摘要准确性；
- 中文自然度；
- 输入输出 Token；
- API 耗时；
- 批处理稳定性；
- 失败重试率。
如果 GLM-4.7 的质量不足，再考虑使用 GLM 5.2 或其他模型，而不是提前假设某个模型一定适合所有任务。
四、继续分析后，发现历史文章并不是一种格式
在规划摘要脚本时，我进一步想到：
脚本应该如何从历史文章中提取真正需要总结的自然语言？
我的中文历史文章跨度较长，编辑器和代码高亮方式并不统一，目前至少存在四种主要情况。
1. 经典编辑器，没有代码高亮插件
最早的一批文章使用经典编辑器，代码可能只是普通的：
<pre>...</pre>
或者：
<code>...</code>
部分文章也可能只是依赖空格、换行和手工 HTML 排版。
2. 经典编辑器，使用 SyntaxHighlighter Evolved
后续一些文章仍然使用经典编辑器，但代码块交给 SyntaxHighlighter Evolved 处理。
文章正文中可能存在类似：
[php]
代码内容
[/php]
或者带有参数的短代码：
[php firstline="10" highlight="12,15"]
代码内容
[/php]
3. Gutenberg，使用 SyntaxHighlighter Evolved
再往后，我开始使用 Gutenberg 编辑器，但代码高亮仍然依赖 SyntaxHighlighter Evolved。
这类文章可能同时包含：
- Gutenberg 区块注释；
- Shortcode 区块；
- Classic 或 Freeform 区块；
- SyntaxHighlighter 短代码；
- 普通 HTML。
4. Gutenberg，使用 Code Block Pro
目前的新文章主要使用 Gutenberg 和 Code Block Pro。
这种代码块不仅包含代码本身，还可能包含：
wp:kevinbatdorf/code-block-pro注释；- JSON 属性；
textarea；pre.shiki；code；span.line；- 主题、行号和语言设置。
这意味着，无论是生成摘要还是重新翻译历史文章，都不能假设所有文章结构相同。
五、为什么最终没有决定先把全部历史文章转换为 Gutenberg + Code Block Pro
发现四种历史格式后，我一度考虑：
是否应该在重新翻译英文文章、增加其他语言之前，先将所有中文历史文章统一转换为 Gutenberg + Code Block Pro？
从长期一致性的角度看，这个想法似乎很合理。
统一之后，后续翻译只需要支持一种格式，编辑和维护也更整齐。
但继续评估后，我认为不应该将全量格式迁移作为翻译工作的前置条件。
1. 历史文章格式迁移风险过高
经典编辑器文章中可能包含：
- 非标准 HTML；
- 手工表格；
- 旧短代码；
- 不完整但浏览器可以兼容的标签；
- 特殊转义字符；
- 手工插入的图片和链接；
- 自定义样式；
- 早期 WordPress 自动生成的段落结构。
批量转换为 Gutenberg 后，可能出现：
- 段落顺序变化；
- 空行变化；
- HTML 被重新转义；
- 短代码被错误包裹；
- 表格损坏；
- 代码缩进变化；
- Gutenberg 提示区块无效。
2. Code Block Pro 本身结构较复杂
将普通 <pre>、SyntaxHighlighter 短代码批量转换为 Code Block Pro，并不只是替换标签。
脚本还需要判断：
- 代码语言；
- HTML 实体；
- 行号；
- 高亮行；
- 转义方式；
- Code Block Pro 当前区块结构。
一旦判断错误，就可能造成代码内容损坏。
3. 格式迁移和翻译属于两个不同问题
如果在重新翻译时同时完成格式迁移，一旦英文文章出现异常，很难判断问题究竟来自：
- 模型翻译；
- 占位符保护；
- 代码块转换；
- Gutenberg 结构生成；
- 插件兼容。
因此，当前更稳妥的策略是：
新文章继续统一使用 Gutenberg + Code Block Pro；历史中文文章保留原格式；摘要和翻译工具兼容历史格式。
旧文章只有在需要重新编辑或大幅更新时，再逐篇人工迁移。
六、因此，摘要生成之前必须先做格式盘点
既然不做全量格式转换，下一步就不是直接调用 GLM-4.7，而是先弄清楚历史文章到底是什么情况。
我计划先开发一个只读的文章格式盘点工具，统计：
- 中文已发布文章总数；
- 摘要为空的文章数量；
- 摘要非空的文章数量；
- 经典编辑器无高亮插件的文章数量；
- 经典编辑器 + SyntaxHighlighter Evolved 的文章数量；
- Gutenberg + SyntaxHighlighter Evolved 的文章数量；
- Gutenberg + Code Block Pro 的文章数量；
- 同时包含多种结构的混合文章；
- 无法可靠识别的文章。
分类不能只包含四种理想情况，还应该保留：
mixed
unknown
因为真实历史数据很可能并不完全整齐。
例如，一篇 Gutenberg 文章可能同时存在：
- Code Block Pro；
- 普通
<pre>； - 从经典编辑器迁移后遗留的 Freeform；
- SyntaxHighlighter 短代码。
如果脚本为了完成统计而强行将其归入单一分类，后续摘要提取和翻译测试就可能建立在错误判断上。
七、为什么要抽取代表文章，而不是直接全站运行
格式盘点的另一个目标，是为后续摘要生成和翻译测试选择代表样本。
每种主要格式都需要抽取少量文章，用来验证：
- 代码是否会被误当成自然语言；
- 短代码是否会进入摘要；
- HTML 是否清理完整；
- 文章标题和章节标题是否保留；
- 超长文章是否需要截断；
- 文章结论是否能够被模型识别；
- GLM-4.7 是否会加入原文没有的结论。
测试样本不应该只选最新、结构最规范的文章。
更合理的是覆盖：
- 短文章；
- 长文章；
- 代码较少的文章；
- 代码很多的文章；
- 含表格的文章；
- 含大量图片说明的文章；
- 含短代码的文章；
- 四种编辑器和代码格式。
这样得到的测试结果，才能反映整个历史文章库，而不是少数理想样本。
八、摘要生成脚本应该如何处理正文
摘要脚本不应该将完整原始 HTML 直接发送给模型。
更合理的处理流程是：
读取中文文章
→ 判断文章格式
→ 删除或隔离代码内容
→ 删除 Gutenberg 区块注释
→ 删除无关短代码
→ 清理 HTML
→ 保留标题、章节标题和自然语言
→ 调用 GLM-4.7
→ 验证摘要
→ 写入 post_excerpt
与完整翻译不同，摘要生成并不需要将代码替换成大量占位符，再在模型输出后恢复。
因为摘要中本来就不应该包含代码，所以直接删除代码通常更简单。
但这里的“删除”必须建立在准确识别之上。
例如，不能因为文章中出现 <code> 就删除整段正文，也不能因为出现方括号就将普通技术说明误认为短代码。
因此，格式识别和自然语言提取应该成为可复用的基础模块，而不是临时正则表达式的集合。
九、摘要写入应只维护 post_excerpt
生成摘要后，我计划将内容写入 WordPress 原生的：
post_excerpt
而不是同时维护一份 Yoast SEO 自定义元描述。
这样做的原因是：
- WordPress 文章列表可以直接使用摘要；
- Yoast SEO 可以继续通过摘要变量生成元描述；
- 英文翻译时可以直接翻译摘要；
- 避免摘要和 SEO 元描述形成两套内容；
- 后续修改摘要时只需要维护一个字段。
正式写入时，也不应该直接使用 SQL 更新数据库。
更适合通过 WordPress 环境调用：
wp_update_post()
这样 WordPress、Yoast SEO、对象缓存以及相关保存钩子都能正确收到文章更新。
十、为什么不能一次处理全部历史文章
即使 GLM-4.7 的摘要质量看起来不错，也不应该第一次就对全部历史文章进行批量写入。
更合理的执行顺序是：
第一阶段：只读统计
不调用 API，不修改数据库，只统计文章格式和摘要状态。
第二阶段：小规模 dry-run
选择 10～20 篇代表文章，调用 GLM-4.7，但只输出候选摘要和日志，不写入 WordPress。
第三阶段：人工审阅
重点检查：
- 摘要是否准确；
- 是否遗漏文章结论；
- 是否包含代码；
- 是否出现营销表达；
- 是否过长；
- 是否只是机械改写标题；
- 不同格式的文章是否表现一致。
第四阶段：少量正式写入
先写入约 20 篇，并检查：
- WordPress 后台摘要字段；
- 中文文章列表；
- 分类和标签页面；
- Yoast SEO 元描述；
- W3 Total Cache；
- EdgeOne 缓存；
- RSS 和页面源代码。
第五阶段：逐批处理
验证没有问题后，再每批处理一定数量的文章，并保留断点恢复、失败重试和运行日志。
这样的方式虽然比一次执行全部文章慢，但可以显著降低批量污染历史内容的风险。
十一、为什么决定单独建立 GitHub 公共仓库
摘要补齐并不只是 SlyTranslate 的一个附加功能。
它本质上是一个独立的 WordPress 历史内容处理工具：
读取文章
→ 判断格式
→ 提取自然语言
→ 调用 AI
→ 验证摘要
→ 写入 post_excerpt
因此，我计划单独建立一个公共仓库：
wordpress-ai-excerpt-backfill
这个名称不绑定 GLM-4.7，也不绑定某个 WordPress 插件。
未来可以支持：
- GLM；
- DeepSeek；
- OpenAI；
- 其他兼容 API；
- 不同摘要规则；
- 其他 WordPress 网站。
文章格式盘点工具也放在同一个仓库中，而不是再建一个仓库。
因为盘点和摘要生成共享：
- WordPress 加载；
- 文章查询；
- 编辑器判断；
- 代码块识别；
- 自然语言提取；
- 测试样本；
- 报告输出。
如果将它们拆成两个仓库，后续会产生重复代码和重复维护。
十二、Codex 在这个计划中的作用
这类工作非常适合让 Codex 协助完成工程实现。
Codex 可以负责：
- 初始化仓库；
- 创建项目结构；
- 编写 CLI；
- 实现格式识别；
- 编写测试；
- 生成 JSON 和 CSV 报告；
- 接入 GLM API；
- 实现 dry-run；
- 实现断点恢复；
- 记录 Token 和耗时；
- 管理 Git commit；
- 根据明确授权部署。
但 Codex 不应该自行决定：
- 什么样的摘要才算合格；
- 哪些内容应该删除；
- 是否可以覆盖已有摘要；
- 什么时候可以全量写入；
- 哪个模型可以直接进入生产。
这些质量标准仍然需要通过实际文章抽样确定。
因此，我计划将职责分成两部分：
Codex 负责工程实现，我负责内容标准、样本审阅和生产决策。
十三、为什么重新覆盖翻译历史英文文章要放在中文摘要之后
我已经有大量历史英文文章，但这些英文文章来自不同阶段的翻译方式，例如：
- Yandex；
- Chrome Built-in AI；
- AutoPoly；
- ChatGPT Plus；
- SlyTranslate；
- 不同提示词和模型。
翻译质量和结构完整性并不一致。
因此，我计划后续重新覆盖翻译历史英文文章。
但这项工作应该放在中文摘要补齐之后。
原因是，重新翻译时可以将中文文章的三个字段统一处理：
title
excerpt
content
这样英文文章可以同时获得：
- 重新翻译的标题；
- 与中文摘要语义一致的英文摘要；
- 重新翻译的正文。
英文摘要不需要再单独根据英文正文重新总结，也不需要继续为空。
这可以减少模型调用，也能让中英文摘要保持对应。
十四、是否增加其他语言，应该晚于英文历史文章重译
在技术上，Polylang 可以继续增加其他语言。
但增加语言并不只是多调用一次翻译 API，还会带来：
- 新的语言分类法；
- 新文章数量；
- 新标签翻译；
- 新系列翻译；
- Sitemap 增长；
- 缓存增长；
- 搜索引擎提交；
- 语言切换；
- 新域名或 URL 结构；
- API 成本；
- 内容维护成本。
因此，在英文历史文章尚未重新整理完成之前，不适合立即扩展更多语言。
更合理的判断顺序是：
- 先补齐中文摘要；
- 验证英文覆盖翻译流程；
- 评估英文流量和维护成本；
- 再选择是否增加其他语言；
- 只选择有明确读者和搜索价值的语言。
增加语言不应该只是因为“技术上可以”，而应该建立在长期维护能力和实际收益之上。
十五、SlyTranslate 的优化仍然不会停止
虽然当前全文翻译已经取得明显进展，但 SlyTranslate 的生产流程仍然可能遇到新的边界问题。
已经出现过的问题包括：
- 长文章超时；
invalid_translation_runaway_output假失败；- 占位符遗漏；
- 占位符重复；
- 占位符与正文示例碰撞；
- 自然语言段落重复；
- Code Block Pro 区块失效；
- Plaintext 区域误判；
- 分类、标签和 Series 同步异常；
- 特色图片不同步；
- 缓存提前生成错误页面。
这些问题说明，模型质量只是翻译流程的一部分。
一个真正可长期运行的翻译系统，还需要：
- 输入保护；
- 输出验证；
- 异常日志；
- 安全回退；
- 缓存处理；
- 元数据同步；
- Git 版本管理；
- 生产部署验证。
因此，摘要项目和历史英文文章重译不会取代 SlyTranslate 优化，而是与它共同构成更完整的 WordPress AI 翻译工程。
十六、为什么还需要继续比较不同模型
当前完整技术文章翻译主要使用 GLM 5.2，摘要计划先测试 GLM-4.7。
DeepSeek 已经完成过初步测试，当前结果不如 GLM 5.2，因此暂时不再作为主要候选。
Gemini 在本地进行过测试，但生产服务器位于阿里云杭州，调用国外 API 时还需要考虑网络连通性。
OpenAI 也可能带来更好的英文自然度，但如果服务器不能稳定请求 API，单纯的质量优势并不足以形成生产方案。
因此，模型比较不能只看一篇文章的英文效果，还应该统一比较：
- 技术准确性；
- 英文自然度；
- 结构完整性；
- 长文章稳定性；
- 处理速度；
- API 成本；
- 国内服务器连通性；
- 部署复杂度；
- 失败重试率；
- 长期维护成本。
最终目标不是找出理论上最强的模型，而是找出：
在可接受成本和操作量下，能够长期稳定生成接近人工重译质量内容的方案。
十七、最终形成的下一阶段计划
经过以上分析，我最终将后续工作整理为以下顺序。
第一阶段：历史文章格式盘点
- 开发只读 CLI；
- 统计四种主要格式；
- 识别 mixed 和 unknown；
- 统计空摘要数量；
- 抽取代表测试文章。
第二阶段：中文摘要生成测试
- 使用 GLM-4.7；
- 清理代码和无关结构；
- 生成 80～120 个中文字符的摘要；
- 记录 Token、耗时和模型原始响应；
- 先 dry-run，不写数据库。
第三阶段：中文摘要正式补齐
- 小批量写入
post_excerpt； - 验证文章列表；
- 验证 Yoast SEO 元描述；
- 验证缓存；
- 逐批处理全部历史中文文章。
第四阶段：重新覆盖翻译历史英文文章
- 保留中文源文章原有结构；
- 同时翻译标题、摘要和正文；
- 更新现有英文文章；
- 避免重复创建；
- 检查 Polylang 关联、分类、标签、Series 和特色图片。
第五阶段：评估其他语言
- 根据英文站结果评估是否扩展；
- 评估流量、成本和维护工作量；
- 不为了语言数量而增加语言。
第六阶段：持续优化翻译流水线
- 继续完善占位符保护；
- 增加历史格式测试样本；
- 优化异常处理；
- 比较模型质量和成本；
- 使用 Codex 与 GitHub 管理代码。
十八、阶段性结论
这套计划并不是一开始就设计出来的。
它是从一个很小的现象开始的：
历史文章摘要为空，导致文章列表重复显示 Post Views，Yoast SEO 元描述也只是截取正文开头。
继续分析后，问题逐渐扩展到：
- 中文摘要基础数据；
- 英文摘要；
- 历史文章格式；
- 代码保护；
- 英文历史文章重译；
- 其他语言；
- 模型成本；
- 自动化脚本；
- GitHub 工程管理。
最终，我没有选择直接批量生成摘要，也没有先将全部历史文章转换为 Gutenberg + Code Block Pro。
当前更稳妥的路线是：
先盘点，再抽样；先补齐中文基础数据，再覆盖英文；先保证单一流程稳定，再考虑扩展语言。
这也符合我目前对 WordPress AI 翻译工程的基本判断：
真正困难的并不是让模型输出一段译文，而是建立一套能够长期运行、可验证、可恢复、成本可控，并且不会破坏历史内容的生产流程。
需要长期技术维护或远程问题排查？
我是拥有 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
发表回复