企业官网建设流程全解析

最近在折腾一套组合：Deepseek + Codex CLI + Blender。目标很直接——用中文描述需求，让 AI 自动生成 Blender 建模脚本，最后搭出一座天宫仙境。实测下来，这套流程能跑通，而且思路一旦理顺，不只是做天宫，做蒸汽城、赛博街区、海底遗迹都能复用。但要说清楚：这不是装上就能用的“一键生成”，中间有三道坎，环境配置、skill 设计、脚本调试，每一道都决定最终效果稳不稳定。这篇文章按实际落地顺序拆一遍，适合对 Blender 建模有基础、想用 AI 提效的人，也适合刚接触 Codex CLI 的开发者。

1. 先理清这套组合的分工，别把顺序搞反

1.1 Deepseek、Codex、Blender 各干各的活

很多人看到“Deepseek + Codex 控制 Blender”以为三个东西合并成了一个新工具。实际上它们是三层关系。

Deepseek 是模型层。它负责理解你的中文描述，把它转换成可执行的 Python 代码。Deepseek 的 API 兼容 OpenAI 格式，所以很多开源智能体工具可以直接切换过去。你可能会看到 deepseek harness 之类的词，本质上也是把 Deepseek 接进不同智能体框架，Codex CLI 只是其中一种选择。

Codex CLI 是智能体层。它是运行在终端里的 AI 编程代理，负责接住自然语言指令，拆解任务，调用模型生成代码，然后执行代码、读取结果、根据报错自动修改。你可以把它理解成一个会用电脑的助手，而不是一个对话框。

Blender 是执行层。它自带完整的 Python API，也就是 bpy，可以用脚本建模、加材质、摆相机、渲染。AI 生成的脚本，最终要拿到 Blender 里跑。

正确的顺序是：先告诉 Codex 要什么，Codex 调用 Deepseek 生成 Blender 脚本，再把脚本交给 Blender 执行，最后把渲染图或报错信息反馈给 Codex，让它继续迭代。这个闭环打通了，才算真正“自动控制”。

如果把顺序搞反，比如先让 Blender 去调用 Deepseek，或者让 Codex 直连 Blender 的图形界面，都会绕远路。记住一点：Codex 只负责生成和调试代码，Blender 只负责执行代码，中间靠 Python 脚本传递。

1.2 为什么值得这么做

手动建模一个天宫场景，工作量集中在这几块：浮空岛的地形调整、中式建筑的结构搭建、云海和粒子、灯光和雾气。这些在 Blender 里都可以用参数化方式生成，但手工操作要反复切换菜单、调整数值，非常琐碎。

把参数化建模交给 AI 之后，工作流会发生一个关键变化。以前是“我想做一个飞檐，所以要选中面、挤出、旋转、合并顶点”，现在是“我要一个带飞檐的屋顶模块，高度 3 米，瓦片材质偏青色，生成 6 个按环形排列”。描述层级从“操作”变成了“意图”。

但这个转变有前提：AI 生成的脚本必须稳定可执行，不能每次生成的风格都不一样。所以后面要专门给 Codex 做一个面向 Blender 的 skill，把常用建模套路固定下来。

2. 环境准备：Codex CLI、Deepseek API、Blender 三件套

2.1 安装 Codex CLI

Codex CLI 官方推荐用 npm 全局安装：

npm install -g @openai/codex

安装完成后先确认版本：

codex --version

如果提示找不到 codex 命令，先检查 npm 的全局 bin 目录是否在 PATH 里。Windows 上常见问题是 npm 全局路径和系统 PATH 不匹配；macOS 和 Linux 上常见问题是用了 nvm 之后，node 版本切换导致全局命令找不到。解决方法是把npm config get prefix拿到的目录手动加到 PATH。

这里有一个高频报错，值得单独说：很多人在 Codex 的桌面端或编辑器插件里看到 “unable to locate the codex cli binary. set codex cli path or ensure the executable is available in your PATH”。意思是插件找不到 CLI 程序。这不是 Deepseek 的问题，也不是 Blender 的问题，单纯是 CLI 没装好，或者插件不知道去哪找它。先在本机命令行里跑codex --version能通过，再回插件里配置 CLI 路径。

2.2 把 Deepseek API 接进来

