KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

05 · AI 时代的 CI：流水线从"执行脚本"变成"有判断力的闸门" — keel 龙骨

这一章回答：AI 进了流水线之后，哪些环节真的被改变了，哪些只是营销词汇；以及在"写代码变便宜"之后，什么反而变得更值钱。

这一章回答：AI 进了流水线之后，哪些环节真的被改变了，哪些只是营销词汇；以及在"写代码变便宜"之后，什么反而变得更值钱。

先给结论：AI 不会让交付变简单，它会让下游闸门成为瓶颈。 这就是为什么对做 AI 应用的人来说，交付工程不是副业而是主战场。

一、先把数据摆出来（而不是凭感觉）

三条可核查的外部证据，回答"AI 到底改变了什么"：

来源 关键结论 对交付的含义
DORA《State of AI-assisted Software Development》2025 约 90% 的技术从业者已在工作中使用 AI，80%+ 认为提效；2025 年的数据显示 AI 采用与交付吞吐量上升相关，但同时交付不稳定性也上升（2024 年的数据里甚至是吞吐下降） "生成得快"不等于"交得稳"。写代码的成本下降了，验证与吸收的成本上升了。
同上：Google 工程师 1110 份开放回答的主题分析 最高频的四个用例是代码生成、信息检索、代码评审、测试；负面主题高度一致：验证开销、幻觉、知识边界、技能退化、制造技术债 AI 在流水线里的四个落点，正好对准这四类场景——这不是巧合，是需求驱动
DORA 的定位判断 AI 是放大器：高绩效组织（平台/规范/测试扎实）被放大收益，混乱组织被放大混乱 决定 AI 收益的前提条件是平台与基础规范，不是模型版本

必须诚实说明口径：DORA 用的是贝叶斯建模 + 自报调查的相关性，不是随机对照的因果结论；Google 工程师的样本也偏单一组织。所以这些数字适合用来"提出假设"和"建立方向感"，不适合用来承诺收益。

另一条独立的因果证据（METR 的 RCT，2025 年发布、2026 年初更新说明存在选择效应）显示：在特定任务集上，资深开发者使用 AI 反而慢约 19%，而使用者本人仍觉得更快——感知与事实会系统性背离。这条带给交付纪律的直接推论是：凡 AI 参与的环节，结论必须用可观测指标来判定，不能用"感觉快了"。

二、AI 在流水线里的六个落点

① PR 摘要与风险评分 ──► ② AI 代码评审 ──► ③ 测试选择/生成 ──► ④ 失败归因
                                                                    │
⑥ 部署风险评分 ◄── ⑤ 金丝雀自动分析 ◄──────────────────── 自动修复（受限）
# 落点 它在替人做什么 成熟度 / 风险
① PR 摘要与风险评分 总结改了什么、可能影响哪些模块，给评审人一个入口 成熟；几乎无副作用
② AI 代码评审 + LLM-as-judge 用 diff + 流水线证据（截图、trace）对照团队未成文的规范挑问题 有用但有假阳性；只建议，不建议阻塞
③ 测试选择与生成 按 diff 选出真正相关的测试；为新增逻辑生成针对性用例，有价值的才沉淀进套件 选择已可用；生成需要人审"断言是否真的断言了"
④ 失败归因 读日志和 diff，把"哪个测试、什么错误、可能在哪个变更引入"直接贴在 PR 上 成熟；把调试从"翻日志"变成"读结论"
⑤ 金丝雀自动分析 灰度期间对比错误率/延迟，超阈值就自动回滚 强依赖指标质量（见第四章 05 节的前提）
⑥ 自动修复 / 自愈流水线 agent 读取失败 → 提 patch → 重跑 风险最高，必须设边界（见下）

一句话概括这套变化：过去流水线回答"通过还是失败"，现在它开始回答"哪里、为什么、要不要回滚"。

六个落点里最容易被误用的：自动修复

自愈流水线听起来很美，落地要过了三关才安全：

  1. 边界明确：只处理确定性的、CI 自身的错误（依赖漂移、lint 风格、锁文件未同步），不处理业务逻辑失败——"为了让测试变绿而改测试"是灾难级自动化。
  2. 同样的流水线审 twice：agent 的修复必须通过和人的代码完全相同的门禁。"同一条流水线既审判 agent 的代码，也审判 agent 的修复"是这套机制唯一的安全底线。
  3. 痕迹可审计、动作可逆：修复的 commit 必须标明是自动修复，来源可追溯，一键可回退。

