video-shotcraft 共同创作引导流程:从产品简报到分镜放行的逐阶段确认协作法

📅 发布时间:2026/10/9 2:06:20
video-shotcraft 共同创作引导流程:从产品简报到分镜放行的逐阶段确认协作法
AI 技能媒体生成视频【免费下载链接】video-shotcraftAI video skill for Claude Code Codex — cinematic product videos with Remotion: 152 shot recipe cards, 209 motion previews, a production-ready template项目地址https://gitcode.com/gh_mirrors/vi/video-shotcraft点击查看免费下载video-shotcraft 的完整宣传片制作分为三种互不合并的模式直接使用模板、自主自由创作、共同创作共同创作是其中唯一带逐阶段用户确认节点的模式。本文围绕 references/guided-free-creation.md 展开完整拆解它的六个确认阶段——产品简报、需求到执行决策表、视觉方向与 styleframe、功能到镜头映射、Gallery 镜头名称解析、分镜确认与制作放行——并结合仓库中的镜头配方卡、Gallery 索引、采集脚本和流水线文档说明每个阶段确认什么、依据什么、产出什么以及放行后如何无重复地衔接后续制作阶段。读完本文你可以掌握一套可复制的协作协议用户只拍板业务与创意决策Agent 承担全部视频工程细节且每个决策都有可追溯的书面依据最终交付的成片可以对照设计 spec 做独立终检。1. 模式定位共同创作在三种模式中的角色SKILL.md 在调用时先判断模式一节中把完整宣传片划分为三条路线直接使用模板走 template/TEMPLATE.md 的原有替换流程不涉及本文的确认节点自主自由创作读 references/pipeline.mdAgent 自主完成阶段 0–7不逐阶段等待确认共同创作读 references/guided-free-creation.md把产品简报、需求决策、视觉方向、镜头映射和最终分镜交给用户确认视频工程细节交给 Agent 执行。共同创作的核心分工在 SKILL.md 中被明确表述为用户确认业务与创意方向Agent 自主完成采集方式、实现参数、SFX 钉帧、Remotion 工程、渲染和技术 QA。 自主自由创作不读guided-free-creation.md也不使用其中的逐阶段确认节点两条路线的阶段 0–3 判断顺序相同产品简报→需求决策→视觉方向→镜头映射→分镜区别只在逐级交用户确认还是Agent 自主选定并记录。一个实用的边界规则若用户在共同创作中明确说你全权决定或跳过确认直接做应切换为自主自由创作并记录该选择不要一边声称自主推进、一边继续逐阶段要求确认。2. 阶段一产品简报与安全素材预检2.1 只读检查不先写代码共同创作的第一阶段要求 Agent 先做只读检查不写视频代码、不修改业务项目、不采集或导出敏感内容。检查范围包括技术栈、入口、启动命令、页面路由、主要组件、交互状态、API、页面文案、CSS 视觉 token、外部依赖和数据风险并判断哪些功能能通过真实页面状态清楚表达。这与 pipeline.md 阶段 0在写视频代码或采集最终素材前只读检查项目的约束一致但共同创作多了一道人工闸门检查结果要先变成用户可确认的简报表。2.2 由 Agent 先填写的产品简报表输出格式是一张 11 行的简报表。关键规则是每一行都必须先给出判断或推荐再写明依据不要把所有字段原样丢给用户填写。文档给出的完整模板当前阶段产品理解 | 项目 | Agent 的判断或推荐 | 依据 | |---|---|---| | 项目定位 | | | | 目标用户 | | | | 视频用途 | | | | 核心卖点 | | | | 必须展示的功能 | | | | 可用页面/状态 | | | | 首屏主张 | | | | 期望时长/画幅/语言 | | | | 音乐/配音 | | | | 数据合规口径 | | | | 视觉线索 | | | 需要确认 1. 只列出无法从项目或用户已有描述中确定的事项。 2. 对可以推荐但仍需用户拍板的事项先写推荐方案依据再在此处提问。填写规则四条能从 README、源码、路由、页面状态、文案或 computed styles 确定的直接填写判断和证据不再询问无法完全确定但可以根据项目合理推荐的填写动态推荐、推荐依据和需要用户拍板的选项完全无法判断的明确写无法从当前材料判断只把它放到下方问题中每轮只追问 1–3 个最影响视频结果的问题不显示置信度字段推荐必须来自当前上传项目或页面不得使用固定答案。这条推荐必须来自当前项目的约束与 final-review 检查项 P4 呼应终检时会核查是否用固定的受众/用途→风格刻板映射替代了项目依据。2.3 临时安全素材预检用户确认简报后先按数据口径做一次临时安全素材预检只采集制作 styleframe 所需的少量页面截图或 token不做完整切片、全量导出或最终素材入库。数据口径规则公开演示数据只有在简报明确确认后可保留客户、个人、内部、密钥、实时或其他敏感数据必须先替换、脱敏或冻结已经明确提供的信息不要重复询问。这里临时二字有工程含义pipeline.md 阶段 4 明确写着此前为 styleframe 采过的少量安全截图只能作为方向验证不得直接替代最终素材。也就是说预检素材与最终素材是两个阶段、两套产物方向错误在 styleframe 阶段就暴露代价只是重截几张图而不是报废整套逐镜头场景。3. 阶段二需求到执行决策表确认后的简报不直接进视觉设计而是先落成一张需求到执行决策表。它的设计意图是把已确认的用户需求、项目证据和 Agent 的执行选择写成同一张可追溯表。文档特别强调它不是固定的受众→风格规则表——每行都必须写明当前项目与用户材料带来的依据并允许 Agent 提出与常见套路不同的推荐。完整表结构当前阶段从需求到制作决策 | 已确认需求 | 项目/用户依据 | 受影响的执行范围 | Agent 推荐 | 需要确认项 | |---|---|---|---|---| | 视频用途 | | 叙事结构、信息量、CTA | | | | 目标受众及其情境 | | 场景、语言、节奏、功能优先级 | | | | 核心卖点与必须展示功能 | | 页面状态、镜头、文案 | | | | 时长/画幅/语言 | | 镜头数、字幕密度、构图 | | | | 音乐/配音 | | 节奏、停顿、SFX 留白 | | | | 数据合规口径 | | 采集、mock、打码、终检 | | | | 视觉方向 | | tokens、材质、转场语气 | | |这张表的约束有三层只记录会产生实际影响的项无法确定的项保留在需要确认项每轮合计只问 1–3 个已经确认的项不得再次提问全程可追溯后续的视觉方向、镜头映射、分镜、素材采集、声音设计与终检都必须能追溯回此表并在设计 spec 中保存是终检的审查基准之一references/final-review.md 的审查输入清单中明确包含需求到执行决策表且 P 类检查项要求需求到执行决策表中的执行选择是否能在分镜、文案、页面状态、音频和素材中找到对应落地。从源码结构看这张表实际上是把用户为什么这样选与Agent 为什么这样执行焊在同一行里使得终检 Agent 不必翻聊天记录就能判定成片是否偏离已确认基准。4. 阶段三视觉方向与 styleframe4.1 从产品自身提取视觉证据视觉方向的起点不是自由发挥而是提取从页面、源码或 computed styles 提取字体、色板、圆角、信息密度、光感和动效性格。这与 SKILL.md 核心理念 2 一致——整支视频的视觉语言必须从产品自身生长不能另造一套不相干的宣传片皮肤。视觉方向分两轮确认第一轮文字方向最多 3 个。每个方向说明名称、一句话视觉主张、3–5 个关键词、字体/色彩/材质、镜头运动性格、适合原因和取舍。文档特别标注只有产品确实适合纸张、编辑部或叙事质感时才把 Ink Press 列为候选不能因为仓库里有它就固定加入。Ink Press 是 template/ 路线的默认纸墨风格写死它会污染其他产品的方向推导。第二轮styleframe 静态对比页。用户选出 1–2 个入围方向或明确授权 Agent 自选后对入围方向制作一个纯 HTML/CSS 的实际 styleframe 对比页每个方向展示 2–3 张 1920×1080 的静态关键画面例如品牌开场、核心功能、品牌收尾使用当前产品的真实页面素材或已提取的视觉 token不写 Remotion 代码、不渲染完整视频用 Playwright/Puppeteer 截出 styleframe 对比图展示并列方向的字体、色板、材质、构图、光感和信息密度。用户确认最终方向后才能进入功能到镜头映射。4.2 styleframe 的能力边界与跳过条件文档对 styleframe 的适用边界给出了明确表述Styleframe 用来确认静态视觉语言不能单独证明缓动、运镜速度或节奏这些仍需结合动效 tokens、Gallery 参考样片判断。若动效差异无法靠文字和样片判断再做短的运动测试。可跳过 styleframe 对比的情形需记录理由用户已经提供严格品牌规范、明确参考片、直接选定 Ink Press或明确授权 Agent 自选并跳过视觉确认。这个跳过理由在终检时也是审查输入之一final-review 的 V 类检查项会核对 styleframe 或跳过理由与实际视觉方向的一致性。5. 阶段四功能到镜头映射5.1 先列功能再扫卡映射阶段的操作顺序是固定的先列产品功能清单再扫描 references/shots/ 各卡 frontmatter 的用途、能量、建议时长和限制给每个必须展示的功能推荐首选和备选镜头。输出是一张四列表| 功能 | 首选镜头 | 备选镜头 | 画面要表达什么 | 需要的页面状态 | |---|---|---|---|---|配方卡的 frontmatter 结构可以从 references/shots/opening/spotlight-hero-card.md 看到实际样例name、一句话、适用、时长、能量、标签六个字段正文再分意图/动效核心/参数表/声音/已知坑/参考实现。以它为例适用写的是单一主角式产品开场把一个核心对象卡片/条目/模块立成全片主角能量写的是中质感最高的一镜节奏慢而稳时长约 4.6s82–220f——这些正是映射阶段选型时逐卡扫描的维度。用户可以接受、替换、删除或授权 Agent 自选。确定映射后必须完整读取选中卡片并按其参考实现定位准确 demo 源码。例如 spotlight-hero-card 的参考实现一节写明demos/opening/spotlight-hero-card/SpotlightHeroCard.tsx原 template/src/aifl/live/SceneOpen.tsx 82–220 段。没有合适镜头时可以新写但要说明新写范围和验证风险。两个特殊标记的处理规则Gallery 标为仅供参考需要自定义实现的样式不默认推荐用户明确点名后才允许自定义实现并把风险写进设计 spec标为缺少预览的样式可读源码用于制作但不得声称已对照动态样片。5.2 映射表不等于分镜文档在此处划了一条硬边界这张映射表不是完整分镜不得在用户确认映射后直接开始制作。它只确定哪个产品功能使用哪一种镜头语法之后还必须进入下一阶段展开镜头顺序、时长、页面状态、具体动作、素材、字幕、转场和声音。这条边界在 SKILL.md 的自主自由创作与共同创作的边界一节中有同样表述两种模式共用只有完整分镜确认/记录后才进入最终素材采集。6. 阶段五Gallery 镜头名称解析6.1 用户只需复制镜头名Gallerygallery/ 静态画廊线上版为动态样片浏览界面只是用户浏览和挑选的界面镜头定义和实现源码已经包含在本仓库。用户不需要描述动画只需复制并提供镜头名。仓库内的索引文件是 gallery/api/library.json。从实际内容看它包含generatedAt、revision、stats当前为 157 卡 / 214 style / 214 样片和cards[]数组每张卡记录name、summary、use用途、duration建议时长、energy能量、intention、source指向references/shots/分类/卡名.md、styles[]每项含key、label、description、media.url样片地址以及category。这些字段正是解析流程的校验依据。6.2 七步解析流程收到镜头名后按以下顺序处理读取 gallery/api/library.json用其中的cards[].name校验card-name用该卡的styles[].key校验style-key不要用模糊猜测代替索引校验用索引中的source定位并完整读取 references/shots/ 对应的.md卡片按卡片参考实现的明确路径把具体样式解析到准确的 demo TSX若文档只写 demo 目录读取目录文件并根据导出名、注释和样式语义确定对应文件将索引中的styles[].media.url解析为参考样片本地 gallery/media/ 若无 mp4先跑 gallery/fetch-media.sh 从 release 拉取——脚本通过gh release download gallery-media下载*.mp4到media/因为样片不进 git或直接用在线 Gallery 对应链接并在设计 spec 记录卡名、style-key、卡片文档、准确 demo TSX、参考样片如卡片需要通用组件再读取并复制 assets/lib/ 的对应文件保留 demo 中已经调校的缓动、时值配比、遮罩时机和已知坑/命门参数只替换目标产品的截图、布局坐标、文案、品牌 token 和必要的构图参数。第 6、7 两步是 SKILL.md 核心理念 6 的执行细则配方卡给的是语义和参数表准确的 demo 源码才是调校过的参数真相缓动、时值配比、摘罩时机、已知坑的规避写法。允许适配性改动但卡上已知坑/命门标注的参数不得降档——质量标准只升不降。凭卡名和理解新写放弃全部调校积累。6.3 两种复制形式与四种异常分支Gallery 可能复制出两种形式spotlight-hero-card shot-transitions · whip-pan只有卡名使用卡片默认变体如果同一卡的多个变体表达差异明显Agent 先按前后镜头和产品气质推荐一个具体变体并说明原因必要时让用户确认。例如 shot-transitions 一卡就有 flash-cut、穿暗场直航、虚焦接力、黑场字卡、whip-pan、mask-wipe 六个style-key默认变体与点名变体的画面语法完全不同卡名 · 样式名优先使用用户点名的具体变体读取对应实现不擅自换式名称不存在报告无法匹配并给出仓库中最接近的真实卡名不要凭名字臆造标为仅供参考需要自定义实现不主动推荐用户明确点名后明确说明该样式没有可复用的完整实现按配方参数和参考样片制作并把实现风险写进设计 spec标为缺少预览可读取准确源码并用于制作但不得声称已对照动态样片。文档在此收束了一条总原则严禁只根据卡名含义重新写一套近似动画。卡片文件提供语义demo 源码才是参数真相。 用户选中多个镜头后把它们与产品功能映射再继续生成完整分镜。7. 阶段六分镜确认与制作放行7.1 完整分镜表把确认的功能和镜头组合成分镜至少包含| # | 时间/帧 | 功能信息 | 镜头卡 | 主动作 | 素材来源 | 字幕/SFX |检查规则四条全部来自文档原文每镜只讲一个主要动效品牌字标 hold 至少 1 秒批量动效收尾至少静止 0.5 秒避免重复 tagline 或让同一种动效反复当主角。这些节奏参数与 SKILL.md 核心理念 4品牌字标落定 hold ≥1s、批量动效收尾留 0.5s 静止、开场主体动作给足 3s和 final-review 的 B3 检查项品牌字标 hold 是否至少 1 秒批量动效收尾是否至少静止 0.5 秒三处互相咬合形成设计期约束—检查期核对—终检期验收的闭环。7.2 制作放行与后续阶段交接用户确认分镜与最终设计 spec 后二者共同构成制作放行不重新打开此前已确认的业务或创意问题只补实现必要的未决项。放行时的两个动作最终全量素材采集整页 2x 截图、元素切片、layout.json。这一步在 pipeline.md 阶段 4 有完整操作规范——复制 assets/scripts/capture-template.mjs 进项目改BASE_URL与选择器跑一次产出三件套全页 2x 截图viewport 1920×1080、deviceScaleFactor: 2截图前document.fonts.ready 600ms settle、per-element cutout悬浮件用透明底需要卡片飞入空板的镜头额外截空 backplate、layout.json记录每个元素在整页坐标系下的{x,y,w,h}bbox 与每页pageH。查看 capture-template.mjs 源码可见 CONFIG 区把路由、选择器、hideForEmptyPlate隐藏元素后补截空底板、interact截图前页面内交互都提成了可改配置进入流水线后半段把批准分镜转成帧级时间轴再进入 references/pipeline.md 的阶段 5 逐镜头实现、阶段 6 声音设计和阶段 7 终检。pipeline.md 对此有明确约定共同创作从 guided-free-creation.md 进入本文件时不要从头重跑。该流程已经完成并确认阶段 0–3直接从阶段 4 最终素材采集继续不重新询问或重新设计。7.3 设计 spec终检的审查基准共同创作结束前要把以下八项保存为稳定的设计 spec或在终检交接时完整提供用户确认后的产品简报需求到执行决策表视觉方向/tokensstyleframe 或跳过理由功能到镜头映射Gallery 卡名与具体变体最终分镜数据合规口径。设计 spec 是 references/final-review.md 的审查基准。final-review 要求审查 Agent 处于干净上下文、不参与制作只提供成片、关键帧、简报、决策表、视觉方向/styleframe、映射、卡名与变体、demo TSX、参考样片、分镜和审美准则不要让独立审查 Agent 依赖零散聊天记录猜测用户确认过什么。审查报告要求逐条给帧号证据如F2 ✗ 第 340 帧缺少已确认的知识图谱功能且不要用没有证据的整体不错代替逐项检查。8. 默认与跳过规则用户授权 Agent 全权决定时仍须根据产品内容动态推导而不是套默认值从视觉 token 生成方向从核心功能与页面状态选择镜头从发布渠道、功能数量和阅读密度推荐时长/画幅/语言从品牌能量与节奏推荐音乐只有项目和用户描述都没有相关线索时才使用30–38 秒、1920×1080作为兜底数据口径按项目风险决定公开演示数据可沿用客户、个人或内部数据改用虚构/脱敏内容首次整片渲染前仍需提交分镜备案除非用户明确要求不看中间产物。这条规则保证了全权决定不等于闭眼执行动态推导优先兜底参数只作最后手段。9. 每轮回复格式把状态显式化共同创作的每一轮回复使用固定四段格式当前阶段 已确认 本轮需要确认 确认后交付这个格式配合每轮只问 1–3 个问题已确认项不得再次提问两条纪律把协作状态从聊天记录中抽出来变成显式字段避免确认漂移。从流程设计看它是整份文档里成本最低但收益最高的一条规范用户随时能回答我们现在停在哪、哪些已经拍板、这一轮要我决定什么、确认后你交付什么而 Agent 侧则被约束不得在已确认项上反复追问。10. 小结一条可追溯的决策链把六个阶段串起来共同创作引导流程实际是一条单向决策链只读产品检查 → 产品简报表11 项Agent 先填→ 临时安全素材预检 → 需求到执行决策表7 类需求 × 5 列追溯 → 视觉方向≤3 文字方向 → styleframe 静态对比 → 定案 → 功能到镜头映射扫 shots frontmatter → 首选/备选 → 完整读卡 → Gallery 镜头名解析library.json 校验 → 读卡 → 读 demo TSX → 记 spec → 完整分镜表7 列 设计 spec 存档 → 制作放行 → pipeline.md 阶段 4 全量采集 → 阶段 5 实现 → 阶段 6 声音 → 阶段 7 独立终检共同创作模式的工程价值不在多问了几轮而在于每个确认节点都产出结构化产物简报表、决策表、styleframe、映射表、分镜表、设计 spec使后续昂贵的逐镜头阶段Remotion 实现、渲染、终检建立在可追溯、可复核的基准之上而所有廉价的方向性争议被压在最便宜的静态确认物上解决。对照 references/pipeline.md 可以进一步阅读自主自由创作路线的完整八阶段细节对照 references/final-review.md 可以查看终检 checklist 的 P/F/V/S/B/D/A/Q 八组完整检查项。赞分享AI 技能媒体生成视频【免费下载链接】video-shotcraftAI video skill for Claude Code Codex — cinematic product videos with Remotion: 152 shot recipe cards, 209 motion previews, a production-ready template项目地址https://gitcode.com/gh_mirrors/vi/video-shotcraft点击查看免费下载相关推荐video-shotcraft 使用指南用 Remotion 镜头卡流水线制作电影感产品视频video shotcraft 使用指南用 Remotion 镜头卡流水线制作电影感产品视频 video shotcraft 是一套面向 Claude CodAI 技能媒体生成视频协作光标当演员video-shotcraft 的 dialogue-duet 与 cast-ensemble 两式镜头语法协作光标当演员video shotcraft 的 dialogue duet 与 cast ensemble 两式镜头语法 导读 本文讲解 video shoAI 技能媒体生成视频Feynman Deep Research 工作流全解析从计划确认到带引用的研究简报交付Feynman Deep Research 工作流全解析从计划确认到带引用的研究简报交付 导读 deepresearch 是 Feynman开源 AI 科研上一篇WarcraftHelper5分钟免费解锁魔兽争霸3全部限制让你的经典游戏重生下一篇WarcraftHelper魔兽争霸3终极增强插件5分钟解锁完整游戏体验创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考