你好，我是 Maneshwar，我正在构建 LiveReview——一个具备爆炸半径感知的 AI 代码审查工具，专为你的关键业务系统打造。给我们点个 Star帮助开发者发现这个项目，试用一下，并分享你的反馈来帮助改进产品。

两篇文章之前，我从未打开过 Blender。

从那以后，Miles Morales 已经荡着蛛丝，把一块 DEV 板拽进了画面，还从广告牌边缘太空步走了 6.5 米而没有人注意到。

每一个镜头都是我和 Claude Code，一次一个提示词地结对编程一个 3D 场景。

它行得通。

它也很慢，因为整部电影仍然是我一个人装在脑子里。

所以这篇文章要谈的是下一个问题，那个我凌晨 1 点还在反复琢磨的问题：

到底需要什么，才能让我打一段话，然后从另一端拿到一个做好的 YouTube 视频？

不是“Claude 在 Blender 里帮我”。

是 Claude来导演这一切。

我翻遍了我能找到的每一个 MCP 服务器、Claude Code 技能、动捕来源和音频模型，查了 GitHub 星数，好知道哪些是久经实战、哪些只是个周末项目，然后写下了我会搭建的技术栈。

剧透：Blender 大概只占三分之一。

职位描述：导演，而非动画师

我在第一部分学到的最有用的一件事，

并不是关于绑定。

而是关于 LLM 擅长什么、在哪里毫无希望。bpyClaude 很擅长写代码、重新链接损坏的贴图、在时间线上排列片段，以及在片段之间拼接根运动。

Claude 从未被要求去发明人体从跳跃落地时是什么样子。

那来自 Mixamo，而 Mixamo 来自一位穿着动捕服的真实表演者。

而这种分工就是整个架构。

LLM 是结构和代码的出色写手，是静态图像还算不错的评论者，却是生物力学的糟糕来源。

所以视频的每一部分都应该交给真正擅长它的一方：

Three columns: Claude writes the shot list, scripts, camera moves and the edit; Claude fetches body motion, sets, the character and mouth shapes; Claude orders voice, SFX, music and background props from specialist models

如果它像人一样运动，就去获取它。

如果是代码，就写出来。

如果是声音，就向一个只做声音的模型下单。

以下是应用了这条规则的完整技术栈：

flowchart TD
    ME[One paragraph from me] --> DIR[Claude Code<br/>director skill]
    DIR --> SL[Shot list<br/>YAML]
    SL --> BR[Blender bridge<br/>one MCP server]
    SL --> MO[Motion library<br/>Mixamo, CMU, Rokoko]
    SL --> AS[Assets<br/>Poly Haven, Sketchfab, image to 3D]
    SL --> AU[Audio<br/>TTS, SFX, music]
    AU --> LS[Rhubarb<br/>mouth shapes]
    MO --> BR
    AS --> BR
    LS --> BR
    BR --> BL[Blender, headless<br/>EEVEE drafts, frame sequences]
    BL --> QA{Checks pass?<br/>eyes + asserts}
    QA -->|no| DIR
    QA -->|yes| FF[FFmpeg<br/>frames + stems]
    AU --> FF
    FF --> YT[YouTube-ready MP4]

    classDef human fill:#e9ecef,stroke:#6c757d,color:#1a1a1a
    classDef brain fill:#9d8cff,stroke:#5b4bcc,color:#1a1a1a
    classDef fetch fill:#5ee6c8,stroke:#1f9c86,color:#1a1a1a
    classDef order fill:#ff9a5c,stroke:#c4602a,color:#1a1a1a
    classDef engine fill:#6ea8ff,stroke:#2f62c4,color:#1a1a1a
    classDef decision fill:#f4d35e,stroke:#b8991f,color:#1a1a1a

    class ME,YT human
    class DIR,SL brain
    class MO,AS,LS fetch
    class AU order
    class BR,BL,FF engine
    class QA decision

让我们自下而上走一遍，从那个所有人都在争论的部分开始。

第 1 层：Blender 桥接（只选一个）

