构建工具箱 · 逆向分析报告

World of Oldcraft 构建工具箱

这是从 WorldOfOldcraft-build-kit.zip 解出的全部内容。
它不是一个成品游戏,而是一套交给 AI 代理、让它独自在长会话里从空 Unity 工程造出一款魔兽风格 MMO 可玩切片的启动套件:任务书、工作规则、强制不停机的钩子、四个生产技能、上一个项目沉淀的经验库、辅助脚本,以及定义最终画面长什么样的已批准概念图。

压缩包 50.2 MB
解压后 49 MB
文件 224
概念图 154 webp
文档 47 md
脚本 9 py + 4 ps1
已批准概念 25
候选概念 129
风格参考 70(未随包)

01一句话结论

先把最重要的事说清楚:这个包能给你什么,不能给你什么。

0 行
游戏代码 —— 包里没有一行 C#、没有一个 Unity 场景
0 个
3D 资产 —— 无 .fbx / .blend / .glb,所有模型都要现场生成
0 把
密钥 —— 不包含任何 API key,FAL_KEY 要自己填
这是一份"开工前的工地"

箱子里的东西分四层:要做成什么(Docs/TASK.md,31 KB 的完整规格)、怎么做(CLAUDE.md,10 条硬规则)、怎么让代理别停下来(dot-claude/ 里两个 Python 钩子)、以及做出来的东西该长什么样(Docs/concepts/approved/ 25 张已经人工挑过的概念图)。

目标产品是什么

《World of Oldcraft》——一款用 Unity 6000.5.9f1 + URP 做的经典奇幻 MMORPG 可玩 MVP。美术定位原文是"经典 World of Warcraft(2004),重制版":同样风格化的手绘世界、同样略带棱角的低多边形造型与夸张体态、同样的界面布局,只是更清晰漂亮。项目自述为非商业粉丝作品、单机、无服务器无联网。核心诉求一句话:2005 年玩过 WoW 的玩家,必须在五秒之内感到宾至如归。

规模预期

维度规格
地图约 1 × 1 km 地形;主路 800–1200 m,徒步穿越 3–5 分钟
可玩身体6 种族 × 男/女 = 12 个,共享一套动画
等级1–5 级
职业6 个,每族绑定一个;每职业自动攻击 + 2 个技能(P0)+ 第 3 个(P1)
性能目标1440p 城内 ≥ 60 FPS
画布预算角色 12–25k 三角面;怪物 4–12k;主建筑 ≤ 30k;道具 0.3–5k;树木 2–8k
贴图主角/主建筑 2K,道具 1K,小道具 512
耗尽预算fal.ai 硬上限 100 美元;Higgsfield 约 10,000 积分(首选生成器)
它想解决的真问题

真正难的不是"生成一个模型",而是让代理在几十小时、几十次上下文压缩之后还记得自己在干什么、还不跑偏、还不停机。这个包里最有价值的设计恰恰不是任务书,而是那套把状态强制写进磁盘、把会话锁死不让人停的机制(见 05)。

02工具箱构成

224 个文件的完整分布,以及它们被安装到 Unity 工程的哪个位置。

文件类型分布

webp 概念图 154 markdown 文档 47 python 脚本 9 json 配置/清单 7 powershell 4 文本 3

按体积算反过来:图片占 48 MB / 49 MB,全部文字加起来不到 1 MB。这是一个视觉资产包,文档是附件。

目录结构

WorldOfOldcraft-build-kit/ ├── CLAUDE.md 10 KB — 代理的工作规则,10 条,全文最强制的一份 ├── KIT_README.md 8.6 KB — 给人看的安装与使用说明 ├── KIT_CONTENTS.json 清单:4 skills / 24 docs / 3 scripts / 2 类需下载项 ├── install_kit.ps1 6.9 KB — Windows 安装器 ├── mcp.json · env.example · requirements.txt │ ├── Docs/ │ ├── TASK.md 31 KB — 完整任务书,19 个章节 │ ├── KICKOFF.md 4 段可直接粘贴的提示词:启动/恢复/报进度/收尾 │ ├── PIPELINE_LESSONS.md 23 KB — 早期项目的血泪教训浓缩 │ ├── refs/ │ │ └── manifest.json 70 条风格参考的元数据 —— 图片本体不在包里 │ └── concepts/ │ ├── approved/ 25 张概念图 + README — 视觉权威 │ └── candidates/ 129 张全部生成稿 — 选型过程的化石层 │ ├── dot-claude/ 安装后重命名为 .claude/ │ ├── settings.json 注册 Stop 钩子与压缩后钩子 │ ├── hooks/ keep_working.py(不许停)· after_compact.py(重锚定) │ └── skills/ 4 个技能,22 个文件 │ ├── 3d-production-routing/ 分诊路由 │ ├── character-sheet-pipeline/ 角色原画 → 生成参考,8 阶段 3 闸门 + 8 个提示词模板 │ ├── blender-game-animation/ 绑定 → 动画 → Unity 交付 │ └── fal-ai-generation/ 生成执行层 + 预算守门 + fal_job.py │ ├── knowledge/ 9 篇 —— 来自前一个项目 Overlord 的经验沉淀 ├── processes/ 9 篇 —— 3D/AI 生产线流程 + 视频存储纪律 ├── projects/overlord/animation-workflow/ 6 篇 —— 前项目的动画流水线交接档案 ├── scripts/ Mixamo 下载 · 参考图抓取 · 批量生图 · GLB 居中 · 延时摄影合成 └── host-tools/ 3 个 PowerShell —— 给"人"用的桌面延时摄影,不归代理管

安装后落到哪里

包内路径安装到作用
CLAUDE.md工程根代理每次启动/压缩后第一个读的文件
dot-claude/.claude/钩子 + 技能,随工程走
mcp.json.mcp.jsonUnity / Blender / Higgsfield 三个 MCP 服务器,路径由安装器填充
env.example.env安装器唯一拒绝覆盖的文件
Docs/refs/manifest.json同左安装器据此联网抓 70 张参考图
scripts/animation/同左安装器据此联网下载 90 条 Mixamo 动画到 Assets/_Source/Mixamo/
开箱不能离线用

包内不含 70 张风格参考图,也不含 90 条 Mixamo 动画。安装器在跑的时候会去 warcraft.wiki.gg、Hugging Face(钉死 revision 7f134bc7…)等站点拉取。断网安装会缺这两大块——参考图缺失只影响风格判断,动画缺失会直接卡死 M2 角色里程碑。

03任务规格 Docs/TASK.md

19 个章节里真正决定成败的三块:观众会看到的九步体验、六种族绑定职业的设计、以及全部资产与预算的技术边界。

观众将看到的一条路

TASK.md §1 把整个项目压缩成九个必须"能用且好看"的时刻。这就是验收时真正被检查的东西:

01登录界面

动态主视觉图 + World of Oldcraft 标志 + 账号/密码 + Login + 音乐

02角色选择

灯光舞台上的角色、种族背景、右侧角色列表、巨大的 Enter World 按钮;单服务器,无服务器列表

03角色创建

六种族 × 男/女,每族自带职业;少量自定义项、Randomize 名字、Accept

04进入世界

绘制风加载图 + 进度条 → 画面溶解 → 区域名金色大字淡入

05起始山谷

带修道院的森林山谷,正是已批准概念图的氛围

06战斗

选定目标、自动攻击 + 每职业至少 2 个技能,真实特效与音效、浮动战斗数字、怪物受击与死亡

07升级

几次击杀后金色光柱升起 + 号角,等级提升

08探索

道路离开森林、石桥过河、穿过金色田野;步行穿越 3–5 分钟;田野旁一小片闹鬼林地(P1)

09石头城

道路尽头是小石城的城门;走进去:石头街道、带喷泉的广场、卫兵、商贩、镇民

六种族 = 六职业,一对一绑定

这是本项目最反常规的设计决定:没有"选职业"这一步。种族和职业是绑死的,每个种族只有一种玩法、一把武器。这样 12 个身体只需覆盖 6 套动作集,把动画成本压掉一半。

种族职业武器身高 男/女(米)已批准设定图
Human 人类Warrior双手巨剑1.85 / 1.75v2_human_C_Enano
Dwarf 矮人Protector单手剑 + 圆盾1.35 / 1.30v2_dwarf_C_Egpt
Night Elf 暗夜精灵Ranger长弓 + 箭袋2.15 / 2.05v2_nightelf_C_Egpt
Orc 兽人Warrior单手剑 + 圆盾2.05(驼背) / 1.90race_orc_A
Undead 亡灵Mage法杖1.80 / 1.70race_undead_B
Bull-folk 牛头人Healer图腾法杖2.50 / 2.30v2_bullfolk_B_Egpt
关于"角色权威"的一条细则

设定图有原版(race_*)和职业编辑版(v2_*_E*)两代。README 裁定:武器和服装以职业编辑版为准,脸、头发、身体以原版为准。这条规则说明作者已经预见到"重画一张图会把脸也改掉"的问题。

六职业的技能表

职业种族 · 武器资源技能 1(P0)技能 2(P0)技能 3(P1)
Warrior人类 · 巨剑怒气Mortal Strike 致死打击Whirlwind 旋风斩Battle Shout 战斗怒吼
Protector矮人 · 剑盾怒气Shield Bash 盾击(短眩晕)Thunder Clap 雷霆一击(范围减速)Shield Block 盾牌格挡
Warrior兽人 · 剑盾怒气Heroic Strike 英勇打击Charge 冲锋(带尘土拖尾)Battle Shout 战斗怒吼
Ranger暗夜精灵 · 弓专注Aimed Shot 瞄准射击(读条)Arcane Shot 奥术射击(瞬发紫箭)Multi-Shot 多重射击
Mage亡灵 · 法杖法力Fireball 火球术(弹道 + 爆炸)Frost Nova 冰霜新星(冰环定身)Frostbolt 寒冰箭(减速)
Healer牛头人 · 图腾杖法力Lightning Bolt 闪电箭Healing Wave 治疗波(金绿光柱)Healing Totem 治疗图腾

Frost Nova 的技能描述写的是"冰环定身"、Frostbolt 是"减速",两处都要求真实控制效果而不只是特效。

世界路线

起点是一张已批准的区域鸟瞰图(v2_zone_overview_west_N)和配套的手绘区域地图(v2_zonemap_west_Nref)。地理被钉死:

尺度全部写死:门高约 2.6 m(风格化放大)、路宽约 6 m、轴心在底部、模型朝 +Z。地图四周用山或悬崖封闭。

技术边界

引擎与管线

Unity 6000.5.9f1 · URP · 线性色彩空间 · Forward+ · 只用新 Input System · Run in Background 必须开 · Unity Terrain 最多 8 个绘制层

场景流

Boot → FrontEnd(登录/选角/建角)→ Loading → World

数据

种族/职业/技能/怪物/NPC 全部走 ScriptableObject;角色存档为 JSON,写在 Application.persistentDataPath

操作方案

经典方案:W/S 前后、A/D 转身、Q/E 横移、空格跳、滚轮缩放、左键拖拽转镜头、右键转身、Tab 循环目标、数字键放技能、Esc 清目标

明确的"不做"清单

§2 直接点名不做:服务器列表、多区域、副本、组队、交易、拍卖、天赋、专业、坐骑、完整背包与装备系统、法术书与天赋窗、死亡跑尸、昼夜循环、天气、复杂任务链。这些只有全部 P0 和 P1 通过后才允许碰。对长会话代理来说,这条"不做"清单可能比"要做"清单更值钱。

04验收清单 TASK.md §2 + §16

18 项验收条目和 7 个里程碑。这是代理唯一被允许用来判断"做完了没有"的依据。

18 项验收条目

#时刻通过条件级别
1登录界面动态主视觉图、World of Oldcraft 标志、账号/密码框、Login 按钮、音乐;Login 进入选角P0
2角色选择角色站在灯光舞台上、种族背景、右侧列表(名字/等级/职业)、Enter World、Create、Delete、旋转;角色跨启动持久化。观感需与已批准 mockup 一样好P0
3角色创建6 个种族按钮、性别、显示该族职业、实时 3D 预览、2 种发型、按种族/性别的发色与肤色、带 Randomize 的名字、Accept/Back、每族一个背景。观感需与 mockup 一样好P0
4角色全部 12 个身体看起来像已批准设定图、风格统一、动画正确(无断肢、无滑步)、正确握持武器P0
5加载与进入世界绘制风加载界面 + 进度条、溶解进入世界、金色区域文字P0
6操作与镜头经典方案、平滑第三人称、不穿入地形或墙体P0
7战斗六职业全覆盖:选定目标、自动攻击、两个带冷却的技能、资源条、每次攻击与技能都有特效和音效、浮动战斗文字、受击反应、怪物死亡P0
8升级击杀给经验、金色光柱、号角、等级与属性提升P0
9世界路线森林山谷+修道院 → 河流石桥 → 金色田野 → 石头城门;符合已批准概念图与区域地图;步行 3–5 分钟P0
10石头城带雕像的城门、城墙、可行走石街、带喷泉广场、至少 4 类 NPC(卫兵/商贩/任务发布人/镇民)P0
11HUD玩家与目标框、带技能与冷却扫动的动作条、经验条、施法条、圆形小地图、带系统消息的聊天框、姓名板P0
12性能在所有者机器上 1440p 城内 ≥ 60 FPSP0
13任务一个带黄色"!"的任务发布人、击杀任务、羊皮纸对话框、任务追踪器、带"?"的交付与奖励P1
14第三技能每职业第三个技能,带特效与音效P1
15闹鬼林地田野旁的闹鬼区域,有自己的怪物与氛围音P1
16少量假玩家6–12 个用角色系统构建的"玩家"在路上游走、在城中站立,头顶有名字P1
17可进入的旅店城中一栋能走进去的建筑P1
18附加拾取窗与背包、小动物、假玩家聊天、黄昏光照、表情动作P2
P0 有 12 项,其中 4 项是纯视觉判断

第 2、3、4、9 项的条件里都写着"看起来像已批准的 mockup / 概念图"。这类条目机器无法自证,所以规则强行规定:代理不许给自己打分,必须由一个新上下文的评审代理对比截图打分(见 11)。

里程碑(六个门)

里程碑内容放行条件
M0 准备读完所有资料;写 PLAN.md、TODO.md、STYLE_BIBLE.md、MAP.md;初始化 git;每个工具做一次廉价冒烟调用;摆好故事相机与截图工具每个工具都有响应,计划已提交
M1 灰盒闭环§1 的整条路径用占位物打通:登录、选角、建角、加载、可操作胶囊体、灰盒山谷/桥/田野/城、一个占位怪、HUD 骨架黄金路径驱动端到端通过。从这里开始游戏必须永远可玩
M2 角色人类男性先走完整条管线进游戏;然后全部 12 个身体 + 发型 + 武器;选角与建角用最终美术评审代理把 12 个身体与已批准设定图逐一对比;两个界面与 mockup 对比
M3 战斗六职业的自动攻击与两个技能、特效与音效、怪物、升级验收测试第 1 轮
M4 世界地形、植被、山谷、桥、田野、城门与城内;雾、后处理、天空、水;城中 NPC验收测试第 2 轮;P0 全绿或进行中
M5 打磨修评审出来的最弱环节、镜头与动画手感、音频、性能P0 全绿
M6 展示Windows 构建、黄金路径录像、电影式飞越、进度延时摄影与分镜、REPORT.md§19 交付物齐全
"永远可玩"是一条硬约束

从 M1 起,每一次提交都要能跑通整条黄金路径(登录 → 建角 → 进世界 → 战斗 → 升级 → 进城)。如果改动弄坏了它、20 分钟内修不好,就必须回滚并重新排队。这是"宁可少做也不许坏"的工程纪律。

状态词表

项目禁止用"完成"这种模糊说法,只承认四个词:

implemented 已实现(东西存在) agent-verified 代理已验证(有夹具/探针/评审在 Game View 里确认过) pending owner review 待所有者审核(一切视觉产物的默认状态) not recorded 未记录(数字缺失时的唯一合法写法,绝不写 0)

05不停机框架 install_kit.ps1 + dot-claude/hooks/

这个包里最独特、也最容易被忽略的部分:一套确保代理不会自己停下来的机制,和一个把整套东西铺进 Unity 工程的安装器。

为什么需要一个"不许停"的钩子

目标是一个跨天、几十小时、几十次上下文压缩的长任务。而 Claude Code 的正常行为是"任务告一段落就结束回合"。keep_working.py 注册在 Stop 钩子上,利用 Claude Code 的一个语义:Stop 钩子以退出码 2 结束,就是"阻止停止",并把 stderr 的内容当作理由回灌给模型。

放行的两个条件

  1. 工程根出现 .claude/ALLOW_STOP 文件 → 退出码 0,允许停止
  2. .claude/session_window.json 里的 until 时间戳已过期 → 退出码 0

两者都不满足时,写一段指令到 stderr 并退出码 2。

每次被拦回来时,代理收到的话

所有者尚未结束本次会话。不要停止。
如果你丢了上下文,按 CLAUDE.md 第 1 节执行。
从 Docs/TODO.md 取下一项。
如果它为空,运行验收测试(TASK.md §2),
把最薄弱环节的修复加入队列,然后继续。
持续截图记录进度(TASK.md §18)。
Claude 想结束回合 │ ▼ Stop 钩子 → keep_working.py │ ├── .claude/ALLOW_STOP 存在? ──────────── 是 ──▶ exit 0 放行 ├── session_window.json 的 until 已过期? ─ 是 ──▶ exit 0 放行 │ └── 都不是 ──▶ exit 2 + stderr 指令 │ ▼ Claude Code 阻止停止,把 stderr 作为理由回灌给模型 │ ▼ 代理继续干活 → 若干回合后又想停 → 回到顶部 上限由 settings.json 的 CLAUDE_CODE_STOP_HOOK_BLOCK_CAP = 1000 抬到 1000 次
这是软约束,不是硬防线

机制上没有任何东西阻止代理自己创建 ALLOW_STOP。.gitignore 也只是让它不进版本库。整套"不许停"建立在"代理会遵守 CLAUDE.md 第 2 节"之上——而那条规则写的是"不要自行结束会话,由所有者结束"。要真正停下,人得手动 Esc 关掉会话,或提前写好 ALLOW_STOP / session_window.json。

上下文压缩后的重锚定

长会话必然被反复压缩。第二个钩子 after_compact.py 挂在 SessionStart 的 compact 和 resume 两个 matcher 上,每次压缩或恢复后往上下文里打印一段带 UTC 时间的指令,强制代理重读状态文件再继续。这和 CLAUDE.md 第 1 节的"每次启动/重启/压缩后按顺序读五个文件"是同一道保险的两半。

安装器做了什么

install_kit.ps1(Windows PowerShell,$ErrorActionPreference="Stop")按九步把套件铺进一个空的 Unity 工程:

1 · 复制与改名

递归复制六个目录;dot-claude/ → .claude/,mcp.json → .mcp.json。CLAUDE.md 和 requirements.txt 强制覆盖。

2 · 概念图回填

若套件缺 Docs/concepts,从上级 card 目录按 selection.json 回填 approved 与 candidates。

3 · 下载 90 条 Mixamo 动画

解析 mixamo_core_set.json,把 90 个 motion_id 一次性传给下载脚本,落到 Assets/_Source/Mixamo/。失败仅告警。

4 · 下载 70 张参考图

跑 scripts/refs/fetch_refs.py,抓取并转成 WebP(质量 88)。失败仅告警。

5 · 生成 .env

唯一拒绝覆盖的既有文件。传入 -FalKey 时用正则只改写 FAL_KEY= 那一行。

6 · 填占位符

替换 {{UNITY_MCP_SERVER_DIR}}、{{BLENDER_MCP_COMMAND}}、{{BLENDER_EXE}}。

7 · 改预算数字

传 -FalBudgetUsd 或 -HiggsfieldCredits 时,同步改写文档正文里的金额,让文档与实际一致。

8 · 追加 .gitignore

逐行查重后追加 .env、.claude/ALLOW_STOP、.claude/session_window.json、Docs/owner-desktop-timelapse/。

9 · 打印下一步

输出人工需要做的收尾操作提示。可重复运行,已存在的东西保留。

给"人"的三个 PowerShell 脚本

host-tools/ 里的 desktop_timelapse.ps1、stop_desktop_timelapse.ps1、make_desktop_timelapse.ps1 用 ffmpeg 定时截整个桌面再合成 mp4,是给所有者录制"制作过程"用的,不在代理的职责范围内(README 明确写 "for you, not for the agent")。停止脚本按 PID 且校验进程名为 ffmpeg 才杀——这条来自 PIPELINE_LESSONS 里"一次无差别 kill 干掉了无关编辑器"的教训。

工具脚本逐项

套件安装脚本(install_kit.ps1)/tmp/woc_kit/WorldOfOldcraft-build-kit/install_kit.ps1

把整个 World of Oldcraft 构建套件安装进一个(空的)Unity 工程目录:复制文档/脚本/钩子、重命名隐藏配置文件、下载 Mixamo 动画与风格参考图、填充 MCP 路径占位符、写好 .gitignore。

  • 参数:-Target 必填;-FalBudgetUsd(默认 100)、-HiggsfieldCredits(默认 "10,000")、-FalKey、-UnityMcpServerDir(默认 C:/GIT/unity-mcp-server)、-BlenderMcpCommand(默认 blender-mcp)、-BlenderExe(默认 C:/Program Files/Blender Foundation/Blender 5.1/blender.exe);$ErrorActionPreference="Stop"。
  • 复制内容:CLAUDE.md、requirements.txt 直接 Copy-Item -Force;Copy-Tree 递归复制 Docs、knowledge、processes、projects、scripts、host-tools 六个目录;dot-claude/ 改名成 .claude/、mcp.json 改名成 .mcp.json、env.example(或套件内已有 .env)改名成 .env。
  • 回退逻辑:若套件里没有 Docs\refs 而父目录(card 文件夹)有 refs/,从父目录复制参考图清单;若没有 Docs\concepts,则把 card\concepts\images\*.webp 拷入 candidates,并按 selection.json 的 approved+recommended 组把选中的图拷入 Docs\concepts\approved。
  • Mixamo:若套件带 mixamo-fbx/ 则整体复制到 Assets\_Source\Mixamo;否则若目标目录没有 *.fbx,读取 scripts\animation\mixamo_core_set.json,用 python 调 download_mixamo.py,把 90 个 clip 的 motion_id 逐个作为 --motion-id 参数传入;失败只 Write-Warning 不中断。
  • 风格参考:若 Docs\refs\manifest.json 存在且目录内没有任何 *.webp,运行 python scripts\refs\fetch_refs.py --refs <refs目录>;失败仅警告并提示手工获取。
  • .env 保护:只在目标 .env 不存在时复制生成,绝不覆盖已有 .env;若传了 -FalKey 用正则 (?m)^FAL_KEY=.*$ 覆写该行,UTF8 无 BOM 写回。
  • 占位符替换:对 CLAUDE.md、.mcp.json 及 Docs 下所有 *.md 递归替换 {{UNITY_MCP_SERVER_DIR}}、{{BLENDER_MCP_COMMAND}}、{{BLENDER_EXE}}(反斜杠转正斜杠);-FalBudgetUsd≠100 时把 "**100 USD**" 和 "hard budget 100 USD" 里的数字改掉;-HiggsfieldCredits≠"10,000" 时替换 "about 10,000"。
  • 追加 .gitignore(已存在则跳过不重复):.env、.claude/ALLOW_STOP、.claude/session_window.json、Docs/owner-desktop-timelapse/;最后打印后续步骤(填 FAL_KEY、pip install、开 Unity、开 Blender、跑 claude)。
