---
name: release-notes
description: "根据工单、产品需求文档或更新日志生成面向用户的发布说明。创建按类别（新功能、改进、修复）组织的清晰、吸引人的摘要。在编写发布说明、创建更新日志、宣布产品更新或总结已发布内容时使用。"
---

## 发布说明生成器

将技术工单、产品需求文档或内部更新日志转化为经过润色的、面向用户的发布说明。

### 上下文

你正在为 **$ARGUMENTS** 编写发布说明。

如果用户提供了文件（JIRA 导出、Linear 工单、产品需求文档、Git 日志或内部更新日志），请先阅读它们。如果用户提到了产品 URL，请使用网页搜索来了解产品和受众。

### 操作说明

1. **收集原始素材**：阅读所有提供的工单、更新日志或描述。提取以下信息：
   - 什么发生了变化（功能、改进还是修复）
   - 影响谁（哪个用户群体）
   - 为什么重要（用户收益）

2. **对变更进行分类**：
   - **新功能**：全新的能力
   - **改进**：对现有功能的增强
   - **Bug 修复**：已解决的问题
   - **破坏性变更**：需要用户采取行动的任何内容（迁移、API 变更）
   - **弃用**：正在逐步淘汰的功能

3. **按照以下原则编写每条条目**：
   - 以用户收益开头，而非技术变更
   - 使用通俗易懂的语言——避免行话、内部代号或工单编号
   - 每条条目控制在 1-3 句话
   - 如果用户提供了视觉素材或截图，请一并包含

   **转换示例**：
   - 技术性："为仪表盘 API 端点实现了 Redis 缓存层"
   - 面向用户："仪表盘加载速度提升最高 3 倍，让你减少等待时间，把更多时间花在分析上。"

   - 技术性："修复了并发结账流程中的竞态条件"
   - 面向用户："修复了在高流量时段某些订单可能失败的问题。"

4. **组织发布说明的结构**：

   ```
   # [产品名称] — [版本 / 日期]

   ## 新功能
   - **[功能名称]**：[1-2 句描述，说明它的功能及重要性]

   ## 改进
   - **[领域]**：[哪些方面得到了改善及其帮助]

   ## Bug 修复
   - 修复了[用用户能理解的术语描述的问题]

   ## 破坏性变更（如有）
   - **需要采取行动**：[用户需要做什么]
   ```

5. **调整语气**，使其与产品的调性相匹配——B2B 产品使用专业语气，面向消费者的产品使用友好语气，API 产品使用开发者导向的语气。

保存为 Markdown 文档。如果用户需要 HTML 或其他格式，请相应转换。