为英文博客翻译质量优化建立独立 ChatGPT 项目：整理历史会话并统一后续评测标准

最近一段时间，我一直在调整 WordPress 中文技术文章的英文翻译流程。

最初使用的是 AutoPoly，后来开始测试 SlyTranslate，并先后对智谱 GLM 5.2 和 DeepSeek 进行了实际翻译对比。

目前已经得到一个比较明确的阶段性结论：

在现有测试文章和评价标准下，DeepSeek 的英文翻译质量不如 GLM 5.2，因此现阶段没有继续测试 DeepSeek 的必要。

接下来真正值得考虑的方向，是在本地环境中测试 OpenAI，并将结果与 GLM 5.2 进行对比。如果 OpenAI 的翻译质量确实存在明显提升，再进一步评估阿里云杭州生产服务器无法直接访问国外 API 的部署问题。

随着测试内容不断增加，相关会话也开始分散在普通聊天记录中：

• AutoPoly 替代插件选择
• SlyTranslate 安装与配置
• GLM 5.2 翻译质量测试
• DeepSeek API 接入与翻译对比
• 长文章翻译稳定性
• Gutenberg 区块和代码块保护
• 翻译质量与广告平台申请之间的优先级判断

这些会话虽然都与英文翻译有关，但此前一直混在普通聊天记录中。

继续这样下去，后续对比 OpenAI 时，很容易遗漏前面的测试过程和阶段性结论，也可能重复讨论已经验证过的问题。

因此，我决定为这项工作建立一个独立的 ChatGPT 项目：

英文博客翻译质量优化

这次整理过程中，我还遇到了一个与项目记忆模式有关的问题。

一、为什么要单独建立一个项目

这次建立项目，并不是为了翻译某一篇具体文章，而是希望长期解决以下问题：

1. 确定适合 WordPress 技术博客的自动翻译工具。
2. 对比不同大模型的英文翻译质量。
3. 保证 Gutenberg 区块、HTML、短代码和代码块不被破坏。
4. 降低每篇文章的人工检查和修正时间。
5. 控制 API 成本、翻译耗时和服务器维护成本。
6. 最终形成一套稳定、简单、可以长期运行的英文内容生产流程。

目前，DeepSeek 与 GLM 5.2 的对比已经完成。

从实际测试结果来看，DeepSeek 暂时没有表现出替换 GLM 5.2 的价值。因此，下一阶段的重点不再是继续测试国内模型，而是考虑是否有必要在本地环境中加入 OpenAI 进行对比。

这已经不是一次性的文章翻译任务，而是一个持续评测、不断调整并最终需要落地到生产环境中的长期项目。

将相关聊天集中到同一个项目中，可以让后续会话更容易参考此前的配置、测试结果和决策依据，也能避免每次都重新说明网站环境和翻译要求。

二、第一次创建项目时选择了“仅项目”记忆

第一次创建项目时，我选择的是“仅项目”记忆。

从界面说明来看，这种模式具有较强的隔离性：

• 项目只能访问项目内部的记忆。
• 项目之外的聊天无法引用项目内容。
• 项目内的聊天也不会引用外部聊天。
• 记忆模式在项目创建后无法修改。

这种模式比较适合需要严格隔离上下文的独立项目。

但我的实际需求并不是完全隔离。

我希望把此前已经完成的 AutoPoly、SlyTranslate、GLM 5.2 和 DeepSeek 相关会话移动到新项目中，作为下一阶段测试 OpenAI 时的参考资料。

当我尝试把已有聊天移入项目时，界面提示：

无法将聊天移入或移出使用仅限项目记忆的项目。

也就是说，在我当前使用的 ChatGPT 界面中，选择“仅项目”记忆后，无法把已有会话迁移进去。

这与我建立项目的初衷发生了冲突。

三、删除原项目，重新选择“默认”记忆

由于记忆模式在项目创建后无法修改，我没有继续保留原来的空项目，而是将其删除，然后重新创建。

第二次创建时，我展开了右上角的记忆设置，并选择：

默认

界面中的说明为：

该项目可以访问外部聊天的记忆，反之亦然。

这更符合当前需求。