桌面延时摄影启动器(给 owner 用,非 agent)/tmp/woc_kit/WorldOfOldcraft-build-kit/host-tools/desktop_timelapse.ps1

在宿主机上用 ffmpeg 的 gdigrab 每隔 N 秒截一张全屏,存为编号 JPG,形成一天一目录的桌面延时摄影;文件头明确注明这是给 owner 记录 agent 工作过程用的,不是给 agent 用的。

  • 参数:-Every(秒,默认 60)、-Out(默认 %USERPROFILE%\Downloads\Oldcraft-desktop-timelapse)、-Region "x,y,width,height"(单显示器裁切,写入 -offset_x/-offset_y/-video_size)、-MaxWidth(默认 2560,scale='min(iw)' 缩放)、-Hidden(后台隐藏运行)。
  • ffmpeg 参数:-f gdigrab -framerate 1 -i desktop,滤镜 fps=1/$Every,scale='min($MaxWidth,iw)':-2,-q:v 3,输出 shot_%06d.jpg;每个会话一个 yyyyMMdd-HHmmss 子目录。
  • 防重入:Out 目录下 running.pid 存在且进程还活着时直接退出并提示先跑 stop_desktop_timelapse.ps1。
  • PID 管理:-Hidden 用 Start-Process -WindowStyle Hidden 后台起 ffmpeg 并把 PID 写进 running.pid;前台模式用 Wait-Process 等待,finally 块里 Stop-Process 按 PID 杀进程并删 pid 文件。
  • 前置检查:Get-Command ffmpeg 找不到就报错退出并提示 winget install Gyan.FFmpeg。
桌面帧合成视频(make_desktop_timelapse.ps1)/tmp/woc_kit/WorldOfOldcraft-build-kit/host-tools/make_desktop_timelapse.ps1

把 desktop_timelapse.ps1 拍的 JPG 序列编码成 mp4 延时视频,默认自动挑 Downloads 里最新的会话目录。

  • 参数:-Frames(帧目录,留空则按目录名排序取 $Out 下最新一个会话目录)、-Fps(默认 30)、-Out(默认同拍摄脚本)。
  • 编码命令:ffmpeg -framerate $Fps -i shot_%06d.jpg,滤镜 pad=ceil(iw/2)*2:ceil(ih/2)*2(补齐偶数宽高),-c:v libx264 -pix_fmt yuv420p -crf 20,输出 <会话目录名>_timelapse.mp4,写在会话目录的父目录。
  • 头部注释给了换算基准:每 1 分钟一帧、24 小时 = 1440 帧 = 30fps 下 48 秒;每 5 分钟一帧约 10 秒。
  • 同样先检查 ffmpeg 在 PATH、无会话目录时报错退出。
停止桌面延时摄影(stop_desktop_timelapse.ps1)/tmp/woc_kit/WorldOfOldcraft-build-kit/host-tools/stop_desktop_timelapse.ps1

按 running.pid 精确停掉后台运行的 ffmpeg 截帧进程,符合 CLAUDE.md “只按 PID 杀进程”的纪律。

  • 无 pid 文件时打印“没有运行中的延时摄影”并 exit 0,幂等。
  • 读 running.pid 后先 Get-Process 校验进程存在且 ProcessName -eq "ffmpeg" 才 Stop-Process -Force;进程名不符(PID 被复用)时不动进程,只报告。
  • 无论如何删除 pid 文件,最后统计按名称排序最新会话目录里的 *.jpg 数量并打印帧目录路径。
项目级 Claude Code 设置(harness 装配点)/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/settings.json

把两个 Python 钩子挂进 Claude Code 生命周期,并把 Stop 钩子的连续拦截上限抬到 1000,这是“agent 不许自己停下来”机制的开关盒。

  • env: CLAUDE_CODE_STOP_HOOK_BLOCK_CAP="1000"——默认该上限较小(约 8 次),抬到 1000 后 keep_working.py 可以连续拦截 1000 次停止请求而不被 harness 强制放行。
  • Stop 钩子:command 类型,python "$CLAUDE_PROJECT_DIR/.claude/hooks/keep_working.py",每次 agent 试图结束回合都执行。
  • SessionStart 钩子两条:matcher "compact" 和 matcher "resume" 都执行 after_compact.py,即上下文压缩与会话恢复后各触发一次。
  • 安装后此文件位于目标工程 .claude/settings.json,属项目级配置,只对打开该目录的 Claude Code 会话生效。
Stop 钩子:阻止 agent 自行结束会话(keep_working.py)/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/hooks/keep_working.py

作为 Claude Code 的 Stop hook,在 owner 未明确结束会话前拒绝 agent 停止:exit 2 拦截停止并把 stderr 文本作为理由回灌给 agent。

  • 先 json.load(sys.stdin) 吞掉钩子输入 JSON,异常忽略——不因输入格式炸掉。
  • 放行条件一:$CLAUDE_PROJECT_DIR(缺省用 cwd)下存在 .claude/ALLOW_STOP 文件即 exit 0;owner 手工创建该文件就是“结束会话”的总开关。
  • 放行条件二:.claude/session_window.json 存在且其 "until" 字段(ISO 时间,utf-8-sig 读入)已是过去时间(无时区则 astimezone() 本地化后与 datetime.now(timezone.utc) 比较)即 exit 0——支持“限时运行到某点自动允许停”。
  • 两个放行条件都不满足:向 stderr 写入固定指令(不许停;按 CLAUDE.md 第 1 节重读状态文件;取 Docs/TODO.md 下一项;TODO 空则跑 TASK.md §2 验收测试并排队补弱项;继续截图 TASK.md §18),然后 exit 2。Claude Code 的 Stop hook 语义:exit 2 = 阻止停止并把 stderr 反馈给模型。
  • 容错是 fail-closed 方向:session_window.json 解析失败被 except 静默吞掉,结果是继续拦截停止而不是放行。
  • ALLOW_STOP 与 session_window.json 都被安装脚本写进了 .gitignore。
SessionStart 钩子:压缩/恢复后重锚定状态(after_compact.py)/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/hooks/after_compact.py

在上下文被 compact 或会话 resume 后,向 agent 注入一段再锚定指令,防止长会话压缩后忘记工作规程。

  • 仅一个 print():SessionStart 钩子的 stdout 会被注入会话上下文。
  • 内容带 UTC 时间戳,并要求在做任何动作之前重读 CLAUDE.md、Docs/PLAN.md、Docs/TODO.md、Docs/DEVLOG.md 最后三条和 Docs/STATS.json。
  • 随后要求继续当前 milestone,并按 Docs/TASK.md 第 18 节为手头功能补一张进度截图。
  • 无副作用、不读文件、不判断条件,纯提示器。
MCP 服务器模板(安装后成为 .mcp.json)/tmp/woc_kit/WorldOfOldcraft-build-kit/mcp.json

声明 agent 工作时要连的三个 MCP 服务器:Unity 编辑器桥、Blender 桥、Higgsfield 云桥;带三个由安装脚本填充的路径占位符。

  • unity:stdio,command "node",args ["{{UNITY_MCP_SERVER_DIR}}/src/index.js"],env UNITY_BRIDGE_PORT="7890"——指向本地 unity-mcp-server 仓库的 Node 入口。
  • blender:stdio,command 为 {{BLENDER_MCP_COMMAND}}(默认 blender-mcp),env BLENDER_PATH={{BLENDER_EXE}} 指向 blender.exe。
  • higgsfield:type "http",url https://bridge.higgsfield.ai/mcp——云端 HTTP 型 MCP,无本地凭据字段(Higgsfield 靠 CLI `higgsfield auth login` 的账号登录,见 env.example)。
  • 三个 {{...}} 占位符在 install_kit.ps1 第 95-106 行被替换为 -UnityMcpServerDir/-BlenderMcpCommand/-BlenderExe 的实际值(统一换成正斜杠)。
环境变量模板(安装后成为 .env)/tmp/woc_kit/WorldOfOldcraft-build-kit/env.example

唯一的密钥载体模板:只含一个 FAL_KEY 空值;被安装脚本复制为 <Target>\.env 且永不回写覆盖。

  • FAL_KEY= 留空,需手工粘贴或用 -FalKey 参数注入;注释指明 fal 预算硬上限见 Docs/TASK.md §15。
  • 明确注释:Higgsfield 不走环境变量,用 `higgsfield auth login` 在本机登录一次 CLI 即可。
  • 第一行注释“Never commit .env”,且 .env 已被追加进 .gitignore。
Python 依赖清单/tmp/woc_kit/WorldOfOldcraft-build-kit/requirements.txt

安装 agent 侧 Python 工具链的三个依赖,供 generate.py / download_mixamo.py / fetch_refs.py / 钩子使用。

  • fal-client>=0.5:fal.ai 官方客户端,generate.py 用 fal_client.run() 和 fal_client.upload_file()。
  • requests>=2.31:download_mixamo.py 与 fetch_refs.py 的 HTTP 库。
  • pillow>=10.0:fetch_refs.py 的图片转 WebP 与 make_timelapse.py 的截图渲染。
  • 钩子用的是 Python 标准库(json/os/sys/datetime/pathlib),不在清单内但要求 PATH 上有 python。
套件内容清单(KIT_CONTENTS.json)/tmp/woc_kit/WorldOfOldcraft-build-kit/KIT_CONTENTS.json