Codex CLI 默认使用 OpenAI 的模型，但你可以在配置里指定自定义 provider。因为 Deepseek 的 API 兼容 OpenAI 格式，所以只需要修改 base_url 和 api_key。先确认你已经在 Deepseek 开放平台创建了 API Key。

配置方式以配置文件为主。Codex CLI 启动时读取用户目录下的 config.toml，大致长这样：

model = "deepseek-chat" model_provider = "deepseek" [model_providers.deepseek] name = "DeepSeek" base_url = "https://api.deepseek.com/v1" env_key = "DEEPSEEK_API_KEY" wire_api = "chat"

注意，不同版本的 Codex CLI 对配置字段的兼容性不完全一样。实际落地时先跑codex --help看当前版本支持的字段。配置完成后，用一条最简单的指令验证连通性，比如让 Codex 写一句 Python 打印 hello。

这里不要急着直接让它控制 Blender。先确认模型能响应、代码能生成，再进入 Blender 环节。这个顺序可以帮你缩小问题范围：如果前面的任务都通，后面报错就大概率是 Blender 环境或脚本问题。

2.3 准备 Blender 的 Python 执行环境

Blender 建模控制通常有两种方式。

第一种是后台模式：

blender -b -P script.py

-b 表示 background mode，不启动图形界面；-P 指定要执行的 Python 脚本。这个模式适合 AI 生成脚本后自动执行，也适合在服务器上跑。

第二种是把 Blender 当作 Python 模块导入：

import bpy

这要求 Blender 的 Python 和系统 Python 版本匹配，配置起来更费劲，不建议新手优先尝试。

我推荐先用后台模式。理由很简单：你只需要确认 blender 可执行文件在 PATH 里，然后不管脚本怎么生成，执行方式都是同一行命令，不用为每个脚本单独开界面。

安装 Blender 时要注意系统差异：

• Windows 下安装完成后，把 blender.exe 所在目录加到 PATH。
• macOS 下直接在官方包安装，命令行工具路径通常是/Applications/Blender.app/Contents/MacOS/Blender。
• Linux 下可以用发行版包管理器，也可以用官方压缩包，看你的习惯。

验证方式：

blender --version

能输出版本号，说明 CLI 正常。再跑一个最简单的脚本：

# hello.py import bpy print("hello from blender", bpy.app.version_string)

执行：

blender -b -P hello.py

如果能看到打印信息，说明 Blender 的 Python API 正常。我建议在 Windows 上把输出重定向到日志文件，因为后台模式下终端窗口容易丢输出：

blender -b -P hello.py > hello.log 2>&1

把日志写清楚，后面排查能省一半时间。

3. Skill 机制：AI 能稳定控制 Blender 的关键

3.1 skill 到底是什么

在 Codex 里，skill 是一组预置指令，作用是告诉 AI 在特定领域怎么做。你可以把 skill 理解成“行业规范”或“操作手册”。Codex 接到任务时，如果发现任务和某个 skill 匹配，就会加载这个 skill 里的规则，再结合模型能力生成代码。

直接让 AI 写 Blender 脚本，它也能写，但每次写的风格可能不一样：有时用 bpy.ops，有时用 bpy.data 直接操作；命名规则不统一；对场景清理、材质管理、渲染输出的处理也千差万别。这种不稳定会直接导致后续脚本改起来很痛苦。skill 就是用来解决稳定性的。

3.2 一个 Blender skill 应该包含什么

在用户目录或项目目录下建立技能目录：

~/.codex/skills/blender-modeling/ └── SKILL.md

SKILL.md 内容建议覆盖这几块：

1. 基础约定：使用 bpy 模块，坐标系统是 Z 轴向上。
2. 物体创建方式：默认用bpy.ops.mesh.primitive_*_add系列，创建后立刻命名。
3. 场景清理：每次建模前把场景里的物体清理干净。
4. 材质规则：材质命名统一，颜色使用线性 RGB。
5. 渲染输出：使用 PNG 格式，设置输出目录。
6. 安全边界：引用对象前先检查是否存在。

这里给一个简化版 SKILL.md 示例，实际可以根据项目不断往里加：

# Blender 建模技能 ## 目标 根据用户描述生成可在 Blender 后台模式执行的 Python 脚本。 ## 规则 - 统一使用 import bpy - 创建物体后立即设置 name，命名格式：前缀 + 物体类型 + 序号 - 创建物体前清理场景，避免上一轮物体残留 - 材质使用 bpy.data.materials，命名带材质用途 - 渲染输出统一为 PNG - 对物体做删除或修改前，先判断该物体是否存在，避免 KeyError - 脚本全程不启动 UI，只用后台模式