我的主要目标并不是建立一个完全封闭的翻译测试环境，而是将已有的 AutoPoly、SlyTranslate、GLM 5.2 和 DeepSeek 测试会话集中起来，并在此前结论的基础上继续推进。

需要注意的是，项目记忆模式是在创建项目时确定的。

至少在我当前使用的界面中，项目创建完成后只能查看当前记忆模式，不能再直接切换。

因此，在创建项目前，最好先确定自己是否需要移动已有聊天。

如果主要目的是整理过去的会话，选择“默认”会更加方便。

四、在项目设置中添加专用指令

项目重新创建后，我进入项目设置，将此前整理的翻译规则放入“指令”中。

这些指令不是用于某一篇具体文章，而是作为整个项目长期使用的背景、约束和评价标准。

由于 DeepSeek 已经完成测试，项目说明也不应再把它写成“待测试模型”。

调整后的项目指令如下：

本项目用于持续提高 WordPress 中文技术文章的英文翻译质量，并确定稳定、可长期使用的自动翻译方案。

当前使用 SlyTranslate，现阶段主要生产模型为 GLM 5.2。DeepSeek 已经完成对比测试，在现有测试文章中，其英文翻译质量不如 GLM 5.2，因此暂不继续测试。下一阶段可能在本地环境中对比 OpenAI。

不要将当前工具和模型视为永久方案，应根据实际测试结果调整。

处理翻译、评测和技术方案时，请遵循以下要求：

1. 保留 Gutenberg 区块结构、HTML 标签、短代码、图片占位、链接、表格和代码块。
2. 不要翻译代码、命令、参数、文件路径、域名、URL、产品名和插件名。
3. 技术术语应准确、自然，避免直译和明显的机器翻译腔。
4. 保持个人技术博客的真实、克制和可信度，不要添加夸张或过度营销的表达。
5. 评估模型时，重点比较技术准确性、英文自然度、结构完整性、长文章稳定性、处理速度和 API 成本。
6. 对同一测试文章采用一致的评价标准，不要因为模型不同而改变评判尺度。
7. 当前生产服务器位于阿里云杭州，调用国外 API 时需要考虑网络连通性和部署可行性。
8. 排查或配置时，每次只推进一个明确步骤，等待我返回执行结果后，再提供下一步。
9. 不要为了理论上的小幅提升而引入大量插件、复杂代码或高维护成本，应优先选择稳定、简单、可长期运行的方案。
10. 最终目标不是追求单篇文章的极致英文，而是在可接受的成本和操作量下，建立接近人工重译质量的长期生产流程。

这些规则基本覆盖了我目前最关心的几个方面：

• WordPress 内容结构不能被破坏。
• 技术内容必须准确。
• 英文表达不能有明显的机器翻译痕迹。
• 模型评测必须采用一致标准。
• 不为了小幅提升引入过度复杂的维护方案。
• 最终方案需要适合长期生产，而不是只优化一篇文章。

项目设置中还可以控制文件库访问权限。

我目前保持启用状态。后续如果需要上传模型测试结果、翻译样本、Markdown 报告或本地测试脚本，可以直接在项目中继续分析。

五、为什么仍然要保留 DeepSeek 相关会话

虽然已经确认 DeepSeek 的翻译质量不如 GLM 5.2，但这并不意味着 DeepSeek 相关会话已经没有价值。

恰恰相反，它们仍然是项目中的重要组成部分。

这些会话记录了：

• DeepSeek API 的申请和接入过程
• 本地测试脚本的运行方式
• 与 GLM 5.2 使用相同文章进行对比的方法
• 翻译质量不如 GLM 5.2 的判断依据
• 为什么暂时停止继续投入时间测试 DeepSeek

如果不保留这些记录，过一段时间后可能又会产生同样的问题：

DeepSeek 是否值得重新测试？

保留完整的测试过程，可以明确说明这个方向并非没有尝试过，而是已经通过实际文章完成了对比，并得出了阶段性结论。

因此，DeepSeek 会话应当作为“已经完成的模型评测记录”保留，而不是作为“下一步待测试任务”。

六、并不是所有翻译会话都需要移入项目

