当自动化成为瓶颈：一次 CI/CD 重构的经验

在这座网站如何通过提示词构建一文中，我介绍过人工智能如何帮助我把旧 WordPress 网站迁移为托管在 AWS S3 和 CloudFront 上的静态网站。我没有预料到，一个原本简单的个人网站会如此迅速地变成复杂的软件项目。

复杂性是怎样不断增加的

最初只是几张网页，随后又加入天气预报、训练数据、游戏、安全扫描、自动发布，以及九种语言。在英文原版之外，我们逐步增加了德语、西班牙语、中文、法语、巴西葡萄牙语、日语、印地语和荷兰语。读者覆盖面扩大了，但每种语言也意味着更多 HTML 文件、导航链接、内容摘要、RSS 和校验逻辑。

我们当时的想法很天真：静态网站构建成本低，所以每次变更都重新生成九种语言应该没什么问题。现实是，即使只修改英文文章，也可能必须等待字体下载、图片生成、其他语言的导航构建、站点地图和安全检查。我们把九种语言都放到了同一条发布关键路径上。

所有语言都要完成才能发布

ENDEESZHFRPT-BRJAHINL

↓

9 种语言

↓

S3 源站

问题不是多语言本身，而是我们设计了错误的依赖关系。

保护措施也可能成为障碍

GitHub 历史记录显示，我们遇到过密钥扫描器阻塞、可重复构建结果不一致、字体安装卡住、工作流配置错误和 AWS IAM 权限缺失。一次部署恢复中，我们核对了 534 个公开对象：501 个符合预期，24 个存在差异，还有 9 个新页面无法读取。

每一项安全措施都有其意义，但叠加在一起，小改动也变得困难。更多自动化并不必然意味着更好的自动化。 检查失败时，应找到根因，而不是为了绿色标记关闭保护。

新设计：先发布英文，再处理八种译文

我们的方向是把主要语言的发布时间与后续翻译分开。

首批发布已批准英文↓S3 源站

后续审核8 种翻译↓S3 源站

越短越好

上图是目标发布顺序，并不是已经在生产环境中验证过的实际时间线。各语言的审核记录通过 SHA-256 绑定到确切的英文源内容。一旦英文源变更，旧审核就自动失效。不能在译文缺失时悄悄用英文页面冒充翻译。

我们依然保留可重复构建、OIDC、最小 AWS 权限、成本限制，以及不进行 CloudFront 缓存失效操作的原则。

我们实际验证了什么

PR #119–#122 引入了英文文章编译器、八种已审核译文的独立编译器，以及英文 → 其他语言 → 完整性检查的执行顺序。手动测试工作流没有 AWS 写入权限。分阶段发布仍受到显式批准变量的限制；现有 OIDC 工作流在上传前仍执行全站验证。

因此，CI 全绿不代表“英文已经上线，而其他语言还在后台处理”。此前的影子测试日志明确显示 sourceToHtmlBuildComplete=false、productionDeploymentApproved=false，以及 0 次 S3 写入。

已测得的时间改善

我们比较了 2026 年 11 月 7 日两次相似的九语言更新记录变更。它们衡量的是完整的旧构建流程，并非两次真正的英文优先生产发布。

越短越好

离线 CI

之前

218 s

之后

198 s

−9.2%

质量检查

之前

175 s

之后

147 s

−16.0%

全站质量门禁包含在离线 CI 中，不能把两项时间相加。安全扫描任务可以并行执行。由于这两次主要是文档变更，Semgrep 和 pip-audit 均跳过了最昂贵的扫描步骤。仅有两次测量也不足以证明长期收益。

优化措施包括避免重复检查相同资源、缓存导航和语言页面的 SHA-256 哈希、复用 Python 与 Sharp 下载、为各构建器计时，以及为纯文档改动提供快速通道。

英文快速通道的测试结果

一次独立的影子基准测试中，英文 HTML 校验仅耗时 0.562 秒，覆盖 60 个英文页面、96 个本地资源及 514 个站内 HTML 链接。模拟的英文合并检查耗时 15 秒，而其他语言的 501 个文件没有被修改。

这些是组件与模拟测试时间，不是“合并到真实 S3 发布”的完整时间。把 15 秒直接和原来的 198 秒比较，会误导读者。

从 Pull Request 到正式上线

PR 并不等于部署。检查、审核和合并之后，发布流程还要核对具体文件、SHA-256 清单、AWS 权限及预算，最后才上传到 S3。CloudFront 按照正常 TTL 刷新，而不是进行收费的强制失效操作。

要证明真正的分阶段发布，我们需要记录：T0 英文合并，T1 英文检查结束，T2 英文 S3 上传确认，T3 翻译处理开始与结束，以及 T4 八种语言的 S3 上传确认。只有这些时间戳才能说明英文究竟提前了多久可用。

用 AI 帮助排查问题

ChatGPT 可以读取失败 PR 的日志、提出针对性修复并再次查看 CI 结果。晚上使用尤其方便。但这不意味着聊天会无限期自主运行；仍然需要可用的会话与工具，并由人审查最终结果。

最重要的教训

优化不只是缩短几十秒，而是不要让第一个有用的结果依赖所有后续可选步骤。英文可以先可靠地发布，另外八种语言随后在同样严格的质量要求下跟进。实际节省多少发布时间，还需要真实部署数据来证明。