AI 编码工具提高了代码产量，却没有同步扩大审查和发布能力。结果是 PR 越积越多，合并风险变得模糊，发布窗口一再后移。Zadig v5.0 上线 AI 审查专员与 AI 发布专员，瞄准的正是这个新瓶颈：让 AI 不只参与代码生成，也进入审查、发布和风险决策链路。
真正的问题不是写得慢，而是看不完
来源摘要提到，团队原本两天能完成的审查工作被拖到五天，甚至出现代码已经进入 main，团队却没有完整看过的情况。GitLab 对 1528 名开发者的调研中，85% 的受访者表示，AI 已把瓶颈从写代码转移到审代码。
这类问题通常不是单纯增加审查人手就能解决。AI 生成代码具有三个放大效应：
- 变更数量增加：同一时间进入队列的 PR 更多。
- 表面完整度提高：代码、注释和测试看起来都很齐全，审查者反而需要花更多时间确认其语义是否正确。
- 风险集中到下游：生成阶段节省的时间，可能转化为合并、验证和发布阶段的等待时间。
因此，审查系统需要回答的不只是“代码是否规范”，还包括“这次改动影响什么”“现有测试是否覆盖关键路径”“是否适合进入当前发布窗口”。
两类 AI 专员应该承担不同职责
AI 审查专员更适合处理进入主干前的分析工作，例如归纳变更范围、识别高风险文件、检查测试缺口，并向人工审查者解释为什么某处值得重点关注。它的价值不在于替人点击 Approve，而在于压缩理解代码所需的时间。
AI 发布专员面对的是另一组问题：某个版本包含哪些变更、风险是否可接受、验证结果是否满足发布条件，以及失败后应执行什么处置。发布环节必须基于流水线事实做判断，不能只读取 PR 描述后生成一段看似合理的结论。
两者可以形成连续链路：
- AI 审查专员分析 PR，并输出结构化风险与测试建议。
- CI 执行测试、安全扫描和质量检查。
- AI 发布专员汇总变更与验证结果，生成发布判断依据。
- 策略引擎执行硬性门禁，高风险操作仍由责任人确认。
这里要保留清晰边界：AI 可以排序、解释和建议，但生产发布权限、敏感配置变更以及高风险豁免，不应只由模型结论决定。
可以这样实践：把 AI 结论变成可验证的门禁
下面是一个可改造的最小示例，并非 Zadig v5.0 的实际配置格式。假设 AI 审查步骤会生成 review.json，CI 再使用确定性脚本判断是否允许继续发布。
先创建 review.json：
{
"risk_level": "medium",
"blocking_findings": [],
"tests_required": ["unit", "integration"],
"tests_passed": ["unit", "integration"]
}
再创建 release_gate.py：
#!/usr/bin/env python3
import json
import sys
from pathlib import Path
report_path = Path(sys.argv[1] if len(sys.argv) > 1 else "review.json")
report = json.loads(report_path.read_text(encoding="utf-8"))
risk = report.get("risk_level", "unknown")
blockers = report.get("blocking_findings", [])
required = set(report.get("tests_required", []))
passed = set(report.get("tests_passed", []))
missing = sorted(required - passed)
errors = []
if risk in {"high", "critical", "unknown"}:
errors.append(f"risk level requires manual approval: {risk}")
if blockers:
errors.append(f"blocking findings: {len(blockers)}")
if missing:
errors.append("missing tests: " + ", ".join(missing))
if errors:
print("RELEASE BLOCKED")
for error in errors:
print(f"- {error}")
raise SystemExit(1)
print("RELEASE GATE PASSED")
运行方式：
python3 release_gate.py review.json
这个设计有两个关键点。模型负责生成风险分析，脚本负责执行稳定、可审计的规则；即使以后更换模型，发布门禁也不会随着提示词波动。实际接入流水线时，还应使用 JSON Schema 校验报告，避免字段缺失或模型输出格式漂移。
AI 审查步骤的提示词也应要求结构化证据，而不是只问“这段代码有没有问题”。可以从下面的模板开始改造：
你是代码审查专员。请基于代码差异、测试结果和变更说明完成审查。
必须输出 JSON，字段包括：
- risk_level: low | medium | high | critical
- changed_components: 受影响组件列表
- blocking_findings: 阻断问题列表，每项包含文件、原因和证据
- tests_required: 本次变更必须运行的测试类型
- review_focus: 人工审查者需要重点确认的内容
约束：
1. 不得把缺少证据的猜测写成确定结论。
2. 涉及鉴权、数据库迁移、资金或生产配置时，至少标记为 high。
3. 无法确认测试覆盖时，明确指出缺口，不得默认测试充分。
落地时先控制权限，再追求自动化率
引入 AI 发布和审查能力时，适合从影子模式开始：AI 只生成报告，不阻断合并，也不触发生产发布。团队可以连续观察若干迭代，对比 AI 发现、人工结论和真实缺陷，再决定哪些规则可以进入强制门禁。
正式采用前，应检查以下事项：
- AI 结论是否附带文件、差异或测试结果等可追溯证据。
- 高风险变更是否要求代码所有者或发布负责人确认。
- 模型不可用、超时或输出无效时，流水线是否默认进入安全状态。
- 提交给模型的源码、日志和配置是否符合数据安全要求。
- 发布记录是否保留模型版本、提示词版本、输入摘要和最终决策人。
- 是否持续统计误报、漏报、审查耗时和发布失败率。
Zadig v5.0 所反映的变化，不只是给研发平台增加两个 AI 角色，而是把 AI 从“代码生产工具”推向“交付协作角色”。真正有效的落地方式，是让模型负责理解大量上下文，让规则系统守住确定性边界，让人继续拥有高风险决策权。