项目创建完成后，下一个问题是：应该把哪些已有聊天移进去？

我的网站已经有大量中英文文章。如果将每一次普通文章翻译会话全部移入项目，不但数量过多，也未必能够提高后续判断质量。

因此，我优先移动的是具有长期参考价值的“方案型会话”。

本次首先整理了以下几类内容。

1. AutoPoly 替代插件推荐

这部分记录了为什么准备放弃原来的 AutoPoly 流程，以及选择 SlyTranslate 的背景。

它可以帮助后续判断：

• 当前方案解决了什么问题。
• 为什么没有继续使用旧插件。
• 自动翻译工具的核心要求是什么。

2. 提升翻译质量建议

这部分主要讨论 GLM 模型、Prompt 和翻译质量的提升空间。

它包含了对当前生产方案的阶段性判断，也是后续对比 OpenAI 的重要基础。

3. 翻译优化建议

这部分记录了 GLM 5.2 的实际测试结果，包括标题、摘要和正文等不同内容的处理情况。

相比单纯讨论模型能力，这类实际运行记录更有参考价值。

4. DeepSeek API 操作步骤

这部分记录了 DeepSeek API 的申请、调用、脚本测试和最终对比结果。

DeepSeek 目前已经不再是待测试模型，但这次测试证明了：

至少在当前文章、Prompt 和评价标准下，DeepSeek 的翻译质量不如 GLM 5.2。

因此，这个会话应当作为已经完成的评测档案保留。

5. 翻译优化与广告选择

这部分虽然同时涉及广告平台，但核心问题仍然与英文内容质量有关：

是先申请新的广告平台，还是先提高英文翻译质量？

这项决策会影响接下来一段时间的工作重点，因此也适合保留在翻译项目中。

不准备移入项目的主要是：

• 普通的单篇文章翻译会话
• 仅整理摘要和标签的聊天
• 与翻译系统无关的 CDN 排查
• 与项目无关的客户报价和广告合作记录
• 已经完全废弃、没有参考价值的重复尝试

这样可以避免项目内容越来越杂。

七、将已有聊天移动到新项目

重新选择“默认”记忆后，“移至项目”菜单中的“英文博客翻译质量优化”已经可以正常点击。

具体操作方式比较简单：

1. 在左侧聊天列表中找到需要整理的会话。
2. 点击会话右侧的三个点。
3. 选择“移至项目”。
4. 点击“英文博客翻译质量优化”。

移动完成后，这些聊天会从普通的最近会话列表中进入项目页面。

聊天原来的标题和内容都会保留，不需要重新复制粘贴。

八、项目中的初步整理结果

完成第一轮整理后，项目中已经包含以下会话：

• 翻译优化与广告选择
• DeepSeek API 操作步骤
• 翻译优化建议
• 提升翻译质量建议
• AutoPoly 替代插件推荐

目前这些会话已经能够覆盖整个翻译优化过程中的几个主要阶段：

1. 为什么需要替换原有翻译插件。
2. 为什么最终选择 SlyTranslate 作为当前测试工具。
3. GLM 5.2 当前能够达到什么翻译水平。
4. DeepSeek 为什么没有替代 GLM 5.2。
5. 下一阶段为什么需要考虑 OpenAI。
6. 英文翻译质量与广告变现之间的先后关系。

后续如果在本地测试 OpenAI，也可以直接在这个项目中创建新聊天，而不必再回到普通聊天列表中重新整理背景资料。

九、建立项目后，下一步并不是继续测试 DeepSeek

项目建立完成后，后续方向已经比较清楚。

DeepSeek 的测试已经结束，不需要再投入时间重复验证。

下一阶段更合理的工作是：

1. 整理一篇统一测试文章

选择一篇具有代表性的 WordPress 技术长文，最好同时包含：

• Gutenberg 区块
• HTML 标签
• Bash 或 PHP 代码
• 链接
• 图片占位
• 表格
• 较长的中文技术说明

这篇文章应尽量使用此前测试 GLM 5.2 和 DeepSeek 时已经使用过的内容，避免更换样本后难以公平对比。

2. 在本地测试 OpenAI