这就是那个让 Claude 通过编写 Python 进入正在运行的 Blender 并按下按钮的 MCP 服务器。

现在这类东西已经很多了。

以下是我认真研究过的四个，星标数为本周数据：

桥接 它擅长什么
mcp-for-blender⭐（约 30.2k）（原名blender-mcp） 我在第 1 和第 2 部分使用的那个。代码执行、视口截图，外加内置的 Poly Haven、Sketchfab、Poly Pizza、Hyper3D Rodin、Hunyuan3D 和 Tripo
官方 Blender MCP⭐ 由 Blender Lab 出品 理解场景：解释节点设置、查找某个材质被谁使用、清理。Blender 的页面列出需要 5.1 或更新版本
carlosh7/blender-mcp⭐（8 星） 14 个类别共 248 个工具，371 次提交，479 个通过的测试，MIT
claude-blender⭐（5 星） 撤销检查点、相机自动取景、本地 TripoSR 和 Shap-E 生成

官方那个之所以官方，是因为它由 Blender 开发者构建，而且Anthropic 宣布了它今年作为 Claude 连接器。

不过读读它自己的页面，它被定位为一种理解复杂设置的方式，而不是用来批量产出影片。

它还带有我在任何 MCP 页面上见过的最诚实的警告：该服务器“会在 Blender 中执行 LLM 生成的代码，且没有任何防护措施”，Blender 建议使用虚拟机或一台不含敏感数据的机器。

顺便说一句，这适用于表格中的每一个服务器。

它们都提供某种形式的“运行这段 Python”，而那才是真正干活的工具。

这就引出了那个有 248 个工具的家伙。

这显然是大量细致的工作，有真正的测试和 CI。

但它让我意识到工具数量不是特性。

American Chopper argument meme about 248 MCP tools versus one tool that runs Python

MCP 服务器暴露的每个工具都附带一个 schema：一个名称、一段描述、一个用于其参数的 JSON 结构。

许多客户端在每一轮对话中都会把所有这些放进上下文窗口，无论你是否使用它们。

有些客户端（包括 Claude Code）可以推迟它们并按需搜索，这解决了空间问题。

但它没有解决选择问题。

A context window mostly filled by tool schemas versus one mostly free with skill descriptions, plus five near-identical tool names for moving a cube

如果有五种略有不同的方式来移动一个立方体，模型必须选择一种，而每一次选择都是一次选错的机会。

一个execute_blender_code加上一个擅长编写bpy的模型已经覆盖了全部 248 个，因为 Blender 中的每个按钮都只是bpy之上的一层薄皮。

所以我的选择很无聊：mcp-for-blender 作为唯一的桥接，通过以下方式安装claude mcp add blender uvx mcp-for-blender，而官方版本则留着用于“这个场景为什么慢”的考古。

而我要从那个 5 星仓库里偷走最好的点子，而不安装它。

在冒险编辑之前做检查点是个好主意。

在第二部分中，.blend文件变成了由脚本生成的构建产物，所以我的检查点只是git commit。

第 2 层：技能，而不是更多工具

如果工具很昂贵，你如何教 Claude 电影摄影？

用Claude Code 技能。

一个技能是.claude/skills/中的一个文件夹，里面有一个SKILL.md：一行始终可见的描述，以及一组只在任务需要时才加载的指令和脚本。

它是提示词工程的惰性导入。

blender-skills（约 143 星）是这个想法的好例子。

它把镜头运动作为技能，turntable，slow-zoom，dolly-rotate，crane-shot，perfect-loop，外加通过 Meshy 实现的图像转 3D，以及一个做 Mixamo 重定向的工具包。

它面向产品拍摄，所以我不会为了一个超级英雄短片而整体安装它。

我会复制它的形态。

我真正想要的是一个小的电影词汇库，每个词都由经过测试的代码支撑：

  • establishing_wide，push_in，pull_out，orbit，crane_up，tracking，over_the_shoulder，handheld_shake
  • rainy_night，golden_hour，villain_red，neon_street，soft_closeup_key

然后“从广角开始，跟拍他到边缘，在他念台词时缓慢推近”就不再是给模型做的创意写作练习了。

