本文是对「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 工程博客交叉核验)
四、AI 进硬件、边缘、机器人、车队(资料最散，难度最高)
为什么比软件难：物理不可回滚、批次差异、周期长、真机稀缺。业界的通用解法是一句话，尽量在硅里测，真机只做最后确认。
嵌入式固件 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
典型的分阶段管道是，先用 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 条高置信)，区分了「事实与共识」和「分析判断」，厂商数字与预测均已标注。