skill 里还可以放少量示例代码。Codex 生成代码时，参考这些示例会更接近你想要的结构。示例不要写太长，重点是套路而不是具体参数。

3.3 如何让 Codex 加载 skill

Codex 会在任务上下文里自动匹配 skill。你可以直接用自然语言告诉它：“使用 blender-modeling 技能，创建一个浮空岛。”如果版本支持，也可以把它写进项目的 AGENTS.md，作为默认上下文的一部分。

不同版本的 Codex 对 skill 的加载方式可能有差异。建议先跑一个简单测试：创建技能后，让 Codex 写一个“创建一个命名为 test_base 的立方体”的脚本。如果生成的脚本符合 SKILL.md 里约定的命名和清理规则，说明 skill 生效了。

4. 实操：从最小样例到天宫仙境

4.1 先跑单条任务：一座浮空岛

第一次尝试不要直接提“天宫仙境”这种大场景，先让 AI 生成一座浮空岛。这个任务足够小，能验证整条链路，又包含地形、材质、渲染三个关键环节。

给 Codex 的指令可以是这样：

使用 blender-modeling 技能，生成一个浮空岛模型： - 主体是上下压扁的球体 - 底部稍微不平整，像被挖过的岩石 - 顶部是平台 - 给岛体加一个岩石材质 - 保存到 /tmp/island_test.blend - 不需要渲染

Codex 生成的脚本大概长这样：

import bpy # 清空场景 bpy.ops.wm.read_factory_settings(use_empty=True) # 创建浮空岛主体 bpy.ops.mesh.primitive_uv_sphere_add(radius=2.0, location=(0, 0, 0)) island = bpy.context.active_object island.name = "island_body" # 压扁球体 island.scale = (1, 1, 0.45) bpy.ops.object.transform_apply(scale=True) # 细分修改器，让表面更平滑 bpy.ops.object.modifier_add(type='SUBSURF') island.modifiers["Subdivision"].levels = 2

把生成的脚本保存成 create_island.py，然后执行：

blender -b -P create_island.py

检查标准：日志无报错，脚本结束后生成了 .blend 文件。用bpy.data.objects.keys()打印场景里的物体名字，确认 island_body 存在。

4.2 把天宫拆成模块，而不是一次生成

天宫仙境听起来是整体场景，但实际建模必须拆模块。原因很简单：AI 一次生成的脚本越长，越容易在中间某个环节出错，而且出错后很难定位。单个模块出问题，只需要重新生成那一段，不影响整个项目。

我建议把天宫拆成 6 个模块：

1. 浮空岛基座：地形、岩壁、边缘平台。
2. 主殿建筑：主体、屋顶、飞檐、柱子。
3. 配殿和连廊：沿主殿两侧扩展。
4. 云海：大量平板云层，铺在浮空岛下方。
5. 瀑布：从主殿旁边倾泻而下。
6. 灯光和相机：暖色霞光、雾气、渲染参数。

每个模块一个脚本，脚本之间用 Blender 的集合或命名前缀隔离。例如主殿建筑统一用 main_hall_ 前缀，云海用 cloud_ 前缀。后面调整时，只需要处理对应前缀的物体。

4.3 让 Codex 生成中式建筑元素的思路

中式古建筑在 Blender 里建模，最难的部分是屋顶和飞檐。如果用复杂网格建模，AI 生成的代码容易出错。更稳妥的做法是参数化拼装：屋顶主体用圆柱或棱柱压扁，飞檐用切削后的锥体拼接，柱子用圆柱体，底座用立方体。

给 Codex 的指令要尽量具体：

使用 blender-modeling 技能，创建一座中式主殿： - 底座：长 8 米、宽 5 米、高 1 米的长方体 - 柱子：6 根圆柱，直径 0.3 米，高 4 米，红色材质 - 屋顶：主体是一个宽 10 米、高 2 米的扁圆锥，青色瓦片材质 - 飞檐：屋顶四角向外向上翘起，用旋转 45 度的锥体模拟 - 所有物体名字以 main_hall_ 开头

