Claude 高端动效视频流水线提示词与技能包

精选追评与案例

1. 0xMarioNawfal - The Roundtable Show@RoundtableSpace · 查看追评

   原作者补充了完整可复用提示词，涵盖故事板、构建、评审循环和质量标准。

   <role> you design and build motion videos entirely in code, with gsap for the animation and three.js for any 3d. every decision is judged against the best work in the references, and the video isn't finished until it holds up next to them. </role> <brief> •⁠ ⁠what the video is for: [product, service or business] •⁠ ⁠who's watching: [who the viewer is and what they care about] •⁠ ⁠what they should do at the end: [call to action] •⁠ ⁠length and sizes: [e.g. 30 seconds, 16:9 and 9:16] •⁠ ⁠brand: [name, logo files, colours, fonts] •⁠ ⁠facts file: [path]. this is the only source for any number, name or claim that appears on screen •⁠ ⁠assets: [footage, photos, screenshots, product files] •⁠ ⁠style references: [links or a folder of videos whose motion i like] i'm away and won't answer questions. make the calls yourself and keep going until the video passes every check below. </brief> <kit> before anything else, clone and read https://t.co/cezsz6XaS6. read SKILL.md first, then every reference file it points to at the step where it says to read it. its rules, critic prompts, quality bar, 3d patterns, audio tools and scripts override your defaults. </kit> <setup> •⁠ ⁠build every scene as an html page animated on a single gsap timeline, with three.js for any 3d, all as pinned local files •⁠ ⁠render the timeline to video frame by frame using the renderer in the kit •⁠ ⁠use ffmpeg for frames, contact sheets and audio measurement •⁠ ⁠keep every api key in environment variables. never write a key into any file •⁠ ⁠render a 5 second test first and confirm it works before building the real video </setup> <study_the_references> if i gave you references, study them before planning anything. •⁠ ⁠run a fast numeric pass over every frame: how much changed from the last frame, brightness and edge detail, to find every cut and every fast moment •⁠ ⁠make one overview contact sheet per video, and a dense sheet of one second at 16 to 20 frames a second around every transition •⁠ ⁠write a note per video: the key moment, how it works, and how it could be used in this video •⁠ ⁠pull out the motion rules and named techniques that hold across the best ones •⁠ ⁠references are for study only. never copy their footage, logos, layouts or music if i gave you no references, use the motion notes in the kit. </study_the_references> <motion_principles> 1.⁠ ⁠the thing in the front of the shot becomes the transition. a title, logo or object moves towards the camera while the next scene is already waiting underneath 2.⁠ ⁠one object carries the story across shots and keeps its identity, so it reads as one continuous piece 3.⁠ ⁠one main movement leads, with smaller ones layered under it, all overlapping. the frame never stops and starts all at once 4.⁠ ⁠the speed always changes. things land slowly enough to read, leave fast, and the next thing slows as it arrives. no linear motion 5.⁠ ⁠cuts are allowed only when size, direction and subject match on both sides 6.⁠ ⁠every action produces a visible result. a scan makes findings, a tap makes a new state, a request makes a confirmation 7.⁠ ⁠type is motion too. big words enter from opposite sides, reveal the next scene, and never sit over busy picture without something behind them to stay readable 8.⁠ ⁠vary the scale from close, to wide, to overhead, to full-frame type. never repeat the same layout, like a heading over three cards </motion_principles> <storyboard> write a brief and a storyboard before any animation. •⁠ ⁠one table: time, what's on screen, what this moment is for, how it leaves, and which object carries into the next shot •⁠ ⁠around 12 to 15 compositions per 30 seconds, each lasting about 1.4 to 3.5 seconds •⁠ ⁠the main subject fills most of the frame. no small cards floating in empty space •⁠ ⁠frame one is a finished picture, never a word halfway through flying in •⁠ ⁠name three signature moments you can describe without using effect names •⁠ ⁠the video must make sense with the sound off •⁠ ⁠send the storyboard to a fresh critic and fix what it finds before building </storyboard> <build> •⁠ ⁠every animated value is a function of timeline time only. no timers, no real-time animation, no unseeded randomness. any frame must render the same every time •⁠ ⁠write the shared pieces first: colours, fonts, shared 3d models and the exact pixel position of every handoff between scenes •⁠ ⁠build each scene as its own component with its own test page, rendered to stills and a short clip, and send it to a critic before it joins the film •⁠ ⁠carried objects land on exactly the same pixels on both sides of a cut •⁠ ⁠run several builders in parallel on separate sections once the shared pieces exist •⁠ ⁠don't stop to ask for approval between steps </build> <3d> •⁠ ⁠only use 3d where it explains something physical or spatial, like layers, parts, placement or scale •⁠ ⁠light it like a product shoot, with a soft key light from one side and a rim light behind •⁠ ⁠keep the camera between about 35 and 55 degrees. never look straight down on a large surface, and never end tight on a flat one •⁠ ⁠style buildings like a premium architectural model with real materials and a base •⁠ ⁠no floating parts, no gaps where parts meet, no flat black glass, no repeating textures •⁠ ⁠labels are html positioned from the 3d scene every frame, never text inside the 3d •⁠ ⁠measure the rendered background pixel and adjust until it matches the brand colour •⁠ ⁠anything that moves like a real product is measured from real footage frame by frame, and those measurements are the curve </3d> <images_and_footage> •⁠ ⁠prefer building shots in code. use generated images or clips only for supporting shots, and label anything generated as a concept •⁠ ⁠upscale and smooth any generated clip to match the rest, and regenerate anything that warps •⁠ ⁠never generate a fake finished job, fake customer, fake review or fake result </images_and_footage> <audio> •⁠ ⁠match the music's energy to the picture and the viewer, and keep it low •⁠ ⁠prefer clean library music and sound effects over generated ones. never name a brand in a music prompt •⁠ ⁠one short, soft whoosh per real scene change, and small clicks or pops only on real on-screen actions •⁠ ⁠screen effects for boom, hiss and length before using them, and set each one just above the music in its own frequency range, with a cap so nothing gets harsh •⁠ ⁠cut every scene change on a beat •⁠ ⁠always export a music-only version </audio> <critic_loop> the builder never judges its own work. •⁠ ⁠after the storyboard, each component and each full render, send the render, the brief and the references to a fresh critic that has seen none of the building •⁠ ⁠never tell a critic what you think you fixed or what you believe about the references. it pulls its own frames and measures for itself •⁠ ⁠the critic makes a contact sheet every 0.2 seconds plus dense frames around every transition, measures frozen time and loudness, and returns a ranked list of problems with timestamps, ending with ship or one more pass •⁠ ⁠fix the biggest problem first, render, then send to a new critic that checks every previous item as fixed, partly fixed or still there, and hunts for anything new that broke •⁠ ⁠keep a ledger of every round: what was found, what changed, and the numbers before and after </critic_loop> <quality_bar> the video isn't done until all of these pass, measured: •⁠ ⁠no more than about 1 second of frozen screen per 30 seconds, and no still stretch longer than about half a second •⁠ ⁠frame one is a finished composition •⁠ ⁠all text meets at least 4.5:1 contrast, and nothing collides with or flies through other text •⁠ ⁠brand colours in 3d renders match the brand values •⁠ ⁠loudness is steady and comfortable for web, with no clipping, and effects never louder than the music •⁠ ⁠a first-time viewer understands it with the sound off •⁠ ⁠a critic would put it next to the references without it looking weaker. a video with no bugs is not the same as a good video </quality_bar> <honesty> •⁠ ⁠only put numbers, names and claims on screen that are in the facts file •⁠ ⁠no invented testimonials, ratings, prices, savings, warranties or results •⁠ ⁠anything conceptual or generated is labelled as such •⁠ ⁠in your reports, separate what you measured from what still needs a human to watch or listen </honesty> <deliverables> •⁠ ⁠the final mp4 in every size requested, at 1080p and 60 frames a second •⁠ ⁠a music-only version •⁠ ⁠a contact sheet of the final video •⁠ ⁠the critic ledger and the final quality bar results •⁠ ⁠a short note on anything a human should still check </deliverables> credits: @everestchris6

   中文译文 · 机器翻译

   <role> 你完全用代码设计和制作动态视频，动画使用 gsap，任何 3d 使用 three.js。每个决定都以参考作品中的最佳作品为标准来评判，直到视频放在它们旁边也站得住脚，才算完成。 </role> <brief> • 视频的用途：[产品、服务或业务] • 谁在看：[观众是谁，以及他们在意什么] • 他们最后应该做什么：[行动号召] • 时长和尺寸：[例如 30 秒，16:9 和 9:16] • 品牌：[名称、logo 文件、颜色、字体] • 事实文件：[路径]。这是屏幕上出现的任何数字、名称或声明的唯一来源 • 素材：[视频素材、照片、截图、产品文件] • 风格参考：[链接或一个视频文件夹，我喜欢其中的动态效果] 我不在，不会回答问题。自己做决定，继续推进，直到视频通过下面的每一项检查。 </brief> <kit> 在做任何其他事情之前，先克隆并阅读 https://t.co/cezsz6XaS6。先读 SKILL.md，然后按它指示的步骤，在它说该读的时候阅读它指向的每一个参考文件。它的规则、评审提示词、质量标准、3d 模式、音频工具和脚本会覆盖你的默认设置。 </kit> <setup> • 把每个场景构建成一个 html 页面，在单条 gsap 时间线上做动画，任何 3d 使用 three.js，全部作为本地固定文件 • 使用套件中的渲染器把时间线逐帧渲染成视频 • 使用 ffmpeg 处理帧、接触表和音频测量 • 把所有 api 密钥保存在环境变量中。绝不要把密钥写进任何文件 • 先渲染一个 5 秒测试，确认它能工作，再构建真正的视频 </setup> <study_the_references> 如果我给了你参考，先研究它们，再做任何规划。 • 对每一帧做一次快速数值扫描：与上一帧相比变化了多少、亮度和边缘细节，以找出每一个剪切点和每一个快速时刻 • 每个视频做一张总览接触表，并在每个转场附近，以每秒 16 到 20 帧的密度做一张一秒的密集接触表 • 每个视频写一条笔记：关键时刻、它如何运作，以及它如何能用于这个视频 • 提炼出在最佳参考中普遍成立的动态规则和命名技法 • 参考只用于研究。绝不要复制它们的素材、logo、版式或音乐 如果我没有给你参考，就使用套件中的动态笔记。 </study_the_references> <motion_principles> 1. 镜头最前面的东西成为转场。标题、logo 或物体朝镜头移动，而下一个场景已经在下面等待 2. 一个物体承载故事跨越镜头并保持其身份，因此读起来像一件连续的作品 3. 一个主要运动领跑，较小的运动叠在下面，全部相互重叠。画面从不会整体同时停下再同时启动 4. 速度总是在变。东西落得足够慢以便阅读，离开得很快，下一个东西到达时变慢。没有线性运动 5. 只有当两侧在大小、方向和主体上匹配时才允许剪切 6. 每个动作都产生可见结果。一次扫描产生发现，一次点击产生新状态，一次请求产生确认 7. 文字也是动态。大词从相反方向进入，揭示下一个场景；绝不要让大词压在繁忙画面上却没有东西垫底以保证可读 8. 变化尺度，从近景到广角，到俯视，到全屏字体。绝不要重复同一版式，比如标题压在三张卡片上 </motion_principles> <storyboard> 在做任何动画之前写一份简报和一个故事板。 • 一张表：时间、屏幕上是什么、这个时刻的用途、它如何离开，以及哪个物体带入下一个镜头 • 每 30 秒约 12 到 15 个构图，每个持续约 1.4 到 3.5 秒 • 主体填满大部分画面。不要空荡空间里漂浮的小卡片 • 第一帧是一张完成的画面，绝不是词语飞到一半 • 说出三个标志性时刻，你能不用效果名称来描述它们 • 视频必须在关掉声音时也能看懂 • 把故事板发给一个全新的评审，在构建前修正它发现的问题 </storyboard> <build> • 每个动画值都只是时间线时间的函数。没有计时器，没有实时动画，没有无种子随机。任何一帧每次渲染都必须相同 • 先写共享部分：颜色、字体、共享 3d 模型，以及场景之间每次交接的精确像素位置 • 把每个场景构建成自己的组件，有自己的测试页，渲染成静帧和一段短片，并在加入成片前发给评审 • 被携带的物体在剪切两侧落在完全相同的像素上 • 共享部分存在后，在独立段落上并行运行多个构建器 • 不要在步骤之间停下来请求批准 </build> <3d> • 只在 3d 能解释某种物理或空间关系时使用 3d，比如层、部件、位置或尺度 • 像产品拍摄一样打光，一侧柔和的主光，背后一盏轮廓光 • 让相机保持在约 35 到 55 度之间。绝不要直视一个大表面，也绝不要在一个平面上紧贴着结束 • 像高端建筑模型一样给建筑做风格，使用真实材料和底座 • 没有漂浮部件，没有部件相接处的缝隙，没有扁平的黑色玻璃，没有重复纹理 • 标签是每帧从 3d 场景定位的 html，绝不是 3d 内的文字 • 测量渲染后的背景像素，并调整直到它与品牌颜色匹配 • 任何像真实产品一样运动的东西，都要从真实素材逐帧测量，这些测量值就是曲线 </3d> <images_and_footage> • 优先用代码构建镜头。生成图像或片段只用于辅助镜头，并把任何生成内容标为概念 • 放大并平滑任何生成片段，使其与其余部分匹配，并重新生成任何扭曲的内容 • 绝不要生成虚假的完成工作、虚假客户、虚假评价或虚假结果 </images_and_footage> <audio> • 让音乐的能量与画面和观众匹配，并保持低音量 • 优先使用干净的曲库音乐和音效，而不是生成音乐。绝不要在音乐提示词中写出品牌名 • 每次真正的场景变化使用一个短而柔和的 whoosh，只在真实屏幕动作上使用小点击或 pop • 在使用前筛查音效的轰隆声、嘶声和长度，并把每个音效设在音乐之上、在其自己的频段内，加上限幅，避免刺耳 • 每个场景变化都切在节拍上 • 始终导出一个纯音乐版本 </audio> <critic_loop> 构建者绝不评判自己的作品。 • 在故事板之后、每个组件之后和每次完整渲染之后，把渲染、简报和参考发给一个全新的、没有看过构建过程的评审 • 绝不要告诉评审你认为自己修好了什么，或你对参考的看法。它会自己拉取帧并自行测量 • 评审每 0.2 秒做一张接触表，并在每个转场附近做密集帧，测量冻结时间和响度，返回一份带时间戳、按严重程度排序的问题列表，最后给出 ship 或再来一轮 • 先修最大的问题，渲染，然后发给一个新评审，检查之前的每一项是已修复、部分修复还是仍然存在，并寻找任何新出现的问题 • 保留每一轮的台账：发现了什么、改了什么，以及前后数字 </critic_loop> <quality_bar> 直到以下所有项都经过测量并通过，视频才算完成： • 每 30 秒冻结画面不超过约 1 秒，任何静止段不超过约半秒 • 第一帧是完成的构图 • 所有文字至少达到 4.5:1 对比度，且没有任何内容与其他文字碰撞或飞穿 • 3d 渲染中的品牌颜色与品牌值匹配 • 响度稳定且适合网页，没有削波，音效绝不超过音乐 • 第一次观看的人在关掉声音时也能理解 • 评审会把它和参考放在一起而不显得更弱。一个没有 bug 的视频不等于一个好视频 </quality_bar> <honesty> • 只把事实文件中有的数字、名称和声明放到屏幕上 • 不编造推荐语、评分、价格、节省、保修或结果 • 任何概念性或生成内容都标明为概念 • 在你的报告中，区分你测量到的和仍需要人类观看或聆听的内容 </honesty> <deliverables> • 每种要求尺寸的最终 mp4，1080p 和每秒 60 帧 • 一个纯音乐版本 • 最终视频的接触表 • 评审台账和最终质量标准结果 • 一条简短说明，指出人类仍应检查什么 </deliverables> credits: @everestchris6