它变成了三次带数字的技能调用。

同样的想法也适用于灯光。

一个一次就对味的预设永远对味，没人需要在凌晨两点重新发现三点布光，因为 Miles 的战衣又渲染成了一团黑块。

第 3 层：动作，获取而非生成

这是大多数“AI 做了我的动画”演示崩掉的地方，也是我最有主见的一层。

不要让 LLM 给人类打关键帧。

它会产出技术上在动、但灵魂上没动的东西。

真实的动作有重心转移、过冲、落地时的一点点缓冲。

动捕免费拥有这一切，因为那是真人做的。

我会接入的来源，按投入精力排序：

Mixamo。免费，从五个标记点自动为 T 姿势角色绑定骨骼，有数千个片段。我在第一部分里一次点击一个下载了其中 78 个，我还会再来一次。

CMU 动作捕捉数据库。约 2,500 个免费片段，GitHub 上有一个BVH 镜像（约 203 星）。需要一个重定向器，第一部分构建了它，第二部分调试了它。

Rokoko。他们的 Blender 插件是免费的，并且可以做重定向。他们的免费计划包含 Rokoko Vision，单摄像头 AI 动作捕捉。最后这一点才是最令人兴奋的：Mixamo 没有的动作，我可以用网络摄像头在客厅里表演出来。

然后是控制器。

在第一部分里，我把 Miles 的臀部往下拖，结果他整个身体像幽灵一样沉进了地板，因为这套骨骼有骨头但没有 IK。

两个修复方案，取决于预算：

Mixamo Rig是一个免费的 GPL 扩展，它在 Mixamo 骨架上构建一套正规的 IK 控制绑定，并能把动画烘焙进和烘焙出这套绑定。在基于它搭建之前，先查看列表页上的版本范围。

Auto-Rig Pro是 Artell 出品的付费、专业级选项，大约 50 美元，被《Manor Lords》等已发售游戏使用，把绑定、骨架间重定向和面部绑定集中在一处。

如果我要在这套流程里花钱，就花在这里。

绑定是那种一旦出错就会悄悄毁掉之后每一个镜头的活儿。

第 4 层：面部，或者说特写问题

有件事我直到尝试构图一个特写时才意识到。

在远景镜头里，没人会看脸。

See? Nobody Cares meme about a broken face rig in a wide shot

然后镜头推近到台词，脸就成了唯一出现在屏幕上的东西。

一张按计时器开合的嘴，一眼就能看出是假的。

一个从不眨眼、或者眼睛像人体模特一样死死盯着正前方的角色，也是如此。

好消息是，大部分面部表演也可以获取，而且最重要的那一块小得令人愉快。

Rhubarb Lip Sync（约 2.6k stars）是一个命令行工具，它监听一段语音录音，并写出嘴形的时间线。

它使用九种形状，A 到 H，外加 X 表示静止，和经典卡通工作室用的小集合一样，而且你可以把脚本交给它，配合--dialogFile这样它就知道台词，而不是靠猜。

它说自己是给 2D 做的，但输出只是带时间戳的 JSON，3D 面部也完全可以照用。

有一个Blender 插件（约 228 stars），但自 2023 年以来就没再动过。

胶水代码短到让我宁愿让 Claude 来负责它：

# rhubarb -f json -d line.txt -o line.json line.wavimport bpy， json

cues = json。load（open（"line.json"））["mouthCues"]
keys = bpy。data。objects["Miles_Head"]。data。shape_keys。key_blocks
fps， start = bpy。context。scene。render.fps, 120   # line begins on frame 120
# Rhubarb's letters -> this model's shape key namesVISEME = {"A": "MBP", "B": "EE", "C": "EH", "D": "AA", "E": "OH",
          "F": "OO", "G": "FV", "H": "L", "X": "rest"}

for cue in cues:
    frame = start + round(cue["start"] * fps)
    for shape in VISEME.values():
        keys[shape].value = 1.0 if shape == VISEME[cue["value"]] else 0.0
        keys[shape].keyframe_insert("value", frame=frame)

