Back to Details

release-notes

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Release Notes Generator

发布说明生成器

Transform technical tickets, PRDs, or internal changelogs into polished, user-facing release notes.
将技术工单、PRD或内部变更日志转换为简洁专业、面向用户的发布说明。

Context

背景信息

You are writing release notes for $ARGUMENTS.
If the user provides files (JIRA exports, Linear tickets, PRDs, Git logs, or internal changelogs), read them first. If they mention a product URL, use web search to understand the product and audience.
你正在为**$ARGUMENTS**撰写发布说明。
如果用户提供了文件（JIRA导出文件、Linear工单、PRD、Git日志或内部变更日志），请先阅读这些文件。如果用户提到了产品URL，请通过网页搜索了解产品和目标受众。

Instructions

操作步骤

  1. Gather raw material: Read all provided tickets, changelogs, or descriptions. Extract:
    • What changed (feature, improvement, or fix)
    • Who it affects (which user segment)
    • Why it matters (the user benefit)
  2. Categorize changes:
    • New Features: Entirely new capabilities
    • Improvements: Enhancements to existing features
    • Bug Fixes: Issues resolved
    • Breaking Changes: Anything that requires user action (migrations, API changes)
    • Deprecations: Features being sunset
  3. Write each entry following these principles:
    • Lead with the user benefit, not the technical change
    • Use plain language — avoid jargon, internal codenames, or ticket numbers
    • Keep each entry to 1-3 sentences
    • Include visuals or screenshots if the user provides them
    Example transformations:
    • Technical: "Implemented Redis caching layer for dashboard API endpoints"
    • User-facing: "Dashboards now load up to 3× faster, so you spend less time waiting and more time analyzing."
    • Technical: "Fixed race condition in concurrent checkout flow"
    • User-facing: "Fixed an issue where some orders could fail during high-traffic periods."
  4. Structure the release notes:
    # [Product Name] — [Version / Date]

## New Features
- **[Feature name]**: [1-2 sentence description of what it does and why it matters]

## Improvements
- **[Area]**: [What got better and how it helps]

## Bug Fixes
- Fixed [issue description in user terms]

## Breaking Changes (if any)
- **Action required**: [What users need to do]
  5. Adjust tone to match the product's voice — professional for B2B, friendly for consumer, developer-focused for APIs.
Save as a markdown document. If the user wants HTML or another format, convert accordingly.
  1. 收集原始素材：阅读所有提供的工单、变更日志或描述内容，提取以下信息：
    • 变更内容（功能、改进或修复）
    • 影响人群（哪些用户群体）
    • 重要性（用户能获得的收益）
  2. 对变更进行分类：
    • 新功能：全新的功能能力
    • 功能改进：对现有功能的增强
    • Bug修复：已解决的问题
    • 破坏性变更：任何需要用户采取行动的变更（如迁移、API变更）
    • 功能弃用：即将下线的功能
  3. 撰写每条条目需遵循以下原则：
    • 优先突出用户收益，而非技术变更细节
    • 使用通俗易懂的语言 — 避免行话、内部代号或工单号
    • 每条条目控制在1-3句话
    • 如果用户提供了图片或截图，请包含在内
    示例转换：
    • 技术表述："Implemented Redis caching layer for dashboard API endpoints"
    • 面向用户的表述："仪表板加载速度现在提升了最高3倍，让您减少等待时间，专注于数据分析。"
    • 技术表述："Fixed race condition in concurrent checkout flow"
    • 面向用户的表述："修复了高流量时段部分订单可能失败的问题。"
  4. 发布说明结构：
    # [Product Name] — [Version / Date]

## New Features
- **[Feature name]**: [1-2 sentence description of what it does and why it matters]

## Improvements
- **[Area]**: [What got better and how it helps]

## Bug Fixes
- Fixed [issue description in user terms]

## Breaking Changes (if any)
- **Action required**: [What users need to do]
  5. 调整语气以匹配产品风格 — B2B产品使用专业语气，消费级产品使用友好语气，API相关则侧重开发者视角。
保存为Markdown文档。如果用户需要HTML或其他格式，请进行相应转换。