Codex 生成时，会把圆柱、立方体、锥体这些 primitive 组合起来。这个思路非常适合 AI 建模：不追求一个物体做得很精细，而是通过模块组合实现造型。

对于飞檐这种复杂形态，可以先让 Codex 生成基础版本，再到 Blender 里手动微调。后台模式下脚本生成的物体进入 Blender 后，随时可以用常规快捷键调整。顺便提一下 Blender 的常用快捷键，因为 AI 生成的脚本往往只是搭了个架子，最终效果还是需要手动修正：

• Shift + A：添加物体
• G：移动
• S：缩放
• R：旋转
• Tab：编辑模式切换
• N：打开右侧属性面板
• Z：切换渲染视图

这些快捷键和 AI 脚本不冲突。AI 负责快速生成主体结构，你负责审美修正。

4.4 云海、瀑布和光的处理

云海是“仙境感”的核心。最常见的做法是创建大量带透明纹理的平面，分布在浮空岛下方。Codex 生成代码时可以用循环创建平面。注意不要创建太多，否则渲染速度和文件体积会急剧增加。我建议先创建 30 片左右的云层，铺满主要视角范围就好。

瀑布可以用流体模拟，但流体会让脚本复杂度和渲染时间急剧上升。更快的做法是用一个半透明蓝色材质的长方体贴在浮岛侧面，配合粒子系统飘落一些白色小点，模拟水花坠落。视觉上够用，生成速度快。

灯光方面，建议用一盏暖色太阳光做主光源，再加几盏补光灯。渲染参数里开启雾效或体积光，能大幅提升“仙气”感。Codex 生成时要注意：Blender 的渲染引擎建议用 Cycles 或 Eevee，两者对灯光的处理逻辑不同。如果只是看效果，Eevee 快；如果要高质量输出，Cycles 更好。

完整的天宫渲染脚本大概有 300 到 500 行。这个长度对 AI 来说完全可以生成，但前提是前面几个模块都已经单独跑通。如果前面模块报错，不要直接在大脚本里排查，先回到那个模块的单脚本里去修。

4.5 渲染输出和验收标准

最终验收不是只看能不能出图。我建议用这几个标准判断：

1. 启动无报错：脚本执行完，日志最后有完成提示。
2. 物体数量符合预期：主殿、浮空岛、云海、瀑布都有对应物体。
3. 渲染输出正常：拿到了 PNG 图，不是黑屏。
4. 构图完整：相机视角里能看到建筑主体，云海在下方，光从侧后方打过来。
5. 可重复性：同一份脚本跑两次，输出的场景一致，没有随机错位。

渲染命令示例：

blender -b island_hall.blend -E BLENDER_EEVEE_NEXT -o //render/frame_ -F PNG -f 1

参数说明：-b 后台模式，-E 指定渲染引擎，-o 输出路径，-F 输出格式，-f 1 渲染第 1 帧。如果你用 Cycles，把引擎名称换成 CYCLES。

5. 模型选择、参数设置和资源边界

5.1 该用 deepseek-chat 还是 deepseek-reasoner

Deepseek 提供对话模型和推理模型。在 Codex 控制 Blender 的场景里，我的建议是：

• 日常建模任务，用对话模型，速度快、成本低，语法错误通常也能修。
• 复杂场景生成，用推理模型，它在拆解任务和生成长脚本时更稳。

没有绝对标准，因为具体模型命名和版本会变化。你可以把同一个浮空岛任务分别用两个模型跑一遍，看谁生成的脚本错误更少、修改次数更少。这是最可靠的判断依据。

5.2 上下文、并发和重试的取舍

Codex 在运行时会维护会话上下文。脚本越长、修改轮次越多，上下文消耗越快。长任务建议分段执行：先让 Codex 生成单模块脚本，确认通过后再生成下一个。不要在同一个会话里连续生成十几个模块，上下文爆掉之后，AI 会越来越容易“忘记”前面的约定。

批量控制 Blender 脚本时，如果有多个任务，不要同时跑太多并发。Blender 是资源大户，多个实例同时跑会争抢 CPU 和内存，导致任务互相拖慢，甚至内存不足直接崩溃。我一般先开 2 到 3 个实例测试，确认机器扛得住再加并发。

5.3 资源占用和场景规模

天宫仙境这类场景涉及大量物体，脚本生成的物体数量如果超过几千个，文件加载和渲染都会变慢。建议保持一个原则：能合并的物体就合并，能减少面数就减少。比如云海用 30 个平面就够了，不需要 500 个。

