最近一段时间，我一直在思考一个问题：
网站接下来还能从哪里获得新的流量增长？
过去，我原本比较看好英文站。
我的计划是逐步把一部分已有的中文历史文章翻译成英文，通过扩大英文内容规模，让网站获得更多海外搜索流量。我最初甚至希望，这件事情能够带来大约 30% 的流量增长。
但实际运行一段时间以后，目前看到的增长大约只有 10%。
广告收入也没有出现特别明显的提升。
不过，现在显然还不能因此认为英文站的方向没有价值。
一方面，英文站上线时间还不算长，搜索引擎发现、收录和重新建立排名都需要时间。
另一方面，目前英文站的历史文章翻译质量并不完全一致。
早期我先后尝试过 AutoPoly、Chrome 内置 AI、Yandex 等不同翻译方案，后来经过多轮实际测试，才最终确定使用 GLM-5.2 作为目前主要的整篇翻译模型。
因此，现在仍然有相当一部分历史英文文章并不是由 GLM-5.2 翻译的。
我目前正在逐步对这些历史文章重新执行 GLM-5.2 覆盖翻译。
所以，现阶段英文站的流量和广告收入表现，本身仍处于一个不断调整的阶段。
但是，这件事情也让我开始思考另一个方向：
如果只是不断把已经存在的中文内容翻译成英文，短时间内想让网站流量出现明显增长，可能并不容易。
相比之下，如果能够发现一个已经存在明确搜索需求、但现有内容供给恰好出现问题的方向，也许更值得投入时间。
最近，我恰好发现了这样一个机会。
一、从一个真实搜索关键词开始
最近查看网站的 Google 搜索自然查询数据时，我发现了一个很有意思的关键词：
A Tour of Go 中文版
它目前只产生了 1 次展示和 1 次点击，数据量非常小。
但对我来说，真正重要的并不是这 1 次点击，而是这个关键词让我开始关注：
现在还有没有人在搜索 Go Tour 的中文版本？
我平时本来也在持续复习和加强 Go 相关知识，所以看到这个搜索词以后，顺手去搜索了一下当前的 Go Tour 中文版本。
结果发现了一件很有意思的事情。
二、Go 官方仍然保留着简体中文入口
Go 官方目前仍然提供 A Tour of Go：
在 Tour 的语言选择页面中，目前依然可以看到：
Simplified Chinese — 中文（简体）
也就是说，至少从官方页面本身来看，简体中文版本并没有从语言列表中消失。(Go)
这让我自然地点开了这个链接。
它指向过去的中文 Go Tour：
tour.go-zh.org
但现在已经无法正常访问。
三、官方中文入口还在，但目标站已经失效
实际访问 tour.go-zh.org 时，目前无法正常打开。
我这里访问时，Firefox 最终显示：
建立安全连接失败
错误代码为：
PR_END_OF_FILE_ERROR
而从服务器请求结果来看，目前这个域名也无法正常提供 Tour 页面。
这就形成了一个比较有意思的状态：
Go 官方仍然展示简体中文入口，但过去对应的中文站已经无法正常使用。
与此同时，我的网站又实际出现了：
A Tour of Go 中文版
这样的搜索查询。
虽然单次数据远远不能证明存在多大的搜索市场，但至少说明：
这个需求并没有完全消失。
而且它和单纯把自己已有的博客内容翻译成另一种语言，有一些本质上的不同。
前者更像是：
已有中文文章 → 翻译成英文 → 等待新的英文搜索流量。
而 Go Tour 中文版这个方向则是：
用户已经存在相关搜索 → 现有中文入口失效 → 尝试补上这个缺口。
这也是我决定进一步研究这个项目的主要原因。
四、最开始，我只是想重新部署旧的中文版
刚发现这个问题的时候，我的想法其实很简单：
既然以前已经有人做过中文版，是不是直接把旧仓库重新部署起来就可以了？
我也确实找到了相关的历史开源项目。
如果只是为了让网站重新能访问，这显然是最快的方案：
找到旧源码，部署到服务器，配置域名，再接入 CDN。
几乎不需要重新开发。
但继续考虑以后，我逐渐觉得，这并不是一个好的长期方案。
问题并不是：
今天能不能把这个网站重新跑起来。
真正的问题是：
以后官方 A Tour of Go 更新了怎么办？
如果直接使用几年前停止维护的中文项目，那么很可能出现：
官方 Tour 不断更新，而中文版继续停留在过去版本。
几年以后，又会重新遇到今天看到的问题。
所以，我逐渐把目标从：
恢复旧 Go Tour 中文版
调整成了：
重新建立一个能够持续跟随官方版本维护的简体中文 Go Tour。
五、我更关心的不是第一次翻译，而是以后怎么维护
一次把整个 Tour 翻译成中文，其实并不是最困难的事情。
真正麻烦的是：
官方以后更新了怎么办？
例如官方修改一个章节。
中文版需要知道：
这段英文发生过变化；
当前中文译文对应的是旧内容；
因此需要重新翻译；
翻译完成以后还需要重新检查。
所以我希望未来建立的并不是一次性的翻译流程，而是一套持续维护机制。
基本思路是：
官方 Go Tour 更新 → 检测英文内容变化 → 找出需要重新翻译的部分 → 调用 GLM-5.2 → 自动验证 → 人工审核 → 更新中文版本。
这里 GLM-5.2 负责的核心工作只有一个：
翻译。
而程序负责决定：
哪些内容发生了变化；
哪些内容应该翻译；
哪些内容不能修改；
译文是不是已经过期；
代码是否发生变化；
页面结构是否仍然完整；
翻译结果是否符合要求。
这和我过去一段时间不断完善 WordPress AI 翻译流程的思路其实比较接近。
只不过这一次，目标从：
WordPress 中文文章 → 英文
变成：
官方 Go Tour 英文 → 简体中文。
六、为什么选择 GLM-5.2
这个选择并不是项目开始以后再决定的。
因为过去一段时间，我已经围绕 WordPress 历史文章翻译测试过多种方案。
从早期的 AutoPoly，到 Chrome 内置 AI，再到 Yandex 等方案，最后经过多轮实际测试以后，目前整篇内容翻译已经逐渐统一到 GLM-5.2。
与此同时，我还处理过不少 AI 翻译中很容易出现的问题，例如：
代码块不能被错误翻译；
HTML 和 Gutenberg 结构不能被破坏；
技术名词需要保持一致；
特殊结构需要保护；
翻译以后还要做完整性验证；
失败任务要能够重新执行。
这些经验正好可以迁移到 Go Tour 中文版。
而且相比复杂的 WordPress Gutenberg 内容，Go Tour 的内容结构反而更加规整。
因此，这次没有必要再从头重新比较一轮翻译模型。
第一版直接使用：
GLM-5.2。
七、这个项目本身也可以用 Go 来实现
既然目标是 Go Tour，我也希望项目自身尽可能使用 Go。
例如：
官方内容同步；
版本差异检测；
文件解析；
GLM-5.2 API 请求；
翻译状态管理；
结构验证；
术语校验；
CLI；
Web 服务；
最终都可以逐步使用 Go 实现。
这件事情还有一个额外价值。
我平时本来也需要持续复习和加强 Go，而相比单独写一些为了演示语法而存在的 Demo，一个真正需要长期运行的项目显然更适合系统地回顾各种 Go 能力。
例如后面很自然会涉及：
HTTP Client、JSON、文件处理、错误处理、测试、context、goroutine、channel、并发控制、Web Server 等。
这些能力不是为了“练习某个语法”而强行加入项目。
而是项目发展到一定阶段以后，本身就会需要。
所以这个项目最终可能同时承担两个作用：
维护 Go Tour 中文版。
以及：
作为一个长期的 Go 实战项目，用于持续复习和加强 Go。
八、Gin 暂定使用，但不急着重写 Tour
既然决定以 Go 为主要开发语言，Gin 自然也是一个很容易想到的选择。
未来如果做翻译管理 API，例如查看翻译状态、触发重新翻译、查看 upstream 差异等，Gin 很适合处理这些 Web/API 功能。
但是我目前不准备一开始就使用 Gin 重写整个 Go Tour。
原因也很简单：
官方 A Tour of Go 本身就是 Go 项目。
在还没有仔细阅读官方源码以前，直接决定把它重写成 Gin，并没有太大意义。
所以目前的顺序是：
先把官方最新版源码拉下来；
先运行；
再阅读代码；
弄清楚它现有的 Web Server、路由、模板、课程数据和代码运行机制；
最后再决定 Gin 应该放在哪一层。
Gin 很可能最终主要用于：
翻译管理；
内部 API；
状态查询；
同步管理。
而 Tour 本身则尽可能沿用官方已有实现。
这样未来跟随 upstream 更新时，也能减少不必要的修改。
九、中文版域名暂定为 zh.go-tour.shuijingwanwq.com
域名也经历了几次变化。
最开始考虑的是：
tour.shuijingwanwq.com
后来又考虑：
go-tour.shuijingwanwq.com
以及：
go-tour-zh.shuijingwanwq.com
目前我更倾向：
zh.go-tour.shuijingwanwq.com
这里可以理解为：
zh 代表语言；
go-tour 代表项目；
shuijingwanwq.com 则属于现有网站体系。
这样未来如果真的存在其他语言，也可以自然扩展。
例如：
ja.go-tour.shuijingwanwq.com
ko.go-tour.shuijingwanwq.com
当然，目前只是从域名和架构上留下这种可能。
第一阶段只做：
简体中文。
英文版没有必要自己再维护一份，因为官方 A Tour of Go 本身就是英文原版。
十、中文站计划继续使用 EdgeOne
这个项目主要面向中文 Go 用户。
因此，与英文站不同，zh.go-tour.shuijingwanwq.com 第一阶段计划使用 EdgeOne，而不是 Cloudflare。
预计的生产链路是：
用户 → EdgeOne → Nginx → Go 服务
原因主要还是中国大陆访问体验。
这个站未来想承接的搜索需求本身就是：
A Tour of Go 中文版
Go Tour 中文
Golang Tour 中文
等中文关键词。
因此，中文站从第一天开始就应该把中国大陆访问体验作为主要考虑因素之一。
而 CDN 与应用本身保持独立即可。
Go 服务并不需要知道前面究竟使用 EdgeOne、Cloudflare 还是其他 CDN。
十一、中文版的目标不是重新创造一个 Go Tour
关于中文版的内容，我目前反而希望保持克制。
我不准备为了让中文站看起来“更丰富”，就大量加入：
中文学习提示；
额外教程；
自定义知识点；
大量原创扩展。
至少这个项目的核心目标不是这些。
我更加希望：
中文版尽可能和官方英文版本保持一致。
官方有多少章节，中文版就对应多少章节。
官方修改什么，中文版跟随修改。
官方没有的内容，原则上不随意加入。
真正需要重点投入的是：
翻译是否准确。
技术术语是否统一。
代码是否保持原样。
内容是否对应当前官方版本。
官方更新以后能不能及时发现并同步。
即使未来需要增加少量中文版本特有内容，也应该尽量限制在必要的翻译说明、版权信息、版本信息和非官方声明等范围内，而不是改变 Tour 本身的教学内容。
我更希望它最终成为：
一个忠实、准确、持续维护的 A Tour of Go 简体中文版本。
十二、翻译状态不能只有“有中文”和“没中文”
如果目标是长期同步官方版本，那么还需要解决一个很重要的问题：
怎么知道现有译文对应的是哪一版英文？
例如某一段英文今天完成翻译。
半年以后，官方修改了这一段。
即使中文文件依然存在，它也已经不能简单算作：
“翻译完成”。
它实际上应该变成：
译文已过期。
所以以后很可能需要记录：
源内容版本；
源内容 Hash；
翻译对应的源版本；
翻译状态；
审核状态。
最基本的状态可以类似：
new
translated
reviewed
outdated
官方英文一旦发生变化，就自动把对应中文译文标记为 outdated。
这样项目才能真正长期跟随 upstream，而不是靠人工记忆判断哪些地方发生过变化。
十三、术语统一也应该由程序帮助保证
Go 教程里有大量固定技术词汇。
例如：
slice
map
interface
method
receiver
goroutine
channel
如果完全让模型自由翻译，不同页面之间很容易出现不同表达。
所以项目第一阶段就可以建立一份简体中文术语表。
它一方面可以加入 GLM-5.2 的翻译规则；
另一方面，也可以提供给 Go 程序执行自动检查。
这样能够尽量保证：
同一个 Go 概念，在整个 Tour 中保持统一表达。
这里仍然遵循一个原则：
尽量忠实于官方内容，而不是重新解释官方内容。
十四、第一阶段暂时不把广告作为上线条件
这个项目的起点，确实与流量增长和广告收入有关。
如果以后 A Tour of Go 中文版 能够持续获得搜索流量，自然也可以评估商业化。
但是第一阶段，我不准备把：
接入广告
作为项目上线条件。
首先要验证的是：
中文站能不能正常运行；
翻译流程是否可靠；
Google 是否正常收录；
相关中文搜索词有没有持续展示；
用户是否真的会使用中文版 Tour。
只有这些基础问题得到验证以后，再考虑广告更合理。
也就是说，第一阶段的重点还是：
先把产品做出来，并验证真实需求。
十五、这一次准备主要在 VS Code 中开发
这个项目还有一个和最近很多自动化项目不同的地方：
我准备主要在 VS Code 中完成开发。
过去一段时间，我已经大量使用 Codex 和其他 AI 编程工具。
对于服务器排查、WordPress 自动化、批处理工具等任务，这种方式能够明显提高效率。
但是 Go Tour 中文版除了最终结果以外，我还希望利用整个开发过程重新系统地梳理 Go。
所以这一次，我希望自己更多地：
阅读源码；
查看类型；
跟踪调用关系；
使用 Go to Definition；
使用 Find References；
查看测试；
Debug；
分析 Git diff；
理解项目为什么这样设计。
AI 和 Codex 仍然会继续使用。
但角色会有所变化。
相比直接让 AI 一次完成整个模块，我更倾向：
让 AI 辅助分析、解释、Review 和处理具体问题，而开发过程本身尽可能保持可阅读、可理解。
项目推进速度可能会慢一些。
但从长期来看，这个过程本身就是项目价值的一部分。
十六、第一阶段只做一个很小的 MVP
现在没有必要直接翻译整个 A Tour of Go。
第一阶段只需要验证这条路线能不能跑通。
暂定目标包括：
- 获取当前官方 A Tour of Go 源码；
- 在本地正常运行；
- 使用 VS Code 阅读核心代码结构；
- 确定 upstream 与中文项目之间的组织方式；
- 建立自己的 Go 项目；
- 使用 Go 跑通 GLM-5.2 API；
- 完成少量页面的中文翻译；
- 建立基础自动校验；
- 部署
zh.go-tour.shuijingwanwq.com； - 接入 EdgeOne；
- 等待搜索引擎收录；
- 观察真实搜索表现。
第一阶段甚至没有必要翻译几十个页面。
先完成几个页面，把整个：
官方源码 → 翻译 → 校验 → 发布
的链路跑通。
然后再决定是否全量推进。
十七、整个过程还可以形成一个新的博客系列
这个项目还有一个额外的价值。
从最初发现搜索关键词，到源码阅读、翻译系统开发、部署、CDN、SEO 和后续流量验证，整个过程本身就可以持续记录。
后续可以包括：
第一次运行最新版 A Tour of Go；
官方 Go Tour 源码结构分析；
如何设计中文本地化架构；
Go 调用 GLM-5.2 API；
Go 实现翻译状态管理；
如何保护 Go 源码不被 AI 翻译；
如何检测 upstream 更新；
如何判断译文已经过期；
Gin 最终在项目里承担什么职责；
Go 服务生产部署；
EdgeOne 接入；
中文版上线后的搜索收录；
A Tour of Go 中文版 是否真的带来了新增流量。
这样一来，开发本身也会持续产生新的博客内容。
项目推动内容更新，内容又可以继续为网站带来新的搜索入口。
十八、结语
这次项目的起点其实非常简单。
我只是在网站的 Google 搜索自然查询里发现：
A Tour of Go 中文版
产生了一次展示和一次点击。
顺着这个关键词继续看下去，又发现：
Go 官方目前仍然保留着简体中文入口，但过去对应的中文站已经无法正常使用。
于是最开始那个：
要不要把旧中文版重新部署一下？
的想法，逐渐演变成了现在的计划：
基于当前官方 A Tour of Go，重新建立一个能够持续同步、GLM-5.2 辅助翻译、Go 程序自动校验并经过人工审核的简体中文版本。
它希望解决的是一个非常明确的问题：
让 A Tour of Go 重新拥有一个准确、可用，而且能够持续跟随官方更新的简体中文版本。
与此同时，我也希望借这个项目重新系统地复习和加强 Go，把 HTTP、Web、并发、测试、CLI、自动化等内容放到一个真正长期运行的项目里重新串起来。
至于它最终能不能获得预期的搜索流量，现在还不知道。毕竟目前看到的也只是一个很小的搜索信号。但和单纯猜测一个方向不同，这一次至少有一个真实的起点：已经有人搜索了它。 下一步，我准备先把当前最新版 A Tour of Go 源码拉到本地，在 VS Code 中打开项目，先看看这个已经运行多年的官方 Go 项目，到底是怎么实现的。
A Tour of Go 多语言翻译项目
本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验，到生产发布与后续维护的实际开发过程。
项目入口：
✅ 简体中文：A Tour of Go 简体中文版
✅ 日语：A Tour of Go 日语版
✅ 德语：A Tour of Go 德语版
✅ 法语：A Tour of Go 法语版
✅ 项目源码：GitHub：shuijingwan/go-tour-i18n
当前已上线简体中文、日语、德语和法语版本。项目属于非官方社区多语言翻译项目，与 Go 官方无隶属或授权关系。
评论
一条对“从「A Tour of Go 中文版」这个搜索词开始：我决定做一个持续维护的 Go Tour 中文版”的回复
[…] A Tour of Go Chinese Version Project Preliminary Design […]