---

kicker: 技术方案 title: Sect Management作品 · 3D 资产生产体系 总体建设方案 cover_lines:

• Sect Management作品
• 3D 资产生产体系
• 总体建设方案

cover_sub:

• PC 端 · 窗口化 · Q 版低模（《部落冲突》风格）
• Sect Management + 挂机 + SLG

meta:

• 文档性质：整合总方案（资产标准 / 生成管线 / 工具设计 / 成本模型 / 执行计划）
• 核 心 形 态：2D 全自动接入 + 3D 人工网页订阅 + 文件为接口
• 版本：v1.0 整合版
• 日期：2026-09-16
• 状态：方案待评审，尚未投入实现

---

Sect Management作品 · 3D 资产生产体系 总体建设方案

项目：PC 端 · 窗口化 · Q 版低模（《部落冲突》风格）· Sect Management + 挂机 + SLG 文档性质：整合总方案（覆盖资产标准、生成管线、工具设计、成本模型、执行计划） 版本：v1.0 整合版 · 2026-09-16 状态：方案待评审，尚未投入实现

---

摘要 · 一页速览

核心架构：三段式，以文件为唯一跨系统接口。

资产描述 → [2D 生成] 全自动 → [3D 生成] 人工网页订阅 → [文件投放] → [规整导入] 全自动
             豆包 MCP              Hyper3D 网页版            inbox        Blender 脚本
             ¥0.2/张               ¥2.88/可用模型              唯一接口       免费

五个关键决策

关键数字

---

第一章 项目与产出目标

1.1 作品画像

1.2 技术路线（已定：路线 A）

《部落冲突》的技术真相是 2D 等距预渲染（3D 建模 → 渲染成 2D 精灵图），但本项目的选择是路线 A：真 3D 等距。

选 A 的理由：PC 端窗口化性能预算远比手机宽松；资产可复用性高，后续做换装、缩放、新建筑都方便；不必为每个资产渲染几十张图。

⚠️ 本方案全部内容基于路线 A。若日后改走路线 B，规整脚本与资产标准需重做。

1.3 资产需求概览

门派题材的特殊性：Poly Pizza 约 10,600 个模型以西方奇幻 / 现代 / 科幻为主，中式古建（飞檐、斗拱、琉璃瓦）、国风道具（香炉、蒲团、经卷）、国风装饰（松竹梅、石狮子、匾额）命中率明显偏低。

→ 结论与通用项目相反：门派题材下 AI 生成比例需要上调，而非下调。

---

第二章 总体架构

2.1 核心决策：三段式 + 文件接口

整个体系切成三段，分界线画在"哪里需要人"和"哪里需要独特能力"上：

段与段之间的接口只有一个：文件。

第二段与系统之间没有任何代码耦合——工具产出"交接包"（提示词文本 + 图片文件），人工拿去网页生成，下载所得 GLB 丢进 inbox/ 目录，系统从 inbox/ 继续。

2.2 为什么这样分：3D 不接入系统的四重理由

这个决策看似"退让"（放弃自动化），实际是同时拿到四个好处：

代价：3D 环节无法无人值守，需人工操作。这个代价用"抽卡免费"和"订阅低价"换回来了。

结论：老大的形态选择在成本与能力上都是最优的。

2.3 架构图

<!--SVG: _assets/arch.svg-->

2.4 人工职责边界

人工只做四件事，其余全自动：

自动完成：提示词拼接、2D 生成与抽卡、三视图裁切、交接包产出、inbox 监视、减面与清理、色板量化与顶点色烘焙、FBX 导出、成本记账、台账登记。

---

第三章 通道一 · 2D 生成（全自动）

3.1 通道说明

3.2 MCP 安装与配置

包信息（已核实存在于 npm）

关键能力（正对本项目需求）