三、AI 来了之后，哪些东西反而更值钱了

能力 为什么变重要
质量门禁的设计 生成变便宜 → 到达闸门的量变大 → 闸门的质量决定吞吐能不能兑现
可观测性与发布反馈 AI 能改代码但不能替你发现"线上悄悄坏了"；没有指标，自动回滚就是玄学
小批量习惯 LLM 乐于输出大改动；把大改动切成可独立发布的小单元，是唯一对冲手段
规格与约定的固化 AI 只能读它读得到的东西。约定不在仓库里（没写成文件或规则），就等于不存在
回滚能力 变更更快 → 出错更快 → 回退必须比出错更便宜

这张表就是"AI 时代为什么要学交付工程"的答案：AI 把成本从"写"搬到了"验、合、放、退"四个字上，而这四个字正是这门课的全部内容。

四、把 AI agent 放进流水线时的三条安全边界

任何让 AI 持有凭据、能改代码或能触发部署的设计，都要先回答这三个问题：

边界 具体做法 不做的后果
身份与权限 CI agent 当"非人身份"管理：独立的最小权限角色；只读日志的角色不允许写 IAM、不允许删库删 namespace 一次越权就是一次生产事故
沙箱执行 需要跑代码/构建时才创建临时隔离环境（容器或 microVM），用完即销毁 不可信行为直接污染宿主 runner
人在环 + 成本可见 敏感动作（发布、回滚、改基础设施）保留人工确认；token 消耗按 agent / job 粒度可见 静默放权和账单失控是同级别的两种失败

一个值得借鉴的工程形态是"编排者自己不能直接写代码"：由编排层持有凭据、通过受限的工具接口调用外界，而真正的代码修改在另一个隔离沙箱里完成。把"能拿到凭据"和"能执行任意代码"这两件事拆到不同进程里，是 agentic 系统安全设计的通行做法。

五、把 AI 接进流水线的最小可行路径

阶段 1（零风险）    PR 摘要 + 失败归因：只产出文字，不改任何东西
阶段 2（低风险）    AI 评审设为建议评论 + 测试选择，只是不阻塞
阶段 3（中风险）    自动修复限定在 lint/格式/锁文件这类确定性错误，且改动单独一个 commit
阶段 4（高风险）    发布风险评分 + 金丝雀自动分析；必须有指标与人工兜底
每一阶段都要回答同一个问题：这一步如果 AI 判断错了，最坏会发生什么、多久能被发现？

动手：可观察结果

动作 产出物 判断标准
给 PR 加自动摘要 PR 顶部一段自动摘要 打开三个历史 PR，看摘要是否一眼看懂改了什么
统计你自己近一个月的 PR 体积 行数分布 + 平均评审时长 体积与评审时长的关系图；> 500 行的 PR 是否明显更久
加一条"只看串行"的 AI 评审 至少评审 10 个 PR 记录它给的建议里有用 / 假阳性的比例，这个比例决定了它能不能升级为门禁
让 AI 做失败归因 一份失败日志 + 归因结论 对比你自己读日志得出的结论是否一致，命中率要能算出来
写一份"自动修复白名单" 一份清单 白名单里的每一条都要能说明"为什么它的错误是确定性的"

故障注入

注入方式 观察什么 说明的现象
让 AI 评审对一个安全改动报高置信度漏洞 是否阻塞合并 若阻塞 → 你会得到一个"大家被迫忽略 AI"的流水线
让自动修复去修一个失败的业务测试 agent 会做什么 它很可能去改测试/改断言——所以要先用白名单限定范围
灰度期间人为抬高错误率 金丝雀是否自动回滚 没有指标或指标不对 → 自动分析形同虚设
给 CI agent 一个只读一信息的宽松角色 能否改到不该改的资源 权限扩散是最常见的失控路径
让 AI 生成一段"看似正确"的实现 覆盖率是否上升、变异存活是否上升 覆盖率涨而变异存活高 = 典型的"写了能跑但没断言"的代码

自测题

  1. DORA 2025 报告里，AI 采用度上升同时伴随哪一项指标恶化？它对流水线设计意味着什么？
  2. 为什么"AI 是放大器"这个定位，比"AI 提升生产力"更能指导实践？
  3. 自动修复流水线必须通过的三条边界是什么？缺一条会导致什么？
  4. 为什么要让"持有凭据"和"能执行代码"分属不同进程？
  5. 如果只能给一条流水线加一项 AI 能力，你选哪一个？为什么它风险最低而收益确定？

进入 keel 阅读