# World of Oldcraft 构建套件 —— 四个代理技能的分析总结

> 对象：`dot-claude/skills/` 下 4 个技能、22 个文件、约 90 KB 文本。
> 对应译文在 `zh/skills/` 目录，路径与原文一一对应。

---

## 一、总览：一个路由器 + 三个执行者

这不是四个并列的工具，而是一条**按生产阶段切分的流水线**。任何一个 3D 任务进来，先被路由技能分诊，再交给对应阶段的执行者。

| 技能 | 角色 | 负责阶段 | 产出 | 规模 |
|---|---|---|---|---|
| `3d-production-routing` | 分诊台 | 入口，全流程 | **不产生素材**，只决定走哪条路 | 38 行 |
| `character-sheet-pipeline` | 参考包生产 | 概念图 → 3D 生成**之间** | 严格正面 A-pose 部件包 + 360 视频 | 239 行 + 9 个提示词模板 |
| `blender-game-animation` | 绑定与动画 | 网格 → 引擎**之间** | 可编辑动画工程 + 验证过的 FBX | 129 行 |
| `fal-ai-generation` | 生成执行层 | 贯穿全程 | 所有 fal.ai 调用的统一出入口 | 78 行 + 3 参考 + 2 示例 + 队列脚本 |

四个技能共享一套底层资料：`processes/3d-ai/`（流程）、`knowledge/`（经验）、`projects/overlord/`（前项目档案）。技能本身只写"该做什么、按什么顺序、在哪设闸门"，具体操作细节全部外链到那些文档。

---

## 二、最重要的一条：整个系统的存在理由只有一个

`character-sheet-pipeline` 的自我说明开门见山：

> 这个技能解决的是图生 3D 管线里最难的一个问题：**让分别生成的部件还能拼回去。**

单张图生 3D 的模型（Tripo、Hunyuan、Rodin、Pixal3D）在**喂给它一张干净的严格正面 A-pose 图 + 孤立部件参考**时，效果远好于喂一张"英雄姿势的帅图"。但手工做出这套参考包，熟练的人也要 30–60 分钟。

这个技能把那 30–60 分钟压成"一次调用 + 三个人工闸门"。

理解这一点，后面所有看起来偏执的规则就都说得通了。

---

## 三、最高法则：严格正面，绝不 3/4

原文用了三段排比来钉这条规则：

> 每一个身体部件、每一个成对物件、每一个配饰，都必须在**正对镜头角度**生成，与严格正面 A-pose 朝向一致。
> **绝不**"3/4 外视角"，**绝不**"英雄角度"，**绝不**"好看的展示镜头"。
> 如果模型坚持要出 3/4，**就加强反 3/4 措辞重试。绝不交付 3/4 部件。**

给出的理由很具体：3/4 生成的部件和严格正面的部件**拼不回去**。缝对不上、衣服穿不上、帽子戴不上去。

### V3 的关键改进：把"祈祷"变成"验证 + 有界重试"

模型确实会偷懒出 3/4 —— 原文自己承认 "it will"。旧版本的做法是加强提示词措辞，但实测下来配饰仍然会漂。

V3（2026-05-19）加了 **Stage 4.5**：每一张严格正面输出在验收前，先过一个视觉分类器，对六个二元项逐项打勾：

| 检查项 | 含义 |
|---|---|
| `body_axis_dead_front` | 主体纵轴是否垂直于镜头（两侧等宽） |
| `no_three_quarter` | 是否完全没有前后之间的 3/4 旋转 |
| `no_body_twist` | 是否没有对立式平衡、胯部扭转、肩部扭转、头部相对胸腔转动 |
| `no_hero_angle` | 是否在平视眼高、零透视戏剧感 |
| `no_partial_back` | 是否**完全**看不到背面（能看见任何背面就不算严格正面） |
| `framing_clean` | 是否白底孤立、完整可见、关键几何没被裁掉 |

判定规则写成了决策树：

- 六项全过 → `pass`，接受
- 1–2 项轻微失败但仍可作正交参考 → `soft_fail`，接受但记警告
- 第 1、2、3、5 项**任一**明确失败 → `hard_fail`，拒绝并重试

### 有界重试：2 次上限，然后升级给人

