为什么有人会在写一本技术书的同时，还要亲手搭建一套自动化的出版流水线？对我来说，这始于一次非自愿的相遇。2020年，一位客户手里有一批与互联网物理隔离的RHEL 7机器，我们得在上面部署一套容器化微服务栈。要在那些机器上安装Docker这类第三方软件，流程上的官僚障碍实在太大，于是我扫了一眼系统里自带还能用的工具，就这样撞上了Podman。

当时那套工具用得并不顺手——至少我们那种用法下，别别扭扭的地方不少。但Podman生态无守护进程的架构从一开始就让我觉得方向对了。不用多说，那个客户项目至今还跑在Podman上。而且后来，类似的实例一个接一个地冒出来。

打开网易新闻 查看精彩图片

我一直是优质技术书的忠实读者，脑子里冒出的第一个念头就是：这么好的工程，得有人为它写本书。于是我着手列出大纲，写了几章，还注册了域名，之后推翻重来，生活、工作又挤进来，一再耽搁。当然，这段时间里市面上已经出了好几本Podman书籍，我大概把它们都买了回来。

推动这本书最终达到可发布版本的有两股力量：一是我对当时即将发布（现在已经发布）的Podman第六版的兴趣，二是前沿大语言模型的进步。在整个出版流程中，AI几乎参与了每一个步骤——从草稿的打磨到管线的自动串联，没有一处是完全“手工”完成的。

我搭的这套发布工具链大概是这个样子：Markdown格式的文稿和可运行的示例，先经过一道源码关（就是跑一遍 just check），接着构建阶段产出带来源证明戳记的PDF和EPUB文件。成品再走一遍制品关（just check-artif