你可能会说
每次 push 都自动跑一遍测试，挂了就告诉我
每次提交代码后都自动跑一遍检查和测试
大白话解释
持续集成就是给代码请了个不眠不休的检查员。你每次把代码推上去，它立刻自动跑一遍编译和测试，几分钟内就告诉你这次改动坏没坏。
它的价值在于早发现。以前大家各写各的，攒到上线前才合到一起，一合全是问题，谁都说不清是谁弄坏的。现在每次提交都验一遍，问题刚冒头就被逮住。
它通常还和自动发布连在一起：检查过了就自动发到测试环境，不用人手动点。
什么时候会遇到
- 开了拉取请求后，页面上出现一排自动检查，绿了才能合。
- 本地测试都过，推上去却红了，原因是服务器环境和你机器不一样。
- 改了配置忘了同步，持续集成立刻报错，省得上线才发现。
- 主线突然变红，大家先停下新功能，把它修绿再说。
- 让 AI 助手帮忙看持续集成的报错日志，定位失败原因。
可以直接对 Agent 说
「帮我给这个项目配置持续集成，每次推送时自动装依赖并跑测试，用最省事的方案」
「持续集成报错了，这是日志，帮我找出是哪个测试或哪一步失败，以及可能的原因」
「帮我在持续集成流程里加一步，提交前自动检查代码格式，格式不对就报错」
正文里带下划线的词，是本站其它词条的入口；这一篇自动链了 2 个相关术语。
最容易想岔的地方
常见的错误理解： 持续集成就是自动跑测试，本地跑过就不用它了
更准确的理解： 本地环境和集成环境不一样，本地过不代表合起来也过。它的价值是保证主分支每次合并后都是好的
常见的错误理解： 集成跑得慢没关系，反正是后台在跑
更准确的理解： 集成一慢，大家就不等它了，开始往主分支塞没验证过的改动，它的意义也就没了。慢的检查要拆开并行
测一下：真遇到了你会怎么处理
单选 · 选完立刻看解释
同事提交的代码把首页搞崩了，上线后才发现 —— 谁都没在本地跑测试。
怎么让这种问题以后自动被拦住？
-
持续集成的意义就是把「跑没跑测试」从靠自觉变成靠机器，失败在合并前就暴露。
-
靠自觉一定会漏 —— 赶时间、忘记、本地环境不同，都可能跳过。规矩要落在流程里而不是群里。
-
回滚是兜底手段，不是防线。能提前拦住的问题，不该放到线上去发现。
题目只考「这个场景下的第一反应」，不考名词背诵 —— 持续集成的定义在上面已经讲过了。