你可能会说
测试过了就自动发布，别让我手动传文件
代码一通过检查就自动把新版本发布上线
大白话解释
持续交付是把发版这件事变成自动的。代码通过检查后，系统自动打包、传上服务器、替换旧版本，人基本不用插手。以前发一次版要折腾半天，现在点一下或者全自动就跑完了。
它和持续集成是一对搭档，常合称 CI/CD。前半段管代码对不对，后半段管对的东西能不能顺利送到用户手里。
更进一步的版本叫持续部署：连最后那一下确认都不用人点，测试全过就直接上线。速度快，但要求测试足够靠谱。
什么时候会遇到
- 合并到主分支后，几分钟内测试环境就自动更新了。
- 半夜发版失败，告警把值班的人叫起来看部署日志。
- 上线后发现配置写错，需要能一键回滚到上一个版本。
- 讨论一个功能多快能上线，答案往往取决于自动发布的链路顺不顺。
- 让 AI 助手帮忙写部署脚本，或排查发布失败的原因。
可以直接对 Agent 说
「帮我设计一条自动发布流程：合并到主分支后自动构建并部署到测试环境，说明每一步做什么」
「这次自动部署失败了，这是日志，帮我定位是构建、上传还是启动环节出的问题」
「帮我把部署脚本改成一键回滚上一个版本，并说明回滚时会影响到什么」
正文里带下划线的词，是本站其它词条的入口；这一篇自动链了 3 个相关术语。
最容易想岔的地方
常见的错误理解： 持续交付就是每次提交都自动上线，越快越好
更准确的理解： 自动上线的前提是能随时回滚、能灰度放量。没有这两样，自动化只是把出错的速度也一起提上去了
常见的错误理解： 持续交付和持续部署是一回事
更准确的理解： 持续交付是「随时可以发布」，发不发由人决定；持续部署是「自动就发了」。多数团队需要的是前者
测一下：真遇到了你会怎么处理
单选 · 选完立刻看解释
你们每次发版都要运维手动登录服务器拷文件，一周一次，每次半小时。
想做到「合并到主分支就自动上线」，需要补上什么？
-
持续部署就是把「合并」到「上线」之间的人工步骤交给流水线，人的手不再出现在关键路径上。
-
人一直在场不等于自动化。手动步骤越多，疲劳导致的失误概率越高。
-
频率越高，同样的手动步骤出错的机会越多。熟练不能替代自动化。
题目只考「这个场景下的第一反应」，不考名词背诵 —— 持续交付的定义在上面已经讲过了。