wehub-skill-sync
64 lines
2.6 KiB
Markdown
64 lines
2.6 KiB
Markdown
---
|
||
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 或其他格式，请相应转换。
|