That is the whole trick: audio in, a keyframe per mouth change out.

Blender's default Bezier interpolation eases between the keys, so the mouth glides instead of snapping.

If your model drives its mouth with face bones instead of shape keys, like the 143 bone face rig on my Miles, the same loop poses bones instead.

Blinks and eye darts are even cheaper.

A blink every two to six seconds, randomised, and a tiny eye flick toward whatever the character is reacting to, is a dozen lines of procedural keyframing, and it is the difference between a person and a wax figure.

Notice the dependency hiding here, too.

Lip sync needs the audio to exist first.

Which means the voice is not post production.

It is pre production.

Layer 5: assets, mostly fetched

Same rule again: generate only what nobody has made yet.

Poly Haven.Thousands of CC0 HDRIs, textures and models. CC0 means no attribution and no strings. mcp-for-blender searches and imports from it directly, and an HDRI alone fixes half of "this scene looks fake".

Sketchfab.Huge, and also where my Miles came from. Read every license, because they vary model to model.

Image or text to 3D, for the props nobody has made:

  • Hunyuan3D-2(~15k stars) andHunyuan3D-2.1(~4.1k stars, adds PBR materials), from Tencent, runnable locally if your GPU is braver than my 4 GB GTX 1650
  • TripoSR(~7k stars), fast single image reconstruction
  • Hosted options like Hyper3D Rodin and Tripo, already wired into mcp-for-blender

One honest caveat from someone who just learned what skin weights are.

Generated meshes are usually a dense soup of triangles.

That is fine for a mailbox in the background.

It is not fine for anything that has tobend, because rigging wants clean edge loops around elbows and knees, and a triangle soup deforms like wet cardboard.

So: generated props, sourced or hand built heroes.

第 6 层：音频是电影的一半

我认识的每个尝试做视频的工程师，都犯过和我一样的错误。

他们花三天时间调渲染设置，却一分钟都不花在声音上。

This Is Where I'd Put My Trophy meme: this is where I'd put my sound design, if I had any

在跳跃动作上加一个 whoosh 音效，一个thwip在蛛丝发射上加 thwip，落地时加一声低沉的闷响，同样的画面突然看起来成本高了十倍。

诀窍是把音频当作独立分轨来处理，而不是一条混好的音轨：

对白。 ElevenLabs用于角色配音。先生成它，因为面部需要它。

音效与环境声。 ElevenLabs 音效能把文字描述变成声音，每次生成最长 30 秒，带有用于雨声和城市嗡鸣的无缝循环模式，以及用于单次音效的 48 kHz WAV。

音乐。它有自己的模型，自己的分轨。stable-audio-tools（约 3.9k stars）是 Stability 为其音频模型开源的代码，如果你想本地控制的话。无论你选哪个，在放到变现频道之前都要检查许可证。

独立分轨正是让剪辑变得可编程的原因。

对白下面的音乐太吵？改一个数字就行。

想让音乐在有人说话时自动压低？那就是 FFmpeg 的sidechaincompress滤镜，以对白分轨为触发键。

一旦所有东西都烘焙进一个 WAV，这些就都不可能了。

第 7 层：像构建系统一样渲染，用 FFmpeg 组装

第二部分已经把场景变成了构建产物，所以这一层基本上就是“继续这么做，只是放大到电影规模”。

三条规则：

无头渲染。 blender -b没有 UI，由脚本驱动，这样一次渲染就是一条命令，而不是一个人去点击。

渲染帧序列，而不是 MP4。如果 Blender 在一个电影文件的第 1,400 帧崩溃，你就失去了整部电影。如果它在一个 PNG 序列的第 1,400 帧崩溃，你只失去一帧，然后继续。Blender 自己的文档推荐的正是这个做法。

用 360p 出草稿，最终版只出一次。第二部分的--fast模式，关掉光线追踪、运动模糊和额外采样，帧时间大约减半。所有东西都在草稿里审。

然后FFmpeg（约 64.9k stars，而且它只是一个镜像）把帧和分轨粘成视频：

