跳转至

从「不敢发」到「天天发」：AI Agent 时代的 CI/CD 生存指南

Ch04.662 从「不敢发」到「天天发」：AI Agent 时代的 CI/CD 生存指南

📊 Level ⭐⭐ | 4.9KB | entities/从不敢发到天天发ai-agent-时代的-cicd-生存指南.md

从「不敢发」到「天天发」：AI Agent 时代的 CI/CD 生存指南

这是2026年的第 31 篇文章

（ 本文阅读时间：约15分钟 ）

01

当 AI 开始写代码，「敢不敢发」成了新问题

先看一组数据：

a1 CLI（一款统一研发命令行工具）—— 数十万行 Go 代码，数百个命令定义，上百个 真实 API 冒烟用例，十余条 CI 流水线共近三千行 pipeline YAML。日均活跃用户数万，周调用量数亿次（已去除 CI 自动化调用的真实用户口径）。三个多月发布了上百个正式版本；最近 30 天几乎每个工作日发布一个版本。

这是一个日活数万、覆盖仓库管理、合并请求、CI/CD 流水线、应用发布、需求缺陷等研发全链路的生产级 CLI 工具，不是 Demo。而且，在这套高频发布体系中，AI Agent 深度参与了代码生成、测试生成、工作项分析等多个环节。

我们都知道，自动驾驶汽车有 L1 到 L5 的安全等级认证：辅助驾驶可以上路，但完全无人驾驶需要层层验证才能获得信任。再看向 AI Agent 驱动的软件研发，正在经历类似的信任建立过程。

眼下，AI Agent 已经能自主完成需求分析、代码编写、测试生成甚至 Code Review。但每次看到 Agent 提交的 MR，团队成员心里难免会浮现一个问题：这次改动，敢直接发到生产环境吗？

传统 CI/CD 流水线解决的是「人写的代码如何安全发布」的问题；AI Agent 时代，这个问题变成：如何让一个本质上具有随机性的 AI 系统，产出可预测、可信赖的代码变更？

基于此，本文以 a1 CLI（一款统一研发命令行工具）为例，分享我们团队如何通过一套完整的 CI/CD 体系，从「不敢发」进阶到「每个工作日自动发版」。其中最核心的挑战，是如何 harness AI 的随机性。

02

第一道防线：代码准入

在代码合入主干之前，我们用多层自动化门禁替代对人工 Review 的单一依赖。核心理念是 「分层 + 快速反馈 + 逃生舱」 三位一体。

2.1 分层门禁体系

第一层：单元测试 + E2E 覆盖率门禁。每次 push 或 MR 自动触发，覆盖率低于 75% 直接阻断合并。这是最基础的质量底线。

第二层：全量冒烟测试（真实 API）。这是我们区别于传统 CI 的关键：并行调用真实的平台 API，不是跑 mock 测试；测试资源通过命名隔离确保互不冲突。真实 API 冒烟能暴露 mock 掩盖不掉的接口契约变更、权限模型调整等问题，任一用例失败，MR 都会被阻断。

第三层：文档同步检查 + 测试清单一致性检查。改了命令或 flag，就必须同步更新文档站（pages-sync-check）；同时，测试清单一致性检查（smoke-manifest-check）确保冒烟用例清单与实际命令树保持同步——新增了命令却没登记到冒烟清单，同样会被拦下。没更新？MR 直接被阻断。

第四层：命令下线规范检查（cmd-retire-check，全新流水线）。命令的「下线」往往比「新增」更危险——直接删掉命令会破坏用户脚本、留下文档残链。这条流水线强制校验命令下线的四项规范：统一走废弃入口、保留下线测试覆盖、文档同步移除、命令树 smoke 引导。同样提供 [skip-retire-check] 逃生舱。

2.2 逃生舱机制

门禁要严格，但不能把人锁死。因此，我们在每个门禁环节都设计了逃生舱：

    pages-sync-che

→ 原文存档

关联