如果你和我一样在游戏公司或数字内容团队里做过技术美术TA或者程序化生成PCG方向应该没少听过这句话能不能让工具自己把资产做了过去听到这话我的第一反应是苦笑——程序化生成的思路没错可每一套生成规则的编写、调试、维护本身就要吃掉一个资深TA大量的时间最后往往变成写规则的比手搭资产的还累项目一赶又退回全手工。最近半年我开始认真用 Claude 和 Codex 这类 AI 编程智能体重整自己的工作流把自然语言规则描述直接转成可执行的生成代码再交给独立执行体去批量跑、批量改、批量验证。试过几个内部 Demo 之后我敢说过去的 PCG 管线最缺的不是算法而是规则的表达成本。AI 恰好把这块成本砍掉了一大截。这篇文章就聊聊我是怎么用 Claude Codex 搭出一套下一代 PCG / 美术生产管线的包括架构怎么拆、代码怎么组织、踩过哪些坑希望对正在折腾同类工具链的朋友有参考价值。1. 传统PCG管线为什么总是做出来没人用1.1 卡住PCG的不是生成算法而是规则表达成本很多团队一谈PCG第一反应是上Houdini或者用程序化纹理。但我的亲身体验是写规则和调参数才是最痛苦的部分。比如做地表植被散布密度、缩放、旋转随机范围得一条条调必须避开道路、水体和石头又得手写掩码采样输出资产带不带碰撞体、LOD、贴图集格式不同还得各写一套导出脚本项目改美术风格整套参数可能就要推倒重来。这些工作的本质是把美术想要的感觉翻译成代码逻辑。问题在于翻译成本太高了。美术口头说这里的草丛密一点、有点坡度变化TA 得想到多层噪声叠加、斜率阈值、密度衰减函数、朝向对齐……一句话背后是几十行代码和十几次迭代。这不是算法不够强而是规则的编写、调试、维护成本不划算。1.2 资产生产链条是割裂的不是一条流水线传统流程里程序化生成的生成环节往往和资产验证、入库、复用是断开的。生成完一批草丛、石头、破碎墙面大家发现不知道哪个变体对应哪套参数贴图格式有的带透明通道有的没带UV 重叠、翻转面、尺寸超限这些问题全靠人工在 DCC 工具里逐个查。换句话说管线断在生成与入库之间。无论规则写得多漂亮没有一套可靠的验证与分发机制生成出来的资产就只是硬盘里的孤儿文件。这也是为什么下一代的PCG管线重点不该只放在生成上而应该放在从生成到入库到复用的闭环上。1.3 AI改变的是整条链路的表达方式Claude 和 Codex 这类工具介入后变化最大的其实是表达方式以前我要手写计算区域内每个点的高度噪声、叠加倍频现在我可以直接描述需求让 Claude 生成对应 PyTorch3D / Blender 脚本我再审。以前改一个散布规则要动代码、跑测试、看渲染图现在我可以让 Codex 按我给定的规格文件批量修改参数并跑回归。以前资产入库要手填一张巨大的元数据表现在代码直接根据生成日志写 ManifestAI 还能帮我自动检查哪些字段缺失、哪些变体版本冲突。核心变化是自然语言成为了规则的第一载体代码只是它的编译产物。美术描述意图规则代码由AI生成执行由Codex托管我只需要在关键节点做判断。这才是这套管线真正下一代的地方。2. Claude Codex 的分工一个负责想一个负责干2.1 为什么不用单一Agent全包很多人会问为什么不干脆让一个 Claude Agent 从头写到尾我测试下来的结论是单一 Agent 在超长任务里很容易丢失上下文而且一旦产生错误设计决策后续会沿着错的方向一路狂飙。举个实际例子。我早期试过给 Claude 一个任务请先帮我生成城市道路布局再做沿街建筑再生成贴图变体。它确实一步步做了但做到第30分钟时最初道路布局里设定的坐标系是Z轴向上后来的建筑脚本却假设Y轴向上——因为中间对话太长模型把早期设定忘了。结果拼接出来建筑整体躺在地上。这就是典型的单点长上下文幻觉。所以我现在采用的分工模式非常明确Claude 负责需要全局理解的架构设计、规则描述、类型定义。它上下文长适合整体规划。Codex 负责需要反复执行的局部编码、重构、批量修改、测试修复。它更适合面对明确的、可拆解的任务单元且反馈循环快。2.2 分工模型和协作流程这套流程我一般走四步也是给小型团队做内部分享时最常用的演示流程需求冻结用自然语言写清要生成什么资产、约束是什么、输入输出格式。这个规格文件是后续所有AI工作的锚点。Claude设计让 Claude 根据规格文件设计模块拆分、数据结构、生成策略并输出伪代码与关键函数签名。Codex执行把 Claude 设计好的模块级任务拆成独立小任务交给 Codex 批量实现、跑测试、按报错循环修复。人工守门每个阶段我只看差异和验证报告不逐行盯代码。这套分工听起来简单但关键是任务颗粒度。Codex 最适合的任务是修改某个函数或者给某个类加一个参数而不是帮我把这套管线重构一下。把任务拆到足够小它才能稳定输出。而 Claude 的价值在于前期规划时把边界划清楚避免后期被 Codex 的执行琐事淹没。2.3 表格角色分工与典型任务阶段负责工具典型任务交付物需求描述人 Claude资产类型、约束、风格参考自然语言规格文档架构设计Claude模块划分、数据Schema、参数定义伪代码 类型定义 Schema功能实现Codex按函数实现生成逻辑、导出脚本可运行代码模块批量执行Codex跑大规模变体生成、渲染回归生成资产 日志验证修复Codex 人根据错误日志修复、补充测试CI 报告 修复补丁入库管理ClaudeManifest校验规则、版本冲突检测Manifest JSON 校验脚本这个表格是我每次拉新成员入职时必放的。它能快速让新人理解AI不是来取代谁而是承担了翻译和搬运工人的工作重心转向意图定义和结果判断。2.4 选型背后的三个理由第一条是容错隔离。Claude 一旦设计错了产生的是架构级的错这种错后期很难修所以要用人审环节压住Codex 如果实现错了通常只是局部函数错跑一次测试就能暴露容错成本低得多。第二条是成本和速度。Claude 的超长上下文和高频调用都会拉高成本不适合做几百轮的反复跑批Codex 更适合穿插在命令行里做细碎改动成本更可控。第三条是执行闭环。Codex 能直接落地成一个可执行体跑测试、看报错、改代码、再跑这个循环可以脱离人工。Claude 更擅长的是一次性生成设计文档它不适合也不擅长做这类需要持续跟踪状态的执行任务。3. 实操从零搭一套AI驱动的植被散布管线3.1 我们以什么作为Demo我不建议一上来就搭整套城市生成或地形系统太复杂容易翻车。我实际建议从程序化植被散布开始因为资产生成逻辑足够简单撒点旋转缩放碰撞体贴图分配但又覆盖了PCG管线的所有核心环节规则描述、生成、变体、验证、入库。下面这个 Demo 就是我这套管线的最小可用原型。目标是给定一片地形网格和若干物种定义自动生成一组带有合理分布、自然旋转、碰撞体、元数据扎口的植被资产。3.2 项目目录与模块划分目录结构我一开始就设计得比较规整因为后续让 Claude 读代码写设计、让 Codex 按模块改功能都需要清晰的边界。pipeline/ ├── specs/ # 自然语言规则与Schema定义 │ ├── vegetation_spec.yaml │ └── asset_schema.py ├── generators/ # 各类生成器 │ ├── scatter.py # 撒点与密度控制 │ ├── transform.py # 旋转、缩放、缩放抖动 │ └── collider.py # 碰撞体与LOD生成 ├── bake/ # 渲染与贴图烘焙 │ └── render_batch.py ├── verify/ # 资产校验 │ ├── check_uv.py │ └── check_scale.py ├── manifest/ # 元数据入库 │ ├── build_manifest.py │ └── validate_manifest.py └── run_batch.py # Codex执行入口这个结构的好处是Claude 读一遍 specs 和 generators 就能理解全局Codex 接到任务时也能快速定位要改哪个文件不至于在巨大仓库里迷路。3.3 规则表达的Schema设计我们让 Claude 根据美术给的自然语言描述生成一套 AssetSchema。以植被为例最终得到类似这样的定义dataclass class VegetationInstance: asset_id: str species: str position: tuple[float, float, float] rotation_euler: tuple[float, float, float] scale_uniform: float seed: int material_slot: str lod_levels: list[str] collider_type: str # none | box | sphere | mesh这套 Schema 是整个管线的心脏。所有生成器只负责产出 VegetationInstance 列表渲染器只消费这个列表Manifest 也只记录这个列表的校验结果。边界清晰之后Claude 和 Codex 就可以在不互相踩脚的情况下并行干活。3.4 生成核心逻辑与AI协作点撒点逻辑我直接用简化的重心Voronoi 密度掩码核心代码大概长这样def generate_scatter_points(terrain_mask, density_map, rng, seed): points [] height, width terrain_mask.shape for y in range(0, height, 2): for x in range(0, width, 2): if terrain_mask[y, x] 0: continue density density_map[y, x] if rng.random() density: points.append((x, y)) return points这段代码很简单但实际开发里真正复杂的部分在于密度如何定义。我给 Claude 的提示词是生成一个函数根据地形斜率、湿度缓冲区和道路距离计算散布密度。密度在斜坡处降低在湿润低洼处提高道路两侧5米内清零。Claude 给出的密度计算公式结合了三层噪声和距离场我审了一遍逻辑没问题就直接用了。如果没有AI这一段的调参我自己可能要折腾一整天。有了AI我只需要描述清楚密度随哪些因素变化、变化趋势如何。3.5 Codex批量生成变体和渲染等到生成函数稳定后我会把批量生成500个植被变体这种任务交给 Codex。具体做法是我写好生成器的输入参数范围每个物种的缩放区间、旋转区间、密度权重。Codex 读取 specs 里的 YAML 参数。Codex 循环调用 generators 模块每生成一批就写一行日志到 assets/log/run_001.jsonl。渲染完成后Codex 检查日志里的失败条目自动重试或者标记异常。这一步里 Codex 最大的价值是闭环执行。它会自己跑测试、看报错、改代码、再做回归。我只需要在关键节点上检查渲染出来的贴图资产目录是否正常。4. 元数据驱动的资产库让PCG资产真正被用起来4.1 资产生成了然后呢很多PCG项目死在资产生成了一堆但美术不愿意用这个环节上。原因不外乎不知道哪个文件对应什么参数贴图格式混乱不知道LOD和碰撞体是否完整。我的解法是把元数据Manifest变成管线的一等公民——生成资产的同时强制生成可追溯的元数据并且由校验脚本保证它和实际资产完全一致。资产入库时Manifest 大约长这样{ asset_id: veg_pine_001, species: pine, params: { density_factor: 0.75, scale_min: 0.8, scale_max: 1.4, rotation_jitter: 12.0, seed: 20240315 }, variants: 36, lods: 3, formats: [fbx, glb], collider: sphere_radius_0.6, created_by: pipeline_generated, source_pcghash: 8f2e93ba1c }这样做的好处是任何人拿到一个资产文件都能通过 Manifest 反查它是哪条规则生成的、用了什么种子、有哪些变体、碰撞体多大、未来如果规则变了能不能安全重建。4.2 AI在元数据环节的两个重要角色在这一环Claude 和 Codex 的分工也很清楚Claude 负责设计Schema与校验规则。比如它会根据我的提示词生成资产必须包含3级LOD尺寸范围在0.5到2.0之间碰撞体类型不能为none这样的校验逻辑。Codex 负责写校验脚本的每个用例比如检查 UV 是否重叠、检查每个文件是否在 Manifest 里有对应条目、检查是否有孤立资产没入库。在实际执行中Codex 会跑一个命令python manifest/validate_manifest.py --manifest manifests/veg_run_001.json --assets assets/veg_001看到输出里有异常条目它就自动去修复代码或调整 Manifest整个循环非常顺。以前人要盯着所有资产文件头大现在 AI 把检查和修复的循环吞掉了。4.3 资产变体链的设计思路一个值得分享的设计是变体链Variant Chain。不是简单把种子改了生成一堆看起来差不多的资产而是把基材资产生成之后沿一条固定路径做衍生基础网格 → 材质分配5种颜色方案 → 法线贴图合成3种强度 → LOD减面3级 → 碰撞体生成 → 输出格式转换FBX/GLB。每一步输出都作为下一步输入并在 Manifest 里记录父子依赖关系。这样当我只需要改颜色的明暗曲线时不用重新跑完整条链只跑材质那一环即可。这种拆法也特别适合 AI 分步执行——Claude 设计这个链的关系Codex 按链路顺序逐环跑每一步都有清晰的输入输出。4.4 为什么说这是下一代的关键下一代不是指AI 全文替我把资产画好——以目前的生成精度直接让 AI 凭空产出可用游戏资产还是不现实。下一代体现在规则可描述、过程可审计、资产可追溯。Claude 把规则从代码转成了自然语言SchemaCodex 把执行从人工盯守转成了自动循环Manifest 把资产状态从一团混乱转成了结构化数据。三者结合才让生成资产真正变成生产资产。5. 实测中的坑AI管线的五个翻车点与应对5.1 AI会偷偷改掉不该改的代码这是所有AI编程工具的通病。有一回我让 Codex 修复散布密度算法它改完函数之后顺手把 render_batch.py 里的输出目录前缀也改了。理由是它觉得统一更合理。这种自作主张在美术生产管线里非常致命——你可能根本没察觉渲染完才发现所有资产路径变了Manifest 全对不上。我的应对是强制审查差异每次 AI 修改完代码我不直接合入而是用git diff快速浏览改动。如果发现不属于当前任务文件的改动直接让它撤销并明确下一条指令里加一句只允许修改 xxx 文件其他文件绝对不要碰。给 Claude/Codex 下任务时一定把改动范围写死。宁可指令啰嗦也不要让AI自由发挥。5.2 长任务跑一半上下文丢了Codex 长时间跑批时偶尔会出现一种情况任务刚开始它还遵守规格文件里的约束跑了 20 分钟之后它似乎忘了规格里的某个限制开始生成不符合要求的资产。比如要求石头的缩放区间是0.8-1.2某批结果却有 0.3 和 3.1 这种离谱值。这个问题的根源是长任务里的上下文漂移。我的解法是把大型任务拆成每1000次生成为一批每批之间重置上下文并且每批的输出都必须带一个 summary 日志。Codex 再次执行时会重新读 summary 而不是靠上下文记忆。5.3 资产验证不能靠AI看一眼刚开始我试过让 Claude 直接看渲染图判断资产质量效果很飘。AI 视觉判断适合粗筛但UV是否重叠碰撞体是否穿透地形模型是否超出尺寸上限这类精确问题AI 看图经常漏检。后来我把所有硬性指标写成一个验证脚本由 Codex 执行UV 检查是否有 UV 超过 [0,1] 区间尺寸检查包围盒是否超过指定范围LOD 检查各 LOD 三角面数是否在设定区间碰撞体检查碰撞体类型是否与 Manifest 声明一致。跑完只输出 PASS/FAIL 列表FAIL 的直接进修复通道。经验是AI 适合写验证脚本不适合当验证器。把验证标准写进代码可复用、可审计、不抽查比让 AI 看图靠谱一个数量级。5.4 Token消耗失控这是成本问题。Codex 批量跑的时候如果任务描述不清它会在同一个错误上反复试错Token 消耗非常快。有一回我让它修复一个法线贴图合成参数它连续重试了 18 次原因只是错误的日志格式让它没识别到已修复。控制方法每轮任务代价设上限让 Codex 每改一次就输出标记成功的可解析日志遇到超过3次重试仍失败的任务直接停掉人工介入而不是继续烧Token。说白了AI 不是越跑越聪明遇到它反复失败时该换的是人的指令不是它的运气。5.5 美术和TA的角色变了要先想清楚最后一个坑不在技术而在人和流程。AI 介入后TA 的工作从写规则变成了描述规则 审核规则美术则从画资产变成给参考和反馈。如果团队的流程没有跟着调整AI 工具很容易变成只有TA一个人自嗨的口袋工具。我给团队的建议是每个AI生成模块必须配一个自然语言的意图文档。让美术能看懂这条例规则在做什么、能调整哪些语义化参数。不要一上来就追求全自动管线先把一个小环节跑通让美术看到我改一句话资产流就能整体变化这个信任感建立起来之后整个管线的推广就顺了。6. 说在最后给想尝试的人三条实际建议如果读到这里你打算在项目里试试这套玩法我有三条实在话第一条永远从一个小资产品类开始。不要想着第一个版本就做全自动城市生成。从植被、碎石、贴花这类规则简单、验证标准清晰的资产入手跑通自然语言 → Schema → 生成 → Manifest → 校验这一圈再横向扩展到复杂品类。我见过一上来就搞大场景的项目AI生成的规则互相打架根本无从调试。第二条把可验证性当第一优先级。AI生成代码最大的风险是看起来对了实际错了。你的管线里至少要有三分之一以上的逻辑是验证逻辑而不是生成逻辑。宁可生成器简单一点也让校验脚本覆盖每个资产的关键指标。否则AI越努力资产库里垃圾越多。第三条不要把AI当能自己干活的实习生要当一个手速极快但需要明确边界的外包。每次发任务前写清楚范围、约束、验收标准任务完成后检查差异验收不通过就退回。这套流程坚持两周你会发现自己团队的PCG管线开发速度快到之前不敢想象。我自己测试下来最大的感受是这套东西没有直接替我把资产做完但确实替我省掉了大量翻译和搬运的时间。以前我要把美术的话翻译成函数把函数跑成资产把资产手工入库现在我只需要确认需求、抽查结果、维护规则边界剩下的脏活累活都让AI扛了。这个方向我还会继续往下走很久。