• 文生图 + 图生图 + 参考图编辑
• 参考图支持 HTTP(S) URL、data URL、本地图片路径（本地路径很关键——三视图就存在本地）
• 生成图片立即保存到本地，规避临时 URL 失效问题
• 支持尺寸、模型/接入点、水印、组图模式
• API Key 不出现在状态、结果或日志中

推荐配置方式：本地安装 + 绝对路径

⚠️ Windows 踩坑预案：MCP 客户端不继承终端 PATH，必须写绝对路径，否则报 spawn ENOENT（此前在 uvx 上已实测踩过）。且 Windows 下用 .cmd 做 command 可能无法直接 spawn。

方式一（推荐）：本地安装后用 node 直跑

cd <项目目录>
C:/Users/Aowind/.workbuddy/binaries/node/versions/22.22.2-3/npm.cmd install seedream-mcp@0.1.1

{
  "mcpServers": {
    "seedream": {
      "command": "C:/Users/Aowind/.workbuddy/binaries/node/versions/22.22.2-3/node.exe",
      "args": ["<项目目录>/node_modules/seedream-mcp/dist/index.js"],
      "env": {
        "ARK_API_KEY": "<火山方舟 API Key>",
        "SEEDREAM_MODEL": "doubao-seedream-4-0-250828",
        "SEEDREAM_OUTPUT_DIR": "<项目目录>/work/01_concept"
      }
    }
  }
}

方式二（备选）：npx 方式

{
  "mcpServers": {
    "seedream": {
      "command": "C:/Users/Aowind/.workbuddy/binaries/node/versions/22.22.2-3/npx.cmd",
      "args": ["-y", "seedream-mcp@0.1.1"],
      "env": { "ARK_API_KEY": "<...>", "SEEDREAM_MODEL": "doubao-seedream-4-0-250828" }
    }
  }
}

配置后须在「连接器管理 → 自定义连接器」点「信任」并完成授权（与 Hyper3D MCP 同一流程）。

SEEDREAM_OUTPUT_DIR 建议显式指定 —— 不配置时会回落到 CODEBUDDY_PROJECT_DIR/seedream/，路径不可控。

3.3 五层提示词模板系统

核心设计：五层拼接。前四层全局固定，只有 L2 随资产变化。

[L1 风格前缀]  ← 全局固定
[L2 主体描述]  ← 用户输入，唯一变量
[L3 视角姿态]  ← 按用途切换（设定图 / 三视图）
[L4 技术约束]  ← 全局固定
[L5 负向约束]  ← 全局固定（Seedream 无 negative_prompt 参数，只能用自然语言写）

L1 风格前缀（示例，需按风格基准产出定稿）

极简Q版低模作品美术风格，等距视角，硬边平面着色 flat shading，
无平滑法线，几何体块化，轮廓清晰；参考《部落冲突》的建筑与角色造型语言；
主色板严格限定为：朱红#8C3A2B、赭金#C9A227、米白#E8DCC0、深木#6B4A2F、青灰#5A6B72；
光照为柔和顶部主光加环境光，明暗对比中等；画面干净、无噪点。

L2 主体描述（示例）

一座中式门派山门，单层，三开间，重檐歇山顶，朱红廊柱，匾额上书「XX门」

L3-a 设定图视角（阶段 1 用）

主体居中完整展示，正视微俯约15度三分之四视角，正交投影无透视变形，
主体占画面高度75%，四周留白。

L3-b 三视图（阶段 2 用）

生成该对象的正交三视图，分别为正视图、侧视图、背视图，
三个视图等大并排，纯白背景，无阴影，无投影，同一比例与朝向基准。

⚠️ 三视图必须正交投影。 若带透视，3D 生成会把透视变形当成真实形状学进去。

L4 技术约束

纯白色背景#FFFFFF，无地面，无投影，无场景元素，无文字水印，
模型边缘清晰锐利，便于抠图。

L5 负向约束

不要真实感渲染，不要写实材质，不要高清照片风格，不要景深虚化，
不要复杂背景，不要多余装饰物，不要人形比例失调。

