今天完成了 A Tour of Go 西班牙语 es-ES 的首次 Production 上线。
如果只看最终结果，这次上线并不复杂：翻译、Quality Check、Final Review、Locale Surface Review、Preview、Production、浏览器验收，最后正式进入 live。
但真正有价值的部分，其实发生在上线之后。
这次 es-ES 首次 Production 暴露出了几个以前存在、但还没有完全标准化的问题。既然下一门语言还要继续复用同一套流程，我没有选择“这次能上线就算了”，而是趁着真实现场和失败 evidence 都还在，把这些问题逐个收敛进正式流程。
最后一共处理了 6 类问题：
- Cloudflare API 瞬态网络失败的容错；
- first-production 公网机器验收与公共 Production verifier 的重复；
- 首次 Production 最终收口仍依赖人工修改文件；
- 当前
livelocale 列表散落在多个文档和测试中； - Google / Bing sitemap 提交没有正式进入新增语言流程；
- Locale Surface Review A gate 因无关 Production identity 变化而过度 stale。
这篇文章记录这次从真实上线问题反推流程标准化的过程。
一、es-ES 上线后，当前已经有 6 个正式 Production locale
西班牙语上线并完成最终收口之后，我先重新检查了一下正式 Production identity：
python3 scripts/production-identity.py list --state live目前共有：
zh-CNja-JPde-DEfr-FRko-KRes-ES
6 个 locale 处于 live 状态。
这次后续优化里，一个很重要的方向，就是进一步明确：
production/identity.json才是 Production 状态的唯一 machine authority。
以前 README、语言说明、运行手册乃至部分测试里，都还会手工枚举“当前有哪些 Production locale”。
语言少的时候感觉没什么问题，但每增加一门语言，都要同步修改一堆地方，时间久了必然产生 drift。
这次正好一起解决。
二、第一个真实故障：Cloudflare API 超时不应该直接让首次上线失败
这次首次 Production 最直接暴露出来的问题，是 Cloudflare API 的瞬态失败。
实际运行时，我遇到了这样的错误：
[首次生产] FAILED
stage: preflight
expected: command exit 0
actual: curl: (28) Operation timed out after 5000 milliseconds with 0 out of 0 bytes received
[first-production:aliyun] ERROR: Cloudflare zone lookup failed
这里最初的问题并不是配置错误，也不是 zone 不存在，而只是一次网络请求超时。
如果这种瞬态问题直接让整个首次 Production 失败，那么随着 locale 越来越多，Production 自动化反而会变得越来越脆弱。
所以这次给 Cloudflare API 增加了正式的 bounded retry。
但这里不能简单粗暴地：
失败 → 再 POST 一次特别是 DNS mutation。
因为某一次 POST 如果已经到达 Cloudflare，只是客户端没有收到响应，那么再次 POST 就存在重复创建的风险。
最终处理逻辑变成了更严格的状态机：
查询当前状态
↓
已经 exact → 成功，不 POST
不存在 → 允许 POST
冲突 → 直接失败
POST 结果未知
↓
重新查询真实状态
↓
exact → 视为成功
absent → 才允许下一次 mutation attempt
conflict → fail closed同时限定：
- 最多 3 次；
- 只对明确的 transient curl failure 重试；
- 使用 1 秒、2 秒 backoff；
- 非 transient error 不重试；
- 最终仍然失败就 fail closed。
这比单纯增加一个 curl --retry 更重要，因为它解决的是：
网络失败时，如何保证 mutation 仍然具有可推理的状态。
三、第二个问题：first-production 自己又做了一遍 Production 验收
处理网络稳定性以后，又发现了一个流程层面的重复。
首次 Production 自己检查了很多内容，例如：
- public routes；
- canonical；
- sitemap；
/socket；- CDN cache；
- HTML identity。
但仓库本来已经有正式的：
scripts/verify-production.sh <release-dir>它也会检查这些东西。
也就是说，一次首次上线过程中，很多公网请求实际上被执行了两遍。
这不仅浪费时间，还增加了：
- CDN 请求；
- DNS / 网络瞬态失败机会；
- 两套 validator 行为逐渐漂移的风险。
所以这次重新划分了职责。
first-production 现在只保留：
DNS 完成
→ 最小公网 readiness
→ 正式 hostname 首页 200
→ html lang 正确确认公网已经具备验收条件以后，只调用一次：
VERIFY_PRODUCTION_NETWORK_SSH=zgocloud \
scripts/verify-production.sh <release-dir>然后由公共 verifier 负责：
routes
canonical
lang
sitemap 105/105
/socket
CDN cache
remote identity这样首次 Production 不再维护第二套类似的机器验收实现。
四、第三个问题：所有验收都通过了，最后居然还要手工改 lifecycle
这次让我感觉最值得优化的，是首次 Production 的最后一步。
之前流程大致是：
machine PASS
→ browser PASS
→ HUMAN visual PASS
→ 手工修改 Surface Review evidence
→ 手工把 production_state 从 first-production 改成 live
→ 再验证最后两步其实已经完全是机械操作了。
真正不能被机器替代的只有：
HUMAN visual gate。
所以这次新增了正式命令：
go run -mod=readonly ./cmd/tour-i18n first-production finalize \
--release-dir /tmp/go-tour-release-YYYYMMDD-<locale>-<shortsha> \
--review-id YYYYMMDD-first-production新的 finalizer 会先自动检查：
release.json
→ first-production receipt
→ locale / hostname / release identity
→ public-machine PASS
→ browser PASS
→ Locale Surface Review A gate current全部通过以后，才显示真正的 HUMAN gate。
维护者必须在真实 TTY 中明确输入：
VISUAL-PASS程序才会继续。
这里我特意保留了几个严格限制：
- 必须真实 TTY；
- 不存在
--yes； - 不允许环境变量绕过；
- 没有默认值；
- EOF 直接失败；
- 输入错误直接失败。
也就是说，程序可以记录：
maintainer 已确认 visual gate passed
但不能自己声称：
我已经看过页面，视觉效果正常。
确认完成以后，finalizer 才机械完成：
Surface Review finalization evidence
+
production_state:
first-production → live并在出现异常时回滚，避免 evidence 和 identity 只成功修改一半。
这一步以后，新增语言最后的 Production 收口不再需要 Codex 手工修改 lifecycle。
五、第四个问题：每增加一个 live locale，为什么要到处修改“当前语言列表”？
es-ES 上线以后，我还注意到一个长期维护问题。
之前仓库里很多地方都写着类似：
zh-CN、ja-JP、de-DE、fr-FR、ko-KR、es-ES包括：
- README；
LANGUAGES.md；- Production Runbook；
- production identity tests；
- preview browser tests。
今天是 6 门语言。
下一门语言上线以后，就会变成 7 门。
如果每次都靠维护者记得去更新所有地方，这些静态列表迟早会不一致。
于是这次把职责进一步收敛：
production/identity.json
↓
Production machine authority新增只读查询：
python3 scripts/production-identity.py list以及：
python3 scripts/production-identity.py list --state live测试如果需要“所有正式 Production locale”，就动态读取 authority，而不是写死：
("zh-CN", "ja-JP", "de-DE", "fr-FR", "ko-KR", "es-ES")README 和运行手册也不再维护不断变化的“当前完整 locale 集合”。
而 LANGUAGES.md 仍然保留语言展示 registry，因为它还有另外的职责：
- English 官方入口；
- autonym；
- 展示顺序；
- 社区语言入口；
- CDN 架构说明。
换句话说：
去掉的是重复的 lifecycle authority，而不是把所有 locale 信息粗暴地塞进一个文件。
改完以后得到一个很满意的结果：
下一门 locale 从
first-production切换为live时，因为“current-live 列表同步”额外需要修改的文件数量：0。
六、第五个问题：Google Search Console 和 Bing 不应该靠上线之后临时想起来
es-ES 正式上线以后，我还手工完成了：
- Google Search Console sitemap 提交；
- Bing Webmaster Tools sitemap 提交。
这个动作本身不复杂。
真正的问题是：
它之前没有正式出现在新增 locale 的标准生命周期里。
这样下一次增加新语言，很容易出现：
Production 都完成了
→ 过一会儿才想起来
→ 好像还没提交 sitemap所以现在新增 locale 的正式顺序增加了一步：
production acceptance
→ visual HUMAN gate
→ first-production finalize
→ production_state=live
→ search-engine submission closeout所有新 Production locale：
- Google Search Console；
- Bing Webmaster Tools；
都作为标准 closeout。
但是这里明确不把搜索引擎状态升级为 Production gate。
也就是说：
没有被 Google 收录
≠ Production 未完成更不会等待 Search Console indexing / coverage 变绿以后才把站点标记为 live。
另外像韩语站使用的：
Naver Search Advisor仍然只是 locale / market-specific search engine。
不会因为 ko-KR 需要 Naver，就要求西班牙语、法语、德语也全部提交 Naver。
七、第六个问题：一个 locale 上线，为什么会让其他 locale 的语言审核 gate stale？
这是这次最后处理的一个比较隐蔽的问题。
Locale Surface Review A gate 会对影响语言质量和页面 identity 的输入做 SHA-256。
原来的设计里还包括：
整个 production/identity.json问题在于：
假设 es-ES 从：
first-production切换为：
live整个 production/identity.json 的 SHA 就变了。
于是刚刚才完成的 Surface Review A gate 会立即变 stale。
甚至完全无关的：
- 另一门语言改端口；
- systemd service 调整；
- CDN 配置变化；
- data root 修改；
也可能导致目标 locale 的语言质量审核失效。
这明显超出了语言审核真正应该负责的范围。
所以现在 A gate 升级为 schema v2。
v2 只绑定目标 locale 的 public identity：
locale
production_hostname
production_public_url而不再绑定：
production_state
port
service
data root
release/current/lock
TLS/vhost
CDN/cache
其他 locale profile这样：
first-production → live不再让语言质量 gate 无意义地 stale。
但如果真正影响公开页面 identity 的内容变化，例如：
hostname
public URL
languages.go
UI
glossary
SEO metadata
course metadataA gate 仍然会 stale。
同时历史 schema v1 不会被偷偷重新解释。
旧 v1 receipt 仍然按照原来的整份 production/identity.json SHA 规则验证。
这样既消除了新流程里的过度 invalidation，又没有篡改历史审核 evidence 的语义。
八、这次不是一个修复，而是一整条流程的收敛
完成以后回头看 Git log，这次改动其实非常集中：
截图中可以看到：
790d379 refactor: 收敛 Surface Review A 身份范围
f2404d9 docs: 补充新增语言搜索引擎收口
b5f39fc refactor: 收敛 production locale 状态来源
2cf39e9 feat: 自动化首次生产最终收口
5965f3e refactor: 去重首次生产公网验收
f7685e8 fix: 完善首次生产 Cloudflare API 容错
c9a8880 chore: 完成 es-ES 首次生产收口
d364c96 fix: 提升首次生产公网验收稳定性这也是我现在越来越喜欢的一种项目维护方式：
不是每新增一门语言就重新设计流程，而是：
复用正式流程
→ 遇到真实 failure
→ 保留 evidence
→ 修正通用流程
→ 后面的 locale 直接继承这样每多上线一门语言，理论上下一门语言应该越来越轻，而不是越来越复杂。
九、最终 Production 验收已经能够完整跑通
优化前，这次 es-ES 实际 Production 最后已经完成了完整机器和浏览器验收：
release identity: PASS
remote identity: PASS
source routes: 7/7 PASS
public routes: 7/7 PASS
html identity: PASS
sitemap: 105/105 PASS
socket boundary: PASS
CDN: PASS
PRODUCTION MACHINE ACCEPTANCE: PASS随后：
desktop routes: PASS
mobile: PASS
Run / Format / Reset / SPA / ads: PASS
PRODUCTION BROWSER ACCEPTANCE: PASS最后进入：
READY FOR HUMAN VISUAL GATE
截图里还有一条 SSH 关于 post-quantum key exchange 的 warning。
它不是这次 Production acceptance 的失败项，所以本次没有把它和 locale 上线流程混在一起处理。
这也属于我现在比较坚持的一点：
真实问题归真实问题，不因为在日志中刚好同时出现，就把所有东西塞进同一个修复。
十、全部修改完成以后，再跑一次组合回归
6 个问题处理结束以后，我最后重新执行了整套相关测试：
go test -mod=readonly -count=1 ./...
python3 scripts/production-identity.py validate
python3 scripts/production-identity-test.py
python3 scripts/first-production-test.py
python3 scripts/verify-preview-browser-test.py
bash -n \
scripts/verify-production.sh \
scripts/verify-production-test.sh
bash scripts/verify-production-test.sh
git diff --check
git status --short最终：
Go tests: PASS
production identity: PASS
first-production tests: 26/26 OK
preview browser tests: 23/23 OK
verify-production-test: PASS
git diff --check: clean
working tree: clean期间测试输出里会出现例如：
production identity error: unknown production locale: it-IT或者：
public URL must be an HTTPS origin ending in /这些是测试故意构造的负向 case。
最终 test suite 为 OK，说明 fail-closed 分支也正常工作，并不是回归失败。
十一、下一步还有一个想验证的方向：把 Translation batch 扩大到 60 Pages
这次流程方面确定的问题已经全部收口。
不过还有一个我暂时没有写进正式规范的效率实验。
现在正式翻译使用：
Codex GPT-5.6 Sol High翻译时 Codex 一次读取：
manifest.json
+ 全部 inputs/*
+ locale glossary再写入整个 batch 的 raw responses。
从最近几门语言的实际消耗来看，模型每启动一个 batch，本身就有固定的上下文读取和推理成本。
所以我准备下一门语言尝试：
60 Pages
+
剩余 Pages
+
Examples 独立 batch而不是继续保持更小的 Page batch。
但目前我没有把“60 Pages”写进正式 runbook。
原因也很简单：
这是一个优化假设，还不是经过验证的生产基线。
下一门语言会实际观察：
- Codex 执行时间；
- 周额度消耗；
- automatic validation failure；
- Quality Check A/B/C/D；
- revision 数量。
如果一次处理 60 个完整 TranslationUnit 确实能够明显节省额度，而且质量没有下降，再考虑把它升级为推荐生产配置。
在那之前，它只是下一轮受控实验。
总结
这次西班牙语上线，最终给我的收获并不仅仅是：
又多了一个
es-ES站点。
更重要的是，真实 Production 又帮我找出了几处只有实际跑完整流程才容易发现的问题。
这次处理以后，新 locale 的后半段流程已经变成：
Production deploy
→ 最小公网 readiness
→ 公共 production verifier
→ browser acceptance
→ HUMAN visual gate
→ first-production finalizer
→ production_state=live
→ Google / Bing submission closeout而且：
- Cloudflare transient failure 有正式容错；
- DNS mutation 不会盲目重复 POST；
- 公网验收不再执行两套；
- HUMAN gate 仍然必须由人确认；
- lifecycle 的机械修改已经自动化；
production/identity.json成为唯一 Production machine authority；- 新增 live locale 不再需要同步多份静态列表；
- Surface Review A 不再因为无关 infrastructure mutation 失效；
- Search Console / Bing 也正式进入上线后的标准 closeout。
这也是这个项目最近越来越明显的变化：
最开始是在“把一门语言翻译出来”。
现在更像是在建设一条可以长期重复运行的：
多语言翻译、审核、上线、验收和维护生产线。
而随着正式 locale 越来越多，我真正希望看到的并不是流程越来越复杂。
恰恰相反：
每一门新语言暴露一次问题，修进通用流程；下一门语言就少踩一次坑。
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 官方无隶属或授权关系。