【系统架构设计】AI 时代的工程基础设施：让 pipeline 替你兜底

101 防御性架构把类型、契约、策略与沙箱钉成系统边界。边界要生效，必须挂进 每次变更都会跑的机器路径——否则只是仓库里一份「建议遵守」的文档。本文讨论这条路径：CI、策略即代码、评测（eval）hook、金丝雀与回滚如何组成 工程基础设施，在「人审不过来」时仍限制破坏。

不写：某个云厂商的 YAML 教程；不编造本站或未公开组织的「AI PR 缺陷率」。训练集群与推理评测基准见 llm-infra；在线 Agent 的 eval hook 在 95 仅点到为止，本文展开 开发期变更流 上的门禁。

系列导航： ← 防御性架构 · 系统架构设计索引 · 架构即 AI 上下文 →

相关专题： SLO 工程 · 混沌工程 · 可观测性索引 · 优雅降级

一、问题：变更速率超过人审吞吐

1.1 威胁模型（开发期）

把「AI 参与的变更」当作攻击面与事故面，比当作效率神话更有用：

Humble 与 Farley 在 Continuous Delivery 中强调：质量内建于部署流水线，而非依赖发布前的英雄式测试[1]。Google SRE 将变更视为可靠性的主要风险来源之一，主张渐进发布与快速回滚[2]。AI 不改写这些结论；它提高 单位时间进入流水线的变更数，使「靠资深工程师盯 Diff」的假设更快失效。

1.2 本文核心问题

1. 门禁应如何分层，每层失败语义是什么？
2. eval 适合挡什么、不适合挡什么？
3. 回滚与金丝雀如何与 28 SLO 的错误预算衔接？
4. 「eval 替代人审」争论的证据边界在哪？

二、门禁分层

2.1 总览

flowchart LR
  PR["PR / change"] --> G1["lint / secret scan"]
  G1 --> G2["type / unit"]
  G2 --> G3["schema / contract"]
  G3 --> G4["policy as code"]
  G4 --> G5["eval hooks"]
  G5 --> G6["review gate"]
  G6 --> G7["canary / progressive"]
  G7 --> Prod["production"]
  G7 --> RB["rollback"]

原则：越靠左越便宜、越确定；越靠右越贵、越接近真实风险。 左侧重机器确定性检查；右侧才引入统计性 eval 与人工。

2.2 Lint、密钥扫描与格式