# 把镜头 30 渲染成 PNG 序列（标志放在 -a 之前，Blender 按顺序读取它们）
blender -b build/sh030.blend -o //frames/sh030_#### -F PNG -s 1 -e 96 -a

# 帧 + 三条分轨 -> 一个 mp4，音乐在对白下被压低
ffmpeg -framerate 30 -i frames/sh030_%04d.png \
  -i audio/dialogue.wav -i audio/sfx.wav -i audio/music.wav \
  -filter_complex "[1:a]asplit[d][key];[3:a][key]sidechaincompress=threshold=0.05:ratio=8[m];\[d][2:a][m]amix=inputs=3:normalize=0[a]" \
  -map 0:v -map "[a]" -c:v libx264 -pix_fmt yuv420p -crf 18 -c:a aac sh030.mp4

asplit把对白复制成两份，一份用来听，另一份作为把音乐压下去的关键。

normalize=0阻止amix悄悄把一切都调低来腾出空间，这个问题用耳朵调试还挺有意思的。

-pix_fmt yuv420p之所以存在，是因为有些播放器在没有它的情况下会直接显示黑屏。

我仍然会把最终的调色和字幕放在DaVinci Resolve里做，只要是要发到我频道上的东西，但机器应该能独立产出粗剪。

第 8 层：两个审阅者，因为其中一个是盲的

让第一部分和第二部分奏效的循环，是 Claude 截一张图、看着它、然后修正它看到的问题。

这个循环很棒。

它也是太空步被交付出去的方式。

Two reviewers: Claude looking at a frame catches dark faces, wide lenses and bad framing; a 44-line script catches pops, floating feet and characters standing past the edge of a billboard

视觉模型审阅的是一张静态图片。

运动缺陷藏在帧与帧之间。

交叉淡化中间那 22 cm 的跳变、Miles 在剪辑点悬停的那一帧、比他站立的窗台还宽的站姿，这些在第 1201 帧的检查中全都过不了。

它们全都会在逐帧测量脚部位置的断言上失败。

所以每个镜头都要经过两个审阅者：

  • 眼睛：Claude 查看草稿帧的缩略图拼版，评判构图、灯光、氛围和可读性。
  • 断言：脚本测量接触、边界、剪辑点处的连续性和缺失的贴图，并大声报错。

如果断言失败，就没人会浪费时间去看。

缺失的一环：导演技能

上面说的每一项都是一个部门。

把各个部门变成一个工作室的，是一项技能：它接收我写的一段话，写出其他人据此工作的计划。

这个计划应该是数据，而不是散文：

title： rooftop_siren
fps： 30
character： original_hero_v2       # 不是 Miles，见上文
shots：
  - id： SH010
    seconds： 4
    set： rooftop_night_rain
    camera： [establishing_wide， push_in]
    motion： { clip： "StandingIdle" }
    audio： { ambience： "rainonarooftop,distanttraffic,wind" }
  - id： SH020
    seconds： 2.5
    camera： [extreme_closeup]
    motion： { clip： "LookAround"， turn： 30 }
    dialogue： { voice： hero， line： "Youhearthat?" }
    face： { lipsync： rhubarb， blinks： auto， look_at： siren }
  - id： SH030
    seconds： 3.2
    camera： [tracking， low_angle]
    motion： { clip： "JumpDown"， speed： 1.2 }
    audio： { sfx： ["clothwhoosh"， "webthwip"， "heavylandingonconcrete"] }

看看里面都有什么。

每个值都是一个技能名、一次库查询，或者给音频模型的提示词。

没有任何东西要求 LLM 凭空发明一个关节角度，也没有任何东西要求它一次性记住整部电影。

导演只写一次这个。

然后每个镜头都跑同一套循环，一个坏镜头单独重跑，而不是整部片子重来：

