持续集成
CI
中级通用持续集成（CI）是在代码提交或合并请求发生时，自动构建并运行检查、尽快反馈结果的工作方式。它让你在多人或 AI Agent 持续改动代码时，早点发现新代码与项目现有部分不兼容的问题。
你可能会说：「我和 AI 经常改同一个网站，能不能每次提交代码后自动检查有没有弄坏原来的功能？」
动手看看修改购物车价格后自动检查
1
开发者提交了购物车价格显示的改动，仓库自动触发 CI，不用再找人手动启动检查。
要点持续集成是怎么帮你发现问题的？
- 1
从代码变动触发自动检查
你可以把检查配置在提交代码或创建合并请求之后触发。比如 AI Agent 改了登录页面，系统就自动安装依赖、构建项目、运行测试，不用等你想起来再逐项执行。
- 2
用检查结果决定怎么修改
检查失败时，你先看是哪一步失败、报了什么错，再让 Agent 针对问题修改。这样做的好处是，讨论依据从“看起来能用”变成了可复现的检查结果；通过检查也不等于功能已经被完整验证。
- 3
让新代码尽早接受共同检验
“集成”的重点是让改动尽早和项目现有代码一起接受检查。我们频繁提交较小的改动，就更容易定位是哪次修改引入了问题；攒很多功能一起合并，出错时排查范围会更大。
容易混淆的地方
CI 关注的是代码变动后能否自动完成构建和检查，不等于把新版本发布给用户；后者属于持续交付或持续部署的范围。它也不等于单元测试：测试只是 CI 可以运行的一类检查，CI 还可以运行代码规范检查、构建等任务。
什么时候用
适合用
- 你和 Agent 共同维护一个网站，希望每次提交代码后都自动构建并运行测试，及时发现改动带来的问题。
- 团队通过合并请求开发后台功能，想在合并前看到同一套检查结果，减少“只在我电脑上能跑”的情况。
- 项目有前后端和共享依赖，改动一处可能影响别处，适合让每次变动都接受自动化检查。
不适合用
- 你只是在本地写一次性的演示脚本，不会继续维护或合并代码，直接运行脚本并手动核对结果更省事。
- 你正在讨论 App 的页面布局，还没有可运行的代码仓库，先做原型和设计评审；CI 检查不了设计是否合适。
- 你想知道网站上线后有没有报错、响应是否变慢，应该看监控和日志；CI 检查的是代码变动，不能替代运行时观察。
练一练选一个答案，看看解释
你让 AI Agent 给订单后台增加筛选功能。代码在 Agent 的电脑上能运行，但合并后同事发现项目无法构建。下次怎样更早发现这类问题？
让 AI 帮你做复制给 AI Agent 直接用
请为这个代码仓库配置持续集成（CI）：在创建或更新合并请求时自动安装依赖、执行现有测试和构建，并清楚显示失败步骤。先查看项目已有的命令和配置，不要凭空添加测试；完成后告诉我触发条件、检查内容和如何查看失败结果。