• 作用：统一风格、挡住明显危险模式（eval(、禁用 API）、扫描密钥形态。
• 失败语义：阻断合并；修复成本低。
• 对 AI：高价值——模型常引入格式噪声与偶然粘贴的密钥样例。

不把「lint 全绿」解读为安全或正确。

2.3 类型与单元测试

承接 101 的类型闸门。单元测试应覆盖 不变量与错误路径，而不是只断言快乐路径——否则生成代码容易「写过测试的实现」。

失败语义：阻断。若测试被生成物删除或空断言，应有 测试覆盖率/变异测试 类二次信号（可选）；没有这类信号时，人审必须盯测试 diff（见 104）。

2.4 Schema 与契约测试

OpenAPI/JSON Schema 校验与 consumer-driven contract 在 CI 红灯，防止契约漂移进入主干。失败语义：阻断。与 101 一致：权威 spec 在仓库内版本化。

对「为过测而放宽 schema」应设 约束工件的额外审门槛（CODEOWNERS 保护 openapi/、policies/）。

2.5 策略即代码

OPA/Cedar 等策略变更与业务代码同 PR 时：

• 策略语法/单元策略测试失败 → 阻断；
• 策略放宽（允许集变大）→ 可要求 强制人审标签，与普通业务 diff 区分。

站内策略模型见 iam/13。

2.6 Eval hooks

此处 eval 指 针对助手/Agent/生成质量的自动评测集，不是机器学习训练的离线 benchmark 榜单。

95 文在运行时侧提到 eval hook；开发期应把 失败案例沉淀回仓库评测集，形成与缺陷跟踪的闭环。评测集本身是代码，需同样走门禁，防止「删案例让绿」。

证据边界：本文不声称某一公开 eval 框架在你的业务上「准确率 X%」——未在本站业务上复现则不作数字结论。

2.7 人审门禁

机器绿灯之后仍可能需要人审：高风险路径、策略放宽、数据迁移、安全相关 diff。人审不是「再跑一遍 lint」，而是判断 意图与全局权衡。编排细节见 104。

2.8 金丝雀与渐进发布

Nygard 强调发布后的快速感知与止损[3]；SRE 实践常用 canary / 分批发布，用 SLI 自动或半自动中止[2]。对 AI 高频合并尤其关键：主干绿灯 ≠ 生产安全。

与 28 的衔接：金丝雀期间错误预算消耗加速 → 自动回滚或冻结发布。与 26 的衔接：可经 feature flag 关闭 AI 引入的功能切片。

三、失败语义与回滚

3.1 三类失败

软失败最危险的处理方式是「先合并再说」——在 AI 吞吐下会系统性累积债务。

3.2 回滚设计前提

回滚能成立，依赖架构前置条件（与是否 AI 无关，但 AI 提高需求频率）：

1. 向前兼容的数据变更策略，或迁移分相位（expand/contract）；
2. 配置/旗标可关功能，而不靠「再推一次热修」；
3. 制品不可变：回滚是重新部署旧制品，不是在生产上手工改文件；
4. 可观测：能回答「这次发布之后哪个 SLI 坏了」——见 observability。

若迁移不可逆，门禁应上移到 强制人审 + 演练环境验证，而不是指望 canary 救场。

四、与邻接系列的分工

五、争论：eval 能否替代代码评审

5.1 双方

5.2 有文献与工程传统支撑的折中

Continuous Delivery 传统主张自动化验证尽可能多，但并不取消对高风险变更的人工决策[1]。SRE 变更管理区分常规变更与高风险变更[2]。迁移到 AI 语境：

• 可用 eval/CI 替代的：格式、类型、已知契约、已知安全坏案例、策略单测；
• 不可用 eval 单独替代的：新的信任边界调整、数据模型破坏性变更、跨团队 API 语义、合规相关策略放宽。

因此「替代」应写成 范围限定的替代：在低风险路径上减少人审强制项；在高风险路径上人审仍是硬门禁。用一句「各有优劣看场景」结束争论不符合本站文风——场景必须用 副作用不可逆性 刻画（与 101 §五同一尺子）。

尚无公开、可复现的跨公司 RCT 证明「全自动 eval 门禁优于人审」；强结论停在机制层。

六、开放问题

1. Eval 成本与假阳性治理
   每次 PR 跑大模型 judge 的费用与延迟可能反向激励团队关掉门禁。如何对 eval 本身设 SLO（时长、成本、抖动）仍缺通用做法。

2. 评测集所有权
   安全团队、平台团队、业务团队谁有权删改案例？缺少所有权时，评测集会腐化为「谁都能改的绿灯开关」。

3. 多仓单逻辑变更
   AI 常跨仓改动；单仓 CI 绿并不能代表系统级安全。跨仓「逻辑发布」的编排仍是开放工程问题（与微服务时代的相同问题，频率更高）。

七、落地检查清单

1. PR 是否强制 secret scan + 类型/单测？
2. openapi/、policies/、evals/ 是否有 CODEOWNERS 或等价保护？
3. 契约测试是否在提供方 CI 阻断？
4. eval 失败是阻断、标标签，还是被忽略？
5. 生产是否有 canary + 基于 SLI 的自动/半自动回滚？
6. 破坏性迁移是否被单独流水线与强制人审捕获？

参考资料

书与经典工程文献

• Humble, J., Farley, D., Continuous Delivery, Addison-Wesley, 2010.（A/B 级，工程经典）[1]
• Beyer, B. et al., Site Reliability Engineering, O’Reilly, 2016 — 变更管理与渐进发布相关章。（B 级）[2]
• Nygard, M., Release It! 2nd ed.（B 级）[3]

规范与工具文档

• OpenAPI Specification 3.1；OPA/Cedar 官方文档（钉所用版本）。（A/B 级）
• 各 CI 系统「required checks」机制文档（GitHub/GitLab 等，按平台钉版本）。（B 级）

站内交叉

• 101 防御性架构
• 28 SLO 工程
• 95 AI 原生架构
• 可观测性系列

核心文献（本主题）

实验与数据

• 本篇无集群压测；不报告未实测的缺陷率或 eval 准确率数字。

系列导航： ← 防御性架构 · 系统架构设计索引 · 架构即 AI 上下文 →