| 轮次 | 动作 |
|---|---|
| 重试 1 | **同一个模型** + 升级措辞。把分类器给的具体理由前置："上一次尝试向镜头右侧旋转了约 25°；这一次**必须**正对。" 加强反 3/4 负面词，把 STRICT FRONT 提到全大写首句 |
| 重试 2 | **换备用模型**（Nano Banana 2）。理由写得很清楚：主模型可能在这个构图上卡死了 |
| 仍失败 | 停止循环，把三次尝试摆给用户，三选一：将就选一张 / 用自定义指令重试 / 跳过这个部件 |

每次判定的结果、理由、重试次数都写进 `manifest.json`，可审计。

**这是一个成熟度很高的设计**：把一个已知的、可复现的失败模式，从"靠提示词祈祷"变成"有检测、有重试上限、有降级路径、有审计记录"。

---

## 四、8 阶段 3 闸门：钱花在哪必须有人批

| 阶段 | 内容 | 闸门 |
|---|---|---|
| Stage 1 | 接收：读图，检测轮廓类型/画风/色板/性别年龄/配饰数量，给用户 2 行摘要**请求确认** | |
| Stage 2A | **母图**：严格正面 A-pose 全身图，2K，白底，中性平光 | |
| Stage 2B | **辅助三视图**：16:9，正/侧/背三个正交投影 + 配饰单独铺开标注 | |
| Stage 3 | 提出部件清单，分四类：`body-essential` / `paired` / `accessory` / `hair` | **▼ Gate 1** 用户确认提取哪些 |
| Stage 4 | 逐件提取，全部严格正面 | |
| Stage 4.5 | 视觉分类器验证 + 有界重试 | |
| Stage 5 | 逐件生成侧视图 + 背视图（渲染量翻倍） | **▼ Gate 2** 用户确认给哪些部件做多视图 |
| Stage 6 | **360 度转盘视频**（最贵的一步） | **▼ Gate 3** 先算积分报价，用户批准 |
| Stage 7 | 打包 + 写 manifest（源图 hash、模型+seed、积分成本、每次验证的判定） | |

三个闸门全部服务于成本控制。Stage 6 的原文是"360 视频是最贵的一步。计算积分：1 个全身 + N 个部件。把成本给用户看，**请求批准**。"

**注意三个闸门在 Oldcraft 里的落地问题**（详见第九节）。

---

## 五、模型路由：每一步都写了理由

| 阶段 | 首选 | 备用 | 为什么 |
|---|---|---|---|
| 2A 母图 @2K | **Nano Banana Pro** | Nano Banana 2 | 2K 正面正交参考下的角色一致性最强。**明令禁止**在这一步用 GPT-Image-2/2.5 |
| 2B 三视图 @16:9 | **GPT-Image-2.5** | GPT-Image-2 → Seedream V5 Lite | GPT-Image 系在"一张图里排多个分格投影并保持同一角色身份"上更强 |
| Stage 4 部件 @2K | **Nano Banana Pro** | Nano Banana 2 | **和 2A 同模型** —— 一致性优先于"每步都用最强的" |
| Stage 4.5 验证 | 宿主图像检查或已配置视觉 API | — | 本技能只提供评分标准，**不含**部署好的分类器服务 |
| Stage 5 多视图 | **Nano Banana Pro** | Nano Banana 2 | 同 Stage 4 |
| Stage 6 360 视频 | **Seedance 2.0**（orbit 模式） | Veo | 用户要求时可用 Kling |

技能里有一句关键的推理：

> **管线中途换模型会引入风格漂移，破坏下游的 3D 重建。**

所以宁可每步都用同一个模型。Stage 2B 是唯一例外，因为它只是"给人看的辅助图"，**不是部件提取的输入** —— 母图（2A）才是。

---

## 六、反模式清单：八条"绝不要做"

这部分和正面规则一样有价值，因为它记录了实际踩过的坑：

