Ozor 变更日志转视频转换器
将变更日志、发布说明和版本更新转化为精美、可直接粘贴的 Ozor.ai 视频提示。此技能读取结构化的变更列表，并生成逐场景的视频提示，以视觉引人入胜的方式宣布更新。
支持的输入类型
- CHANGELOG.md — 标准的 Keep a Changelog 格式
- GitHub 发布 — 带标签的发布描述
- 发布说明 — 带项目符号的功能列表
- 版本摘要 — “新功能”风格文档
- 提交摘要 — 为某个发布而分组的提交消息
- Jira/Linear 发布说明 — 导出的问题列表
工作流程
阶段 1 — 解析变更日志
读取变更日志并提取：
- 版本号 — 发布标签（例如 v2.4.0）
- 发布日期 — 发布时间
- 变更类别 — 按类型分组变更：
- 新功能 — 全新的能力
- 改进 — 对现有功能的增强
- 错误修复 — 已解决的问题
- 破坏性变更 — 任何需要用户操作的内容
- 弃用 — 即将移除的功能
- 头条变更 — 单个最具影响力或用户请求最多的变更
- 变更数量 — 变更总数（用于时长估算）
阶段 2 — 为视频进行优先级排序
并非每个变更日志条目都值得一个场景。应用以下规则：
始终包含：
- 头条功能（最大或最常请求的变更）
- 任何会改变用户工作流程的新功能
- 破坏性变更（用户需要知道）
在空间允许时包含：
- 重大改进（性能、用户体验）
- 高度请求的错误修复
视频中跳过（在注释中提及）：
- 次要的错误修复
- 内部重构
- 依赖更新
- 文档变更
按变更数量的场景预算（目标约每 3 秒视频 1 个场景）：
- 1–3 个变更：6–8 个场景（介绍 + 每个变更 2–3 个场景 + 总结 + CTA）
- 4–7 个变更：10–15 个场景（介绍 + 每个顶级变更 2–3 个场景 + 总结 + CTA）
- 8+ 个变更：15–20 个场景（介绍 + 每个顶级变更 2–3 个场景 + “更多” + CTA）
阶段 3 — 构建视频
使用此经过验证的发布视频结构：
- 介绍 / 版本徽章 — 使用简洁动画显示产品名称和版本号。设定基调：“[产品] [版本] 的新功能”
- 头条功能（2–3 个场景） — 最大的变更获得多个场景，并具有最多的视觉关注：
- 标题 / 它是什么 — 作为标题的功能名称加一句引语。
- 工作原理 / 视觉 — 展示功能实际运行：UI 演示、动画或示意图。
- 影响 / 好处 — 这对用户为什么重要。展示结果或成果。
- 附加功能场景（每个 2–3 个场景） — 每个优先变更都有自己的小序列：
- 标题 / 它是什么 — 功能名称和简短描述。
- 详情 / 视觉 — 视觉展示什么发生了变化：之前/之后、演示或示意图。
- （可选）好处 — 如果变更足够重要，增加一个短场景强调其价值。
- 总结 / “更多” — 如果有被降优先级的变更，添加一个场景简要列出它们：“另外：[修复 1]、[修复 2]、[改进 1]”
- CTA — “立即更新”、“立即尝试”或“阅读完整的发布说明：[URL]”
阶段 4 — 生成 Ozor 提示
输出一个完整的、可直接复制的提示：
## Ozor 视频提示
**来源：** [产品] [版本] 变更日志
**视频类型：** 发布说明 / 新功能
**格式：** 16:9 横屏
**预计时长：** [X] 秒
**目标受众：** [现有用户 / 开发者 / 团队]
---
### 提示（复制并粘贴到 Ozor）
为 [产品] 版本 [X.X] 创建一个 [时长] 的发布说明视频。
[N] 个场景：
(1) 版本徽章 — [产品] 徽标居中位于 [深色/浅色] 背景上。版本号 “[X.X]” 伴随微妙动画出现。副文本：“[发布日期] — [标语或变更数量摘要]”。
(2) [头条功能名称] — 标题卡：功能名称作为粗体标题。一句引语：“[此功能用通俗语言做什么]”。[视觉：代表该功能的图标或图形。]
(3) [头条功能名称] 详情 — [展示功能实际运行：UI 演示、屏幕录制风格动画或逐步示意图。包括确切的屏幕文本。]
(4) [头条功能名称] 影响 — [为什么重要：展示成果、节省的时间或之前/之后对比。屏幕文本：“[关键好处声明]”。]
(5) [功能 2 名称] — 标题卡：“[功能名称]”加一行描述。[视觉：图标、UI 元素或隐喻。]
(6) [功能 2 名称] 详情 — [功能的可视化演示：使用时的样子、工作原理或关键截图风格帧。包括屏幕文本。]
(7) [功能 3 名称] — [功能标题 + 视觉方向。对于较小的功能，一个结合标题和演示的场景即可。]
[...继续处理其余功能，每个主要功能 2–3 个场景，每个次要功能 1 个场景...]
([N-1]) 和更多 — 剩余变更的简洁列表：“[修复 1]”、“[改进 1]”、“[修复 2]”。每个伴随勾选标记动画出现。
([N]) CTA — “[立即更新 / 立即尝试]”并附上 [产品 URL]。徽标淡出。
风格：[简洁 / 现代 / 大胆]。背景：[深色 / 浅色]。强调色：[品牌色]。
语调：[自信 / 兴奋 / 专业]。
受众：[谁]。
---
### 注释
- [关于要上传的素材的建议]
- [被降优先级并可能单独制作视频的变更]
- [迭代技巧]
适应规则
如果变更日志仅包含错误修复：
- 将其定位为可靠性/质量更新
- 以“我们听取了意见”或“已消灭的 Bug”消息开头
- 按主题分组修复，而非逐条列出
- 保持简短：最多 3–4 个场景
如果变更日志包含破坏性变更：
- 突出显示——用户需要看到这一点
- 使用视觉警告指示器（颜色变化、图标）
- 解释发生了什么变化以及用户需要做什么
- 将其放在场景 2（介绍之后）以提高可见性
如果变更日志跨越多个版本：
- 合并为“季度更新”或“年度回顾”格式
- 按主题而非版本号分组
- 以跨版本中最具影响力的变更开头
如果变更日志来自 GitHub 发布：
- 将发布标题提取为视频标题
- 使用标签名称作为版本徽章
- 解析 Markdown 格式以获取项目符号和标题
质量检查清单
在呈现最终提示之前，请核实：
- 版本号在场景 1 中突出显示
- 头条功能获得最多的视觉关注
- 破坏性变更（如有）被明确提及
- 每个场景恰好包含一个变更或想法
- 屏幕文本简短——功能名称加一行描述
- CTA 准确地告诉用户要做什么
- 没有关键变更被无故省略而未提及
- 被降优先级的变更列在注释部分
规则
- 每个获得场景的变更都必须有视觉描述。 “展示新仪表板”是不够的——描述仪表板的外观、动画效果、显示的文本。
- 绝不虚构功能。 每个变更必须源自提供的变更日志。
- 用户影响优先于技术酷炫。 用户请求的小型 UX 修复比大型内部重构更值得放入视频。
- 保持精炼。 发布视频应在 30–60 秒内。30 秒的视频应有约 8–10 个场景；60 秒的视频应有约 15–18 个场景（大致每 3 秒 1 个场景）。用户想要亮点，而不是文档。
- 版本号必须可见。 它出现在场景 1 中，并可选择性地作为持久徽章出现。