机器可读的套件装箱单:列出打包的 skills、文档、脚本,以及由安装器负责下载的两类外部资产。

  • skills 四项:character-sheet-pipeline、fal-ai-generation、blender-game-animation、3d-production-routing(安装后进 .claude/skills/)。
  • docs 共 24 条:knowledge/ 9 篇(含 overlord-unity-test-input.md 等经验教训)、processes/3d-ai/ 8 篇(higgsfield-cli、image-generation、prompting、tools 等)加 workspace-video-storage.md、projects/overlord/animation-workflow/ 6 篇旧项目交接文档。
  • scripts 列出 3 个核心脚本:center_glb_bottom.py、download_mixamo.py、generate.py(清单未列 fetch_refs.py 与 make_timelapse.py,但套件里有)。
  • downloaded_by_installer 字段声明两类安装期下载物:Assets/_Source/Mixamo/*.fbx(按 mixamo_core_set.json)和 Docs/refs 图片(按 manifest.json);links_not_copied 为空。
风格参考图抓取器(fetch_refs.py)/tmp/woc_kit/WorldOfOldcraft-build-kit/scripts/refs/fetch_refs.py

按 Docs/refs/manifest.json 的清单从原始出处下载第三方 WoW 风格参考截图/粉丝图,统一转存为 WebP——套件有意只发货清单不发图(版权考虑)。

  • 清单字段:每项含 file(保存相对路径)、image_url、可选 source_page;manifest 在 --refs 目录(默认脚本上两级 Docs/refs)。
  • 反爬处理:UA 伪装 Chrome 128;对有 source_page 的项准备两种 header 变体(不带 Referer / 带来源页 Referer 都试一遍),因为有的站拒绝外来 Referer、有的站强制要求本站 Referer。
  • 重试策略:tries=3,每轮内两种 header 各试,指数式等待 time.sleep(2*(attempt+1)),timeout=(20,90) 元组。
  • 幂等与安全:目标文件已存在且非 0 字节就跳过;PIL 打开后按模式转 RGBA 或 RGB,im.save(target, "WEBP", quality=88)。
  • 退出码语义:有任何失败 exit 1 并逐条打印“去 source_page 手工保存”的兜底指引;全部成功 exit 0。
fal.ai 批量生图器(generate.py)/tmp/woc_kit/WorldOfOldcraft-build-kit/scripts/image-gen/generate.py

从 prompts JSON 批量调 fal.ai 生图(含 edit 模型),并发下载结果,产出人工评审用 HTML 报告——agent 走 fal.ai 备用生成路线时的统一入口。

  • 命令行:generate.py <prompts.json> --model(默认 nano-banana-2,共 16 个端点:nano-banana-2/-edit、nano-banana-pro/-edit、gpt-image-2/-edit、gpt-image-2.5/-edit、grok-imagine-2/-edit、seedream-v4/-edit、seedream-v5-pro/-edit、flux-pro(v1.1)、flux-dev)--aspect-ratio(默认 1:1)--run-id --dry-run --workers(默认 5)--skip-existing。
  • 密钥:load_env() 从仓库根 .env(脚本上三级目录)用 setdefault 注入环境,优先 FALAI_KEY 再 FAL_KEY,缺了直接 sys.exit(1)。
  • 按模型适配参数:nano-banana-pro 加 safety_tolerance="6"、enable_web_search=True、resolution="2K";edit 端点传 image_urls(本地路径先 fal_client.upload_file(),http URL 直通);nano-banana/grok 用 aspect_ratio;gpt-image-2/seedream 用 GPT_IMAGE_SIZE 枚举映射(1:1→square_hd 等)且 seedream 弹掉 output_format;其余用 size_map {1:1:(1024,1024),16:9:(1344,768),9:16:(768,1344)} 的 image_size 字典。
  • 并发与产物:ThreadPoolExecutor 跑任务,输出到 scripts/image-gen/data/<run_id>/ 下 images/(<id>_<变体>.png)、results.json(含 remote_url、seed、error)、report.html(深色 A/B/C 三栏对比评审页,页脚提示按对象挑 A/B/C 或给迭代反馈)。
  • 成本控制只在文档/策略层(TASK.md §15 的 100 USD 上限),脚本本身无预算熔断;--dry-run 只打印提示词不花钱,--skip-existing 避免重复计费,但默认 --workers 5 会并发烧钱。
  • 每个 prompt 对象支持 variants 字典(A/B/C),变体值可以是纯字符串或 {prompt, images|image} 字典(后者用于 edit 流程)。
Mixamo 动画下载器(download_mixamo.py)/tmp/woc_kit/WorldOfOldcraft-build-kit/scripts/animation/download_mixamo.py

按精确 motion_id(UUID) 从 Hugging Face 数据集 Linzhan/Mixamo-Animations-Characters 拉取 Mixamo 动画 FBX 文件,带完整的完整性校验与下载凭证——只做获取,不做重定向/导出。

  • 流程:请求 /api/datasets/<REPO>/revision/<revision>(默认 main)拿到固定 sha,再按 sha 拉 metadata.csv,要求每个 motion_id 在 CSV 里恰好命中 1 行(否则 raise)。
  • 路径校验:archive 内路径必须是 animation/<name>.fbx 两段式,否则 raise 'Unexpected archive path'。
  • 内容校验:载荷必须以二进制 FBX 头 b'Kaydara FBX Binary \x00\x1a\x00' 开头且 ≥1024 字节,否则 raise;下载后计算 sha256。
  • 安全写入:目标文件已存在且哈希不同 → raise FileExistsError 拒绝覆盖;新文件先写 <name>.fbx.part 再 .replace() 原子改名——不留半截文件。
  • 凭证:每成功一个 clip 就把记录(url、bytes、sha256、archive、archive_revision、metadata_sha256、verification 提示语)增量写进 <output>/downloads.json,后续网络失败不丢先前成果;最后另存 metadata.csv 副本;--motion-id 可重复传入,--revision 默认 main。
GLB 底部中心重定原点(center_glb_bottom.py)/tmp/woc_kit/WorldOfOldcraft-build-kit/scripts/3d/center_glb_bottom.py

用无头 Blender 把一批 .glb/.gltf 的枢轴移到包围盒底部中心,让生成模型进引擎后能直接“落地”——对应 CLAUDE.md 批量后台 Blender 处理里的 re-pivot 工序。

  • 调用方式:blender --background --python center_glb_bottom.py -- <in_dir> <out_dir>,在 `--` 后取参。
  • 每个文件先 bpy.ops.wm.read_factory_settings(use_empty=True) 清空场景再 import_scene.gltf,互不污染。
  • 算法:对所有 MESH 对象的 bound_box 角点乘 matrix_world 求世界空间联合包围盒,取 bottom_center=(中点X, 中点Y, minZ),再把所有无父级根对象的 matrix_world 平移 -bottom_center(子对象随父移动),整体不破坏层级。
  • 导出 export_scene.gltf(export_format="GLB", use_selection=False) 到 out_dir,.gltf 输入统一改名 .glb 输出;原始文件不动;逐文件打印 [ok]/[nomesh]/[fail] 与最终计数。
  • 注意 docstring 写的是 Unreal 语义(pivot 在底部中心),但操作本身与引擎无关,Unity 里同样适用。
进度截图合辑工具(make_timelapse.py)/tmp/woc_kit/WorldOfOldcraft-build-kit/scripts/capture/make_timelapse.py

把 TASK.md §18 规定的进度截图合成为带字幕的延时视频和分镜总览图,供 owner 与 Reviewer 快速回看开发过程。

  • 输入约定:Docs/progress/<feature>/<yyyymmdd-HHMMSS>__<short-caption>.png(caption 从文件名 __ 后解析,时间戳里的 - 换空格)。
  • 命令行:--root(默认 Docs/progress)、--feature(可重复)、--all、--master(全部功能按文件名时间排序合成一个 master_timelapse.mp4,字幕带 [feature] 前缀)、--fps(默认 3.0)、--hold-last(默认 2.0 秒)、--width(默认 1920)、--no-captions。
  • 渲染:Pillow LANCZOS 缩放到目标宽(高取偶),底部画半透明黑条烧入字幕(字体按 arial→segoeui→DejaVuSans 回退),存临时目录 f%06d.jpg。
  • 编码:写 ffmpeg concat 清单 list.txt(每帧 duration=1/fps,末帧重复一次并 hold max(hold_last,1/fps) 秒),ffmpeg -f concat -vf pad 偶数化 -c:v libx264 -pix_fmt yuv420p -r 30。
  • 分镜图:storyboard() 输出 4 列 × 480px 缩略图网格 JPG,每格下沿写截断到 70 字符的 caption;产物统一进 Docs/progress/_out/。
  • 启动即检查 shutil.which("ffmpeg"),没有则直接退出;依赖 Pillow。
Mixamo 核心动画清单(mixamo_core_set.json)/tmp/woc_kit/WorldOfOldcraft-build-kit/scripts/animation/mixamo_core_set.json

为经典 MMO 切片精选的 90 条 Mixamo 动画的采购清单:钉死数据源与版本,按 10 个用途组分类,安装器据此驱动 download_mixamo.py 批量拉取。

  • 头部元数据:source 为 Hugging Face 数据集 Linzhan/Mixamo-Animations-Characters,revision 固定为 7f134bc734557b1d9516cb476d25ea1f577e45c1,license 标注 "adobe-mixamo-terms (record as Mixamo terms, not CC0)",note 说明按六个种族角色(Human 双手战士、Dwarf 剑盾、Night Elf 弓手、Orc 剑盾、Undead 法师、牛头人治疗者)策展并要求用前逐条预览。
  • clip 总数 90,motion_id 全部唯一;每条记录字段为 group / motion_id / name / use 四项。
  • 10 个 group 及数量:locomotion 18、social 16、great-sword 14、bow 14、melee 8、shield 7、magic 5、reaction 4、creature 3、healer 1。
  • 示例条目:{"group":"locomotion","motion_id":"c9cc6f74-b96c-11e4-a802-0aaa78deedf9","name":"Sword And Shield Idle","use":"default combat-ready idle"};{"group":"magic","motion_id":"a3d120fd-c26a-46c7-a4a0-59c1c5d8157c","name":"Standing 1H Magic Attack 01","use":"Fireball cast"};{"group":"social","name":"Waving Gesture","use":"/wave"};{"group":"creature","name":"Mutant Breathing Idle","use":"hunched humanoid mob idle"};{"group":"healer","name":"Magic Heal (one hand)","use":"Healing Wave / heal cast"}。
  • 安装器用法:install_kit.ps1 遍历 $coreSet.clips 把每条 motion_id 拼成 --motion-id 参数一次性传给 download_mixamo.py,输出到 Assets\_Source\Mixamo。
这一层的完整分析原文摘要

【安装流程(install_kit.ps1,Windows PowerShell,$ErrorActionPreference=\"Stop\")】① 校验/创建 -Target 目录并转绝对路径;$Kit 取脚本所在目录。② 复制:CLAUDE.md、requirements.txt 直接强覆盖复制;Copy-Tree 递归复制 Docs、knowledge、processes、projects、scripts、host-tools 六个目录;dot-claude/ 重命名复制为 .claude/,mcp.json 重命名为 .mcp.json。③ 文本模式回退:若套件缺 Docs\\refs 或 Docs\\concepts,从其父目录(card 文件夹)补 refs 清单和 concepts/images/*.webp→candidates,并按 selection.json 的 approved+recommended 把选中图复制进 Docs\\concepts\\approved。④ Mixamo:套件内若有 mixamo-fbx/ 就整体复制到 Assets\\_Source\\Mixamo;否则仅当目标没有 *.fbx 时,解析 scripts\\animation\\mixamo_core_set.json(90 个 clip、10 个 group、钉死 HF revision),把全部 motion_id 作为 --motion-id 传给 python scripts\\animation\\download_mixamo.py 下载;失败仅 Write-Warning 提示先 pip install 再重跑。⑤ 风格参考:Docs\\refs\\manifest.json 存在且目录无 *.webp 时运行 scripts\\refs\\fetch_refs.py 下载并转 WebP(q88);失败仅警告。⑥ .env:仅当目标不存在时从套件 .env 或 env.example 复制生成——绝不覆盖已有 .env;传 -FalKey 时用正则覆写 FAL_KEY= 行(UTF8 无 BOM)。⑦ 占位符与预算改写:对 CLAUDE.md、.mcp.json、Docs 全部 *.md 替换 {{UNITY_MCP_SERVER_DIR}}、{{BLENDER_MCP_COMMAND}}、{{BLENDER_EXE}};-FalBudgetUsd≠100 或 -HiggsfieldCredits≠\"10,000\" 时在文档正文里同步改写预算数字。⑧ 追加 .gitignore:.env、.claude/ALLOW_STOP、.claude/session_window.json、Docs/owner-desktop-timelapse/(逐行查重,不重复追加),最后打印下一步操作指引。安装器唯一拒绝覆盖的既有文件是 .env;其余 Copy-Item -Force 会覆盖目标同名文件。 【\harness(让 agent 一直跑下去的框架)】.claude/settings.json 把 CLAUDE_CODE_STOP_HOOK_BLOCK_CAP 抬到 1000,并注册两类钩子:Stop 钩子运行 keep_working.py——它先吞掉 stdin JSON,然后检查 $CLAUDE_PROJECT_DIR/.claude/ALLOW_STOP,存在即 exit 0 放行停止;否则解析 .claude/session_window.json 的 \"until\" ISO 时间戳,已过期即 exit 0;两者皆无则向 stderr 写入“owner 未结束会话,不许停:按 CLAUDE.md §1 重读状态、取 Docs/TODO.md 下一项、TODO 空则跑 TASK.md §2 验收并补弱项、继续截图 TASK.md §18”并 exit 2——Claude Code 对 Stop 钩子 exit 2 的语义是阻止停止并把 stderr 作为理由回灌给模型,配合 BLOCK_CAP=1000 可连续拦截上千次。owner 结束会话的手段就是创建 ALLOW_STOP 文件或让 session_window.json 的 until 过期。SessionStart 钩子在 matcher \"compact\" 和 \"resume\" 时运行 after_compact.py,向上下文打印一条带 UTC 时间的指令:先重读 CLAUDE.md、PLAN.md、TODO.md、DEVLOG.md 最后三条、STATS.json 再继续当前 milestone 并补进度截图,用于长会话压缩后的状态重锚定。ALLOW_STOP 与 session_window.json 均被 .gitignore 排除,agent 若自己创建它们也不会入库(但机制上不阻止 agent 自造 ALLOW_STOP——这是信任 agent 的软约束,不是硬防线)。 【配套工具链】宿主机侧三个 ps1 是 owner 专用桌面监控:desktop_timelapse.ps1 用 ffmpeg gdigrab 每 -Every 秒截屏存 JPG(running.pid 防重入,-Hidden 后台化),make_desktop_timelapse.ps1 用 libx264/yuv420p/crf20 合成 mp4,stop_desktop_timelapse.ps1 按 PID 且校验进程名为 ffmpeg 才杀。agent 侧脚本:generate.py 是 fal.ai 批量生图器(16 个模型端点、5 并发、产出 images/+results.json+report.html 评审页);download_mixamo.py 按 UUID 从钉死 revision 的 HF 数据集拉 FBX(二进制头校验、sha256、拒覆盖不同内容、原子写、downloads.json 凭证);center_glb_bottom.py 无头 Blender 把 GLB 枢轴移到包围盒底心;make_timelapse.py 把 Docs/progress 截图合成带字幕延时视频与分镜图;fetch_refs.py 按 manifest 抓参考图(双 Referer 变体、3 次重试、幂等跳过)。 【安全轨与硬编码假设】安全轨:.env 永不覆盖、密钥不落 git(.gitignore 覆盖 .env/ALLOW_STOP/session_window.json);Mixamo 与 refs 下载全部幂等且拒绝覆盖冲突文件;stop 脚本只按 PID 杀且验进程名;keep_working.py 对坏配置 fail-closed(宁可拦死不误放)。硬编码/假设:整套是 Windows 向——默认 C:/GIT/unity-mcp-server、Blender 5.1 安装路径、%USERPROFILE%\\Downloads\\Oldcraft-desktop-timelapse、gdigrab 抓屏、依赖 PATH 上的 python/node/ffmpeg/blender;unity MCP 桥端口固定 7890;higgsfield 端点固定 https://bridge.higgsfield.ai/mcp 且鉴权走 CLI 登录而非环境变量;100 USD fal 上限只存在于文档文案替换层面,generate.py 代码里没有预算熔断;安装器假设 Target 基本是空工程,非空时 -Force 复制会覆盖目标里同名文档。

值得注意的点

  • install_kit.ps1 只对 .env 做“存在即不覆盖”保护,其余全部 Copy-Item -Force——对非空目标目录重跑安装器会覆盖目标里 agent 已改过的 CLAUDE.md、Docs/**、.claude/ 钩子等文件,套件只设计给空工程用。
  • 100 USD fal.ai 预算硬上限没有任何代码级熔断:generate.py 默认 --workers 5 并发、无花费计数、无 dry-run 强制;预算控制完全依赖 agent 遵守 TASK.md §15 与文档文案(安装器用 -FalBudgetUsd 只是字符串替换 "**100 USD**" 和 "hard budget 100 USD" 两处,改数不生效于任何执行逻辑)。
  • keep_working.py 是 fail-closed:session_window.json 若 JSON 坏掉或缺 "until" 键,异常被静默吞掉,结果是永久拦截停止;同时它信任 agent 不作弊——agent 技术上可以自行创建 .claude/ALLOW_STOP 停止自己,防线是提示词纪律("The owner ends the session")而非机制。
  • CLAUDE_CODE_STOP_HOOK_BLOCK_CAP=1000 意味着若 agent 逻辑上无可做事但 ALLOW_STOP 不存在,会被钩子连续弹回多达 1000 次回合,每回合都重读文档再空转——死循环风险由钩子文案里的“TODO 空则跑验收测试并补弱项”兜底。
  • 钩子依赖 PATH 上的 `python` 命令且 settings.json 用 $CLAUDE_PROJECT_DIR 定位脚本:Windows 上若只有 python3/py 启动器或 CLAUDE_PROJECT_DIR 未注入(fallback 是 cwd,钩子进程的 cwd 不保证是项目根),Stop 钩子会静默失效或报错。
  • install_kit.ps1 调 Mixamo/refs 下载都期望 `python` 已在 PATH 且已 pip install requirements.txt,但它不会自动装依赖,失败降级为 Write-Warning 后安装“成功”——可能装出一个没有动画和参考图的半成品工程,需看输出警告。
  • mixamo_core_set.json 的 license 字段明确 "adobe-mixamo-terms (record as Mixamo terms, not CC0)":这 90 条动画不是 CC0,与 CLAUDE.md 第 6 节“免费资产记 LICENSES.md”并行存在一套 Mixamo 条款的许可记录义务,LICENSES.md 需按 Mixamo terms 记录。
  • download_mixamo.py 钉死 HF revision 7f134bc7…,若数据集上游被删/改名安装即 404(仅警告);其“拒绝覆盖不同内容本地文件”的 FileExistsError 会让安装器第 74 行整体非零退出,重复运行前需手工清理损坏的 .fbx。
  • fetch_refs.py 抓的是第三方截图/粉丝艺术(套件故意只发清单),产物仅限 Docs/TASK.md §3 规定的 2D 风格参考用途,不能进游戏资产管线;退出码非 0 时安装器只警告,缺图是常态,需按打印的 source_page 手工补。
  • desktop_timelapse.ps1 用 -i "desktop" 会截整个桌面(含其他窗口与敏感信息),且默认输出在 Downloads\Oldcraft-desktop-timelapse(不在工程内);.gitignore 里的 Docs/owner-desktop-timelapse/ 与脚本实际输出目录并不一致,说明存在两种存放约定。
  • generate.py 的 ROOT 取脚本上三级目录找 .env:脚本必须保持在 <项目根>/scripts/image-gen/ 下运行才读到密钥;MODELS 表含 openai/gpt-image、xai/grok、bytedance/seedream 等非 fal 品牌端点但全部经 fal_client 计费,花费全部计入 100 USD fal 预算。
  • center_glb_bottom.py 假设 GLB 内 MESH 的 bound_box 可信且以 Z-up(min Z 为底)语义处理,docstring 按 Unreal 描述;导入 Unity 的管线(CLAUDE.md §8)另要求 FBX 导出参数与 scale 1 校验,此脚本只负责 GLB re-pivot,不处理贴图解析问题。
  • make_timelapse.py 的截图字幕直接取自文件名 __ 之后的 caption——文件名即数据,agent 按 TASK.md §18 命名不规范(缺 __ 或时间戳)会导致视频字幕错乱;--master 模式跨功能目录按文件名字典序排序,跨日截图混排时需文件名时间戳真实可靠。

06生产线技能与经验库

四个技能、九篇经验、九篇流程、六篇前项目档案。这部分才是"怎么真的做出一个能用的 3D 角色"的答案。

四个技能如何分工

3d-production-routing

分诊台。不含产能,只把任务分派到正确路线。强制三条全局纪律。

character-sheet-pipeline

角色原画 → 3D 参考。8 阶段 3 闸门,把一张角色图展开成严格正面的部件包。

blender-game-animation

绑定 → 动画 → Unity 交付。管线末端,负责 FBX 干净导出与重导入验证。

fal-ai-generation

执行层 + 预算守门。所有生成调用的统一出入口,带收据与去重。

贯穿四个技能的一条哲学

"技术完成、视觉验收、引擎集成"是三件必须分开报告的事实——生成了 mesh 不等于有骨骼,导出了 FBX 不等于接了 Animator。这条规则直接对应 CLAUDE.md 第 7 节的四状态词表。

角色表管线:8 阶段 3 闸门

这是整个包里技术含量最高的一段流程。它解决的是"图生 3D 时,模型看到的永远是一张乱七八糟的立绘"这个核心问题:

Stage 2A Nano Banana Pro 出母图(严格正面) Stage 2B GPT-Image-2.5 出三视图(正/侧/背) │ ▼ Gate 1 部件清单核对 —— 不过闸不许往下 │ Stage 4 逐件提取正面视图(身体 / 配对件 / 配件 / 头发) Stage 4.5 分类器反查 3/4 视角,有界重试 │ ▼ Gate 2 多视图齐备性检查 │ Stage 7 按报价渲染 360 度转盘视频(Seedance) │ ▼ Gate 3 生成 manifest.json 审计记录

"有界重试"是关键词——4.5 阶段的重试次数有上限,避免代理在同一个部件上无限循环烧钱。

技能库全部文件

3D 生产路由技能(总入口/分诊器)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/3d-production-routing/SKILL.md

不产生任何素材,只负责分诊:给定一个 3D 任务(参考图、生成网格、材质、程序化重建、游戏动画),决定走哪条 API/技能路线,并规定跨会话续接生成作业的纪律。

  • 先读 processes/3d-ai/tools.md 工具地图和 knowledge/creative-skills.md 技能目录,再只加载与所请求输出对应的那一条工作流(两者在 kit 内均实际存在)
  • 明确把 fal.ai 调用、本地上载、队列恢复全部路由到 ../fal-ai-generation/SKILL.md;旧的 3D AI Studio API 技能已退役
  • 核心纪律"先确立工件":参考图/网格/材质/程序化模型/运动参考/可编辑动画是不同工件;"生成网格"不等于完成蒙皮、game topology、烘焙贴图或可用导出
  • 模型标识纪律:Higgsfield 的 job type 与 fal 的 endpoint name 是两套标识符,即使可见模型名相似也不可互换;提交前必须向所选 provider 核实模型 ID 与输入 schema
  • 续接纪律:按保存的 provider + job/request ID 续接;轮询超时不算失败作业,不允许重复提交;旧的脚本默认值和 vendor 默认值都不能覆盖用户已做的选择
  • 凭据只来自被 git 忽略的根目录 .env 或 provider 自身登录;产物和溯源信息随 Workspace card 保存
  • 含分享边界:出现在目录中不等于获准发布用户项目、媒体、账户历史或全部已装技能
fal.ai 生成技能(图像/视频/音频/3D/材质的执行层)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/fal-ai-generation/SKILL.md

把需求和本地参考图变成"已下载、已审核"的素材:优先用 fal.ai MCP,MCP 读不到本地文件时改用自带的 Python 队列客户端 scripts/fal_job.py;是本项目 100 USD fal 预算的实际执行技能。

  • 模型选择流程:未指定模型时先调 recommend_model(带真实 task),再 get_model_schema 读精确 endpoint;相似显示名在不同 provider 上不是可互换 endpoint ID;批量提交(尤其视频/3D)前先看定价
  • 运行五步法:检查输入文件→只上传本任务需要的参考→按 live schema 组装字段(image_urls/image_url/aspect_ratio/image_size/resolution/duration 各 endpoint 不同,禁止对所有模型塞同一参数对象)→长作业优先 submit_job 并立即落盘 endpoint、request ID、status/result URL 和输入参数→check_job 轮询、get_job_result 取结果
  • 恢复语义:processing/IN_QUEUE/IN_PROGRESS 是正常态不是失败;等待超时不授权重复提交;提交没返回 ID 时先查账户历史;COMPLETED 结果里仍可能藏着 provider 错误
  • 验收分离:技术完成与视觉验收分开记录;下载产物后才可依赖本地文件而非 CDN 链接;被拒的 take 连原因一起保留;生成的 mesh 仍需独立的 rig/topology/export 检查
  • 命令级自检:python scripts/fal_job.py submit --endpoint ... --input ... --out ... --dry-run 不联网不花钱即可验证安装
  • 每个 job 一份 receipt(job.json),已存在的 receipt 会阻塞再次提交;密钥绝不打印;凭据和原始签名链接不得进入可分享的报告
  • 参考文档路由:参数与恢复看 references/mcp-workflow.md,概念/编辑/材质决策看 references/prompting-and-review.md,换机器连接看 references/setup.md
角色设定图管线(单图→完整 3D 参考包,8 阶段 3 闸门)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/character-sheet-pipeline/SKILL.md

把一个角色图(任意姿势任意风格)扩展成可拼装的严格正面参考包:2K 严格正面 A-pose 主图 + 三视图补充 sheet + 逐部件严格正面拆件 + 可选 side/back 多视图 + 每资产 360° 视频,供下游 Tripo/Hunyuan/Rodin/Pixal3D 图生 3D 使用;V3 增加视觉分类器反 3/4 漂移校验。

  • 最高法则:一切部件 STRICT FRONT 严格正面,绝不 3/4、绝不 hero angle——3/4 部件与正面部件拼不回去;模型跑偏就加强反 3/4 措辞重试,Never ship a 3/4 part
  • 8 阶段 3 闸门:Stage 1 接收确认→2A 严格正面 A-pose 主图→2B 三视图补充 sheet→Gate 1 部件清单确认→Stage 4 逐件提取→Stage 4.5 分类器校验→Gate 2 多视图审批→Gate 3 按报价审批 360 视频→Stage 7 打包+manifest.json(含源图 hash、模型+seed、credit 成本、每次校验 verdict)
  • 模型路由表:2A/4/5 用 Nano Banana Pro(回退 Nano Banana 2,2A/4 绝不用 GPT-Image-2/2.5,保持风格连续以免破坏下游 3D 重建);2B 用 GPT-Image-2.5(fal id openai/gpt-image-2.5/flare/*,回退 GPT-Image-2、Seedream V5 Lite,因其多分格构图更强);Stage 6 用 Seedance 2.0 orbit 模式(回退 Veo/Kling)
  • 部件四分类各有硬性姿态表:body-essential(torso/legs/arms/head,严格正面 A-pose 保证接缝匹配)、paired(hands/boots 成对同框同角度、hands 掌心朝镜头 boots 脚尖朝镜头)、accessory(帽子武器一律正面,禁止 hero shot)、hair(默认提取,opt-out 而非 opt-in,软 alpha 边缘)
  • Stage 4.5 有界重试:每个严格正面输出先过视觉分类器,verdict 分 pass/soft_fail/hard_fail;hard_fail 最多自动重试 2 次(retry 1 同模型+升级 prompt,retry 2 换 Nano Banana 2),仍失败则把 3 次尝试呈给用户三选一;全部 verdict 写入 manifest.json 供审计
  • 成本闸门:Stage 5 多视图使渲染量翻倍(例 9 件正面+10 张多视图=19 张),Stage 6 是最贵步骤(8 件+1 全身=9 次视频渲染),必须先报价再等用户批准
  • 统一技术规范:2K(2048×2048 或最近 1:1)、纯白背景 #FFFFFF、中性平光(禁电影光——阴影会毁掉 3D 法线提取);输出目录结构 00_sheet/01_parts/02_multiview/03_360/ + manifest.json
  • 当前为 V3(2026-05-19);声明自身不含独立生成 runner,分类器用宿主 image inspection 或已配置 vision API 并记录所用方式;作者 Stefan Vaskevich,方法论出自 top3d.ai
Blender 游戏动画技能(绑定、动画、烘焙与引擎交付)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/blender-game-animation/SKILL.md

对交付的 3D 角色做蒙皮、可编辑 action 动画、修订、回放、烘焙和经过验证的 Unity 交付;源自 2026-09-09 验收的 Overlord Wolf 工作,是 3D 管线末端的动画/交付所有者。

  • 先读维护中的流程文档再动手:新动画读 processes/3d-ai/blender-game-animation.md;缺 Mixamo FBX 时先按 knowledge/mixamo-animation-acquisition.md(Archer/Urs/General/Dryad 用过 exact-ID 公共档案+下载器);疑难查 knowledge/blender-game-animation-lessons.md
  • 人的动作参考的既定决策:用 Seedance 2.5 Video Edit,以已验收的角色视频为 motion authority、批准的真人/mocap 服图片为外观,保相机保时序,不从文本重建动作;每条动画对比两条 Seedance 2.5 take + 一条 MiniMax H3 Max take
  • 每个新角色 pack 默认含 Run Turn L/R 与 Idle Turn L/R(owner 2026-09-17);直立体单位用 90 度 Idle turn:后撤步更宽、后脚离地前先有明确躯干旋转(2026-09-18),从既有验收姿态派生,通常无需新运动参考
  • 蒙皮标准:automatic weights 只是初值,须检查松散 mesh island、对侧肢体影响、肩胯过渡与硬质部件(牙齿),剪枝后 normalize 并按目标引擎限制影响数;关节极限/张嘴/弯脊柱弯尾巴要在做全量 clip 之前测
  • 时序显式化:duration = (last_frame - first_frame) / fps,以秒和帧双记录;单改 fps 会改运动速度,转 clip 要在时间上重采样;攻击接触保持同一归一化比例(wolf 例:1.7s、接触帧比 39/51,但明确这是案例不是默认值)
  • 交付验证链:烘焙 evaluated motion 到独立 runtime skeleton、保留可编辑控制 rig;导出检查被静音的 library track/helper bone/地面/相机不泄漏;含 clip 名、时长、loop 标志、root motion、接触事件的 manifest;复制到干净目录重导入验证骨骼/蒙皮/时长/权重/贴图分辨率;源动画批准、导出验证、引擎内集成必须作为三个独立事实报告
  • 9 月 19 日直立体引擎档位:逐 rig 脚步相位匹配、0.35s SmoothStep turn 退出与 Idle settle、固定 2x 步、大转弯中 30% 位移、0.55s 恢复;动物需单独步态评审
  • 动画环节禁止顺手重生成模型或贴图;Set Pose 摆姿工具与常规 Space 回放(每 action 显式 range/fps、save/reopen 后测试)是每个交付的硬性验收项
模板 2A:严格正面 A-pose 主设定图/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/character-sheet-pipeline/prompts/01a_apose_front.md

定义整条管线唯一母图的生成 prompt:全白背景 2K 严格正面 A-pose 全身图,后续所有部件提取都以它为参照。

  • 模型锁定 Nano Banana Pro(回退 Nano Banana 2),明令 NEVER GPT-Image-2/2.5;2K(2048×2048 或最近 1:1)、1:1 方幅
  • Prompt 骨架内嵌可验证的正面判据:双肩等宽、双脚等角、双眼直视镜头、手臂约 45° 下外展(非 T-pose 非垂臂)、掌心朝镜头、脚尖朝前、eye-level 零透视、#FFFFFF 无地面阴影、中性漫射光
  • {CHARACTER_DESCRIPTION} 替换规则:intake 时构建,必含性别呈现、视觉年龄、艺术风格(realistic/stylized/anime/cel-shaded)、关键服装、配饰、色板
  • 约 23 项 negatives 清单(no three-quarter/no body twist/no contrapposto/no hero pose/no foreshortening 等),按各模型语法追加
  • 10 项质量 checklist;末条规定:3 次尝试仍不 hold 严格正面就升级给用户,DO NOT ship a 3/4 sheet
模板 2B:三视图补充设定图(16:9)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/character-sheet-pipeline/prompts/01b_character_sheet.md

给用户的视觉辅助:一张 16:9 图内横排 front/side/back 三个正交投影 + 配饰单独铺开标注,供部件确认 gate 指认和多视图姿态参照。

  • 模型 GPT-Image-2.5(2026 年 9 月起默认,fal id openai/gpt-image-2.5/flare/*),回退 GPT-Image-2 再到 Seedream V5 Lite;明确它不是部件提取的输入(2A 图才是)
  • 三投影构图规则:front 占左三分之一、side 为右转 90°(相机看到角色左侧)、back 为 180° 正背面,三者脚在同一 ground line,A-pose 全程保持
  • 配饰以隔离物体画在图右侧并逐个加名称小字标注({ACCESSORY_LIST} 来自 intake 检测;无配饰则整段省略)
  • 构图失败(视图重叠/各视图换脸)重试 2 次后落 Seedream V5 Lite,再失败则升级用户
模板 Stage 4:body-essential 部件(torso/legs/arms/head)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/character-sheet-pipeline/prompts/02_parts_body.md

四个身体必需部件的逐件严格正面提取 prompt,保证与 2A 母图同角度从而接缝可拼。

  • 全部 Nano Banana Pro + 2K + 强制附 2A 母图作 reference;每件有独立模板:torso 颈根到髋顶、切口干净无悬垂布片;legs 双腿同框脚尖朝前;arms 到腕为止、手不含(另提取);head 表情中性、闭嘴睁眼、含发不含身
  • 最常见失败模式被点名:模型会旋转部件(most common failure: model rotates the part)——checklist 首项是可验证的严格正面(部件两侧等宽/等角)
  • 失败处理:漂到 3/4 就加强 STRICT FRONT 锚点+反 3/4 负面重打,NEVER ship a drifted part;3 次仍漂移升级用户可选跳过或带警告接受
  • V3 条款:输出必须先过 Stage 4.5 分类器,hard_fail 的件不得出货;重试逻辑在 08_3q_classifier.md
模板 Stage 4:成对部件(hands/boots/手套护手)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/character-sheet-pipeline/prompts/03_parts_paired.md

左右成对物品的提取规则:成对同框、特写裁切,但两件必须处于同一严格正面角度。

  • 与身体件的区别:paired 允许更近的特写换细节清晰度,但角度纪律不变——若左手正面右手 3/4,管线就无法重新装配
  • hands 模板:掌心对镜头 dead-on、左左右右同框标注、手指放松微张;boots 模板:脚尖对镜头、带正面可见的扣带鞋底细节
  • 非对称对(一手套一护手)有通用 {LEFT_ITEM_NAME}/{RIGHT_ITEM_NAME} 模板,要求标注左右
  • negatives 含类别特有项:no inside-palm tilt(手)、no outer-sole tilt(靴)、除非母图如此否则 no clenched fists
模板 Stage 4:配饰(帽/武器/背包/披风/珠宝)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/character-sheet-pipeline/prompts/04_parts_accessory.md

六类配饰的严格正面提取模板;配饰是历史漂移最重的类别,此文件是 V2 教训的落点。

  • 规则:即使配饰也一律先严格正面——帽子按戴在正面角色头上的朝向、单手武器 blade-front 全长按技术参考图呈现、披风平铺或隐形衣架、珠宝 macro 特写;side/back 只属于 Stage 5 且需用户点名
  • 明确记载 V2 的错误决定及纠正:早期版本允许配饰 3/4(理由是用户可在 3D 里转回去),实际迫使手动转回正面并劣化参考质量,故 STRICT FRONT 是唯一基线
  • V3 强制条款:配饰必须过 Stage 4.5 分类器不得绕过——V2 数据显示 accessories 是最高漂移类别
  • 所有模板要求隔离呈现:no character body parts visible、无角色穿戴(帽是 standalone 但按佩戴朝向摆位)
模板 Stage 4:头发提取(默认开启)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/character-sheet-pipeline/prompts/05_parts_hair.md

把头发从头部剥离为独立严格正面参考图,供专门的毛发 3D 管线使用,避免图生 3D 模型把头发糊成与头融合的块。

  • 默认 ON、只能 opt-out 不能 opt-in:跳过头发默认导致更差的 3D 输出;可提取的下游用途明确列出(XGen、Hair Tool、Genesis hair、hair cards 贴图参考、手工单独建发)
  • Prompt 要点:同时附 2A 母图和 head 提取件;像从头拿起来悬浮在空中但从正前方看;发丝与空气交界处必须 soft alpha edges,negatives 明令 no harsh outline/no clean silhouette cut
  • 仅三种情况可跳过:角色秃头、头发完全被帽/兜帽遮住(改提取帽兜)、用户在 Gate 1 显式 opt-out;短发贴头皮、动漫刺发、辫子、kitsune 耳朵都要提取
  • 长马尾/辫子/背后造型在 Gate 2 批准后加做 side+back(Stage 5),背面剪影与正面差异大时价值最高
模板 Stage 5:逐件多视图(side 90°/back 180°,闸门控制)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/character-sheet-pipeline/prompts/06_multiview.md

为 Gate 2 批准的部件生成严格正交 side/back 视图;同样是正交视图,3/4 在此同样被禁止。

  • Gate 2 交互协议:默认提案为 body-essential 四件+hair 各配 side+back;用户可回复 default / add: [parts] / remove: [parts] / skip all / side only,等待明确答复才继续
  • 闸门理由给出量化渲染成本:9 件正面+5 件双视图=19 张,每张都耗 credit,用户必须对体量知情同意
  • side 必须是精确 90° profile(不是 80° 不是 100°)、back 是精确 180°(不是 back 3/4);模板要求附 2A 母图+该件的 Stage 4 正面件双 reference,切口与正面件同一解剖地标
  • 含 head、hair、accessory 的专用 side/back 变体模板;通用 negatives 独有 no 45° angle 一项
模板 Stage 6:每资产 360° 转台视频/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/character-sheet-pipeline/prompts/07_360_video.md

生成 Blender/Marmoset turntable 式参考视频:相机锁死、主体自转 360°,是成本最高、也最容易被视频模型的电影化倾向毁掉的阶段。

  • 硬规则:Camera LOCKED、主体绕自身垂直轴顺时针转满 360° 回到面对镜头;视频模型默认会 dolly/加戏/灯光漂移,全部与参考转台相反,这是本步骤被称为最难的原因
  • 参数:Seedance 2.0 orbit 模式(回退 Veo、用户点名则 Kling)、4-6 秒、1:1(高瘦资产用 9:16)、以该资产静帧作首帧锚定、全程纯白背景中性平光
  • 三类 override:全身角色 5 秒 A-pose 不变、小物件(戒指珠宝)4 秒柔和顶光 macro、长资产(武器法杖披风)绕长轴垂直摆放 5 秒
  • 不合规升级链:锁相机 2 次失败后依次改用 tripod-mounted security camera 措辞、加唯一运动是主体旋转显式反运动条款、缩到 3 秒减少漂移窗口、最后落 Veo orbit mode
  • 成本条款:8 件+1 全身=9 次视频渲染,Gate 前报价,cheapest opt-out 是仅全身;全身 360 先渲染,用作部件 360 姿态漂移的对照
模板 Stage 4.5:视觉分类器与反 3/4 升级重试(V3 核心)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/character-sheet-pipeline/prompts/08_3q_classifier.md

定义每张严格正面/多视图输出的结构化验尸 prompt:分类器输出 JSON verdict,驱动有界自动重试环,是 V3 修补 V2 加强负面词仍挡不住 3/4 漂移缺口的机制。

  • 三套 rubric:strict-front 六项二值检查(body_axis_dead_front/no_three_quarter/no_body_twist/no_hero_angle/no_partial_back/framing_clean);side rubric 查 90° 精确度和两种 3/4 中间态;back rubric 查 no_partial_face 等
  • 判定规则:6 项全过=pass;1-2 项轻微=soft_fail 带警告接受并记 manifest;第 1/2/3/5 项任一明显失败=hard_fail;第 4/6 项单独失败通常 soft_fail
  • 输出为纯 JSON(含 estimated_camera_rotation_degrees 带符号估计旋转角),无散文无 markdown fence;文件自述只提供 rubric 不含部署的分类器服务,用宿主 image inspection 或已配置 vision API 并记录方式
  • 升级重试 prompt 模板把分类器失败原因和旋转度数原样写进 [CRITICAL CORRECTION] 头部再拼原 stage prompt;Retry 1 同模型、Retry 2 换 Nano Banana 2、再失败给用户三选一(带警告接受/自定义指令再来一次/跳过)
  • manifest 逐件记录 attempts 数组(model+verdict+reason+image_hash)、final_verdict、retry_count、accepted_image
  • 成本与边界:每次校验约 1-2 美分(GPT-4o-mini-vision 档)、10 件约 15% hard_fail 率≈12 次调用,远廉于一次 Nano Banana Pro 重生成;用户可显式跳过校验(记 manifest);Stage 6 视频不自动分类,改人工过目
  • 默认选 GPT-4/5 vision 而非 Claude vision 的理由:管线在 Stage 2B 本就要求 OPENAI_API_KEY,且 JSON 严格输出在 GPT-4o/5 上成熟;rubric 可移植,改用 claude-opus-4-7 vision 保持 prompt 不变即可
fal MCP 工具清单与恢复流程参考/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/fal-ai-generation/references/mcp-workflow.md

列出 2026-09-15 验证过的 fal.ai MCP 工具面、按阶段给出必备入参,规定队列恢复动作和凭据头格式边界。

  • 8 个 MCP 工具映射到阶段:recommend_model(task)/search_models/get_model_schema(endpoint_id)/get_pricing/upload_file/run_model(提交并短等)/submit_job(不等待)/check_job(endpoint_id+request_id+status_url)/get_job_result(可带 response_url);工具名可能被宿主加前缀,要现场 discover 而非硬编码
  • 额外验证过的路由示例:fal-ai/patina/material(文生材质,必填 prompt,含 maps/image_size/tiling_mode/output_format,与处理图像的 fal-ai/patina 不同);tripo3d/h3.1/image-to-3d(必填 image_url,几何/贴图质量、PBR、朝向、面数为独立控制)——用来说明输入必须跟实际 operation 走
  • 可用的忠实编辑示例入参:endpoint fal-ai/nano-banana-pro/edit,字段 prompt/image_urls/aspect_ratio:auto/resolution:2K/num_images:1/output_format:png,并声明字段是当时 live schema 的快照、下次用要复查、禁止提交 example.invalid 占位 URL
  • 本地上载标准命令:python scripts/fal_job.py --env /path/to/project/.env upload --file reference.png --out reference-upload.json,从保存的 JSON 读 url;大 base64 不进对话;localhost URL 不是公网 URL
  • 恢复纪律:IN_QUEUE/IN_PROGRESS/processing 都表示继续原请求;COMPLETED 后先查结果里的错误;下载失败重试同一 result,禁止为重下而重新生成;提交结果未知先查账户历史;取消是单独的用户授权动作
  • 凭据三格式不可混用:fal 托管 MCP 用 Bearer 头,REST 模型 API 用 Authorization: Key,Python SDK 读 FAL_KEY;MCP 不共享聊天应用订阅,生成走接收者自己的 fal 账户
Prompting 与交付评审参考/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/fal-ai-generation/references/prompting-and-review.md

规定概念探索、忠实编辑、材质、mesh、运动参考五类任务的 prompt 写法和交付前人工评审清单。

  • 概念探索只变有意义的设计维度(silhouette/比例/构造/色板/氛围),候选要标注使用户无需重打 prompt;模型能多生成不是扩批的理由
  • 忠实编辑:点名什么保留、精确改什么,复用已验收图而非长文重建;多参考要分工(body 来自 A、material 来自 B、pose 来自 C);材质编辑保持 mesh/剪影/相机/背景不动
  • Patina 材质生成、mesh 重贴图、mesh 生成是三件事不能互替;不得用高模生成承诺 game-ready mesh;PBR 贴图要逐通道确认分辨率、UV、色彩空间与法线惯例,高模细节烘焙到低模后单独验证导出材质
  • 运动参考:写明起始姿势、动作、接触/恢复、相机、时长;真人/服装转移用已验收视频作 motion authority;新生成 clip 是视觉参考不是测量 mocap 数据,可读源运动与更短的游戏时序分开保持
  • 交付评审 7 条:全尺寸对照输入与 brief、核对数量/取景/身份/缺件/多余件、确认每个文件可打开且报告链接真实文件、每输出一个 verdict 并记录取舍原因、只改失败判据不推翻已批特征、到请求量即停、绝不藏失败 take 或不检查就宣布批准
跨项目接入 fal.ai 的环境配置参考/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/fal-ai-generation/references/setup.md

说明如何把整个 fal-ai-generation 文件夹复制到其他项目并完成 MCP 与 Python 两条链路的连接。

  • MCP 连接:fal dashboard 建 key(inference/API scope),Streamable HTTP 端点 https://mcp.fal.ai/mcp,Authorization 头填 Bearer <key>;勿与文档连接 https://docs.fal.ai/mcp 混淆;要在活会话里确认 get_model_schema 等工具存在,配置文件本身不证明连接
  • key 的传递方式:原仓库 .env 里放 MRMAK_MCP_FAL_AUTHORIZATION(完整 Bearer 值),.mcp.json 用 ${MRMAK_MCP_FAL_AUTHORIZATION} 展开、Codex 用 env_http_headers;根 .env 不会被每个 MCP client 自动读取;合入既有配置而非覆盖其 servers
  • Python helper 要求 3.10+:python -m pip install -r scripts/requirements.txt 后 python scripts/fal_job.py --help;key 读取顺序 FAL_KEY→legacy FALAI_KEY→MRMAK_MCP_FAL_AUTHORIZATION,--env 显式指定 .env,凭据绝不打印
  • 免费自检命令:python scripts/fal_job.py submit --endpoint fal-ai/nano-banana-pro --input examples/concept.json --out output/concept --dry-run——不 import SDK、不联网、不建付费 job;真实 submit 消耗账户 credits
  • 分享纪律:只分享干净源目录,绝不分享含 .env 或私有 receipt 的工作目录;receipt、上载记录和生成媒体留在接收者自己的任务目录
示例任务演练:一次小型 fal 生成/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/fal-ai-generation/examples/WALKTHROUGH.md

给出一个不花钱的排练脚本和一条真实生成后的续接命令序列,教会 agent receipt→status→result 的标准节奏。

  • 示例任务:一个 brass observatory robot(望远镜头、三足、蓝色机身),先查 live schema,本地保存结果+prompt+request ID,编辑决定留到用户看完
  • 排练命令 dry-run 预期输出:dry_run: true + endpoint + input 字段名;明确这验证的是 helper 安装而非账户权限
  • 真实流程:省略 --dry-run 后 receipt 在 output/robot/job.json;续接用 python scripts/fal_job.py status --job output/robot/job.json 和 result --job output/robot/job.json,result 下载媒体到同一任务目录,检查对象之前不算 accepted
  • 编辑路径:上传选中的本地文件→用保存的 upload URL 替换 edit.json 占位→检查 edit endpoint→开新任务目录
  • 自述诚实性声明:包内没有样例渲染,验收标准(完整机器人、望远镜头、三足、蓝身、可读剪影;编辑只改漆色)是排练 brief 不是已生成的断言
示例输入:文生概念图(Nano Banana Pro)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/fal-ai-generation/examples/concept.json

一个中性的文生图输入文件,演示 text-to-image endpoint 的字段形状,无私有美术与真实账户 URL。

  • 字段组合对应 Nano Banana Pro 概念端点:prompt + aspect_ratio:1:1 + resolution:2K + num_images:1 + output_format:png
  • prompt 本身示范参考级写法:单一完整物体、居中、中性背景、柔和均匀光、可读剪影、no lettering
  • 被 setup.md 和 WALKTHROUGH.md 的 --dry-run 命令直接引用,作为零成本安装自检的输入
示例输入:忠实编辑图/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/fal-ai-generation/examples/edit.json

演示编辑 endpoint 的输入形状:prompt 显式声明只改什么、保住什么,参考图字段留占位符。

  • prompt 模板示范忠实编辑句式:Keep the exact same object, proportions, camera, background and lighting. Change only ... Preserve ...
  • image_urls 是 https://example.invalid/replace-with-your-upload.png 占位符——fal_job.py 的 submit 对含 example.invalid 的输入会直接 raise ValueError 拒绝提交,测试用例专门验证这条防线
  • 字段与 mcp-workflow.md 的 nano-banana-pro/edit 示例一致:aspect_ratio:auto、resolution:2K、num_images:1、output_format:png
fal 队列辅助脚本 fal_job.py(214 行)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/fal-ai-generation/scripts/fal_job.py

不依赖 MCP 的独立 Python 客户端:本地文件上载、队列提交、状态轮询、结果下载,全部围绕一份可续接的 job.json receipt 设计,核心目标是防重复扣费。

  • 四个子命令:submit(--endpoint/--input/--out,支持 --dry-run)/ status --job / result --job / upload --file --out;输出均为单行 JSON
  • 防重复提交机制:receipt 以 open(x) 独占创建,已存在即拒绝再次 submit;提交抛异常时 receipt 保留并标 status=submission_unknown,强制先查账户历史;example.invalid 占位符输入直接拒发
  • submit 的 dry-run 分支在任何 import fal_client/dotenv 之前返回 {dry_run:True, endpoint_id, input_fields:sorted(inputs)}——零网络零 SDK 零付费;真实 receipt 记录 provider/endpoint_id/完整 input/created_at,成功后补 request_id 与 status_url/response_url/cancel_url
  • key 解析:依次查环境变量再查 --env 指定(或仅 cwd)的 .env,名字容忍 FAL_KEY/FALAI_KEY/MRMAK_MCP_FAL_AUTHORIZATION,正则剥掉 Bearer/Key 前缀后写回 os.environ[FAL_KEY];异常输出只报类型不带 SDK 原文(防签名 URL 泄漏进对话)
  • media_urls() 递归发现嵌套结果里的媒体:dict 带 url 字段、以 _urls 结尾的 key(如 model_urls)、https 字符串列表——测试专门验证 model_urls.glb 与 map_type:normal 这类 3D/PBR 结果能被收齐
  • download_result():只允许无内嵌凭据的 https、按 sha256(url)[:10] 命名、.part 临时文件原子落盘、单文件 512 MB 上限、按 content_type 猜扩展名;result.json 已存在时离线复用(队列历史过期后仍可取);结果含 error/error_type 时标 provider_error 并 raise,绝不静默下载
  • upload 幂等:按源文件 sha256 比对已有 receipt,同文件复用 URL、异文件要求换输出路径
Python 依赖清单/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/fal-ai-generation/scripts/requirements.txt

fal_job.py 的全部运行时依赖,刻意保持最小。

  • 仅两个依赖:fal-client>=0.13.2,<1(官方 SDK,读 FAL_KEY 环境变量)与 python-dotenv>=1,<2(解析 --env 指定的 .env)
  • 上限锁定(<1、<2)防止 SDK 大版本破坏 queue API 调用签名
  • 被 references/setup.md 的安装命令直接引用:python -m pip install -r scripts/requirements.txt
fal_job.py 的单元测试(8 用例)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/dot-claude/skills/fal-ai-generation/scripts/test_fal_job.py

用 unittest + Mock 固化 fal_job.py 的每条防扣费/防误判行为,使这些纪律在后续修改中不可回归。

  • test_dry_run_never_loads_sdk_or_writes_receipt:patch client 抛 AssertionError 证明 dry-run 路径不加载 SDK,且连输出目录都不创建
  • test_existing_receipt_blocks_duplicate_submission 与 test_uncertain_submission_keeps_guard:receipt 存在即拒(ValueError);提交异常后 receipt 状态为 submission_unknown、异常原文(private provider details)绝不写入 receipt、后续 submit 仍被拒且 sdk.submit 全程只调用一次
  • test_processing_result_never_fetches_or_resubmits:状态 IN_PROGRESS 时 result 命令不调 sdk.result 也不调 sdk.submit——落实超时不是失败纪律
  • test_completed_provider_error_is_not_downloaded:COMPLETED 但结果含 error 时 download_result 不被调用并 raise;test_placeholder_is_not_submitted:example.invalid 输入拒发
  • test_nested_models_and_material_maps_are_discovered:media_urls 对 map_type:normal 图片和 model_urls.glb 的收集顺序断言;test_saved_result_does_not_require_provider_history:本地 result.json 存在时零 provider 请求返回 result_saved + review:pending

知识经验库 knowledge/ · 9 篇

全部来自所有者前一个 Unity 项目 Overlord(2026 年 3–9 月)和若干代理基准测试。价值在于这些数字是真实返工换来的。

3D 生成偏好 — owner 的固定口味(2026-08-28 记录)/tmp/woc_kit/WorldOfOldcraft-build-kit/knowledge/3d-gen-preferences.md

记录 owner 对 AI 3D 资产生成(Customuse MCP + fal.ai)的默认决策,避免每次重新询问模型选择;定义了被锁定的烘焙降面管线(bake-down pipeline)。

  • 术语必须区分:Patina(fal.ai)是给网格做材质的工具(owner 最爱),与 Meshy 7 retexture(Customuse 的 textureGeneration 节点)不是一回事。
  • 锁定的管线(2026-08-28):1) Tripo v3.1(tripoV31Mesh3d)高模 faceLimit≈300k、自带 4K 贴图,质量优先;2) meshDecimation(Blender Collapse)把 prop 降到约 5-9k 面;3) uvUnwrap(xatlas 默认);4) textureBaking:源=带贴图高模,目标=展开低模,bakeChannel ["all"](basecolor/normal/roughness/specular/metalness),2K。
  • 最终游戏资产是 bake 节点的输出,不是生成的高模。CR1 在 Map01 prop 批次上被 owner 直接否定("bad"),由此锁定此管线。
  • 纹理/材质默认必须用 fal.ai 的 Patina,除非 owner 明确另说;Customuse 上可并行测试 Tripo v3.1 一体出图和 Meshy 7 retexture 两个变体做对比。
  • Tripo P1 仅作为低风险快速 prop 的备选。工作流在 Customuse canvas 上组装,结果(GLB/FBX/贴图)交回本地项目。
图像生成经验(fal.ai / Nano Banana 等)/tmp/woc_kit/WorldOfOldcraft-build-kit/knowledge/image-gen-lessons.md

记录经实测的图像生成 API 细节、模型轮换策略、3D 参考图的 prompt 默认值和报告规范,直接可用于本项目的概念图/贴图生成。

  • API 细节:生成用 fal-ai/nano-banana-2(aspect_ratio 参数);编辑端点 fal-ai/nano-banana-2/edit 需要 image_urls(复数数组),写成单数 image_url 是常见错误;Pro 版为 fal-ai/nano-banana-pro。
  • 粉丝向/IP 编辑:fal-ai/nano-banana-pro/edit 加 safety_tolerance: "6"(字符串,最大宽松度)+ enable_web_search: true + resolution: "2K"。但 prompt 侧内容审查(422 content_policy_violation)在生成前触发,safety_tolerance 绕不过——品牌词是常见触发器("Chevy V8 valve cover"、"classic American V8" 被拒,改为纯描述性措辞立即通过),材质 prompt 必须去除品牌/IP 词。
  • 背景移除正确端点是 fal-ai/imageutils/rembg(bria/background/remove 和 fal-ai/bria-rmbg 均 404)。上传用 fal_client.upload_file() 拿远程 URL。
  • 模型轮换(2026-08-20 更新):概念探索默认组合是 nano-banana-pro + grok-imagine-2 + seedream-v5-pro 同 prompt 并排对比;GPT-Image-2 被降级。Grok Imagine 2 的 t2i 路径必须带 /text-to-image 后缀(xai/grok-imagine-image/v2.0 返回 "Path /v2.0 not found")。
  • 永远并行生成:ThreadPoolExecutor 5+ workers,21 张图串行约 10 分钟 vs 并行约 30 秒;results.json 里必须保存远程 URL。
  • 3D 参考图 prompt 默认:纯色中灰背景(不是白/黑/花纹);风格锚定语 "stylized 3D Unreal Engine 5 render, non-photoreal, not cartoon";色彩写明 60/30/10 比例。A-pose( arms 偏离身体 30°)与 variant A(A/B/C 变体第一个)是两个概念,绝不能混淆。
  • 风格关键词与参考保真度成反比:忠实复刻要剥掉所有风格关键词、以 "recreate the exact X, do not redesign" 开头(Akira 项目 v3 加 Arcane/Guilty Gear 风格词导致角色不可辨认,v4 剥离后正确还原 Kaneda 摩托);探索阶段风格词才是有用的杠杆。
Mixamo 动作源获取(按 UUID 精确下载)/tmp/woc_kit/WorldOfOldcraft-build-kit/knowledge/mixamo-animation-acquisition.md

定义获取 Mixamo 动画 FBX 的标准路径:本地缓存 → HuggingFace 公共档案 → 精确 UUID 下载器;最后才请求 owner 手动下载。Overlord 的 Archer、Urs、mounted General 已验证此路线。

  • 顺序:1) 查已接受参考目录记录 Mixamo motion UUID(名字有歧义,必须用 UUID);2) 搜本地 ArtSource/Characters/*/Source/Animation/Mixamo/ 缓存及 downloads.json 回执;3) 用 HuggingFace 数据集 Linzhan/Mixamo-Animations-Characters(metadata.csv 映射 motion_id/prompt/description/frames/file);4) 跑 scripts/animation/download_mixamo.py --motion-id <uuid>,按精确 UUID 下载、校验 FBX 二进制头、写 SHA256 到 downloads.json、拒绝覆盖不同文件;只需 requests,无需登录/API key。
  • Dryad 已验证样本(档案 revision 7f134bc734557b1d9516cb476d25ea1f577e45c1):Standing 2H Magic Attack 03(UUID e21d35a0-…)130 帧/4.3s;Standing Idle 03(51e30f03-…)343 帧/11.4s;Standing React Death Forward(586a54c0-…)111 帧/3.667s;均为 30 fps、每 1/30 秒一个 key、315 条曲线(含常量通道)。
  • 导入到已有的 Blender 实例检查动画曲线、时长、key 间距,只删临时导入对象,保留 owner 编辑/当前 Action/帧号;不要为接收另开 Blender。
  • 许可标注为 adobe-mixamo-terms,不得把动画文件描述成 CC0 或新许可。
  • 9 月 24 日教训:路线曾被埋在旧脚本里,agent 没找到、不必要地让 owner 手动下载 3 个文件。绝不可静默用名字相似的动作替代(Archer 的 Standing_Idle_03_Examine.fbx 不是 Dryad 的 Standing Idle 03 / Playing With Magic)。