- ❌ **绝不**用 3/4 角度生成任何部件。模型会默认出 3/4，加强措辞重试，绝不交付。
- ❌ **绝不**给配饰拍"英雄镜头"。帽子和武器也要先出严格正面，侧背由多视图阶段补。
- ❌ 不要用随机姿势生成部件（比如提取武器时生成"角色拿着剑"）。武器必须**孤立、严格正面**。
- ❌ 不要加设定图上没有的背景、环境或道具。
- ❌ **不要用电影感光照** —— 原文的括号注释："*虽然更好看，但会把阴影烤进参考图，毁掉 3D 法线提取。*"
- ❌ 不要在闸门批准前生成 Stage 5 或 Stage 6。
- ❌ 不要跳过头发提取，除非用户明确要求跳过（**默认提取**，是 opt-out 而不是 opt-in）。
- ❌ 不要把成对物件合并成一张"双手"图 —— 左右可能不对称。要一起展示并标注，但必须处于**同一个严格正面角度**。

---

## 七、绑定与动画技能：核心是"三件事分开报告"

`blender-game-animation` 有一条统领性的收尾规则：

> **源动画批准、导出验证、引擎内实际集成，必须作为三个独立事实报告。**
> 在 Blender 里编辑片段，不等于接好了 Animator，也不等于接好了游戏内的伤害事件。

这条规则直接对应 Oldcraft 的四状态词表（implemented / agent-verified / pending owner review）。

### 硬性验收项

- 每个交付的 `.blend` 必须存成 **Material Preview + 中性棚光**，不能留 Workbench/Solid 贴图显示当最终审阅状态
- 烘焙 evaluated motion 到**独立的运行时骨架**，同时**保留可编辑控制骨架**
- 从**复制出来的目录**重新导入到干净场景验证 —— 否则贴图会静默地从旧目录解析
- 检查被静音的 library track、辅助骨骼、地面、相机**没有泄漏**进交付包
- manifest 写清：片段名、时长、循环标志、根位移、接触事件
- 对比评估后的样本姿势与已批准源动画（在统一坐标系下，且要处理 UV/法线接缝复制点）

### "Set Pose" 是硬性要求

每一次动画审阅都要提供：
- 已批准的 **Set Pose** 工具
- 命名真实的关节控制器
- 独立调整道具的能力
- **保存姿势参考 / 返回动画**的工作流

并且明确：**任何求解器或播放计时器都不允许覆盖手动摆的姿势。**

### 时间公式

```
duration = (last_frame - first_frame) / fps
```

配套警告："只改 fps 会改变运动速度；转换片段时要在时间上重采样。" 以及攻击接触帧在整体节奏缩放时要保持同一归一化比例。

### 反复重申的纪律："这是案例，不是默认值"

狼的 1.7 秒、接触比例 39/51、导出 4 个片段 —— 原文明确写：

> 这是**一个工作示例**。请从下一个任务里选择数值和命名，而不是把这些设置当作每个角色的默认值。

这条纪律在四个技能里反复出现，是整套文档最有价值的元规则之一。

### 默认交付的转身片段

每个新角色包**默认包含** Run Turn Left/Right 和 Idle Turn Left/Right（所有者 2026-09-17 的决定）。直立单位用已批准的 90 度 Idle 转身：更宽的后撤步，后脚离地前先有明确的躯干旋转（2026-09-18）。这些转身**从已批准的姿势派生，通常不需要新的运动参考**。

---

## 八、fal.ai 技能：本质是一个成本与恢复的管理器

在 Oldcraft 里 fal.ai 有 **100 美元硬上限**，所以这个技能的定位很明确：它不是"怎么生成得更好看"，而是"**怎么不重复花钱、怎么在被中断后还能接上**"。

### 五步运行法

1. **检查输入文件**，只上传这个任务需要的参考。托管的 MCP **读不到本地 Windows 路径**，必须走上传辅助脚本换 URL。
2. **按 live schema 组装参数**。`image_urls` / `image_url` / `aspect_ratio` / `image_size` / `resolution` / 时长 —— 每个端点都不同。原文："**不要给每个模型塞同一个参数对象。**"
3. 长作业优先 `submit_job`。**立刻**把 endpoint、request ID、返回的状态/结果 URL 和输入参数存到任务目录。
4. `check_job` 轮询 → `get_job_result` 取结果。
5. **先下载再依赖 CDN 链接。** 保留被拒的 take 连同原因。

### 恢复语义（这套说法是整个技能最实用的部分）

- `processing` **是正常态，不是失败**
- 等待超时**不授权**重复提交
- 提交没返回 ID 时，**先查请求历史**再重试
- `COMPLETED` 的结果里**仍然可能**藏着 provider 错误
- 技术完成与视觉验收**分开记录**
- 生成的网格仍然需要独立的 rig / 拓扑 / 导出检查