模板管理：模板存放于 prompts/，纳入版本管理——模板是资产一致性的真正来源，改模板等于改全项目风格。

3.4 迭代式抽卡策略

一致性不能靠"固定提示词"或随机种子保证（详见 3.5），只能靠迭代收敛：

关键点：R2、R3 把上一轮胜出的图作为参考图传入。 这是把"盲抽"收敛成"迭代"的核心手法。

参考图参数

3.5 待实测：Seedream 4.0 是否支持 seed

为什么重要：若支持 seed，可通过固定种子 + 固定提示词获得高度相似的结果，一致性控制会大大简化。

当前证据冲突：

验证方法：请求体加 "seed": 42，连发两次，比对结果。

注意：即便支持，官方口径也是"相同 seed 会生成类似结果，但不保证完全一致"。故 seed 只是辅助，参考图锚定链才是主力。

---

第四章 通道二 · 3D 生成（人工网页 + 订阅）

4.1 通道说明

4.2 订阅方案决策

官方定价（2026-09-16 查官方定价页）

credit 换算关系（交叉验证得出）

• Creator：30 credits/月 → 60 模型/月
• Business：208 credits/月 → 416 模型/月
• 两者都是 1 credit = 2 模型，即 0.5 credit / 模型
• 与官方 API 文档的 Base Gen-2.5 generation = 0.5 credits 完全吻合 ✓

推荐：Creator 年付 $288

需实测确认：Redos: Geometry x20 的确切机制（是"免费重做 20 次"还是"额度上限"）。这直接影响抽卡空间。 额外发现：Creator 计划还包含 Seedream 免费额度（官方原文："Free Creator tier models - Seedream and default models"）以及 OmniCraft 的 HDRI Generator 免费 8K、Texture Generator 免费下载、Image Enhancer 无限 2K/4K。前者可能覆盖部分 2D 成本，后两者对作品场景环境光与材质贴图有直接价值 → 具体额度待实测。

4.3 成本真相：为什么网页 + 订阅是最优解

这是整个方案最重要的一笔账。

单价对比（年付摊销）

但真正的差距在"可用模型单价"——因为抽卡是否扣费完全不同

假设按 5 次尝试得到 1 个满意模型：

差距 5 倍。 原因很简单：网页版抽卡不花钱，API/MCP 抽卡也花钱。

这就是"3D 不走 MCP、走网页"的成本依据。 加上 TAPose 与零集成成本，这个决策无可挑剔。

4.4 网页操作 SOP（人工照此执行）

工具产出的交接包应包含：

人工步骤：

抽卡的正确姿势：在第 5 步反复生成直到满意，不满意直接丢弃重新生成，不要点确认。这是"零成本试错"的用法。

4.5 网页版参数建议

网页工作区支持完整的参数集（比 MCP 的 6 个参数丰富得多）：

---

第五章 接口点 · 文件投放规范

5.1 inbox 机制

inbox/ 是系统与 3D 生成之间唯一的接口。工具监视该目录，任何新出现的 GLB/FBX 自动进入规整流程。

这个设计的价值：将来换任何 3D 生成工具（腾讯云、本地模型、外包建模），只要产物丢进 inbox/，系统行为完全不变。

5.2 命名规范（关键）

命名是自动推断资产类型的唯一依据，必须严格。

格式：<类型前缀>_<资产名>_<序号>.glb

示例

bld_shanmen_01.glb        山门
chr_zhangmen_01.glb       掌门
prp_xianglu_01.glb        香炉
dec_denglong_01.glb       灯笼
env_caodi_01.glb          草地

既有脚本已实现 --auto-role，支持中英文关键词推断（实测 13 用例全通过）。但前缀命名比关键词猜测更可靠，建议人工下载时即按规范命名。

5.3 元数据 sidecar（可选但推荐）

