Deepseek、Codex、Blender 这三个词放在一起很容易让人以为是在讲一个“AI 一键生成 3D 大片”的魔法按钮。真正上手之后你会发现它解决的不是“自动建模”而是把一套建模流程变成可反复调用的 skill让重复劳动变得可控、可改、可复用。Codex 在这里是执行代理Deepseek 负责把自然语言需求拆成建模步骤Blender 则是接收 Python API 命令的底层画布。我最近用这个组合尝试搭建天宫仙境场景时最深刻的体会是不要追求一次生成整个宫殿而要先跑通“一句话 - 脚本 - Blender 输出文件”的最小链路。这里还有一层容易被忽略的好处整个流程不需要背 Blender 快捷键也不用手动去点菜单。Codex 控制 Blender 的方式是通过命令行执行 Blender 的 Python 脚本相当于把建模操作全部脚本化。你真正要关心的是场景拆解、参数设计、输出校验和异常处理这些东西才是长期能复用的能力。1. 这个组合真正解决的不是“自动建模”而是流程失控很多人第一次看到“Deepseek Codex Blender”时会默认它的价值是“让 AI 替你建模”。这个理解不能说错但它把重点放偏了。手动建模重复做三个月你自然会想到写脚本写脚本最难受的是每个场景都有差异脚本不能写死。Deepseek 和 Codex 的组合真正解决的是“流程失控”的问题让一个复杂的、多步骤的、容易遗漏的 3D 工作流变成一份可以被语言调用的施工手册。1.1 为什么手动脚本解决不了“每次都不同”的场景如果你懂一点 Blender Python你完全可以写一个生成宫殿的脚本创建圆柱做柱子创建立方体做台基创建锥体做屋顶。问题是今天你要做天宫明天你要做海上仙山后天你要做不同比例的城门楼。每次都要改坐标、改尺寸、改命名规则脚本维护成本很快超过收益。这时候你会想到让大模型来写脚本。但直接把整个需求丢给模型结果通常不稳定这一轮生成的代码能用下一轮代码的命名方式又变了输出路径也可能丢。原因很简单大模型每次都在重新“猜”你的工作流它没有约束也没有检查点。1.2 Deepseek、Codex、Blender 三者各管一段我更建议把这个组合理解成一条流水线而不是一个黑盒组件职责类比Deepseek把“天宫仙境”这样的需求拆成具体建模步骤并生成 Blender Python 脚本设计师 / 拆解者Codex加载 skill、执行命令、调用 Blender、回读日志决定下一步做什么项目经理 / 执行调度Blender接收脚本命令完成几何创建、材质设置、渲染输出施工队 / 画布Deepseek 负责“想”Codex 负责“做”Blender 负责“出活”。如果你想控制得更细还可以让 Codex 在每一步后读取 Blender 输出的对象数量、文件路径和渲染结果然后决定是否继续。这种分工最大的意义是你不再需要把全部场景细节塞进一次对话里。你可以把天宫拆成台基、立柱、屋檐、祥云、灯光分别交给 skill 处理每一步都能被验证、被修改。现在社区里已经出现了不少 harness 或插件项目本质都是在做这件事但无论封装成什么样底层链路都绕不开“模型拆解 - Agent 执行 - Blender 输出”。2. 搭环境先跑通“最小链路”再追求“自动生成”搭建环境的第一步不是配一个“全自动天宫生成”系统而是先回答一个更基础的问题让 Codex 执行一条最简单的 Blender 命令能不能看到输出2.1 最少需要准备什么从常见实践看本地至少需要这几样东西工具说明Blender建议 3.6 以上版本4.x 也常见需要能通过命令行启动Codex CLI可通过 npm 或 Homebrew 安装安装后用codex --version验证Deepseek API Key用于把 Codex 的模型后端接到 DeepseekPython 环境Codex CLI 本身需要运行环境Blender 内置 Python 只负责执行脚本这里要注意Blender 自带一套 Pythonblender -b -P script.py执行脚本时使用的是 Blender 内置的 Python而不是你系统里安装的 Python。Codex CLI 负责生成和运行命令不负责给 Blender 提供 Python 环境。理解这一点后面排查问题会少走很多弯路。Deepseek 接入 Codex 的方式不同版本差异很大。目前 Deepseek 提供兼容 OpenAI 格式的 API所以很多社区配置会在 Codex 的自定义模型供应商里填上 Deepseek 的接口地址、模型名和 API Key。具体字段名不要照抄旧帖子以你当前安装版本的示例配置为准。模型名通常可以选deepseek-chat或deepseek-reasoner这类标识具体以当时 API 文档为准。2.2 先验证 Blender 能脱离界面执行脚本先写一个最小脚本test_blender.pyimport bpy print(Blender Python OK:, bpy.app.version_string)然后在终端里执行blender -b -P test_blender.py如果终端里能看到类似Blender Python OK: 4.x.x的输出说明 Blender 的命令行链路是通的。这个步骤很重要因为很多“Codex 控制不了 Blender”的问题其实不是 Codex 的问题而是 Blender 本身根本没有被正确调用。接下来再加一个更接近建模的测试import bpy bpy.ops.object.select_all(actionSELECT) bpy.ops.object.delete(use_globalFalse) bpy.ops.mesh.primitive_cube_add(size2.0, location(0, 0, 1)) print(Cube created)执行后没有报错再继续下一步。2.3 再验证 Codex 能调用命令并回读输出在接入 skill 之前先用一个最直白的 prompt 测试 Codex请运行 blender -b -P test_blender.py并把输出展示给我。如果 Codex 能把命令执行完并正确回读 Blender 打印的信息说明“模型 - Agent - Blender”的链路已经打通了。这时候再做天宫场景才算有基础。一个小提醒不要一上来就开启完全自动模式尤其是让 Codex 直接删除文件、覆盖输出、修改系统路径。先让它在工作目录内跑确认一次链路再逐步放开权限。注意不要一上来就让 Codex 生成整个天宫。先让它画一个立方体保存一个文件跑通链路再逐步扩大范围。3. 用 skill 把“天宫”拆解成施工手册Codex 控制 Blender 建模真正有门槛的不是 API 调用而是怎么让模型每次都按同一套逻辑施工。skill 就是用来解决这个问题的。3.1 为什么需要 skill让模型按套路施工如果把需求直接丢给模型它当然也能写出一段生成宫殿的代码。但问题很明显每次生成的对象命名可能不一样坐标原点可能不一样材质颜色可能不一样甚至有时会漏掉“清空默认场景”这个关键步骤。这种不稳定性对一次性的 demo 没有影响但如果你想反复生成不同形态的天宫场景就很难接受。skill 的作用是给模型一份“施工手册”。手册里写清楚任务目标、执行顺序、命名规则、输出路径和检查方式。模型不再凭空猜而是按照手册里的框架写代码。这样哪怕中间换了模型输出也会稳定很多。3.2 一个最小 skill 的示例结构skill 的具体加载方式会随 Codex 版本变化但设计思路是一致的。你可以把它理解成一组文件里面包含一段 Markdown 说明和若干参考脚本。下面是一个很简化的示例结构不保证所有版本通用但它能帮你建立起概念--- name: blender_build_palace description: 在 Blender 中生成天宫风格场景先清理场景再按组件顺序建模 triggers: - 天宫 - 宫殿群 - palace --- # 施工步骤 1. 解析用户描述中的元素列表。 2. 清理 Blender 默认场景删除默认立方体。 3. 按 台基 - 立柱 - 屋檐 - 祥云 - 灯光 的顺序建模。 4. 每个大步骤结束后打印当前场景对象数量。 5. 保存 .blend 文件到输出目录并打印文件路径。这段说明不是给代码执行器看的而是给大模型看的。模型读到 skill 之后会按照步骤去生成 Blender Python 脚本。你可以在 skill 里补充更多细节比如“柱子用圆柱体”“台基用立方体并缩放”“屋顶用锥体”等等让模型少一点自由发挥。3.3 从手写脚本到 skill 的升级路径很多人一开始就想写一个完整的“天宫 skill”这是最容易翻车的路径。更好的做法是先把单个组件跑通再逐步沉淀成 skill。我的建议路径是手写脚本生成一个柱子和一个台基。让 Codex 运行脚本确认输出正确。把尺寸、数量、颜色等可变参数提取成变量。把脚本和说明整理进 skill。用不同的参数跑两遍验证 skill 是否稳定。比如下面这个脚本片段只做“台基 成排柱子”的最小闭环import bpy # 清理默认场景 bpy.ops.object.select_all(actionSELECT) bpy.ops.object.delete(use_globalFalse) # 台基 bpy.ops.mesh.primitive_cube_add(size2.0, location(0, 0, 0.5)) base bpy.context.object base.scale[0] 3.0 base.scale[1] 2.0 base.scale[2] 0.5 # 柱子 for i in range(4): x -1.2 i * 0.8 bpy.ops.mesh.primitive_cylinder_add(radius0.2, depth2.0, location(x, -0.8, 1.5)) column bpy.context.object column.name fpalace_column_{i:02d}这样做的价值在于Codex 以后遇到同类需求时可以直接参考这段脚本里的命名和结构而不是每次都从零开始编一套新的。等组件越来越多再把这些脚本整合进 skill天宫场景的搭建速度才会真正上来。4. 真正决定成败的是输入边界和输出边界很多人第一次用这个组合时关注的都是“模型能不能生成代码”。实际上模型生成代码只是第一步真正决定项目能不能长期用的是输入边界和输出边界。4.1 输入边界单位、命名、坐标和路径先看三个最常见的输入问题。第一是单位。Blender 默认使用米但你可以把场景单位改成厘米或者毫米。同一个location(0,0,1)在不同单位下视觉比例完全不同。所以 skill 里一定要写清楚“当前场景单位使用米”或者在每次建模前统一重置单位。第二是命名。如果你不主动命名对象Blender 会生成一堆Cube.001、Cylinder.004之类的名字。当场景里有几百个对象时后续修改根本无从下手。我更建议在 skill 里约定命名规则比如palace_column_01、palace_roof_01让每个对象都能被识别。第三是路径。Blender 脚本里写 Windows 路径时要注意反斜杠转义问题路径中有空格或中文时也会增加出错概率。测试阶段最好先用简单的绝对路径比如/tmp/palace_test.blend确认链路后再换成项目目录。还有一个很容易忽略的点坐标原点。代码生成时模型的旋转和缩放是相对原点的。如果 skill 没有规定“主体建筑中心位于世界原点”生成结果就可能偏移到很远的地方看起来像是“代码成功但场景乱七八糟”。4.2 输出边界不只保存一个 .blend 文件单一 .blend 文件只能说明“脚本执行完了”不能说明“结果符合预期”。我建议在 skill 里定义三样输出主文件保存后的.blend路径。验证信息对象数量、面片数量、材质数量。渲染结果一张测试角度的渲染图。保存主文件可以这样写import bpy bpy.ops.wm.save_as_mainfile(filepath/tmp/palace_test.blend) print(Saved:, bpy.data.filepath)渲染一张测试图可以用import bpy bpy.context.scene.render.filepath /tmp/palace_render.png bpy.ops.render.render(write_stillTrue) print(Rendered:, bpy.context.scene.render.filepath)这两段代码都不复杂但它们会强迫流程回答一个问题这个场景到底生成成什么样了如果 Codex 每次跑完都能告诉你“保存到了哪里渲染图在哪里场景里有多少个对象”你才真正具备迭代的基础。4.3 参数表格化让每次生成都可复现想让“天宫仙境”能被反复生成最好把可变参数抽成一张表而不是散落在脚本各处。比如在 skill 里约定参数含义示例值base_width台基宽度3.0base_depth台基深度2.0column_radius柱子半径0.2column_height柱子高度2.0column_count每排柱子数量4roof_scale屋檐缩放比例1.2output_name输出文件名tian_gong_a这样模型在生成脚本时会优先从这张表里取参数而不是自己随意发挥。你要生成不同版本的天宫时只需要改参数表不需要重写整个 skill。5. 踩坑排查按照链路逐层确认这个组合的报错五花八门但绝大多数都可以归到几个固定层级。按照链路一层一层查比随机试要快得多。5.1 常见的三类报错第一类Codex 本身没跑起来。如果你看到类似Unable to locate the Codex CLI binary的提示通常不是 Blender 的问题也不是 Deepseek API 的问题而是 Codex CLI 没有被正确安装或者当前终端的 PATH 没有包含它的安装目录。先打开终端执行codex --version如果能输出版本就把这个二进制路径填到工具的配置里如果终端也不认识就先重新安装 Codex CLI。第二类Blender 命令执行成功但没有任何输出。这种情况下先用人工方式执行一遍blender -b -P test_blender.py确认 Blender 本身能跑如果人工执行正常再检查 Codex 的当前工作目录、命令路径和权限配置。第三类skill 没有被触发。很多时候是因为 skill 名称或描述不够明确。可以在 prompt 里显式写“使用 blender_build_palace skill”或者直接说“按天宫宫殿群 skill 的步骤执行”。如果 skill 还是没有加载检查 skill 文件是否放在 Codex 能扫描到的目录下以及名称和描述是否和约定一致。5.2 推荐的排查顺序我一般会按这个顺序排查先看 Codex 本身运行codex --version确认 CLI 可用。再手工运行blender -b -P test_blender.py确认 Blender 脚本链路可用。让 Codex 执行一个最简单的脚本确认它真的能调用命令并回读输出。再加入 skill先跑一个最小组件比如一根柱子。最后才生成完整的天宫场景。如果第 2 步就失败后面的所有问题都不用看。很多时候问题不是模型不行而是执行环境不完整。如果你使用的是旧版 Blender某些 Python API 的参数名可能不一样。遇到 “unexpected keyword argument” 之类报错时先查你本机 Blender 版本的 API 文档而不是硬套网上的新代码。6. 这个方案适合什么不适合什么把组合跑通之后更要清楚它的使用边界。它不是一个通用的 3D 生产工具而是一个适合特定场景的自动化工作流。6.1 适合快速搭建概念场景和批量变体这个方案最适合的是快速生成概念场景、场景布局和批量变体。比如你要做天宫仙境的初版效果需要台基、柱子、屋顶、云海、灯光的粗略摆位让 Deepseek 拆解、让 Codex 执行很快就能得到一个可导入 Blender 继续修改的基础场景。它也适合做批量变体。同样的 skill把参数表里的column_count从 4 改成 6再把屋顶缩放从 1.2 改成 1.5就能生成另一个版本的宫殿。只要 skill 稳定生成十个小版本并不难。6.2 不适合需要生产级拓扑和专业绑定的场景但如果你需要的是骨骼绑定、角色权重、复杂 UV 展开、工业级拓扑或者要求模型面数干净、每条边都有明确用途那目前这类“让大模型写脚本控制 Blender”的方式并不合适。原因很简单模型生成的脚本偏向于“快速摆出形状”不会考虑拓扑质量更不会考虑后续要进游戏引擎做动画。所以我的建议是把它当作前期的场景草稿生成器或者当作重复性工作的自动化助手而不是替代资深建模师的工具。最终需要进入生产管线时还是要导入 Blender重新整理拓扑、材质和命名。单次跑通只能说明流程没有断长期使用需要日志、校验、参数表和异常处理。这三件事缺一件后面都会回来找补。这个组合真正值得长期关注的地方不是“AI 能不能建模”而是它能不能帮你把经验沉淀成一套可复用的操作流程。模型会升级Codex 会改版Blender 也在不断更新但“先拆解任务、再固化流程、最后验证输出”的思路才是这类工作流的核心。先跑通最小闭环再逐步扩大场景范围你会发现“让 AI 控制 Blender 建模”这件事真正难的不是技术而是流程设计。