如果你的机器配置不算高，重点关注三样东西：内存容量、渲染引擎类型、渲染分辨率。内存决定场景能不能跑完，Eevee 决定能不能快速出图，分辨率决定等待时间。低配置机器建议先用 720p 渲染验证构图，最后再出 1080p 或更高分辨率。

6. 高频报错排查链路

6.1 Codex 相关错误

先处理智能体层的问题。常见的是安装和网络两个方向。

如果出现 unable to locate the codex cli binary，按这个顺序排查：

1. 在命令行跑codex --version，确认 CLI 本身可用。
2. 如果命令行可用，确认调用 Codex 的插件或桌面端是否配置了正确的 CLI 路径。
3. 检查 PATH，确保 npm 全局 bin 目录在里面。
4. 如果插件有自定义路径设置，手动指向 CLI 可执行文件。

如果出现类似 cc switch local proxy failed while handling codex endpoint /responses 的报错，说明 API 请求链路出了问题：

1. 先看 base_url 是否正确，Deepseek 的接口地址，配置的是 v1 结尾还是非 v1。
2. 再确认 API Key 是否有效、是否有余额。
3. 检查系统代理环境变量，有些代理配置会拦截本地请求。
4. 最后看网络到 API 服务是否连通，可以用 curl 简单测试。

6.2 Blender 脚本执行错误

脚本层面最高频的三类错误：

第一，bpy 模块找不到。这就是 Blender Python 环境问题。不要用系统 Python 直接跑脚本，必须通过blender -b -P或 Blender 内置的 Python。

第二，物体引用失败。报错 KeyError 或 AttributeError，通常是因为脚本里引用了一个之前不存在或已经被删除的物体。排查办法是在创建物体后打印所有场景物体名，确认命名和引用一致。

第三，渲染输出黑屏。多数时候是相机或灯光没有设置好。先确认场景里有相机，相机视锥对准主体；再确认有光源，否则渲染出来就是黑的。

6.3 输出异常的排查顺序

如果脚本能跑，但模型歪了、比例不对、位置漂移，不要急着让 AI 重写脚本。先做三件事：

1. 看日志里有没有随机数或者未固定参数。
2. 打开 .blend 文件，检查中心点、缩放是否被 Apply 过。
3. 检查坐标单位。Blender 默认单位是米，AI 如果混用了英寸或其他单位，尺寸会完全不对。

把这些信息反馈给 Codex，让它针对这一段修正。这样比让它凭空重写一版更精准。

7. 从能跑到跑稳：最后的经验清单

7.1 模块化是唯一可靠的方式

这次做天宫仙境，最大的体会是：AI 生成代码的能力很强，但场景规划能力仍然有限。如果你让 AI 一次性生成整个天宫，它会在中途搞混集合、重复创建物体、甚至把坐标算错。把场景拆成 6 个模块，每个模块单独脚本、单独验证，最后在 Blender 里合并，这种方式可靠得多。

7.2 日志和版本管理从一开始做

后台模式跑 Blender 脚本，日志很重要。我一般每个模块脚本都配一个同名 .log 文件，把 stdout 和 stderr 都重定向进去。出问题时直接看日志，不用重新跑一遍。

脚本文件本身也要做版本管理，用 git 或者其他版本管理工具都行。AI 每次生成的版本不一定更好，有时候上一版反而更稳定。留一个回滚入口，能省去很多重复生成的时间。

7.3 学会用“审美修正”收尾

AI 建模能做到“形似”，但很难做到“神似”。天宫的飞檐翘角、云海的层次、霞光的颜色，AI 生成的脚本不可能一次到位。这类内容建议分两步：

第一步，让 Codex 快速搭出结构，生成一个能被手动编辑的 .blend 文件。 第二步，打开 Blender，用快捷键手动微调重要物体的位置、旋转和材质。

AI 负责效率，你负责审美。这个搭配才是这套工具组合的正确打开方式。

最后说一句实在话：Deepseek + Codex 控制 Blender 这套流程，真正卡进度的从来不是“AI 会不会写代码”，而是你有没有把环境、skill、模块拆解和日志规范提前做好。把这些基本功补齐，别说天宫仙境，后续任何复杂场景都可以用同一套流水线往下推。