【系统架构设计】防御性架构：用系统设计约束 AI 犯错
内容提要
本文探讨AI生成代码时代，系统架构需通过设计约束控制错误爆炸半径。核心是分层防御：类型系统、Schema契约、契约测试、策略引擎和运行时沙箱，将错误限制在可接受范围内。强调硬约束优于提示词，按副作用不可逆性分层设置约束强度，并指出不可逆路径省略硬闸门是已知反模式。
延伸解读
硬约束与软约束的分界
文章强调，提示词属于软约束，模型可能遗忘或忽略，而架构硬约束应落在编译器、校验器、策略引擎等机器可判定层。这一区分对工程实践有直接指导意义：在设计AI协作流程时，应优先构建可自动执行的检查，而非依赖模型自觉遵守规范。
按副作用不可逆性分层设防
文章提出按副作用不可逆性分层设置约束强度，而非一刀切。例如，文档、文案等低风险变更可放宽约束，而支付、权限等不可逆路径需叠加契约、策略、沙箱与人审。这种分层策略有助于在速度与安全之间取得平衡，避免过度约束拖慢开发。
约束失败应成为可观测信号
文章建议将schema校验失败、策略拒绝等约束违反转化为可聚合的指标，作为变更质量的SLI。这提示工程团队应建立约束失败的监控体系，而非仅依赖日志，从而客观衡量AI生成代码的破坏性变更被拦截的情况，为质量改进提供数据支撑。
Q&A
什么是防御性架构？它主要解决什么问题？
防御性架构是在AI生成代码时代，通过系统设计约束（如类型系统、Schema契约、契约测试、策略引擎和运行时沙箱）来控制错误爆炸半径的架构方法。它主要解决AI生成代码可能带来的越权调用、契约漂移和校验缺失等失败模式，将错误限制在可接受范围内。
AI生成代码时代，系统架构需要防范哪些典型失败？
AI生成代码时代，系统架构需要防范三类典型失败：越权调用（如生成客户端直接访问内部管理API或使用高权限token）、契约漂移（如字段改名、可选变必填、枚举漏分支）和校验缺失（如跳过鉴权、幂等键、输入边界）。这些失败在人工协作中也存在，但AI改变了速率和覆盖面。
类型系统、Schema契约、契约测试、策略引擎和运行时沙箱分别能钉住什么错误？
类型系统能钉住签名不匹配、空安全和部分不变量；Schema契约能钉住字段缺失、类型错误和枚举越界；契约测试能钉住已登记的交互被破坏；策略引擎能钉住权限逻辑漏洞；运行时沙箱能限制执行环境的损害，如只读DB角色、网络白名单等。但每层都有钉不住的地方，如类型系统钉不住业务语义错误，Schema钉不住语义正确但业务危险的合法请求。
为什么提示词不能作为控制面？硬约束应该落在哪里？
提示词是软约束，模型可能遵守也可能遗忘，不能作为控制面。硬约束必须落在编译器、校验器、策略引擎、身份与隔离等系统层面，确保生成物要么通过校验器，要么进不了主干。
如何按副作用不可逆性分层设置约束强度？
按副作用不可逆性分层设置约束强度：文档、注释等低风险变更使用低约束；内部只读API或实验功能使用中等约束（类型+Schema）；支付、权限、多租户数据面等不可逆或合规敏感路径使用高约束（契约+策略+沙箱+人审）。
在不可逆路径上省略硬闸门有什么风险？
在不可逆路径上省略硬闸门是已知反模式，与是否使用AI无关，但AI会提高触发频率。例如支付、权限等路径如果没有硬约束，AI生成代码可能直接导致资金损失或权限漏洞。
防御性架构的落地检查清单包括哪些内容？
落地检查清单包括：生产写路径与AI/CI身份是否默认最小权限；对外API是否有版本化OpenAPI/JSON Schema并在CI校验；跨服务依赖是否有契约测试；授权是否集中在策略引擎且默认拒绝；高风险工具/迁移是否有沙箱与人审；约束失败是否有metrics。
