发布门控（Release Gate）

一款轻量、可配置的 AI 智能体部署门控机制。在执行不可逆操作前强制执行结构化签核流程——未完成明确清单即禁止部署。

何时使用本技能

在执行以下任一操作前，请先阅读本技能：

• 难以回滚 — 例如 systemctl restart、数据库迁移、文件部署、数据删除
• 面向客户 — 例如公开上线、网站更新、定价变更
• 高风险操作 — 例如支付处理、向真实用户发送邮件、法律文件正式生效
• 需团队协同 — 例如需多个智能体或人类角色事先对齐

快速开始

部署前：完整执行发布门控检查清单。
任一项目未勾选则阻断部署。无论结果如何，均须记录日志。

最小化门控（单评审人）

## 发布门控 — [功能名称]

### 开发签核（Dev Sign-Off）
- [ ] 代码已测试且运行正常
- [ ] 现有功能无回归问题
- [ ] 未硬编码密钥与凭证

### 最终检查（Final Check）
- [ ] 上述所有复选框均已勾选
- [ ] 部署者：[姓名/智能体名称]

若任一复选框未勾选：立即阻断（BLOCK）。修复后重新执行。

完整门控（多角色）

## 发布门控 — [功能名称]
日期：YYYY-MM-DD  
部署者：[智能体或人员姓名]

### 开发签核（Dev Sign-Off）
- [ ] 功能已完成端到端构建与测试
- [ ] 未破坏任何现有路由/接口
- [ ] 数据库迁移安全且为增量式（无破坏性 Schema 变更）
- [ ] 已完成安全审查：认证、输入校验、IDOR、速率限制

### 产品 / 文案签核（Product / Copy Sign-Off）
- [ ] 网站/UI 已体现该功能
- [ ] 文案准确描述代码实际行为
- [ ] 不得为尚未实现在代码中的功能编写网站文案
- [ ] 所有页面/触点的定价信息保持一致

### 法务 / 合规签核（Legal / Compliance Sign-Off，如适用）
- [ ] 隐私政策已涵盖本功能
- [ ] 已核查监管要求（TCPA、GDPR、COPPA 等）
- [ ] 已审阅所有第三方条款

### 最终检查（Final Check）
- [ ] 上述所有角色均已达成一致
- [ ] 无待解决的阻塞项
- [ ] 已向 deployments.log 写入日志条目

若任一复选框未勾选：立即阻断部署（BLOCK THE DEPLOY）。须先完成对齐。

角色定义 — 请按团队实际情况定制

仅定义与项目相关的角色。独立开发者只需 Dev + Final Check 即可。

配置您的门控

将适配您项目的模板复制到工作区中，保存为 DEPLOY_GATE.md（或内联至项目 AGENTS.md 中）。自定义检查项内容及角色名称。

示例：SaaS 初创公司

# 发布门控 — MyApp

## 角色
- Dev：代码、安全、数据库
- Product：文案、定价、UI
- Legal：隐私、合规

## 触发条件
- systemctl restart myapp
- app.py、models.py、templates/ 的变更
- landing_page.html 的任意更新
- 定价变更

## 门控检查清单
### Dev
- [ ] 已在本地 + 预发布环境完成测试
- [ ] 数据库迁移安全（仅允许增量式）
- [ ] 无硬编码密钥

### Product
- [ ] 网站已同步新功能
- [ ] 如需，定价页面已更新

### Orchestrator
- [ ] Dev 与 Product 已对齐
- [ ] 已写入日志条目

## 日志文件
/opt/myapp/logs/deployments.log

日志记录

每次门控执行（无论通过或阻断）均必须记录。

日志格式

[2026-03-30 04:00 UTC] DEPLOY: 添加 Stripe 支付入口
  功能：Stripe 支付集成 v1
  Dev：PASS | Product：PASS | Legal：PASS
  部署者：[智能体或人员]
  结果：APPROVED — 已执行 systemctl restart myapp

[2026-03-30 04:00 UTC] BLOCKED: 添加 Stripe 支付入口
  功能：Stripe 支付集成 v1
  Dev：PASS | Product：BLOCKED（定价页面未更新）
  部署者：[智能体或人员]
  结果：BLOCKED — 部署暂停，待 Product 角色更新定价页面

Python 日志辅助函数

from scripts.release_gate import log_gate_decision

log_gate_decision(
    log_file="/opt/myapp/logs/deployments.log",
    feature="Stripe checkout v1",
    roles={"Dev": "PASS", "Product": "PASS", "Legal": "PASS"},
    result="APPROVED",
    deployer="[your agent or name]",
    notes="systemctl restart myapp"
)

硬性规则

1. 任一未勾选项 = 阻断（BLOCK）。 不得在存在未完成项的情况下部署。
2. 禁止“先部署再修复”。 先修复，再门控，最后部署。
3. 每次决策均须记录日志 —— 无论通过或阻断。日志即审计追踪依据。
4. 门控同样适用于回滚操作。 回滚仍属于一次部署。
5. 若不确定某项操作是否需要门控：它就需要。

应避免的反模式

❌ “只是个小改动” —— 小改动同样会导致生产故障
❌ “文案稍后再更新” —— 上线时网站必须与代码完全匹配
❌ 对涉及用户数据的功能跳过 Legal 行审核
❌ 未记录阻断事件 —— 不完整日志会掩盖问题模式
❌ 仅凭脑内执行门控而不落笔成文

与智能体工作流的集成

部署前钩子模式（Pre-deploy hook pattern）

# 在智能体任务中，于任意部署命令前：
gate_passed = run_release_gate(
    feature="添加订阅计费功能",
    required_roles=["Dev", "Product"],
    checklist={
        "Dev": ["测试通过", "无硬编码密钥", "迁移安全"],
        "Product": ["定价页面已更新", "文案准确"],
    }
)
if not gate_passed:
    raise RuntimeError("发布门控未通过。部署已被阻断。")

与 deploy-gate 技能配合使用

若您的项目已采用 deploy-gate 技能，本技能提供其底层模式与日志工具支持。deploy-gate 是 release-gate 在具体项目中的实例化实现。

本技能不提供的能力

• 不提供运行时强制阻断 —— 无任何代码物理阻止部署。门控生效依赖于智能体被明确指示将其视为硬性规则。
• 不检测门控是否被绕过 —— 若智能体跳过检查清单，系统不会自动发现。日志是您唯一的审计依据。
• 不支持并发审批 —— 若两个智能体同时审批，日志以最后写入为准。多智能体团队应串行化门控执行。
• 不处理日志写入失败 —— 若日志写入失败，部署决策将无法记录。务必在继续前验证日志条目已成功写入。

这是一种由智能体指令驱动的结构化规范，而非运行时强制系统。此设计是刻意为之 —— 与专业工程实践（PR 检查清单、DORA 门控、SOC2 变更管理）所采用的模式一致。纪律本身即是机制。

参考文献

• OWASP 安全部署检查清单：https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/
• 十二要素应用部署指南：https://12factor.net/