A Tour of Go 中文翻译项目进展：完成前 8 页、修复 present 语法，并暂缓 DeepSeek 对比

Go Tour 中文版开发实战

(1) 从「A Tour of Go 中文版」这个搜索词开始：我决定做一个持续维护的 Go Tour 中文版

(2) A Tour of Go 中文版项目设计冻结：从 101 页到 103 页，从 Gin 转向 Cobra CLI

(3) A Tour of Go 中文版开发实战：英文基线、在线运行与 101 页上游同步体系

(4) A Tour of Go 多语言翻译项目实录：完成首个 zh-CN 页面翻译闭环

(5) A Tour of Go 中文翻译项目进展：完成前 8 页、修复 present 语法，并暂缓 DeepSeek 对比

2026 年 8 月 2 日，我正式开始推进 go-tour-i18n 项目的简体中文翻译，并完成了第一个页面 welcome/1 的完整翻译闭环。

在上一篇文章《A Tour of Go 多语言翻译项目实录：完成首个 zh-CN 页面翻译闭环》中，我记录了页面投影、术语表、Protected Token、开发阶段重试机制以及首个中文 candidate 的生成过程。

经过第二天的继续开发，目前项目已经完成 8 个简体中文课程页面：

• welcome/1
• welcome/2
• welcome/3
• welcome/4
• welcome/5
• basics/1
• basics/2
• basics/3

Welcome 章节已经全部完成，Basics 章节也完成了前三页。

不过，这次推进过程中最重要的收获，并不只是增加了几个已翻译页面，而是进一步确认了正式发布页面的运行语义、改进了中文提示词，并修复了一个隐藏在 legacy present 语法中的行内代码保护问题。

一、项目目前采用 103 个正式发布页面

A Tour of Go 官方源码包含 7 个 .article 文件。

按照 standalone 本地运行模式统计，原本共有 101 个普通课程页面。不过，Welcome 章节中还存在两个受 #appengine: 条件控制的页面：

• Go offline
• The Go Playground

这两个页面在官方线上运行环境中会被展开为独立页面。

由于本项目的目标是构建公开发布的中文版，而不只是复制 standalone 本地运行结果，因此最终采用了 103 个正式发布页面：

• 101 个普通页面；
• 2 个条件页面；
• 同时保留 2 条条件源记录用于审计。

项目没有直接修改官方原始 _content 文件，而是在发布投影层生成正式页面。

这样既可以保持上游源码不变，也可以明确区分：

• 官方原始源码；
• standalone 本地页面；
• 正式发布页面投影；
• 中文 candidate；
• 最终发布内容。

二、Welcome 章节已经全部完成

正式发布投影中的 Welcome 章节共有 5 个页面：

1. Hello, 世界
2. 其他语言版本
3. 离线使用（可选）
4. Go 语言演练场
5. 恭喜

其中，第一个页面经历了多次开发 attempt。

这些 attempt 并不只是反复修改中文，而是在逐步校准：

• 页面投影；
• 条件内容处理；
• Protected Token；
• 术语表；
• System Prompt；
• candidate validator；
• 开发模式重试行为。

所有模型请求、原始响应和验证结果都按照 source SHA 和 attempt 编号保存，没有被后续结果覆盖。

三、正式发布页面改用远程执行语义

welcome/1 中有一句话用于说明用户点击“运行”按钮后，程序在哪里编译和运行。

官方源码针对不同环境提供了两种语义：

• standalone 本地 Tour：在用户的计算机上运行；
• 官方线上 Tour：在远程服务器上运行。

本地 Tour 会注册 /socket，调用服务器本机的 Go 工具链执行代码。这种方式适合开发人员在自己的电脑上运行，但不能直接公开到生产环境。

本项目的生产站点不会直接开放本地 /socket，因此正式发布投影最终采用：

在远程服务器上编译并运行该程序。

与此同时，仓库中的原始 standalone Tour 行为保持不变。

也就是说：