Blender 游戏动画:经实测的经验(Wolf/Scorpid/Warrior/Urs/Dryad 案例集)/tmp/woc_kit/WorldOfOldcraft-build-kit/knowledge/blender-game-animation-lessons.md

最大的经验文件(367 行):从 Overlord 已批准的 Wolf、Scorpid、Skeleton Warrior、Urs、Dryad 等交付中沉淀的 Blender 绑定、权重、烘焙、导出、播放与评审的可复用教训。测试环境 Blender 5.1.0。

  • 四足基线(2026-09-10 owner 批准的 Wolf rev 07):9 条起步 clip(Idle/Run/Attack/Death/Walk/Turn L/R/Run Turn L/R);Run 由实际平面距离的单一归一化相位驱动、按转向曲率混合不重启循环;Wolf 批准步幅 45°×30 帧间隔×2=90°@30fps;Run 保留艺术标定 2m 步幅(原生 scale-2 实测 1.05m)、Walk 每循环 0.68m;58 条运行时断言 + 279 个采样姿态通过。这些数值是 Wolf 标定,不可照搬。
  • 权重:热权重初绑后必须解剖清理(对侧肢体泄漏、肩部权重进鬃毛、牙齿要刚性绑到正确上下颌骨);剪枝到 4 influences 后再查一遍。Wolf 最终源网格 9,209 焊接顶点/17,835 三角面,glTF 导出 23,663 顶点(接缝导致),导出顶点数变多不等于几何重复。
  • 计时纪律:数时间区间而非样本数——0-51 帧是 52 个样本 51 个区间,30fps 下 1.7s;接触帧 39 → 1.3s、39/51=0.7647058824。改节奏到 T 秒时速度用 1.7/T、接触时间 T*39/51。24→30fps 若只改场景设置会缩短循环,必须重采样(保留 Idle 2.5s、Run 0.833333s)。
  • 烘焙导出:作者 rig 38 骨、游戏文件 28 骨无约束;Root 和 Body 虽不形变也要保留(携带层级与局部运动)。验收标准:拷贝目录后 FBX/GLB 在干净场景重导入,21 个采样姿态误差 <0.000001m(FBX 实测约 5.6e-7m、GLB 约 7.6e-7m)。
  • 导出后验证纹理必须真实加载像素(packed glTF 在像素访问前报 has_data=False 是误报);Blender glTF 导入器会生成 BoneShape 辅助网格,报"多余角色网格"前先核对 GLB 原始 mesh/skin 列表;拷贝文件夹测试防纹理从旧目录解析。
  • 几何修复教训:Wolf Run 后腿在 14-16 帧折叠是 thigh/shin IK 求解接近奇异——是 rig 问题不是权重问题(先查骨骼轨迹再重画权重);膝盖 pole 直接取 thigh 向量会在大后撤步时翻转,要先去掉沿 hip-to-ankle 轴的分量再投影。Urs 转身:钟形胸偏移叠加变化的骨盆 yaw 会让胸朝向短暂倒退,胸的绝对朝向要单独定义并检查单调性。
  • Blender 5.1 specifics:复制 rig 要显式绑定 action slot;复制的 IK target 保持局部;未用的播放场景加 fake user 防丢失;Bone.vector 是父级相对坐标,armature 空间方向要用 bone.tail_local - bone.head_local(搞混会把盾牌和肩甲转错)。
  • 动作切换会继承变换:旧 Action 没有手指通道时,从新姿势切回会残留约 100mm 手指位移——给旧 Action 缺失通道补常量 key,别假设未打 key 的通道会自动复位。Dryad 的 Mixamo 命名 RightUpLeg 实际是下躯干不是腿;施法预览范围要先开 use_preview_range 再设边界(Dryad 用 40-87、闭合 88)。
  • MCP 备用路线(owner 2026-09-14 确认):Higgsfield Blender 连接掉了先试常规 Blender MCP(随 Blender 自动启动);交互式桥不保留跨调用的 Python globals;长调用超时但 Blender 仍在跑,用保存的脚本/日志/进程检查避免重复劳动;后台 --factory-startup 隔离第三方插件。
