KishoreCR728/project-video

项目转视频

将任何项目转化为优质的营销视频。该技能在项目的仓库内部（或针对某个 URL）运行，分析产品的真实情况，并基于真实的功能和界面生成 Remotion 视频。

黄金法则：流水线是 分析 → 故事板 → 审批 → 构建 → 渲染。在故事板获得用户批准之前，绝不编写任何 Remotion 代码。

自动模式： 如果用户的请求包含“全自动”、“无中断”、“一次完成”、“自动驾驶”等明确要求不间断端到端运行的词汇，则切换至自动模式：跳过故事板审批暂停（写入 video/storyboard.md，声明你正在以自动模式进行，并直接进入构建阶段），使用合理的默认值（解说类型、1080×1920 @ 30fps、按标准优先级顺序的品牌标记）自动决定所有开放性问题，并且仅在遇到真正的障碍（网站不可达、经过 3 次修复尝试后仍然存在的渲染错误）时停止。启动本地开发服务器仍然需要明确的用户授权——但如果用户提供了运行命令，或者仓库有明确的标准开发命令（npm run dev、docker compose up），则“全自动”本身可视为该授权。在自动模式下，仍然在提供 MP4 的同时交付故事板，以便用户事后查看并请求修改单个场景。

阶段 0 — 检测输入

确定可供使用的内容，按优先级排序：

1. 实时 URL （生产或 UAT/预发布）——最佳来源。如果未提供，请向用户索要。
2. 本地开发服务器 ——如果仓库存在但没有任何内容在运行，提供启动它的选项。读取 package.json / docker-compose.yml / Makefile / README 以找到开发命令。在启动任何内容之前，请让用户确认（环境变量、端口和数据库各不相同）。如果无法启动，则回退到仅代码分析。
3. 仅代码 ——静态分析仓库；视觉将完全是纯 SVG 重建。

此外，还要询问（或从上下文中推断）：

• 哪种视频类型？（解说 / 演示 / 发布 / 预告片——参见 references/video-archetypes.md）
• 哪种宽高比？默认：1080×1920 竖屏，30 fps。提供 16:9 和 1:1 作为额外渲染。
• 是否有品牌标记？检查仓库中是否有设计标记 JSON；否则从实时网站提取颜色/字体；否则使用 assets/brand-theme.json 的默认值。

阶段 1 — 分析项目

目标：创建一个 video/project-brief.md 文件，后续所有声明均可追溯至此。

静态分析 ——读取 README、docs/、仓库中的登录页面文案、路由/页面结构、功能模块、产品名称和标语。

实时分析 （如果 URL 存在）——使用 Playwright 运行 scripts/capture-screens.mjs 以：

• 在目标宽高比和桌面尺寸下截取关键页面（首页/主屏、仪表盘、3–5 个核心功能界面）的截图
• 如果类型是演示或发布，则录制 1–2 个核心流程的简短（3–6 秒）屏幕捕捉
• 提取网站的实际颜色、字体和标题文案

写入 video/project-brief.md，包含：产品是什么、目标受众、前 5–7 个功能（每个都需注明证据来源）、视觉标识（颜色/字体/标志）以及所截取素材的列表及其文件路径。

规则：不虚构功能，不夸大其词。 如果仓库、文档或实时网站中不存在，则该内容不得出现在视频中。

阶段 2 — 故事板（强制审批门）

阅读所选类型的 references/video-archetypes.md 以获得场景结构和时长，然后使用仅来自项目简报的内容，逐个场景填充 references/storyboard-template.md。

• 旁白采用屏幕文本，而非画外音。保持屏幕上的文本简短（每次最多约 8 个单词，最多同时显示 2 行），并安排好节奏，使每个单词在屏幕上可读的最小时间约为 0.35 秒。
• 预先为每个场景分配帧数，使得总帧数精确匹配类型的时长。
• 对于每个场景，标记哪些视觉效果是 SVG，哪些是设备框架内的真实 UI 截取（混合风格——参见标准文档）。
• 在末尾添加音乐和声音建议部分（类型、BPM 感觉、重音落在何处）。不要提供或嵌入音频文件。

保存为 video/storyboard.md，呈现给用户，然后停止。在用户批准或编辑之前，不得继续。（例外：在自动模式下，呈现故事板摘要并立即继续，无需等待。）

阶段 3 — 构建 Remotion 项目

获得批准后，完整阅读 references/remotion-standards.md ——它包含了所需的动画值、过渡规则以及混合 SVG + 截图设备框架模式。然后搭建脚手架：

video/
├── remotion.config.ts
├── src/
│   ├── index.ts            # registerRoot
│   ├── Root.tsx            # 每个宽高比对应一个 <Composition>
│   ├── config.ts           # fps、持续时间、每个场景的帧预算
│   ├── theme.ts            # 所有颜色/字体/间距——单一数据来源
│   ├── scenes/             # 故事板每个场景对应一个文件
│   ├── components/         # DeviceFrame、CountUp、AnimatedChart、ConnectorLine、ParticleField、TextReveal…
│   └── assets/screens/     # 阶段 1 截取（通过 staticFile 导入）

硬性规则：

• 每个颜色、字体、圆角半径和阴影都来自 theme.ts。场景中不得有硬编码值。
• 场景持续时间来自 config.ts，必须总和等于该类型总时长。
• 所有图表/图表/图标图形均为内联 SVG。真实的 UI 仅出现在使用阶段 1 截图的 DeviceFrame 组件内部——切勿在存在真实截图的场景中，用 SVG 伪造产品截图。
• 全程使用 TypeScript、Remotion 4.x、@remotion/transitions 实现场景切换。

阶段 4 — 预览、渲染、交付

1. npx remotion studio ——验证每个动画，以实际播放速度检查文本可读性，确认时间安排。
2. 修复问题，然后执行 npx remotion render <CompositionId> out/<视频类型>-vertical.mp4。
3. 如果需要，渲染其他宽高比。
4. 交付：MP4 文件、storyboard.md、project-brief.md 以及可编辑的项目。提及 theme.ts 和 config.ts 是用于重新品牌化或重新调整时间安排的两个关键文件。

参考文件

• references/video-archetypes.md ——解说（60 秒）、演示（75–90 秒）、功能发布（30 秒）、预告片（15 秒）的场景结构 + 时长。在阶段 0/2 期间阅读。
• references/storyboard-template.md ——每个场景的表格格式。在阶段 2 期间阅读。
• references/remotion-standards.md ——动画值、过渡、混合设备框架模式、SVG 规则。在阶段 3 之前完整阅读。
• scripts/capture-screens.mjs ——Playwright 截取脚本。在阶段 1 期间运行（node scripts/capture-screens.mjs <url> <outDir>；需要 npm i playwright + npx playwright install chromium）。
• assets/brand-theme.json ——回退品牌标记；尽可能使用项目提取的值覆盖。