抽卡过程会产生大量信息（用了哪个候选、第几次尝试、实际参数）。建议对每个入库文件附一个同名 .json：

{
  "asset": "shanmen",
  "role": "building",
  "channel": "web",
  "generated_at": "2026-09-16T15:30:00+08:00",
  "tier": "Gen-2.5-Medium",
  "mesh_mode": "Quad",
  "target_faces": 8000,
  "prompt_ref": "prompts/entries/shanmen.txt",
  "attempt": 3,
  "credits_consumed": 0.5
}

作用：成本归集、参数复现、问题追溯。

---

第六章 通道三 · 规整与导入（全自动）

6.1 执行方式

python blender_unity_prep.py --batch ./inbox --outdir ./export/unity_fbx \
       --preset clash-style --auto-role --flat \
       --palette config/palette.json --bake-vertex-color --strip-textures

（--palette / --bake-vertex-color / --strip-textures 为 B 路线新增参数，见 8.4）

6.2 既有脚本能力

blender_unity_prep.py（已在工作区，725 行，逻辑经 mock 测试通过，尚未在真实 Blender 实机运行）

clash-style 预设的五种角色预算

6.3 验证闸门

首次只跑 3~5 个资产，在 Unity 里确认尺寸 / 面数 / 顶点色显示正确 / 朝向均正常，并用 Frame Debugger 确认多个资产确实合批（Draw Call 未随资产数线性增长），再全量批处理。

合批验证是 B 路线的成败判据：若合批不成立，B 相对 A 的唯一优势就消失了，须回退检查 shader 与材质共享方式。

---

第七章 辅助来源 · Poly Pizza

约 10,600 个免费低模，单文件 .glb，需在 poly.pizza Apply免费 API key。

与 AI 资产混用的关键：Poly Pizza 上不同作者风格差异极大（写实、卡通、像素、极简都有），必须过同一套规整流程 + 色板归并才能混用，否则一眼看出"这件是买的、那件是生成的"。

---

第八章 资产标准

8.1 面数预算（三角形）

本项目采用保守的 clash-style 预设（道具 400 / 装饰 600 / 建筑 2000 / 角色 2500 / 地块 2000），远低于 PC 上限——因为挂机 + SLG 同屏数量大，且需为 LOD 与后续扩展留余量。

8.2 尺寸规范

1 Unity unit = 1 米。

8.3 色板（风格一致性的第一道闸）

定死 12~16 色主色板，所有资产（含 Poly Pizza 的）事后统一到该色板。

{
  "name": "menpai_v1",
  "colors": {
    "roof_tile":    "#8C3A2B",
    "roof_ridge":   "#C9A227",
    "wall_plaster": "#E8DCC0",
    "wood_beam":    "#6B4A2F",
    "stone_grey":   "#5A6B72",
    "jade_green":   "#4E7A5E"
  }
}

8.4 材质路线：B · 统一顶点色（已定）

术语消歧：本节的「B」是材质路线编号（B = 统一顶点色，A = Shaded 直接落地）；与摘要决策 1 的「技术路线 A」（真 3D 等距 vs 2D 预渲染精灵）是两套独立编号，勿混读。

决策：采用 B 路线——最终交付形态为「无贴图 + 顶点色 + 单一共享材质」，以换取色板统一、可合批、省贴图内存。放弃 A（Shaded 直接落地）。

⚠️ 实施前必须澄清的一处参数语义

material=None 是交付形态（最终产物不带贴图），不是传给 Hyper3D 的参数。

若真按字面把 material=None 传给生成端，模型将完全不带颜色信息，Blender 端「量化到色板」就失去了输入——没有原始颜色可供归并，色板一致性无从谈起。

正确的参数组合：

即：用 Shaded 取色，用 Blender 转成顶点色。最终产物仍是「无贴图 + 顶点色 + 单材质」，与 B 的目标完全一致，但颜色信息得以保留。

官方定义依据（2026-09-16 查证 fal.ai / pixazo 的 Rodin v2.5 参数文档）：

