AI SDD 开发规范-24-完整、可落地的事后检验 + Gate 限制体系
2025/12/27大约 4 分钟
AI 编码执行期标准 Prompt（Execution-Time Prompt Template）
这是AI 编码体系里最后、也是最容易被低估的一环。
你前面已经把 事前（Snapshot）+ 事中（Execution Prompt）做到了工程级水准，如果事后没有 Gate，整体仍然是“不闭环的”。
结论先行：
AI 编码后的校验，必须从“结果检查”升级为“多层 Gate 驱动的发布判定系统”。
下面我会给你一套完整、可落地的事后检验 + Gate 限制体系，而且是专门为 AI 编码设计的，不是人类 CI 的简单复用。
一、核心原则（非常重要）
传统 CI 的假设是：
代码是人写的，意图可信，只验证结果
AI 编码的现实是：
代码是“机器推导”的，意图不完全可信，必须同时验证：
- 结果是否正确
- 修改是否越权
- 风险是否被低估
所以 Gate 不是一层，而是分层、分权、可否决的。
二、AI 编码后的五层 Gate 体系（推荐）
整体结构如下：
AI Commit
↓
Gate 0：变更合法性 Gate（AI 特有）
↓
Gate 1：编译 / 静态校验 Gate
↓
Gate 2：单元 / 契约 Gate
↓
Gate 3：行为 / 回归 / QA Gate
↓
Gate 4：性能 / 稳定性 / 风险 Gate任何一层失败，直接阻断，不允许“带病进入下一层”。
三、Gate 0：AI 变更合法性 Gate（极其关键）
这是人类 CI 几乎没有的，但 AI 必须有
目标
验证：AI 是否遵守了 Execution Contract
核心检查项
- 是否只修改了 Snapshot 授权范围内的文件？
- 是否触碰了禁止目录 / 高风险模块？
- 是否存在“未声明意图的修改”？
- 是否出现与 PLAN 不一致的改动？实现方式（工程可落地）
Git Diff + Snapshot 白名单路径
AST / Diff 规则检测：
- 新增 public API？
- 方法职责扩大？
强制要求：
- AI Step → Commit Message → Intent 对齐
Gate 0 不通过 = 不看代码质量，直接打回
四、Gate 1：编译 + 静态校验 Gate（硬门槛）
目标
验证：代码在工程层面是否“站得住”
最小必选项
- 编译 / 构建通过
- Lint / 格式校验
- 静态分析（空指针、资源泄漏、并发）关键建议（AI 场景）
- Warnings 视为 Errors（至少对 AI Commit）
- 禁止 AI 引入新的 Warning Baseline
五、Gate 2：单元 / 契约 Gate（语义正确性）
这是防止“编译通过但行为错误”的第一道防线
必须覆盖的三类测试
1. 新增 / 修改逻辑对应的单元测试
2. 关键分支 / 异常路径
3. 对外接口的契约测试（若有）AI 特有规则
- AI 修改了逻辑 → 必须同步更新或新增测试
- 未覆盖的分支 → 明确声明原因不允许“我觉得不用测”
六、Gate 3：行为回归 / QA Gate（系统层面）
目标
验证：系统行为是否与“设计意图 + 历史行为”一致
推荐手段
- 回归测试
- 核心业务用例自动化
- Mock 下游 / 回放历史流量（如有）
AI 风险点重点关注
- 边界条件变化
- 默认值变化
- 异常处理路径变化七、Gate 4：性能 / 稳定性 / 风险 Gate（发布前）
这是防止“功能正确但线上事故”的最后一道门
核心检查维度
性能：
- 延迟是否退化
- QPS / 资源消耗是否异常
稳定性：
- 重试 / 超时 / 熔断行为是否变化
风险：
- 是否引入不可回滚改动
- 是否触碰 Failure Budget 红线非强制但强烈建议
- 与历史版本做 对比基线
- 不看绝对值，看 变化趋势
八、Gate 的裁决权设计（非常重要）
建议的裁决权模型
| Gate | 裁决权 |
|---|---|
| Gate 0 | 规则自动否决 |
| Gate 1 | 系统自动 |
| Gate 2 | 自动 + 人 |
| Gate 3 | 人为主 |
| Gate 4 | 技术负责人 |
越靠前越自动，越靠后越需要人
九、AI 编码的“发布资格判定公式”
你可以明确写成一句话规则：
AI 代码 ≠ 测试通过即可发布
AI 代码 = 合法 + 正确 + 可控 + 风险可接受十、给你一个高度关键的判断
AI 编码的核心不是“写得对不对”，
而是“有没有被一套制度驯化”。
你现在已经完成了：
- 事前：认知冻结
- 事中：执行约束
- 事后：多层 Gate
这三点合在一起，已经是：
AI 软件工程治理体系（而不是工具使用技巧）