### 收据硬锁

`scripts/fal_job.py` 每个作业写一份 receipt（`job.json`），**已存在的 receipt 会阻止再次提交**。这是防止重复扣费的机械锁，不依赖代理记得。

### 凭据纪律

密钥绝不打印；凭据和原始签名链接**不得进入可分享的报告**。运行时密钥来自环境变量或被显式选中的 `.env`。

---

## 九、路由技能的三条全局纪律

`3d-production-routing` 只有 38 行，但它是四个技能里密度最高的。三条全局纪律：

**1. 先确立工件。**
参考图 / 生成网格 / 材质集 / 程序化模型 / 运动参考 / 可编辑动画 —— 这是六种**不同的工件**。原文：

> **生成了网格，不等于确立了蒙皮、游戏拓扑、烘焙贴图或可用的导出。**

**2. 模型标识按 provider 现场核实。**

> Higgsfield 的 job type 和 fal 的 endpoint name 是**两套不同的标识符**，即使它们可见的模型名很像。

提交前必须用所选 provider 查证。并且提醒："旧脚本的默认值、厂商技能的默认值，**都不能覆盖用户已经做出的选择**"。

**3. 凭据只来自被 git 忽略的根 `.env` 或 provider 自己的登录。**

还有一条共享边界值得注意：

> 出现在目录里，**不等于**获准发布用户的项目、媒体、账户历史或全部已装技能。

---

## 十、一个容易忽略的事实：这些技能不只为 Oldcraft 写的

文件里散落着这样的句子：

- fal 技能："**这个技能及其相对资源可以复制到另一个项目。**"
- fal 技能："这条**仓库专属**策略不会改变另一个接收方在技能被复制走之后的存储要求。"
- blender 技能："在原始仓库里维护链接的流程和教训。"
- routing 技能："准备交接时，使用共享流程。"

这些技能是从作者的主仓库里**抽出来复用**的，带着"被复制到别处也要成立"的设计意识 —— 哪些是通用方法、哪些是本仓库特有的策略，在正文里被显式标注出来了。

这也解释了为什么技能的相对链接指向 `../../../knowledge/` 和 `../../../processes/`：在原仓库里它们是同级目录，Oldcraft 套件把它们一起复制了过来，链接才仍然成立。

---

## 十一、与 Oldcraft 项目的适配度

| 技能 | 适配情况 |
|---|---|
| `character-sheet-pipeline` | **直接命中需求**。TASK.md §6.1 的要求就是"从已批准设定图做出严格正面 A-pose 图（加侧背视图），头发和武器单独提取"，并明确点名要遵循这个技能 |
| `blender-game-animation` | **直接命中需求**。对应 TASK.md §6.4–6.5 的绑定与动画路线 |
| `fal-ai-generation` | **可用且必要**。Oldcraft 首选 Higgsfield，fal 只做备选并带 100 美元硬上限 —— 这个技能正好是那个预算的守门人 |
| `3d-production-routing` | 可用，但它的默认上下文不是 Oldcraft，需要按项目调整路线表 |

### ⚠ 一处需要显式处理的冲突

`character-sheet-pipeline` 的设计前提是**交互式**的：它有三个需要停下来等用户答复的闸门（Gate 1 部件清单、Gate 2 多视图、Gate 3 的 360 视频报价），措辞是"**等待明确批准再继续**"。

而 Oldcraft 的 `CLAUDE.md` §2 写的是：

> 所有者不可用。**绝不提问，也绝不等待答复。**做出决定，把决定及其理由写入 `Docs/DECISIONS.md`，然后继续。

**这两条规则直接对撞。** 技能说"等批准"，项目规则说"绝不等待"。

Oldcraft 的 `character-sheet-pipeline` 技能文本其实已经打了一个补丁（"复用当前任务里已经给出的授权范围；检查点解决的是**新选择**，而不是把同一个问题再问一遍"），TASK.md 也有对应处理（把预算写死在文档里，由代理自行判断）。但这仍然是一条**需要代理在 M0 阶段主动裁决并记录**的规则冲突 —— 否则最坏的情况是代理卡在 Gate 1 等待一个永远不会来的答复。