本文是对「AI 时代 CI/CD 与 E2E 工程实践」的技术研究,结论经多来源交叉核验(Google Cloud / Testing Blog、Martin Fowler 团队的 CD4ML、ml-ops.org、Playwright / Pact / promptfoo / Arize Phoenix 官方文档、DORA 2025、UN R156/R155 法规原文、arXiv 论文,以及 2025–2026 的工程博客与厂商文档)。文中区分「事实 / 共识」与「分析判断」;厂商案例数字与未来预测已标注为判断,请打折看待。这是一份快速演变的领域快照(2026 年年中),非选型结论。
先给骨架:传统 CI/CD 的地基没变——版本控制、小批量、渐进式交付、测试金字塔,一样都还在,而且在 AI 提速之后更重要。变的是往上叠的三件事。总结成四个范式转变:
| # | 从 | 到 |
|---|---|---|
| 1 | 确定性断言 assert == | 概率评估 evals(阈值 + 容忍方差 + LLM-as-judge) |
| 2 | 代码是唯一制品 | 代码 + 数据 + 模型 + prompt 四类制品都要版本化 |
| 3 | 测试金字塔到此为止 | 测试 + eval + 线上可观测(evals 本身也要监控漂移) |
| 4 | 人写测试、CI 只负责跑 | AI 生成 / 自愈测试;而 AI 写代码 → CI 门禁必须更硬 |
一、传统基线(对照)
先把不变的地基说清楚,后面的"变"才有参照。
- 测试金字塔仍是骨架。Google 建议大致 70% 单元 / 20% 集成 / 10% E2E;E2E 只留一两条关键用户旅程。原因是 E2E 有三宗罪:flaky(无代码改动也间歇失败)、慢(可达数小时甚至数天)、难查(失败不指向根因)。经典案例里,一个过度依赖 E2E 的团队要等 3 天才拿到一次变更的反馈。(Google Testing Blog, 2015;Ham Vocke, 2018)
- 渐进式交付是主流降风险手段。以 Argo Rollouts(Kubernetes controller)为例:canary 按 20/40/60/80% 逐步放量、每步暂停收指标,blue/green 双实例切换;默认接 Prometheus,健康检查失败可自动 abort 回滚。(2023)
- 契约测试替代重 E2E。Pact(消费者驱动)让服务间"不用整体部署就能验证兼容",只测消费者实际用到的部分,专治微服务的"版本地狱"。(Pact 官方, 2022)
- DORA 2025 的定调:AI 是放大器——放大团队既有的强项与弱项,回报主要来自改进底层交付系统而非工具本身;版本控制和小批量在 AI 提速后更关键(当安全网)。
二、AI 原生软件(LLM / Agent / RAG):evals 成为新的单元测试
核心矛盾:输出非确定性,"断言相等"直接失效。业界正在形成的共识是——evals(评估)成为新的单元测试。
evals 和传统测试有四点本质不同:非确定性(需重复跑才能建立置信)、LLM 调用要花钱、部分输出需另一个 LLM 来评分(LLM-as-judge)、pass/fail 太粗(质量是一条光谱而非二值)。(Arize, 2026-07)
把 eval 做成 CI 回归门禁
工具已经成熟。promptfoo 提供官方 GitHub Action:解析通过率、低于配置阈值(如 95%)就 exit 1 卡住构建;可用 path filter(prompts/**)只在 prompt/RAG 改动时触发,而不是每次 commit 都烧钱;支持响应缓存降本、定时红队安全扫描。Arize Phoenix 则让你用普通 pytest / Vitest / Jest 写 eval——每个 suite 是一个数据集,每个 case 是一个样本,每次跑是一次 experiment,可设 suite 级门禁(如"至少 70% 的跑分为满分、平均延迟低于 5 秒才放行")。(promptfoo / Arize Phoenix 官方, 2026)
三条容易踩的纪律
- 把 prompt 当代码。prompt 进 Git、版本化当制品,和源码一样对待。
- 100% 通过率是危险信号——说明你的测试集太弱,别为了刷高分而优化。
- LLM-as-judge 自己必须先被验证。拿人工标注的 held-out 集把裁判模型校准到高真阳率 / 真阴率,才可信;而且能用确定性断言的地方就别用裁判(又贵又飘),裁判留给真正需要它的阶段。
- 阈值要容忍方差。非确定性系统别像确定性测试那样"单次弱结果就挂构建";eval 数据集小而精(~100+ 例)即可,和线上 trace 的异步评估分开。
三、MLOps / LLMOps:交付的不是包,是管道
权威框架:Google Cloud 定义了三级 MLOps 成熟度——L0 全手工 → L1 ML 管道自动化 + 持续训练 → L2 全 CI/CD 自动化;微软用的是 5 级。要注意:行业没有统一标准,各家层级数不同。
ML 的 CI 比软件宽得多:除了代码测试,还要数据校验 + 训练后模型质量评估 + 模型校验三道独立门禁;上线前要拿新模型指标对比线上模型再决定放不放。
CT(持续训练)是 ML 独有、传统软件没有对应物的东西:用新数据在生产自动重训,可以由"性能退化"这个信号触发。
Martin Fowler 团队的 CD4ML(2019)把这件事讲透了:交付的不是单个软件包,而是一条能自动部署预测服务的训练管道;一次构建可由代码 / 数据 / 模型任一变化触发(三层变量,而非软件的一层);非确定性模型的上线用 shadow(新旧模型并行、同收生产流量)、A/B、多臂老虎机;并且必须监控输入(检测 training-serving skew)、输出、用户反馈,闭环回来触发重训。
漂移监控是必需而非可选:ML 因数据分布持续演变而退化,要监控 data drift / concept drift / 模型陈旧——这是它和传统软件最根本的差别之一。
LLMOps ≠ MLOps
| 维度 | 经典 MLOps | LLMOps |
|---|---|---|
| 版本化制品 | 训练集、特征、模型权重 | prompt、embedding、向量索引、RAG 管道、护栏 |
| 成本结构 | 训练重、批量推理便宜 | 推理重、按 token 计(单次 GPT-4 调用被引为 MLOps 推理的 10–100×) |
| 迭代节奏 | 周 — 月 | 天 — 小时(改 prompt / 刷 RAG / 调护栏) |
| 评估 | accuracy / F1 / AUC 等定量指标 | LLM-as-judge、人工评估、幻觉率,监控输出质量漂移 |
| 治理成熟度 | 成熟(血缘、元数据、审计) | 约等于 MLOps 在 2018 年的水平,缺端到端数据血缘 |
(ml-ops.org、CD4ML、2026 工程博客交叉核验)
四、赋能硬件 / 边缘 / 机器人 / 车队(资料最散,难度最高)
为什么比软件难:物理不可回滚、批次差异、周期长、真机稀缺。业界的通用解法是一句话——尽量在硅里测,真机只做最后确认。
嵌入式固件 CI
- 分层测试。先在 host 跑静态分析 + MISRA 检查 + 单元测试(CppUTest / Unity / Ceedling),固件还没碰硬件就拦住大部分问题;再用 QEMU 在 CI 里启动真固件(可模拟 ADC / GPIO / 总线并喂测试波形);最后 HIL(硬件在环)——CI 编排器用继电器、断电控制器、UART 给真板刷固件、发命令、切 GPIO 触发测试。覆盖率:host 用 Gcov / LCOV,target 侧用 Segger SystemView。
- OTA 固件:分组灰度(staging 组 → 逐步放量)+ 失败自动回滚 + 固件必须签名(私钥进 HSM / KMS)。
某厂商案例称引入嵌入式 CI/CD 后砍 70% 手工 QA、少 40% 生产固件 bug——厂商数字,当方向别当承诺。
边缘 AI / TinyML
runtime 菜单:ExecuTorch / llama.cpp / ONNX Runtime / TensorRT-LLM / vLLM,加 MCU 侧的 TVM / XNNPack / CMSIS-NN 和厂商 runtime(CoreML / NCNN / MACE)。量化是边缘交付的核心环节:AWQ、GPTQ(4-bit 到 175B 参数)、QLoRA(单 GPU 微调 65B)。可行性的一个标志:MCUNetV2 用 32kB SRAM 就能在 Visual Wake Words 上做到 90%+ 准确率——MCU 上跑推理是真的能落地的。(2025-01 汇编)
机器人:仿真驱动的 sim-to-real
典型 staged 管道:NVIDIA Isaac Sim 训 RL 策略 → Gazebo 中间测 → ROS 2 真机实时推理;论文里端到端 RL 局部规划器达到与成熟的 Nav2 导航栈相当的水平(有确定性基线可对标)。(arXiv 2501.02902, 2025-01)
该论文"纯 Isaac 训练零样本迁移到真机"这一点,是作者自己一篇论文的窄结论,对抗核验判定它不能外推成"仿真普遍可替代真机训练"。把它当"某些任务上可行"的存在性证明,别当通用结论。
软件定义汽车 / 车队 OTA
- 数字孪生当"配置清单":先对云端孪生跑 dry-run OTA 再推真车;孪生必须配置感知(精确表示软 / 硬件 / 数据配置),否则退化成不可信仿真、反而导致危险的现场更新。
- 五层验证:lab(元件)→ bench(子系统)→ SIL/HIL 仿真 → 整车 → 现场数据,配 driver-in-the-loop 与 OTA shadow 模式;物理样机还没有时先用 SIL/HIL 验逻辑。
- 法规是硬约束。UN R156 要求:失败或被篡改的更新必须可回滚到上一安全态、安装前验真、安装后验成功;要建 SUMS(软件更新管理系统,OTA 与进厂更新同一套标准),SUMS 须第三方审计认证、证书 3 年有效。配套 UN R155(网络安全)、ISO 26262(功能安全)。(UN 法规原文)
五、反向:AI 如何改造 CI/CD 与 E2E 本身
- self-healing E2E。以 Meticulous 为例:用埋点录制真实会话自动生成并维护前端 E2E(无需手写,AI 引擎随功能演进增删用例),PR 提交时并行跑、声称"数千屏 <120 秒"卡合并,在 Chromium 层做确定性调度以消除 flaky,默认 mock 后端重放录制的响应。同类还有 testRigor / Testim / mabl。(厂商说法,已知用户含 Dropbox / Notion 等)
- agentic coding 是新的攻击面。AI 助手的配置文件(如 Claude Code 的
.claude/目录)已被证明可被利用:CVE-2025-59536(CVSS 8.7,恶意仓库文件在用户同意前经 hooks 执行任意 shell)、CVE-2026-21852(通过 env 覆盖把全部 API 流量导向攻击者服务器)。防御:CI 加 AST 扫描(缺护栏、硬编码 model ARN、未批准的 hook 命令就挂构建)+ 用 CODEOWNERS 把动到.claude/的 PR 强制路由到安全评审。(2026-03) - pre-commit 不算防线。本地钩子能被
git --no-verify绕过,同样的 secret / 策略扫描必须在服务端跑 + 配分支保护,在开发者绕不过去的地方。 - 供应链升级到 AI。SBOM → AI-BOM / ML-BOM:登记模型版本、训练 / 微调数据、许可、embedding、第三方 AI 服务、eval 制品(模型常以 pickle 分发 = 可远程执行代码)。目标 SLSA Level 3 + Sigstore 签名;静态 SBOM 多是"没人用的合规快照",成熟度已从"有 SBOM"转向"能据其行动"。法规推手:EU CRA、EU AI Act、ISO/IEC 42001。
综合:按产品类型选策略
| 产品类型 | CI/CD 重点 | "E2E" 形态 |
|---|---|---|
| Web / 前端 | CI + 视觉回归 | Playwright(getByRole、web-first 断言、trace viewer);或自愈类(Meticulous) |
| 移动端 | fastlane + 设备农场 | Firebase Test Lab / BrowserStack;商店内外测通道自动化 |
| 后端 / 微服务 | GitOps(Argo)+ 渐进式交付 | 契约测试(Pact)替代重 E2E;canary + 指标自动回滚 |
| LLM / Agent / RAG | eval 门禁(promptfoo / Phoenix) | golden set + LLM-as-judge(先校准)+ shadow / A-B 上线 |
| 经典 ML | MLOps L1→L2 + CT | 数据 / 模型 / 代码三门禁 + 漂移监控 + CD4ML shadow |
| 边缘 / 嵌入式 | host → QEMU → HIL 分层 | 签名 + 分组灰度 OTA + 自动回滚 |
| 机器人 / 车队 | 仿真驱动 + 数字孪生 dry-run | SIL/HIL + shadow;车规 UN R156 可回滚 SUMS |
给独立开发者 / 小团队的最小可行落地(按性价比)
- 只要产品里有 LLM 功能,第一件事是给它上 eval 门禁。promptfoo:一个 golden set + 用
prompts/**path filter 只在改 prompt 时跑 + 阈值卡 PR + 开缓存降本。这是从"AI 功能能跑"到"AI 功能不退化"的关键一步,性价比最高。 - 后端:CI 上 API / E2E(Playwright)+ 部署后对生产端点自动冒烟(把手动 curl 自动化)。服务少就先别上契约测试。
- OTA:无论是 App 热更新还是固件,对标嵌入式那套——分组灰度 + 失败自动回滚 + 包签名,别做"一把梭全量直更"。
- 供应链:用了 AI 编码助手就把它的配置目录纳入评审(CODEOWNERS)+ 服务端 secret 扫描(别只靠本地 pre-commit)+ CI 生成 SBOM。
- 移动:商店发版流程脚本化,补一层设备农场冒烟。
主要来源:Google Cloud MLOps 成熟度框架、Google Testing Blog(测试金字塔)、Martin Fowler / Thoughtworks《CD4ML》、ml-ops.org、Playwright / Pact / promptfoo / Arize Phoenix 官方文档、Argo Rollouts 文档、DORA 2025、UN R156 / R155 与 ISO 26262 法规、arXiv 2501.02902、以及多篇 2025–2026 的嵌入式 / 边缘 AI / SDV / 供应链安全工程博客。研究经三票对抗式核验(73 条确认、2 条否、69 条高置信),区分了"事实 / 共识"与"分析判断",厂商数字与预测均已标注。