flowchart LR
    S[Shot from the YAML] --> A[Generate dialogue<br/>and SFX]
    A --> L[Rhubarb<br/>mouth cues]
    S --> M[Fetch motion<br/>and set]
    L --> B[Build shot<br/>bpy scripts]
    M --> B
    B --> D[360p draft]
    D --> T{Asserts pass?}
    T -->|no| B
    T -->|yes| V{Claude likes<br/>the contact sheet?}
    V -->|no, fix camera or light| B
    V -->|yes| F[Final frames]
    F --> X[FFmpeg mux]

    classDef src fill:#e9ecef,stroke:#6c757d,color:#1a1a1a
    classDef order fill:#ff9a5c,stroke:#c4602a,color:#1a1a1a
    classDef fetch fill:#5ee6c8,stroke:#1f9c86,color:#1a1a1a
    classDef build fill:#9d8cff,stroke:#5b4bcc,color:#1a1a1a
    classDef decision fill:#f4d35e,stroke:#b8991f,color:#1a1a1a
    classDef out fill:#6ea8ff,stroke:#2f62c4,color:#1a1a1a

    class S src
    class A order
    class L,M fetch
    class B,D build
    class T,V decision
    class F,X out

这是电影的 CI。

每个镜头是一个 job，YAML 是配置，断言是测试，而 Claude 是那个还顺手写修复的评审。

我构建它的顺序

不是图上的顺序，而是依赖的顺序：

  1. 桥接 + 技能。一个 MCP 服务器，一个相机和灯光技能库。没有可靠的镜头，其他一切都不重要。
  2. 动作库。Mixamo 和 CMU 藏在一个重定向器后面，Mixamo Rig 做 IK，Rokoko Vision 补上没人有的那些片段。
  3. 音频分轨。人声、音效、音乐，全部独立。这个排在之前面部之前，因为面部要读取音频。
  4. 面部。Rhubarb 胶水、程序化眨眼和眼球目标，然后特写就不再吓人了。
  5. 断言。第二部分的检查，推广到每个镜头。
  6. 导演技能。只有在每个部门都能独立运转之后。一个没有剧组的导演只会写出非常自信的 YAML。

还有一个我会诚实面对的问题：这能做出皮克斯短片吗？

不能。

它能做出的是一个月前的我根本做不出来的东西：一个 30 秒的场景，角色动起来像个人，说话时嘴型和词对得上，听起来像发生在某个地方，而且是由一台机器在我写下一段文字时组装出来的。

第三部分到此收尾。

如果你构建过这其中任何一块，尤其是面部，告诉我哪里崩了。我显然还有一大堆要崩的地方。


你的团队注意力有限，而 AI 生成代码的洪流让保持生产环境安全可靠变得更难，同时还不能拖慢你。

我正在构建LiveReview，一个感知爆炸半径的 AI 代码评审，为你的业务关键系统而打造。

它不会把每个 diff 都同等强调地呈现出来，LiveReview 按爆炸半径给每个变更打分——即它的影响通过调用图能延伸多远——这样你就能把注意力集中在真正重要的地方。

把代码评审的精力花在业务风险最高的地方——而不是均匀分摊到每个 diff 上。

⭐ 在 GitHub 上给它点星：

LiveReview

gitleaks.yml osv-scanner.yml govulncheck.yml semgrep.yml dependabot-enabled mcp-testcases.yml

LiveReview：面向业务关键系统的爆炸半径感知 AI 代码审查

LiveReview 是一款 AI 代码审查工具，它会为 diff 中的每个代码块按爆炸半径打分：即一项改动通过调用图能波及多远、触及多少持久化状态，以及测试覆盖程度如何。对共享鉴权检查的 3 行改动，其评分可能高于 300 行的 UI 调整。团队的注意力会优先投向风险最高的代码，而不是平均分散到每个 diff 上。

blast-radius-demo.mp4

LiveReview 的爆炸半径与审查优先级评分，直接在 diff 查看器中呈现。

精确的计算方式，而非黑箱 一眼看清爆炸半径 影响评分的每一个因素

爆炸半径评分是如何工作的？（更技术化的解释）

目标如下：

  • 一个被其他 40 个文件引用的函数中的 3 行修复，且还会写入数据库，应当获得高分。
  • 单个文件中 300 行的 UI 改动，且被……完全覆盖



点击下方，用你的代码库试用 LiveReview：

LiveReview Banner