• 本地原始 Tour 仍然使用 your computer 分支；
• 中文正式发布投影使用 a remote server 分支；
• 旧 source 下已经保存的 6 次翻译 attempt 继续保留；
• 不会为了切换发布投影而伪造新的模型调用记录。

这一步进一步明确了：课程翻译不能脱离最终发布环境单独处理。

四、开始翻译正式 Go 技术页面

Welcome 章节完成以后，我开始翻译 Basics 章节。

目前完成了前三页。

1. Packages

中文标题定为：

包

这一页介绍：

• Go 程序由包组成；
• 程序从 main 包开始运行；
• 如何使用 fmt 和 math/rand；
• 包名与导入路径之间的关系。

GLM-5.2 生成的中文整体自然、准确，基本可以直接使用。

这一页沉淀了三个基础术语：

• package → 包
• import path → 导入路径
• package name → 包名

2. Imports

中文标题定为：

导入

模型最初生成的句子是：

这段代码将导入路径放在一个带圆括号的“分组”导入语句中。

技术含义基本正确，但“将导入路径放在”略显机械，也没有充分表达多个导入项被组织到一起的含义。

最终调整为：

这段代码将多个导入项组织在一个带圆括号的“分组”导入语句中。

另一句原始译文是：

但使用分组导入语句是更好的风格。

最终调整为：

不过，使用分组导入语句是更好的代码风格。

这一页新增术语：

• import statement → 导入语句

3. Exported names

中文标题最终定为：

导出名

模型原始标题为“导出的名称”，意思没有错误，但在 Go 技术语境中，“导出名”更简洁，也更符合中文开发者的常用表达。

模型原始正文包括：

如果一个名称以大写字母开头，它就是导出的。

最终调整为：

在 Go 中，以大写字母开头的名称是导出的。

最后的操作说明也从：

然后再试一次。

调整为：

然后再次运行。

这一页新增术语：

• exported name → 导出名
• unexported name → 未导出的名称

五、发现一个看起来像错误的反引号结构

检查 Packages 页面时，我注意到官方源码中有这样一段：

`package`rand`

`package`rand`

如果按照普通 Markdown 理解，这段内容似乎存在明显问题：

• `package` 是一个行内代码；
• rand 是普通文本；
• 最后还多了一个反引号。

但是，查看官方线上页面的 HTML 后发现，实际渲染结果是：

<code>package rand</code>.

<code>package rand</code>.

这里的结构完全正确：

• package rand 是一个完整的代码节点；
• 空格位于代码节点内部；
• 英文句号位于 </code> 之后。

原因在于 A Tour of Go 使用的不是普通 Markdown，而是 legacy present 语法。

在这种语法中，代码范围内部出现的单个反引号会被转换为空格。

因此：

`package`rand`

`package`rand`

最终表示的是：

package rand

package rand

源文件本身没有错误，正式页面投影也没有破坏这段内容。

六、真正的问题发生在 Protected Token 层

虽然官方源码和最终页面渲染都正确，但项目自己的保护器没有完整理解这套 present 语法。

原保护器使用的正则类似于：

