Claude+Codex组合：把PCG美术生产管线变成可审计的代码流水线

最近大半年我一直在打磨一个自己挺满意的组合玩法让 Claude 负责把美术需求翻译成代码让 Codex 负责把这些代码真正嵌进项目仓库、跑通测试、提交改动。整套思路围绕一个目标——把 PCG/美术生产管线里那些又杂又碎、全靠人肉维护的活变成一条能自我检查、能回滚、能被 review 的流水线。这篇文章就把这套组合的拆解思路、实操步骤、踩坑心得一次讲完适合正在被程序化生成节点、批量资产工具、DCC 脚本折腾的技术美术和独立开发者参考。1. 内容整体设计与思路拆解1.1 传统 PCG/美术生产管线卡在哪里PCG 不是新鲜概念。Houdini VEX、Substance Designer 节点、Blender Geometry Nodes、Unity 里的随机摆放工具本质上都在做程序化内容生成。但真把一套节点图用到项目里会发现它有几个很难忍的毛病。第一个毛病是节点图无法真正被审计。美术师拖出来的节点网络看起来像一张漂亮的流程图实际运行时却是一张隐式依赖图。谁改了什么参数、为什么这个 Tile Sampler 要接在 Height Map 后面、某条 Group 规则到底过滤了哪些面全都没有留下可追踪的痕迹。项目改版三个月后回头维护旧资产基本只能靠猜。第二个毛病是规范只存在“关键 TA”的脑子里。每个项目都有自己的坐标单位、命名前缀、LOD 规则、碰撞通道、导出格式。这些知识很难写进文档因为太细碎更新太快。结果就是新人进来只能复制粘贴旧资产稍微调整就出错。第三个毛病是节点图和代码之间天然有断层。很多人以为 PCG 就是拖拖节点不需要写代码。但真正要落地的项目里一定有批处理、文件 IO、元数据写入、资产命名校验、CI 调度这些“胶水活”。这些活不适合用节点表达写脚本又没人愿意维护。所以我的判断是下一代 PCG/美术生产管线的核心不是做出更炫的生成节点而是把生成逻辑沉淀成代码资产。代码可以被版本管理、单元测试、Code Review、自动回归。而 ClaudeCodex 的组合恰好能把“把逻辑写成代码”这件事的成本压到很低。1.2 为什么偏偏是 Claude 和 Codex 这个组合很多朋友问我为什么不用一个全能工具或者为什么不让一个大模型从头干到尾。这里要先说清楚两个工具的定位差异。Claude 更擅长“理解需求、生成结构化内容”。给它一段自然语言描述它能产出逻辑清晰的函数、参数 Schema、用例列表甚至能帮你把丑得一塌糊涂的 Python 脚本整理成模块化结构。它的长上下文能力适合阅读一整份设计文档再动手。Codex 更擅长“在一个真实仓库里执行多步骤任务”。它能列出目录、读文件、改代码、跑测试、看报错再修复像一个能自己动手的实习生。给它一个清晰的 scope它能独立完成“实现函数 补测试 跑通 pytest 生成 PR”这条链路。单独用 Claude你会陷入“复制代码到本地运行报错再粘贴回去问它怎么改”的无尽循环。单独用 Codex你又会发现它面对开放式需求时容易跑偏把命名规范搞乱甚至顺手改掉不该碰的配置文件。我的实践是分阶段采样先用 Claude 拿到高度结构化的设计和伪代码再让 Codex 在受控的仓库里实现和验证。一个负责“想清楚”一个负责“做出来”。这个分工不光是效率问题更重要的是它让每一步都有产出物方便人工 review。2. 核心细节解析与实操要点2.1 美术生产管线里哪些环节真适合被 AI 编码不是所有美术环节都适合丢给 AI 写代码。先说结论四类环节最适合。第一类是批量导入导出与格式转换。比如一堆 FBX 需要统一单位、批量转 Y 轴朝上、重新生成碰撞体这类逻辑确定性极高只要把规则写清楚AI 生成的脚本非常可靠。第二类是元数据与命名规范管理。扫描资产目录核对命名前缀、贴图后缀、LOD 层级是否合规自动生成报告。这类场景非常适合写测试用例AI 生成代码的容错率也高。第三类是参数化配置层。把 Houdini 节点的大量 UI 参数抽成 JSON/配置表再让程序读取配置驱动生成。Claude 非常擅长把自然语言需求映射成 JSON Schema。第四类是 PCG 核心逻辑的骨架。比如面分布算法、随机种子管理、规则化安置、LOD 减面策略。AI 能生成能跑的初版但需要 TA 做美学调参和边界补充。不太适合 AI 直接生成的是材质通道的最终混合数值、灯光摆放、特效节奏这一类强审美判断的环节。你可以让 AI 生成候选方案但最终选哪版、调多少还是得靠人眼。下面是我自己整理的可 AI 化程度表当你决定把某个模块交给 AI 时可以对照参考管线环节AI 可编码程度主要原因建议切入点批量资源转换高规则固定、结果可验证先写转换脚本再补测试命名与元数据校验高逻辑简单、容易出报告先定义规则文档参数化配置生成高需要结构化输出让 Claude 直接生成 JSON SchemaPCG 分布与生成逻辑中高必须有可调参数和边界处理先做核心算法再抽配置材质视觉调优低强审美、强主观只让 AI 给候选人做终审灯光氛围设计低依赖场景上下文不推荐让 AI 自动改2.2 给 Claude 写项目上下文比通用 prompt 更重要的几个参数让 Claude 生成 PCG 代码时最忌讳的就是只丢一句话“帮我写个自动散布岩石的节点。”它大概率会给你一个能跑但完全不符合项目环境的脚本最后浪费时间。我习惯在每次生成前给它一份显式的项目上下文。核心包括目标 DCC 或引擎版本、坐标单位和轴向、命名规范、输出格式、异常处理要求、禁止使用的依赖。这些信息看似琐碎却能决定代码能不能直接落地。举个例子这是我的常用 prompt 模板你是一个 Houdini 技术美术助手。当前项目环境 - 宿主版本Houdini 20.0 - 坐标单位米Y 轴向上Z 轴朝向摄像机 - 命名规范节点名使用 snake_case属性使用小写加下划线 - 输出在不依赖第三方库的前提下生成一个可运行的 Hou Python 节点脚本 - 异常处理所有文件路径操作都需要 try/except并在失败时打印包含节点名称的错误信息 请根据下面这段需求先输出一份“关键决策清单”再输出完整代码 需求在给定网格表面按面面积散布碎石点生成顶点色高度扰动写入碰撞标签。注意我特意让它“先输出关键决策清单再输出代码”。这一步非常有价值。Claude 会把坐标轴、单位、属性命名、随机算法这些关键选择写出来我在确认它没有跑偏后再继续。如果它一开始就假设成 Z 轴朝上的左手坐标系我在决策清单阶段就能发现不用等到代码跑崩。另一个有效技巧是给 Claude 喂一小段现有工程代码作为上下文示例。哪怕只是几行命名风格类似的工具函数它的生成结果就会明显向项目风格靠拢。这个操作我屡试不爽。2.3 约束 Codex 的执行边界Codex 这类编码代理工具能力越强越需要划边界。我经历过它顺手改了测试依赖、把 requirements.txt 里的版本号升级、又重排了某个工具函数顺序的情况。改动本身可能没问题但你根本不知道它为什么改这种不可控感在美术生产管线里是致命的。我的做法是给 Codex 一份任务说明文件类似小型 PRD 加 scope 约束。这份文件放在仓库根的 docs/tasks/ 目录下Codex 每次行动前都会读到。内容包含三块目标文件清单、禁止修改清单、可执行命令清单。下面是一份实际用过的任务说明结构# Task: implement stylized rock generator ## Scope - target files: src/stylized_rock_generator.py - tests: tests/test_rock_generator.py - config: configs/rock_default.json ## Do NOT modify - requirements.txt - .github/workflows/*.yml - any file under tools/ or docs/ ## Allowed commands - python -m compileall file - python -m pytest tests/ -x ## Definition of done - generate_rocks() is importable - pytest passes - no changes outside scope把这份文件作为唯一事实来源后Codex 就不会再乱闯别的地方。我还把仓库权限设成只允许创建分支让它每次产出都走 PR人工 review 通过后才合入主分支。别嫌麻烦在美术生产管线上宁可慢一点也不要在周五下午收到一个悄悄改坏全局配置的“惊喜”。3. 实操过程与核心环节实现3.1 完整案例让 AI 搭一个风格化岩石 PCG 节点用一个实际案例串一遍完整流程。需求是这样的项目里美术师要频繁手摆岩石效率低且容易重复。我希望做一个 Houdini 节点输入一个基础网格自动在该网格表面按面积密度散布碎石点并生成带颜色和碰撞属性的输出。我先让 Claude 按前面 2.2 的 prompt 工作拿到的第一版核心代码长这样import hou import random import json def generate_rocks(source_node, output_node, params): 在目标网格表面按面面积散布碎石点输出带颜色属性的点云。 geo output_node.geometry() src source_node.geometry() prims src.prims() random.seed(params[seed]) # 收集所有三角形面中心作为候选位置 prim_areas [] candidate_positions [] for prim in prims: center prim.position() area prim.area() prim_areas.append(area) candidate_positions.append(center) total_area sum(prim_areas) rock_count int(total_area * params[density]) rock_count max(rock_count, params.get(min_count, 1)) # 按面积加权采样让分布更贴合视觉密度 chosen_indices random.choices(range(len(prims)), weightsprim_areas, krock_count) for idx in chosen_indices: pos candidate_positions[idx] scale random.uniform(params[scale_min], params[scale_max]) prim geo.createPoint() prim.setPosition(pos) prim.setAttribValue(rock_scale, scale) prim.setAttribValue(Cd, (0.2, 0.3, 0.4)) prim.setAttribValue(collision_marker, 1)这个版本能跑但它直接在函数里写死了属性名和颜色后续美术师要调参数就得改代码。这一步我不急着让它继续优化而是先把方案拿到 Codex 侧做落地验证。这里要说一下AI 生成代码的初版未必不好但它默认是“一把梭”式的写法参数全部藏在代码里这正是我前面说的传统管线痛点。所以后续一定要让工具继续做解耦。3.2 Codex 接入仓库并补测试我把 Claude 生成的脚本放进示例仓库后给 Codex 派了任务按任务说明实现模块、写测试、跑通 pytest。Codex 扫了一圈目录很快发现一个问题脚本直接 import hou但单元测试环境根本没有 Houdini 运行库。它把这个风险写进了 plan建议把“核心算法”抽成纯 Python 模块让 hou 相关依赖只在 DCC 运行时加载。这是我特别满意的一次操作。它没有硬着头皮去装库而是通过结构调整让核心算法可测试。修改之后的代码大致分成两层# rock_core.py import random def sample_by_area(areas, positions, density, seed): 纯 Python 实现依赖注入候选点和面积方便单测。 rng random.Random(seed) total_area sum(areas) count int(total_area * density) count max(count, 1) chosen rng.choices(range(len(areas)), weightsareas, kcount) positions_out [] for idx in chosen: pos positions[idx] scale rng.uniform(0.3, 1.8) positions_out.append((pos, scale)) return positions_out# test_rock_core.py from rock_core import sample_by_area def test_sample_count_by_density(): areas [1.0, 2.0, 3.0] positions [(0, 0, 0), (1, 0, 0), (2, 0, 0)] result sample_by_area(areas, positions, density0.5, seed42) assert len(result) 0 assert all(isinstance(r[1], float) for r in result)最终流程变成核心算法是纯 Python 模块可以跑单元测试Houdini 节点脚本变成薄薄一层只负责从节点参数读取 JSON、调用 core、写回属性。这个结构比 Claude 给同事手写的第一个版本健康太多。3.3 参数化配置化让美术师完全不碰代码管线要真正给美术师用必须把参数暴露成可视化配置而不是让大家在编辑器里改 Python 字典。我让 Claude 生成了一份用于描述配置结构的 JSON Schema再让 Codex 在仓库里实现“读取配置 → 校验参数 → 驱动生成”的模块。配置大概长这样{ asset_name: stylized_rock_03, seed: 42, density: 0.05, scale_range: { min: 0.3, max: 1.8 }, collision_tag: runtime_collision, output_fbx: true, lod_count: 3 }然后在 Houdini 的节点参数面板里绑定了关键字段美术师只需要动密度、随机种子、缩放范围这三个滑块。其他字段比如输出路径、LOD 数量统一走项目默认值避免大家改出格式不统一的资产。这里有一个特别重要的设计加入 dry-run 模式。勾选之后管线只打印生成日志和预计产出不真正创建几何体和文件。美术师可以先确认参数没问题再执行否则脚本在高密度参数下会生成十几万个点卡半天最后发现数值填错了。这类小问题手动写工具时经常被忽略AI 生成代码时更是容易遗漏。参数化做对之后美术师才愿意主动用。否则哪怕底层多智能Tool 界面难用就等于不存在。3.4 从单节点升级到批量生产管线单个节点跑通不算管线只有能批量调度、按时出结果、可以追溯的时候它才算生产工具。我把批量任务抽象成一个简单表格式驱动结构每个任务包含以下字段字段示例说明job_idrock_batch_01唯一标识asset_namestylized_rock_a资产名input_mesh/asset/mesh/rock_base.fbx输入网格路径seed17随机种子density0.08密度参数scale_range[0.3, 1.5]缩放范围output_dir/asset/output/rocks/a/输出目录metadataLOD3;tagruntime附带标签批量调度脚本会逐行读任务表调用之前写好的生成模块把每一条结果写进日志。日志格式统一为 JSON Line记录任务 ID、时间戳、参数哈希、生成点数、耗时、输出路径。这样出了问题可以一键回放把参数哈希取出来重新跑一次就能复现同一批结果。夜跑是我特别推荐的生产模式。白天美术师排队等结果晚上跑批次生成第二天早上只用看一张汇总报告。报告里列出成功、失败、异常资产再配合生成的缩略图墙审阅效率比逐个打开工程文件高太多。4. 常见问题与排查技巧实录4.1 代码能跑但生成结果完全不是美术要的效果这是最常见的挫败时刻。脚本没有任何报错点也多位置也对但看一眼就知道“这不是项目里那个风格”。原因通常不是算法错了而是美学目标没有被翻译成可调参数。Claude 无法看到美术参考图它只能靠你给的自然语言描述。所以要做的不是换一个 prompt 让它“更风格化”而是把风格差异拆解成可调项比如尺度分布是否更极端、点密度是否更稀疏、颜色是否有对比、是否保留边缘轮廓。我后来的习惯是每提一个模糊需求就让 Claude 先输出“可能影响视觉效果的参数清单”然后我人工把最有影响的三个参数暴露到配置里。这样美术师可以自己滑滑块找到目标风格而不需要求研究凌晨两点改算法。4.2 Codex 在仓库里改了不该改的文件Codex 执行力强但判断力有限。它看到一个工具函数不顺眼可能会顺手重写发现测试依赖缺失可能会直接在 requirements.txt 里加包。这些超出 scope 的改动轻则引入兼容性风险重则影响其他团队成员。规避方案有三层。第一层在任务说明文件里面写死“禁止修改清单”。第二层用只读权限加不直接合并主分支所有改动强制走 PR。第三层发现越界修改时直接 reset 掉相关文件把它改回原始状态再重新派任务。别嫌麻烦治住这一个问题后面能省出十倍时间。4.3 上下文太长Claude 后半段开始“失忆”当需求文档、代码规范、示例代码全部塞进一次对话Claude 往往在前半段很清醒越到后面越容易忘掉关键约束。比如前面说好了 Y 轴朝上它最后却在输出的代码里用了 Z 轴朝上。不要试图让一次对话解决所有问题。我的做法是分阶段第一阶段只生成接口定义和数据 Schema不写实现。第二阶段生成核心算法模块。第三阶段生成壳层和参数面板绑定。每个阶段之间我会人工确认一遍输出。这样做虽然多花几次交互但每个模块都能控制在小规模代码块内生成质量明显更稳。4.4 美术师反馈“还是不如手搓”如果美术师体验后说不好用先别急着怪 AI。多数情况不是生成效果不行而是反馈闭环太慢。手动摆石头看一眼就知道对不对用 AI 生成参数填完要跑几秒甚至几分钟结果出来不好看又要改参数重跑这种反馈延迟让人很难受。对应的解法是快速预览。我让工具生成一套低密度缩略结果几秒钟出预览图确认方向没问题后再用完整密度跑最终资产。同时保留“历史参数回放”功能每次生成的参数、种子、输出全部存档美术师可以对比不同版本的差异找到最好看的那个数字组合。当她能明确说出“上次那个参数再生成一版”就说明她真正信任这条管线了。5. 落地节奏与后续扩展5.1 成本可控别让模型调用费变成隐性黑洞长期跑 AI 编码是有成本的。我刚开始天天让 Claude 和 Codex 并行工作一个月发现调用量比想象中大得多而且很多是重复劳动。后来定了几条规矩。第一能复用的 prompt 模板绝不超过两天改动一次。第二大量生成的中间代码归入 Cache 机制同一需求直接命中黄金输出不重复调用模型推理。第三把所有模型请求按模块打上标签月末统计哪些模块花最多哪些收效最高把低效模块砍掉或人工维护。这样成本始终处在可控范围不会突然给团队带来惊吓。5.2 下一步可能扩展的方向管线跑顺之后我觉得这个模式还能继续向几个方向延伸。一是材质生成中的“逻辑参数”部分比如给材质生成噪声配置、遮罩组合候选。二是关卡布局初筛把规则写成 Python 校验器让 Claude 生成候选布局方案再用自动校验器过滤明显不合理的排列。三是美术资源构建后的自动化验证扫描贴图尺寸、法线方向、碰撞碰撞体数量AI 生成校验脚本我们只负责看结果。这些方向的核心套路其实是同一个把需求写清楚 → 让大模型生成结构化实现 → 让编码代理完成落地 → 用测试和日志保证可追溯。原理不变只是场景在变。我个人在实际操作中的体会是这一轮尝试最值钱的不是“AI 写代码真快”而是它逼着我把脑子里模糊的流程变成了显式的、可审查的、能回滚的逻辑。PCG 美术管线最缺的就是这种确定性。如果你也想试建议先挑一个自己最头疼的纯逻辑重复环节比如批量资产规范校验先跑通闭环再去啃程序化生成。只要把第一条流程跑顺了后续所有模块都会顺很多。