texture_delight 官方定义：removes baked-in lighting and shine from the texture, giving a flat, neutral surface that's easier to relight or edit。它与 Shaded 不是互斥，而是修正：Shaded 自带烘焙光，texture_delight 恰好剥掉，得到 flat、中性的纯 albedo。

结论：material=Shaded + texture_delight=true 是 B 路线取色的精确最优组合——PBR 冗余、None 归零、All 浪费。此处曾有一处误判（认为二者"语义冲突"），经查官方定义后已修正。

B 路线四步（Blender 端，需扩展 blender_unity_prep.py）

顺序不可颠倒：减面必须发生在顶点色烘焙之前，且在减面时保护色区边界。顺序错了会出现颜色渗色（一个面被两个色区的顶点插值成中间色）。

与既有代码的关系（实施成本评估）：脚本已有 merge_materials_by_color()（约 40 行），其「从 Principled BSDF 读 Base Color → 量化 → 归并材质槽」的框架正是 B 路线的基础。需两处改造：

取色逻辑（color_key 读 Base Color）可直接复用，净新增工作量集中在「色板最近邻 + 顶点色写入 + 贴图剥离」三块。

收益（量化）

代价与规避

代价：颜色分辨率受顶点数限制——顶点色逐顶点插值，色块边界锐度取决于网格密度；减面过狠会使颜色区域粗糙。

规避（本方案的关键红利）：flat shading 恰好把这个缺点变成优点。扁平着色本就是硬边、色块分明的表现方式，顶点色边界与面边界天然重合，观感反而比贴图更"低多边形"、更贴合《部落冲突》风格。A 路线想营造的色块感，在 B 路线下是免费副产品。

唯一需要守住的红线：减面预算（8.1）与颜色分区粒度要平衡。若某资产的色区比面片还细，应上抬该资产的面数预算，而非牺牲色板一致性。

Unity 侧落地（不可遗漏）

8.5 Unity 导入设置

8.6 其他硬约束

8.7 性能优化优先级

对挂机 + SLG，Draw Call 比面数重要得多。

一个建筑 2000 面不算什么，但 50 个建筑 = 50 个 Draw Call 才是瓶颈；挂机作品要长时间稳定运行，内存与 GC 比峰值性能更关键。

优先级：合批 > 顶点色（已定，见 8.4） > LOD > 面数

图集路线未采用：图集方案仍需 UV 且占用图集空间，与 B 路线「贴图全部退场」的目标冲突；顶点色在做到合批的同时连贴图内存一起省掉，是同一目标下更彻底的路径。

---

第九章 工具设计

9.1 目录结构

asset_forge/
├── config/
│   ├── palette.json            # 色板 + 顶点色量化基准（12~16 色，见 8.4）
│   ├── recipes.json            # 各通道参数配方
│   └── budgets.json            # 成本闸门阈值
├── prompts/
│   ├── style_prefix.txt        # L1
│   ├── view_setting.txt        # L3-a
│   ├── view_orthographic.txt   # L3-b
│   ├── technical.txt           # L4
│   ├── negative.txt            # L5
│   └── entries/                # 各资产的 L2 描述
├── data/
│   ├── ledger.db               # SQLite 台账
│   └── cache/                  # 按 hash 缓存，防重复消耗
├── input/
│   └── assets.csv              # 名称 / 类型 / 描述
├── work/
│   ├── 01_concept/             # 设定图候选
│   ├── 02_final/               # 定稿
│   ├── 03_views/               # 三视图
│   └── 04_handoff/             # 交接包（提示词 + 图片）
├── inbox/                      # ← 人工投放，监视触发
├── export/
│   └── unity_fbx/              # 最终交付
└── forge.py                    # CLI 入口

9.2 模块职责

9.3 状态机与幂等