`[^`\n]+`

`[^`\n]+`

这个正则遇到第一个后续反引号时，就会认为行内代码已经结束。

因此：

`package`rand`

`package`rand`

被错误拆分为：

`package`

`package`

以及没有受到保护的：

rand`

rand`

模型实际收到的页面片段类似于：

... statement ⟪GTI18N_f769f12c_000006⟫rand`.

... statement ⟪GTI18N_f769f12c_000006⟫rand`.

其中，Protected Token 只对应 `package`，后面的 `rand“ 仍然作为普通文本发送给模型。

这次 GLM-5.2 恰好没有修改剩余内容，所以 Token 恢复后，candidate 仍然得到了原始的合法 present 写法。

但这种成功存在明显偶然性。

模型以后完全可能：

• 移动 rand；
• 删除末尾反引号；
• 把 rand 当成普通英文处理；
• 调整 Token 与 rand 的顺序。

因此，即使当前 candidate 能够通过 validator，这个保护逻辑仍然必须修复。

七、修复 legacy present 行内代码保护

修复后，保护器能够把整个 present 行内代码识别为一个完整单元。

现在：

`package`rand`

`package`rand`

会被整体映射为：

⟪GTI18N_f769f12c_000006⟫

⟪GTI18N_f769f12c_000006⟫

其语义内容是：

package rand

package rand

Token 恢复时，则逐字还原为官方原始 present 源码：

`package`rand`

`package`rand`

最终仍由 present 正确渲染成：

<code>package rand</code>

<code>package rand</code>

本次修复增加了相应的回归测试，覆盖：

• 普通单词行内代码；
• 包含一个内部空格的代码；
• 包含多个内部空格的代码；
• 代码后的标点边界；
• Protected Token 的完整映射；
• Token 恢复后的逐字还原；
• candidate validator 的结构比较；
• Basics Packages 页面中不再残留未保护的 `rand“。

这次问题再次说明：

candidate 与 source 结构一致，并不代表进入模型前的 source 保护过程一定正确。

如果保护器首先错误拆分了合法源码，那么模型响应与错误保护结果保持一致，也可能通过后续校验。

因此，除了验证模型输出，还必须为保护器本身建立与官方 present 解析行为一致的测试。

八、原计划测试 DeepSeek，但最终暂时搁置

上一篇项目实录的最后，我原本计划先暂停继续翻译页面，对 DeepSeek 的新版本进行一次测试，再决定 A Tour of Go 项目后续主要使用哪个模型。(永夜)

当时考虑 DeepSeek，主要有两个原因。

第一，GLM-5.2 的付费 Tokens 已经消耗了不少。如果后续要翻译全部 103 个页面，甚至扩展到其他语言，就有必要评估是否存在质量、速度和成本更合适的模型。

第二，DeepSeek 官方刚刚发布了新的模型更新。我原本希望使用同一个完整课程页面，在完全相同的条件下比较：

完整课程页面
→ 相同的 Protected Token
→ 相同的 glossary
→ 相同的提示词要求
→ 相同的 present 解析和结构校验
→ 比较中文质量、首次通过率、速度和费用

完整课程页面
→ 相同的 Protected Token
→ 相同的 glossary
→ 相同的提示词要求
→ 相同的 present 解析和结构校验
→ 比较中文质量、首次通过率、速度和费用

此前，我确实已经对 deepseek-v4-pro 与 GLM-5.2 做过一次比较。

但那次测试发生在 WordPress 技术博客翻译场景中，而不是 A Tour of Go 课程页面翻译场景。

当时的目标，是评估 DeepSeek 是否值得接入现有的 WordPress 博客整篇翻译流程。测试脚本向两个模型提供相同的中文内容、提示词，以及标题、摘要和正文测试字段。

测试结果表明：

• DeepSeek V4 Pro 的响应速度更快；
• 标题更加简洁，但遗漏了一部分技术信息；
• 摘要更倾向于压缩和重组内容；
• 正文存在少量段落衔接和指代问题；
• GLM-5.2 对原文信息的保留更加完整；
• GLM-5.2 的技术文章语气和段落独立性更加稳定。

因此，当时得到的准确结论并不是“DeepSeek 在 A Tour of Go 翻译中不如 GLM-5.2”，而是：

在面向 WordPress 技术博客整篇翻译流程的基础 A/B 测试中，DeepSeek V4 Pro 没有表现出足以替换 GLM-5.2 的稳定质量优势。

那次测试也没有继续投入大量时间，把完整的 Gutenberg 长文保护和还原逻辑全部复制到本地 A/B 脚本中。更详细的测试过程可以参考《在 GLM 5.2 之后测试 DeepSeek：一次面向 WordPress 长文翻译的模型对比与取舍》。 (永夜)

这一次原本考虑重新测试，是因为我以为 DeepSeek V4 Pro 已经推出了更新版本。

进一步检查官方更新日志后才发现，2026 年 7 月 31 日完成更新的实际上是：

DeepSeek-V4-Flash-0731

DeepSeek-V4-Flash-0731

官方明确说明：

• 本次只升级 DeepSeek-V4-Flash API；
• DeepSeek-V4-Pro API 没有更新；
• APP 和 Web 端模型也没有更新；
• 正式更新后的 V4-Pro 仍需等待后续发布。(DeepSeek API Docs)

当时的官方文档还显示，Responses API 只支持 deepseek-v4-flash，deepseek-v4-pro 的相关支持预计在 2026 年 8 月上旬加入。(DeepSeek API Docs)

我真正希望重新评估的是更新后的 Pro 版本，而不是以速度和成本为主要优势的 Flash 版本。

如果现在继续调用 deepseek-v4-pro，实际测试的仍然是此前已经评估过、尚未完成新一轮更新的模型。

这种情况下，即使重新跑一遍 A Tour of Go 页面，也很难得到真正有意义的“新版本对比”结论，只会额外消耗：

• 开发时间；
• API Tokens；
• Codex 使用额度；
• 模型适配与结果分析成本。

因此，最终决定是：

暂时搁置本轮 DeepSeek 对比，继续使用已经完成校准的 GLM-5.2 推进项目。

这里的“搁置”并不是永久排除 DeepSeek。

等到 DeepSeek 官方真正发布新的 V4-Pro 版本，并且能够确认模型版本或实际能力已经发生变化后，再使用 go-tour-i18n 现有的统一流程进行测试：

• 相同页面；
• 相同 Protected Token；
• 相同 glossary；
• 相同翻译提示词；
• 相同 candidate validator；
• 相同页面渲染和结构校验。

这样得到的结果才具有真正的比较价值。

九、GLM-5.2 当前表现如何

从目前完成的正式技术页面来看，GLM-5.2 的整体表现比较稳定。

截至 basics/3，尚未发现：

• Go 技术概念的明显误译；
• 关键内容遗漏；
• 模型自行增加解释；
• .play 路径损坏；
• 行内代码内容变化；
• 预格式化代码变化；
• present 页面结构损坏；
• 链接 target 被修改。

三个 Basics 页面的大致情况是：

• basics/1：基本可以直接使用；
• basics/2：需要轻微中文润色；
• basics/3：需要轻微中文润色。

目前需要调整的内容，主要集中在中文表达，而不是技术准确性。

例如：

• 标题过于字面；
• 句子保留英文语序；
• “是更好的风格”一类机械表达；
• “再试一次”没有准确描述实际操作；
• Go 专用术语不够简洁。

这说明 GLM-5.2 已经能够可靠完成完整技术页面的初始翻译，但还不能仅凭前三个简单页面，就直接证明剩余所有复杂页面都可以完全无人观察地批量发布。

十、不会继续把剩余页面全部逐页推进

项目初期采用的是严格的单页流程：

完整课程页面
→ GLM-5.2 整页翻译
→ 保存 candidate
→ 自动校验
→ 检查中文质量
→ 更新 glossary 或保护规则
→ ready

完整课程页面
→ GLM-5.2 整页翻译
→ 保存 candidate
→ 自动校验
→ 检查中文质量
→ 更新 glossary 或保护规则
→ ready

这种方式非常适合最初几个页面。

它已经帮助项目发现并解决：

• production 页面投影问题；
• 本地执行与远程执行的语义差异；
• 固定 UI 术语问题；
• 普通正文与专有名称的区别；
• legacy present 行内代码问题；
• 开发阶段重试限制问题；
• 中文提示词中的机械表达问题。

但是，如果剩余九十多个页面仍然一篇篇翻译、返回、评审、修改、提交，整体效率会非常低。

而且，连续翻译 Basics 开头的短页面，无法覆盖整个 A Tour of Go 的结构和技术复杂度。

因此，接下来不会直接继续 basics/4，而是改成三阶段推进。

十一、下一阶段先选择代表页面

第一阶段将从不同章节挑选约 5～7 个有代表性的页面。

这些页面应尽量覆盖：

• 较长的技术说明；
• 练习页面；
• 特殊 present 结构；
• 方法与接口；
• 泛型；
• goroutine 与 channel；
• .image 页面；
• 其他少见 directive。

这批页面仍然采用单页翻译和完整评审。

目标不是继续增加 ready 数量，而是尽快确认：

• 保护器是否仍然遗漏其他 present 语法；
• GLM-5.2 是否能准确处理复杂 Go 概念；
• glossary 是否已经足够稳定；
• System Prompt 是否还需要调整；
• 长页面是否会出现截断、重复或上下文问题。

十二、代表页稳定后试跑 10 页

代表页面完成后，将一次自动翻译 10 个普通 pending 页面。

这 10 页作为全量运行前的试生产批次。

主要观察：

• 是否全部通过结构和 candidate 校验；
• 是否再次出现需要修改保护器的问题；
• 是否出现技术概念误译；
• glossary 是否发生大范围冲突；
• 是否需要继续调整 System Prompt；
• 多数页面能否直接使用或只需很轻的润色。

这一步将不再每翻译一页就暂停和提交，而是完成一个批次后统一分析。

十三、最后才进行剩余页面的批量翻译

如果代表页面和 10 页试跑都保持稳定，就可以让程序自动处理剩余页面：

pending
→ 自动翻译
→ 自动验证
├─ 通过 → ready
└─ 失败 → 有限重试
             └─ 仍失败 → blocked

pending
→ 自动翻译
→ 自动验证
├─ 通过 → ready
└─ 失败 → 有限重试
             └─ 仍失败 → blocked

进入 blocked 的页面，可以导出完整页面，由 ChatGPT 重新翻译，再进入同一套自动校验。

需要特别说明的是：

批量自动翻译不等于自动发布。

即使剩余页面全部生成 candidate，仍然需要完成：

• present 重新解析；
• 页面结构比较；
• .play、.image 和链接校验；
• HTML 渲染验证；
• 页面路由验证；
• 章节级抽样；
• 全站发布前检查。

只有通过这些检查的页面，才允许进入最终发布流程。

十四、当前阶段总结

截至目前，go-tour-i18n 项目已经完成：

• 固定官方 upstream commit；
• 103 个正式发布页面目录；
• 2 条条件源页面审计记录；
• Welcome 章节全部翻译；
• Basics 前 3 页翻译；
• 共 8 个 zh-CN 页面进入 ready；
• GLM-5.2 请求、响应和验证记录留存；
• candidate 与页面状态管理；
• 中文 glossary 逐步积累；
• 正式发布远程执行语义修正；
• legacy present 行内代码保护修复；
• source SHA 与上游内容跟踪；
• candidate validator；
• 开发模式与正式模式重试区分；
• 跨章节代表页、10 页试跑和全量翻译策略；
• 核实 DeepSeek 本轮只更新 V4-Flash，因 V4-Pro 尚未更新而暂缓模型对比。

项目开始时，我原本以为最主要的问题是：

AI 能不能把 Go 教程翻译好？

真正开始实现以后才发现，模型翻译只是整个系统中的一个环节。

一个可以长期维护的多语言项目，还必须解决：

• 页面身份如何保持稳定；
• 上游更新如何同步；
• 正式发布投影如何生成；
• 特殊语法如何正确保护；
• 模型调用如何审计；
• 自动校验如何避免误判；
• 术语如何保持一致；
• 本地运行和生产运行如何区分；
• 失败页面如何恢复；
• 模型何时值得重新评估；
• 什么时候才适合进入批量翻译。

目前只完成了 8 个页面，但项目的翻译、校验和状态管理基础已经逐渐稳定。

接下来最重要的事情，不是尽快把数字从 8 页增加到几十页，而是通过少量有代表性的复杂页面，确认整个流程是否真的具备安全批量运行的条件。