Overlord 角色动画评审经验(2026-09-15~19 评审汇总)/tmp/woc_kit/WorldOfOldcraft-build-kit/knowledge/overlord-character-animation-reviews.md

从 Wild Skeleton、Human Swordsman、Human Archer、Urs、Mounted General 五轮 owner 评审中汇总的作者决策与评审纪律,规定 carry pose、步态、重心转移、转场修复和交付习惯。

  • 先检查打开的 Blender 文件再动手:磁盘版本可能早于 owner 的实时修改,先抓可恢复副本;后续贴图包只换外观、保留已批准运动;换 Action 前核对骨骼名/rest 变换/绑定兼容。
  • 动作必须从 RTS 俯视角读得出来(2026-09-24 重申):以游戏尺寸判断,别把迭代花在上看不见的小幅;肩/头引导+延迟的手部可让软体或扎根生物显活。
  • carry pose 先于动作库:手全程握住道具,Wild Skeleton 双手剑握持保留,Archer 双弓击打命中瞬间弓更水平、bow 留在源盾牌手。Urs 同侧手脚运动被拒——普通两足 Run 前臂必须对侧前腿。
  • Warrior 步态修复实例:保持步频缩短步幅后,站姿膝弯均值从 61.4° 降到 28.8°;修订后 1.5m/0.6s 的 Run 在 visual scale 1 下 3.5m/s 需要 1.4x 采样。'elbow inward' 被误解为内侧 pole 拉向肋骨遭拒(owner 意思只是掌心朝前的垂臂)——旋转歧义要拿现场演示姿势确认。
  • 转场要修整条链不是只修端点:Archer Shot 第 14-19 帧抖动涉及躯干+手臂;死亡膝不能先内塌再反向;Archer 55 帧 Death Right、Swordsman 60 帧 Stun 是个例不是模板。+15% 提速 = 时长除以 1.15。
  • Mounted General 教训:Review 03 的自定义 IK solver 被拒——它在每个 timer tick 覆盖直接手臂编辑;Review 04 改用真实肩/肘/腕骨的直接 FK、暂停所有动画同步后被 owner 批准并要求所有后续评审沿用(2026-09-20)。盾牌是 549 顶点的刚性集合,由 hand 父级 shield_grip 骨独立携带;owner 在 Idle 第 102 帧亲手做的 carry 要在全部 22 条 clip 保留。
  • 交付习惯:主人直接在 Blender 里审——留正确文件、选好 Action、普通空格播放、保存中性 Material Preview,不做评审视频;结束前做拷贝包重导入+采样姿态对比+可移植纹理;用户批准、源 QA、导出 QA、Unity 集成四件事分开记录,检查通过不等于视觉验收。
四足转向集成(Wolf Turn90_01,2026-09-19)/tmp/woc_kit/WorldOfOldcraft-build-kit/knowledge/overlord-quadruped-turning.md

记录 Wolf 90 度转向 clip 集成进 Unity 的具体规则:相位匹配表、转向出口混合、与双足标准的差异,以及 FBX 100x 缩放导致的包围盒误报。

  • 补充转向 clip 单独导入,保留既有模型/Avatar/材质/步态/战斗 clip;核对骨骼路径、帧原点、时长、小数帧 key、静止 Root 和带符号 heading 曲线。
  • 玩法用独立导航 yaw + 每角色固定 authored 步频(默认 2x;Wolf 4x)。绝不为等完整源转向而延迟移动;保持重复指令下的相位和即时战斗/Stop/死亡打断权。
  • 双足的两脚/两膝匹配表对动物不完整:Wolf 用四爪+前臂+小腿+hock 相对 Body 匹配;每种移动步态烘焙 64 个采样姿态、只在转向出口匹配,不逐帧搜索姿态;直行/左/右 Run 共享同一相位。
  • 转向出口/停止用完整 0.35 秒有限 SmoothStep 混合,要检查中间帧的实际肢体变换而不只是 mixer 权重。Wolf 平衡参数独立保留:4.4 m/s、误差超 30 度时 20% 平移加速、即时释放、360 度/s 转向。
  • 陷阱:Wolf 导入网格 transform 是 100x——BakeMesh 审计包围盒要补偿缩放并把顶点变换到实际根骨坐标,直接拿原始烘焙顶点比 localBounds 会误报 overflow(改正后无需改 prefab bounds)。
  • 这是相位匹配,不是 foot IK 或接触锁定声明;步态 clip 一旦改动必须重建姿态表。
Unity 输入回放安全(EditorInputReplay,2026-09-19)/tmp/woc_kit/WorldOfOldcraft-build-kit/knowledge/overlord-unity-test-input.md

自动化输入测试把真实键盘鼠标锁死的事故复盘与恢复协议;CLAUDE.md 第 8 节明确引用,是本项目所有自动化 Play Mode 测试必须逐字复用的规则。

  • 事故:被中断的 Editor 输入测试让 'Unit lab test mouse' 和 'Unit lab test keyboard' 保持激活、真实设备被禁用,玩法点击/UI/滚轮缩放全部失灵,与选择几何无关。
  • 不要只依赖 MonoBehaviour 字段或协程完成做清理:脚本重载会丢字段,嵌套迭代器失败可能绕过外层协程的 cleanup。
  • 共享 EditorInputReplay 辅助器规则:接管输入前捕获启用设备 ID、当前 pointers、输入设置、dirty 状态、time scale,恢复数据持久化到 Editor SessionState;在脚本重载前、Play Mode 退出、组件 disable/destroy、正常完成和失败时全部恢复;嵌套迭代器同受 finally 管辖;拒绝重叠回放;保留刻意预先禁用的设备。
  • 测试后必须验证硬件所有权,即使断言全部通过——合成设备还是 current 时绝不允许报告输入 QA 完成。
  • EditorInputReplayChecks.Run() 用 8 个同步清理用例覆盖,不排队点击/游戏指令。
直立单位运动:转向出口要匹配脚部相位(2026-09-18 批准的标准)/tmp/woc_kit/WorldOfOldcraft-build-kit/knowledge/overlord-upright-locomotion.md

owner 批准的直立单位(人类/骷髅/双足 Urs)转向-行进相位匹配集成标准,含每角色一次性配置流程和 2026-09-19 批准的五角色共享数值档案。

  • 问题:转向可在 clip 任意点结束,恢复任意背景的 Run 相位会换领先脚、产生可见跳变,加长 crossfade 解决不了。方案:交接瞬间从与当前可见腿部姿态最接近的 Run/Walk 相位起步,再按距离推进步态;比较双脚+双膝相对髋部(排除 controller yaw、世界位移、装饰性 turn retreat),匹配最后一次评估的混合结果。
  • 每角色一次性配置:在真实导入 rig 上辨认髋/脚/膝并验证前向轴与骨骼路径(Urs baker 用 Mixamo 骨名,其他 rig 要显式映射);每步态烘焙 64 采样共享姿态表,脚全权重、膝四分之一权重;只在离开转向时选最近相位,已有的更好相位要保留。
  • 共享档案(2026-09-19 批准,适用 Human Archer/Human Warrior/Skeleton Warrior/Skeleton Archer/Wild Skeleton):误差超 30 度保留 30% 请求速度、SmoothStep 0.55s 恢复、270 度/s 转向、authored 步频固定 2x;Turn→Run/Walk 和 Run/Walk/Turn→Idle/Ready 都用完整 0.35s 有限 SmoothStep;之前的 0.22s 指数曲线因手臂移动过快被否。
  • Urs 的 3.8 m/s 和 +10% Run 变更不是全队重标定;动物和 General 占位保留各自行为。转向出口匹配表若源 clip 变化必须重建。
  • 数据细节:五对 RosterTurn90_01 用 193 采样、0.234375 帧间距;Urs 间距不同;绝不要假设四分之一帧。引擎入口:UnitAnimationPlayer.PhaseMatching.cs、UnitLocomotionPhaseBaker.cs、Unit.Steering.cs 等。
  • 这是视觉相位选择,不是 foot IK 或 root motion;绝不因这套装置把导航推迟到整步结束。每个角色交接要写明相位匹配是否配置、骨映射、步幅/混合标定和缺失 clip。
创意技能库索引(2026-09-15 审计)/tmp/woc_kit/WorldOfOldcraft-build-kit/knowledge/creative-skills.md

把 2026-03-15~09-15 的 170 卡 Workspace 注册表审计结果编成 8 个已选交接模块的路由索引(图像生成、角色表、fal.ai、Higgsfield、img2threejs、材质烘焙、动作参考、Blender 动画导出),说明存储与发现结构。

  • 审计覆盖 170 张卡,其中 89 个描述命中 3D/生成主题——但明确声明这些只是发现候选,不是 89 个已验证工作流。
  • owner 于 2026-09-15 选定全部 8 个模块,并按其要求用 fal.ai 技能替换退役的 3D AI Studio;打包时未运行任何付费生成。
  • 模块化按需加载:先走 3d-production-routing 路由再只加载需要的模块,不要把一切合成一个大技能;工作流在 processes/3d-ai/、观察在 knowledge/、原始回执随项目。
  • 注意 kit 内相对路径(../.claude/skills/、../processes/3d-ai/、../projects/overlord/ 等)多指向原 Overlord 工作区,在 WorldOfOldcraft-build-kit 里未必存在,引用前要先确认目标是否随 kit 安装。
  • 历史证据注意:8 月前的 Workspace 文件夹已在 commit 3a549713 本地移除,示例要查 Git 历史;img2threejs 保留 Apache-2.0 许可,Higgsfield 厂商工具仍是外部依赖。
  • 诚实边界声明:打包检查不构成新的付费生成、分类器实现或自动绑骨服务。
一条被反复重申的边界

每篇经验文档都写着同一句话的意思:"这些数值是那次交付的标定,不是通用默认值"。期望代理继承的是方法和纪律,具体数字要针对新角色重新标定。

生产流程文档 processes/ · 9 篇

动画运动参考选择流程(AI 生成参考视频)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/processes/3d-ai/animation-reference-selection.md

规定在 Blender 动画制作之前如何用 AI 视频生成挑选运动参考:确定用途/演员/相机、批准起始姿势、按固定配方生成候选、评审归档、以及生成人体版本供视频动捕的默认方法。

  • §0 每次新批次前先与 owner 确认两条路线:直接在人体上生成供视频动捕(mocap),还是在游戏角色上生成供 GPT/动画师做运动参考;当前偏好是角色优先、再对胜出动作做人体重制;相机角度按用途选择,三分之四/等距视角不是强制默认。
  • §1 起始姿势必须先经 owner 明确批准,之后作为候选视频的 starting-frame 输入角色(start_image),而不是只在提示词里写 'character reference';批准一张起始图不等于批准由它派生的所有后续动作。
  • §2 基线配方(owner 确认):每个动画 2 条 Seedance 2.5 take + 1 条 MiniMax H3 Max take,精确模型 ID 为 `seedance_2_5` 和 `minimax_h3_max`;记录源图哈希、精确提示词、模型 ID、provider job、fps、时长与视频 URL/文件。
  • §3 决策标签体系:Selected(绿)/Candidate(黄)/NEW/History;生成完成或技术检查通过不等于艺术验收;保留早期版本并用稳定变体名,重新分类时不删原文件。
  • §4 Warrior 完成包共 8 条胜出参考(Idle、Walk、Run、Stun、两条 Attack、两条 Death);'参考包选定' 是与 authored Actions、导出资产、引擎验收相互分离的里程碑。
  • §5 人体版本standing decision(2026-09-13):默认用 Seedance 2.5 Video Edit(`seedance_2_5`, `mode=video_edit`),以已批准的字符视频为运动源、人体动捕服图为外观源;外观图必须逐动作匹配源片起始姿势与武器握持,否则 Run/Idle 会继承搭箭姿势、Stun 会把手抬到胸前。
  • 教训:Archer 的 16 条人体重制因动作『太像人』被整体否决——匹配起始图、模型和精确运动提示词并不能保留已批准的运动;保留运动就要以已批准的『视频』为运动源,不要把提示词一致当作运动保真证据。
  • 历史 prompt 驱动重制流程(human-mocap-02):每个胜出源 2 条 take(Seedance 2.5 与 MiniMax H3 Max),目标动捕服务 QuickMagic,但提取与 Mixamo 兼容 FBX 导出并未完成;文中链接的 projects/overlord/skeleton-animation/warrior-05 等 README 在本 kit 中不存在(断链)。
Blender 游戏动画工作流(从视频参考到引擎交付)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/processes/3d-ai/blender-game-animation.md

