从代码冻结到交付后监控的完整流程，AI 分工与人工职责边界。
发布是一个决策密集阶段
日常开发中，AI 可以大量参与生成和初筛。发布阶段的差异在于：每个决策的影响范围更大，可逆性更低。变更日志写错了可以改，但时机选错了导致的事故影响的是真实用户。
因此发布阶段的核心原则是：AI 处理信息聚合，人类做发布决策。不是 AI 不能做决策，而是这类决策的风险高度、背景复杂度和责任归属都要求人工判断。
发布流程
代码冻结 → AI 生成变更日志初稿 → 人工审查 → 发布说明定稿 → 部署 → 交付后监控
代码冻结
代码冻结标志着”本次发布的内容边界已经确定”。
冻结期间的规则：
– 只允许合并明确标记为当前版本修复的 PR
– AI 驱动的大规模生成（重构、批量修改）必须在冻结前完成，冻结后的 AI 生成内容需要特别严格的审查
– 每次例外合并都需要明确说明为什么这个变更值得引入的风险
为什么 AI 场景下代码冻结更重要：AI 可以在很短时间内生成大量代码变更。没有冻结边界，发布内容难以预测和审查。冻结强制对”什么进了这次发布”做出人工确认。
AI 生成变更日志
变更日志是 AI 擅长的任务：聚合 git 提交记录、PR 描述、关联的 REQ 文档，生成结构化的变更摘要。
给 AI 的上下文应该包括：
– 本次发布的 git 范围（从上次 tag 到当前）
– 各 PR 和 REQ 文档
– 目标受众（内部团队 vs. 外部用户）
要求 AI 生成的结构：
[版本号] [发布日期]
新功能
- [功能描述，用户视角]
改进
- [改进描述]
修复
- [Bug 修复描述]
已知限制
- [本次发布未解决的已知问题]
AI 生成变更日志的局限：它只能处理提交记录和 PR 描述里有的信息。如果提交信息写得模糊（”fix bug”、”update code”），变更日志质量也会低。提交信息的质量决定变更日志的质量。
人工审查变更日志
检查以下内容：
- 是否有遗漏的重要变更（AI 可能跳过了没有对应 PR 的直接提交）
- 技术描述是否对目标受众适合（用户不需要知道”重构了数据库查询层”）
- 已知限制是否完整（这是对用户的诚实承诺，不能遗漏）
- 版本号是否遵循语义化版本规则
发布时机决策（人工）
AI 不参与时机决策。以下因素需要人工综合判断：
- 当前运营情况（高峰期不发布）
- 团队状态（发布时需要有人在线响应问题）
- 用户通知（需要提前告知的变更）
- 回滚预案的完备程度
部署和交付后监控
部署前确认清单（人工）：
– 回滚方案已准备，回滚时间已评估
– 关键监控指标已确认处于正常状态
– 负责人在线，可以响应发布后 1 小时内的问题
交付后监控窗口：
– 0-30 分钟：主动监控核心指标（错误率、响应时间、关键业务流程）
– 30 分钟 – 2 小时：持续观察，响应用户反馈
– 2 小时后：如果无异常，正式确认发布成功
AI 可以辅助分析监控数据和日志异常，但”是否需要回滚”的判断由人工做出。
发布说明 vs. 变更日志
两者面向不同受众，内容侧重不同：
| 变更日志 | 发布说明 | |
|---|---|---|
| 受众 | 开发团队、内部用户 | 外部用户、客户 |
| 内容 | 完整的技术变更列表 | 对用户有影响的变化，用户语言 |
| 细节程度 | 较详细，含技术描述 | 较简洁，聚焦用户影响 |
| AI 参与 | 生成初稿 | 在变更日志基础上提炼 |
两者都由 AI 生成初稿，人工审查后定稿。区别在于人工审查时的关注点不同。
紧急发布
计划外的紧急修复（Hotfix）走缩短流程，但不跳过关键决策节点：
问题确认 → 修复生成（AI 辅助）→ 快速审查（至少一人）→ 部署 → 监控 → 补充变更日志
不能省略的：至少一人的代码审查，和部署后的主动监控。
可以简化的：变更日志可以在部署后补充，发布说明可以延后到标准发布周期。
紧急发布后，在下一个常规复盘中补充记录：为什么需要紧急发布，如何避免类似情况。