2026 年 8 月 2 日，我正式开始推进 go-tour-i18n 项目的简体中文翻译，并完成了第一个页面 welcome/1 的完整翻译闭环。
在上一篇文章《A Tour of Go 多语言翻译项目实录：完成首个 zh-CN 页面翻译闭环》中，我记录了页面投影、术语表、Protected Token、开发阶段重试机制以及首个中文 candidate 的生成过程。
经过第二天的继续开发，目前项目已经完成 8 个简体中文课程页面：
welcome/1welcome/2welcome/3welcome/4welcome/5basics/1basics/2basics/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 个页面：
- Hello, 世界
- 其他语言版本
- 离线使用（可选）
- Go 语言演练场
- 恭喜
其中，第一个页面经历了多次开发 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`
如果按照普通 Markdown 理解，这段内容似乎存在明显问题：
`package`是一个行内代码；rand是普通文本；- 最后还多了一个反引号。
但是，查看官方线上页面的 HTML 后发现，实际渲染结果是：
<code>package rand</code>.
这里的结构完全正确：
package rand是一个完整的代码节点；- 空格位于代码节点内部；
- 英文句号位于
</code>之后。
原因在于 A Tour of Go 使用的不是普通 Markdown，而是 legacy present 语法。
在这种语法中，代码范围内部出现的单个反引号会被转换为空格。
因此：
`package`rand`
最终表示的是：
package rand
源文件本身没有错误，正式页面投影也没有破坏这段内容。
六、真正的问题发生在 Protected Token 层
虽然官方源码和最终页面渲染都正确，但项目自己的保护器没有完整理解这套 present 语法。
原保护器使用的正则类似于：
`[^`\n]+`
这个正则遇到第一个后续反引号时，就会认为行内代码已经结束。
因此：
`package`rand`
被错误拆分为：
`package`
以及没有受到保护的：
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`
会被整体映射为：
⟪GTI18N_f769f12c_000006⟫
其语义内容是：
package rand
Token 恢复时，则逐字还原为官方原始 present 源码：
`package`rand`
最终仍由 present 正确渲染成：
<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 解析和结构校验
→ 比较中文质量、首次通过率、速度和费用
此前，我确实已经对 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-FlashAPI； DeepSeek-V4-ProAPI 没有更新；- 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
这种方式非常适合最初几个页面。
它已经帮助项目发现并解决：
- 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
进入 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 页增加到几十页，而是通过少量有代表性的复杂页面，确认整个流程是否真的具备安全批量运行的条件。
Go 学习与文档多语言本地化项目
本系列完整记录 Go 学习与文档多语言本地化项目从 A Tour of Go 起步，逐步扩展到站点首页、项目说明页、学习内容、文档以及未来内容包的实际开发过程，包括架构设计、统一术语治理、整页翻译、结构保护、自动校验、独立质量审核、生产发布与长期维护。
项目源码：
✅ GitHub：shuijingwan/go-tour-i18n
语言版本：
当前跨项目目标语言池共包含 66 个语言版本。Go 项目本身目前提供 65 个社区 Production 语言版本，下面每一门 Go 语言版本都直接链接到其当前公开站点。语言列表沿用项目首页现有的展示顺序。
英语（美国）仅作为跨项目目标语言纳入列表，并不是单独的 Go Production 语言版本。当前 Go 的英文源内容仍为官方 generic English，因此英语（美国）链接到 Go 官方站点，而不是不存在的本地社区部署。
- 阿姆哈拉语
- 阿拉伯语
- 孟加拉语
- 葡萄牙语（巴西）
- 保加利亚语
- 加泰罗尼亚语
- 克罗地亚语
- 捷克语
- 丹麦语
- 荷兰语
- 英语（美国）（Go 官方英文站点）
- 英语（澳大利亚）
- 英语（加拿大）
- 英语（印度）
- 英语（新加坡）
- 英语（南非）
- 英语（英国）
- 爱沙尼亚语
- 菲律宾语
- 芬兰语
- 法语（法国）
- 法语（加拿大）
- 德语（德国）
- 德语（奥地利）
- 德语（瑞士）
- 希腊语
- 古吉拉特语
- 希伯来语
- 印地语
- 匈牙利语
- 印度尼西亚语
- 意大利语
- 日语
- 卡纳达语
- 哈萨克语
- 韩语
- 西班牙语（拉丁美洲）
- 拉脱维亚语
- 立陶宛语
- 马来语
- 马拉雅拉姆语
- 马拉地语
- 书面挪威语（Bokmål）
- 波斯语
- 波兰语
- 葡萄牙语（葡萄牙）
- 旁遮普语（果鲁穆奇文，印度）
- 罗马尼亚语
- 俄语
- 塞尔维亚语（西里尔文）
- 简体中文（中国大陆）
- 简体中文（新加坡）
- 斯洛伐克语
- 斯洛文尼亚语
- 西班牙语（西班牙）
- 斯瓦希里语（坦桑尼亚）
- 瑞典语
- 泰米尔语
- 泰卢固语
- 泰语
- 繁体中文（台湾）
- 繁体中文（香港）
- 土耳其语
- 乌克兰语
- 乌尔都语
- 越南语
项目正在持续扩展新的 Go 学习与文档内容，并长期维护各语言版本的术语一致性、翻译质量、独立审核、生产发布与后续更新。
本项目属于非官方社区多语言本地化项目，与 Go 官方无隶属、授权或背书关系。