由于阿里云杭州生产服务器无法直接访问国外 API，OpenAI 的第一轮测试更适合在本地电脑中完成。

这一阶段只需要判断：

• 技术准确性是否明显优于 GLM 5.2
• 英文自然度是否明显提升
• Gutenberg 和 HTML 结构是否稳定
• 长文章是否能够完整处理
• API 成本是否可以接受

3. 再决定是否解决生产服务器网络问题

只有 OpenAI 的翻译质量明显优于 GLM 5.2，才有必要继续研究：

• 阿里云杭州服务器如何访问 OpenAI API
• 是否需要增加中转服务
• 是否需要将翻译任务放到其他服务器
• 是否值得承担额外网络和维护成本

如果质量只是略有提升，就没有必要为了理论上的小幅优化增加复杂部署。

十、项目后续的模型评测状态

经过当前阶段的测试，模型状态可以暂时整理为：

GLM 5.2

当前表现最稳定，也是现阶段主要使用的翻译模型。

优势包括：

• 技术内容处理相对准确
• 英文自然度较好
• 可以通过国内服务器直接调用
• 与现有 SlyTranslate 和定制插件流程兼容
• 部署和维护成本较低

目前主要问题是翻译质量可能仍未达到 ChatGPT Plus 人工重译的水平，但继续通过 Prompt 微调获得大幅提升的空间已经比较有限。

DeepSeek

已完成测试。

在相同测试文章和评价标准下，整体英文翻译质量不如 GLM 5.2，因此暂时停止继续测试。

DeepSeek 的 API 接入经验仍然有保留价值，但现阶段不考虑将其作为主要生产模型。

OpenAI

尚未完成 API 对比测试。

下一阶段可能先在本地电脑中进行测试。是否进一步解决生产服务器访问问题，要根据实际质量提升幅度决定。

这种状态整理比简单列出“待测试模型”更加准确，也能避免后续重复投入时间。

十一、这次整理得到的一个经验

这次操作本身并不复杂，但有两个细节比较重要。

第一个是项目记忆模式的选择。

如果只是创建一个完全独立的新项目，不需要导入任何历史聊天，“仅项目”记忆会有较好的隔离效果。

但如果主要目的是整理已有会话，并在过去讨论的基础上继续推进，那么“默认”记忆更加适合。

至少在我当前使用的 ChatGPT 界面中：

选择“仅项目”后，无法将已有聊天移入或移出项目；而项目创建后，也不能再修改记忆模式。

第二个是及时更新项目指令。

项目指令不能一直停留在项目刚开始时的状态。

例如，DeepSeek 已经完成测试并确认不如 GLM 5.2，就不应继续写成“后续准备测试 DeepSeek”。

否则，后续新会话可能仍会把 DeepSeek 当作尚未验证的候选方案，导致重复讨论和重复操作。

十二、总结

英文博客翻译质量优化已经持续了一段时间，但此前相关测试记录比较分散。

这次通过建立“英文博客翻译质量优化”项目，我完成了以下工作：

1. 为翻译质量优化建立独立项目。
2. 发现“仅项目”记忆不适合迁移已有聊天。
3. 删除原项目并改用“默认”记忆重新创建。
4. 将长期翻译规则写入项目指令。
5. 将 AutoPoly、SlyTranslate、GLM 5.2 和 DeepSeek 相关核心会话移入项目。
6. 明确记录 DeepSeek 已经完成测试，且翻译质量不如 GLM 5.2。
7. 将下一阶段重点调整为本地测试 OpenAI。
8. 初步形成了统一的翻译优化和模型评测工作区。

项目建立完成并不代表翻译方案已经最终确定。

目前可以确认的是：

GLM 5.2 仍然是现阶段更适合生产使用的模型，DeepSeek 暂时不再继续测试。

接下来需要验证的，不是 DeepSeek 能否追上 GLM 5.2，而是 OpenAI 的翻译质量是否能够带来足够明显的提升，从而值得进一步解决国外 API 在阿里云杭州生产服务器上的网络和部署问题。

这个独立项目将用于保存后续测试过程、统一评价标准，并最终帮助我确定一套稳定、简单、成本可控的英文博客长期翻译方案。