【系统架构设计】AI 时代的工程基础设施：让 pipeline 替你兜底
内容提要
本文探讨防御性架构中变更门禁的工程实现，强调将类型、契约、策略与沙箱等约束嵌入CI流水线，以应对AI参与开发带来的高变更速率。门禁分层包括lint、类型测试、契约测试、策略即代码、eval hooks、人审及金丝雀发布，每层有明确失败语义。核心观点是机器检查替代低风险人审，高风险变更仍需人工，回滚依赖架构前置条件，并指出eval无法完全替代人审。
延伸解读
门禁分层：越靠左越便宜，越靠右越贵
文章将变更门禁分为lint、类型测试、契约测试、策略即代码、eval hooks、人审和金丝雀发布等层次，并指出越靠左的检查越便宜、越确定，越靠右的越贵、越接近真实风险。这提示读者在设计流水线时，应优先用低成本、确定性的机器检查覆盖常见问题，而将昂贵且统计性的eval和人工评审保留给高风险变更，以平衡效率与安全。
eval 不能单独替代人审
文章明确区分了eval的适用边界：它适合拦截确定性回归、已知安全坏案例和权限类回归，但不适合单独判断复杂业务对错、新颖攻击或架构权衡。作者强调，所谓“替代”应限定在低风险路径上减少人审强制项，而高风险路径（如破坏性数据迁移、跨团队API语义变更）仍需人工硬门禁。读者应避免盲目用eval全自动放行变更。
回滚依赖架构前置条件
文章指出，回滚能否成立取决于架构是否具备向前兼容的数据迁移、可关闭功能的配置/旗标、不可变制品和可观测性。若迁移不可逆，则不能指望金丝雀或回滚救场，而应提前设置强制人审和演练环境验证。这提醒读者，在引入AI高频变更前，先检查自身架构是否满足这些前提，否则门禁再严也可能无法止损。
警惕软失败被静默忽略
文章将失败分为硬失败、软失败和生产信号失败，并特别警告软失败（如eval分数低、flaky测试）最危险的处理方式是“先合并再说”，因为在高吞吐下会系统性累积技术债务。读者应明确软失败的默认动作（阻断或需人工确认），并避免因eval成本高而关闭门禁，否则会反向激励团队绕过质量保障。
Q&A
AI 时代为什么需要将变更门禁嵌入 CI 流水线？
因为 AI 参与开发导致变更速率超过人审吞吐，传统依赖资深工程师盯 Diff 的方式失效。将类型、契约、策略与沙箱等约束嵌入 CI 流水线，可以在每次变更时自动执行机器检查，限制破坏，确保质量内建。
变更门禁分层有哪些层级？每层的失败语义是什么？
门禁分层包括：lint/密钥扫描、类型/单元测试、schema/契约测试、策略即代码、eval hooks、人审门禁、金丝雀/渐进发布。失败语义：lint、类型、契约、策略语法失败为硬失败，阻断合并；eval 分数低于阈值或 flaky 测试为软失败，可阻断或需人工确认；生产信号失败（如 canary SLI 恶化）则回滚或暂停 rollout。
eval hooks 适合挡什么？不适合单独挡什么？
eval hooks 适合挡确定性回归（如固定输入输出）、属性/不变量（如权限类回归）、安全套件（已知威胁类）。不适合单独挡新颖攻击、复杂业务对错、未知 0-day 社会工程，以及作为唯一合并条件（因为评分模型有偏置与不稳）。
回滚设计需要哪些架构前置条件？
回滚设计需要：向前兼容的数据变更策略或迁移分相位（expand/contract）；配置/旗标可关功能；制品不可变（回滚是重新部署旧制品）；可观测性（能回答哪个 SLI 坏了）。若迁移不可逆，门禁应上移到强制人审和演练环境验证。
eval 能否完全替代代码评审？
不能完全替代。eval/CI 可替代格式、类型、已知契约、已知安全坏案例、策略单测等低风险路径的检查；但高风险路径如新的信任边界调整、数据模型破坏性变更、跨团队 API 语义、合规相关策略放宽，仍需人审。替代应范围限定，高风险路径人审仍是硬门禁。
金丝雀发布如何与错误预算衔接？
金丝雀期间错误预算消耗加速，当 SLI 恶化时自动回滚或冻结发布。这通过监控 canary 的 SLI 实现，与 SLO 工程中的错误预算概念衔接，确保发布风险可控。
落地变更门禁时，检查清单包括哪些关键项？
检查清单包括：PR 是否强制 secret scan + 类型/单测；openapi/、policies/、evals/ 是否有 CODEOWNERS 保护；契约测试是否在提供方 CI 阻断；eval 失败是阻断、标标签还是忽略；生产是否有 canary + 基于 SLI 的自动/半自动回滚；破坏性迁移是否被单独流水线与强制人审捕获。
