如果你和我一样在游戏公司或数字内容团队里做过技术美术（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 按我给定的规格文件批量修改参数并跑回归。
• 以前资产入库要手填一张巨大的元数据表；现在代码直接根据生成日志写 Manifest，AI 还能帮我自动检查哪些字段缺失、哪些变体版本冲突。

核心变化是：自然语言成为了规则的第一载体，代码只是它的编译产物。美术描述意图，规则代码由AI生成，执行由Codex托管，我只需要在关键节点做判断。这才是这套管线真正"下一代"的地方。

2. Claude + Codex 的分工：一个负责想，一个负责干

2.1 为什么不用单一Agent全包

很多人会问，为什么不干脆让一个 Claude Agent 从头写到尾？我测试下来的结论是：单一 Agent 在超长任务里很容易丢失上下文，而且一旦产生错误设计决策，后续会沿着错的方向一路狂飙。

举个实际例子。我早期试过给 Claude 一个任务："请先帮我生成城市道路布局，再做沿街建筑，再生成贴图变体。"它确实一步步做了，但做到第30分钟时，最初道路布局里设定的坐标系是"Z轴向上"，后来的建筑脚本却假设"Y轴向上"——因为中间对话太长，模型把早期设定忘了。结果拼接出来，建筑整体躺在地上。这就是典型的"单点长上下文幻觉"。

所以我现在采用的分工模式非常明确：

• Claude 负责需要全局理解的架构设计、规则描述、类型定义。它上下文长，适合整体规划。
• Codex 负责需要反复执行的局部编码、重构、批量修改、测试修复。它更适合面对明确的、可拆解的任务单元，且反馈循环快。

2.2 分工模型和协作流程

这套流程我一般走四步，也是给小型团队做内部分享时最常用的演示流程：

1. 需求冻结：用自然语言写清"要生成什么资产、约束是什么、输入输出格式"。这个规格文件是后续所有AI工作的锚点。
2. Claude设计：让 Claude 根据规格文件设计模块拆分、数据结构、生成策略，并输出伪代码与关键函数签名。
3. Codex执行：把 Claude 设计好的模块级任务拆成独立小任务，交给 Codex 批量实现、跑测试、按报错循环修复。
4. 人工守门：每个阶段我只看"差异"和"验证报告"，不逐行盯代码。

这套分工听起来简单，但关键是"任务颗粒度"。Codex 最适合的任务是"修改某个函数"或者"给某个类加一个参数"，而不是"帮我把这套管线重构一下"。把任务拆到足够小，它才能稳定输出。而 Claude 的价值在于前期规划时把边界划清楚，避免后期被 Codex 的执行琐事淹没。

2.3 表格：角色分工与典型任务

这个表格是我每次拉新成员入职时必放的。它能快速让新人理解：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。具体做法是：

1. 我写好生成器的输入参数范围（每个物种的缩放区间、旋转区间、密度权重）。
2. Codex 读取 specs 里的 YAML 参数。
3. Codex 循环调用 generators 模块，每生成一批，就写一行日志到 assets/log/run_001.jsonl。
4. 渲染完成后，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 把规则从代码转成了自然语言+Schema，Codex 把执行从人工盯守转成了自动循环，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扛了。这个方向，我还会继续往下走很久。