DRAFT → CONCEPT_GENERATING → G1_PENDING → CONCEPT_APPROVED
      → VIEWS_READY → HANDOFF_PACKED
      → [人工网页] → INBOX_INGESTED
      → PREPPING → G2_PENDING → DONE

幂等三原则

1. 提交前先查台账：同 (prompt_hash, recipe_hash) 已生成过则复用，不重复消耗
2. 交接包可重复产出：人工随时可重新拿提示词与图片，不触发任何计费
3. 断点续跑：任何阶段中断，从台账 status 恢复

9.4 CLI 设计

forge.py concept  --asset "山门" --desc "中式门派山门……" --role building --n 4
forge.py approve  --asset "山门" --pick 2          # G1 选图
forge.py views    --asset "山门"                    # 生成三视图
forge.py handoff  --asset "山门"                    # 产出交接包
forge.py ingest   --watch inbox                    # 监视人工投放
forge.py prep     --all --preset clash-style       # 批量规整
forge.py ledger   --report cost                     # 成本报表

---

第十章 成本模型

10.1 2D 成本（全自动段）

10.2 3D 成本（人工网页段）

方案对比

推荐 Creator 年付：3D 不接入系统，Business 的 API 权益用不上；60 模型/月足以覆盖首期与迭代。

10.3 首期投入测算（60 资产）

第二年起：若已有订阅，仅需续费 ¥2074；2D 成本按新增资产线性增长（¥2.6/资产）。

10.4 成本结论

订阅费是主要支出，2D 生成成本可忽略。 因此优化重点不是省 2D 的钱，而是提高订阅额度的利用率——即利用"抽卡免费"机制，在确认前充分试错，把每个 credit 都用在确定的成品上。

这与"抽卡免费"的机制相辅相成：抽得越多，摊到每个可用模型上的订阅成本越低。

---

第十一章 执行计划

11.1 分期推进

11.2 上线前验证清单

11.3 关键风险

---

附录 A · 核心参数速查

豆包 Seedream 5.0 Flash（2D · 2026-09-28 起为默认） POST https://ark.cn-beijing.volces.com/api/v3/images/generations · 模型 doubao-seedream-5-0-flash-260915 单价见 asset-forge/backend/.env 的 ARK_PRICE_PER_IMAGE · 输入图首张免费 · 失败不计费 · 参考图 ≤10 张 · 限流 500 张/分钟 🔴 不支持 sequential_image_generation（连 "disabled" 都回 400）⇒ 抽卡改走「N 路并发单图」 🔴 不支持 size="4K" ⇒ 预设只认 1K / 1.5K / 2K，或显式 宽x高（总像素 921,600~4,624,220） 实测（同区域同提示词）：4 张候选墙钟 14.3s（旧 4.0 组图 93.7s）· 单图 2K 11~15s · 1024x1024 原样出图 （旧值：doubao-seedream-4-0-250828 · ¥0.20/张 · 支持组图；seed 支持性仍未验，5.0 亦未验）

Hyper3D 网页版（3D） https://hyper3d.ai · 确认前免费生成 · 订阅制 Creator $288/年（60 模型/月）· Business $1152/年（416 模型/月） 1 credit = 2 模型（0.5 credit/模型） 角色必开 TAPose；geometry_instruct_mode 建议 faithful 材质（路线 B）：material=Shaded + texture_delight=true 取色 → Blender 转顶点色 material 四值：PBR（完整PBR贴图）/ Shaded（烘焙光+无PBR解析）/ All / None（仅几何、无颜色，勿用）

四个必须注意的坑

---

附录 B · 与既有文件的关系

---

核心判断：整套体系的形态是「2D 全自动接入 + 3D 人工网页订阅 + 文件为接口」。这个形态的价值不在"自动化程度"，而在用人工换取免费抽卡能力——网页版"确认前免费生成"的机制，使每个可用模型的成本降到 API 路径的 1/5；而"不接入系统"的克制，则让整个体系对 3D 生成工具的变更完全免疫。