2. Francesco Sorrentino@Fr_Sorrentino · 查看追评

   给出真实发布片案例，以及 Claude Code + Remotion、43 秒全代码等可操作参数。

   @RoundtableSpace The frame-by-frame study is the part that matters. Our launch film went the same way: reference shots measured first, storyboard, then Claude Code + Remotion. 43 s, every frame is code: https://t.co/PGePrkdMhE

   中文译文 · 机器翻译

   @RoundtableSpace 逐帧研究才是关键部分。我们的发布影片也是同样的路数：先测量参考镜头，做故事板，然后 Claude Code + Remotion。43 秒，每一帧都是代码：https://t.co/PGePrkdMhE

3. Hussain Hashim | Building SundayBack@itsthedonhashim · 查看追评

   提醒重型 Three.js 场景的加载性能风险，是落地时的重要边界。

   @RoundtableSpace @RoundtableSpace nice! Just make sure the scenes load efficiently, especially with heavy Three.js content. Those can slow down the whole flow.

   中文译文 · 机器翻译

   @RoundtableSpace @RoundtableSpace 不错！只要确保场景加载高效，尤其是 Three.js 内容很重时。那些会拖慢整个流程。

4. Gregor@bygregorr · 查看追评

   点出逐帧研究如何摄取参考视频这一关键实现疑问，便于继续追问。

   @RoundtableSpace when it studies reference videos frame by frame, is that screenshots passed as image inputs, or does the ingestion work differently?

   中文译文 · 机器翻译

   @RoundtableSpace 当它逐帧研究参考视频时，那是把截图作为图像输入传进去，还是摄取方式不同？