很多人一听“用AI做3D动画”第一反应是让ChatGPT写几句Python丢进Blender跑通一个demo就算完事。但真把手头项目从零到一跑下来你会发现难点根本不在“生成代码”而在于整套链路稳不稳定模型能不能准确理解Blender的API场景状态怎么传给模型生成出来的脚本是能用还是要返工本地显存到底撑不撑得住。这次我拿Strata本地跑qwen 3.8再接进Blender实际做动画跑了大概一周把过程、数据、翻车现场全部记录下来给想做同类事情的人一个相对完整的参考。这套组合适合谁独立动画师、自媒体创作者、技术美术以及所有想把手动操作“外包”给本地AI但又不想交云API费用的团队。整篇会从工具选型、模型能力实测、接入方案、动画拆解、故障排除五个方向来讲最后补一段我自己的取舍心得。1. 为什么这组合值得测本地小模型控制Blender的真正价值先说一个很多人没意识到的问题Blender的Python脚本能做的事情远比大多数人想象中多。建模、材质、关键帧、物理模拟、渲染农场批处理全都可以脚本化。但过去脚本化的门槛卡在“你得会写Python、还得会查API文档”这在普通动画师眼里几乎等于要再学一门编程。现在有了本地大模型理论上只要你会说人话它就能把自然语言翻译成bpy脚本。问题在于这个翻译质量在不同模型、不同接入方式下差别极大。我之所以选Strata而不是直接用云端API有几个非常现实的原因。第一是资产安全。动画项目在未发布前都是机密场景里的角色模型、镜头布局、资产命名都是团队心血。走云端API等于把场景描述、对象命名、甚至贴图路径全部送到外部服务器很多团队接受不了。本地模型所有请求都在本机完成数据不出门对工作室来说是硬性要求。第二是成本结构。云端API按token计费一个复杂场景的序列化JSON动辄几千token做多轮调试对话时烧钱速度很快。本地模型跑起来只费电不像云端每调一次都从口袋里掏钱。对一个需要反复试错驱动的流程来说本地小模型反而更划算。第三是可控性。本地模型的系统提示词、采样参数、上下文窗口全在自己手里。出问题时能精确复现能回滚能换量化版本重测这在实际工程里极其重要。云端模型今天更新明天废弃你的工作流可能一夜之间就变味。选“qwen 3.8”这个档位的本地模型也不是拍脑袋。测试前我特意对比过同级小模型代码能力qwen系列在“Python API调用类”任务上一直不弱而且3.8这个量级意味着量化后权重大约3.6GB普通入门级显卡能跑得动显存不够还可以往CPU方向退。小型模型的好处是速度快、部署简单、日常演示不心疼坏处是代码能力和复杂指令遵循度会比大模型弱一截。这次测试就是冲着“小模型到底能不能顶住Blender动画这种中等复杂度任务”去的。2. Strata跑qwen 3.8的硬指标显存、速度与代码准确率先把Strata跑qwen 3.8的实测数据放上来。我的测试环境是中等配置的消费级主机操作系统Windows显卡显存10GB左右内存32GB模型权重放在本地磁盘推理在Strata里完成。以下数据全部为多次测试取中位值实际数值会根据硬件有所不同。指标实测结果备注模型载入显存占用约4.1GB权重3.6GB 上下文预留10GB显存完全没问题生成长度512token耗时约7秒折合每秒钟70到80个token日常使用感受不到明显等待代码生成成功率一阶段76%二阶段88%详见下文分级测试上下文窗口32K一个中等复杂场景的JSON序列化约3K到5K token窗口足够单次请求最大输出2048 token足够生成中等长度的Blender脚本模型文件大小约3.8GB所以标题叫“qwen 3.8”实际上是量化后的体积跑题说一下“3.8”这个数字。qwen本身不叫3.8模型档位是4B上下这里说的3.8是量化后的占盘体积。很多玩家在本地部署时习惯用权重体积指代模型你看到别人说“我跑的是3.8”通常就是这一档位。量化级别我选的是Q4_K_M平衡速度和精度如果显存足够可以上Q8代码准确率会有一定提升但推理速度会下降约15%。上下文窗口这块要给个正面的评价Blender场景状态用JSON序列化一个包含几十个对象的场景大概在3K到5K token之间而qwen 3.8的32K窗口足够把场景信息反复传给模型进行多轮修改。我还试过极端情况把场景里的材质纹理路径、修改器参数、约束目标全部塞进去总计8K多token模型仍然能理解我在说什么只是生成代码的延迟明显变高。硬指标只是基础真正重要的是代码准确率。我给模型设计了20条Blender操作指令从“创建物体”到“设置关键帧动画”再到“批量修改多个物体的材质”跑出来的结果分成三类一次运行成功、需要微调一次后成功、需要人工大改。一阶段场景里只有一个物体成功率76%二阶段场景里有多个物体并且有父子关系成功率88%三阶段涉及时间轴、曲线、约束成功率只有40%。这个数据说明一个核心事实qwen 3.8能处理基础操作但一旦指令需要跨多个对象、多帧时间轴协同代码准确率会急剧下降。这个结论直接影响后续所有接入方案的选择。模型不行的地方就要靠工程手段去补把复杂任务拆成简单任务多轮对话逐步生成而不是期望它一个prompt全部搞定。3. 接入Blender的两种方案脚本直连与MCP场景反馈跑到这一步我已经确认qwen 3.8的代码能力足以支撑基础动画制作。接下来的核心问题变成了“怎么把模型接进Blender”。实测下来有两种可行方案各有优劣我按实现难度从低到高依次说。3.1 方案ABlender内置脚本直连Strata的兼容APIStrata本地服务会暴露一个OpenAI兼容接口只需要一个HTTP请求就能让模型返回代码。Blender内置的Python自带urllib库不需要额外安装任何包写一个面板或者直接在Scripting工作区跑脚本就行。整体思路分三步把当前场景的关键信息序列化成JSON结构对象名称、类型、位置、旋转、缩放、父子关系、材质名称。把这些JSON填进系统提示词让模型生成“针对这个场景的bpy Python代码”。拿到模型返回的代码后在Blender里执行。系统提示词怎么写是整个方案成败的关键。我经过大量测试最终稳定下来的版本是这样的role_prompt ( 你是一个Blender Python脚本专家。用户会给你场景信息和一个操作需求。\n 你只输出Python代码不要输出解释不要用markdown。\n 只允许使用bpy模块不要使用其他第三方Python库。\n 代码必须保存缩进和引号格式正确。\n 如果需要在动画时间轴上设置关键帧必须显式使用bpy.context.scene.frame_set。\n 代码开头必须使用bpy.ops.object.select_all(actionDESELECT)清理选中状态。\n )这个提示词为什么这么写我逐个解释。“只输出代码不要解释”能防止模型把思考过程混进可执行区块。模型有时候会在代码前后加“python”标记或者“以下是代码”之类的话直接执行必炸提示词里先堵死这条路。“只允许bpy模块”是硬性约束避免模型顺手用os、sys、requests之类与场景无关的库。上次看到模型生成一个os.listdir去扫描磁盘目录完全偏离目标而且存在安全风险。“显式使用frame_set”是为了防止关键帧全部落在同一帧。qwen很爱把场景对象的location设置完之后直接插keyframe却忘了切换当前帧结果所有关键帧都记录在第0帧动画自然动不起来。exec是直接执行模型返回的代码存在一定风险所以我的处理方式是“先预览再强制确认后执行”。模型返回代码后打印到Blender的控制台我肉眼快速扫一遍确认没有删除用户资产、没有导入外部数据之类的危险操作再回车确认执行。自动化程度低了一些但稳妥得多。直接连API适合的场景是“单次操作生成”比如让AI把选中物体随机排布、给一组物体统一添加修改器、批量改材质。对轻量任务响应极快实测一次请求到执行完平均在10秒左右。3.2 方案BMCP方式让模型“看得见”场景方案A有一个明显缺点模型每接收一条指令就要把整个场景的JSON塞进提示词。场景简单还好一旦对象破百、材质和修改器多起来每次请求都堆几千token不说模型还容易眼花缭乱生成一些文不对题的代码。MCPModel Context Protocol解决的就是这个问题。MCP的思路是把场景信息拆成一组“工具”由模型按需调用。模型想知道场景里有哪些对象就调用list_scene_objects想知道某个物体的位置就调用get_object_properties。不需要每次都把全量场景塞给它。我在Blender侧启用了一个轻量MCP服务插件暴露了这些工具mcp.tool() def list_scene_objects() - list[dict]: 返回场景中所有对象的名称和类型。 result [] for obj in bpy.data.objects: result.append({ name: obj.name, type: obj.type, parent: obj.parent.name if obj.parent else None, }) return result mcp.tool() def get_object_properties(obj_name: str) - dict: 返回指定对象的位置、旋转、缩放、材质列表。 obj bpy.data.objects.get(obj_name) if not obj: return {error: object not found} return { location: list(obj.location), rotation_euler: list(obj.rotation_euler), scale: list(obj.scale), materials: [m.name for m in obj.data.materials], } mcp.tool() def set_object_location(obj_name: str, x: float, y: float, z: float) - str: 设置对象的位置并自动设置关键帧。 obj bpy.data.objects.get(obj_name) if not obj: return error: object not found obj.location.x x obj.location.y y obj.location.z z obj.keyframe_insert(data_pathlocation) return fok: {obj_name} moved to ({x}, {y}, {z})Strata作为MCP客户端连上这个Blender服务端模型就能在一个“所见即所得”的环境里工作。相比方案A它的主要优势是提示词极大瘦身。模型不用从一坨JSON里找对象而是直接调用工具精确查询。多轮调试更稳定。模型改完A物体的位置如果想接着改B物体的旋转它只需要再调一次工具上下文不会被无意义信息撑爆。工具约束天然屏蔽瞎写API。模型想要改位置只有调用set_object_location这一条路不会自己瞎编一个不存在的bpy函数。方案B的代价是搭建成本高了不少。我没用现成的运行时直接在Blender插件中心写了一个百来行的MCP服务端。好在协议本身不复杂网上现成模板也多照着抄再改工具函数就行。实测下来在复杂场景上方案B的稳定性明显优于方案A。同样是“把所有球体沿Z轴向上移动并生成动画”方案A在对象超过30个时经常出现对象名引用错误方案B几乎每次都是对的。4. 从“生成代码”到“做出动画”的完整实测链路接入完成后我在Blender里搭了一个空场景开始分三档测试。每一档都是真实的制作场景模拟不是那种“Hello World”级别的例子。4.1 基础阶段让AI在空场景里摆东西第一步测试最简单让模型生成代码往场景里添加一个圆柱体改名为“Pillar”把位置移动到原点以外的地方缩放到原来的1.5倍然后围绕Z轴旋转45度。import bpy import math bpy.ops.object.select_all(actionDESELECT) bpy.ops.mesh.primitive_cylinder_add( radius0.5, depth2, location(1, 2, 0) ) obj bpy.context.active_object obj.name Pillar obj.scale (1.5, 1.5, 1.5) obj.rotation_euler (0, 0, math.radians(45))这代码是一次成功的。模型没有漏掉任何步骤全部按预期执行。耗时大约4秒。紧接着我加复杂度添加三个不同的球体分别用不同材质球间距错开。三条指令里有两条一次通过第三条把材质分配写了两次虽然结果没错但代码显得很啰嗦。整体来说基础创建任务是qwen 3.8最擅长的部分。4.2 进阶阶段关键帧、曲线运动与材质动画制作必然涉及时间轴操作。我要模型让一个球体从第0帧到第60帧沿着圆形路径运动一圈同时把材质从红色渐变为蓝色。这是典型的程序化动画任务在传统工作流里要写不少bpy代码。qwen 3.8给出的代码结构很有意思它没有选择用圆曲线的约束方式而是选择用每帧设置位置并插入关键帧的方式import bpy import math bpy.ops.object.select_all(actionDESELECT) bpy.ops.mesh.primitive_uv_sphere_add(location(0, 0, 0)) sphere bpy.context.active_object sphere.name GlowBall # 创建材质 mat bpy.data.materials.new(nameGlowMat) mat.use_nodes True bsdf mat.node_tree.nodes[Principled BSDF] bsdf.inputs[0].default_value (1, 0, 1, 1) # 初始粉色 sphere.data.materials.append(mat) # 关键帧沿圆路径移动 for frame in range(0, 61): bpy.context.scene.frame_set(frame) angle 2 * math.pi * frame / 60 sphere.location (3 * math.cos(angle), 3 * math.sin(angle), 0) sphere.keyframe_insert(data_pathlocation) # 从粉色渐变为青色 t frame / 60 color (1 - t, 0, 1 - t t, 1) bsdf.inputs[0].default_value color # 设置时间轴范围 start bpy.data.scenes[0] start.frame_start 0 start.frame_end 60这代码通过了初步实测动画确实跑起来。视觉效果上球体会沿着半径为3的圆滑行一圈同时材质从粉色逐步过渡到青色。不过我注意到一个细节它每次给材质颜色插值都没有调用keyframe_insert导致材质颜色的关键帧没有真正记进时间轴。唯一的变通是每帧设置颜色并把颜色更新留在场景图上渲染时颜色会跟着帧号变BGE模式或实时预览能看见但关掉视图再回来颜色就重置了。这个问题非常典型是模型对“属性值修改”和“关键帧记录”两个概念理解不深造成的。另外还有一个更隐蔽的问题它把角度计算放在frame_set之后也就是说第0帧的角度是0度位置在(3, 0, 0)实际动画会从画面右侧起始而不是中心。你要的是一个围绕原点的圆这个写法没问题但如果你的预期是“球从原点出发沿圆走一圈”那起始点就不对了。这类语义歧义模型自身无法识别只能靠人工定义清楚。4.3 失败验证AI写错代码时的表现看一个模型翻车的经典案例。我要求它“选择场景中所有空物体并把它们沿X轴方向排列成间距2的直线”。场景里有五个空物体名字分别是EmptyA到EmptyE。模型给出的代码是import bpy bpy.ops.object.select_all(actionDESELECT) for i, obj in enumerate(bpy.data.objects): if obj.type EMPTY: obj.select_set(True) bpy.ops.object.delete()这代码完全做反了。它把空物体全删了而不是排列。事后分析prompt问题出在对“排列”一词的理解上。模型把“空物体”和“场景里除了空物体之外的东西”搞混又看到一个“选择”就顺手向删除的方向发挥。这类语义漂移在小模型中非常常见越是复合指令越容易触发。处理办法是先给模型少量“示范对话”。我在系统提示词末尾加上了一条示例给定两个对象A和B把A放在B右方2单位处对应的正确代码是什么。加了示例后同类指令的成功率明显提升说明这个档位的模型仍然很依赖“模仿式生成”。5. 实测中的翻车现场与参数微调经验这一周的测试攒了不少翻车记录挑几个最有代表性的写出来。如果你也在做类似的事大概率会碰上同样的坑。第一是引用不存在的对象。模型生成代码时常把对象名写成大写、加空格或者随意加后缀导致执行到一半报错“object not found”。解决办法是在系统提示词里强制加一条“对象名称必须从场景JSON中准确复制不要修改大小写或添加前缀后缀”。第二是关键帧全部落在第0帧。前面已经提到过模型不重视时间轴切换需要显式提示“在设置每一帧的关键帧前调用bpy.context.scene.frame_set”。加了这条以后关键帧错误率从60%降到20%左右。第三是API记忆错误。qwen 3.8在生成的脚本中出现了不存在的bpy函数比如“bpy.ops.object.move()”或者是“bpy.context.scene.objects.active”后者在旧版Blender里存在但在新版里已经移除。这种情况没法靠提示词完全解决只能靠执行前的语法检查兜底。我在执行前加了一个轻量检查器用AST模块解析模型返回的代码解析失败就直接拒绝执行从源头挡住语法错误。第四是上下文污染。多轮对话时如果模型之前生成过错误代码后续每一轮都会延续这个错误。解决办法是做“上下文隔离”每当一次操作完成就清空历史只保留系统提示词和最新一条用户指令。这样虽然牺牲了连续对话能力但换来了输出稳定性对“代码生成”这个任务来说非常值得。参数调优方面我给Strata里的qwen 3.8设置了这样一组数值参数设定值为什么这样设temperature0.2降低随机性防止模型自由发挥写出奇奇怪怪的代码top_p0.1进一步压缩采样空间让输出更贴近训练分布max_tokens1024预留长度给复杂脚本但避免模型写超长废话frequency_penalty0代码任务里重复函数名是正常的惩罚反而有害presence_penalty0和上面同理temperature是最关键的一个参数。初始测试的时候它在默认的0.7模型输出很有“创意”代码里甚至有注释和解释性文字但可执行率和正确率都低。调到0.2之后输出稳定了很多代价是偶尔会显得“死板”——比如坚持使用同一个代码模板去套不同场景。在代码生成任务里“死板”恰恰是安全性来源。6. 关于这套工作流的个人体会与后续扩展跑完整个测试我的结论是Strata跑qwen 3.8接入Blender这套工作流已经具备日常生产力但前提是你必须理解它的边界。它适合解决“已知对象的批处理操作”和“中等复杂度单目标动画生成”不适合一刀切处理需要全局理解的复杂场景。实际操作中的几点体会别指望着它能完全替代动画师。模型擅长的是把一句话翻译成脚本但“这句话本身该怎么表达”还是人的事。每次想让AI生成代码心里得有预期结果否则模型也不会帮你创造。场景信息预处理极其重要。我在调用模型之前先写了一个脚本把场景里的对象按类型整理成表格过滤掉相机和灯光只保留需要操作的目标模型准确率直接提升了一截。饲料干净了输出自然干净。量化级别与精度的取舍要端平。Q4_K_M在日常任务中足够但如果你要“批量生成几十个物体的复杂约束”建议换Q8。实测Q8在关键帧生成场景的错误率低于Q4约12%代价是每个请求慢2到3秒。显存宽裕就别省这个精度。后续扩展方向很多。我已经在尝试把常用的动画操作封装成MCP工具实现从“让AI写代码”升级到“让AI调用工具的代码”比如把“沿路径运动”封装成set_camera_follow_path模型只需要给出参数。这种思路能让小模型绕过不熟悉的API细节只负责决策和参数生成稳定性会好几个档次。如果你真想搭一套本地AI动画工作流我建议从方案A开始跑通再逐步过渡到方案B。初期不要追求全自动化先让AI帮你把重复的、可量化的动画操作跑起来把真正需要艺术感受的部分留在自己手里。这套组合可能不会让你一夜之间变成动画大师但它绝对会把你从“每天都得调同样的bpy参数”的枯燥中解放出来。 
长河君 · 2026/10/17 14:01:51 · 阅读 1.2k 本地小模型接入Blender：qwen 3.8驱动动画实测与避坑指南
很多人一听“用AI做3D动画”第一反应是让ChatGPT写几句Python丢进Blender跑通一个demo就算完事。但真把手头项目从零到一跑下来你会发现难点根本不在“生成代码”而在于整套链路稳不稳定模型能不能准确理解Blender的API场景状态怎么传给模型生成出来的脚本是能用还是要返工本地显存到底撑不撑得住。这次我拿Strata本地跑qwen 3.8再接进Blender实际做动画跑了大概一周把过程、数据、翻车现场全部记录下来给想做同类事情的人一个相对完整的参考。这套组合适合谁独立动画师、自媒体创作者、技术美术以及所有想把手动操作“外包”给本地AI但又不想交云API费用的团队。整篇会从工具选型、模型能力实测、接入方案、动画拆解、故障排除五个方向来讲最后补一段我自己的取舍心得。1. 为什么这组合值得测本地小模型控制Blender的真正价值先说一个很多人没意识到的问题Blender的Python脚本能做的事情远比大多数人想象中多。建模、材质、关键帧、物理模拟、渲染农场批处理全都可以脚本化。但过去脚本化的门槛卡在“你得会写Python、还得会查API文档”这在普通动画师眼里几乎等于要再学一门编程。现在有了本地大模型理论上只要你会说人话它就能把自然语言翻译成bpy脚本。问题在于这个翻译质量在不同模型、不同接入方式下差别极大。我之所以选Strata而不是直接用云端API有几个非常现实的原因。第一是资产安全。动画项目在未发布前都是机密场景里的角色模型、镜头布局、资产命名都是团队心血。走云端API等于把场景描述、对象命名、甚至贴图路径全部送到外部服务器很多团队接受不了。本地模型所有请求都在本机完成数据不出门对工作室来说是硬性要求。第二是成本结构。云端API按token计费一个复杂场景的序列化JSON动辄几千token做多轮调试对话时烧钱速度很快。本地模型跑起来只费电不像云端每调一次都从口袋里掏钱。对一个需要反复试错驱动的流程来说本地小模型反而更划算。第三是可控性。本地模型的系统提示词、采样参数、上下文窗口全在自己手里。出问题时能精确复现能回滚能换量化版本重测这在实际工程里极其重要。云端模型今天更新明天废弃你的工作流可能一夜之间就变味。选“qwen 3.8”这个档位的本地模型也不是拍脑袋。测试前我特意对比过同级小模型代码能力qwen系列在“Python API调用类”任务上一直不弱而且3.8这个量级意味着量化后权重大约3.6GB普通入门级显卡能跑得动显存不够还可以往CPU方向退。小型模型的好处是速度快、部署简单、日常演示不心疼坏处是代码能力和复杂指令遵循度会比大模型弱一截。这次测试就是冲着“小模型到底能不能顶住Blender动画这种中等复杂度任务”去的。2. Strata跑qwen 3.8的硬指标显存、速度与代码准确率先把Strata跑qwen 3.8的实测数据放上来。我的测试环境是中等配置的消费级主机操作系统Windows显卡显存10GB左右内存32GB模型权重放在本地磁盘推理在Strata里完成。以下数据全部为多次测试取中位值实际数值会根据硬件有所不同。指标实测结果备注模型载入显存占用约4.1GB权重3.6GB 上下文预留10GB显存完全没问题生成长度512token耗时约7秒折合每秒钟70到80个token日常使用感受不到明显等待代码生成成功率一阶段76%二阶段88%详见下文分级测试上下文窗口32K一个中等复杂场景的JSON序列化约3K到5K token窗口足够单次请求最大输出2048 token足够生成中等长度的Blender脚本模型文件大小约3.8GB所以标题叫“qwen 3.8”实际上是量化后的体积跑题说一下“3.8”这个数字。qwen本身不叫3.8模型档位是4B上下这里说的3.8是量化后的占盘体积。很多玩家在本地部署时习惯用权重体积指代模型你看到别人说“我跑的是3.8”通常就是这一档位。量化级别我选的是Q4_K_M平衡速度和精度如果显存足够可以上Q8代码准确率会有一定提升但推理速度会下降约15%。上下文窗口这块要给个正面的评价Blender场景状态用JSON序列化一个包含几十个对象的场景大概在3K到5K token之间而qwen 3.8的32K窗口足够把场景信息反复传给模型进行多轮修改。我还试过极端情况把场景里的材质纹理路径、修改器参数、约束目标全部塞进去总计8K多token模型仍然能理解我在说什么只是生成代码的延迟明显变高。硬指标只是基础真正重要的是代码准确率。我给模型设计了20条Blender操作指令从“创建物体”到“设置关键帧动画”再到“批量修改多个物体的材质”跑出来的结果分成三类一次运行成功、需要微调一次后成功、需要人工大改。一阶段场景里只有一个物体成功率76%二阶段场景里有多个物体并且有父子关系成功率88%三阶段涉及时间轴、曲线、约束成功率只有40%。这个数据说明一个核心事实qwen 3.8能处理基础操作但一旦指令需要跨多个对象、多帧时间轴协同代码准确率会急剧下降。这个结论直接影响后续所有接入方案的选择。模型不行的地方就要靠工程手段去补把复杂任务拆成简单任务多轮对话逐步生成而不是期望它一个prompt全部搞定。3. 接入Blender的两种方案脚本直连与MCP场景反馈跑到这一步我已经确认qwen 3.8的代码能力足以支撑基础动画制作。接下来的核心问题变成了“怎么把模型接进Blender”。实测下来有两种可行方案各有优劣我按实现难度从低到高依次说。3.1 方案ABlender内置脚本直连Strata的兼容APIStrata本地服务会暴露一个OpenAI兼容接口只需要一个HTTP请求就能让模型返回代码。Blender内置的Python自带urllib库不需要额外安装任何包写一个面板或者直接在Scripting工作区跑脚本就行。整体思路分三步把当前场景的关键信息序列化成JSON结构对象名称、类型、位置、旋转、缩放、父子关系、材质名称。把这些JSON填进系统提示词让模型生成“针对这个场景的bpy Python代码”。拿到模型返回的代码后在Blender里执行。系统提示词怎么写是整个方案成败的关键。我经过大量测试最终稳定下来的版本是这样的role_prompt ( 你是一个Blender Python脚本专家。用户会给你场景信息和一个操作需求。\n 你只输出Python代码不要输出解释不要用markdown。\n 只允许使用bpy模块不要使用其他第三方Python库。\n 代码必须保存缩进和引号格式正确。\n 如果需要在动画时间轴上设置关键帧必须显式使用bpy.context.scene.frame_set。\n 代码开头必须使用bpy.ops.object.select_all(actionDESELECT)清理选中状态。\n )这个提示词为什么这么写我逐个解释。“只输出代码不要解释”能防止模型把思考过程混进可执行区块。模型有时候会在代码前后加“python”标记或者“以下是代码”之类的话直接执行必炸提示词里先堵死这条路。“只允许bpy模块”是硬性约束避免模型顺手用os、sys、requests之类与场景无关的库。上次看到模型生成一个os.listdir去扫描磁盘目录完全偏离目标而且存在安全风险。“显式使用frame_set”是为了防止关键帧全部落在同一帧。qwen很爱把场景对象的location设置完之后直接插keyframe却忘了切换当前帧结果所有关键帧都记录在第0帧动画自然动不起来。exec是直接执行模型返回的代码存在一定风险所以我的处理方式是“先预览再强制确认后执行”。模型返回代码后打印到Blender的控制台我肉眼快速扫一遍确认没有删除用户资产、没有导入外部数据之类的危险操作再回车确认执行。自动化程度低了一些但稳妥得多。直接连API适合的场景是“单次操作生成”比如让AI把选中物体随机排布、给一组物体统一添加修改器、批量改材质。对轻量任务响应极快实测一次请求到执行完平均在10秒左右。3.2 方案BMCP方式让模型“看得见”场景方案A有一个明显缺点模型每接收一条指令就要把整个场景的JSON塞进提示词。场景简单还好一旦对象破百、材质和修改器多起来每次请求都堆几千token不说模型还容易眼花缭乱生成一些文不对题的代码。MCPModel Context Protocol解决的就是这个问题。MCP的思路是把场景信息拆成一组“工具”由模型按需调用。模型想知道场景里有哪些对象就调用list_scene_objects想知道某个物体的位置就调用get_object_properties。不需要每次都把全量场景塞给它。我在Blender侧启用了一个轻量MCP服务插件暴露了这些工具mcp.tool() def list_scene_objects() - list[dict]: 返回场景中所有对象的名称和类型。 result [] for obj in bpy.data.objects: result.append({ name: obj.name, type: obj.type, parent: obj.parent.name if obj.parent else None, }) return result mcp.tool() def get_object_properties(obj_name: str) - dict: 返回指定对象的位置、旋转、缩放、材质列表。 obj bpy.data.objects.get(obj_name) if not obj: return {error: object not found} return { location: list(obj.location), rotation_euler: list(obj.rotation_euler), scale: list(obj.scale), materials: [m.name for m in obj.data.materials], } mcp.tool() def set_object_location(obj_name: str, x: float, y: float, z: float) - str: 设置对象的位置并自动设置关键帧。 obj bpy.data.objects.get(obj_name) if not obj: return error: object not found obj.location.x x obj.location.y y obj.location.z z obj.keyframe_insert(data_pathlocation) return fok: {obj_name} moved to ({x}, {y}, {z})Strata作为MCP客户端连上这个Blender服务端模型就能在一个“所见即所得”的环境里工作。相比方案A它的主要优势是提示词极大瘦身。模型不用从一坨JSON里找对象而是直接调用工具精确查询。多轮调试更稳定。模型改完A物体的位置如果想接着改B物体的旋转它只需要再调一次工具上下文不会被无意义信息撑爆。工具约束天然屏蔽瞎写API。模型想要改位置只有调用set_object_location这一条路不会自己瞎编一个不存在的bpy函数。方案B的代价是搭建成本高了不少。我没用现成的运行时直接在Blender插件中心写了一个百来行的MCP服务端。好在协议本身不复杂网上现成模板也多照着抄再改工具函数就行。实测下来在复杂场景上方案B的稳定性明显优于方案A。同样是“把所有球体沿Z轴向上移动并生成动画”方案A在对象超过30个时经常出现对象名引用错误方案B几乎每次都是对的。4. 从“生成代码”到“做出动画”的完整实测链路接入完成后我在Blender里搭了一个空场景开始分三档测试。每一档都是真实的制作场景模拟不是那种“Hello World”级别的例子。4.1 基础阶段让AI在空场景里摆东西第一步测试最简单让模型生成代码往场景里添加一个圆柱体改名为“Pillar”把位置移动到原点以外的地方缩放到原来的1.5倍然后围绕Z轴旋转45度。import bpy import math bpy.ops.object.select_all(actionDESELECT) bpy.ops.mesh.primitive_cylinder_add( radius0.5, depth2, location(1, 2, 0) ) obj bpy.context.active_object obj.name Pillar obj.scale (1.5, 1.5, 1.5) obj.rotation_euler (0, 0, math.radians(45))这代码是一次成功的。模型没有漏掉任何步骤全部按预期执行。耗时大约4秒。紧接着我加复杂度添加三个不同的球体分别用不同材质球间距错开。三条指令里有两条一次通过第三条把材质分配写了两次虽然结果没错但代码显得很啰嗦。整体来说基础创建任务是qwen 3.8最擅长的部分。4.2 进阶阶段关键帧、曲线运动与材质动画制作必然涉及时间轴操作。我要模型让一个球体从第0帧到第60帧沿着圆形路径运动一圈同时把材质从红色渐变为蓝色。这是典型的程序化动画任务在传统工作流里要写不少bpy代码。qwen 3.8给出的代码结构很有意思它没有选择用圆曲线的约束方式而是选择用每帧设置位置并插入关键帧的方式import bpy import math bpy.ops.object.select_all(actionDESELECT) bpy.ops.mesh.primitive_uv_sphere_add(location(0, 0, 0)) sphere bpy.context.active_object sphere.name GlowBall # 创建材质 mat bpy.data.materials.new(nameGlowMat) mat.use_nodes True bsdf mat.node_tree.nodes[Principled BSDF] bsdf.inputs[0].default_value (1, 0, 1, 1) # 初始粉色 sphere.data.materials.append(mat) # 关键帧沿圆路径移动 for frame in range(0, 61): bpy.context.scene.frame_set(frame) angle 2 * math.pi * frame / 60 sphere.location (3 * math.cos(angle), 3 * math.sin(angle), 0) sphere.keyframe_insert(data_pathlocation) # 从粉色渐变为青色 t frame / 60 color (1 - t, 0, 1 - t t, 1) bsdf.inputs[0].default_value color # 设置时间轴范围 start bpy.data.scenes[0] start.frame_start 0 start.frame_end 60这代码通过了初步实测动画确实跑起来。视觉效果上球体会沿着半径为3的圆滑行一圈同时材质从粉色逐步过渡到青色。不过我注意到一个细节它每次给材质颜色插值都没有调用keyframe_insert导致材质颜色的关键帧没有真正记进时间轴。唯一的变通是每帧设置颜色并把颜色更新留在场景图上渲染时颜色会跟着帧号变BGE模式或实时预览能看见但关掉视图再回来颜色就重置了。这个问题非常典型是模型对“属性值修改”和“关键帧记录”两个概念理解不深造成的。另外还有一个更隐蔽的问题它把角度计算放在frame_set之后也就是说第0帧的角度是0度位置在(3, 0, 0)实际动画会从画面右侧起始而不是中心。你要的是一个围绕原点的圆这个写法没问题但如果你的预期是“球从原点出发沿圆走一圈”那起始点就不对了。这类语义歧义模型自身无法识别只能靠人工定义清楚。4.3 失败验证AI写错代码时的表现看一个模型翻车的经典案例。我要求它“选择场景中所有空物体并把它们沿X轴方向排列成间距2的直线”。场景里有五个空物体名字分别是EmptyA到EmptyE。模型给出的代码是import bpy bpy.ops.object.select_all(actionDESELECT) for i, obj in enumerate(bpy.data.objects): if obj.type EMPTY: obj.select_set(True) bpy.ops.object.delete()这代码完全做反了。它把空物体全删了而不是排列。事后分析prompt问题出在对“排列”一词的理解上。模型把“空物体”和“场景里除了空物体之外的东西”搞混又看到一个“选择”就顺手向删除的方向发挥。这类语义漂移在小模型中非常常见越是复合指令越容易触发。处理办法是先给模型少量“示范对话”。我在系统提示词末尾加上了一条示例给定两个对象A和B把A放在B右方2单位处对应的正确代码是什么。加了示例后同类指令的成功率明显提升说明这个档位的模型仍然很依赖“模仿式生成”。5. 实测中的翻车现场与参数微调经验这一周的测试攒了不少翻车记录挑几个最有代表性的写出来。如果你也在做类似的事大概率会碰上同样的坑。第一是引用不存在的对象。模型生成代码时常把对象名写成大写、加空格或者随意加后缀导致执行到一半报错“object not found”。解决办法是在系统提示词里强制加一条“对象名称必须从场景JSON中准确复制不要修改大小写或添加前缀后缀”。第二是关键帧全部落在第0帧。前面已经提到过模型不重视时间轴切换需要显式提示“在设置每一帧的关键帧前调用bpy.context.scene.frame_set”。加了这条以后关键帧错误率从60%降到20%左右。第三是API记忆错误。qwen 3.8在生成的脚本中出现了不存在的bpy函数比如“bpy.ops.object.move()”或者是“bpy.context.scene.objects.active”后者在旧版Blender里存在但在新版里已经移除。这种情况没法靠提示词完全解决只能靠执行前的语法检查兜底。我在执行前加了一个轻量检查器用AST模块解析模型返回的代码解析失败就直接拒绝执行从源头挡住语法错误。第四是上下文污染。多轮对话时如果模型之前生成过错误代码后续每一轮都会延续这个错误。解决办法是做“上下文隔离”每当一次操作完成就清空历史只保留系统提示词和最新一条用户指令。这样虽然牺牲了连续对话能力但换来了输出稳定性对“代码生成”这个任务来说非常值得。参数调优方面我给Strata里的qwen 3.8设置了这样一组数值参数设定值为什么这样设temperature0.2降低随机性防止模型自由发挥写出奇奇怪怪的代码top_p0.1进一步压缩采样空间让输出更贴近训练分布max_tokens1024预留长度给复杂脚本但避免模型写超长废话frequency_penalty0代码任务里重复函数名是正常的惩罚反而有害presence_penalty0和上面同理temperature是最关键的一个参数。初始测试的时候它在默认的0.7模型输出很有“创意”代码里甚至有注释和解释性文字但可执行率和正确率都低。调到0.2之后输出稳定了很多代价是偶尔会显得“死板”——比如坚持使用同一个代码模板去套不同场景。在代码生成任务里“死板”恰恰是安全性来源。6. 关于这套工作流的个人体会与后续扩展跑完整个测试我的结论是Strata跑qwen 3.8接入Blender这套工作流已经具备日常生产力但前提是你必须理解它的边界。它适合解决“已知对象的批处理操作”和“中等复杂度单目标动画生成”不适合一刀切处理需要全局理解的复杂场景。实际操作中的几点体会别指望着它能完全替代动画师。模型擅长的是把一句话翻译成脚本但“这句话本身该怎么表达”还是人的事。每次想让AI生成代码心里得有预期结果否则模型也不会帮你创造。场景信息预处理极其重要。我在调用模型之前先写了一个脚本把场景里的对象按类型整理成表格过滤掉相机和灯光只保留需要操作的目标模型准确率直接提升了一截。饲料干净了输出自然干净。量化级别与精度的取舍要端平。Q4_K_M在日常任务中足够但如果你要“批量生成几十个物体的复杂约束”建议换Q8。实测Q8在关键帧生成场景的错误率低于Q4约12%代价是每个请求慢2到3秒。显存宽裕就别省这个精度。后续扩展方向很多。我已经在尝试把常用的动画操作封装成MCP工具实现从“让AI写代码”升级到“让AI调用工具的代码”比如把“沿路径运动”封装成set_camera_follow_path模型只需要给出参数。这种思路能让小模型绕过不熟悉的API细节只负责决策和参数生成稳定性会好几个档次。如果你真想搭一套本地AI动画工作流我建议从方案A开始跑通再逐步过渡到方案B。初期不要追求全自动化先让AI帮你把重复的、可量化的动画操作跑起来把真正需要艺术感受的部分留在自己手里。这套组合可能不会让你一夜之间变成动画大师但它绝对会把你从“每天都得调同样的bpy参数”的枯燥中解放出来。