分类： Go Tour
-
在完成 A Tour of Go 简体中文 103 个正式课程页面的 ChatGPT 全量重译后，我没有立即覆盖现有正式译文，而是继续进行了完整语义质量审核，并使用 A/B/C/D 四级标准区分“可以直接发布”“可选优化”“建议修订”和“必须修复”。审核过程中曾有 2 页处于 B 级，本身已经达到发布质量，但由于最终只剩少量页面且修改成本很低，仍继续 revision，最终达到 A=103、B/C/D=0。随后项目进一步完善 canonical promotion 的 evidence chain、retry provenance 与 EOF normalization，确认每个正式 candidate 都能追溯到对应的 ChatGPT 原始译文和最终有效 attempt。正式 apply 后 103 页中 102 页发生变化，80 页完成确定性 EOF normalization，再次 dry-run 得到 0 changed、103 unchanged，完整测试最终通过。结合 103 页全量重译、完整语义审核和统一工程验证，我对当前 zh-CN 的内部综合质量评价由原来的约 94 分提高到约 98 分。
-
在 A Tour of Go 简体中文项目中，上一篇实验已经确认 ChatGPT 值得作为新的 Translation Engine 继续扩大验证。本轮进一步将实验扩展到全部 103 个正式课程页面，并通过固定 retranslation batch、GitHub 数据交接、ChatGPT 整页翻译、raw response 保存、restore、统一 validator 与有限 retry，完成 103/103 全量重译。整个过程没有改变原有完整 present.Section 翻译单元和结构校验体系，而是利用 ChatGPT + GitHub 减少大量人工复制粘贴，并通过 11 个 Batch、独立 Git 提交和历史 evidence 保留，使新的 ChatGPT 译文能够进入可追踪、可校验的工程流程，为后续完整语义审核和 canonical promotion 做好准备。
-
在完成 A Tour of Go 简体中文 103 个课程页面后，我继续验证如何把现有约 94 分的工程性翻译质量进一步提升到 96～97 分。最初重点研究 minimal-protect，希望通过减少 protected token、保留更多原始上下文改善 GLM-5.2 译文，但后续对 157 个 protected token 的信息损失审计、Static Context 实验以及重复请求测试均未显示稳定质量优势，因此优化重点从 Protection Policy 转向 Translation Engine。本轮选取 methods/24、concurrency/7、concurrency/11 三个代表页，由 ChatGPT、Codex Sol 和 GLM-5.2 独立生成最终译文，再交给 ChatGPT、DeepSeek、GLM-5.2 和豆包进行 12 次匿名质量评审。ChatGPT 获得 8/12 第一名，即使排除自身作为评审模型后仍获得 5/9 第一名。现阶段不会立即覆盖已有 103 页，而是准备进一步验证自动化 ChatGPT retranslation staging，在统一 validator 和页面验证基础上评估是否值得全量重译。
-
在 A Tour of Go 简体中文翻译流程中，我一直担心大量 protected token 会遮挡模型上下文，从而影响 GLM-5.2 的翻译质量。为验证这一点，我先将保护策略缩减到 minimal-v1，又进一步设计了只额外暴露静态代码的 Static Context 单变量实验。结果却逐渐指向另一个问题：7 个代表页中的 157 个保护标记并没有隐藏任何可翻译英文自然语言，而完全相同的 API Request 在 5 个页面上全部生成了不同的 Response。随后通过 5 页、2 种模式、3 次独立运行共 30 个计划样本，并对所有通过结构校验的译文进行匿名多候选排名，最终发现模型自身的运行间波动明显大于目前能够观察到的 Static Context 质量收益。基于这一结果，正式翻译流程继续保留成熟的 Default protected-token 方案，而 minimal-v1 与 Static Context 保留为开发实验能力。
-
A Tour of Go 简体中文第一阶段 103 个课程页面已经全部进入 ready 状态。在现有版本已经具备较高翻译质量和完整发布能力后，我重新评估此前暂时搁置的 minimal-protect 翻译模式。当前 zh-CN 译文工程性估计约为 94 分，而成熟的 minimal-protect 目标希望达到 96～97 分。通过 methods/24 的真实实验可以看到，raw-input 会错误修改 .play 指令，而 minimal-protect 只保护完整 .play 后成功消除了这一问题，同时让 validator 继续发现 link inline-code 和 font span 等下一层结构差异。同页对比中，默认 protected-token 使用 15 个保护 token，而 minimal-protect 仅使用 1 个，更多原始上下文可以直接交给 GLM-5.2。后续将继续使用原有 7 个代表页验证翻译质量、结构稳定性、重试成本和跨语言保护规则的复用程度，再决定是否正式切换默认模式。
-
A Tour of Go 简体中文站点完成 Sitemap 提交后，进一步实测 Google、Bing、360、百度与搜狗的实际索引状态。Google 已开始自然抓取并建立索引，Bing 已发现页面但尚未抓取，因此通过 IndexNow 一次主动提交全部 104 个 URL；百度普通收录 API 则受每日 10 条额度限制，最终只提交首页和核心课程入口。结合 360 暂无索引数据以及搜狗主站“收录量高、索引量低”的实际表现，最终决定停止持续人工主动提交，让后续页面依靠 Sitemap、内部链接和搜索引擎自然抓取完成收录。
-
在 A Tour of Go 多语言项目的 Playground 浏览器直连代理稳定运行后，继续补齐第三方调用身份识别。根据 Go Playground 官方对第三方服务的使用说明，在 ZgoCloud Nginx 的 /compile 与 /fmt 转发请求中统一增加项目级唯一 User-Agent go-tour-i18n/1.0 (+https://github.com/shuijingwan/go-tour-i18n)，避免绑定具体语言或服务器。完成 Nginx 配置检查及 Compile、Format、CORS、方法限制等生产回归后，又向 golang-dev 公开邮件列表发送使用告知，使当前 Playground 调用链在保持正常运行的同时具备稳定、可识别且适合未来多语言扩展的项目身份。
-
记录 A Tour of Go 中文版在手机端出现“运行”和“格式化”偶发失败后的排查过程。通过微信、自带浏览器、QQ 浏览器、百度 APP，以及 Wi-Fi、5G 等不同环境反复测试，确认问题无法稳定复现；进一步分析 ZgoCloud Nginx 日志后发现，当天所有正常进入服务器的 /compile、/fmt 请求均返回 200/204，但部分前端失败无法与现有日志完整对应。为避免在根因不明确时贸然修改生产架构，最终为 Playground 增加独立 JSON 访问日志和专用错误日志，补充请求耗时、上游状态和上游响应时间等观测信息，为下一次真实故障留下更完整的排查证据。
-
A Tour of Go 新的 ZgoCloud Playground 执行节点搭建完成后，本文继续记录生产端 Run / Format 的实际切换过程：从代码审计、统一 Playground 基础地址、生产与本地运行模式隔离，到 release manifest、自动部署脚本和生产发布同步更新。上线后还遇到了 EdgeOne 缓存旧 /tour/script.js，导致浏览器继续请求旧 /_/compile 的问题；定向清除缓存后，Run 与 Format 最终成功切换到 ZgoCloud，并通过桌面浏览器和手机真实网络环境验收。
-
A Tour of Go 简体中文版上线后，生产环境访问 Go 官方 Playground 偶发出现 TLS 握手超时。本文记录如何在现有 ZgoCloud 服务器上新增独立 Playground 执行节点，通过 Nginx、HTTPS 8443、CORS 与固定接口转发，将 /compile、/fmt 请求直接发送至 play.golang.org，同时保持原有网络服务不受影响，并完成连续真实编译、格式化和安全边界验收。