2026-09-09 由 Overlord Wolf 生产确立的主工作流:检查输入与定义输出、可恢复工作区、网格/骨骼准备、蒙皮压力测试、按参考 block 动作、精修、派生游戏 clip、烘焙运行时副本、导入验证与 Unity 交接。

  • §1 动手前读目标游戏的动画需求并写出 clip contract(Clip/Timing/Behavior/Events/Motion/Rig 六字段);测量参考视频 fps/帧数/分辨率;缺失 Mixamo donor 按 knowledge/mixamo-animation-acquisition.md 用精确 UUID 获取,缩略图和同名动作不算替代品。
  • 标准转身 clip(2026-09-17 起每个角色包必含):Run Turn Left/Right、Idle Turn Left/Right;直立项从已批准 Run 派生(保四步周期、共享归一化相位),直立单位用 90 度两步转身(2026-09-18 Urs 标准);运行时 root motion 关闭,随 FBX 交付哈希过的 controller-motion sidecar。
  • 地面四足用 Wolf revision 07 确立的 9 clip 构成(2026-09-10):Idle、Run、Attack、Death、独立 Walk、Turn Left/Right、Run Turn Left/Right。
  • §3-4 Wolf 作者绑定 38 骨含 26 根 deform 骨;焊接容差 0.000001 m(与其尺度绑定,不可照搬);蒙皮六步清理(抑制对侧影响、镜像平均、躯干按解剖分区、下颌防胡子拉伸、牙齿刚性、平滑+剪枝归一);导出每顶点最多 4 根影响。
  • §7 游戏 clip 时间公式:duration=(last_frame-first_frame)/fps,contact_fraction=contact_time/duration;Wolf 攻击 0-51@30fps=1.7s、接触帧 39=1.3s=76.47%(满足 owner 要求的 75-80%),死亡 0-40@30fps=1.333333s;换 fps 必须按等效时间重采样,FBX 导入器可能把帧原点平移 1。
  • §8a standing preference(2026-09-18):每个交付 .blend 重开时必须以 EEVEE Material Preview 显示真实材质,中性 studio.exr strength 1;§8b(2026-09-20):评审必须带 Set Pose/Save Pose Reference/Return to Animation 可编辑姿势参照。
  • §9-11 烘焙独立运行时骨架、导出前锁定动作列表并排除地板/相机/控制物;交付包复制到另一目录导入空场景验证(clip 数、时长、接触时刻、零未加权顶点、贴图路径、抽样姿态最大偏差);Unity 交接记录 loop 标志、Generic rig 预期、root-motion 政策、世界尺度、前向轴、事件时刻。
  • 引擎交接:直立单位转身相位匹配标准档案为 30% 转身速度、0.55s 恢复、固定 2x 步伐、0.35s 缓出转身退出、0.35s Idle 沉降(Urs 档案,2026-09-18);文中多处链接指向 projects/overlord/* 与 .claude/skills/blender-game-animation/SKILL.md(后者经 install_kit.ps1 由 dot-claude/ 安装后即存在)。
AI 角色创建流程(概念探索,YouTube 用途)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/processes/3d-ai/character-creation.md

面向 YouTube 内容的风格化女性英雄角色概念流程:目的定义 → 2-3 个原型并行 → 参考锚点 → 每原型 3 条提示词 → 生成迭代 → 编辑提示词 → 终选;是概念探索文档,不是 3D 生产默认值。

  • 七步管线:purpose → archetype(2-3 个方向并行)→ reference gathering(借能量不抄袭)→ 每原型 3 条变体提示词 → 生成+具体反馈迭代 → edit prompts 调姿势/配色/细节 → 终选。
  • 全局提示词硬约束:`stylized 3D Unreal Engine 5 character render, non-photoreal, not live-action, not fashion photography, not cartoon`;`young adult woman, early-to-mid 20s`;`full body, full height character visible`;显式 60/30/10 色彩比例;材质按 3D 材料描述;质量锚 `collectible premium game heroine`。
  • 五类常见修正循环:太写实→加 stylized UE5 语言与 slightly idealized proportions;太平淡→加叙事细节(疤、义肢、奖杯物);像女巫/天使/机器人→显式否定;细节噪音→cleaner shape language;年龄跑偏→重新锚定年龄段。
  • 反通用准则:设计里可见的故事 + 1-2 个签名元素 + 明确态度表情 + 带反差的熟原型(pirate+aristocrat、berserker+steampunk)。
  • edit prompt 关键句式:always say 'keep the same silhouette / same outfit structure / same identity',否则模型会重新发明角色。
  • 文件自带的工具表写 ChatGPT canvas + Flux (via Banana) + Blender,但文件头部与 tools.md 都声明这些是概念探索默认值、Flux-only 表已被替换;对 Oldcraft 的 12 种族/职业体型(男女双性别)简报,'年轻女性英雄、UE5 风格' 默认值不能直接套用。
游戏动画润色流程(Skullgirls 谈话的 3D 改编)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/processes/3d-ai/game-animation-polish.md

2026-09-11 基于 Mariel Cartwright 的 GDC Skullgirls 谈话改编的润色阶段:在支撑力学与游戏事件时刻锁定后、最终烘焙前,提升普通游戏速度下动作的可读性与预备/释放/冲击对比。

  • 前置条件:支撑机制和游戏事件时间已稳定;新动作先在目标控制器里用粗姿势试跑;对已批准动画保留基线快照,只改被要求的通道(curve path/component/keys/interpolation 指纹防误改动作库)。
  • RTS 振幅规则(owner,2026-09-24):动作幅度要在抬高视角的游戏相机、单位实际屏幕上可读;只在特写里可见的小动作不值得单独润色;先保证姿势区分度再协调腰、肩、头、手。
  • §3 五量区分表:Authored poses and curves(运动形状)、Pose exposure(可读构型停留时长)、Timeline fps(帧秒换算)、Bake density(烘焙采样密度)、Game clock(输入/移动/接触/冷却/打断);2D 例子里删冗余帧不是降低导出采样密度的指令;60fps 的一帧效果只有 30fps 一半时长。
  • §5 冲击重音候选表:Stronger extremes、Drag、Smear、Impact enlargement、Overshoot;每项有实施候选与保留前检查;在我们的事件驱动近战里 overshoot 必须先做空间检查——尾刺/颌不得在伤害事件前视觉上穿过目标。
  • 缩放要区分永久网格编辑与临时动画脉冲,测量评估后的结果而不是相乘 local scale;渲染器 bounds 必须包含放大后的轮廓;Scorpid 尾刺远端宽度约翻倍是一次性指定夸张,不是通用值。
  • §6-7 恢复段要可用可打断,不拖长尾阻止下一条指令;Hitstop 是独立引擎呈现选择,RTS 多单位混战中全局冻结会破坏无关单位与指令响应,未经游戏设计方确定只是提案。
  • §8 双评估都记录才接受:视觉评估(普通速度动作/方向/重量/时机对比/恢复更好)+ 技术评估(受保护通道、脚、IK、穿插、bounds、seam、scale reset、导入后动画无损);几何改动后要检查所有使用该网格的 clip。
Higgsfield 在项目工作流中的用法(CLI 与 Blender 集成)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/processes/3d-ai/higgsfield-cli.md

规定 Higgsfield 的两种执行界面(CLI 与 Blender 原生回调)如何发现状态、恢复任务、留存凭证,并列出观察到的模型 ID;强调不要把可用的 Blender 回调换成名字相似的 CLI 调用。

  • 2026-09-15 审计:CLI 版本 1.1.24,live catalog 共 91 个模型;CLI 与 Blender 集成是不同执行上下文,模型名相似也不能互相替换。
  • 只读检查命令:`higgsfield --version`、`higgsfield model list --json`、`higgsfield model get tripo_h3_1_image_to_3d --json`、`higgsfield workflow list --json`、`higgsfield generate list --size 50 --json`、`higgsfield generate get <job-id> --json`;授权新请求用 `generate create <job-type> ... --wait`,wait 超时不是失败,保留 job ID 用 `generate get` 或 `generate wait` 恢复,确认失败前不重复付费提交。
  • 观察到的模型 ID:`gpt_image_2_5`、`gpt_image_2`、`grok_image_2_0`、`nano_banana_flash`、`seedance_2_5`、`minimax_h3_max`、`tripo_h3_1_image_to_3d`——是观察值不是通用默认;原生 Tripo H3.1 路线与通用 `tripo_3d`、`multi_image_to_3d` 路线不同。
  • 凭证纪律:保存 provider、精确模型/job 类型、request ID、请求输入、本地输出路径与观察状态;远程链接不是持久资产必须下载;估算 credits 与实际账单是两种记录;私有收据与可分享示例分离。
  • 禁止把编号历史构建脚本对着已完成的 Blender 场景重跑(可能重新提交新 job 或依赖中间检查点)。
  • 换机器:`higgsfield auth login` 用接收者自己的账号认证,Blender companion 单独安装;文中引用的 [MCP setup](../project-mcp.md) 在 kit 的 processes/ 下不存在(断链)。
AI 图像生成流程(fal.ai / Banana 批量生成)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/processes/3d-ai/image-generation.md

经 `scripts/image-gen/generate.py` 走 fal.ai 的批量参考图迭代流程:对象规划→每对象 3 变体→HTML 报告→owner 反馈循环→终稿入 data/final/,含命名规范与 edit 工作流。

  • 四阶段管线:对象规划以 HTML 报告提案并暂停等 owner 批准;批量 5-7 个对象(上限 10,再多上下文退化);每对象 3 条 A/B/C 变体(不多不少);HTML 报告是唯一评审界面。
  • 端点表:默认生成 `fal-ai/nano-banana-2`;编辑 `fal-ai/nano-banana-2/edit`(用 `image_urls` 复数数组);高质量 `fal-ai/nano-banana-pro`;抠图 `fal-ai/imageutils/rembg`。
  • 硬规则:始终并行 `--workers 5` 起步绝不串行;3D 参考图默认纯中灰背景;结果必须保存远程 URL 到 results.json 供 edit 流程复用;报告登记进 workspace/workspace.json 的 Workspace 卡片。
  • 命名规范:迭代图 `{object_id}_{variant}.png`、终稿 `{object_id}_final.png`(如 speedboat_final.png)、运行目录 `data/run_YYYYMMDD_HHMMSS/`;终稿统一放 `scripts/image-gen/data/final/`。
  • Edit 工作流四步:`fal_client.upload_file()` 上传源图 → 调 `fal-ai/nano-banana-2/edit` 带 `image_urls:[uploaded_url]` → 报告里前后对比 → 可选 rembg 收尾。
  • 术语区分:A-pose 是标准绑定期姿势(双臂离体 30 度),与提示词变体 A/B/C 无关;文件头提醒 generate.py 仍保留 Nano Banana 2 的遗留默认值,必须显式传 `--model`,且该默认端点不在 TASK.md §15 表内。
AI 图像提示词技术手册(Banana Pro / Banana 2)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/processes/3d-ai/prompting.md

针对 3D-ready 图像的提示词知识库:风格锚定、60/30/10 色彩、材质语言、剪影可读性、角色/道具分型提示词与常见修正对照表。

  • 风格锚定必须放在提示词前部防漂移:`stylized 3D Unreal Engine 5 render, non-photoreal, not live-action, not cartoon` + `premium game-asset quality, collectible feel`;没有锚定模型会倒向写实或库存照片审美。
  • 色彩控制显式写 60/30/10 比例并带具体材质(例 `60% matte black steel, 30% aged bronze plates, 10% glowing cyan core`);材质用 3D 材料名(brushed titanium、scarred leather、emissive crystal inlays)而不是 shiny/rough/colorful。
  • 3D 参考背景默认 `solid uniform medium gray background`——不用白(过亮)、不用黑(吞剪影边缘)、不用纹理。
  • A-pose 标准描述:`standing straight facing camera directly, arms held at 30 degrees from the body, palms facing down, feet shoulder-width apart`,是绑定期参考姿势不是动作姿势;turnaround 用 `character turnaround sheet, front / side / back views on neutral background`。
  • 角色防飘条款:`standing on solid ground, feet touching a flat surface`(防浮空)、给手具体任务(防浮手)、指定表情态度而非 neutral。
  • 道具分三型:high-poly(micro-scratches/engravings,为烘焙供细节)、low-poly game-ready(clean geometric forms,作为拓扑参考)、simple objects;turnaround 加 top 视图,需要尺度感时 `placed next to a hand for scale`。
  • 常见修正对照表覆盖:太写实、太卡通、太平淡、过度设计、浮空、相机角度错、手部错误、色彩浑浊 8 类问题及对应措辞。
3D 生产工具路由图(tool map)/private/tmp/woc_kit/WorldOfOldcraft-build-kit/processes/3d-ai/tools.md

按『请求的输出』路由到正确入口与执行依赖的总地图,取代原 Flux-only 工具表;是 processes/3d-ai 其余文档与 .claude/skills 的索引。

  • 九行路由表:概念图/忠实编辑 → image-generation.md + prompting.md(generate.py 走 fal.ai 或 Higgsfield);中性角色 sheet 与部件 → .claude/skills/character-sheet-pipeline/SKILL.md;fal 生成/编辑/视频/材质/3D → .claude/skills/fal-ai-generation/SKILL.md(fal MCP + 便携 Python helper);Blender 内生成网格 → higgsfield-cli.md;程序化 Three.js 重建 → .agents/skills/img2threejs/SKILL.md;材质与游戏网格烘焙 → knowledge/3d-gen-preferences.md;运动参考 → animation-reference-selection.md;可编辑绑定/动画/导出 → .claude/skills/blender-game-animation/SKILL.md;YouTube 缩略图 → thumbnail-concepts skill。
  • task-specific defaults:编辑以已批准图为权威、额外风格语言会重新设计它;8 月模型轮换不覆盖更新的任务选择;parts sheet 保持 strict-front 中性光,hero 相机不适合提取或 mocap。
  • 明确警告:`generate.py` 有遗留 Nano Banana 2 默认参数必须显式 `--model`;Tripo 网格生成、Meshy 重打图、Patina 材质创建是三个独立操作;生成的高模不会自动等于游戏网格。
  • 交付声明纪律:人体视频转换成功不等于动作捕捉成功(human video transfer does not prove successful motion capture)。
  • 每次 API 请求前先读本地任务清单,保留精确 provider/model/request ID,超时后恢复既有 job,输出与 Workspace 卡片一起下载;引用的 `.agents/skills/img2threejs/SKILL.md` 在本 kit 中不存在(断链),`.claude/skills/*` 路径在安装后由 dot-claude/ 映射产生、有效。
Workspace 视频存储优化规范/private/tmp/woc_kit/WorldOfOldcraft-build-kit/processes/workspace-video-storage.md

owner 2026-09-15 设定的默认:新生成/下载的视频经保守 H.264 重压缩后轻量存储并出具收据,避免 provider 原片与多份大副本长期堆积。

  • 标准命令:下载关闭后运行 `python scripts/workspace_video_optimize.py path/to/video.mp4 --apply --allow-new`(已有文件夹可省 `--allow-new`;不带 `--apply` 仅清点);API 入口 `optimize_file(path, report_dir=None, allow_new=False)` 返回英文 JSON 收据。
  • 编码参数:保守 H.264、CRF 20、slow preset、原分辨率/像素格式/帧时序、音频直拷、faststart;预览衍生品才允许 H.264 960px / CRF 23。
  • 替换门槛:完整输出至少省 15%,且三组一秒 SSIM 抽样均 ≥0.985,候选全解码验证后才原子替换;收据必须区分 `providerOriginalSha256` 与 `storedSha256`,不得把旧源哈希改写成原片从未存在。
  • 保护名单:Overlord Blog 档案(devlog/archive,Git LFS)、发布/导出母版、Unity/运行时导出、alpha、HDR、高位深、多轨道媒体;已高效的 HEVC 下载与紧凑预览保留原样是优化结果不是失败。
  • 安全边界:除非显式给路径绝不扫描 Downloads/inbox;批量传 `--apply --workers 2`,跳过 2 分钟内修改过的文件,`--exclude` 排除活跃生产目录;物理路径去重处理 workspace/overlord 与 projects/overlord junction;不做递归删除、不进 Unity 工程目录。
  • 陷阱:kit 的 scripts/ 下实际没有 workspace_video_optimize.py(只有 3d/capture/image-gen/animation/refs 五个子目录),也没有 workspace/ 目录与 workspace.json——该脚本与其维护报告在本 kit 中缺失,Oldcraft 项目若要用需自行补齐或忽略。

前项目动画流水线档案 projects/overlord/ · 6 篇

Overlord Wolf:动画完整工作样例(worked example)/tmp/woc_kit/WorldOfOldcraft-build-kit/projects/overlord/animation-workflow/README.md

把 2026-09-09 owner 批准的 Wild Wolf 整条 Blender 动画制作过程固化为可复用知识的总索引:十步成功序列、四剪辑交付契约、脚本快照地图与验证证据清单。

  • 十步成功序列:检查 GLB+四段 24fps 视频参考并抽 contact sheet → 保留 UV 焊接重合缝几何 → 布骨架+自动权重 → 加 paw IK/pole 控制/hock helper/身体-下颌-尾控制 → 从视频重建完整 Idle/Run/Attack/Death → 修复 Run 循环约 14-16 帧的后腿折叠 → 加前后脚时序、躯干弹簧传导、头部补偿、尾部延迟 → 自动范围/fps 选择与原生分剪辑播放场景 → 把作者动作烘焙到 28 根运行骨骼 @30fps → 复制目录重导入做纹理/权重/时序验证。
  • 四剪辑引擎契约:wolf_idle 2.5s(0-75@30fps)、wolf_walk 0.833333s(实为 run loop,项目命名约定)、wolf_attack_c39 1.7s(咬合接触在相对 f39/1.3s,一次性、首尾姿态一致)、wolf_death 1.333333s(一次性、保持终帧)。
  • 最终资产事实:17,835 三角面、9,209 焊接顶点、1 材质、4096×4096 base-color JPEG;作者 rig 38 骨,导出 rig 28 骨、无运行期约束、Root 静止;皮肤归一化、≤4 影响、零未加权顶点、零跨腿泄漏。
  • evidence/scripts/ 声称保留 19 个生产脚本的逐字节快照(8 个阶段:参考检查/导入解剖/权重细化/控制与动作/修订 QA/游戏变体/播放/烘焙导出/导出比对),配 evidence/provenance.json 的 SHA-256;但文档自己声明这不是单命令可重跑的流水线——依赖 wolf 专属坐标、中间 NPZ、旧版动作计数,以及本地 NumPy/SciPy/OpenCV/FFmpeg。
  • 迁移重导入验证:FBX 与 GLB 两种格式各 21 个评估采样点与批准源在 0.000001m 内一致;FBX 从复制目录解析外部纹理,GLB 内嵌保留。
  • 后续引擎线:2026-09-09 起把 FBX 导入可玩 Wild Wolf prefab,实现 UnitAnimationSet/UnitAnimationPlayer 与编辑模式预览;2026-09-10 owner 批准九剪辑组合作为未来地面四足动物的基线,58 条运行时断言通过。
  • 注意:文中引用的 evidence/、research/、build_report.py、../logs/*.html 在本 kit 中均不存在(实测目录缺失),仅文档随 kit 分发。
动画批次重启指南(2026-09-19 知识检查点,含 9-20/9-24 追加)/tmp/woc_kit/WorldOfOldcraft-build-kit/projects/overlord/animation-workflow/NEXT_BATCH.md

下一批角色动画开工前的入口文件:11 个单位的当前可编辑源与交付包索引表、批次重启检查清单、Set Pose 评审新标准、Dryad v12 状态,以及备份受阻等挂起事项。

  • 11 单位可编辑源索引(路径在 <Overlord project>/ArtSource/Characters/):HumanArcher 与 Swordsman 各 14 剪辑;三具 Skeleton 的 Turning01 增量包各 6 剪辑(不替代攻击/死亡/Walk/Stun);Urs Classic/Pyro;General 14 core + 9 reserved(含 Stun,已导出,Unity 集成待办);Knight 11 core + 6 reserved(OwnerUpdate02 长矛,需 Unity 重导入);WildWolf Turn90_Final01;WarScorpid v06。
  • 9-20 追加:owner 批准 General 的 Set Pose 工作流——可直接编辑的命名关节、道具独立调整、保存的剪辑/帧姿态参考、未触碰 Action 的恢复——并入每次动画评审标准,要求实测骨骼/网格在 timer tick 与重开后的真实运动。
  • 9-24 追加:Dryad 修订 12,Dryad_Animations_v02.blend 内 Shield 掌指关节可见活动(HandIndex1/2 要看网格影响而非仅骨名),99 骨 rig 与皮肤不变;工具链 dryad_shield_hands12.py / ShieldHands.build() / shield_source12.json;下一任务是叶变种与 root-capture VFX(按 VFX Concepts V05)。
  • 失败/受阻记录:GitHub LFS 容量耗尽导致 Overlord 远程备份上传被拒,远端备份挂起;指示恢复容量后重试、不得绕过 LFS;文件仅存本地+本地 Git。
  • 五个单位的 Unity 转向迁移归属另一个 agent;只读检查发现旧五单位绑定尚未配置新的 travel/phase 表;Classic/Pyro 已有 runtime foot-phase 匹配和 0.35 秒 eased 转场停止混合;Ursa 后续 blend 细化仍待引擎内视觉评审。
  • 批次检查清单核心:切文件前保存恢复检查点并检查实时未保存权重/姿态;先批 Run 再派生变体;攻击需要自己的 ready 姿态而非从远处 Idle 滑入;实验分支批准前隔离;历史 setup 脚本可能覆盖已修正的权重或 Actions,复用前必须读输入与阶段依赖。
  • 明确要求:交付必须保存可用 Material Preview 与普通 Action/Space 播放,直接在 Blender 里评审,不做自动评审视频画廊;source 批准、导出验证、引擎集成三种状态分开记录,不得从知识检查点推断新批准。
四足运动:已批准的动画基线(九剪辑组合契约)/tmp/woc_kit/WorldOfOldcraft-build-kit/projects/overlord/animation-workflow/quadruped-locomotion.md

2026-09-10 owner 批准的 Wolf rev07 九剪辑组合,作为所有『转向跟随朝向』的地面四足动物的动画与控制器契约:clip 组成、planted turn 与 heading 曲线的数学约定、验收标准。

  • 九剪辑基线:Idle、Run、Attack、Death、Walk、Turn Left/Right、Run Turn Left/Right;Walk 必须是单独授权的四拍步态(逐爪依次落地、重心转移),明文禁止把 gallop 放慢来假装走路;strafe(侧移)是独立行为,四足不默认需要。
  • planted turn 契约(狼):一步 45 度/30 帧间隔 @30fps = 1 秒,与 Idle 入场姿态无缝;按外部旋转编舞,交付角度、时长与采样 heading 曲线,控制器按曲线相邻差分逐帧施加——本地姿态配无关恒定旋转会滑步,若再把 root yaw 加进动画会转两次;45 度步进不要默认换成双倍 90 度剪辑。
  • 步幅驱动:Walk 交付每完整周期的源米位移与源-世界尺度声明,归一化相位按 实际位移/世界步幅 推进,播放速度 = 世界速度 ÷ (worldStride/clipDuration);Run turn 交付带符号角/周期、步幅、参考半径(stride/angleRadians),与直行 Run 共享一个归一化相位。
  • 坐标系陷阱:狼作者文件 -Y forward/Z up,左转 = 正 Blender Z 旋转;Unity +Z forward/Y up 左转 = 负 yaw;manifest 必须显式给出两种符号。
  • rev06→rev07 失败教训:run bank 的 roll 符号在代码里看似合理实际朝转弯外侧倾,rev07 修正并测量;验收要求按几何判定向解剖内侧倾斜,并测量变形后的脚底而非控制原点。
  • 9-11 控制器修订:从静止起步的 Move 曾要等满 1 秒 planted turn,响应性差——改为加速中朝路线转向+反转时非零速度地板;运行转向 1.5x 权重增益 + 0.075s 平滑让躯干弯曲更可见,姿态仍钳制在授权 pose 上;此修订当时仍待自己的视觉 chat 批准。
  • 边界声明:批准的 2m gallop 步幅与巡逻速度是 Wolf 的艺术校准,不推出『无滑步世界接触』或通用速度规则;慢速巡逻速度从未被选定;静态跑步机预览不能证明世界空间接触锁定。
  • Wolf 兼容命名:已有 wolf_walk 是批准的 gallop(游戏在用,保留),新增 wolf_walk_slow 与四个 turn 剪辑;加入剪辑本身不等于接入 UnitAnimationSet/UnitAnimationPlayer/巡逻行为。
Skullgirls 演讲研读:对我们生物动画的启示(GDC 2014, Mariel Cartwright)/tmp/woc_kit/WorldOfOldcraft-build-kit/projects/overlord/animation-workflow/skullgirls-polish.md

2026-09-11 应 owner 要求对 GDC 2014 动画训练营演讲《Making Fluid and Powerful Animations For Skullgirls》(21:06)做的带时间戳分析,并推导出 3D/RTS 适配的『美学打磨 pass』。

  • 方法:完整英文自动字幕 + 42 张概览帧 + 三段演示的 48 个连续采样;明确声明是转述分析非逐字稿,且 30fps 录像无法展现其讨论的 60fps 游戏每一帧;源记录在 research/skullgirls/source-review.json(kit 内不存在)。
  • 12 条带时间戳原则:可读剪影(01:51)、预动/telegraph 区分玩家响应与敌人前摇(02:25)、重关键姿态优先于均匀中间帧(03:50)、follow-through(04:38)、smear(05:37)、短 overshoot(06:33)、夸张中间形变传达拖拽与重量(07:48)、粗动画先进游戏测(09:43)、不均等的姿态驻留(11:30)、hitstop 属运行期行为(12:46)、Idle 周围过多 easing 削弱响应(13:13)、冗余中间帧导致失重(15:20)。
  • 流程变化:新增 processes/3d-ai/game-animation-polish.md 打磨 pass,排在时序与支撑稳定之后;把『动作是否从游戏相机读得清、有力』的艺术判断与既有技术验证(rig 稳定、接地、事件时序、导出保真)分开评估。
  • Scorpid 适配实验边界:保持批准节奏 1.6s、接触在 48 间隔的第 37 帧、预紧 ≤14、释放 31;实测 stinger 接触时远端宽度为放大基底的约 2.05–2.09 倍、第 40 帧恢复中性尺度。
  • 技术依赖教训:为保留全部 Death 曲线,加宽的 stinger 一度穿地;微调一个远端关节恢复离地间隙且保留倒地通道——从此任何网格编辑都要触发全剪辑库的表面间隙检查(death_geometry_clearance_06.json)。
  • 红线:overshoot 不得让 stinger 在伤害事件前视觉上穿过目标;sprite 张数、曝光、Blender key、烘焙密度是不同东西,删帧会缩短时长;hitstop 仅作可选引擎实验(全局冻结不是多单位 RTS 的默认);2 倍缩放脉冲是 Scorpid 专属选择,不得变成通用乘数或强加于平静运动。
  • 结果状态:新工作流已含命名打磨 pass、早期可玩 blocking 检查、游戏相机对比、艺术/技术分离评估;但该 pass 尚未做任何端到端生产试验,本研究不批准也不修改任何新剪辑。
人类与骷髅 90 度转向 —— Unity 交接(2026-09-18)/tmp/woc_kit/WorldOfOldcraft-build-kit/projects/overlord/animation-workflow/roster-turns-2026-09-18/HANDOFF.md

把 Urs 批准的『90 度两步转向』方法推广到 Human Archer、Swordsman 与三具骷髅共 10 条 Idle Turn 剪辑的源/导出交接:时序契约、controller_motion 侧车格式、Unity 接收方步骤与验证数字。

  • 范围:5 角色 × 左/右 = 10 条 90 度非循环一次性转向全部修订并导出验证;人类包为完整 14 剪辑库,骷髅 FBX 保留 6 剪辑增量(Idle、Run、Run Turn L/R、Idle Turn L/R);其余动作、几何、UV、权重、材质字节保留。9-19 更新:五个 Unity 资产已用这些导出+rig 专属相位表+用户批准的 Urs 完整转向配置,但最终游戏内视觉批准仍待办。
  • 时序契约:0–45 帧 @30fps = 1.5s(沿用原节奏);领先脚 6.5625 抬起、21.5625 落地,后脚保持支撑到 27.1875、40.3125 落地,45 帧 settle;胸部到首次落地已转约 83.37 度而骨盆-胸部朝向保持单调。
  • 两步转向刻意含模型空间后退 0.244–0.285m 与首次落地踝间距 0.367–0.463m(五个角色逐一列表);两端点匹配原本地 ready 姿态,世界后退是有意为之,预览循环重置原点,因此不是无缝位移循环。
  • 侧车格式:controller_motion.json 沿用 Urs 字段名——每剪辑有 yaw_degrees_unity、position_x_blender、position_y_blender;193 个均匀采样,间隔 0.234375 帧,跨 45 帧;必须用声明间距或归一化相位,不能套用 Urs 的四分之一帧常量;用 controller_motion_sha256 校验。
  • Unity 侧要求:Generic FBX、root motion 关、初始不简化曲线、人类源保留全部 6 影响;源 -Y forward/Z up,Blender (X,Y,Z) → Unity (-X,Z,-Y),按 prefab 基精确映射并只施加一次 visual scale;纯预览按 1x 完整施加授权 yaw+位移,游戏保持固定 2x 步法(完整源步 0.75s)+独立朝向+随时打断;不得为外观后退移动 NavMeshAgent/collider。
  • 转出场相位匹配不在本任务配置:Unity 重导入时按 mixamorig:Hips/LeftFoot/RightFoot/LeftLeg/RightLeg 逐 rig 烘焙已批准的 Run/Walk 腿姿态表(UnitLocomotionPhaseBaker 与 Urs installer 是既有实现),不得自动照抄 Urs 的移动/blend 值。
  • 验证数字:10 条转向各过 365 采样(含分数支撑事件);完整授权预览中支撑踝最大水平漂移 <0.011mm;各包复制重导入最差顶点差 0.222–0.415mm(Human Archer 985 姿态 0.415mm … Skeleton Archer 422 姿态 0.222mm)。
  • 复现工具:AnimationTurning/Tools/ 下 roster_turn90_common/author/validate/promote/export/playback 六个脚本,动作构建器复用 Characters/Urs/Tools/turn90_02_motion.py(按角色缩放、保留 45 帧时长);Blender 后台 --python export_roster_turn90.py -- <prefix> 可重导出;引擎副本在 ArtSource/AnimationTurning/RosterTurn90_01/HANDOFF.md。
Wolf 90 度转向 —— Unity 交接(2026-09-19 批准)/tmp/woc_kit/WorldOfOldcraft-build-kit/projects/overlord/animation-workflow/wolf-turn90-final01/HANDOFF.md

owner 批准的狼 90 度左/右转向补充包(Export/Turn90_01/)的绑定与集成交接:两剪辑契约、Generic/Copy-From-Avatar 绑定步骤、heading 曲线施加规则、交付验证与未完成的 gameplay 工作。

  • 包内容:仅两条静止转向 wolf_turn_left/right(0–54 @30fps = 恰 1.8s,Unity yaw 0→∓90°,loop 关);九剪辑基线仍在 Export/Locomotion_07/,明令不得用这个两剪辑 FBX 覆盖基线包;需作为独立补充动画模型导入并只替换 animation set 里的 turnLeft/turnRight。
  • 烘焙密度:骨骼姿态每四分之一帧烘焙(120 采样/秒)以保住帧间 IK 爪路径,每剪辑 217 个姿态采样、无重定时;Blender FBX 重导入显示 1–55、glTF 显示 0–54——必须核对 1.8 秒时长而不是照抄导入器的帧起点。
  • 绑定:Generic + Copy From Other Avatar 用现有 Wolf Avatar(Wolf.fbx,GUID ed6ca0f85fd4e63439c115db5d6e2d75,Avatar fileID 9000000),28 骨名称/层级/rest 矩阵与 v07 baked 模型完全一致;关压缩与关键帧缩减、resampleCurves=false 保分数帧;用 unity_turn_curves.json 替换 yaw 曲线,键时间是归一化相位 sampleIndex/54(不是秒),旧 ±45° 曲线绝不能留在新对上。
  • 关键陷阱:保存的 Wolf 动画集 usePlantedTurns 默认 false——只导入/重绑剪辑不会让转向进 gameplay;共享控制器用 405°/s 导航朝向 + 固定 2x 播放,此时长实际只有 0.9 秒,turnPlaybackSpeed 只用于独立预览;授权 heading 故意未烤进 FBX/GLB,施加必须恰好一次,独立-yaw 玩法被打断时可能滑步。
  • 交接时的 Wolf balance 快照(只读、未改):移动 4.4 m/s、转向倍率 0.2、转向恢复 0s、Run 步幅 2m、Walk 步幅 0.68m、Walk 阈值 1.4 m/s。
  • 验证交付:两格式各 434 个四分之一帧姿态与最新作者网格最大表面误差 <0.000001m;2 剪辑/28 骨/1 蒙皮网格/17,835 三角面/1 材质;无控制/pole/helper 骨、零未加权顶点、≤4 影响、Root 与 armature 静止;唯一贴图为 Textures/Wolf_BaseColor.jpg 4096×4096。这些全是 Blender/导出侧检查,Unity 导入与 gameplay 评审在交接时仍未完成。
  • 四足相位匹配警告:现有直立 LegPose helper 只表示两脚两膝,对四条腿不完整;评审要覆盖双向、反转、连续下令、Stop/Hold、攻击/死亡打断、转向退出到 Idle/Run/Walk。
  • 复现:作者文件 Wolf_Turn90_Final01.blend(含全 heading 预览)+ 烘焙版 Wolf_Turn90_Final01_Game.blend + Source/Animation/turn90_01.json + Tools/turn90_01/export_turns.py 与 validate_export.py/check_saved_blends.py;游戏根目录 python ArtSource/Tools/character.py export wild_wolf 可再导出。
被复用的是方法,不是资产

包内实测 0 个 .fbx / .blend / .glb。Overlord 的模型、骨骼、动画一条都没带过来,只带走了契约、教训和验收标准。真正给 Oldcraft 用的动画来源是另外那 90 条 Mixamo 片段。

07四个技能详解 dot-claude/skills/ · 22 个文件 · 约 90 KB

这四个技能是套件里技术含量最高、也最容易被当成"配置文件"划过去的部分。它们不是四个并列工具,而是一条按生产阶段切分的流水线:一个分诊台 + 三个执行者。

3d-production-routing

分诊台
入口 · 全流程
不产生素材,只决定走哪条路

character-sheet-pipeline

参考包生产
概念图 → 3D 生成之间
239 行 + 9 个提示词模板

blender-game-animation

绑定与动画
网格 → 引擎之间
129 行

fal-ai-generation

生成执行层
贯穿全程
78 行 + 队列脚本

整个系统的存在理由只有一个

理解这一点,后面所有看起来偏执的规则就都说得通了。character-sheet-pipeline 的自我说明开门见山:

原文

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

单张图生 3D 的模型(Tripo、Hunyuan、Rodin、Pixal3D)在喂给它一张干净的严格正面 A-pose 图 + 孤立部件参考时,效果远好于喂一张"英雄姿势的帅图"。但手工做出这套参考包,熟练的人也要 30–60 分钟。这个技能把那段时间压成"一次调用 + 三个人工闸门"。

最高法则:严格正面,绝不 3/4

技能的原文用三段排比来钉这条规则:

THE CARDINAL RULE — STRICT FRONT, NEVER 3/4

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

理由很具体:3/4 生成的部件和严格正面的部件拼不回去。缝对不上、衣服穿不上、帽子戴不上去。技能自己承认"模型会这么干"("it will")。

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

旧版本靠加强提示词措辞,但实测配饰仍然会漂。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

六项全部通过
→ 接受,继续管线

soft_fail

1–2 项轻微失败,但仍可作正交参考
→ 接受,警告写入 manifest

hard_fail

第 1、2、3、5 项任一明确失败
→ 拒绝,进入下面的重试循环

hard_fail → 拒绝,重试计数 +1 重试 1 同一模型 + 升级措辞 把分类器给的具体理由前置:「上一次尝试向镜头右侧旋转了约 25°;这一次必须正对。」 加强反 3/4 负面词,STRICT FRONT 提到全大写首句 ▼ 仍 hard_fail 重试 2 换备用模型(Nano Banana 2) 理由:主模型可能在这个构图上卡死了 ▼ 仍 hard_fail → 停止循环 升级 把三次尝试摆给用户,三选一: 将就选一张 / 用自定义指令重试 / 跳过这个部件 上限:每个部件最多 2 次自动重试(共 3 次尝试)。 每次判定(pass / soft_fail / hard_fail + 理由 + 重试次数)都写入 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 个部件。把成本给用户看,请求批准。"

模型路由:每一步都写了理由

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

管线中途换模型会引入风格漂移,破坏下游的 3D 重建。所以宁可每步都用同一个模型。Stage 2B 是唯一例外 —— 因为它只是"给人看的辅助图",不是部件提取的输入;母图(2A)才是。

八条"绝不要做"

反模式清单和正面规则一样有价值,因为它记录了实际踩过的坑:

绑定与动画技能:核心是"三件事分开报告"

统领性的收尾规则

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

这条规则直接对应 Oldcraft 的四状态词表(implemented / agent-verified / pending owner review)。配套的硬性验收项:

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 转身:更宽的后撤步,后脚离地前先有明确的躯干旋转。这些转身从已批准的姿势派生,通常不需要新的运动参考。

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 连同原因。

恢复语义 —— 整个技能最实用的部分

收据硬锁与凭据纪律

scripts/fal_job.py 每个作业写一份 receipt(job.json),已存在的 receipt 会阻止再次提交。这是防止重复扣费的机械锁,不依赖代理记得。密钥绝不打印;凭据和原始签名链接不得进入可分享的报告。

路由技能的三条全局纪律

3d-production-routing 只有 38 行,却是四个技能里密度最高的。

① 先确立工件

参考图 / 生成网格 / 材质集 / 程序化模型 / 运动参考 / 可编辑动画 —— 六种不同的工件。原文:生成了网格,不等于确立了蒙皮、游戏拓扑、烘焙贴图或可用的导出。

② 模型标识按 provider 现场核实

Higgsfield 的 job type 和 fal 的 endpoint name 是两套不同的标识符,即使可见模型名很像。并且:旧脚本的默认值、厂商技能的默认值,都不能覆盖用户已经做出的选择。

③ 凭据只来自根 .env

或 provider 自己的登录。附带一条共享边界:出现在目录里,不等于获准发布用户的项目、媒体、账户历史或全部已装技能。

一个容易忽略的事实:这些技能不只为 Oldcraft 写的

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

这些技能是从作者的主仓库里抽出来复用的,带着"被复制到别处也要成立"的设计意识 —— 哪些是通用方法、哪些是本仓库特有策略,正文里被显式标注了出来。这也解释了为什么技能的相对链接指向 ../../../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 的设计前提是交互式的:三个闸门的措辞都是"等待明确批准再继续"。

而 Oldcraft 的 CLAUDE.md §2 写的是:"所有者不可用。绝不提问,也绝不等待答复。"

技能说"等批准",项目规则说"绝不等待",两条规则直接对撞。Oldcraft 的副本其实打了一个补丁("复用当前任务里已经给出的授权范围;检查点解决的是新选择,而不是把同一个问题再问一遍"),TASK.md 也有对应处理(把预算写死在文档里,由代理自行判断)。但这仍然是一条需要代理在 M0 阶段主动裁决并记入 DECISIONS.md 的冲突 —— 否则最坏的情况是代理卡在 Gate 1 等一个永远不会来的答复。

技能库全部文件

技能路径作用行数体积
3d-production-routing3d-production-routing/SKILL.md分诊路由:决定一个 3D 任务走哪条路线382.2 KB
character-sheet-pipelinecharacter-sheet-pipeline/SKILL.md8 阶段 3 闸门,角色原画 → 严格正面参考包23919.2 KB
└character-sheet-pipeline/prompts/01a_apose_front.md模板 2A:严格正面 A-pose 母图353.1 KB
└character-sheet-pipeline/prompts/01b_character_sheet.md模板 2B:三视图补充设定图 16:9544.4 KB
└character-sheet-pipeline/prompts/02_parts_body.md模板 Stage 4:身体必需件(躯干/腿/臂/头)464.1 KB
└character-sheet-pipeline/prompts/03_parts_paired.md模板 Stage 4:成对件(手/靴)453.7 KB
└character-sheet-pipeline/prompts/04_parts_accessory.md模板 Stage 4:配饰(帽/武器/背包/披风)595.0 KB
└character-sheet-pipeline/prompts/05_parts_hair.md模板 Stage 4:头发(默认提取)493.1 KB
└character-sheet-pipeline/prompts/06_multiview.md模板 Stage 5:逐件侧视 + 背视765.3 KB
└character-sheet-pipeline/prompts/07_360_video.md模板 Stage 6:360 度转盘视频(最贵的一步)644.2 KB
└character-sheet-pipeline/prompts/08_3q_classifier.md模板 Stage 4.5:反 3/4 视觉分类器 + 升级重试措辞1328.0 KB
blender-game-animationblender-game-animation/SKILL.md绑定 → 动画 → 烘焙 → 验证过的 Unity 交付12911.9 KB
fal-ai-generationfal-ai-generation/SKILL.md生成执行层 + 预算守门 + 收据去重784.8 KB
└fal-ai-generation/references/mcp-workflow.md参数示例与作业恢复934.6 KB
└fal-ai-generation/references/prompting-and-review.md概念 / 编辑 / 材质的提示词决策492.6 KB
└fal-ai-generation/references/setup.md换一台机器时的连接方式522.6 KB
└fal-ai-generation/examples/WALKTHROUGH.md不花钱的预演 + 正式生成命令341.6 KB
└fal-ai-generation/examples/concept.json概念生成的输入示例—331 B
└fal-ai-generation/examples/edit.json编辑生成的输入示例—374 B

以上 19 个 markdown / json 文件已全部译为中文,见 中文翻译 一节。中文译文保留英文提示词原文(否则提示词就没法用了),只翻译说明性文字。

08视觉基准 Docs/concepts/approved/ · 25 张

这 25 张图是整个项目唯一不容争辩的东西。TASK.md 的措辞是:代理必须先逐张打开它们,之后每一次生成都要以它们为输入和风格锚点,"不匹配已批准概念的资产,在进场之前就要修好或换掉"。

10
种族设定图(6 原版 + 4 职业编辑版)
8
世界路线概念图
7
界面稿 + logo + 区域地图

全部 25 张已批准概念图(缩略图墙)

鼠标悬停放大,点击看全图。

logo_oldcraft_A.webplogo_oldcraft_A.webp
race_bullfolk_B.webprace_bullfolk_B.webp
race_dwarf_C.webprace_dwarf_C.webp
race_human_C.webprace_human_C.webp
race_nightelf_C.webprace_nightelf_C.webp
race_orc_A.webprace_orc_A.webp
race_undead_B.webprace_undead_B.webp
v2_biome_farmland_N.webpv2_biome_farmland_N.webp
v2_biome_haunted_N.webpv2_biome_haunted_N.webp
v2_bullfolk_B_Egpt.webpv2_bullfolk_B_Egpt.webp
v2_city_human_G.webpv2_city_human_G.webp
v2_city_human_inside_N.webpv2_city_human_inside_N.webp
v2_city_stone_inside_N.webpv2_city_stone_inside_N.webp
v2_city_stone_inside_W.webpv2_city_stone_inside_W.webp
v2_dwarf_C_Egpt.webpv2_dwarf_C_Egpt.webp
v2_human_C_Enano.webpv2_human_C_Enano.webp
v2_nightelf_C_Egpt.webpv2_nightelf_C_Egpt.webp
v2_start_valley_N.webpv2_start_valley_N.webp
v2_transition_farmland_N.webpv2_transition_farmland_N.webp
v2_ui_charcreate_N.webpv2_ui_charcreate_N.webp
v2_ui_charselect_fix_G.webpv2_ui_charselect_fix_G.webp
v2_ui_hud_N.webpv2_ui_hud_N.webp
v2_ui_login_G.webpv2_ui_login_G.webp
v2_zone_overview_west_N.webpv2_zone_overview_west_N.webp
v2_zonemap_west_Nref.webpv2_zonemap_west_Nref.webp

种族设定图

全部是中灰纯色背景的风格化 3D 渲染立绘,无文字无水印 —— 这是刻意的,因为它们要直接喂给图生 3D 模型。灰色背景是生成管线的硬要求。

职业编辑版(role edit)

同一批角色,只改武器和服装配色。这是项目解决"重画一张图会把脸也改掉"的办法,也是判断哪个文件对哪一部分有权威的依据。

世界路线

按玩家从出生到进城的顺序排列。注意这批图画风并不统一 —— 有的接近 2004–2010 年的 WoW 引擎截图,有的偏手绘卡通,过渡段最"玩具低模"。落地前必须先写 STYLE_BIBLE.md 把它们统一(见 11)。

界面稿、标志与地图

这四个界面是 P0 验收第 1、2、3、11 项的直接比对对象,措辞都是"看起来要和 mockup 一样好"。布局元素需要照抄,但画面里的文字不能照抄(见 11 的第 2 条发现)。

两套地图是同一地理的两种画法

v2_zone_overview_west_N 是 3D 渲染鸟瞰(用作登录动画与加载图的底图),v2_zonemap_west_Nref 是羊皮纸手绘世界地图(用作游戏内 UI)。两张图地理完全同构:城在西南、紫雾墓地在西北、红顶教堂在东北、麦田风车在中南、河流东西横贯、两座桥跨河、群山围住北缘与东缘。

09候选池与筛选漏斗

129 张候选,晋升 25 张。这个目录是选型过程留下的化石层,读它能还原出作者到底怎么挑的。

129
生成稿总数
25
晋升为已批准
19%
采纳率
100%
已批准图都来自候选目录 —— 纯"生成→筛选"漏斗

我把两个目录做了交集:approved 里除 README.md 外的 25 个文件全部存在于 candidates 里,没有一张是"新生成"的。这是一条干净的晋升链路,也意味着没有任何已批准图是不可追溯的。

文件名里藏着两代工艺

命名特征含义出现在
_A / _B / _C同一提示词的重试或变体种族表、logo、lineup、旧 UI
_G / _N / _W模型 id —— 同一提示词喂三个模型做对比v2 世界图与 v2 UI
_Nrefreference-conditioned,以某张已定稿图为参考再生成区域地图
_Egpt / _Enano做职业编辑时用的模型4 张 v2_* 角色表
v2_ 前缀第二代精修,时间戳 20:36–21:39(v1 是 18:39)全部最终方案

一个可以直接看出来的规律:_G 出小图(约 200 KB、1088×608、插画感强),_N / _W 出 2752×1536 高清图(380 KB–1 MB)。作者最终几乎一致地选了 _N。

三条被砍掉的支线

换个游戏名字

logo 经历过三轮命名竞争:Elderhold Online → Realms of Eldmoor → World of Oldcraft,最后在 Oldcraft 内部 A/B 二选一取 A。前两个名字的 4 张 logo 全部躺在候选目录里。

多做一个大陆

东区地图(v2_zonemap_east_Nref、v2_zone_overview_east_N)已经生成好了,但 MVP 只做西区,东区整套留作扩展。这是主动砍范围,不是做不出来。

多两个生态带

峡谷、雪原、矮人城、兽人城都生成过,因为不在"森林→农田→鬼林→城"这条主线上而被搁置。

v1 界面稿为什么被淘汰 —— 一条实质原因

旧 UI 稿把真实商标词生成进了画面

分析这批落选稿时可以直接看到:ui_charcreate_A 的种族按钮上出现 Gnome / Tauren;ui_charselect_B 出现 Blackrock Spire / Orgrimmar / Thunder Bluff / Stormwind / Ironforge;ui_hud_A 的小地图出现 Silverpine Road。而 TASK.md §3 与 CLAUDE.md §6 都明确要求"提示词禁品牌词,含真实游戏 logo 或名称的输出必须拒绝"。

但要注意一个关键限定:商标词并不是 v1 与 v2 的分界线。已批准的 v2_ui_charselect_fix_G 画面里同样写着 Stormwind / Ironforge / Dun Morogh,v2_ui_login_G 同样带着 WoW 1.12.1 的版本串。这里真正发生的事情是:v1 被 v2 在完成度上取代(v2 分辨率更高、布局更完整),而"商标词"这条规则从 v1 到 v2 都没有被执行过。详见 第 11 节第 1 条。

全部 129 张候选稿(缩略图墙)

这是完整未删减的生成记录。被采纳的 25 张用金色边框标出,其余为落选。鼠标悬停放大。

biome_canyon_A.webpbiome_canyon_A.webp
biome_canyon_B.webpbiome_canyon_B.webp
biome_farmland_A.webpbiome_farmland_A.webp
biome_farmland_B.webpbiome_farmland_B.webp
biome_haunted_A.webpbiome_haunted_A.webp
biome_haunted_B.webpbiome_haunted_B.webp
biome_snow_A.webpbiome_snow_A.webp
biome_snow_B.webpbiome_snow_B.webp
city_dwarf_A.webpcity_dwarf_A.webp
city_dwarf_B.webpcity_dwarf_B.webp
city_human_A.webpcity_human_A.webp
city_human_B.webpcity_human_B.webp
city_human_inside_A.webpcity_human_inside_A.webp
city_human_inside_B.webpcity_human_inside_B.webp
city_orc_A.webpcity_orc_A.webp
city_orc_B.webpcity_orc_B.webp
lineup_all_A.webplineup_all_A.webp
lineup_all_B.webplineup_all_B.webp
logo_elderhold_A.webplogo_elderhold_A.webp
logo_elderhold_B.webplogo_elderhold_B.webp
logo_eldmoor_A.webplogo_eldmoor_A.webp
logo_eldmoor_B.webplogo_eldmoor_B.webp
logo_oldcraft_A.webplogo_oldcraft_A.webp
logo_oldcraft_B.webplogo_oldcraft_B.webp
race_bullfolk_A.webprace_bullfolk_A.webp
race_bullfolk_B.webprace_bullfolk_B.webp
race_bullfolk_C.webprace_bullfolk_C.webp
race_dwarf_A.webprace_dwarf_A.webp
race_dwarf_B.webprace_dwarf_B.webp
race_dwarf_C.webprace_dwarf_C.webp
race_human_A.webprace_human_A.webp
race_human_B.webprace_human_B.webp
race_human_C.webprace_human_C.webp
race_nightelf_A.webprace_nightelf_A.webp
race_nightelf_B.webprace_nightelf_B.webp
race_nightelf_C.webprace_nightelf_C.webp
race_orc_A.webprace_orc_A.webp
race_orc_B.webprace_orc_B.webp
race_orc_C.webprace_orc_C.webp
race_undead_A.webprace_undead_A.webp
race_undead_B.webprace_undead_B.webp
race_undead_C.webprace_undead_C.webp
start_valley_A.webpstart_valley_A.webp
start_valley_B.webpstart_valley_B.webp
transition_canyon_A.webptransition_canyon_A.webp
transition_farmland_A.webptransition_farmland_A.webp
transition_haunted_A.webptransition_haunted_A.webp
transition_snow_A.webptransition_snow_A.webp
ui_charcreate_A.webpui_charcreate_A.webp
ui_charcreate_B.webpui_charcreate_B.webp
ui_charselect_A.webpui_charselect_A.webp
ui_charselect_B.webpui_charselect_B.webp
ui_hud_A.webpui_hud_A.webp
ui_hud_B.webpui_hud_B.webp
ui_login_A.webpui_login_A.webp
ui_login_B.webpui_login_B.webp
v2_biome_canyon_G.webpv2_biome_canyon_G.webp
v2_biome_canyon_N.webpv2_biome_canyon_N.webp
v2_biome_canyon_W.webpv2_biome_canyon_W.webp
v2_biome_farmland_G.webpv2_biome_farmland_G.webp
v2_biome_farmland_N.webpv2_biome_farmland_N.webp
v2_biome_farmland_W.webpv2_biome_farmland_W.webp
v2_biome_haunted_G.webpv2_biome_haunted_G.webp
v2_biome_haunted_N.webpv2_biome_haunted_N.webp
v2_biome_haunted_W.webpv2_biome_haunted_W.webp
v2_biome_snow_G.webpv2_biome_snow_G.webp
v2_biome_snow_N.webpv2_biome_snow_N.webp
v2_biome_snow_W.webpv2_biome_snow_W.webp
v2_bullfolk_B_Egpt.webpv2_bullfolk_B_Egpt.webp
v2_bullfolk_B_Enano.webpv2_bullfolk_B_Enano.webp
v2_city_dwarf_G.webpv2_city_dwarf_G.webp
v2_city_dwarf_N.webpv2_city_dwarf_N.webp
v2_city_dwarf_W.webpv2_city_dwarf_W.webp
v2_city_human_G.webpv2_city_human_G.webp
v2_city_human_N.webpv2_city_human_N.webp
v2_city_human_W.webpv2_city_human_W.webp
v2_city_human_inside_G.webpv2_city_human_inside_G.webp
v2_city_human_inside_N.webpv2_city_human_inside_N.webp
v2_city_human_inside_W.webpv2_city_human_inside_W.webp
v2_city_orc_G.webpv2_city_orc_G.webp
v2_city_orc_N.webpv2_city_orc_N.webp
v2_city_orc_W.webpv2_city_orc_W.webp
v2_city_stone_inside_G.webpv2_city_stone_inside_G.webp
v2_city_stone_inside_N.webpv2_city_stone_inside_N.webp
v2_city_stone_inside_W.webpv2_city_stone_inside_W.webp
v2_city_stone_square_G.webpv2_city_stone_square_G.webp
v2_city_stone_square_N.webpv2_city_stone_square_N.webp
v2_city_stone_square_W.webpv2_city_stone_square_W.webp
v2_dwarf_C_Egpt.webpv2_dwarf_C_Egpt.webp
v2_dwarf_C_Enano.webpv2_dwarf_C_Enano.webp
v2_human_C_Egpt.webpv2_human_C_Egpt.webp
v2_human_C_Enano.webpv2_human_C_Enano.webp
v2_nightelf_C_Egpt.webpv2_nightelf_C_Egpt.webp
v2_nightelf_C_Enano.webpv2_nightelf_C_Enano.webp
v2_start_valley_G.webpv2_start_valley_G.webp
v2_start_valley_N.webpv2_start_valley_N.webp
v2_transition_canyon_G.webpv2_transition_canyon_G.webp
v2_transition_canyon_N.webpv2_transition_canyon_N.webp
v2_transition_canyon_W.webpv2_transition_canyon_W.webp
v2_transition_farmland_G.webpv2_transition_farmland_G.webp
v2_transition_farmland_N.webpv2_transition_farmland_N.webp
v2_transition_farmland_W.webpv2_transition_farmland_W.webp
v2_transition_haunted_G.webpv2_transition_haunted_G.webp
v2_transition_haunted_N.webpv2_transition_haunted_N.webp
v2_transition_haunted_W.webpv2_transition_haunted_W.webp
v2_transition_snow_G.webpv2_transition_snow_G.webp
v2_ui_charcreate_G.webpv2_ui_charcreate_G.webp
v2_ui_charcreate_N.webpv2_ui_charcreate_N.webp
v2_ui_charcreate_fix_G.webpv2_ui_charcreate_fix_G.webp
v2_ui_charselect_G.webpv2_ui_charselect_G.webp
v2_ui_charselect_fix_G.webpv2_ui_charselect_fix_G.webp
v2_ui_hud_G.webpv2_ui_hud_G.webp
v2_ui_hud_N.webpv2_ui_hud_N.webp
v2_ui_login_G.webpv2_ui_login_G.webp
v2_ui_login_N.webpv2_ui_login_N.webp
v2_zone_overview_east_N.webpv2_zone_overview_east_N.webp
v2_zone_overview_west_N.webpv2_zone_overview_west_N.webp
v2_zonemapA_G.webpv2_zonemapA_G.webp
v2_zonemapA_N.webpv2_zonemapA_N.webp
v2_zonemapB_G.webpv2_zonemapB_G.webp
v2_zonemapB_N.webpv2_zonemapB_N.webp
v2_zonemap_east_G.webpv2_zonemap_east_G.webp
v2_zonemap_east_N.webpv2_zonemap_east_N.webp
v2_zonemap_east_Nref.webpv2_zonemap_east_Nref.webp
v2_zonemap_west_G.webpv2_zonemap_west_G.webp
v2_zonemap_west_N.webpv2_zonemap_west_N.webp
v2_zonemap_west_Nref.webpv2_zonemap_west_Nref.webp
zonemap_A.webpzonemap_A.webp
zonemap_B.webpzonemap_B.webp

候选样本细看

10风格参考语料库 Docs/refs/manifest.json

70 条风格参考的目录清单。这是理解"经典、重制版"这个美术目标最直接的入口。

图片本体不在包里

我实测过:Docs/refs/ 目录下只有 manifest.json 一个文件,70 张图一张都没有。它们由安装器联网抓取(主要来自 warcraft.wiki.gg 和 Internet Archive 的 Wayback Machine)。所以这份 JSON 是"要抓什么"的清单,不是"抓到了什么"的结果。

70
参考条目
9
分类
7
年代/来源世代
31
条是 2004 原版素材

分类分布

分类原始 key数量
高清重制目标hd-target14
游戏内 UIui12
生物creatures9
前端界面frontend8
艾尔文森林elwynn7
暴风城stormwind6
北郡northshire5
闪金镇goldshire5
部落区域horde4

年代分布

世代数量
2004 原版31
现代客户端18
2019 怀旧服10
Unity 粉丝重制3
UE5 粉丝重制3
官方概念画3
UE4 粉丝重制2

来源站点

域名条目数
warcraft.wiki.gg44
web.archive.org10
blizzardwatch.com4
images-wixmp-ed30a86b8c4ca887773594c2.wixmp.com3
static.wikia.nocookie.net2
d3kjluh73b9h9o.cloudfront.net2
bnetcmsus-a.akamaihd.net1
cdn-wow.mmoui.com1
i.imgur.com1
st.renderu.com1
i.ytimg.com1

每条记录包含什么

{
  "file":            "frontend/login-screen-vanilla-dark-portal.webp",
  "category":        "frontend",
  "subject":         "Vanilla login screen (Dark Portal) with login UI",
  "what_to_take_from_it": "Layout: WoW logo top-left, Account Name/Password boxes +
                     Login button centred inside the portal, small red buttons
                     bottom-left/right, version text bottom-left; palette of
                     fire-orange portal, black stone, red glowing statue eyes.",
  "era":             "vanilla 2004",
  "source_page":     "https://warcraft.wiki.gg/wiki/Login_screen",
  "image_url":       "https://warcraft.wiki.gg/images/Login_screen_Vanilla.jpg",
  "credit":          "Blizzard Entertainment (screenshot via warcraft.wiki.gg)"
}

what_to_take_from_it 这一字段写得很具体 —— 不是"参考这张图的氛围",而是逐条列出要抄哪一个 UI 元素、抄它的什么颜色。这让代理能在一张截图里精确定位可复用的设计,而不至于整张照搬。

授权条款写得很清楚

70 条里有 56 条直接署名为暴雪娱乐的截图,4 条经第三方媒体转载(Blizzard Watch 的 2010 年截图库),其余 10 条是粉丝重制作品与画师署名。TASK.md §3 对它们的用法划了硬边界:只能作为 2D 概念图的风格参考,绝不能当贴图用,绝不能作为 3D 生成的直接输入,也绝不能进入最终构建。hd-target 分类(14 条)是其中最接近目标观感的一批 —— 尤其是一个用 Unity URP 做的艾尔文森林粉丝重制,被文档点名为"最接近目标的一条参考"。

11风险与警示

以下是我逐张打开图片、逐份文档比对之后发现的十六处问题,并由一个独立代理在文件系统上复核过。前三处是已批准的权威文件与任务书规则之间的真实矛盾——代理在 M0 阶段一定会撞上它们。

01 · 冲突approved 界面稿里写着暴雪的地名

证据  v2_ui_charselect_fix_G 画面里直接写着 Stormwind(服务器名)、Ironforge、Dun Morogh(角色所在地),角色卡是 Thorin 60 级战士 / Elira 48 级法师 / Kael 32 级圣骑士 / Sarya 28 级盗贼 / Brom 20 级猎人。v2_ui_login_G 左下角写着版本串 "Version 1.12.1 (5875) (Release) / Sep 10 2006" —— 那是 WoW 1.12.1 补丁的字面版本号。v2_city_stone_inside_N 里有一块 "THE LION'S PRIDE" 招牌。

为什么重要  TASK.md §3 写"用你自己的地名和 NPC 名;构建里不许出现暴雪 logo 或名称";CLAUDE.md §6 写"拒绝任何出现真实游戏 logo 或名称的输出"。而同一份任务书又要求"界面看起来要和这些 mockup 一样好"。代理会同时收到"照抄这个布局"和"不许出现这些名字"两条指令。值得注意的是:被淘汰的 v1 界面稿恰恰是因为画面里有 Gnome / Tauren / Orgrimmar 而被拒的 —— 说明这条标准在 v1 用得很严,到 v2 就没有再执行。

02 · 冲突建角稿有 8 个种族,任务书只有 6 个

证据  v2_ui_charcreate_N 左侧是 8 个种族头像的两列网格(对应 WoW 原版八大种族),右侧羊皮纸职业说明写的是 Mage(法师),而画面中央预览的角色是一个持剑的暗夜精灵 —— 按 TASK.md §5.1,暗夜精灵的职业应该是 Ranger 游侠。

为什么重要  TASK.md §5.1 明确规定 6 个种族、每族绑定一个职业。这份 mockup 是在"六族六职业"这个设计决定之前生成的,从未按新规则返工。验收第 3 项的通过条件是"6 个种族按钮…显示该种族的职业",与 mockup 直接矛盾。

03 · 冲突选角稿的等级是 20–60,游戏只有 1–5 级

证据  角色卡上的等级是 60 / 48 / 32 / 28 / 20,还有一个"Stormwind City"的所在地字段。

为什么重要  TASK.md §9.2 规定等级 1–5,§1 规定"一个服务器,显示它的名字,没有服务器列表"。验收第 2 项要求的列表字段是"名字、等级、职业"。

04 · 风险八张世界概念图不是同一种画风

证据  把八张并排看:v2_start_valley_N 和 v2_city_human_inside_N 接近 2004–2010 年的 WoW 引擎截图;v2_biome_* 和 v2_city_stone_inside_* 明显偏手绘卡通;v2_transition_farmland_N 最"玩具低模",几何面块感最强。

为什么重要  TASK.md §4 要求"保持一种一致风格,拒绝破坏风格或比例的资产",并且明确要在任何生成之前先写出 STYLE_BIBLE.md。当八张权威参考本身就不一致时,代理必须先自己做一个统一裁决并记录下来,否则后续每一张生成都会从不同的锚点出发。这是 M0 阶段最容易低估的一项工作。

05 · 歧义"12 个身体"的取色规则没写清楚

证据  race_human_C 和 race_dwarf_C 每张画了 4 个身体(2 男 2 女、两种肤色/发色);其余四族每张只画男女各 1 个。

为什么重要  验收第 4 项要求"全部 12 个种族/性别身体看起来像已批准设定图",但人类和矮人的设定图给的是 4 选 2 的选项,没有说明多出来的两个变体是该舍弃、还是该做成肤色选项。TASK.md §5.2 确实提到"肤色(色调或贴图替换)",但没把两件事连起来。

06 · 歧义牛头人的配色前后矛盾

证据  原版 race_bullfolk_B 是红袍 + 蓝光水晶杖;职业编辑版 v2_bullfolk_B_Egpt 是绿袍 + 绿光藤叶杖。

为什么重要  README 的裁定是"武器和服装以职业编辑版为准,脸/发/身体以原版为准"。这条规则在本例中会造成歧义:袍子的颜色算"服装"(取绿)还是算"身体外观"?需要一次明确决策。

07 · 冲突流程文档与任务书的工具表互相打架

证据  processes/ 里的文档默认的图像端点是 fal-ai/nano-banana-2 及其 edit 版;TASK.md §15 的工具表只列 fal-ai/nano-banana-pro 和 openai/gpt-image-2.5/*。另外 knowledge/3d-gen-preferences.md 把 Meshy 7 重打贴图列为可对比选项、把 Customuse 当作锁定管线,而 TASK.md §15 明确写着 "Avoid: Meshy retexture",且只授权 Higgsfield Tripo H3.1 与 fal Tripo P1 直出。

为什么重要  这是一份从旧项目继承的文档与一份新写的任务书之间的正常漂移。CLAUDE.md 第 1 节规定 Docs/TASK.md 是权威,但这批流程文档被四个技能直接链接引用 —— 代理读到哪一份就按哪一份执行。建议在 M0 就把这份差异固化成一条决策记录。

08 · 风险跨种族体型的动画重定向是从未验证的

证据  PIPELINE_LESSONS.md §7 把自己的风险清单第一条写成:"跨种族体型的 Humanoid 重定向,在仓库里从未验证过 —— Overlord 只用 Generic rig,四个身体共享一套动画集是最冒险的美术任务。"

为什么重要  而当时的做法(第 48 行)是"只用 Generic,从未使用 Humanoid Avatar,即使在 Mixamo 人类模型上"。World of Oldcraft 有 6 种差别巨大的体型(矮人 1.30 m 到牛头人 2.50 m),任务书 §6.5 要求"优先用 Humanoid avatar + 一个共享 Animator Controller,撑不住就在 Blender 里逐身体烘焙"。这条路线要在第一个身体上尽早试,失败了整条角色管线要改道。

09 · 风险自动绑骨没有可用服务

证据  PIPELINE_LESSONS.md §7:"没有任何已验证可用的自动绑骨服务。Higgsfield 的 3d_rigging 和 bl_import_motion 都只是目录里列着、没实测过。"Mesh2Motion、Cascadeur、Animate Anything 三个方案的历史评价是"一直差一点成功,然后崩溃"。

为什么重要  3d_rigging 是任务书 §15 的首选路线,但在经验文档里它是未验证的。回退方案是在 Blender 里手工绑定(每个生物 1–2 小时),这会直接限制生物种类数量。

10 · 风险"不许停"机制是软约束

证据  机制上没有任何东西阻止代理自己创建 .claude/ALLOW_STOP 然后体面地结束会话。.gitignore 只让它不进版本库。

为什么重要  整套长会话设计建立在"代理会遵守 CLAUDE.md 第 2 节"之上。要真停,人得手动关会话或提前写好放行文件。这是有意的设计选择,不是漏洞 —— 但使用者需要知道这条线在哪。

11 · 提示安装器只在 Windows 上跑

证据  安装器是 PowerShell 脚本,参数示例是 C:\GIT\WorldOfOldcraft、C:\Program Files\Blender Foundation\...,还有 winget install 的说明;host-tools/ 三个脚本依赖 ffmpeg 的 gdigrab 桌面抓取设备。

为什么重要  整套工具的原始运行环境是 Windows。在 macOS 或 Linux 上需要自己重写安装步骤(没有 PowerShell 的 gdigrab 等价物,其余步骤都是纯复制 + 下载,可以手工照做)。

13 · 冲突两份文档对 A-pose 的手臂角度各说各话

证据  dot-claude/skills/character-sheet-pipeline/prompts/01a_apose_front.md(母图模板)要求 "Arms angled ~45° down-and-out";而 processes/3d-ai/prompting.md 写的是 "arms held at 30 degrees",knowledge/image-gen-lessons.md 也写 "arms 偏离身体 30°"。

为什么重要  TASK.md §10 的 A-pose 管线同时引用了这两套文档。手臂角度直接决定图生 3D 出来的模型能不能正常绑定 —— 30° 与 45° 是两个不同的目标姿态。代理必须在 M0 阶段做一次明确裁决并写进 DECISIONS.md。

14 · 冲突两套 Python 依赖约束不一致

证据  根目录 requirements.txt 是 fal-client>=0.5(无版本上限);而 dot-claude/skills/fal-ai-generation/scripts/requirements.txt 是 fal-client>=0.13.2,<1 加 python-dotenv>=1,<2。

为什么重要  KIT_README 的安装步骤只让你装根目录那一份。而 fal_job.py 文档里声称的队列 API 行为是按 0.13.x 描述的 —— 按 README 装出来的环境对 fal 客户端行为没有任何版本保证,而这正是消耗 100 美元预算的那条通路。

15 · 歧义机器可读清单与实际内容对不上

证据  KIT_CONTENTS.json 的 scripts 数组只登记了 3 个脚本,漏掉实际存在的 scripts/refs/fetch_refs.py 与 scripts/capture/make_timelapse.py;links_not_copied 声明为空数组,但文档里确实存在断链引用(workspace_video_optimize.py、processes/project-mcp.md、.agents/skills/img2threejs、scripts/shared/report_style.py —— 最后这个被 knowledge/image-gen-lessons.md 引用而该目录并不存在)。

为什么重要  这不是致命问题,但它说明这份清单是手写的、没有校验过。不要把它当作可信的完整性依据;以文件系统实况为准。

16 · 提示批量生图脚本的模型表比任务书宽

证据  scripts/image-gen/generate.py 内置的模型注册表有 14 个 key,除任务书列出的 Nano Banana 与 GPT-Image 系列外,还包含 grok-imagine-2、seedream-v4、seedream-v5-pro 等 —— 其中 Seedream V5 Pro 不在 TASK.md §15 的授权清单内。默认参数是 --model nano-banana-2、--workers 5。

为什么重要  一个"顺手就能用"的脚本里躺着任务书没授权的模型,对追求预算纪律的项目是个小隐患。使用该脚本时必须显式传 --model(PIPELINE_LESSONS 第 21 行也确实这么要求)。

12 · 提示概念图分辨率低于最终贴图要求

证据  已批准的角色设定图大多是 1024×768,界面稿是 1088×608,只有 v2_*_Enano 系列是 2400×1792。而 TASK.md §14 要求主角与主建筑贴图做到 2K。

为什么重要  这不是缺陷 —— 概念图的定位本来就是风格锚点与生成输入,不是贴图来源。但如果误把它们直接当贴图用,会得到明显糊掉的表面。2K 贴图必须由生成管线重新产出。

整体判断

这个包在工程纪律上做得非常扎实:黄金路径必须永远可玩、代理不许给自己打分、失败的尝试要保留、报不出的数字写"未记录"而不是 0。它真正的薄弱处集中在美术权威文件的时代错位 —— 那几张界面 mockup 是在"六族六职业、自创地名、1–5 级"这些决定敲定之前生成的,之后没有返工,却在验收条款里被要求"一模一样地还原"。这是 M0 阶段最值得优先处理的一件事。

12中文翻译

核心文档已全文译为简体中文,与原文件一一对应,放在 zh/ 目录下。

译文原文体积内容
CLAUDE.zh.mdCLAUDE.md10 KB代理的工作规则全文:10 条硬规则。每次启动或压缩后第一个要读的东西。
TASK.zh.mdDocs/TASK.md31 KB完整任务书 19 章:使命、MVP 九步、18 项验收表、六族职业表、世界路线、工具与预算、里程碑、交付物。
KIT_README.zh.mdKIT_README.md8.6 KB给人看的说明:套件构成、一次性环境准备、安装命令、启停方式、预算与授权。
KICKOFF.zh.mdDocs/KICKOFF.md2.1 KB四段可直接粘贴的提示词:启动 / 崩溃恢复 / 给镜头报进度 / 收尾冻结。
PIPELINE_LESSONS.zh.mdDocs/PIPELINE_LESSONS.md23 KB前项目血泪教训浓缩:工具清单、生产路线、Unity/Blender 陷阱、长会话框架经验、给提示词的前 15 条规则、已知风险。
SKILLS-OVERVIEW.zh.md(分析总结,非翻译)17 KB四个技能的分析总结:流水线分工、最高法则、8 阶段 3 闸门、模型路由理由、八条反模式、与项目的适配度与规则冲突。

四个代理技能的译文 zh/skills/ · 19 个文件

译文原文说明
skills/3d-production-routing/SKILL.zh.md3d-production-routing/SKILL.md分诊路由,38 行
skills/character-sheet-pipeline/SKILL.zh.mdcharacter-sheet-pipeline/SKILL.md角色表管线主文档,239 行
skills/character-sheet-pipeline/prompts/*.zh.md (9 个文件)character-sheet-pipeline/prompts/*.md9 个提示词模板(01a–08)
skills/blender-game-animation/SKILL.zh.mdblender-game-animation/SKILL.md绑定与动画,129 行
skills/fal-ai-generation/SKILL.zh.mdfal-ai-generation/SKILL.md生成执行层,78 行
skills/fal-ai-generation/references/*.zh.md (3 个文件)fal-ai-generation/references/*.md3 份参考文档
skills/fal-ai-generation/examples/*.zh.* (4 个文件)fal-ai-generation/examples/*2 个输入示例 + 演练
提示词原文保持英文

这些技能里含有会被直接复制去执行的英文提示词(prompt skeleton、negative 清单、{CHARACTER_DESCRIPTION} 这类模板占位符)。这些内容在译文里保持英文原样不动,中文只作紧邻的说明。把提示词译成中文就没法用了 —— 项目的皮肤是英文提示词,这一点在 CLAUDE.md 里也写死了。

翻译约定

保持英文原样的是:文件路径、代码标识符、MCP 工具名、Unity 与 Blender 的 API 和导入参数、模型与端点 id、CLI 命令、品牌名、资产车道名,以及 implemented / agent-verified / pending owner review 这套状态词。六种族与六职业在首次出现时保留英文并附中文,之后统一用中文。每个译文文件开头都有一行 HTML 注释标明它是机器翻译及其源文件路径。

关键术语对照

原文译文说明
owner所有者项目的发起人,也是唯一有权结束会话的人
lane车道 / 工作线多代理并行时的一条独立工作流,每条独占一类资源
Integrator集成者主循环,唯一有权改动打开中的 Unity 编辑器的代理
gold path黄金路径登录→建角→进世界→战斗→升级→进城 这条必须永远可跑通的主线
gate闸门 / 关卡里程碑或流程里的强制检查点,不过不许继续
greybox灰盒用基础几何体搭的可玩结构,美术资产之前的第一步
fixture夹具跑在 Play Mode 里、把结果写成 JSON 的自动化检查
harness运行框架钩子 + 夹具 + 黄金路径驱动的总称
role edit职业编辑同一角色的武器/服装重绘版本
face_limit / decimate保持原文生成与减面的参数名,不译

没有翻译的部分

以下文件保持英文原样,因为它们是给机器读的而非给人读的,改动反而会破坏引用关系:

这些文档的内容要点已经在本报告第 06 节做了中文提炼,需要时可以参考那里的逐文件摘要。

13独立复核

一个独立代理在文件系统上重新核对本报告的全部结论后给出的补正。

更正

补充

复核后的计数

项目值
approved概念图webp25
approved目录文件总数(含README)26
candidates概念图webp129
approved∩candidates文件名交集25
交集内容逐字节相同25/25
md47
py9
json7
ps14
txt2
env.example(无扩展名计1)1
kit文件总数224
kit目录数32
kit内容字节合计50414335
Docs/refs图片数0(仅 manifest.json 45,069 B)
refs条目70
refs分类hd-target 14 / ui 12 / creatures 9 / frontend 8 / elwynn 7 / stormwind 6 / northshire 5 / goldshire 5 / horde 4
refs年代vanilla 2004=31, modern=18, classic 2019=10, fan remake Unity=3, UE5=3, UE4=2, concept art=3
refs署名含Blizzard Entertainment56
fal_job.py行数214
test_fal_job用例数8
mixamo_clips90
dot-claude/skills文件数22
scripts下py文件数5
install_kit.ps1行数114
hooks脚本行数keep_working.py 36 + after_compact.py 9
kit内cs_unity_prefab_fbx_glb文件
断链引用workspace_video_optimize.py、processes/project-mcp.md、.agents/skills/img2threejs、scripts/shared/report_style.py、projects/overlord/skeleton-animation/* 均实测不存在
world概念图尺寸8张中7张2752x1536,v2_city_human_G为1088x608,实测一致
v1/v2候选mtimev1=2026-09-24 18:39, v2=20:36–21:39,与lane说法一致
复核结论

该 9-lane digest 的事实密度和准确率很高:我逐条抽查了文件数(224)、扩展名分布(webp 154/md 47/py 9/json 7/ps1 4/txt 2/env.example 1)、approved 25 与 candidates 129 及 25 个交集(全部逐字节相同)、refs 无图片且 manifest 70 条的分类/年代/域名计数、fal_job.py 214 行与全部防扣费机制、mixamo 90 clips 与 Dryad UUID 一致性、8 张世界概念图尺寸、v1/v2 mtime 世代、各断链文件、TASK §15 白名单/Avoid 表等,均与原始文件相符。需要修正的硬错误只有一处(测试用例 8 个写成 9 个),另有三处措辞夸大或不精确(refs Blizzard 署名 56 而非约 57、'逐字复用'、negatives 约 25 而非 23),一处实质性误导(把'含暴雪商标词'当 v1 UI 落选实质理由,而已批准的 v2_ui_charselect_fix_G 画面内仍含 Stormwind/Ironforge/Dun Morogh 与狮徽,我已实际打开该图核实)。最大缺口是覆盖面:安装与运行基础设施整层(install_kit.ps1、hooks、settings/mcp/env/根 requirements、5 个 scripts、KIT_CONTENTS.json、host-tools)没有任何 lane 覆盖,且报告没有点明'kit 内 0 行代码 0 个 3D/场景文件、全部产物靠运行时生成与下载'这一定性事实,以及 A-pose 30°/45° 两套文档冲突、根与技能 requirements.txt 的 fal-client 版本约束冲突、KIT_CONTENTS.json 漏登记两个脚本这几处 kit 内部不一致。整体评级:主干可信可引用,基础设施层需补写后再发布。