> For the complete documentation index, see [llms.txt](https://zhouhao4221.gitbook.io/haiqing-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zhouhao4221.gitbook.io/haiqing-docs/05-workflow/release-workflow.md).

# 发布工作流

从代码冻结到交付后监控的完整流程，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 辅助）→ 快速审查（至少一人）→ 部署 → 监控 → 补充变更日志
```

**不能省略的**：至少一人的代码审查，和部署后的主动监控。

**可以简化的**：变更日志可以在部署后补充，发布说明可以延后到标准发布周期。

紧急发布后，在下一个常规复盘中补充记录：为什么需要紧急发布，如何避免类似情况。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://zhouhao4221.gitbook.io/haiqing-docs/05-workflow/release-workflow.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.