夜雨聆风
维护 Caddy 中文文档这些年:AI 如何改写同步方式
很多事情不是被技术难住的，而是被长期维护拖垮的。
Caddy 中文文档这件事，恰好让我看见了 AI 到底改变了什么。
我做 Caddy 中文文档，不是临时起意，也不是一时兴起翻几页看看。
回头翻本地仓库历史，这件事的时间跨度已经非常长了：
caddy-cn-doc
：从 2018-09-05 到 2022-02-14，共 189 次提交。 caddy2-cn-doc
：从 2020-05-02 到 2026-05-13，共 103 次提交。
这两个数字说明一个很朴素的事实：它从来不是一次翻译任务，而是一项长期维护工程。
为什么当时会想把 Caddy 推荐到中文社区
最早想推广 Caddy，其实没有什么宏大叙事，原因很实际。
那几年很多人一提到 Web 服务器，默认就是 Nginx。Nginx 当然强，而且强得很稳定，但它也有一种很典型的工程气质：灵活、成熟、细节多、心智负担也不低。你要自己管证书、管续期、管很多边界配置，还要对配置语法足够熟悉，不然一个小地方写错，就容易让人怀疑人生。
而 Caddy 给我的第一印象，是“它把很多原本应该自动化的事情，真的默认自动化了”。
- 自动 HTTPS
：申请证书、续期证书、配置证书链，这套事在 Caddy 里变成了默认能力。 - 配置表达更顺手
：Caddyfile 对大量常见场景更直观，不必一上来就进入那种满屏指令和块嵌套的状态。 - 更适合中小站点快速落地
：个人站、博客、文档站、轻服务代理，部署路径短很多。
我当时最直观的感受是：以前很多人不是不想折腾 HTTPS，也不是不愿意学服务器，而是他们在真正把站跑起来之前，已经先被前置工作消耗掉了耐心。
Caddy 让这件事简单了很多。所以我想做中文文档，不是为了“拥有一个翻译站”，而是为了让更多中文开发者少踩一点和语言有关的门槛，更快体会到这个东西为什么值得用。
Caddy1 时代：全文自己翻，靠热情硬扛
Caddy1 阶段，整个维护方式现在回头看，非常原始。基本就是自己逐页翻，局部借助有道之类工具做底稿，再人工把术语、命令、示例、上下文一点点校回来。
站点地址是：https://dengxiaolong.com/caddy/zh/。
这种工作最大的特点，不是技术含量高，而是非常碎，非常慢，而且很难并行。你翻译一页，不只是把英文变成中文，还要确认术语是否一致，代码块有没有被翻坏，页面里的链接还能不能跳，目录标题是不是和其他页面风格统一。
最早做的时候，靠的是兴趣和责任感。说直白一点，就是靠人硬扛。
后面我把这个项目推荐到了阮一峰网络日志《每周分享第 34 期》，被收录之后，项目在中文技术圈的可见度明显高了不少。被更多人知道当然是好事，但事情也随之变复杂了。
-
会出现克隆和仿站。 -
你得证明来源，避免别人整套搬走后反过来说他是原创。 -
还会出现一些异常访问和滥抓取行为，要想办法限制。
所以我后来甚至在源码里加过一些明显能证明来源的标记，用来反向识别那些复制站。也尝试过限制某些 IP 访问页面。
文档项目最累的部分，常常不是内容生产，而是内容被生产出来以后的一切维护动作。
Caddy2 出现后，事情一下子变得更正规，也更难了
Caddy2 比 Caddy1 更成熟，这几乎是肉眼可见的。它不只是新版本，而是整个体系都变得更完整了：文档结构更清楚，模块化更强，指令和配置能力也更加系统。对用户来说这是好事，但对翻译维护者来说，难度并不是线性增加，而是会明显放大。
-
页面数量更多。 -
层级更深。 -
指令页、教程页、快速开始页、升级页、FAQ、模块页会一起演化。 -
上游更新时，变更并不总是集中在一个地方。
更麻烦的是，我开始翻 Caddy2 的时候，它本身也还在持续演进。也就是说，你不是面对一个已经稳定下来的文档集，而是在追一个还在动的目标。
今天翻完一页，不代表下个月这页没变化。你刚把某个术语统一掉，上游可能又新增了三处相关内容。你以为站点差不多同步完了，回头一看，导航结构、样式、锚点、教程入口又改了一轮。
站点地址是：https://caddy2.dengxiaolong.com/docs/。
这一阶段我的翻译方式也在变化：早期主要靠 Google 翻译打底，后来逐步转成“先机器翻，再人工归一术语和上下文”，再后来出现 DeepSeek 这类对话式 AI，又能继续往前走一步，开始让模型参与整理和重写。
另外，版权问题我也没有回避。当时我专门在 Twitter，也就是现在的 X，上公开留言 @caddyserver 沟通过这件事：https://x.com/comdeng/status/1491739619209416705。
以前最耗时间的，不是翻译，而是同步
很多人容易误会这种项目的工作量，觉得无非就是“把英文翻成中文”。实际上真正拖慢人的，经常不是翻译本身，而是同步过程里的脏活累活。
-
官网样式变了，你得跟着改。 -
导航结构变了，你得对齐。 -
目录里新增了页面，你得先找出来。 -
有些页面不是完全没翻，而是翻了一半，或者翻的是旧版本。 -
链接、锚点、图片、脚本、CSS，只要有一处漂了，整体观感就会变成“这个站过时了”。
这种工作最烦的地方在于，它们都不难，但很耗神。你得写脚本、做 diff、看目录、逐页确认、反复回查。有些工作没有任何创造性，但又不能不做。最典型的一次就是官网样式升级。放在以前，我大概率要先把上游前端结构拉下来，再对比本地模板、样式和脚本，一处一处改，改完后再手工打开页面检查有没有断掉。完整走完，8 个小时并不夸张。
AI 介入之后，维护模式第一次真的变了
这次我真正感受到“不是提效一点点，而是维护模式被改写了”，发生在 2026-05-10 到 2026-05-13 这一轮同步里。
如果把这轮 AI 驱动同步开始之前的状态作为分界，那么从那之后到当前最新提交，仓库实际变化是：
-
新增 10 次提交。 -
影响 56 个文件。 -
总差异 +4720 / -1179。
更关键的是，这 4 天里改的不是零碎小补丁，而是一整批核心文档：包括 docs.css、docs.js、head.html、nav.html，以及一大批指令页、教程页、快速开始页和捐赠页。
也就是说，AI 介入之后，我不是只让它“翻几段文字”，而是让它参与了一整套维护闭环。
这次 AI 到底帮我做了什么
如果只说一句“AI 帮我节约时间”，这句话是对的，但太轻了。真正准确的说法应该是：AI 把原来必须由人手工串行推进的工作，拆成了可以快速收敛的几个环节。
第一层：样式同步
这次我先发现的是，官网样式已经明显变化了，视觉上更现代，信息层次也更清楚。过去遇到这种情况，我通常会先紧张，因为这意味着前端结构、CSS、模板片段和交互脚本都可能要跟着动。
以前我大概率会写一些辅助脚本，再加上手工 diff，一处处核。这次的不同是，我直接对着 AI CLI 描述目标和当前目录结构，让它先给出一个可用的同步基线。结果非常直接：过去大概要 8 小时才能把第一版轮廓做出来的事，这次 8 分钟就已经能看到有效结果了。
这里不是 8 分钟全部结束，而是 8 分钟从零到可验收基线。这已经完全改变了工作节奏。
第二层：页面差异盘点
样式对齐之后，真正费脑子的其实是内容差异。我把官方文档仓库拉下来后，让 AI 去做目录和页面级别的比对。它最有价值的地方不是帮我翻译，而是帮我回答：哪些页面中文站还没有，哪些页面有但明显落后于当前英文版，哪些页面链接结构变了，哪些页面只是标题、锚点或术语没有跟上。
这一层过去很烦。因为人去做的时候，很容易漏，尤其是目录很多、页面很多的时候。AI 在这一步最像一个不会累的对照器。
第三层：批量修复与复核
盘点出差异以后，以前的做法往往还是一页页补。这样做有两个问题：容易在局部反复投入，也很难在修完一批以后快速验证还有没有别的没跟上。这次更有效的方式是，把缺失页面、指令页面、教程页面分组处理，然后让 AI 继续协助复核。它不只是给一版初稿，而是能继续参与“这一组是否已经同步完整”的判断。
以前是人找问题、人改问题、人再检查自己有没有漏掉问题。现在变成了人定义范围，AI 帮忙找差异，人做关键判断，AI 协助完成与复核。这不是简单加速，而是把维护者从低价值重复劳动里往外拽了一大截。
但这件事的终点，不是翻译站更好维护了
真正值得想一想的是，AI 一边让翻译站更好维护，另一边也在削弱“翻译站必须存在”的理由。因为现在很多人面对英文技术文档，已经不是“要么自己硬读，要么等别人翻译”这两种选择了。
他们还有第三种办法：把英文原文直接喂给 AI，然后围绕自己的问题继续追问。这样得到的结果，很多时候比静态翻译页更贴合场景。因为用户不是只想知道“这段英文什么意思”，而是想知道它跟我现在的配置有什么关系，这段说明在我的部署场景里该怎么理解，我究竟该用哪个指令、哪个模块、哪个写法。
这意味着中文技术文档项目的价值正在迁移。过去的核心价值是把英文内容覆盖成中文；现在更有价值的，也许是做高质量导航，做中文语境下的解释，做真正解决问题的案例和边界说明，做帮助读者减少误判的注释，而不是单纯逐页搬运。
所以我现在更愿意把这类项目定义成：不是一个翻译站，而是一个中文工程实践入口。
结语
我现在回头看这件事，最深的感受其实不是“快了多少”，而是人终于不用把时间耗在那些最磨人的地方了。
以前维护这种中文文档，最容易把人消耗掉的，不是某一页特别难翻，而是你总得反复做那些没人愿意反复做的事：找差异、对结构、核链接、补样式、查遗漏。活不重到做不动，但足够碎，碎到最后很容易把兴趣磨没。
现在不一样的地方在于，这些最碎、最烦、最不值得人长期亲自硬扛的部分，终于可以交给 AI 去分担了。人可以把精力留给更像“人该做的事”的部分：判断、取舍、统一口径、决定哪些内容值得保留，哪些页面值得优先同步。
对我来说，这才是真正重要的变化。
它不是简单省了几个小时，而是让这类原本很容易半路放弃的长期维护，重新变得有可能坚持下去。