3D Vibe Coding
手册

§00这本书怎么用+资源包

How to Use This Book, and What's in the Kit

这一节回答四件事：这本书里有什么（三百八十多页、23节加4个附录）、动手之前先得知道什么（去哪注册、免费档够不够用、机器上得先装哪几样）、按你自己的目标该从哪一节翻起，以及随书资源包里有什么、缺什么。五分钟读完这节，你就知道剩下那几百页跟你有没有关系。

先看东西

三张图。一张是能开着老爷车在塞纳河岸上跑的巴黎街区，一张是能走到星球背面去的小王子，一张是能剖开缸体看活塞上下的四冲程发动机。

这三样东西是2026年9月那两周里真做出来的，能点开玩、能拖动、能拆。我不会写代码（所有产品都是AI写的，这是老读者都知道的事），3D更是第一次碰。这本书就是把那两周走过的路原样写下来，每个按钮、每条命令、每次翻车，都带着截图和积分账。

给谁看

你在用Codex、Claude Code、Cursor里的任意一个，做过点东西出来，但没碰过3D，也不打算去学建模。你想做的是能给别人玩的东西：一个网页小游戏、一段科普演示、一个能转能拆的产品说明。

不是给3D美术看的。书里所有「怎么建模」的部分都交给了Tripo，所有「怎么写代码」的部分都交给了agent，我干的事情只有两件：决定哪一层归谁，以及在它们做砸的时候知道是哪一步砸了。这两件事正好是AI替不了的，也是这本书真正的内容。

这本书里到底有什么

先给你一个体量的概念，免得你以为这是一份十几页的速查卡。

三百八十多页这个体量有点吓人，所以先说清楚它的性质：这是一本查的书，不是一本读的书。五个部分之间是并列关系不是递进关系，你从哪一部分切进去都能用。真正需要顺着读的只有Part IV那四节，因为那是一个项目从选题到发布的完整时间线。

我自己检验一本工具书有没有用的标准只有一条：你照着做，能不能得到和书里一样的数。所以书里每个数字都带出处，每个界面都带截图日期，翻车的部分一个没删。

五个部分，各解决什么

开始之前：注册、免费档、什么时候才该订阅

书里的截图全是我自己那个付费账号，余额两万多，你别照着它估成本。真要动手，先把下面五行看完，五分钟就够。

截至2026-09官方标价与界面实测，以官网为准；最新价看tripo3d.com/pricing。

一句话的判断法：免费档帮你决定要不要付钱，帮不了你做出一件能交付的东西。先用它把生成质量看准，再决定订不订。

开始之前：机器上得先有什么

上面那张表管账号，这张表管机器。这些东西书里是分散在各节里交代的（Node在§11、Blender在§13、Unity在§14），第一次读容易走到半路才发现缺东西，所以在这里集中列一次。只想在浏览器里点几下生成模型的话，一样都不用装——下面这些是「要把整本书跟着做完」的清单。

按需跳读

这本书是查的，不是从头读到尾的。按你现在卡在哪儿挑：

• 今晚就想生出第一个能用的模型：§01把表单讲完，§03讲怎么把文件拿到本地，两节够了
• 看完视频来找那四条参考图配方的：§08开头就是，一个框，四条，加一段可以整段复制的提示词原文。想知道为什么是这四条、每一条各挡掉了什么，往下翻到§09
• 想直接抄提示词：§09。它是从我真跑过的95条提示词里挑出来的，大部分配「提示词原文+设计图+ Tripo结果」三联，少数只有提示词原文，能照着改自己那条
• 被积分吓到了：§07和附录C。默认设置下一次生成50积分，其中35分买的是8K贴图；把贴图档位拨到2K是30，只要几何是15
• 模型太重，网页打不开：§04讲减面和重拓扑，§12讲贴图吃显存那件事（17件资产5.38 GB显存，显卡工具按1024进位读作5.0 GiB；降到1024²之后0.22 GiB，折成十进制是0.24 GB）
• 要让人物走起来：§06讲自动绑骨的全流程，做不好再翻§13看Blender里手工绑的对照组为什么更差
• 目标是一款能玩的游戏：§16到§19顺着读，或者倒着从§19的验收清单读起，先知道终点长什么样
• 目标是一段教学演示：§20到§22，三种类型挑最像你那个的
• 已经在做，卡住了：附录B。一共66条，分五块——Three.js与加载GLB 23条、Unity 13条、Tripo Studio与平台侧21条、Blender与格式转换6条、发布与打包3条，渲染成黑、角色发白、一排人同步走这些都在里面
• 不知道该谁干哪一层：§15。如果只读一节，读这节

这本书和资源包怎么拿

这本书是免费的，跟着我那条Tripo视频一起送。领的方式只有一条路：给那条视频一键三连，然后在评论区回复「3d」，我发给你。

没做成一个随便点的置顶链接，是因为我想知道它到底被多少人真的拿走了，这个数会决定我下一本橙皮书写不写、写多厚。你回复的那两个字符对我是有用的信息。

发给你的是这本书的PDF，加上下面要讲的那套资源包。PDF适合在电脑上翻和搜，386页里每一页都有页码、每一节都有书眉，正文里每一处「§12」「附录B」都是可点的，跟着引用直接跳，不用回目录查页码。

微信读书版（EPUB）随后补。那一版会多一封「给读者的话」，其余内容完全一样。没有和PDF一起发，是因为EPUB要把这本书里那些宽表重排成窄屏能读的样子，是另一道工序，我不想赶工出一个在手机上糊掉的版本。

我在视频里说的是「模型、提示词、脚本全在里面」，这句话大体是对的，但有一处例外和两处时间差（一批资产和几个脚本没赶上封版），都写在下面「包里没有什么」那一小节。先读那一小节再解压，比解压完再回来找我省事。

随书资源包有什么

先说盘点口径，免得你以为拿到的是个几百件的素材库。这轮项目里一共140个GLB文件，按模型内部的任务ID去重之后，只有62次真正独立的Tripo生成，其余都是同一件的减面版、降贴图版和引擎工程里的拷贝。从这62次里挑出可以再分发、且设计图和提示词都在本地的，最后进包56件、81.1 MiB，覆盖建筑、载具、人物、道具、植被、机械六类。

先把单位说死，免得你对不上数。全书只有一条规矩：按1024进位量出来的读数写MiB／GiB／KiB，自己按十进制算出来的写MB／GB（这条规矩在§12立的，那儿还解释了为什么显存那笔账按十进制算）。所以这一节里的文件体积一律写MiB（1 MiB等于1,048,576字节），和附录A那张逐件表用的是同一把尺子；macOS的访达按1000进位显示，同一批文件它会写成85.1 MB，不是拷贝出了问题，Windows资源管理器的读数则和这里一致。判据是「量的还是算的」，不是「文件体积还是贴图显存」——同一批文件也会以十进制出现：§12和§17那张38件的对照表写的是534.6 MB降到52.4 MB，对应的1024进位读数是509.9 MiB降到50.0 MiB（附录A那一组），同一批文件、同一个9.8%，只是两种进位。两种进位差多少是固定的（MB和MiB之间约4.9%，GB和GiB之间约7.4%），所以同一笔账的倍数在哪一边都成立，别拿两边的数直接相减。资源包的体积一律看MiB，那是文件本身的数。

挑的时候按两组对照来凑，不是按好看来凑：

这个包是2026-09-11装配的，装完逐件核过一遍：56件的三角面、顶点、贴图张数与尺寸、骨骼关节数、动画片段名、文件体积，全部和附录A那张表对得上，一件都没差；每个文件的头四个字节都是glTF，JSON块能解析，拷进包之后的SHA256和源文件一致。整包221个文件、解压后235.3 MiB，zip 212.3 MiB（访达和浏览器按十进制显示，同样两个数在那儿写作246.8 MB和222.6 MB）。附录A那张逐件清单可以直接当验收单用。

怎么确认你手上那份就是这本书对应的那一版。解压之后核三样：清单.md第一屏写着「装配日期：2026-09-11」，模型/下面是56件，脚本/里是11个文件（其中5个是2026-09-13补进去的，是哪五个见下面「包里没有什么」的第三件事）。三样都对得上，这一节讲的就是你手上那份。对不上的话，以包内清单.md和SHA256.txt为准——那两个文件是跟着包走的，这一节是跟着书走的。

包里没有什么

三件事我提前说，免得你解压之后觉得缺斤少两。

小王子那一组不随包发模型。设计图和提示词全在（22张PNG加5个jobs*.jsonl），照着能把这条流水线完整跑一遍，但GLB和那个可玩demo都撤了，理由在下面警告②。「书里讲了、包里没有」一共两处，这是第一处，另一处是紧接着要说的那批P2.0资产；除掉这两处，书里提到的每一件你都能在模型/里找到实物。

2026-09-12那批P2.0新资产，暂时也不在这个包里。那两天我又用智能网格模式跑了一批巴黎扩展资产（glb-1024/40件、glb-1024-新/13件，合计71.2 MiB），书里§06、§12、§17会拿它们当案例讲工序和数据，但资源包是09-11封的版，它们没赶上。这一版里没有它们，这句话是确定的（将来补不补是下一版的事，补了我会同步改附录A那张「随包／不随包」的标记）。好在这不影响你照着做：§12和§17那条降贴图工序的输入只要是8192²原档就行，包里D组那6件游乐设施正是没优化过的8192²原档，拿它们跑脚本/glb_downscale.py能把同一条工序原样走一遍，数不会和书里的38件一样，但每一步的做法和核验项是同一套。

顺带把这一批的一个数放在这儿，因为它解释了为什么书里到处都在讲降贴图：P2.0出来的贴图是8192×8192的，解码进显存之后单件要358 MB，26件摆进同一个场景就是9.3 GB，显存会炸。降到1024²之后单件5.59 MB、26件145 MB，几何一个三角面都没动：那一轮核过的38件，合计735,232个三角面，降贴图前后逐件相等，省下来的全是图片字节（534.6 MB降到52.4 MB）。全书这笔显存账统一按每像素4字节（RGBA32）展开再乘整条mipmap链的1.33倍算，1 MB当100万字节；你拿显卡工具去对，它按1024进位，读数会比这里小约7%（同一个数在那边是341 MiB、8.67 GiB），不是算错了。怎么做的在§12和§17。

第三件是反过来的：有五个脚本比书晚到，现在补上了。书里§04、§12、§13、§17反复在用glb_downscale.py（降贴图、转朝向、烘变换）、fbx2glb.py（FBX转GLB，带三通道包围盒交叉核验）、render_glb6.py（六机位离线渲图定朝向）、e10_topology.py（数FBX里每个多边形是几边形，解析器和_probe_fbx.py是同一套），第一版装包时它们没赶上，等于教了半天工具拿不到手。现在五个都在脚本/里，进包前逐个体检过：没有绝对路径、没有密钥、没有账号信息。其中fbx2glb.py和render_glb6.py要本机装Blender（它们是用--background模式调它）。下面那张参数表讲的就是glb_downscale.py，配着§12那五道工序和那份八项核验清单一起读。

脚本那一栏值得单说

资源包里最能直接省你时间的其实不是模型，是E2-批量流水线.py和optimize_assets.sh这两个：前者按资产类型给不同的减面率（人和车敢砍到0.25，建筑0.45，树和铁塔只敢0.75），25件跑完131秒、平均5.2秒一件；后者只resize贴图、一根三角面都不动，因为瓶颈从来就不在几何上。

GLB怎么打开

资源包里的模型全是.glb。它是glTF这套3D格式的二进制打包版，网格、材质、贴图、骨骼、动画全塞在一个文件里，拷来拷去不会丢贴图。有四条路可以看它，按「花多久」排：

导出弹层长什么样、Format和Texture Resolution怎么选，§03有那张图和完整说明；左边黄色的「Send To」是直推Blender的出口，走§11。

许可：先看完这段再用

资源包里的模型是我用自己的Tripo付费订阅账号生成的，喂进去的设计图也都是我让agent画的，不含第三方照片、名画扫描件和品牌商标（这句管的是图和模型这两层，提示词那一层另说，见本段末尾和§09第03条）。挑件的时候剔掉了四类有风险的：在产商标车型（雪铁龙2CV）、名画高清复制品裁切（那份复制品的扫描版权没核）、维基照片裁切的发动机与木马、以及和已收录件同源只换了贴图档位的重复文件。第三类要多说一句，因为容易被读成前后矛盾。那两张图当初在维基图页上看到的标注就是公有领域，§02和§20写的是我当时用它的情形；但我没有逐张回去核对每张图的许可证具体是哪一版、有没有附加条件。「我自己拿它生成一个模型」和「把成品随书发给几千个人」是两件事，后者的标准更高——所以这一类在再分发这一层剔掉，不代表当初用它有问题。逐条理由写在附录A末尾。这四类剔的是模型文件本身，管不到你写提示词时拿哪个真实专名当形体的尺子——所以别把上面那句读成「提示词里也没有品牌名」：包里tripo-source/jobs.jsonl的提示词原文里是有的（「与经典雪铁龙2CV同一美术风格」「雷诺4CV造型」这两处），它们只负责把形状说死，没有挂到任何一件资产上，怎么用、用完之后该注意什么，§09第03条有一整条讲。还有个口径你得知道：上面说的剔除只管模型/那六组素材。demo/里那三个可玩版是完整的程序，它们要跑起来就得带着自己那份资产——巴黎里有那辆2CV和铁塔，发动机的活塞连杆来自维基照片，星月夜的村庄柏树来自名画裁切。所以它们是「打开玩一玩、看看这套流水线最后能做成什么样」的成品，不是给你拆出来当素材用的。要素材请用模型/那六组，那里面是干净的。

上面提到的那批09-12的P2.0资产，将来真要补进包也是同一把尺子量：全部是我自己的设计图生的，没有一张输入图来自照片或扫描件；那批里的公交车、警车、游船、共享单车，提示词最后一句全部写死了「车身上不写任何文字、编号与徽章标识」，所以模型上没有品牌字样可以被烘进贴图。下面警告①对它们同样成立。

最后一句关于口径。书里每个数字都有出处：积分数来自Tripo官网定价页和界面上的实际扣费，面数和贴图尺寸来自直接读GLB文件头（不是听工具汇报的），耗时来自脚本自己打的时间戳。没实测过的能力我会写明「未实测」。你照着做如果结果对不上，大概率是版本变了，不是我编的。

§01十分钟跑通第一次图生3D

Your First Image-to-3D in Ten Minutes

这一节结束时，你会有一个能拖着转、能下载下来的3D模型，并且知道那个「生成」按钮上的数字是怎么算出来的、哪几个开关该关掉。

先看这一张图

Tripo Studio打开就是这个样子。整个平台你先只需要认识三样东西：顶栏右边那个闪电符号后面的数字（积分余额）、中间那个拖图进去的框、框下面那两个按钮。

我的余额是两万多，你别照着这个数估成本。专业版订阅每月给3000积分，我这两万多是另外买的积分包。按官方标价，专业版¥140一个月3000积分，折下来一个积分不到五分钱；免费档给200积分，官方自己标的是「约13个模型」。

把图拖进去，价格立刻显示在按钮上

这是整个平台我最喜欢的一个设计：还没生成，按钮上就写着这一次要花多少。你不用去翻价目表，也不用生成完了才知道被扣了多少。

首页这个框够快，但开关只有两个。真正干活的地方在工作台（顶栏左边「3D工作台」进去）。左边竖排一列工具：模型、智能拆分、重拓扑、贴图生成、动画，其中智能拆分和贴图生成下面还各有折叠起来的子工具。这一节只用「模型」那一个，剩下的后面各有一节。

两种模式：高精度模型和智能网格

面板最上面那一排就是分岔口。这两个模式出来的是两种完全不同的网格，不分高下，各有各的去处。

表里的价格是截至2026-09我在界面上看到的标价和实扣数，以官网为准。

那次免费试用用掉之后，按钮上是什么数

上面那张图是2026-09-11，我的预览期试用还在，所以按钮写的是100划掉跟一个0。第二天再进这个表单，试用没了，我盯着按钮看那个数会不会回到100——没有，它是100划掉、后面跟一个65。原价划线、实扣65，之后我连着做的十四件，每一件都是按65走的。

把这一件从头做完要花多少，拆开是这样的：网格65，想要颜色再点一次贴图生成30，合计95。如果只要几何不要颜色，高精度模式那边关掉纹理是15，智能网格这边是65——这两个数是纯几何的真实对比，不要拿默认的50去比，那50里有35分是8K贴图。

十四件乘65是910，这是我2026-09-12那天在网格上的全部开销。加上十三件贴图生成的390和一次自动绑骨的20，那一天一共1320积分。

面数那个框：两种模式数的不是同一种东西

这是我这两周最晚才搞明白、也最容易让人算错账的一件事。

两种模式的设置里都有一个定面数的框（高精度叫Polycount，中文界面叫「面数」），但这个数字在两边数的不是同一种面。高精度出的是三角面，那个数就是三角面的数；智能网格出的是四边面，那个数数的是四边面。而引擎最终只认三角面，一个四边面进引擎要拆成两个三角面。

拿同一张出租车设计图做过一次严格对照：两边都填8000，只换模式那一栏。

同一个8000，智能网格拿到的几何预算是高精度那边的2.09倍。所以「同一张图、两种模式，外观差不多」这句话我原本想写，跑完这一组就划掉了——智能网格那版的保险杠栅条、大灯圈、门把手、雨刷全都在，高精度那版在同样的位置是几块糊过去的面。两边谈不上谁好谁坏，只是同一个数字在两边买到的东西根本不一样。

这组对照还有两个读数值得记下来。一是那个数是个目标不是硬上限：填8000，实得8,596个四边面，超了7%。二是四边面换算成三角面的倍数不是2，只有全是四边形的网格才趋近2。全书那批38件实测落在1.37到1.87倍之间，中位1.75，做面数预算就按1.75估；这一件8,596到15,431是1.795倍，落在分布偏上的位置。完整分布见附录D，实验过程、线框对照图和三条独立测量通道在§04。

几何与贴图：那个弹层里每一个开关

高精度模型模式下点开「通用设置 → 几何与贴图」，会弹出一个七八项的面板。这是整个Studio里信息密度最高的一屏，也是最容易被人一路默认点过去的一屏。

逐项说我是怎么设的：

「Generate 50」这个数字是怎么来的

我一开始以为50就是生成一个模型的价钱。后来干脆坐在表单前面做了件很笨的事：把几何与贴图弹层里的开关一个一个动，每动一下看按钮上那个数跳成多少。全程只看不按，没花积分。

只动一个开关：把Texture关掉。贴图那几行当场全部收起，Texture Quality、Remove Lighting、PBR一起消失，连左栏的8K Texture也灭了。按钮从50掉到15。

再把Texture开回来，逐档试分辨率，得到的是一串很规整的数：

结构就很清楚了：几何15是底价，贴图是个打包加项，2K加15、4K加25、8K加35，Ultra Mesh Quality再加15。默认那50分里，35分是8K贴图，几何本身只占15。

这里有个容易搞混的地方：Ultra Mesh Quality那15分不在默认的50里面。工作台打开时Ultra是关着的，50已经是它关着时的价；开了才变65。把Ultra算进默认价，一整批资产的预算会凭空多出四分之一。每个动作的基础价和加项，完整放在§07。

还有一件事我是被它坑了才知道的。当天早上我截到过一张按钮写65的表单，还以为是另一种模式。其实是我前一次生成把Ultra Mesh Quality开着，弹层顶上那句「We'll automatically save your settings for next time」替我记住了。这个记忆是跨会话的：你为了一件特写资产开的档，会一直跟着后面每一件。

首页那个快捷框又是另一套默认值，同一张图选高精度模型时按钮写55，比工作台的50多5分。首页那个框没有可展开的设置，所以这5分落在哪个开关上，我在界面上核不到，也就不去猜。能用的规矩只有一条：以你按下去之前按钮上当场显示的那个数为准，两个入口的默认开关不一样。同一张图想要同一个价，就都从工作台进，那边每个开关都看得见。

走一遍智能网格：从灰模到上色

下面是我2026-09-11那天用同一张出租车设计图跑的一次完整流程，用的是智能网格的P2.0预览版（免费那一次）。

这一趟的账很清楚：生成0（预览期免费），贴图30，余额25220变成25190。试用只有这一次，之后同样一趟是65加30。同一张图我之前用v3.1 HD跑过一次，Studio右上角报的是18497个三角面、12522个顶点；P2.0这版是5615个四边面，三角化之后是9,800个三角面。进引擎的三角面差了将近一倍，但形体没塌，车灯、格栅、保险杠、顶灯该有的都在。

耗时到底该怎么念

做完一件我总想知道「这到底几秒」，然后发现这个问题有三个不同的答案，而它们都是对的。下面这一列数来自2026-09-12录屏时现场生成的另一辆出租车（智能网格，Quad，6044面）：

这本书里凡是给了秒数的地方，写的都是算子耗时，不含上传和排队。我把口径写死在这儿，是因为这两个数差着将近一倍，你拿16秒去估自己做四十件要多久，会估少一半。图片上传本身也要时间，你的网络和图的大小都算在里面。

一次批量：十四件网格的面数怎么定

2026-09-12我把巴黎那套资产整批重做了一遍，全部走智能网格。这一批是这本书里最像「真的在干活」的一段：十四件网格、十三件纹理，一个下午。

面数没有一个万能值，我按用途分了三档：

看最右边那一列你就明白上一节为什么要专门讲面数口径了：填6000的长椅，进引擎是一万两千多个三角面。一来实际面数会略微超过你填的那个数，二来四边面三角化还要再乘一道，实测倍数在1.37到1.87之间、中位1.75（完整分布见附录D）。做预算请直接拿这一列的三角面数去算，别拿表单里填的那个数去算。

耗时也很有参考价值，下面这些全部是算子口径：最快17秒（长椅），最慢65秒（街角咖啡馆），建筑大多落在45到62秒，人物和车辆落在21到26秒。大体的规律是面数填得越高、结构越碎，跑得越久。

十二件的算子状态全是success，一次重试都没用上。这和我做高精度那批的体感一致：图准备对了，生成这一步本身很稳。真正废掉的那一件，问题出在参数没送进去，下面单说。

这一批唯一浪费掉的65分

凯旋门那一件我做废了，废得很隐蔽：我用浏览器自动化往面数框里打字，框里明明白白写着15000，提交完打接口核参数，face_limit读回来是5000——也就是默认值，65积分打了水漂。

手动点鼠标打字的人不会遇到这条。但只要你打算让Codex或者Claude Code替你批量跑表单——这本书的读者大概率会——这就是第一个坑。根因、正确的写法、还有一个不用等生成完就能验的硬办法（设完面数按一下右方向键看它跳到几），完整在§04。

另外三条只有连着做几十件才会遇到的

十分钟清单

把上面浓缩成一张开工前过一遍的单子：

到这里你手上应该有一个能转的模型了。下一节讲那张送进去的图该长什么样——图生3D的成败，八成不在这些开关上，在你喂进去的那张图上。

§02参考图怎么准备

Preparing the Reference Image

图生3D的成败八成在那张图上。这一节给你一条能背下来的四字配方和它的完整提示词原文、五条展开的硬要求、一个当场判断成没成的验收信号，外加两个我真的翻过的车。

四条配方，先抄走

整本书如果你只带走三样东西，这是其中一样。参考图的配方，压到能背下来的长度就四条：

四条都满足，图生3D的命中率会高到让你觉得这一步不需要技巧。缺一条就开始有东西不对，缺两条基本要重来。

四条翻译成一句能直接丢给出图模型的话，是这样，原样抄走就能用：

单个物体、完整入画、居中放在纯白背景上，四分之三视角，
只有极淡的接触阴影、无其他物体、无文字、无人物。

这句话我在所有设计图的提示词里都挂着，一个字没改过。下面把四条拆开讲为什么，顺带补上第五条——它不在配方里，我却在它身上摔过一跤。

配方之外，这一节剩下的事都在后面两节展开，这里不重复：五条硬要求各挡什么、一整套能出风格一致批次的提示词模板、换题材怎么改、两次翻车（梵高的柏树变成岩石尖塔、活塞裁掉一截变成硬币）、以及开工前的一分钟检查，全在§09；为什么先出设计图而不是文生3D、以及「读Tripo给它起的名字」这个验收信号，在§08。

模板里那些「无XX」只是倾向，不保证

模板前半段里写着「无阴影无文字水印」。这句话大部分时候管用，偶尔不管用。

遇到这种情况先别急着重画。先分清一件事：那个没听进去的东西会不会变成形体。

所以四条配方里真正不能让步的是「一个物体」，另外三条都还有一点弹性。提示词没被完全执行，本身不构成重画的理由。

正面例子：一张横幅怎么改成能用的输入

做旋转游乐场那个demo需要两匹旋转木马。参考图找的是美国Index of American Design的一张水彩记录画，维基图页上标的是公有领域，横幅构图。（同上，这两件木马也只在随包素材这一层被剔掉了，口径见§00。）

关键动作是补背景，不是裁主体。原图本来就满足五条要求里的四条：单物体、全身入画、浅色背景、接近四分之三视角。缺的只是比例，那就补背景，别动主体。

结果是两匹木马都一次过，Tripo认成ornate horse和carousel horse，各50积分。后来做旋转逻辑的时候还发现一条：Tripo出的木马朝向是固定的，长轴沿Z，代码里统一转九十度就能让它们沿切线站好。

§03生成之后

After the Generate Button

模型跑出来了，接下来三件事：看懂右上角那三行读数、在正确的地方验收、把文件真的拿到手上。最后一件不止「点导出」一条路，做到十件以上，走接口比点按钮省事得多。

右上角那三行数

生成完成，画面右上角会出现三行：Topology、Faces、Vertices。这是你对这个模型的第一手了解，比看图靠谱。

生成完成后右上角那块读数区见§01那张图：Topology Quad、Faces 5615、Vertices 5381；底栏从左到右是撤销／重做、Free Retry、Texture 30、3D Print、收藏、Share、Export。

巴黎那批资产的面数，我有一份完整统计可以当参考：31个GLB、29个独立资产，面数从16711到46196，中位数18509，一个超过10万面的都没有。

这份统计里有一件得单独拎出来说，不然它会骗你：46196那个最大值，是奥斯曼建筑重拓扑之后的面数，它直出时是92.7万面。那是镂空阳台栏杆那种结构，复杂度由对象本身带来——同一批里结构简单的埃菲尔铁塔，直出只有1.9万面。这一件也是29件里唯一走过重拓扑的，其余28件全是直出，一次重拓扑都没用上，默认就落在1.5到2万面这个游戏可用的区间里。那92.7万面怎么压到2万多的四边面拓扑、代价是什么，在§04；同一件在减面实验里的逐行读数在§17。

想让面数从一开始就落在你要的量级，办法在按下生成之前：高精度模型的「几何与贴图」弹层最底下有个Polycount滑块，在那儿先把数定死就行（§04）。我做奥斯曼建筑那一件的时候还没翻到这一栏——§04开头那句被我自己推翻的错话，就是这么来的；后面几批一律先设面数，再没出现过这个量级。

验收去Tripo自己的预览页，不在你的引擎里

这一条是我踩坑踩出来的，而且踩得很典型。

做小王子那个demo的时候，我一度判定玫瑰和狐狸两个模型都重建失败了。在我自己的引擎里看，玫瑰是「一团皱巴巴的红块」，狐狸是「摊在地上的一坨」。我当时甚至已经往经验库里写了一条归纳：细长结构是图生3D的弱项。

两次判断都是错的，那条归纳也是错的。

错在哪儿？我是在夜景、低角度、贴得很近的截图里下的判断。那种条件下，低多边形模型会退化成一个剪影，红玫瑰缩成一个红团，狐狸缩成一坨。这是我判定方式的问题，不是资产的问题。

更要命的是，Tripo的预览页是免费的、直接的、权威的一手证据，任务详情页一进去就是它。我却跳过它，拿自己引擎里一张光都没打对的截图下了结论。

做到十几件之后，预览页就不够用了

一件一件点开预览页，点到一半就不想再点了。2026-09-12那批十三件，我改成把文件取到本地（怎么取，下面两节就讲），用固定机位批量渲一组图，一次看完。

/Applications/Blender.app/Contents/MacOS/Blender --background --factory-startup \
  --python _verify/render_glb.py -- <某个.glb> <输出.png> 640

它出四张，机位按glTF的坐标约定固定死：−Z（正前）、+X（右）、+Y（顶）、斜45°。全程不开浏览器、不点鼠标，十三件一起跑几分钟就完。

这组图能一眼看出三件事：贴图有没有贴歪、比例对不对、正面朝哪个方向。最后那条最容易被忽略，代价也最大——等一整条街的行人都背对着马路才发现，要返工的是摆放代码，不是模型。各家资产的朝向口径不一样，§12有完整的一张表。

导出弹层

底栏那个蓝色「Export」按钮点开，是一个四行的弹层。

File Name：预填的就是§02说的那个自动命名。这辆车它认成了「vintage car 3d model」，对的。你要改名字在这儿改，但改之前先读一遍原来那个。

Format：下拉展开是六种，USD、FBX、OBJ、STL、GLB、3MF，默认落在GLB上。

我这次全程只导GLB，网页和引擎都吃它，一个文件里把网格和贴图全打包了。其余五种我没有逐个导出验过，所以只说界面给了什么，不说它们各自好不好用。上传那一侧接受的是OBJ、FBX、STL、GLB四种（工作台右侧「上传3D模型」那个框上写着，150 MB以内），比导出少一个USD和一个3MF。

Texture Resolution：这里选1k。这是§01那条警告的落点。Tripo默认导8192×8192，一张底图摊进显存是358 MB，十几件资产就能吃掉5.0 GiB显存。在这个下拉里选1k，同样的场景降到0.22 GiB，游戏距离上肉眼看不出区别（这两个GiB是显卡工具那侧按1024进位的读数，换成本书算显存的十进制口径是5.38 GB和0.24 GB，口径见§12）。

「不收费」这句话我后来补了一次正面证据。做那组模式对照实验的时候，我从详情页导过一次FBX，导之前余额20205，导完还是20205，一分不动。导出格式转换这一步确实不吃积分，你要GLB要FBX要OBJ，想导几次导几次。

Send To：直接推给DCC Bridge，不落本地文件。要接Blender的话这是最短的路，具体在§11。

Assets页：你的东西都在这儿

那排筛选条比看起来有用。资产做到几十件的时候，「哪些还没上贴图」「哪些已经绑过骨」靠肉眼在缩略图里翻是翻不出来的，点一下Untextured或者Rigged就齐了。

走接口拿GLB：绕开那个「另存为」对话框

点「导出」走的是浏览器下载链路，会弹一个系统级的「另存为」对话框。你自己点没问题，但只要你想批量、想让AI agent替你跑，到那个对话框就得停手——原生文件对话框是任何浏览器自动化都进不去的地方。

所以我换了条路：不碰那个按钮，直接去走数据本身的通路。按该用的顺序有三条。

路子一：官方开放API（正式集成走这条）

要把取文件这件事写进脚本、接进自己的工具、交给agent自动跑，正经入口是官方开放API：基址https://openapi.tripo3d.com/v3，API Key在platform.tripo3d.com创建，认证走Authorization: Bearer <token>，任务轮到status: "success"之后从output.model_url取GLB。这条路是公开文档写明的，字段有版本号兜着，不会因为网页改版而失效。

有一个前提得先知道：API的额度和Studio的订阅是两套账，要分别购买。所以走这条路之前先去platform.tripo3d.com/billing把API钱包充上，别拿Studio的余额去推算它。完整的接法、CLI和插件怎么用，在§11。

路子二：应急——只有几件、又暂时没配API Key时

先说清楚定位：签名链接约两天就过期，这条通路也没有版本承诺，正式集成请走路子一。它只解决一种情况——手上就三五件，API Key还没申请下来，先把文件拿到手。

页面加载模型预览的时候，本来就会去请求CDN上那个GLB。在资产列表里点一下，让详情页把模型真的加载出来，打开浏览器的网络面板，在请求列表里找那条.glb，右键复制地址就行。

那是一条CloudFront签名URL，过期了回页面重新加载一次，换一条新的出来。

路子三：知道站内接口存在就行，别依赖它

Studio网页自身还有一套站内接口，2026-09-12那批资产我当时就是从那儿取的。但它没有公开文档、没有版本承诺，路径和字段随时会变，还得挂着你浏览器里的登录态，所以我不把具体怎么调写进来。要批量、要写进产品、要交给agent长期跑，请走路子一的开放API——那才是有版本号兜着的那条。

不管URL是从路子一还是路子二拿到的，下载那一步我写了个小脚本，一并做解码和校验：

python3 pull_glb.py --url '<编码过的URL>' --out 产出/rose.glb
# URL 太长或者带特殊字符，就先存成文件再喂：
python3 pull_glb.py --url-file /tmp/u.txt --out 产出/rose.glb

它做三件事：URL如果被编码过就解一次码，下载，然后校验文件头四个字节是不是glTF。最后打印文件名、体积和哈希前十六位。这一步的意义是拿到正面证据：拿到的确实是一个GLB，不是一个改了扩展名的错误页。

还有一条容易踩的：Smart Mesh出的模型，取到手的成品文件是output_mesh_<id>.fbx，不是GLB。别拿GLB的解析器去读它然后怀疑文件坏了。带贴图的那一版是tripo_texture_<id>.fbx，绑骨那两个是tripo_rigging_<id>.fbx和tripo_retarget_<id>.fbx，都是FBX。要进网页得先转成GLB，那道工序在§17。

十三件串下来是什么体感

不走导出按钮批量取文件这件事，我在2026-09-12那批上跑满了一轮，有几个数值得先知道：

把模型传回Tripo接着做

导出不等于结束。减面、拆件、绑骨这些都在Tripo里做，你也可以把外面的模型传进来。上传支持OBJ、FBX、STL、GLB，150 MB以内。

传进去之后会先弹一个对话框，要你把模型转到一个「特征信息足够的角度」。

看左边那一列示例，你会发现它和§02讲参考图的四条配方是同一个道理：能看见特征的那一面才算信息，看不见的那一面等于没给。参考图是这样，模型的分析角度也是这样。

拿到文件之后去哪

GLB到手，后面的路就宽了。我这两周把它们送去了三个方向：Three.js做成能在浏览器里走进去的世界、Unity做成原生可玩的版本、Blender做减面和绑定的返工。

这一节要记住的

到这里，「一张图变成一个能用的模型文件」这条最短路径就走完了。接下来两节讲怎么把它变便宜、变轻、变成可以拆开动起来的零件。

§04减面与重拓扑

Decimation and Retopology

读完这节，你会知道自己手上这个模型到底要不要减面、面数该定多少、什么时候花那10积分走一次重拓扑。中间夹着一场我花15积分做的受控对照实验：同一张图、同一个面数上限，只换几何模式那一栏，两边出来的网格根本不是一回事。还有一个更重要的事实：拖慢你游戏的多半不是三角形。

先去数一遍面数，多半你用不上重拓扑

我做巴黎那个可驾驶街区demo的时候，心里一直装着一句自己写下的话：网页版默认把面数拉满，prompt里写low poly也不听，所以必须走一次重拓扑二次处理。这句话在项目README里躺了两天，后来我把31个GLB文件全解析了一遍，才发现它是错的。

真实数字是这样：29个独立资产，面数落在16711到46196之间，中位数18509，没有一个超过10万面。（31个文件里pedestrian-01有静态、绑骨、动画三个版本，是同一个网格，去重后是29个。）这个量级本来就是游戏能直接用的，整个巴黎项目一次重拓扑都没用上。

那句错话是从哪来的？它来自更早一次实测，那批资产里镂空精细的奥斯曼建筑天生927K面，也就是92.7万，得走重拓扑压到2万多面的四边面拓扑才进得了引擎。我当时在README里把它写成了「927万面」，同一节的下一行写的却是「927K面」，同一个927，一处万一处千，差十倍。自己项目的文档也是待核实来源，不是事实。

三个词先说清楚

面数就是这个模型由多少个小平面拼成，面越多形状越细腻，显卡每帧要处理的东西也越多。三角面是三个顶点围成的面，引擎最终认的都是它；四边面（Quad）是四个顶点围成的面，做动画和手工改模型时它更听话，因为边能连成一圈一圈的走向。

重拓扑是把同一个形状用一套全新的、更规整的面重新铺一遍，形还是那个形，铺法换了。减面（业内也叫decimation、simplify）是在原来那套面上做合并删减，不重铺。两者都能把面数降下来，但重拓扑给你的是干净的边环走向，减面给你的是更少的三角形，代价是拓扑更乱。

上面这三段是定义。定义谁都能背，问题是四边面到底值多少钱、值不值你多付的那几十积分。这件事我不想靠转述别人的说法，所以专门跑了一次对照实验。

E10：同一张图，只换模式那一栏

这个实验编号E10，2026-09-12跑的，总共花掉15积分。要回答的问题只有一句：同一张参考图，走高精度模型和走智能网格，出来的网格差在哪，差多少。网上能查到的说法全是定性的——「四边面更好改」「三角面更适合直接渲染」——我想要能数出来的数。

第一步：把输入锁死

对照实验最容易垮在「两边其实不一样」上。所以先说控住了什么。

「同一张图」这四个字我不想靠记忆。把两个项目的接口返回里image_to_model.image指向的input.png各自拉回本地，连同源文件一起算SHA-256，三方对：

A 的 input.png    1,141,563 字节  c2c01442…f102b6ab
B 的 input.png    1,141,563 字节  c2c01442…f102b6ab
本地 car-01-taxi.png             c2c01442…f102b6ab

逐字节相同。有意思的是这两次上传在Tripo那边是两个不同的对象（20260912/0f78f762…/input.png和20260912/fd811639…/input.png），路径不一样、内容同一张。哈希这一步别省。「我记得我传的是同一张」和「这两个文件的SHA-256逐位相同」，在证据等级上差着一整个数量级，而一个对照实验的全部价值就押在这个等级上。

第二步：数出来的结果

那个62秒是算子耗时，从接口的1789196500减到1789196562算出来的（算子耗时口径，不含上传与排队；端到端要往上加，两个口径的实测差见§01，词条见附录D）。

第三步：三条独立通道互相核对

四边形占比这个数有个麻烦：只有解原生文件才看得到。平台预览会三角化，导成GLB也会三角化，你在网页里和在Three.js里都数不出来它原本是几边形。所以这个数必须自己去文件里挖，而只要是自己挖的数，就得有第二条路来验它。这次用了三条。

前两条逐位相同：四边形、三角形、N边形三个桶的计数一个不差，连「接近」这种说法都用不上。第三条独立确认了A。这样这张表上的数就不是某一个脚本的自说自话了。

第四步：线框图上一眼可见

左边是一锅三角汤：车身、车顶、轮毂上全是走向随机的三角形，没有任何一条能辨认的结构线。右边是规则的四边形网格：车身板件上横平竖直，轮毂是放射状的四边形，车窗、车门缝、保险杠周围能看出明确的边环（edge loop，一圈首尾相接、走向一致的边）。

结论：同一个8000，几何预算差2.09倍

我视频脚本里原本有一句「同一张图，两种模式出来的东西外观差不多，但后面能改的程度完全不一样」。跑完这一轮，前半句得改。

两件的包围盒比例几乎一样（1.000×0.533×0.567对1.000×0.511×0.538），整体形体确实是同一辆车。但细节层级差得很明显：B有保险杠的栅条、大灯的圈、车门把手、雨刷、车内的方向盘，A在同样的位置是几块糊过去的三角面。

原因在于face_limit这个数字在两种模式下数的不是同一种东西：

所以这一轮的实话是：智能网格在这次对照里既更细、又更好改，代价是65积分对15积分。贵的那一档贵在哪，这张表把它摊开了。要纯静态道具、扔进场景里远远看一眼就完事的，15积分那档完全够；要进Blender接着改、要绑骨做动画、要在近处被人看仔细的，多付那50分买的是下面这两个动作。

四边形到底买到了什么：Blender里的两个动作

「可编辑性更好」这句话太滑了，谁都能说，听完还是不知道好在哪。所以我把B那件拖进Blender，做了两个最常见的动作，录成了画面。

动作一：推细分

细分（Subdivision）就是把每个面再切细，顺便把表面推光滑。对四边形网格来说这件事特别听话：一个四边形切成四个四边形，网格走向不变，只是密了一倍。

这三个数是能用笔算验的，我很喜欢这一点。Catmull-Clark细分的规则是：一个四边形变四个，一个三角形变三个。B这件有6,835个四边形和1,761个三角形，那么一级之后应该是6835×4 + 1761×3 = 32623。和Blender里读出来的32,623一模一样。一级之后全是四边形了，所以二级就是32623×4 = 130492，也对上了。

能对上这件事本身就是个交叉验证：它同时证明了「6,835个四边形＋1,761个三角形」这个拆分是对的。如果四边形占比数错了，这两个数就对不上。

动作二：画一条边环

边环是一整条首尾相连、走向一致的边。在四边形网格上选中它只要点一下，然后就能整条推拉、整条加细、或者在它旁边再切一刀加出新的结构线。这是手工改模型时最常用的动作，没有之一。

有一条得说清楚：这条边环不是闭合的一整圈。它从车后窗一路走到车门上沿就断了。我去查过断点，两端的终止边都只连着一个面，也就是模型在那两处本来就有开口边界，边环走到边界自然停下——不是被三角面卡住的。要形容它，说「一整条边环」比说「一整圈」准。

另外这件模型的拓扑里找不到一条又长又闭合、还正好朝着镜头的竖向横截面环。我扫了全模型1,732条边环去挑，唯一符合的那条只有20条边，而且大半被车身挡住。79.5%四边形不等于「拓扑跟人手工做的一样漂亮」，它给你的是「大部分地方能用边环工具」，不是「处处都有教科书级的边环布局」。

面数在生成表单里就能定，不用等生成完再补救

这是我自己走了弯路才明白的一条。高精度模型那一侧，展开「General Settings → Geometry & Texture」，弹层最底下就是Topology和Polycount。

那个弹层的全貌在§01。这里只取两个读数：Topology默认Triangle，面数控制滑块量程500到2000000。还有一个数不在那张图上——§01那一屏的滑块被人拉到了上限，不是默认落位——这个滑块的默认值是20000，见§01那张逐项开关对照表。

默认20000这个数，正好解释了为什么我那批资产普遍落在1.5到2万面：它不是随机的，它就是表单里那个默认值。弹层顶上还有一句「We'll automatically save your settings for next time」，意思是你改一次，后面都跟着走。

智能网格那一侧是另一套默认值（弹层见§01）：四边面默认选中，Polycount量程500–25000、默认5000。

两边的默认值差了四倍，这件事在你按下生成之前就已经决定了一半。想要低模，改这个滑块，别在提示词里写「low poly」——提示词管的是形状和风格，管不了这个数字。

重拓扑这一页，每个开关是什么

左侧工具栏第五个是重拓扑。选中Assets里的模型，或者直接上传一个（OBJ / FBX / STL / GLB，150 MB以内），左边面板就三样东西。

底下那个按钮写着「Retopology 10」，10就是积分数，跟你把Polygon Count拖到500还是50000没关系——滑块怎么拖，按钮上都是同一个数。

10积分和50积分，什么时候按哪个

拿它去比的那一头是重新生成：再跑一次高精度模型，界面默认标50，其中35分是8K贴图，把档位拨到2K是30（这笔账在§07）。

判断标准其实很简单，看你不满意的是什么：

重拓扑有它的代价，这条我实测撞过：那栋奥斯曼建筑压到2万面档位之后，精细的镂空阳台栏杆糊成了一团，细节只能靠贴图补回来。纯建模层面，2万面撑不住那种装饰性结构。面数预算的物理限制就摆在这儿：2万面撑不住那种装饰性结构，想留住它，得靠贴图而不是几何。

四边面的面数怎么换算成三角面：系数是1.75到1.8

这条坑得挺隐蔽。那栋建筑重拓扑之后，Tripo界面上读数是2.4万面，我在README里也是这么记的；后来跑E1实验解析同一个GLB文件，数出来是41106个三角面。

两个数都没错，因为界面在拓扑选四边面时数的是四边面，而导进引擎时四边面会被拆成三角形，一个变两个。做面数预算要按三角面算，别按界面读数算。

但这里有个我自己写错过、必须改回来的地方。我一度把这条换算写成「大致乘以二」，那是高估。因为所谓的四边面模型从来不是纯四边形，里面总混着一部分三角形，而三角形拆成三角形是一比一，不翻倍。真实系数是这么来的：

三角化后面数 ÷ 原生面数 = 1 + 四边形占比

E10那件四边形占79.51%，1 + 0.7951 = 1.795，而实测是15431 ÷ 8596 = 1.795。9月11日那辆P2.0出租车四边形占74.5%，1 + 0.745 = 1.745，实测9800 ÷ 5615 = 1.745。两次都对得上小数点后三位。

同一张出租车设计图走智能网格出的结果见§01：Topology Quad / Faces 5615 / Vertices 5381，线框能看出规整的四边面走向。

能减到多少，由几何有多光滑决定

E1这个实验的方法很笨：拿11个真实资产，每个都跑一遍gltf-transform simplify，比例依次取0.5、0.2、0.1、0.05、0.02，记下面数不再往下掉的那个拐点。脚本在三模式实验/E1-减面极限/run.py。表里的「原始面数」是直接读GLB的索引访问器算的：indices.count ÷ 3，也就是文件里实打实写了多少个三角形。

规律不在类别那一列，在几何本身：人体是连续曲面，砍到3.3%还认得出是个人；车和长椅是大块平滑面，10%上下；建筑有大量直角、窗洞、栏杆，只能到37%至44%；铁塔那种格构结构和树那种分离薄片，几乎砍不动，70%到95%就是它们的地板。

为什么会这样，想一下减面算法在干什么就清楚了：它找相邻的两个顶点，判断合并之后形状偏差大不大，不大就合并。连续曲面上到处都是「合并了也看不出来」的点，所以砍得动；而一根钢梁只有八个顶点，合并任何两个，那根梁就塌了。光滑度这个词，说的其实是「有多少个可以被牺牲掉的顶点」。

这张表里的数字是「再减就崩」的断裂点，不是拿来当生产参数用的。真跑那25个资产时我用的是人物／载具／道具0.25、建筑0.45、树和铁塔0.75，全都留了余量。还有一个口径要交代：E1的分母是已经处理过一遍的副本，不是Tripo直出的原始文件（最明显的是表里那棵梧桐，7473已经是减过一轮的，Tripo刚生成出来是18414面，见§17），所以这些百分比只能横向比较各类资产之间的相对关系，别拿单个数字去对你自己的模型。

所以别拿一套统一参数跑全库。统一给0.25，人物那边浪费了（本可以更狠），建筑那边直接毁掉细节。

批量清洗：25个资产131秒

E2就是把上面那条结论变成一条流水线：按几何类型分配减面率，人／车／道具给0.25，建筑给0.45，树和铁塔给0.75，逐个先simplify再optimize。

npx --yes @gltf-transform/cli simplify in.glb tmp.glb --ratio 0.25 --error 1
npx --yes @gltf-transform/cli optimize tmp.glb out.glb --compress quantize --texture-size 512

两条要交代清楚的：第一，那35%的体积下降里有一部分是--texture-size 512的功劳，不全是减面；第二，每个资产5.2秒里大部分是npx的启动开销而不是计算，真要批量跑，把gltf-transform装成本地依赖而不是每次npx，能快一大截。

面数预算怎么定：先量，再谈数字

「多少面算多」这个问题，我原先给的是一个绝对数：一个网页demo全场景控制在30万三角面以内。回头把本书里真跑过的读数排到一起，这条经验值站不住，而且它错的方向正好是本节反复警告的那一个——它会让你砍过头，把本来塞得下的东西砍掉。

三组读数，全都出自同一台机器（MacBook Pro，Apple M4 Pro）：

最后那一行要读准：16.7毫秒是被垂直同步顶住的帧间隔，不是GPU真忙了多久，它只说明「没掉帧」，说不出还剩多少余量。真把余量量出来的是中间那一行——244万三角面、77个绘制调用，渲染一帧只花5.0毫秒，离16.7毫秒的预算还有三倍多。

也就是说，本书里跑得最重的那个demo，三角面是「30万」那条建议的九倍，帧率一帧没掉。所以这条经验值得换个说法：三角面不是这两个demo的瓶颈，绘制调用和贴图才是。两个佐证都在书里——巴黎那一轮把实例配额调大，三角面从144万涨到244万，绘制调用还是77一个没加，渲染耗时从2.7毫秒只涨到5.0毫秒（附录B）；而小王子那边GPU只忙0.37毫秒的时候，页面照样卡得没法看，真凶是31张贴图吃掉的5.0 GiB显存（＝十进制的5.38 GB，口径见§12）。

面数当然还要管，只是它管的是单件而不是全场景。逐件的分配大致这样：主角和特写对象给1.5到2万（Tripo默认值正好落在这儿），中景道具5千到1万，远景和需要成百上千个实例的东西1千以内、或者干脆用程序化几何。单件实在压不下来还有个后手是LOD——同一个物体准备几套精度不同的模型，离得远时换成粗的那套。

Blender里减和命令行减，产出是一样的

E0那次实验专门比过三条路：全程Blender、直连命令行、以及两者混搭。结论对我来说挺解气：减面这件事上Blender和命令行的产出是等价的，同样的比例、同样的面数、观感上分不出来。所以如果你不会用Blender，减面这一步完全不必为了它去学。

Blender真正不可替代的地方在别处，是绑定和权重编辑那一层，那是§13的内容。混搭那一版的收益也很具体：多付15%的三角面，换来14栋建筑而帧率不掉。

还有一条我得说清楚：Tripo自带的重拓扑和本地的gltf-transform simplify，我没有做过同资产、同目标面数的正面对比。它们做的本来也不是一件事（一个重铺、一个删减），但「同样降到2万面，哪个观感更好」这个问题，我手上没有数据，所以不替任何一边说话。这条实验在我的待办里编号E8。

做完减面还有一件事值得先算：你打算用GLB替换掉的那些程序化物件，替换后的三角面总量是多少。巴黎那座城的行道树原先是程序化的实例，全城两万株只吃9个draw call、8.4万三角；我一度想全换成Tripo的树，近景档的实例上限是150株（这150是总配额，几个变体分摊它，不是每个变体各150），真换上15k三角的GLB，光近景一项就是225万三角，是整层预算的26倍。

程序化树和换成Tripo GLB之后的对照图在§17（同一组对比，那里还带着减面前后的面数）。

减面之前先去量贴图

这一节到这里全在讲怎么把面数降下来，所以必须补一句反的：你手上那个卡顿，多半不是面数造成的，减面救不了它。

前面定面数预算那一段引的0.37毫秒，出处就是这件事。做小王子星球那个demo时页面卡得没法看，我丢给agent的原话是「性能需要优化500%」，但我没让它直接去减面，先量了一次——整条后期链只吃掉16.7毫秒预算里的0.37毫秒，卡顿不可能来自三角形。真凶是31张贴图占掉的5.0 GiB显存（＝十进制的5.38 GB，口径见§12）。只用gltf-transform resize把贴图降到1024²、几何一个面不动，显存就从5.0 GiB掉到0.22 GiB，三角面147,879一个没变。怎么量、命令怎么敲、逐项前后数据长什么样，在§12有完整一节。

什么时候该走重拓扑

把这一节收成一张判断表：

我真跑了一次，结果和我填的数对不上（已结案）

上面这些都是账面上的说法，最后我还是花10积分跑了一遍，拿一栋鬼屋当样本。它是v3.1 HD直出的，三角面18462、顶点12685。

我把Polygon Count的文本框改成5000，按回车，页面没有任何反应（滑块有没有跟着动我也没看清），然后按下重拓扑。等了两分钟左右。

拓扑确实换成四边面了，面数却没落到我填的5000，而是13272。当时我给自己留了两种可能：要么那次输入根本没提交上去（页面确实一声不吭），要么四边面的计数口径本来就不一样。写书的时候我把它标成了悬案。

第二天这个悬案就结了，而且答案是两种可能同时成立。

第一层：输入框的状态没同步，页面一声不吭

9月12日批量跑P2.0的时候我又撞上了同一件事，这次留下了铁证。凯旋门那件，面数输入框里明明白白显示着15000，提交完去接口读回来，face_limit是5000，也就是默认值。65积分就这么打了水漂。

根因是这个输入框背后是响应式框架托管的：你（或者你的脚本）把字打进DOM，value确实变了，但框架内部那份状态没收到通知，提交时它拿的是自己那份，也就是默认值。界面上你看到的是15000，提交出去的是5000，中间没有任何提示。

手敲键盘一般不会触发这个，因为真实按键会派发完整的事件链；用自动化脚本往里灌值就必中。正确写法是绕过属性赋值、直接调原型上的setter，再手动把事件补齐：

const tb = [...document.querySelectorAll('input')]
  .filter(i => i.type !== 'file' && /^\d+$/.test(i.value)).pop();
const set = Object.getOwnPropertyDescriptor(
  window.HTMLInputElement.prototype, 'value').set;
set.call(tb, '15000');
['input','change','blur'].forEach(e =>
  tb.dispatchEvent(new Event(e, {bubbles:true})));

第二层：两边的8000，数的东西不一样

第二种可能也是真的，而且就是本节开头E10那场实验证出来的：智能网格的面数上限数四边面，高精度的数三角面。同一个数字填进去，一边给你8,596个四边面（合15,431三角），一边给你7,379个三角面。重拓扑这一页的Polygon Count是同一套逻辑——拓扑选了四边面，那个数字数的就是四边面。

套回鬼屋那件：默认值是10000（四边面口径），实际跑出来13272个四边面。按前面那条1 + 四边形占比的公式，如果它接近纯四边形，进引擎大概是两万四到两万六千个三角面，和原来那个18462三角面的版本比，面数其实是涨的。我以为自己在减面，其实是在换拓扑，顺手把三角面数推高了。

给你的操作建议就三句：按下按钮之前，先用ArrowRight验一次那个数进没进去；按下按钮之后，回头对一眼右上角那三行读数；心里记着四边面那一列的数还要乘上1.75到1.8才是引擎看到的数。这三件事加起来花不到十秒，能省掉一次65积分的空跑。

§05智能拆分与贴图生成

Part Segmentation and Texture Generation

这一节解决两个问题：怎么让一辆车的轮子真的能转，以及怎么用同一个几何做出一整条街不重样的房子。两件事都是在模型生成之后做的，各自有一条明确的入口和一个明确的价。

轮子转不了，不是因为没做

巴黎那个demo里有可驾驶的老爷车，开起来的时候轮子是不转的。我一开始以为是自己偷懒没写那段代码，去查才知道根本写不了。

E3这个实验是专门为这件事做的。用Blender的mesh.separate(type='LOOSE')按连通分量切开模型，理论上互不相连的几何块会各自独立出来，轮子应该就掉出来了。

切出来的是几百个100到650面的碎片。AI生成的网格不是一整块干净的曲面，它是碎的，而且轮子和车身在几何上是糊在一起的，连通分量这把刀根本切不到它们之间的缝。这条同时解释了另一件事：为什么Blender的自动权重绑定会塌（那是§06的内容），根因和这里是同一个。

想明白这一点之后，很多现象就串起来了。行业里对AI生成网格有个常见评价，说它「多边形分布均匀、边环不贴合解剖结构」，听着抽象，翻译成人话就是：这些模型是从一团体素或者一个隐式曲面上抠出来的，算法只保证外表面对，不保证内部结构有意义。它给你的是一层壳，不是一个装配体。

所以那18076个面里，没有任何一处记录着「这里是轮胎和挡泥板的分界」。人眼能看出来，是因为人认识车；几何算法看不出来，因为几何上那里什么都没有。

语义分件是什么

语义分件就是按「这块是什么」来分，而不是按「这块和那块连不连着」来分。轮子之所以是轮子，是因为它在语义上是轮子，不是因为它和车身之间有一道几何缝隙。这件事纯几何算法做不了，得有一个理解「这是一辆车」的模型来做。

Tripo Studio左侧工具栏第三个就是它，叫智能拆分，它下面还挂着一个Fill Parts。这一节只讲智能拆分，因为它是「车能不能动」这条路上唯一的关口。

智能拆分这一页，先看清两条前提

那两条限制直接决定了你的工序顺序：

这条不用你去猜，Studio会当场告诉你。9月12日我录操作过程的时候，拿一个四边面模型进了智能拆分，页面直接给出提示：四边面模型不支持拆分。它在你花钱之前就把话说在前面了。所以这条规则你其实不用背，按下去之前看一眼右上角那行Topology就够了：是Quad，就知道该先绕去哪一步。

上传之后的第一个弹层：Find the Best Angle

「Find the Best Angle」弹层见§03：左栏用四组正反例告诉你什么角度算「特征充分」，右边是模型和X/Y/Z三个数值框。

它的提示语写的是「Adjust the view to an angle with sufficient feature information of the model」，看着像在让你调相机。但那三个X/Y/Z数值框动的是模型自身的旋转，不是视角。我在绑骨那一轮就是按字面理解去拖画面，结果X被带到了-71.59，整个人躺平了，后面那一步直接失败。

正确做法：进来什么都别拖，确认X/Y/Z是0，点Confirm。真要转着看，用滚轮和右键，那两个操作不写进数值。「Use Original UV」保持开着，它决定了拆出来的部件要不要沿用原来的贴图坐标，开着才能让拆件后的贴图不错位。

Detail Level：三档，决定你拿到几个零件

三档给出的是部件数量区间，不是精度档。想要「能开的车门、能转的轮子」，Balanced起步；只想把一个角色分成头、身、四肢做换装，Simple就够；Detailed那一档我没用过，所以不替它说话。

结果：77个部件，轮子是独立的

有个细节值得记：拆完之后右上角的Faces还是18497，一点没变，Vertices却从12522涨到了13801。面数不变是因为没有新增几何，顶点变多是因为切缝处的点被复制成了两份，一份归这块，一份归那块。看到顶点涨了不用慌，那正是拆开了的证据。

Part List每一行右边有个眼睛图标和一个三点菜单，可以逐个隐藏、重命名、合并。Merge是把选中的几块并回一块，用来收拾那些被切得过碎的零件；Save是把拆分结果写回这个资产。

完整操作顺序

拆完之后能干什么

拿到36个带名字的部件，导出的GLB里它们就是36个独立节点，引擎里按名字取就行。轮子能绕自己的轴转，车门能绕铰链开，车顶灯能单独发光。对照E3那个结论，这是同一辆车上两条路的分岔：连通分量给你358个没有意义的碎片，语义分件给你36个有意义的零件。

这条对教学类演示的意义比对游戏更大。一台机械要讲清楚它怎么工作，前提就是能把它拆开；我做四冲程发动机那个demo时，活塞和连杆是分两次单独生成的，因为当时还没有拆件这条路。现在回头看，整机生成一次再语义拆分，比逐件生成再手工装配省事得多，而且零件之间的比例天然是对的（分开生成的零件对不上尺寸，是我在那个项目里踩过的坑）。

贴图生成：同一个几何，换一身衣服

左侧工具栏第六个是贴图生成。它做的事很纯粹：几何一个字不改，只重新算一遍贴图。

选中模型之后，面板长这样：

实测：同几何多贴图，成本是一顿早饭

这个能力我是专门去测的，因为巴黎那条街上7种建筑是循环复用的，每栋出现两次，开着车很容易认出重样。

25积分换一栋看起来完全不同的房子，比重新生成一栋（50分）便宜一半，而且几何是同一份，引擎里还能共享几何省显存。给核心建筑各配一到两张贴图变体，一条街的重样感就没了。

这条为什么对我特别重要，得说说当时的处境。巴黎那条赛道两边的房子是七种建筑循环摆的，代码里就是buildingKeys[i%7]，每栋沿路出现两次，开着车跑一圈很容易认出来。要解决它，笨办法是再生成七栋新的（350积分），聪明办法是给现有的七栋各配一张变体贴图（175积分），而且新旧两版共用同一份顶点数据，显存只多一份贴图。

API层对应的是POST /v3/models/texture，官方文档写得很清楚：固定model_seed、只改texture_seed，就能在同一个几何上批量出贴图变体。想把这件事做成流水线而不是手点，走这条。

价格这块我得把观察如实摊开：2026-09-10那次4K加自定义参考图是25分，无参考图20分；2026-09-11再看，8K档下按钮写的是30分。按钮上的数字是跟着你当前开关实时变的，所以别背价目表，按下去之前看一眼那个数就行。

用什么当风格参考，我的经验是直接给一张同类物体的照片或设计图，效果比写文字描述稳。给建筑换贴图时我用的就是另一栋店面的图，它自带了「这个世界里的材质长什么样」这个信息，比写「深绿色百叶窗，窗台有花箱」精确得多。这和写生图提示词是同一个道理，具体方法在§09。

智能网格出的是灰模，贴图是必经的第二步

走智能网格（P2.0）这条路的话，贴图生成不是可选项。它生成完给你的是一个没有贴图的灰模，底部会弹一句「Retry for better results or proceed to Texture」。

点了Texture之后的中间状态见§01：中央「Generating Texture...」进度条，右侧资产卡片上跑着计时，这一次是135秒。那个数是界面自己的倒计时、含排队，不是算子耗时。

贴图完成的样子见§01：还是09-11那件，5615个四边面、5381个顶点，几何没动，材质上来了。这一步花了30积分，余额从25220掉到25190。

一批13件跑下来，贴图生成这一步长什么样

上面那一件是试水。9月12日我把整批巴黎资产重做了一遍，网格阶段跑了14件，其中13件接着跑了贴图生成，每件30积分，合计390积分。一次跑这么多，才看清这一步的真实形状。

跑完之后我把参数从接口核回来，13件逐项一致：

逐项核一遍这件事值得做。13件里只要有一件的texture_alignment飘了，你拿到的就是一件风格对不上的资产，而这种错在缩略图上看不出来，要等它进了场景、摆在另外12件旁边才会现形。批量跑完不要只看「成功」两个字，把参数拉回来对一遍。

一个会让你对不上账的字段：model_version有两段

这条我卡过一次。同一个项目，网格刚跑完的时候去读详情接口，model_version是Nexus-v2.0-20260801；等贴图生成也跑完再读同一个接口，它变成了v3.5-20260815。

它没有改写历史。详情接口返回的永远是这个项目当前最新的那个算子，而网格和纹理是两个算子，各有各的版本号——你读到哪一个，取决于你什么时候读。

这两步要等多久

耗时这件事界面会自己告诉你，卡片上跑着秒数。我记下来的几个：智能网格那辆出租车的贴图跑了135秒，Assets页上另一个正在生成的模型显示102秒；9月12日那批里铁塔那件的纹理是109秒。

这一节的秒数都是算子耗时（算子耗时口径，不含上传与排队；端到端要往上加，两个口径的实测差见§01，词条见附录D）。排预算按端到端算，比较不同配置的快慢按算子耗时算，两个口径别混。

高精度模型那一侧的生成，表单上直接标着「Expect longer wait times」。这一档我没有逐件采过算子耗时，手上只有端到端的数：小王子那批16件（§08）和名画那两件（§09），都是一件约四分钟，走的都是v3.1加8K贴图。所以全书凡是写「高精度模型一件多久」，读的都是端到端那一头，和上面那几个算子秒数不是一个口径，别拿来互相换算。

这个量级意味着一件事：不要守着页面等。Pro档给的是10个并发任务，把一批要做的东西一次性都提交出去，回头再统一收，比一件一件盯着快得多。Assets页那排筛选标签这时候特别好用，Untextured那一档能一眼挑出还欠一步贴图的。

13件串着提交那一轮我还学到一条：别用「找到写着『纹理生成30』的按钮」这种方式去定位它，按钮上的文字和那个价格数字是两个独立节点，拼不到一起，等它出现会一直等到超时。按位置找那个黄色主按钮就行。同理，一次别塞太多件，我试过一口气提交三件，中途就被超时打断了，两件一批最稳。

拆不好的时候长什么样

拆件不是每次都给你想要的那种分法。09-11那次Balanced档标称的是6到15件，实际出了36件，轮子、车门、车顶这些关键件都对，但也有一批很小的零碎块（保险杠上的几条、车灯周围的边）被单独分了出来。这种时候不用重跑，在Part List里把相邻的几块选中点Merge并回去就行。

重跑的话又是一次40积分，所以档位一开始就选对比事后修划算。我的经验是：想要的部件数落在6到15之间就Balanced，不要因为「多分点总没坏处」去选Detailed，碎片越多要合并的手工活越多，而且从这次的结果看，Balanced本身就可能给到比标称更多的件。

两件事的工序位置

「拆完就能各转各的」这句话，我后来把它验了。把那个77部件的GLB接进一个最小查看器，让四个轮子各绕自己的轴转45度、车身不动：

§06绑骨与动画

Auto-Rigging and Animation

这一节走完，你能拿到一个真会走路的角色：41根关节的骨架、一段2.375秒的行走循环，导出成GLB直接进引擎。中间几个坑我都踩过，位置和判据都写在下面，包括一条能省掉50积分的入口选择。

先看反面：自己动手绑，会绑成什么样

第一版巴黎demo跑起来，街上的人走路是滑的，像脚下踩着冰。那18个行人确实是静态网格在平移，加了点上下起伏假装走路。

我第一反应是在Blender里给它绑。Blender有个ARMATURE_AUTO，塞一副骨架进去，让它自动算权重。蒙皮权重就是「哪根骨头动的时候，这块皮跟着动多少」的那张表，绑骨的一大半功夫都在这上面。

自动权重确实跑完了，也确实生效了，结果是这样：

关节数是关键线索：Blender自动权重只求出了4根关节（root / spine / head / neutral_bone），而这个网格是几百个碎片拼出来的，没有连续的蒙皮拓扑，权重自然求不对，碎片还会在变形时脱离主体。根因和§05那358个碎片是同一个。

几个词

绑骨（rigging）是给一个静态网格装一副骨架，并算清楚每块皮归哪根骨头管。关节就是骨架上的节点，人形骨架一般四十来根。T-Pose是双臂平举成T字的中立站姿，业内把它当默认起始姿势。A-Pose是手臂自然下斜三四十度的站姿，看起来更放松。重定向（retarget）是把一套动作从一副骨架搬到另一副骨架上。

T-Pose和A-Pose的区别在后面会变成一条要紧的判据，先记住它们不是一回事。

我原本以为这条链很长：生成→绑骨→找动作库→重定向→导出。实测下来它短得多，因为Tripo把动作库那一段也包了，不需要重定向。

入口，和那个必须改的下拉

左侧工具栏最后一个是动画，页面标题叫「3D Rigging & Animation」。

先选对入口，这一步就能省50积分

绑骨页的模型从哪来，有两条路，价钱不一样。

2026-09-12那次我绑的行人是前一天在Tripo里生成的，本来就躺在账号里，所以在/workspace/rigging页右侧直接点中它就开工了，既没付那50分，也没遇上下面要讲的那个弹层。这条路我后知后觉，早两天知道能少花一笔。

如果你确实要上传：那个会把模型转歪的弹层

弹层上那句提示是「调整视角至一个具有足够模型特征信息的角度」，看字面像是在说相机。但那三个数动的是模型自身的旋转。我按字面理解去拖画面，数值就被带跑了：

真正的入口条件：四肢和躯干得分得开

我头两次绑骨都失败了。第一次用的是巴黎那批「走路中被拍到」的行人（前倾、侧身），第二次换了个站直的碎花裙角色，站直了但一只手搭在胸前，还是失败。

第三次跑完，产品自己弹了一条提示出来：

看到这条横幅的当天，我给自己记的结论是「前两次不是姿态不够正，是根本不是T-Pose」。两天后这个结论被自己的实测推翻了。

2026-09-12我又做了一个要绑骨的行人，参考图生成的时候模型没听话，给的是A-Pose：手臂朝下斜了三四十度，根本不是横平的T字。我本来打算重生一张严格T-Pose的，请求超时了，就先拿这张凑合着往下走。结果是点一次「自动绑定」，19秒，第一次就成了。

官方那条横幅推荐T-Pose，这个推荐没错，T-Pose是空隙最大的姿势，成功率最稳。但它是「更好」不是「必须」，我把它读成了硬门槛，多花了一轮时间去重生参考图。你手上那张图如果已经是A-Pose，先拿去绑一次试试，比重画一张快。

自动绑定20积分：成没成，看动画卡片上的字

选好模型、选好类人预设，点那个「自动绑定20」。2026-09-10绑那个巴黎行人时，等了一轮之后中央预览是空白的，旁边出现「重试」按钮，第二次重选类人预设再绑才成，那一次实打实多花了20分。当时我写下的结论是「第一次多半会失败，这是产品的固定行为」，这话说满了。

回头把记录对齐，样本其实只有两个，而且指向相反的方向：那个行人是第二次才成；09-12那个A-Pose行人一次就过。两个样本撑不起「固定行为」这四个字。同一天我还误判过一回，那次其实是把「确认导入」当成了绑骨，白等了一轮，并没有真的绑失败。

所以现在的说法是：第一次绑不成是有可能的，遇到了就点「重试」，不必当成坏消息；但它不是必经的一步，预算上留一次重试的余量（多20分）就够了。

判据很清楚：看动画卡片上的字。全是「请先绑定骨骼」就是没绑成；绑成功后它们会变成可点的动画名。

绑一次骨要多久：三个数，三种口径

这件事我得说细一点，因为你拿秒表掐，掐到的数和界面告诉你的数对不上，不是你掐错了。

界面和接口给你的都是算子本身跑了多久（算子耗时口径，不含上传与排队；端到端要往上加，两个口径的实测差见§01，词条见附录D）。写进项目排期的要用端到端那个数，别用接口报的。

动画库有多少个，我数了两遍

2026-09-11第一次数完，我记下的是110个，但没记数法，事后自己都复原不了是怎么点出来的。2026-09-12录屏那天重数了一遍，这次把过程留下了：左侧动画面板从头滚到尾，分8屏截完，逐张卡片数过去，类人骨架下是97个。所以这本书里凡是提到这个量，写的都是「近一百个」。

分五类：All / Basic / Interactive / Scene Specific / Emotional，另有搜索框。里面有walk、run、idle、sit、jump这些基础动作，也有dance_01到dance_06、sing_01到sing_04、greet_01到greet_04这类成组的，还有basketball_shot、surf、jump_rope这种场景动作。完整清单在research/studio-facts里。

这近一百个里，做游戏真正常用的其实就那么几个：idle（站着等）、walk、run、turn、sit、wave_goodbye。情绪那一组（cry、laugh、angry、frightened）在做剧情演示时有用，运动那一组更像是给短视频素材准备的。

它把动作库包进来这件事，省掉的工序比看上去多。正常流程里，你得先找一个动作库（Mixamo之类），下载一个FBX，再做重定向，把那副骨架上的动作映射到你这副骨架上，关节名字对不上还得手工连线。Tripo这边是它绑的骨、它出的动作，两边天生同名同构，重定向那一步整个不存在。我一开始判断「链路长、要重定向」，是错的。

最致命的一步：点动画只是预览

我第一次导出拿到的GLB是「有骨骼、零动画」，查了半天才明白问题出在哪：在动画库里点一下卡片，只是让预览播给你看，不等于把它带进导出文件。

「动画数量」那个数字从0变成1，才算真的带上了。旁边的「原地播放动画」也要理解一下：打开之后，动画只管迈腿，位移交给游戏代码管。做游戏角色这个开关必须开，不然动画自带的位移会和你的移动逻辑打架。

导出来的是两个文件，不是一个

还有一个更隐蔽的：我一度以为「导出把动画丢了」，其实是它被分成了两份。做小王子那个角色时，点导出的同时抓了一下网络请求，在一串studio/progress和project/detail里看见了一个从没出现过的文件名。

这两个体积是文件落盘后数字节数换算的，不是界面上的读数：5,040,200字节和135,540字节，按1 MiB = 1,048,576字节折成4.81 MiB和132 KiB。本节的模型体积一律按MiB写，§22和附录A那张资产表引的是同一批数。

两个文件同源、41个关节同名，用法就是把前者的骨架装进场景、用后者的剪辑驱动，AnimationMixer是按节点名字绑轨道的，对得上。顺带解掉了另一个疑虑：既然动画在独立文件里，网格那个文件的静止姿态就是干净的绑定姿势，之前看着像「停在步态上」是我看错了。

还有一条：tripo_retarget_这个文件没有_meshopt后缀，也就是没压缩，可以离线直接读；带_meshopt的那些用手写解析器读出来是乱码。

第一件P2.0绑骨件

前面讲的三件绑骨资产用的都是高精度模式（v3.1）。2026-09-12我用智能网格（P2.0）也绑了一件，这是这本书里唯一的P2.0绑骨样本，数据单独列一下：

「Cluster」是FBX里存蒙皮权重的那个结构，一根骨头一个，所以41这个数和前面v3.1那副骨架是同一个规模；LimbNode是骨骼节点，82个包含了骨架末端那些不带权重的节点。这些数不是从界面上抄的，是把FBX下下来用strings直接数出来的，凡是能落盘再数一遍的，就别信界面上的数字。

有两件事要提前知道，不然装进项目里会踩：

验一遍再进引擎

拿到GLB先别急着接，写个二十行的页面把它拖进去数一遍。

巴黎那个行人的动画数据拆开是这样：123个通道，其中16个通道带关键帧（真正在动的腿、臂、脊柱，帧数51到57不等），采样间隔0.042秒（约24 fps），时长2.375秒一个完整走路循环；剩下107个是常量通道，对应手指这类保持不动的关节，属于正常结构。面数从头到尾没涨，19830进、19830出。

这里的123和前面那张两文件表里的126不是同一件资产。但别拿123去认角色——123只是41×3这个算式的结果，凡是41关节、只有关节带通道的件都是123（巴黎这个西装行人是，§15那个T-Pose男性也是）。126那件是小王子。两件都是41关节，差的三条来自骨架根节点——通道数是「带通道的节点数×3」（位移／旋转／缩放各一条），巴黎那件只有41根关节带通道（41×3=123），小王子那件连骨架根节点也带上了（42×3=126）。所以看到自己的件数落在这个区间，不用怀疑绑骨出错。

接进引擎的三条硬约束

还有一条让角色看起来不呆的小设置：mixer.timeScale跟着实际移动速度走，走多快推多快。我按每秒2.5米定标，站住的时候把它冻住。不做这件事的话，角色会出现「脚在原地小碎步、人却在飞速平移」那种滑冰感，观众一眼就看出来不对。

朝向要分三类记，别并成一条

「模型进场景之后是背对着你的」这件事我处理过太多次，一开始我以为有一个统一的角度能兜住全部，后来发现朝向惯例是按来路分的，有三套，混着记必然装反。

第三行那两个例外没法靠推理找出来，只能渲图看：一辆车的正面在−X（+X那一面是尾灯和后窗），一件靠墙的书箱正面在−Z（−Z那一面书箱是敞开的，+Z是合上的箱盖）。

量一个绑骨模型的身高，比你想的难

这条我栽得很惨，写出来给你省两轮。我要把小王子和那张1米01的书桌摆在一起，得先知道他多高，于是写了个函数去量包围盒。数收敛了，拟合也漂亮，量出来的结论是1.552米。这个1.552是测量假象，真实渲染出来的人只有0.79米，站在书桌旁边比桌面还矮。

往下看之前先把三个长得很像的数摆清楚，不然后面每一句都容易读岔：

错的不是1.55这个目标值，是量法。底下三处问题叠在一起，每一处单独看都不显眼；三处都修完之后，身高探针一次收敛到1.547米，正好落回目标上：

为什么会连着两次判错：第一版只验证了「数收敛了」，没验证「画面对了」。这类bug可怕在它全链条自证，拟合收敛、代码不报错、模型和骨架都是好的，连「贴地0.064米」这种细节都算得出来。

一个能走的角色，花在哪几笔

以上是截至2026-09的官方标价，以官网为准。按¥0.0467一分算，一个会走路的角色约¥3.27。这70分是我09-10那次逐笔记下来的，那一件没有重试；要是碰上一次重绑，这一件就是90分、约¥4.20。

这套流程后来在巴黎那座城上又跑了一遍，主角换成另一个行人角色（pedestrian-01），绑法完全一样，只是它那次第一遍没绑成，多花了20分。街上18个行人里有6个由那一个绑骨模型实例化出来、真的在走，其余12个是五种不同的静态行人站着（一开始是18个全用它，那其实是个bug，根因见§18），桌面全流程和三种移动端尺寸的回归测试都通过。两个角色是两条线上的两件事，账也分开记，别把它们当成同一个。

还有一条我没测的，得说清楚：近一百个动画里我只实地验过walk这一个，跑步、挥手、舞蹈的质量稳不稳定，我不知道。面部和口型那一层也完全没碰，所以这本书里不会出现关于它的任何结论。

§07怎么把积分花在刀刃上

Spending Credits Where They Count

这一节讲的是配置选择：每个按钮上那个数字是怎么构成的、同一件资产有几种配法、什么时候该配高什么时候该配低。学会读按钮上那个实时变化的数，比背价目表有用得多。

订阅这一层：四档，差别不只是积分数

截至2026-09官方标价，以官网为准。

最后那一行比积分数重要得多。Free档生成的模型是公开的，而且标着非商用；从Pro开始才是私有加商用。你要是打算把做出来的东西放进产品里，这一行就是门槛，不是积分够不够的问题。

免费档能做到哪一步

200积分按基础价15算是13个模型，按界面默认的50算是4个。这个量足够你把整条链走一遍，看看生成质量对不对得上你的需求，但不够做一个项目。

真正卡住你的也不是数量，是另外两条属性：模型归属，和导出。归属那条上面刚说过，导出这条我没能验到底。

这个洞我没补上，但它不挡你做决定，所以先把结论放在这儿。「要不要付钱」这个决定卡在模型归属那一行，不卡在导出这一行。导得出也好、导不出也好，免费档的产出都是公开的、标着非商用。所以免费档只该用来回答一个问题：它生成出来的东西，够不够你用。够用，再考虑从Pro起步；不够用，你连这一步都省了。

至于导出本身，你不用等我，注册完三分钟就能当场问清楚：生成一件，点Export，把你真正要的那个格式（多半是GLB或FBX）点到底，看它让不让你下载。导出不扣积分（本节后面有我拿余额验的那一笔），所以这一步花的是三分钟，不是那200分里的任何一分。要点的是你真正要的那个格式，别只点一个能导的就当过了——别等做完一批资产才发现拿不走。

并发数也是个隐形差别。Free是1个并发，意味着你提交一件就得等一件；Pro是10个。做一批二十几件资产的时候，这个差别比积分数更影响体感。

一积分值多少钱

¥140除以3000，一积分约¥0.0467。这本书里所有的人民币数字都按这个价折算。

这个基准价我复核过，因为它撑着全书所有的¥数字。2026-09-13不带账号、不带登录态重取了一次官网Pricing页，Compare Plans的Price行还是Pro $20 /月、$240 /年，和带着优惠券采集那次一模一样。另一条旁证是三个付费档的CNY对USD比值：140÷20、630÷90、2310÷330全都正好是7.0——优惠券只会打歪其中一格，不会让三格一起保持同一个汇率。采集当天我账号上确实挂着一张首月券，它折到的是卡片顶部那个大号价，没折到对照表，验法写在附录C。

我账号里那两万多的余额不是订阅送的，是另外买的积分包。这个也得说清楚，不然你看到截图里的余额25220，会误以为Pro一个月给这么多。

官方那张表，和界面上量出来的那一套

官网Pricing页的FAQ里有一张积分表，叫「How do Credits work in Tripo AI?」，把每个动作的基础价和可选加项分开列。这是官方唯一一处把这件事说明白的地方，生成按钮上不会告诉你。

官方那张六行的积分表（每个功能的基础分和可选加项）在附录C，截至2026-09的标价，以官网为准。

拿它去对界面上实测到的数字，两项严丝合缝，两项要多看一眼：

拿它去对界面上实测到的数字，两项严丝合缝，两项要多看一眼：

第一行不能靠凑。默认表单里Ultra是关的，所以「15 + 10 + 10 + Ultra 15」这个拆法虽然凑得出50，描述的却不是你打开工作台时看到的那个状态；照着它去界面上找那15，会把本来关着的Ultra打开，一次多花15积分。我在工作台里把开关一个一个关过去量了一遍（过程和截图在§01），量出来的是另一套结构：几何15是底价，贴图是打包卖的，2K加15、4K加25、8K加35，Ultra Mesh Quality单独再加15。

把同一个表单从「只要几何」一路开到「8K＋Ultra」，按钮上的数是15 / 30 / 40 / 50 / 65五档，逐档对照表在附录C。

截至2026-09界面实测，以当天按钮上的数为准。

两套分法的差别很实在，它决定你能动哪一块。界面把Texture Gen和HD Texture打包在一个开关后面，你没法只关其中一项；能动的是贴图档位，从8K拨到2K少20分。而官方表里那个15分的Ultra，在工作台的默认状态下本来就是关着的。

所以那个50不是几何本身的价钱，其中35分买的是8K贴图。这和面数那边是同一件事的两面：默认值替你做了选择。差别在于面数那个默认值（高精度模型那边的面数控制默认20000，而滑块量程是500到200万）恰好落在可用区间，而贴图默认给的是最贵的8K档。知道了这一点，你就有了一个可以调的旋钮。

智能网格那条线实扣多少

这条线我对得最细，因为09-12那天我连着跑了十几笔，每笔都拿余额去核。

截至2026-09界面实测，以当天按钮上的数为准。

怎么验的：那天主批12件网格是12 × 65 = 780，另有一件重做和一件绑骨用的行人，网格共14笔910；加上13笔纹理的13 × 30 = 390，再加一笔绑骨20，合计1320，和当天余额从21540掉到20220这一段一分不差。逐笔对得上，这个65就不是我看花了眼。

官方自己的算法验证了「基础价15」

对完账我心里还是有点不踏实，因为FAQ那张表是我抄下来的，万一抄错了呢。后来发现定价页上有一个可以反推的东西：每一档都写着「N Monthly Credits ≈ M Models」，拿N除以M就行。

四档全部落在15上。官方在算「你的积分能做几个模型」的时候，用的分母就是15，不是50。这是产品自己在页面上确认了基础价。

这条对你的实际意义是：Pro那3000积分不是只够做60个模型，是够做200个。前提得说清楚，官方那个分母15算的是纯几何，不含贴图；真要带贴图，2K档一件30分，3000积分是100件。就算按这个算，也比按默认的50分一件多出一倍。

工作台高精度模型表单的全貌在§01：通用设置下是「几何与贴图」，订阅专享区有「分部件生成（带New角标，默认关）」。

但按钮上的数字才是当场生效的那个

我得把一处对不上的地方摊出来。首页那个快捷生成框里有个二选一，高精度模型和智能网格，选前者时按钮写的是55，不是50。

首页那个快捷入口的样子见§01：拖一张图进来，下面高精度模型/智能网格二选一。选高精度模型时按钮是「Generate 55」，比工作台表单的50多5分——这5分对应哪个开关，我没在界面上核出来。

同一个框切到智能网格（图见§01），按钮变成「Generate 100 0」，走的是智能网格那条线，Preview期间第一次免费。同一张图、同一个框，两个按钮的数差着一倍，差别只在上面那个二选一。

Trial x1：免费那一次之后，落在折后价上

界面上有好几处挂着「Trial x1」或「New Function Trial」的角标，意思是这个功能给你免费试一次。我撞上的有这些：

截至2026-09界面实测，以当天按钮上的数为准。

有一处要说在这儿，免得你翻到§01时犯嘀咕：上表「分部件生成」那一行记的是我2026-09-11在国际站界面上看到的角标；§01那张09-14拍的国区截图上，这一项挂的已经是New，不是Trial x1。是国区和国际站的差别，还是这三天官方改了角标，我没分开验。角标会变、价目表会过期，只有按钮上当场显示的那个数不会——这正是全书反复说「以你按下去之前按钮上那个数为准」的原因。

智能网格的AI Model下拉见§01：P2.0 – Preview带「Trial x1」，另一项是P1.0 – Fast。规划预算时按你实际会付的那个数算，Trial只有一次。

这里有个我早期算错过的地方：我一度以为Trial用完就回到原价100，做批量预算时按100乘件数算，结果多留了一大截。真正扣的是划线后的65，一批12件就差420分。预算宁可按看到的按钮数算，别按记忆里的价目表算。

余额在哪看

Assets页的样子见§03。这里只提一件事：积分余额常驻顶栏右侧，旁边就是Upgrade；下面那排All / Smart Mesh / Untextured / Textured / Rigged筛选，做完一批资产用它来点数最快。

余额的变动可以当账本用。那辆P2.0出租车做完贴图，余额从25220变成25190，正好30分，和按钮上写的对得上。每做一步记一次余额，比事后回忆准得多。完整的一串读数在附录C，四个时间点互相闭合。

按用途选配置：同一件资产有五种配法

讲完构成，说真正要做的决定。一批资产不该一个配置跑到底，该先给每件定个用途，再按用途选档。这是我做完三批资产之后才固定下来的做法。

同一件资产有五种配法，单价从15到65——差的几乎全在贴图档位上：主角走8K（50）、中景4K（40）、远景2K（30）、只要形状就把Texture整个关掉（15）、要干净四边面走智能网格P2.0（65）。五行完整对照表在附录C。

巴黎那批23件我走的是4K那一档，一件40；小王子那16件是默认的8K，一件50。而在画面里，一件只在两百米外出现的建筑，8K和2K我分不出来。

巴黎那批23件我走的是4K那一档，一件40；小王子那16件是默认的8K，一件50。同一个「高精度模型」两个单价，差的全在贴图档位上，而在画面里，一件只在两百米外出现的建筑，8K和2K我分不出来。

这些积分花在哪了

八条线逐笔花在哪，那张流水表在附录C（含每一笔的用途和失败重试）。小计1350积分，约¥63。

要一个最硬的数的话，用这个：从9月11日那个25220的读数，到9月12日收工时的20120，Tripo这边净掉了5100积分，按¥0.0467一分算约¥238。这是余额头尾相减，不靠任何一条记录加总，也是这本书里我最愿意拿出来对外说的一个成本数字。上面那张1350的表发生在25220这个读数之前，属于另一段，两个数不要相加。

这张表里有两个数字值得单独看。一个是小王子那条线的840分，占了六成以上，因为那是唯一一条「按设计图清单批量生成」的线，16张图各生成一次。真正吃积分的从来不是难度，是件数。另一个是星月夜那200分里的50，那是我误判一次生成失败、重复提交造成的，属于纯浪费。

顺着这个往下想，钱该花在哪就清楚了。件数是省不掉的，你要几件就是几件。能动的只有每件的配置档位，和那些白交的重复提交。把远景件的贴图档位拨到2K，单价从50降到30；提交前先看清楚状态，别在任务还在跑的时候以为它失败了。这两件事加起来，同样这些产出大概能落在800分上下。

另一笔账：时间

积分好算，时间容易被忽略。我记下来的几个数：

上表里Tripo侧那几个数是算子耗时（算子耗时口径，不含上传与排队；端到端要往上加，两个口径的实测差见§01，词条见附录D）。排期按端到端算，别按接口报的算。

这张表里有个挺反直觉的东西：最花钱的那几步，你根本不用盯着，提交完就能走开。真正吃你注意力的是后面组装和调试那一大段，而它一分钱不要。所以别一件一件提交，Pro给的10个并发是实打实的产能，一次丢一批出去，回头统一收。

怎么记账

我这一轮之所以能把每笔说清楚，靠的不是事后回忆，是两件很笨的事：每条线在自己的记录文件里留一行「这条花了多少积分、花在哪」，以及关键步骤前后各看一眼顶栏余额。

这两件事的可信度不一样，我是吃了亏才分清的。余额掉了，是扣费真的发生过的正面证据；记录加总只能证明「我记下来的那些确实花了」，证明不了「没记下来的不存在」。所以两边打架的时候以余额为准，然后老老实实把差额写出来。我09-10那一段就是只有加总没有余额，现在回头看，账面上的洞正好都在那一段。

余额差法特别好用，因为它不受界面显示影响。那辆出租车做贴图，余额25220变25190，就是30，跟按钮上写的一致；09-12那12笔网格，780分也是这么逐笔对上的。要是哪次对不上，说明你理解错了某个开关。产品说的价和实际扣的分，得自己对一遍才算数。

还有一处没对上，如实写在这儿：官方表里Segmentation是5、每部件再加5，而Studio的拆件按钮上明晃晃写着40。我只拆过一次（09-11那辆出租车），那天按钮挂着Trial、实扣0，没机会用余额差去验。所以本书凡是提到拆件40，说的都是界面按钮上的数，这一条我还没验完。你自己一次拆件就能验完——两个前提和完整说明在附录C。

还有一条成本线我没走

整本书讲的都是网页订阅这条路。Tripo另有API和CLI，走那条的计费方式、额度形态和网页端不一样，我这一轮没有实测，所以这一节里的任何数字都不要往API上套。那部分在§11，等真正接过一遍再写。

把预算铺开的几条做法

§08为什么先出设计图再建模

Design First, Model Second

这一节讲我那两个世界共用的那条流水线：先让编程Agent画一张设计图，再把图送进Tripo变3D。开篇就是那四条参考图配方（看完视频来找它的，就在下一页），然后是中间这一步为什么不是多余的，以及怎么用Tripo自己起的模型名当一道不花钱的验收。

先把那四条配方给你

视频里我念的那四条要求，就是下面这个框。你现在什么都不用懂，把它照抄进你给出图模型的提示词里，拿回来的3D模型质量会立刻不一样。为什么是这四条、每一条各挡掉了什么，§09一条一条拆。

这四条不是我总结出来的口号，是我真跑过的提示词里逐字写着的。下面这段可以整段复制，粘在你自己那句「画面内容：……」的前面或后面：

单个物体、完整入画、居中放在纯白背景上，四分之三视角，只有极淡的接触阴影、无其他物体、无文字、无人物。

小王子那颗星球上摆着16件Tripo模型，巴黎那座城里摆着23件（两个demo的样子见§00，展开在§22和§18）。

两边都没有一件是我手搓的——我不会写代码，也不会用Blender建模，这本书从头到尾的前提就是这个。也没有一件是从素材站下的，全部是从零生出来的。

两边走的是同一条路：Codex先出一张设计图，Tripo再把设计图变成3D。

文生3D一步到位，坏处是出了事你不知道该改哪头

Tripo的生成表单上有文本页签，你直接打字也能出模型。我一开始也觉得中间那张图是多余的：既然它能听懂「一只坐着的狐狸」，为什么要绕道先画出来？

跑完两批之后我改主意了。三个理由，按我自己认的重要性排。

中间那张图是唯一能让你定位问题的东西。文生3D是一次生成，出来不对，你分不清是自己的描述没说清楚，还是它的形体重建没做好。插一张设计图之后这两件事就分开了：图不对，改文字；图对了而模型不对，那就是重建这一步的事，跟你怎么写没关系。批量做的时候这一条特别值钱：16件资产里有一件翻车，你得在两分钟内知道往哪修。

改图便宜，改模型贵。设计图走的是编程Agent的订阅额度，重出一张不额外花钱；Tripo的v3.1高精度生成一次50积分。我在小王子那批上重出过两张设计图（§09里的「短茎大花头」那两张），一分钱没多花。同样的犹豫如果发生在文生3D上，就是100积分。

一批资产的风格统一，只能在2D那一层控制。3D模型的「风格」其实是几何概括程度加贴图质感，你在Tripo的表单上没有旋钮能调它。但设计图那一层有。把同一段风格描述原样复制到每一条任务里，出来的16张图就是同一套语言，Tripo照着重建，16个模型也就是同一套语言。巴黎那批23件能摆进同一条街不打架，靠的就是这个。这一条在§09里有完整写法。

这条流水线长什么样

22、16、19、17这四个数不一样，先把口径接上，不然你数自己手上的文件会数不对。

输入那22张PNG里，真正送进Tripo的只有16张。另外6张分别是：玫瑰和猴面包树苗各一张备用重做图（原版重建得就对，没送）、老式飞机的设计图（图出了，但这一件始终没送生成）、小王子的一张重编码副本，以及星球表面的两张等距圆柱贴图——那两张是贴到代码生成的球体上去的，本来就不走建模这条路。

产出那19个GLB＝16件成品＋小王子绑骨链路上多出来的3个文件。那3个是：带骨架的prince-rig.glb、带preset:biped:walk行走动画的prince-anim.glb，以及和它同内容的一份副本prince-walk.glb。

最后进引擎的17个＝15件静态资产＋绑骨版小王子＋那个动画文件。没绑骨的原始prince.glb和那份重复的副本没上场，留在产出/里。

时间成本比我想的短。小王子那批第一组9张设计图，从21:57跑到22:07，串行，十分钟全部出货（文件时间戳可查，平均一张一分多钟）。Tripo那边单件生成实测各约4分钟。

也就是说，一个下午做16件资产是真的，不是宣传口径。真正吃时间的是决定要哪16件，以及生完之后把它们摆进世界，后面§16到§19全在讲这个。

这一步Tripo站内就有，不一定非要在站外做

我自己两批都是在站外跑的，因为我要的是一个能写进JSONL、一条命令跑16张的批处理入口，而不是在网页上一张一张点。但如果你只做三五件，站内这条路更短：出图和生成3D在同一个工作台里，图出来直接送进Model，中间不落地。

那几个模板的名字我盯着看了一会儿：T Pose、Asset Extraction、3D Print-Ready。给3D用的图是一个独立品类，产品自己也这么认。上一段我论证的那些减法，就是这几个模板替你按下去的开关。§09讲的是怎么用文字把同样的开关按得更准、更可复制。

小王子那批：16张图进去，16个模型出来

这16张图送进Tripo，选v3.1高精度，一件50积分，16件全部一次通过，没有一件重跑。

这句话我不是凭印象说的，它有两道互相独立的证据。第一道在Tripo那边：16个任务详情页逐个看过，形体全对，没有一件需要换图重来（下一小节讲怎么用它自动起的名字十秒钟看完一件）。第二道在引擎这边：小王子那个demo每次改完我都跑一遍自检，脚本逐件确认GLB有没有真的加载进场景，最后一轮的结论原样写在项目的成果总览里——「资产到位16/16，零报错」。

两道证据查的不是同一件事。Tripo那边证明的是「生成对了」，引擎这边证明的是「16件一件不落地进了世界」。这两件事我都栽过，所以现在都查。

钱也对得上：16次生成×50，加两次自动绑骨20，这条线一共840积分，逐笔在附录C里。绑骨那20分之所以扣了两次，是因为那一次第一次没绑成、重试了一遍。这不是每次都要付的固定开销——09-12那件A-Pose行人一次就过，两个样本方向正好相反，别照着「每件40分」排预算（§06）。那次重试花在绑骨上，不在16次生成里，上面那句「16件一次通过」说的是生成这一步。16件资产、一个下午、八百多积分，这是「先出设计图」这条路完整跑通一次的真实价码。

读Tripo自动起的名字，是最便宜的一道验收

模型生成完，Tripo会给它起一个英文名。关键在于：那个名字不是从你的提示词里抄的，是它照着自己重建出来的形体写的。所以它等于模型自己填了一张验收单交给你。

看水井那一条：木架、绳子、木桶、手摇绞盘，四样东西一样不少，而我在提示词里写的正是这四样。不用下载GLB、不用开渲染器、不用等模型加载，扫一眼名字就知道它理解成了什么。

16个名字全中。这道验收就发生在任务详情页上，不花钱，也不用等。

所以正确用法是两段：名字不对，一定有问题，直接重来；名字对了，再去看Tripo自己的预览。

补一条09-12才发现的：这个名字每次都会重写一遍

上面那张表是2026-09-10做小王子那批时记的。两天后我拿巴黎那批设计图重跑了一遍智能网格，才发现一件当时没注意的事：这句英文描述是Tripo每次生成现写的，不是存在某个地方复用的。同一张输入图跑两次，它会给你两句不一样的话。

最干净的证据是凯旋门。同一张building-06-arc.png，我因为面数参数没设对重跑了一次，两次拿回来的名字是：

一次认出了这是凯旋门，一次只说「一座大拱门」。两次都对，措辞不一样。所以这个名字能用来判断「它理解成了什么」，不能用来当资产的身份标识。

还有一处更容易吃亏的。我那两棵树，提示词写的都是巴黎街头的梧桐，一棵绿冠一棵秋黄。拿回来的名字是：绿冠那件叫maple tree（枫），秋黄那件叫oak tree（橡）。两个名字里都没有「绿」和「秋」，而枫在大多数人脑子里恰恰是「秋天那棵」。三个月后你按名字去认这两个文件，十有八九会装反。

避开的办法就一个，也很便宜：对号入座只认你自己那条提示词和渲图，不认这个名字。我后来给38件重新对号时定的规矩是：文件名由我起（tree-01-plane-green、tree-02-plane-autumn），Tripo起的那句话只当参考写进表格的备注列。§10讲命名的时候会把这条规矩展开。

顺带说，这件事正好从反面说明了「先出设计图」为什么值：你手上那张图是这条流水线里唯一稳定不变的东西。Tripo的措辞每次会飘，模型的面数每次会差一点，只有那张PNG和那行提示词，三个月后打开还是原样。所以我的项目目录里永远是「设计图和jobs.jsonl跟GLB放在一起」，丢了模型能重生，丢了图就真丢了。

巴黎那批：23件走同一套流程，留了设计图的19件全部一次通过

开发笔记里我当时写的原话是：

这里要把话说准，免得你以为只有19件进了游戏。23是最终发布包里点得到的Tripo模型总数，§16和§19用的都是这个数。19是其中留了设计图和提示词、你照着能复现的那一批，附录A的A组B组给的就是这19件。差的4件（雪铁龙2CV、埃菲尔铁塔、奥斯曼公寓、街角咖啡馆）是我直接在网页里点出来的，当时没留输入图。所以那句「19/19一次通过」说的是有据可查的那19件。

什么时候可以跳过设计图

输入本来就是一张真图的时候。

名画那两件（星月夜里的柏树、千里江山图的一段山）是从3840 px原作上手工抠下来的；发动机的活塞和连杆是零件照片裁的。这些都没有设计图这一步，直接送进Tripo。判据很简单：你要的东西世界上已经有一张正面清楚的图，就别再让AI重画一遍。重画只会让它离你想要的更远，而且多花一次生成的时间。

反过来，只要这个东西是你脑子里的、现实中没有现成正面图的，设计图这一步就省不掉。小王子星球上那16件全属于后者，所以16件全都先画了一遍。

下一节把这条流水线上最需要手艺的那一半拆开讲：那张设计图的提示词到底怎么写。

§09提示词技巧示例（含图）

Prompt Recipes for Image-to-3D

十八条从真实项目里逐字抄出来的写法，每条尽量配「提示词原文+设计图+ Tripo结果」三联。素材是我这两周真跑过的95条提示词，一条没编。包括两个翻车的：柏树被理解成岩石尖塔，活塞被理解成一枚硬币。它们留在这儿是因为两个坑都有明确的避法。

先说一句总的判断：给Tripo用的图写提示词，和给人看的图写提示词，是两件事。

给人看的图要好看，光影、景深、氛围都是加分项。给Tripo看的图要好读——它要从一张2D图里猜出背面长什么样，任何会干扰它读形体的东西都是减分项：投影、渐变、高光、背景、被裁掉的一半、贴在身上分不开的手臂。

所以下面这十八条，大半是在做减法。

01 ·四条配方：一个物体、白底、四分之三视角、整个东西都在画面里

这四条是所有例子的公共前缀，一条都不能少。如果这一节你只抄一样东西，抄它。

单个物体、完整入画、居中放在纯白背景上，四分之三视角，只有极淡的接触阴影、无其他物体、无文字、无人物。

这是游乐园那批8条提示词共用的那半句，一字不差。同一套要求在小王子那批写成「纯浅米灰背景，无地面投影、无文字、无水印，单个主体居中完整入画，略高于平视的3/4视角」，在巴黎那批写成「纯浅灰色背景无阴影无文字水印，3/4等距透视单个主体居中构图」。三批的说法不同，四项要求是同一套。

四条各自在挡一件具体的事，挡的都不是同一件：

下面这条是小王子那批的完整写法，可以看到公共前缀和「画面内容」是怎么拼的：

风格：安托万·德·圣埃克苏佩里《小王子》插图的语言——深色钢笔线条勾出干净轮廓，内部平涂低饱和水彩色块，暖米白纸面质感，形体概括、块面分明，没有复杂纹理、没有高光渐变，适合 image-to-3D 重建。纯浅米灰背景，无地面投影、无文字、无水印，单个主体居中完整入画，略高于平视的 3/4 视角。画面内容：一只安静坐着的狐狸，橘棕色皮毛，白色的下巴和肚皮，两只尖耳朵，深色的四只爪子，一条粗大的尾巴盘在身体侧面。

我在小王子这批用的是浅米灰不是纯白，因为纯白容易和物体上的高光区混在一起。但要点是「纯色、无渐变、和主体不同色」，不是某个具体颜色。拿不准就照第一段那句原文写纯白，那是最稳的。

02 ·风格段落原样复制到每一行，一个字都别改

上面那段提示词里，从「风格：」到「3/4视角。」是完全固定的，16条任务一字不差，只有「画面内容：」后面那句在变。巴黎那批也一样：

风格：低多边形写实卡通风游戏资产原画，奥斯曼巴黎复古配色（奶油色石材/藏青灰蓝屋顶/黑色锻铁/黄铜细节），暖调柔和摄影棚布光，纯浅灰色背景无阴影无文字水印，3/4等距透视单个主体居中构图，细节清晰适合image-to-3D重建。画面内容：一间巴黎街角面包店建筑门面，红色帆布雨棚，金色手写体招牌字体位置留白，橱窗摆放法棍面包造型剪影，深木色门框。

我在巴黎的开发笔记里把这一条写成了可复用的结论：

打架是很具体的一件事：一栋楼是柔和布光的，隔壁那栋是硬光带投影的，摆在同一条街上，你说不清哪里不对，但就是假。风格统一不是审美追求，是这批资产能不能摆在一起的前提。

要换词头的只有一处，就是「资产原画/角色原画/载具原画/植被资产原画」这几个字。它们决定了出图模型把这次任务归到哪一类，换掉之后人物的比例和载具的透视会明显更对。除了这几个字，风格段落里剩下的每一个逗号都别动。

03 ·用真实参考名替代形容词，这是整节最划算的一招

如果说第02条决定一批资产协不协调，这一条决定单件像不像。

它的提示词里有两个真实车型名：

风格：低多边形卡通游戏载具原画，与经典雪铁龙2CV同一美术风格，暖调柔和摄影棚布光，纯浅灰色背景无阴影无文字水印，3/4等距透视单体居中构图，细节清晰适合image-to-3D重建。画面内容：一辆巴黎复古出租车，雷诺4CV造型，黑色车身搭配奶油黄车顶，车顶装有TAXI字样灯箱位置留白。

「雷诺4CV造型」定的是形体，「与经典雪铁龙2CV同一美术风格」定的是美术语言。这两个词组合起来，比你写十个形容词都准。因为形容词要经过模型的一次翻译，专名不用，它直接指向一个世界上存在的、有确定外形的东西。

「复古」这个词模型能给你1920年代，也能给你1970年代；「雷诺4CV」只有一个答案。我在巴黎那批里到处用这一招：报刊亭写「Kiosque à journaux」，地铁口写「Guimard风格」，喷泉写「Fontaine Wallace」，广告柱写「Colonne Morris」，咖啡椅写「Maison Drucker」，绑骨姿势写「参考Mixamo角色T-Pose」。

用法上有个分寸。专名负责「是什么」，几何描述负责「怎么建」，两个都要写。只写「Kiosque à journaux」，出图模型可能给你一个正面平视的写实照片；只写「八边形深绿铸铁亭子」，出来的东西谁也认不出是巴黎的。

04 ·一个准确的术语，能打包掉一整段解释

上一条是拿专名指物，这一条是拿术语指做法。

小王子那颗星球的表面不是建模出来的，是一张糊上去的贴图。这类需求最难说清楚的是「展开方式」，而它有一个精确的词：

……画面内容：一张星球表面的地图，采用等距圆柱投影（赤道横贯正中，上下两极的区域自然收拢淡出），左右两个边缘可以无缝拼接成一圈。

「等距圆柱投影」是世界地图最常见的那种展开方式。写这六个字，比写十句「要能包住一个球、左右要接得上、两极要收进去」都管用，而且一次到位。

同一类的还有：「T-Pose」「低多边形」「PBR」「孟莎屋顶」「掌状复叶」「等距透视」。形容词打不了这个包，术语可以。写提示词的时候我会专门停一下问自己：我正在描述的这件事，有没有一个行业里的固定叫法？有就用它，那一句能省掉三行。

05 ·角色要绑骨，参考图得按绑骨的规矩来

绑骨（给模型装上一副可以驱动的骨架，之后才能播走路、挥手这类动画）对参考图的要求比静态资产严得多。我头两次都没成，第三次Tripo自己把答案弹在了页面上。

T-Pose就是双臂水平张开站成一个「大」字的姿势，是骨骼动画行业的通用起手式。我前两次没成的原因，不是姿态不够正，是根本就不是T-Pose：第一次用的是走路中被拍到的前倾侧身行人，第二次用的是站直但手臂弯着的女士。

小王子本人是主角，要走路，所以他那一张的提示词是全批里最长最啰嗦的一条，啰嗦的地方全在四肢的分离度上：

……画面里没有复杂纹理、没有高光渐变、没有细长垂挂物，适合 image-to-3D 重建与自动骨骼绑定。纯浅米灰背景，无地面投影、无文字、无水印，单个主体居中完整入画，正视角，全身都要在画面里。画面内容：一个全身站立的小男孩，头顶是蓬松的金色短发，脸上只有两个小小的墨点当眼睛；穿一件及膝的深蓝色长外套，外套下摆不超过膝盖，里面是浅米色衬衫；脖子周围围着一圈红色短围巾，围巾就搭在脖子上、不要长出飘带；两条手臂自然下垂但向外张开约三十度，手臂与躯干之间留出清楚的空隙，不贴住身体；两条腿分开站立、间距明显，两腿之间和腿与外套之间都能看出分开；脚上是两只小小的深色鞋子。整体比例略偏卡通，头稍大；关键是四肢轮廓要清楚可分离。

为什么要写「围巾就搭在脖子上、不要长出飘带」？因为飘带是细长垂挂物，绑骨算法会犹豫它属于身体还是属于手臂。绑骨用的参考图，画的不是好看的角色，是一副容易被切开的轮廓。

还有一件事值得单说，因为它把我自己原来的判断修正了一半。真正承重的不是「严格水平的T-Pose」，是「四肢和躯干分得开」。2026-09-12我又做了一个会走路的行人，那张参考图上手臂是向下斜着张开三四十度的A-Pose，不是水平的T，自动绑定19秒，第一次就成。那件的细节在§06。

所以参考图的硬要求，我最后收成四条：全身入画、正视角、手臂向外张开与躯干留出清楚空隙、两腿分开站稳。手臂是水平还是下斜三十度，没那么要紧。

补一句：Tripo站内的Image工具里直接有一个叫T Pose的模板（那张面板截图在§08）。我是先踩了两次坑才反推出这条规矩，后来才看见它就摆在那儿。你要是只做一两个角色，从那个模板起步比自己写这段提示词省事得多；要批量做、要每次都一样，还是得把上面这段写死。

06 ·比例不写进提示词，就等于交给了裁图

这是我踩得最疼、也最容易被忽略的一条。

结果Tripo老老实实按它看到的比例重建：一个扁扁的圆盘。做四冲程发动机demo时我在笔记里写的是：直接用会像一枚硬币。

这一件我想说清楚是谁的问题：不是重建不准，恰恰是太准了。我给它的图里那个活塞就是扁的，它照着做了。配方第四条「整个东西都在画面里」，说的就是这件事：被裁掉的部分，它不会替你脑补。

怎么避开，两条路，我两条都用了：

教训不是别裁图，是你没在提示词里说的比例，模型就从图里量。所以巴黎那批树的提示词长这样：

风格：低多边形写实卡通风游戏植被资产原画，奥斯曼巴黎复古配色，暖调柔和摄影棚布光，纯浅灰色背景无阴影无文字水印，3/4视角单棵树完整居中构图，树干与树冠比例正确，细节清晰适合image-to-3D重建。画面内容：一棵巴黎街头梧桐树，高大笔挺的浅灰色斑驳树干，茂密宽大的掌状绿色树冠，树冠饱满有层次。

07 ·数量和姿态要数出来，别写「一群」

……画面内容：一小群巴黎街头鸽子，五只灰蓝色鸽子聚在一处，其中两只展翅姿态、三只站立啄食，造型低多边形简化但可辨识。

「一群鸽子」这种写法，模型可能给你三只，也可能给你三十只，而三十只的重建结果是一团糊在一起的灰块。多物体本来就是image-to-3D的难区（第01条那句「单个主体居中完整入画」就是为这个写的），真要做一组，就把数量和姿态数清楚，让它保持稀疏、每只都能看出轮廓。

08 ·真要两个东西同框，就让它们「紧凑成组」

第01条说「一个物体」，但现实里总有那么几件东西拆开就没意义了：人和他骑的车、桌子和配套的椅子、牵狗的人和那只狗。

句式上的差别很小，效果差别很大。「A和B」会让它构图成两件东西，「骑着B的A」只有一个主体。巴黎那批的露天桌椅组用的是同一招，提示词末尾还补了一句兜底：

……画面内容：一组巴黎咖啡馆露天桌椅，一张圆形白色大理石桌面配黄铜包边与铸铁桌腿，两把 Maison Drucker 红白藤编扶手椅一左一右，桌旁立着一台圆柱形不锈钢燃气取暖伞，顶部有反射罩，三件物体紧凑成组不分散。

「三件物体紧凑成组不分散」这一句是我后来加的。它把「多主体」重新定义成了「一个组」，重建出来是一坨连在一起的东西，而不是三件互相飘着的碎片。

什么时候可以破第01条，判据只有一个：这两样东西在你的游戏里会不会分开动。会分开动（车轮要转、门要开）就必须拆，那是§05拆件那一节的事；永远黏在一起（骑车的人、成套的桌椅）就合成一件生成，省一次钱也省一次装配。

09 ·做零件，不是做整台机器

这条是我做游乐园那批时想明白的，后来成了我决定「哪些东西给Tripo做」的主要判据之一。

为什么这么分：圆的、重复的、要动的那部分，代码算得又准又便宜；有造型、有材质、观众会凑近看的那部分，生成模型做得比代码好太多。一座摩天轮的轮圈是一个正多边形加辐条，写代码十分钟，精确到小数点；让AI生成一个几十米高的轮圈，它给你的每根辐条粗细都不一样，还没法转。

游乐园那6件全是按这个思路拆的：旋转木马（做一整座，因为它的顶棚雕花才是看点）、摩天轮吊舱、飞椅的一把吊椅、旋转茶杯的一只杯、鬼屋、海盗船船体。三件是「机器上取下来的那个零件」，不是机器本身。

10 ·建筑别写「一个物体」，写「单栋建筑」

主体是一栋楼的时候，「单个物体」这四个字会让出图模型犯难：楼本来就是由很多东西组成的。所以游乐园那批的鬼屋和售票亭，第一条被改写了：

皮克斯动画电影的场景设定图：一座游乐园鬼屋小楼，紫灰色木板墙、墨绿尖顶、歪斜的窗框和歪掉的烟囱、门口有南瓜灯。单栋建筑、完整入画、居中放在纯白背景上，四分之三视角，只有极淡的接触阴影、无其他物体、无文字、无人物。均匀柔和的摄影棚布光，颜色鲜明干净。

「单栋建筑」和「单个建筑」这两种写法我都用过，出来都对。关键是把量词换成主体本身的量词：一栋楼、一棵树、一位角色、一辆车、一组桌椅。巴黎那批的树写的是「单棵树完整居中构图」，人物写的是「单个角色居中构图」，都是同一个动作。

还有一句是专门给建筑和地标加的，在巴黎第三批那32条里出现了25次（剩下7条是人物，它们换成了「全身从头顶到鞋底完整入画不裁切」，意思一样）：

……3/4 视角，单个主体居中，完整入画不裁切不被边框切断，细节锐利，适合 image-to-3D 重建。

「不裁切不被边框切断」是「完整入画」的加强版。建筑和铁塔这类又高又瘦的东西，出图模型特别爱把顶部切掉一点点，它觉得那样构图好看。一句「不被边框切断」，比把画幅改成竖版还管用。（铁塔那件我两样都做了：画幅1024×1536，提示词写「整塔顶天立地全身入画」。）

11 ·品牌字样让它留白，别让它写字

巴黎那批里有三处需要文字的地方，我全部写成了「位置留白」：面包店的「金色手写体招牌字体位置留白」、地铁口的「黄色Metropolitain字样招牌位置留白」、出租车的「车顶装有TAXI字样灯箱位置留白」（那条提示词在第03条）。

模型其实写得出那几个字，问题在后面：写上去的字会被烘进贴图，之后改不掉。留白留出来的是一块干净的牌子，进引擎之后想贴什么贴什么，还能做多语言。这一条对做游戏比对做单件模型重要得多。

12 ·「无文字」是倾向不是保证，重要的位置得正面写

上一条说的是主动留白，这一条说的是被动禁止不一定拦得住。

这件事的性质要说准：「无文字水印」这类否定句约束的是背景和水印，不是画面主体自己的招牌。模型的理解没错，是我那句话没覆盖到那个位置。它也不影响用：这件资产我照常装进了城里，那行糊字在街对面根本看不出来。

所以避法是正面写，不是把否定句写得更重：

13 ·贴图类资产要告诉它「这是贴图，不是画」

星球表面不是一个模型，是一张要糊到球上的图。这类需求得把用途直接写进提示词，而且要把「画」的本能全部禁掉：

……画面内容：一张星球表面的地图，采用等距圆柱投影（赤道横贯正中，上下两极的区域自然收拢淡出），左右两个边缘可以无缝拼接成一圈。地表由暖赭石与沙色的缓坡丘陵构成，点缀几片鼠尾草绿的小草坡和两三处淡玫瑰色的裸岩，偶尔有几道极细的钢笔线条暗示等高线。这是一张贴到球面上的贴图，不是一张画：整体必须平整、光照均匀、没有强光、没有投影、没有明暗渐变，颜色过渡柔和。画面里不要有天空、云、水、人物、建筑、文字、水印、边框、坐标网格。

「这是一张贴到球面上的贴图，不是一张画」这半句，是整条提示词里最值钱的。把下游用途直接写出来，模型会自己收敛掉一堆你还没想到要禁的东西：戏剧光、暗角、笔触的立体感，全都跟着没了。这个招数在第16条还会再出现一次。

14 ·另一个翻车：梵高的柏树，被理解成了岩石尖塔

这一件没有提示词，输入是从《星月夜》3840 px原图上手工抠出来的柏树，去背景，白底1024×1024。起因是2026-09-10看到@HoodyLiu那条把星月夜做成可拆分3D油画的推文（https://x.com/HoodyLiu/status/2097536045881704688），想验证Tripo能不能把其中一层做成真的立体。

两件事同时成立。好消息：风格保真度不是问题。油画笔触和颜色被原样烘进贴图，凑近看，梵高那种一道一道的笔触全在，侧视也能确认它是有真实体积的，不是一张竖着的纸。

另一半：形体语义漂移了。那些火焰般向上卷的枝叶被整体理解成了一块岩石尖塔。原因不神秘，§02那条翻车已经拆过：这张输入图本身就不写实，它是一幅后印象派油画的局部，轮廓由笔触构成，没有一条边是硬边。

所以这一条不该记成「它做不了艺术品」，该记成一条可以提前判断的规律：

怎么避开，两条：一，把这类输入当成「拿贴图」而不是「拿形体」用，我最后就是这么处理星月夜那个demo的，柏树的形体在引擎里重做，Tripo那件只贡献表面；二，如果非要它的形体，先自己画一张写实的设计图，再让它建：绕回§08那条流水线，中间那张图就是干这个用的。

还有一点值得记：它漂移得很诚实。名字直接告诉了你它当成石头了，你第一时间就能发现，而不是等摆进场景才懵。§08那条「读名字当验收」说的就是这个。

15 ·二次修正的写法，以及一次没必要的返工

第一批跑完，我担心两件东西：玫瑰那根细长花茎、树苗那根细细的芽茎。细长结构在image-to-3D里会不会断掉？我当时认定会，于是立刻写了一个jobs-retry.jsonl，把这两件重画成「粗壮版」。

……形体概括、块面分明，画面里没有任何细长结构、没有复杂纹理、没有高光渐变，适合 image-to-3D 重建。……画面内容：一朵盛开的玫瑰，花头又大又饱满、占满整个主体，花瓣厚实、层层叠叠向外张开；花头正下方只有一小截粗壮的绿色花萼，不画长花茎、不画叶子。

……画面内容：一株猴面包树幼苗，短短的一截粗茎，顶端三片又大又厚、圆钝的叶子向外张开，叶片宽大饱满，整体像一个矮胖的三叶小盆栽。

这两张图最后一张都没送进Tripo。因为原版重建得就是对的。那朵带细长花茎的玫瑰，面19612的模型上，花头、花萼、花茎、叶片一样不缺（§08那张预览图就是它）。

所以我在经验库里写下的那条「细长结构是image-to-3D的弱项」，没有证据，已经撤回。这两张图我还是留在这里，因为这两条提示词本身是对的写法：把「短茎大花头」「短粗」这种比例意图写死，把「不画长花茎、不画叶子」这种减法写死，真遇到细长件翻车的时候，这就是修法。只是这次它没派上用场。

16 ·把「适合image-to-3D重建」这句话本身写进去

两批提示词的风格段落末尾都挂着这么一句：小王子那批是「适合image-to-3D重建」，巴黎那批是「细节清晰适合image-to-3D重建」，小王子本人那张是「适合image-to-3D重建与自动骨骼绑定」。

这句话不是写给人看的注释。它告诉出图模型「这张图的下游是什么」，模型会因此自己收敛掉一堆不该有的东西：戏剧光、浅景深、局部虚化、艺术性的裁切。这是整段提示词里最划算的一句，因为它替你挡掉的是你还没想到要挡的东西。

17 ·「低多边形」是产量词，「水彩插画」是气质词，两个都要给

对照两批的风格前缀就能看出差别。巴黎那批第一个词是「低多边形写实卡通风游戏资产原画」。低多边形（low poly，用尽量少的面构成形体的游戏美术风格）说的是几何复杂度，它让23件资产的面数和细节密度落在同一个量级上，摆进同一条街才协调。

小王子那批第一句是「深色钢笔线条勾出干净轮廓，内部平涂低饱和水彩色块」，说的是气质。但请注意它紧接着还写了「形体概括、块面分明」，这半句干的是和「低多边形」同一件事。

一段好的风格前缀，气质和几何复杂度这两件事要分别说清楚，缺哪个都会出问题：只说气质，16件的精细程度会飘；只说低多边形，出来是一批没有性格的灰积木。

18 ·拒绝清单比形容词管用

把上面十八条里所有的「不」拉出来看，是一张很长的单子：无地面投影、无文字、无水印、没有复杂纹理、没有高光渐变、没有细长垂挂物、不要长出飘带、不画长花茎、不画叶子、不要有天空云水人物建筑文字水印边框坐标网格、无阴影、不裁切不被边框切断、不写任何编号与徽章标识。

我的经验是，写3D参考图的提示词，拒绝清单的长度大概能占到三分之一，而且它比正面形容词稳定得多。「干净」「简洁」「适合建模」这类词每个模型的理解都不一样；「无地面投影」只有一种理解。

唯一要记住的边界是第12条说的那件事：拒绝清单管得住背景和氛围，管不住主体自身该有什么。主体上的东西要正面点名。

把这十八条收成一张单子

写完自己的提示词，对着这张单子过一遍，能过就发：

下一节讲怎么把这十八条批量跑起来：jobs.jsonl怎么写、为什么绝对不能并发、网页端一次提交几件才不会超时、以及那个绿色的勾为什么有时候是骗你的。

§10批量出图与命名

Batch Generation, Naming, Retries

把上一节那十八条变成一个能跑的批次：jobs.jsonl怎么写、为什么必须串行、命名怎么定才能一路对到GLB、重试放哪、验收该看哪块屏幕。后半节是2026-09-12那次网页端批量重做的实战记录：一批塞几件不会超时、页面退化了怎么自己修回来、十几个文件怎么下载。附一个必须知道的坑：脚本打的那个绿勾会骗人。

一行一个任务，四个字段

批量出设计图用的是gen_via_codex.py，任务写在一个JSONL文件里（每行一个独立的JSON对象，不是一个大数组）。一行长这样，这是巴黎那批的第一条，原样抄自tripo-source/jobs.jsonl：

{"prompt": "风格：低多边形写实卡通风游戏资产原画……画面内容：一栋巴黎奥斯曼风格转角公寓建筑，弧形立面转角，浅灰色石材外墙，底层拱形商铺橱窗，上层带铸铁阳台栏杆，顶部灰蓝色锌板孟莎屋顶。", "out": "building-01-corner.png", "size": "1024x1024", "quality": "high"}

四个字段：prompt是上一节写好的那段，out是输出路径，size是尺寸，quality固定high（中低档会丢细节，而细节正是Tripo用来判断形体的东西）。

跑起来一条命令：

python3 gen_via_codex.py --batch jobs.jsonl

它走的是编程Agent的订阅额度，不需要API key，跑一批不额外花钱。失败的任务打到错误输出但不中断其余，所以一批里坏一条不会毁掉整批。

绝对不要加--concurrency

这个脚本默认并发是1，也就是串行，一张跑完再跑下一张。不要手贱去调高它。

原因是兜底逻辑：Agent不一定会把图写到你指定的out，脚本的兜底做法是给共享的生成目录拍个快照，跑完求差集，取最新那张搬过去。一并发，多个任务的产物混在同一个差集里互相抢——2026-06-18我实测过，背靠背跑两张，输出的两个文件md5完全相同。

串行的代价其实不大。小王子第一组9张，21:57开跑，22:07收工，十分钟。巴黎两批31张设计图，也是一个下午就跑完了。真正的时间花在挑哪些资产要做上面，不在等图。

验真看三个正面证据，任何一条为假就是假图：

这一条我放在这么靠前的位置，是因为它的危害有滞后性：假图长得也像回事，你把它送进Tripo、花掉50积分、拿回一个奇怪的模型，然后开始怀疑Tripo。批量跑完先抽验两张，再往下游送。

命名：设计图叫什么，GLB就叫什么

规则只有一条：同名，只换扩展名。听起来是废话，但它换来的东西很实在：代码里写一句assets/${id}.glb就能装配整座城；漏了哪一件，两边目录ls一对就知道；三个月后回头看，你还能从模型名反查出它是哪条提示词生的。

小王子那批我用的是另一套：设计图叫01-玫瑰.png（两位序号加中文名），模型叫rose.glb（英文短名，因为它要进JavaScript代码）。这套是妥协过的，不如巴黎那套好用，每次都要在脑子里做一次中英对照。要是重来一次，我会全用巴黎那套。

重试写进一个新文件，不要改原文件

小王子那批一共有五个任务文件：jobs.jsonl（第一组9件）、jobs-retry.jsonl（两件重做）、jobs-prince.jsonl（主角）、jobs-planet.jsonl（两张星球贴图）、jobs-props.jsonl（七件道具）。

拆成五个文件有两个好处。一是每个文件都是一份可复现的记录：三个月后我还能一行一行读出当时想要什么；要是在原文件上改，历史就没了。二是重试的成本变得很低：只改那一条、跑一个两行的文件，不用担心误触发另外14条重跑（重跑设计图不花钱，但会白等十分钟）。

重试文件用b后缀，不用-v2、不用日期。理由是它和原版在同一个目录里按文件名排序时会紧挨着，01、01b、02、02b，一眼能看出哪几件返过工。

送进Tripo这一段是纯机械活，只有一件事要盯

首页生成表单的样子见§01。设计图拖进去，模式选高精度模型，点生成；按钮上那个积分数会随加项开关变。

我在浏览器自动化的笔记里给这一段下过一句评语：批量生成本身是机械活，设计图（Agent出）→ 上传 → 选v3.1高精度 → 提交 → 轮询积分对账 → 拿接口取GLB。7个连着跑没有额外的坑。

要盯的只有积分余额，它是唯一可信的提交成功信号。

做星月夜那次我在这儿栽过：点完生成，积分没立刻变、页面也没跳转，我判定失败又点了一次，结果两条任务同时在跑，白花50积分。那一轮总共−200积分跑了5次生成，多出来的那50就是这么来的。

09-12那批：网页端连着提交十几件，四条实操

上面那句「纯机械活」是2026-09-10写的，当时一批只有7件。9月12号我为了给视频重做素材，在网页端一口气跑了14次生成加13次贴图生成，这才发现连着提交和提交一件是两回事。四条，按踩到的顺序写。

验收先看Tripo自己的预览，不看自己引擎里的截图

这条我2026-09-10栽得挺惨。

当时小王子的demo已经跑起来了，我在夜景、低角度、贴得很近的截图里看到玫瑰是「一团皱巴巴的红块」、狐狸是「摊在地上的一坨」，直接认定这两件重建失败了，还顺手在经验库里写了一条「细长结构是image-to-3D的弱项」。

两个判断都是错的。去Tripo的任务详情页一看：玫瑰是完整的玫瑰，花头、花萼、花茎、叶片都在；狐狸是完美的坐姿狐狸，耳朵、黑鼻、白胸、尾巴都清楚（那两张预览图在§08和§09）。

错在读图的方式，不在模型。低多边形模型在夜景低角度近距离下会退化成剪影，红玫瑰缩成一个红团，本来就该这样。而Tripo的预览是免费、直接、权威的一手证据，任务详情页一进去就是它，我却跳过了它去猜。

资产页见§03。顶部筛选按批次属性分：All / Smart Mesh / Untextured / Textured / Rigged，批量做完之后靠它点数。

所以我的验收顺序固定成三步：读Tripo自动起的名字（§08）→ 看Tripo自己的预览 → 才轮到自己引擎里的截图，而且引擎截图必须是中性光、正面、镜头退到能看见整体。为了这个我专门写了一个自检脚本，用无头浏览器逐件把摄像机摆到固定位置出图，就是§08那张道具拼图。

一批下来的账

两栏的单价对不上，当时我以为是记错了，后来才搞清是档位不同。巴黎那份开发笔记写于2026-09-09，账本上是实打实的40（2190生成一棵树之后剩2150）；小王子那批按钮上稳定是50。同一个「高精度模型」，几何底价15是固定的，差的全在贴图那一档：2K是30、4K是40、8K是50，再把Ultra网格打开就是65。按这条阶梯反推，40对应的是4K贴图档，50是默认的8K。阶梯是2026-09-11在表单上一档一档点出来的，完整拆法和我这次的实付明细在§07和附录C。巴黎那栏的700–800是开发笔记当时随手写的估数，不是逐笔加出来的：按23件×40反推应该是920，中间这120到220分的缺口我核不出来——那批当时没有逐条余额读数兜底，事后补不回去。所以这一栏我按附录C那条规矩处理：能闭合的单独说，不能闭合的标明是哪种数，小计那一格写的是反推值920，不是那个估数。小王子那栏的840反过来是能闭合的（16×50加两次绑骨20）。

Part II到这里结束。接下来Part III换一个方向：这些GLB拿到手之后，怎么接进Three.js、Blender、Unity，以及哪一层该交给谁。

§11把Tripo接进你的工具：五条路的入口与门槛

Five Integration Paths — Entry Points and Blockers

五条把Tripo接进自己工作流的路。其中两条我真的从零装到登录完，连日志带截图；MCP那条补跑了协议握手和工具表，还把它配进Claude Code验到连上；剩下两条给你官方口径和入口在哪。标题写的是「入口与门槛」不是「跑通」：五条路里没有一条走到「一件资产落盘」那一步，缺的是什么、为什么缺，节末单独有一段交代。

五条路其实是两类

第一次看Tripo开发者文档，左边导航里躺着CLI、Codex插件、ComfyUI节点、Quick Start、一大串API端点，还有博客里的DCC Bridge和一个GitHub上的MCP仓库。看起来是六七个并列的选项，很容易挑花眼。

其实只有两类。

第一类是「让AI替你调用生成能力」：Codex插件、CLI、MCP。你在编程Agent里用人话说「给我做个宝箱放到assets目录」，它自己去调、自己下载、自己放进你的项目。这一类的门槛是Node和一次浏览器登录，不需要你懂API。

第二类是「把模型送进你的软件」：DCC Bridge、以及API的下载环节。模型是你自己在网页上生成的，这两条只负责把文件搬到该去的地方。

先说结果：两条都被挡住了，而且卡点不是同一个

我得把最重要的一条先讲了，因为它会改变你的预算方式。

CLI那条卡在Tripo的API钱包是0积分。Codex那条卡在我的Codex订阅额度耗尽。两条路都走到了「发起生成」才被拦下，全程Tripo API积分变化是0 → 0，一分没花，也没买。

顺手把另外四条折叠的FAQ也取全了，这五条合起来才是完整的计费图景：

路径一实录：Tripo CLI

环境：macOS 26.6.0 / Apple Silicon / Node v26.0.0 / npm 11.12.1。全过程14:04到14:51。

npm install -g tripo-cli
# added 11 packages in 5m

冷装实测4分49秒，同一台机器第二次跑238毫秒。慢的是国内网络拉registry，不是包大。

装完验证版本：tripo在/opt/homebrew/bin/tripo，版本0.4.0。

tripo doctor

这时候api key那行是红叉，api reachability是感叹号「skipped (no key)」，都正常，因为还没登录。

tripo login

终端5秒内打出一个四位加四位的终端码、一个授权网址、以及三步人话说明（打开网址、填终端码、点Authorize），然后阻塞等你。--region ov是国际区、cn是中国大陆区，不带的话浏览器流程会让你选。从发起到打出「网页授权完成」一共210秒，其中绝大部分是人在浏览器里操作的时间。

授权成功后终端自己往下走，打出的是：

✓ 网页授权完成
✓ Key 验证通过(region=ov),当前余额 0 积分
! 余额为 0:新账号可在控制台领取免费额度,或运行 tripo topup 充值

tripo make prop-02-bench.png --model tripo-p2 -p quad=true --no-open

还有一条关于模型版本的更正。文档页只提tripo-p1和tripo-v3.1，说「面数预算两万以内走p1、其余默认v3.1」。但tripo docs --topic commands/make里还有一个tripo-p2，而且它从不被自动选中，必须手动写--model tripo-p2。三个别名映射到的线上版本号是v3.1-20260211/ P1-20260311 /P2-20260801。

tripo view car-01-taxi.glb

路径二实录：Codex插件

官方文档写的是在Codex里打开Plugins → Plugins Directory → 搜Tripo 3D → Install。实测这一步根本不需要GUI。

codex plugin add tripo-3d@openai-curated-remote

14秒装完，版本tripo-3d 0.2.1，作者VAST，MIT协议。装完即启用，codex plugin list显示installed, enabled，~/.codex/config.toml里不落条目。

所以路径二和路径一共用同一个API钱包。这条推论被我自己的失败印证了：路径一余额是0，路径二就算模型额度充足也一样生不出东西。你要为这两条路准备的是同一笔钱。

codex exec -s workspace-write -c sandbox_workspace_write.network_access=true \
  "给我生成一个巴黎长椅的 3D 模型，保存到 ./assets"

文档和实际对不上的地方

把这两轮撞到的整理成一张表。左边是文档怎么写，右边是我机器上实际怎样。最后一条属于后面MCP那一小节，一并放这儿。

命令表：日常只用四条

tripo make能吃图、吃多视图、也能吃已有模型：

tripo make concept.png --for print
tripo make front.png back.png
tripo make hero.glb --then texture,rig
tripo make @last --then convert:fbx

--for后面跟七个内置预设：game-mobile、game-pc、film、print、ar-web、anim、toy。@last是「最近一个任务」，任何接受任务ID的地方都能用。什么都不想记就直接敲tripo，它会开一个交互菜单。

退出码表值得贴在脚本里，因为它把「白花钱」和「没花钱」分得很清楚：

Windows用户有三件事要先做（这几条我没有Windows机器可验，是文档原文）：npm装的是一个tripo.ps1脚本、PowerShell默认会拦住它，跑一次Set-ExecutionPolicy -Scope CurrentUser RemoteSigned；@last和带逗号的参数要加引号；配置和历史在%USERPROFILE%\.tripo。

剩下三条路：API、MCP、DCC Bridge

API

API Key在platform.tripo3d.com的API Keys页创建，只显示一次。基址https://openapi.tripo3d.com/v3，认证走Authorization: Bearer <token>。所有生成接口都是异步的：POST拿task_id，然后GET /v3/tasks/{task_id}轮到status: "success"，从output.model_url下GLB。官方给的节奏是每2秒轮一次、不要超过每秒1次请求，典型生成10到120秒。

文档里那条Game-Ready Character管线最值得看，它把我在§06里手点的绑骨流程写成了四个接口调用：

官方标的预估是约105秒、约85积分，并提醒两条：调rig之前一定先调rig-check，它会返回推荐的骨架类型、避免失败；retarget只吃已绑骨模型的task_id。这和我在§06里踩的坑对得上，网页版默认骨架预设是「适用于动物」、人物必须手动换，走API的话rig-check把这件事自动化了。

MCP：两条路，而且新旧分裂

第一条是官方CLI内置的tripo mcp子命令，命令表里写着Run the CLI as an MCP server。你装了CLI就已经有了它。

第一条我补测了。2026-09-13我用一个自写的stdio客户端跟它走了一遍MCP协议：initialize、tools/list、两次读类tools/call。这一轮同样是零消耗，没有发起任何生成。

握手返回的是protocolVersion 2024-11-05、serverInfo为tripo-cli 0.4.0，capabilities里只有tools，没有resources也没有prompts。tools/list列出五个工具：

tripo_make的入参和命令行那条tripo make是一一对应的：scenario就是那七个预设，then就是处理链（原文举例"texture,rig,convert:fbx"），model三选一、tripo-p2的括注写着P-series preview with quad，output_dir是产物目录。换句话说MCP这一层没有新增能力，它是同一套CLI换了个协议门面。

配进Claude Code的写法是下面这段，2026-09-13实测。它是stdio server，不占端口、不用你自己起进程，把命令交给客户端就行。项目根放一个.mcp.json：

{
  "mcpServers": {
    "tripo": {
      "command": "tripo",
      "args": ["mcp", "--quiet", "--no-open"]
    }
  }
}

不想写文件的话，在项目目录里敲一条命令让它替你写：

claude mcp add --scope local tripo -- tripo mcp --quiet --no-open

然后用claude mcp list验一下，我这台机器上打出来的是tripo: tripo mcp --quiet --no-open - ✔ Connected。那两个参数是有理由的：--quiet把进度日志从stderr上摁掉，免得和协议输出混在一起；--no-open不让它自己弹浏览器——MCP是给Agent用的，不该在你没看着的时候开窗口。

到这儿为止都是实测的。再往下——在会话里说一句「给我做个宝箱放到assets目录」——我没跑通，因为那句话最终会走到tripo_make，而钱包是0。请求本身没有格式要求，SKILL.md给的示范就是这个句式：说清楚要什么、放哪儿，参数它自己填。

第二条是GitHub上的VAST-AI-Research/tripo-mcp仓库。采集当天我数了一下：200 star、27 fork、总共8次提交，最后一次提交停在2025年4月14日，到现在快十七个月没动过，7个issue开着，README自标alpha。

DCC Bridge：唯一不涉及AI Agent的那条

这条很容易和MCP混淆，其实完全是两回事。DCC Bridge是一条传输通道：你在浏览器里的Tripo Studio生成好模型，点一下，模型直接出现在Blender里，不用下载、不用导入。它不替你调生成，也不听人话。

官方博客写的Blender版要求：Windows或Mac；Blender 4.1.0或更新；浏览器只支持Chrome 116+、Edge 116+、Opera 102+，其他浏览器不支持。装法是在Studio里下ZIP包，Blender里编辑 → 偏好设置 → 插件 → 从磁盘安装选那个ZIP（不要解压），启用后按N调出面板，回网页点DCC Bridge激活，然后在导出小窗里点Export。

导出弹层那张图在§03。这里只看底下两个按钮：左边Send To就是DCC Bridge的出口，右边Export是普通下载。

两条官方FAQ提前记住能省时间：不能同时推给多个Blender实例，连接只认第一个启动的那个，开多个会报「Port already in use」；插件更新后如果显示「All connections closed」连不上，重启Blender并重新激活，看到日志里出现「Server running on port XXXX」才算真连上。

哪些步骤必须你自己做

这一轮跑下来，有五件事Agent不该替你做，或者做不了。

最小项目长什么样

走CLI的话，最小项目就是一个空文件夹加一条命令：

task.json记录这个任务是怎么创建的。官方给Agent的建议里有一条我很认同：如果preview.png存在，在决定继续管线还是重跑之前先看一眼它。这是让Agent自己做质检，比跑完一整条链再发现形不对便宜得多。

这一节还缺什么

缺的是最后一步：钱包里有积分之后，把tripo make真的跑通一次。具体缺的是三个数——任务从提交到成功的算子耗时、扣掉的API积分、以及tripo-out里那一个目录的真实产物。现在这一节能告诉你的是「到发起生成为止的每一步长什么样、会卡在哪」，还不能告诉你「一件资产从命令行出来要多久、多少钱」。CLI、Codex插件、MCP三条路卡在同一个地方，就是那个0积分的API钱包。

这一轮往前挪了一格：MCP那条补了协议实测和工具表，也把tripo mcp配进Claude Code验到Connected，配法在前面那一小节。所以缺口从「装到哪一步会卡」窄成了一件具体的事——那一件落盘的资产。API那条的缺口更大，具体缺哪三样，在前面API那一小节已经点过名了。

那个「Get Your free wallet(14 days)」按钮一直在旁边，我没点，理由在前面那张钱包截图底下：它是一次性权益、带14天倒计时，该留给真正要连着跑测试的那一周，而不是为了在书里凑一个数把它烧掉。这一节宁可缺一个数，也不想给你一个「我领了、跑了一件、然后钱包过期」的样本。

§12 Three.js：让模型在网页里跑起来

Three.js — From GLB Files to a Playable Page

六个可交互demo跑下来，我在加载Tripo资产这件事上踩过的坑、一个和直觉完全相反的性能结论，以及P2.0那条路上完全不同的另一套工序。

先说三件决定成败的事

把Tripo导出的GLB塞进Three.js，理论上是三行代码的事。实际上我做完巴黎城、星月夜、四冲程发动机、旋转游乐场、游乐园、小王子星球这六个demo之后，发现真正决定它成不成的只有三件事。

一，环境贴图。没有它，Tripo出的PBR材质在白底上会渲成一团死黑，而你会以为是模型坏了。

二，贴图尺寸。卡顿的第一反应是三角形太多，但我量完之后发现渲染链只用掉了预算的八分之一，真正吃掉5 GiB显存的是贴图。

三，带骨骼的模型怎么复制。用错一个函数，一整排行人会像仪仗队一样同手同脚。

剩下的都是细节。这一节按这三件事展开，顺带把自校验那几个最贵的教训也放进来。

最小可跑的那个壳

开头那句「三行代码」在这一小节里兑现，同时也会看清它的水分：真正属于「加载模型」的只有new GLTFLoader().load()那一句，其余三十几行是把浏览器里那套渲染环境立起来的固定开销——渲染器、场景、相机、灯、环境贴图、一个能拖着转的controls。这一整页只写一次，后面六个demo都是在它上面长出来的。

先把环境立住。我所有demo的Three.js都是固定在项目vendor目录里的，不走CDN，因为发布包要能在断网环境下跑通、也要能塞进B站Toy这种子路径托管。

vendor目录里我只精选了五个文件：

这五个文件不用去页面上一个个找。npm拉一次锁死版本的three，再从包里挑出来就行——我比对过，这么拿到的五个文件和我六个demo里实际跑的那五个逐字节相同：

npm i three@0.160.0
mkdir -p vendor/addons/loaders vendor/addons/controls vendor/addons/utils
cp node_modules/three/build/three.module.js                     vendor/
cp node_modules/three/examples/jsm/loaders/GLTFLoader.js        vendor/addons/loaders/
cp node_modules/three/examples/jsm/controls/OrbitControls.js    vendor/addons/controls/
cp node_modules/three/examples/jsm/utils/BufferGeometryUtils.js vendor/addons/utils/
cp node_modules/three/examples/jsm/utils/SkeletonUtils.js       vendor/addons/utils/

版本号要钉死，不能写npm i three。addons里的文件会跟着主库一起演进，五个文件必须来自同一个版本，混版的报错长得和缺文件一模一样。本节所有代码都在r160（也就是three@0.160.0）上跑过。

然后是壳本身。下面这一整页可以直接复制、另存成index.html，和上面那个vendor目录、一个model.glb放在同一层：

<!doctype html><meta charset="utf-8">
<style>html,body{margin:0;height:100%;overflow:hidden}canvas{display:block}</style>
<script type="importmap">{"imports":{
  "three": "./vendor/three.module.js",
  "three/addons/": "./vendor/addons/"
}}</script>
<script type="module">
import * as THREE      from 'three';
import {GLTFLoader}    from 'three/addons/loaders/GLTFLoader.js';
import {OrbitControls} from 'three/addons/controls/OrbitControls.js';

const renderer = new THREE.WebGLRenderer({antialias:true});
renderer.setPixelRatio(Math.min(devicePixelRatio, 2));
renderer.setSize(innerWidth, innerHeight);
document.body.appendChild(renderer.domElement);

const scene = new THREE.Scene();
scene.background  = new THREE.Color(0xf2f0ea);
scene.environment = studioEnv(renderer);      // 没有它，金属件在白底上是死黑（函数写在本页末尾）
const camera = new THREE.PerspectiveCamera(45, innerWidth/innerHeight, 0.01, 100);
camera.position.set(2.2, 1.6, 2.8);
const controls = new OrbitControls(camera, renderer.domElement);
controls.target.set(0, 0.7, 0);
const sun = new THREE.DirectionalLight(0xffffff, 2.5); sun.position.set(3, 5, 2);
scene.add(sun, new THREE.AmbientLight(0xffffff, 0.5));

new GLTFLoader().load('./model.glb', g => {
  const root = g.scene, b = new THREE.Box3().setFromObject(root);
  const c = b.getCenter(new THREE.Vector3());
  const s = 1.6 / Math.max(...b.getSize(new THREE.Vector3()).toArray());  // 原始只有1.0单位
  root.scale.setScalar(s);
  root.position.set(-c.x*s, -b.min.y*s, -c.z*s);
  scene.add(root);
});
addEventListener('resize', () => {
  camera.aspect = innerWidth/innerHeight; camera.updateProjectionMatrix();
  renderer.setSize(innerWidth, innerHeight);
});
renderer.setAnimationLoop(() => { controls.update(); renderer.render(scene, camera); });

// 环境贴图：canvas 画一张渐变当 equirect，不需要外部 HDR 文件。为什么这么写见下一小节
function studioEnv(rd){
  const c=document.createElement('canvas'); c.width=128; c.height=128;
  const g=c.getContext('2d'), grd=g.createLinearGradient(0,0,0,128);
  grd.addColorStop(0,   '#ffffff');
  grd.addColorStop(.34, '#e8e4da');
  grd.addColorStop(.52, '#928d82');
  grd.addColorStop(.75, '#5c574e');
  grd.addColorStop(1,   '#403c35');
  g.fillStyle=grd; g.fillRect(0,0,128,128);
  g.fillStyle='rgba(255,255,255,.9)';
  g.beginPath(); g.ellipse(40,24,26,13,0,0,Math.PI*2); g.fill();
  const t=new THREE.CanvasTexture(c);
  t.mapping=THREE.EquirectangularReflectionMapping;
  const pm=new THREE.PMREMGenerator(rd);
  const env=pm.fromEquirectangular(t).texture;
  pm.dispose(); t.dispose(); return env;
}
</script>

在这个目录里起服务、浏览器开http://localhost:8765，能看见模型、能拖着转，再往下读那三个坑：

python3 -m http.server 8765

坑一：白底加PBR金属加没有环境贴图，等于死黑

这是我付出时间最多的一个坑，而且它有伪装。

四冲程发动机那个demo，v1是深色赛博底，看着一切正常。v2改成纸感白底之后，整台机器直接变成一团黑影。金属度高的时候漫反射被抑制，只靠直接光什么都看不见；深色背景下这个问题被背景吃掉了，一换白底就全暴露。

解法不需要外部HDR文件，就是上面那一页末尾的studioEnv()：用canvas画一张渐变当equirect环境贴图，走PMREMGenerator转成可用的环境光照，再挂到scene.environment上。

那十几行里有两个细节是试出来的，不写出来你照抄也调不对。

环境贴图不能全亮。我第一版渐变是从白到浅灰，结果金属反射回来全是亮色，整个画面发白、没有重量感。必须给它一个暗部，相当于摄影棚里的黑旗，金属才有明暗对比。上面那段渐变从#ffffff压到#403c35就是为了这个。

白底场景别用ACESFilmic色调映射，它会把白底压成灰。

星月夜那个demo走的是另一条更简单的路：加载完直接把材质的金属度归零。

// 星月夜：村庄模型本来是一团黑，两行就回来了
mat.metalness = 0;
mat.roughness = 0.92;

两条路的取舍很清楚：要金属质感就老老实实做环境贴图，不要金属质感就把metalness摁掉。最怕的是既不做环境贴图又保留高金属度，那就是一团黑。

坑二：尺寸和原点，两件事都不能想当然

Tripo导出的GLB被归一化到最长边约等于1.0单位（不是高度：解析包围盒能看到长椅是1.0×0.549×0.413、出租车是0.522×0.570×1.0，撑满1.0的那条边各不相同）。我在§14用实测数字展开这件事，这里只说Three.js侧怎么处理：实例化之后先量包围盒，再按目标尺寸算缩放，最后把底面压到地面。

const b = new THREE.Box3().setFromObject(root);
const size   = b.getSize(new THREE.Vector3());
const center = b.getCenter(new THREE.Vector3());
const scaled = new THREE.Group();
scaled.scale.setScalar(height / size.y);
root.position.sub(new THREE.Vector3(center.x, b.min.y, center.z));
scaled.add(root);

这段对静态模型是对的。对带骨骼的模型是错的。

Box3.setFromObject量SkinnedMesh量不准。（我一开始以为是「它拿的是绑定姿势的几何包围盒」，后来才弄清楚：three.js从r155起已经会按当前姿势算了，真正咬人的是那个包围盒缓存不会自己更新——姿势变了，你量到的还是上一帧的。修法一样，理由不一样，这里更正一下。）叠上Armature节点变换之后算出来的尺寸离谱。做方案D那个「同一模型两种绑定」的实时对照页时，右边那个模型被放大到画面里只剩两只鞋。

解法是绕开Three.js，直接读GLB里POSITIONaccessor的min和max拿真实尺寸，按已知值硬算。GLB的头部结构很简单，不需要任何库：

import struct, json
d = open(f,'rb').read()
jl = struct.unpack('<I', d[12:16])[0]
j = json.loads(d[20:20+jl])
# 遍历 meshes[].primitives[].attributes.POSITION → accessors[i].min / .max

坑三：带骨骼的模型不能用普通clone

巴黎城里有18个行人，其中6个用的是同一个绑骨模型（另外12个是静态的，为什么不是18个全走，见§18）。第一版我用clone()复制，结果这几个人同手同脚，像在走正步。

原因是普通clone会让所有实例共享同一副骨骼。必须用SkeletonUtils.clone()，然后每个实例配一个自己的AnimationMixer。

import {clone as skeletonClone} from 'three/addons/utils/SkeletonUtils.js';

const root = skeletonClone(walkScene);
const mixer = new THREE.AnimationMixer(root);
mixer.clipAction(walkClip).play();
// 相位错开，否则一整排人还是整齐划一
mixer.setTime((x*0.37 + z*0.11) % walkClip.duration);

还有两条是接Tripo绑骨动画特有的。

把位移轨切掉，只留旋转轨。retarget出来的剪辑里Hip.position的Y位移范围是1.338，而人本身才1米高。行走是代码推的，动画再叠一层位移，循环回到起点时整个人会弹回去。我在画面里看到的「走着走着又会回退一大步」，根因就是这个。步态本来就是纯旋转，位移归游戏代码管。

在Tripo那边对应的是导出时勾上「原地播放动画」（见§06），勾了它动画就只管迈腿。

模型朝向是试出来的，不是推出来的。Tripo预设人形的自然朝向不是+Z，实测差90度。小王子那个demo里这个常量写死成PRINCE_YAW = -Math.PI/2，而这个数是在浏览器控制台里现场转rotation.y、看正对还是背对镜头试出来的。

但「差90度」这句话只对绑骨预设人形成立，别把它当成通则。静态资产还有另外两套完全不同的惯例，符号甚至是相反的，我在后面「朝向」那一节按类别拆开写。把三类混成一句话记，迟早会把一栋楼装反。

性能：瓶颈是贴图，不是三角形

这是这一节我最想让你记住的一条，因为它和直觉完全相反。

小王子星球那个demo做完，页面卡得没法看，我丢给agent的原话是「性能需要优化500%」。我的第一反应和所有人一样：减面、关泛光、砍阴影。

但我先量了一次。量出来的结论把我的第一反应全推翻了。

渲染链只用掉了预算的约八分之一。卡顿不可能来自三角形数量、后期链或者JS，砍这些等于白砍。

真凶在显存。把场景里所有材质的贴图列出来：

唯一贴图数: 31
尺寸分布:  8192×8192 × 10      4096×4096 × 20      2048×1024 × 1
估算显存:  5.0 GB（含 mipmap）

这批v3.1资产导出的是8192²的PBR贴图。（贴图这件事必须按模式说：v3.1这条路出base color、normal、ORM三张，P2.0那条路只出一张base color，两者的处理方式不一样，后面有一整节讲P2.0。）每个道具在画面里才一两米高、屏幕上几百像素，却挂着一张8192²的底图。一张8192²按RGBA32展开是268 MB，加上整条mipmap链（×4/3）约358 MB；17个资产的贴图加起来是5.0 GiB，GPU一直在做纹理换入换出，表现出来就是「卡」。（别拿17乘358——那17件挂的不全是8K：唯一贴图31张，其中8192²的10张、4096²的20张、2048×1024的1张，10×358＋20×89.5＋11＝5381 MB＝5.01 GiB，逐张清单在§22。）

处理办法是只降贴图，不碰几何：

gltf-transform resize 产出/x.glb 网页/assets/tripo/x.glb --width 1024 --height 1024

（gltf-transform是装成全局或本地依赖之后的简写。没装的话，在前面补上npx @gltf-transform/cli，效果一样，只是每次多等几秒启动；说明见§04。这条命令要先有Node，见§11。）

画质在这个观看距离上肉眼无损。王座特写的木纹、红绒、金冠，主角特写的脸、外套扣子、围巾，1024²都撑得住。

顺带省掉的四样，都是量完之后才敢动的。

antialias关掉。接了EffectComposer之后画面是先渲进render target的，画布那层的MSAA对场景几何完全不起作用，开着只是白付一次多重采样缓冲加resolve。

阴影从PCFSoftShadowMap降到PCFShadowMap，并且不再每帧重渲阴影贴图。

泛光跑在半分辨率上。纯填充操作，肉眼分不出，模糊开销少四分之三。

自适应分辨率兜底，但中间要留死区。帧时间掉到48 fps以下降档，回到91 fps以上才升回去。两边挨太近的话，一台稳定跑50 fps的机器会来回抖，而每次改档都要重建WebGL缓冲区，那比稳定50 fps更难受。

另一条路：P2.0资产的接入工序链

上面这些坑，全是v3.1那条路上踩出来的。九月我把巴黎那座城里沿街的资产整批换成P2.0重出的件，才发现这是另一条路，坑几乎不重合。同样是「把GLB塞进Three.js」，工序链要重走一遍。

五道工序，少一道就装不上去。

第一件事：P2.0只出一张base color

这条我放在最前面，因为它决定了你到底在找什么文件。

ORM是把环境光遮蔽、粗糙度、金属度三个量打包进一张图RGB三个通道的常见做法，是引擎判断「这块表面是金属还是布」的依据。P2.0没有它，也没有法线图，于是同一盏灯下，P2.0的新件会比v3.1的旧件哑：没有法线图，表面那层细凹凸不参与打光；没有ORM，整件东西从头到脚只有一个粗糙度。

说清楚一点：P2.0这个模式本身就只出这一张图，转换过程什么都没丢。我用两份独立记录核过：一份是taxi那次FBX转GLB的逐项核验，一份是38件批量降贴图的逐件日志，两边都只数到一张。

第二件事：8192²乘26件等于9.3 GB

P2.0那张base color出厂就是8192²。前面小王子那节已经量过一次8K贴图的代价，巴黎这边我又算了一遍，因为件数不一样（这座城里装机的是26件，重出的那批一共38件），而且这笔账在纸上就能算完，不用等浏览器崩给你看。

算法是按每像素4字节（也就是RGBA32）解码再加整条mipmap链，系数约1.33倍，和前面小王子那节写的358 MB是同一笔账。这笔账我按1 MB等于100万字节算，你要是拿显卡工具对，它按1024进位、读数会比这里小约7%（同一个数在那边是341 MiB、8.67 GiB），不是算错了。降到1024²之后比旧件贵33%，换来的是单张贴图分辨率翻倍，落在预算内。

1024这一档是我照配方定的，没和512、2048做过A/B。画质上够用，但我不能说它是最优解。

38件批量降贴图：不走Blender，直接改glTF的JSON和BIN

这批资产已经是GLB了，所以这一道我刻意绕开了Blender，直接改GLB里的glTF JSON和BIN数据块：只动images那几段字节和可选的顶点数据，其余原样搬过去。绕开Blender的理由、源与产物的逐项对照、以及38件全过的八项核验清单，完整在§17「批量那一档」，那里还多两条：doubleSided全是true的Blender成因，以及多张贴图必须按原图名一一对应。

朝向：三类资产三套惯例，千万别并排读

「Tripo出来的东西朝哪边」这个问题没有单一答案。我手上这三类资产各有各的惯例，混成一句话记一定会出事，所以拆开写。

先看行人和建筑那两行：符号是相反的，而两者的包围盒长得一模一样，光看数字分不出来。我第一次就是拿「旧件朝+Z」这一句去套建筑，把楼装反了90度，素墙对着马路。

P2.0家族的两个例外也都是渲图读出来的。vehicle-04-citroen-ds正面朝-X：+X那一视图是尾灯和后窗，-X才是DS那张四头灯的脸。building-10-bouquiniste-wall正面朝-Z：-Z视图里书箱是敞开的、看得见书，+Z是合上的箱盖。

再强调一遍这件事为什么不能靠算：包围盒推不出朝向。绕Y转90度只是把X和Z互换，转180度连互换都没有。--yaw 90和--yaw -90出来的包围盒完全相同，一个车头朝前，一个倒着开。新旧各渲一组六视图并排看，这是唯一靠得住的办法，26件就得看26遍，没有自动化的捷径。

烘进顶点，不要写节点矩阵

yaw定好了，接下来是把这个旋转写到哪儿去。GLB里有两个位置可以放：写成场景根节点的变换矩阵，或者直接乘进每一个顶点。这里必须选后者，而理由不在Tripo那边，在你自己的加载代码里。

巴黎demo的loadCityTree()是这么写的：用Box3.setFromObject量世界包围盒（这一步会把节点矩阵算进去），然后把归一化施加在原始geometry上（这一步无视节点矩阵）。量的时候算了，用的时候没算，两步不在同一个坐标系里。给这样的加载器一个带旋转的节点矩阵，模型会静默错位，不报任何错。

烘进顶点对两条路都安全，所以我每一件都带着--bake跑。「量的时候算了、用的时候没算」这类不对称，是接第三方资产时最容易中的一类埋伏，症状永远长成同一个样子：位置不对，但控制台干干净净。

A/B帧时间：量出来的是「量不出回归」，不是「变快了」

换完六件之后要回答一个问题：新件有没有把性能换坏。问题看着简单，第一次我量错了。

「六件」也要说清口径：它是2026-09-12那一轮真正落地的六个旧槽位——那一轮清单上排了九个，三个当场否掉（映射表把一栋六层公寓写成了地铁口、新咖啡露台多一根两米高的取暖伞会把桌椅按比例压到半米、行道树在另一条线上换），理由在§16。这一轮之后另一条线又换掉两个行人槽位，加起来才是§16说的「8个槽位」。下面这张A/B表量的是那六件，不是八件。

不能看帧间隔。浏览器的帧间隔被vsync锁在8.3或者16.6毫秒上，两组资产量出来的中位数会一模一样，差别全被锁没了。要量的是每一帧GPU真正忙了多久，这需要一个WebGL2扩展挂在requestAnimationFrame上：

const ext = gl.getExtension('EXT_disjoint_timer_query_webgl2');
const q = gl.createQuery();
gl.beginQuery(ext.TIME_ELAPSED_EXT, q);   // 这一帧开画之前
// … renderer.render(scene, camera) …
gl.endQuery(ext.TIME_ELAPSED_EXT);        // 画完
// 隔几帧再来收结果，单位是纳秒；GPU_DISJOINT 为真说明这次计时不可信，丢掉
if (gl.getQueryParameter(q, gl.QUERY_RESULT_AVAILABLE)
    && !gl.getParameter(ext.GPU_DISJOINT_EXT))
  ns = gl.getQueryParameter(q, gl.QUERY_RESULT);

协议也要钉死，否则你量的是自己的驾驶技术：刷新页面、跑一段自由漫游、回到出生点静止采样。巴黎demo的出生点坐标是确定性的，两次完全可复现。

这张表的结论是「量不出回归」，不是「变快了」。0.37毫秒的差落在跑间噪声里，我没有第二次独立跑来支撑「变快」这个说法，所以不说。draw call一个没变，三角面降了0.7%，和逐件的算术对得上，这两条才是真结论。把噪声读成改进，是性能测量里最常见的一种自欺，尤其在你正好希望它变快的时候。

一个格式坑：normalized的int16会让你算出32783倍的缩放

这个坑值得单独写，因为它完全不像格式问题，倒像「我的数学写错了」。

巴黎demo现有的26件资产都带KHR_mesh_quantization扩展，顶点位置不是float32，而是normalized: true的int16。这个标志的意思是：这里存的整数不是坐标本身，读的时候要除以这个类型的满量程（int16是32767）才是真实值。它是压缩类扩展的标配，因为整数比浮点省一半空间。

我自己那个无依赖的GLB解析器一开始不认这个标志，把原始整数直接当世界坐标读。于是pedestrian-02被读成32767单位高，而它实际是1.0。接着「按旧件高度对齐新件」那个功能拿这个数去做除法，算出来的缩放系数是32783。

# 按分量类型归一化回 [-1,1] / [0,1]
if accessor.get('normalized'):
    SCALE = {5120:127.0, 5121:255.0, 5122:32767.0, 5123:65535.0}
    pos = pos / SCALE[accessor['componentType']]
    if accessor['componentType'] in (5120, 5122):   # 有符号的还要夹一下下界
        pos = np.maximum(pos, -1.0)

两条可以带走的。自己写glTF解析器，就一定要处理normalized。而从FBX那条路转出来的GLB不产生normalized accessor，所以同一个解析器读新件一直是对的、只在读旧件时出错。一个只在一半输入上出错的bug，比全错的bug难找得多，因为你会先怀疑那一半输入。

后期链里最深的一个坑：ShaderPass会clone uniforms

这一个我排查了很久，因为症状极具误导性。

const Grade = { uniforms:{ uRes:{value:new THREE.Vector2(1,1)}, … } };
const gradePass = new ShaderPass(Grade);      // ← 这里 clone 了一份
Grade.uniforms.uRes.value.set(w, h);          // ← 写的是原来那份，着色器读的是 clone

两个对象，写错了不报错，着色器只会一直用初始值。

于是uRes停在(1,1)，湿边效果「取邻居」取的是屏幕另一头的深度，整片地面被判成巨大跳变、压成灰的；而天空因为处处深度都是1.0反而看着完全正常。顺着「天空没事、地面全黑」这条线去查，会一路怀疑深度纹理格式、线性化公式、掠射面梯度，全都对，因为根本不是那些。

排查路径记下来，下次照做：

同一轮里我还清掉了两个自测脚本自己的bug。测量方法本身也要被怀疑。

自校验：这一节的教训最贵

截图自校验之前，先确认页面的加载遮罩已经淡出。做发动机v2那轮，我有四轮都在给一张蒙了白色遮罩的图调材质。每轮都判断「还是发白」，于是继续调环境贴图、调曝光、调金属度，而真正的原因是#load那层不透明白色盖在整个画面上没消失。

另外三条工程上的：

macOS没有timeout命令。timeout 50 chrome ...会静默变成command not found，整条命令什么都没干。我因此以为headless渲染失败了好几轮。

headless Chrome写完截图文件后不退出。命令会超时报错，但文件已经写出来了。报FAIL不等于没文件，收尾要按文件是否存在重新盘点，别信退出码。另外多个headless实例堆积会互相干扰，先pkill -f "headless=new"再跑。

后台标签页的requestAnimationFrame会停。本地自校验要加setInterval(frame, 340)兜底。

发布：两个沙盒的坑

做完了要给人看。静态托管最省事，把目录整个传上去就行，Vercel、Cloudflare Pages、GitHub Pages都能直接扔。

但有两类环境会咬人。

第一类是禁用fetch()的沙盒。我最早那版巴黎demo发在Artifact里，模型渲染成纯黑，没有任何报错。查了很久才明白：那个环境会完全禁用fetch()（连data:URI都不放行），而Three.js的GLTFLoader加载贴图时优先走ImageBitmapLoader、内部用的正是fetch()，于是静默失效。

// 逼 Three.js 退回到走 <img> 标签的经典加载路径
window.createImageBitmap = undefined;

这条对任何类似的沙盒环境都成立，不只对那一家。

第二类是子路径托管。B站Toy这类平台把页面跑在/toy/<slug>/下面，绝对路径的资源引用会404、根绝对跳转会跳错。包传得上去、审核也可能过，但打开是坏的。我的发布包因此全部用相对路径。

Toy的发布动作本身是两段式的：先不加确认参数跑一次，拿到预览链接自己在浏览器里检查，确认没问题再提交审核。预览就是那道闸门，别一步到位。

混搭：Tripo和程序化不是二选一

最后一条，也是我认为对做游戏最有用的一条。

巴黎城里近景行道树用的是Tripo生成的GLB（两款巴黎七叶树，绿叶和秋黄交替，近景实例配额110；早期是36株、用的还是另一棵梧桐，换树种和提配额的原因都在§18），中景、远景和公园的两万株保留程序化球冠。原因很实在：近景要细节，远景只需要「那儿有个绿色的东西」，而AI模型的面数成本撑不住两万株。

这笔账我在巴黎城里同机位同画质量过，开着沿街14栋Tripo建筑对全程序化，代价是多17个draw call、多15%三角面，帧率一帧没掉。完整的两组读数在§13。

接Tripo树的时候还有个细节值得记：城市层给的c.h是「冠高」，而GLB树的宽高比接近1比1（整树包围盒），程序化树是宽8比高11的瘦高个。按高度等比放大到2倍时冠幅会变成14米，而行道树间距才8米，整排会糊成一片。最后heightScale取1.2，冠幅落在8.4米。

接Tripo资产的检查表

§13 Blender：什么时候该进，什么时候别进

Blender — When It Earns Its 300 MB

同一个资产跑三条路径的实测对比、一次失败得很彻底的自动权重绑定，以及几个不打开GLB的JSON就永远发现不了的坑。结论可能和你想的不一样。

先说结论

「Tripo出的模型要不要进Blender」这个问题，我一度以为答案是「当然要，专业流程都这么干」。跑完对照实验之后，我的答案变成了三句话。

只做减面和压缩的话，Blender没有优势。同一个资产，Blender产出6772面、365 KiB，命令行产出6781面、369 KiB，肉眼和数字上都等价，而命令行不需要那三百兆的依赖。

Blender在这条管线上有两件事最值得它那三百兆，头一件是让死的资产活过来。Tripo直出的静态模型是0个skin、0个关节，任何关节动画都做不了；Blender一秒就能给它加上骨架。第二件是格式转换：P2.0带贴图的产物只给FBX，浏览器只吃GLB，而我这台机器上当时装了的、能把FBX读进来再吐成GLB的，只有它，这条在本节最后展开。

但在Tripo的资产上，Blender的自动权重是不成立的。转一下脊柱整个人就倒了。这条是我实测出来的，下面有图。

所以2026年9月这个时点，我的真实推荐是：角色要动，走Tripo自带的绑骨（见§06）；Blender留给格式转换、拆件、精修、烘焙和hero资产。

E0：同一个资产，三条路径

实验设置尽量干净：同一个案例building-03-boulangerie.glb（奥斯曼面包店，16696面/ 568 KiB / 512²贴图），环境是Blender 4.4.3无头执行加@gltf-transform/cli4.5.0，耗时用date +%s记墙钟。

这件输入不是Tripo直出的原件，是A组那件在本地跑过一道gltf-transform optimize之后的512²版，也就是附录A的B组；Tripo直出的原件是16874面、1.49 MiB、1024²贴图。三条路喂的是同一个输入，所以对照本身不受影响，但引这几个数的时候别把它当成「Tripo刚出炉的样子」。（本节的文件体积一律按1024进位写成KiB／MiB，和附录A那张逐件表用的是同一把尺子。）

模式B，Tripo直连引擎，两条命令：

gltf-transform simplify in.glb tmp.glb --ratio 0.1 --error 1
gltf-transform optimize tmp.glb out.glb --compress quantize --texture-size 512

减面3秒、压缩3秒，合计6秒。产出6781面/ 369 KiB。

模式A，进Blender，一段无头脚本：

bpy.ops.import_scene.gltf(filepath=SRC)
m = obj.modifiers.new('dec','DECIMATE')
m.decimate_type = 'COLLAPSE'
m.ratio = 6781/16696
bpy.ops.export_scene.gltf(filepath=DST, export_format='GLB', export_apply=True)

导入0.2秒、减面加导出0.1秒，含Blender启动的墙钟2秒，后续压缩同模式B再3秒。产出6772面/ 365 KiB。

差异在千分之一量级。「必须进Blender」这个迷思，在减面这件事上是假的。

模式C是混搭，不是二选一。我在巴黎城里同机位同画质跑了两个变体：开着沿街14栋Tripo建筑，和把它们全关掉。

用15%的三角预算，买下赛道沿线全部的高细节建筑，帧率一帧没掉（两个变体都锁在vsync 60 fps满帧）。这就是混搭的量化价值。

Blender不可替代的那一件事：绑定

用pedestrian-01-man-suit.glb（静态行人，和E0一样取的是B组那件512²版，不是Tripo直出的原件；不过「0个skin、0个关节」这一条A组原件同样成立，降一道贴图不会凭空长出骨架）补测，Blender侧脚本建一条三骨骼链root → spine → head，用ARMATURE_AUTO自动权重，一秒跑完。

E3：连通分量拆不出轮子

在做「车轮能不能转」这件事之前，我先试了最直觉的路：用Blender按连通分量把网格切开（mesh.separate(type='LOOSE')），看能不能得到一个可以独立旋转的轮子。

拆不出来。Tripo的输出不是一整块干净网格，而是几百个100到650面的碎片。按连通分量切只能得到这些碎片，得不到「轮子/车身/车门」这种语义部件，因为轮子和车身在几何上是糊在一起的。

这条结论解释了两件事。我那个游戏里车轮转不了，根因是源模型里根本没有可分离的轮子，跟我做没做没关系。而Tripo自己那个「智能拆分」功能之所以是刚需，是因为它做的是语义拆分（按物体含义分件），这是几何算法做不到的事。拆件的实操和实测结果在§05，这里不重复。

E4：自动权重绑上了，但权重是错的

绑定生效不等于绑定可用。我把E0里绑好的那个文件重新导入Blender，进姿态模式依次转spine和head，渲三张图。

根因和E3是同一个。模型是几百个碎片拼成的，没有连续的蒙皮拓扑，ARMATURE_AUTO算出来的权重自然对不上；碎片还会在变形时脱离主体。

独立评测里对AI生成网格的通用描述是「多边形分布均匀、边环不贴合解剖结构」。碎片化正是「没有边环结构」的表现，而边环恰恰是自动权重赖以工作的东西。

换成Tripo自带绑骨，同样的动作

为了看清楚差在哪，我把一个Tripo自动绑骨出来的角色也导进Blender，做完全相同的动作。

那什么时候该进Blender

把该做的和不该做的分开写，比一句「看情况」有用。

先过一道：你拿到的这个GLB，Blender可能根本打不开

上面所有实验用的都是带贴图的那批文件，一导就进。但我后来撞上了两种导不进去的情况，问题都出在文件本身，不在Blender。

第一种：文件名里带meshopt的那个变体。

Extension EXT_meshopt_compression is not available on this addon version

Blender 4.4的glTF导入器不支持这个压缩扩展，报完这一行就结束，模型一个顶点都进不来。我在两条完全不同的线上各撞了一次：一次是做两种模式对照实验时去拿几何数据，一次是渲Blender演示素材时。两条线撞的是同一件事，说明它不是偶发。

怎么避开，两条路：

第二种：为了省积分关掉贴图生成的那种。这条是个陷阱，值得专门说。

v3.1这条路把「贴图生成」关掉，价格会明显往下走。听起来像是「我先出个白模，贴图以后再说」，但实测的产物是这样的：

GLB 顶点属性：只有 POSITION 和 NORMAL
materials = 0   textures = 0   images = 0

连UV都没有。UV是把二维贴图贴到三维表面上的那套坐标，没有它，任何贴图都无从贴起。所以「以后再补贴图」这条路是不通的，要贴图只能回Tripo重跑一次。

Tripo的GLB导进Blender之后长什么样

在写脚本之前，先知道你会拿到什么。这几条看起来琐碎，但每一条我都是因为没预料到才多花了时间。

命名带uuid。一个模型进来是三件套：tripo_node_<uuid>、tripo_mesh_<uuid>、tripo_mat_<uuid>，uuid是那次生成任务的标识。好处是不会重名，坏处是脚本里没法按人类可读的名字找对象，得按类型或顺序找。前面那两张大纲视图截图里能看到完整的名字。

多一个glTF_not_exported集合。里面通常躺着一个「棱角球」，是glTF导入器的辅助物体，不是你的模型。它不会被再次导出，但会被bpy.context.scene.objects遍历到。

材质是PBR而且带金属度。Blender里看着正常，因为Blender的默认HDRI环境把它照亮了；一进Three.js或者白底场景就变黑（见§12）。Blender里看着对，不代表引擎里看着对。

整体高度接近1.0单位。这条和引擎侧是同一件事，见§14坑一。在Blender里表现为：导进来那个模型在默认网格上小得像颗豆子，你会下意识去缩放视图，然后忘了它本身的尺寸也是要处理的。

Blender、命令行、混搭的总对照

压成三句：要动的东西绕不开A；只要摆着好看的东西B更快；要摆满一整个城市，C是唯一答案。

那还能不能在Blender里绑好Tripo的资产

E4证明的是「直接对Tripo直出的静态网格跑自动权重」这条不成立，它没有证明「Blender绑不了Tripo的东西」。这两句话差别很大，我不想把前者说成后者。

按E3和E4的根因往回推，有条路在逻辑上是通的：碎片化是自动权重失败的原因，那就先把拓扑变连续，再绑。可以先在Tripo里做一次重拓扑（10积分，产出四边面，见§04），或者先做语义分件把部件分开（见§05），拿到更规整的网格之后再进Blender。

无头Blender：不开界面也能干活

上面那些实验没有一个是我手点出来的，全部是--background模式跑的脚本。对不会写代码的人来说，这反而是更省事的路：你不需要学Blender的界面，只需要让编程Agent写一段脚本。

blender -b --python modeA.py -- in.glb out.glb

脚本里三件事：bpy.ops.import_scene.gltf导入、加修改器或建骨架、bpy.ops.export_scene.gltf导出。要出图的话再加一步渲染。这一节所有Blender截图也是脚本截的，用的是Blender自带的bpy.ops.screen.screenshot，整窗口一次拿下。

让Agent写这种脚本，我的经验是把三件事在需求里说死，剩下的它能自己搞定。

还有一条边界要先知道：--background下没有OpenGL上下文。bpy.ops.render.opengl()会直接报Cannot use OpenGL render in background mode，所以视口叠加层那一整套都拿不到：线框overlay、左上角的统计信息、Loop Cut的黄线，一个都没有。要「能认出这是Blender界面」的画面，只能开前台录屏；无头能给你的是干净的渲染结果，没有系统边框、没有鼠标、没有菜单栏。我这一节的线框图是用Wireframe修改器把每条边变成真几何渲出来的，面数标签是事后用PIL画上去的。先知道这条边界，就不会花半天去调一个不存在的开关。

还有一条是验收习惯：截图脚本报的OK，判据要是文件大小而不是退出码。我的shot()函数里写的是os.path.exists(p) and os.path.getsize(p) > 10000。Blender在无头或者窗口没画完的情况下能写出一个几百字节的空PNG，退出码照样是0。

FBX转GLB：本机已有Blender，这道转换就走它

P2.0带贴图的产物只给FBX，而浏览器只吃GLB，中间必须过一道转换。我选Blender的理由是「我这台机器上当时装了的只有它」，不是「只有它做得到」。后面那句我没有资格说，因为要说它得先把别的方案一个个试过，而我一个都没试。

我当时探的那一圈是这样：assimp没装、pygltflib没装、gltf-transform虽然好用但它只吃glTF，读不了FBX。而Blender 4.4.3就在/Applications里，--background --python可跑，不用再装一个新东西、不用再验一遍它认不认这批文件。

还有一条更硬的理由：这批FBX的Creator字段写的就是Blender的FBX IO。也就是说文件是Blender导出的，那就用同一个实现读回来，轴向和单位的往返最不容易出岔子。

三通道包围盒交叉核验

转换有没有把模型弄坏，最怕的是「看着挺对」。我用了三条互相独立的路径去算同一个世界包围盒：

三者最大偏差1.0e-08。这个数字的意思是：三条路算出来的是同一个东西，转换没有偷偷改尺度，也没有偷偷改轴向。

为什么盯着包围盒不放，因为真正会把一整座城搞散的就三件事，而它们全落在这一个可测量的量上：Y必须是上轴（引擎里缩放系数是目标高度 / size.y，上轴错了尺寸直接乱套）、长宽高比不能变（等比缩放，比例变了模型就变胖变瘦）、绕Y的朝向要和被替换的旧件一致。而绕Y转90度会让X和Z互换，所以包围盒这一条顺带把朝向也兜住了一半。

顶点数从5,381涨到11,617是UV和法线接缝拆点的正常结果，不是转坏了。这一条我要标一句：涨了2.16倍我没有再去查是不是拆多了，因为26件合计约30万顶点，在预算内，所以没深究。

命令长这样，一件一条，跑完脚本自己把核验跑完并打分，全绿才返回0：

python3 fbx2glb.py taxi-p2-smartmesh-textured.fbx \
    -o out/car-01-taxi.glb --yaw -90 --dump-texture

--dump-texture会把降采样之后的贴图另存一张PNG，用来肉眼确认没糊没坏。这一步别省，数字全对而贴图糊了的情况是存在的，数字看不出来。

三个不打开GLB的JSON就发现不了的坑

这三个都是我在这条管线上踩实的，共同点是：模型渲出来一模一样，你只有去读那个JSON才知道出了事。

一，use_backface_culling的语义是反的。Blender的FBX导入器默认不开背面剔除，导出成glTF就是doubleSided: true，每个三角形正反两面都要跑一遍片元着色，片元开销直接翻倍。我那38件全中招，而且和巴黎demo里现有的件全不一致。修法只有一行，但符号要摆对：

mat.use_backface_culling = not double_sided
# use_backface_culling = True  →  glTF 的 doubleSided = false

薄片类资产（招牌、树叶、旗子）是真需要双面的，那些要单独开。判据是「这件东西有没有厚度」，不是默认值。

二，Blender会在FBX旁边建一个<文件名>.fbm/目录。那是它解包内嵌贴图的地方，你以为只是读了一下文件，其实它往你的素材目录里写了东西。我的脚本因此先把FBX复制进临时目录再导入，跑完就删。凡是「只读」的操作里藏着写动作，都值得记一笔，因为它会在你完全没预期的时候污染原始素材目录。

三，替换贴图不能「所有槽位都换成第一张图」。我第一版就是那么写的，因为P2.0那件只有一张base color，怎么写都对，看不出问题。换成一件带normal和ORM的FBX，它会把法线图也替成颜色图，然后你会得到一个表面凹凸完全乱掉、但不报任何错的模型。现在的写法是按原图名一一对应，对不上直接报错退出。

一句话

Blender在这套流程里的位置，不是「专业人士的必经之路」，是「AI暂时做不到那一层的补齐」。它补的是绑定、动力学、面部和hero级精修，而不是减面和压缩。哪一层AI补上了，Blender在那一层的价值就退一步。Tripo自带绑骨从20积分把41关节交到你手上这件事，本身就是这条边界在移动的证据。

§14 Unity：把资产搭成一座会动的园区

Unity — Ten Traps Between a GLB and a Playable Build

一座游乐园，六座设施，从Tripo的GLB到55秒巡游片、51 MB网页版和191 MB原生可玩版。中间十个坑，其中一个的根因对任何用glTFast的项目都成立。

这条路给你什么，要你付什么

星光游乐园这条线，最早是Three.js版，最后落在Unity上。换过去的理由只有一个：要出片。Unity能给你实时阴影、后处理、定帧渲染和一个能双击就玩的原生应用，这几样在浏览器里要么没有要么很贵。

代价是十个坑。我按踩到的顺序写，前面几个是「资产进不来」，中间几个是「进来了但不对」。编号只到十，但十个之后还有五件同等量级的事——构建成功却启动即崩、角色发白、WebGL体积、出片管线、镜头连错三次——它们各自太大，所以单独起了标题，没挤进那个编号里。

先交代版本，因为Unity 6改了两个名字，照着旧教程会找不到东西。我用的是Unity 6000.0.83f1，GLB导入走glTFast 6.0.1。

分工原则：这条是整套东西的骨架

在四冲程发动机那轮验证过的判据，在游乐园这里照样成立，而且游乐设施天然就分得开。

判断标准一句话：这个件错了，别人一眼能看出「机构不对」吗？能，就写代码。这条判据的完整推演在§15。

换成给玩家的说法更直白：会被凑到跟前细看的东西用Tripo做，只会远远瞥一眼的，代码画就够了。游乐园这张表就是这条判据的逐行落地：木马、吊舱、飞椅是Tripo，转它们的那个圈、那条轨道、那根转轴是代码。

本轮新生成的Tripo资产六件：旋转木马、摩天轮吊舱、旋转飞椅、旋转茶杯、鬼屋、海盗船，参考图由Codex批量出（8张串行约11分钟，全部成功）。树、长椅、花坛、喷泉、广告柱、摊位沿用巴黎那轮。

坑一：Tripo的GLB比例是归一化的

这个坑极具迷惑性，因为它长得不像比例问题。

每一个Tripo导出的GLB都被归一化到最长边约等于1.0单位。下面这组是实测的高度值，注意它们并不都是1.0——因为撑满1.0的那条边未必是高：

eiffel-tower 1.0000 / haussmann 0.9096 / carousel 0.9973 / teacup 0.5037
bench 0.5491 / walker-rigged 1.0000 / tree-green 1.0000

解析包围盒能看清这件事：铁塔是0.686×1.0×0.687（高撑满），长椅是1.0×0.549×0.413（长撑满），出租车是0.522×0.570×1.0（深撑满）。引擎里scale = 1直接摆，等于把每栋楼当成一米大。表现出来是「东西都对，但看着很怪、很空、像个模型展览」。你会去调光照、调材质、调后处理，怎么调都不对，因为根因是比例。

正确做法四步：实例化后先量包围盒；s = targetHeight / bounds.size.y；摆位时把底面压到地面pos.y -= bounds.min.y * s；宽扁件（车、长椅）按最长边归一，不按高度。

验收信号很好记：给58米算出来的缩放是×58，说明原始就是1.0，你数对了。

坑二：glTFast默认不带meshopt解码器

症状会把你带到完全错误的方向。GLB文件明明在磁盘上、.meta也生成了，但AssetDatabase.LoadAssetAtPath<GameObject>()返回null，日志只说「找不到资产」。

真相藏在.meta里，那是唯一给线索的地方：

reportItems:
- type: 0
  code: 20
  messages:
  - EXT_meshopt_compression

能正常导入的模型，这一项是reportItems: []。

根因是Tripo的CDN上tripo_pbr_model_<uuid>_meshopt.glb这个变体带EXT_meshopt_compression，而我的工程里没有meshopt解码器，ScriptedImporter直接判导入失败。说清楚一点：glTFast本身是支持这个扩展的——官方功能表上写着「✅ via package」，4.4.0起装com.unity.meshopt.decompress就会定义MESHOPT宏、走解码路径。所以准确的说法是「默认不带解码器」，不是「解不开」。装那个包和本地解压二选一，我选了后者，理由在下面。

修法是在本地解掉再喂Unity：

npx --yes @gltf-transform/cli copy in.glb out.glb

copy会走一遍完整的读写流程，出来的文件只留下KHR_mesh_quantization，Unity那边直接就能导入。我选这条而不是装解码包，是因为它把问题挡在工程外面：22个GLB一次处理干净，谁拉这个工程都不用先装对一个包。要是你的管线天天从Tripo拉新模型，装com.unity.meshopt.decompress更省事。

坑三：批处理里新GLB要跑两遍

-executeMethod跑的时候，新拷进来的GLB还没被导入。在方法开头加AssetDatabase.Refresh()不够，glTFast的导入是延迟的，而批处理里没有帧循环等它完成。

跑两遍就好：第一遍触发导入，第二遍资产就在了。我的构建脚本里这条是写死的。

坑四：把Light加在root上，整个物体会被挪走

var root = new GameObject("FerrisWheel");
root.transform.position = c;                    // 摆到 (-42, 0, 66)
var rimLight = root.AddComponent<Light>();      // ← 灯加在了 root 自己身上
rimLight.transform.localPosition = new Vector3(0f, hubY, 0f);
//         ^^^^^^^^^^^^^^^ 这就是 root.transform，整个轮子被挪到 (0, 17.5, 0)

这个bug最难查的地方在于它不报错。场景里有一个完整的摩天轮，只是它不在你以为的地方。我一度以为是相机机位写错了。

诊断方法：不要猜，直接打印。

var fw = GameObject.Find("FerrisWheel");
var wb = new Bounds(fw.transform.position, Vector3.zero);
foreach (var r in fw.GetComponentsInChildren<Renderer>())
    wb.Encapsulate(r.bounds);
Debug.Log($"root={fw.transform.position} "
        + $"包围盒 center={wb.center} size={wb.size}");

打印出来root=(0.00, 17.50, 0.00)，一眼定位。灯要挂在子物体上。

坑五：圆柱体的轴是Y，转90度的账要算对

Unity的PrimitiveType.Cylinder轴向是Y。绕Z转φ之后轴指向(−sinφ, cosφ, 0)。摩天轮的辐条要沿半径，所以φ = θ + 90°；外圈要沿切线，所以φ = θ。

我把这两个的90度弄反了，整只轮子炸成一把乱插的棍子。这是个看着像玄学、其实是三角函数的典型，算一遍就清楚了，别靠试。

坑六：前向渲染下，一个物体吃得下几盏像素光是有上限的

一座140×150米的园区，地面铺成一整块的时候，这块地面是一个物体。Unity只会挑几盏灯去逐像素照它，58盏路灯里绝大多数对地面毫无贡献。表现是「灯全开了却还是一片黑」。

正解的道理是：灯的位置本来就是我自己算出来的，那就不该让引擎去实时算。共享一份LampPositions()，地面贴图按它画光池、实际摆灯也用同一份，两者永远对得上。实体点光只负责照亮树和设施这些立在地上的东西。

光池衰减用1/(1+(d/r)²)，叠加时取max而不是相加（相加会在灯密处糊成白团）。光池半径R=13.5m是试出来的。和它配套的那几个后处理参数，请按字段名对，别按数字记：最后落在构建脚本里的是Bloom的intensity 0.38、threshold 0.92，以及ACES之后的postExposure 0.25（少数几个导演机位会把它单独抬到0.65到1.15）。这几个都是Post Processing Stack v2的字段，URP的Volume里名字和取值范围都是另一套。

坑七：Bloom的阈值才是那个开关

threshold = 0.72意味着比0.72亮的东西全都发光，连被照亮的墙面也一起炸，整个画面糊成一片白。夜景里只有灯泡和灯带该发光。

阈值给到0.92，只让真正的高光炸开。这一条比intensity重要得多。（同样提醒一句：threshold是PPSv2里Bloom的字段，URP的Volume版Bloom虽然也有一个阈值，但它和整条曝光链的关系不一样，0.92这个数搬过去不保证还是同一条界线。）

坑八到坑十：三个小的

中文文件名在macOS上会被NFD归一化。我写过一个「渲染成中文名再复制成ASCII名」的自校验脚本，结果排序时旧图把新图覆盖回去了（03-高处俯瞰.png的Unicode码位排在03-俯瞰全园.png之后），白看了两轮旧截图。修法是渲染直接出ASCII文件名。

静态渲染里Update不跑。编辑器模式渲染时MonoBehaviour.Update/LateUpdate不会执行，所以旋转木马和摩天轮在静帧里是静止的、走路角色是T-pose。这些都是正常的，不是bug。要出带动作的帧得进Play模式。

glTFast导入的动画clip是子资源，播放不需要AnimatorController。它会把preset:biped:walk作为AnimationClip子资源挂进来，AssetDatabase.LoadAllAssetsAtPath能枚举到。用Playable直接推给Animator：

using UnityEngine.Playables;    // ← PlayableGraph
using UnityEngine.Animations;   // ← AnimationClipPlayable / AnimationPlayableOutput

_graph = PlayableGraph.Create("Walker");
var playable = AnimationClipPlayable.Create(_graph, clip);
var output  = AnimationPlayableOutput.Create(_graph, "anim", animator);
output.SetSourcePlayable(playable);
_graph.Play();

三个必须知道的点。第一，using是两条不是一条，而且这三个类型分在两个命名空间里：PlayableGraph在UnityEngine.Playables，AnimationClipPlayable和AnimationPlayableOutput在UnityEngine.Animations。只加后面那一条，PlayableGraph.Create这一行就是CS0246找不到类型，而报错指的是行、不是命名空间，很容易以为是包没装。第二，PlayableGraph字段要标[System.NonSerialized]，它含指针，不能让Unity序列化。第三，自定义的数据类要标[System.Serializable]，否则存进场景后构建出来是空的。

那个最坏的失败：构建成功，启动即崩

构建出来的macOS应用启动就崩，日志只有一句：

The file '.../Data/level0' is corrupted! Remove it and launch unity again!

level0是构建产物里的序列化场景文件，三个构建的level0都约1.0 MB、没有截断。

根因：场景文件里被写进了内联MonoScript。Assets/Park.unity里41个m_Script引用中，有27个是没有guid的纯fileID形式，指向场景文件内部的8个!u!115 MonoScript块：

--- !u!115 &140919112 ---
MonoScript:
  m_Name:                        ← 空
  m_ClassName: ThirdPersonCamera
  m_AssemblyName: Assembly-CSharp

正常Unity场景永远不该内联MonoScript，它只应存在于.cs资源的导入产物里。m_Name为空是「脚本对象已创建但资产注册未完成」的特征。触发条件是批处理里「编译脚本 → AddComponent → SaveScene」跑在同一个进程里，而中招哪些类是竞态：同一份代码，12个Spin安然无恙，另外8个类全中招，两次构建的中招集合还不一样。

验证一个构建产物，「进程还活着」是最弱的一级证据。正确的判据是三条同时看：运行日志里的装配和警告计数、应用自己截的图、组件数量对账。

解法是把场景里的自定义脚本清零：

场景文件里没有任何自定义脚本引用，就没有可损坏的引用。清单存的是层级路径不是名字（同级会重名），而且必须在重挂父级之后才记录路径，否则运行时找不到。

构建链上还加了一道闸门ParkVerify.SceneIsClean()，检查场景里有没有无guid的m_Script或内联!u!115，命中就报错并中止构建。宁可构建失败，也不要产出一个「构建成功、启动即崩」的app。

角色发白：根因不在灯，在角色

这条我判错过一次，值得记。

网页版和巡游片里所有行人和主角都是发白的白色人形，肉眼一看就是坏的。我第一轮的处理是调灯（路灯5.2降到2.1、曝光0.38降到0.26），然后判定「站在灯正下方仍偏亮属于可接受的夜景表现」。

复核推翻了这个判断。根因是角色本身：Tripo出的这个角色是白T恤加浅灰裤，基色贴图均值0.58，而长椅是0.18、树是0.44。同一套灯光下它比别的东西亮三倍，再过一遍曝光、ACES和Bloom就成了白影。

修法不动灯光，把角色材质克隆一份存成独立材质，基色乘0.5、粗糙度拉满、金属度归零。

WebGL体积：165 MB压到51 MB

第一版WebGL构建165 MB，其中WebGL.data一个文件就152 MB。源GLB一共才58 MB，构建出来却是152 MB，还是brotli压过的。

量了贴图才明白，而且这笔账要按张数数，不能按件数数。六座游乐设施每件挂三张：基础色是8192×8192，法线和ORM各是4096×4096，一件合计1.007亿像素；六件就是18张、6.04亿像素。加上园区里另外十六件（十五件是三张1024²，只有citroen-2cv那件是三张4096²），22个GLB的贴图总量是7.01亿像素。一张8192²在Unity里按RGBA32展开是268 MB，七亿像素全摊开是2806 MB，带上整条mipmap链（×4/3，口径和§12那笔账一样）约3.7 GB。源文件里这些图是JPEG，所以在磁盘上不占地方，进了构建就全摊开了；brotli回压到152 MB，量级对得上——这是一个量级判断，不是逐字节对账。

引擎侧没有开关，就在源文件上处理。贴图名字带槽位标识，可以分开定尺寸：

R="npx @gltf-transform/cli resize"
$R --width 512  --height 512  --pattern "*ormal*"  in.glb t1.glb
$R --width 256  --height 256  --pattern "*ORM_*"   t1.glb t2.glb
$R --width 256  --height 256  --pattern "*_rm"     t2.glb t3.glb
$R --width 1024 --height 1024                      t3.glb out.glb

分配逻辑：基础色1024（决定观感，给足）、法线512、金属粗糙度256。基础色1024对1080p输出是3倍过采样，木马在画面里最宽也就640像素。

这四行有两个坑。--pattern是glob而且大小写不敏感，*ORM*会把NormalGL_...一起命中（「Normal」里有「orm」），法线也被压到256；改成*ORM_*（带下划线）才分得开。resize只会缩小、不会放大，所以必须先做小尺寸的pass、最后做兜底的大尺寸pass，顺序反了没法补救。

「贴图总像素」那一行是从22个GLB里逐张读图像头加出来的，66张一张不落，不是估的。降完之后是31.3 M而不是22×1.376 M＝30.3 M，多出来的那1 M有个具体出处：haussmann那件的ORM贴图名字既不含ORM_也不以_rm结尾，两条--pattern都没命中它，最后落在兜底那一档被定成1024²而不是256²。按名字分槽位就得接受这个：名字不守规矩的那几件会漏网，而它不报错。

原始8K模型单独备份着，要出更高规格的版本可以回到那一份。

出片管线：把已经在跑的东西录下来

园区里的东西本来就在动。静帧传达不了这一点，所以出片不是「加个渲染」，而是把已经在跑的东西录下来。

三个关键决定。

用Time.captureFramerate定帧，不用实时录屏。它让游戏时间按固定步长走、与真实帧率脱钩，每一帧都是确定的。实时录屏会因为掉帧而抖动，而这台机器的帧率并不稳定。

渲到RenderTexture再读像素，不走ScreenCapture。后者只能截屏幕分辨率（这台机器是3024×1898），出不了标准1920×1080。

存JPEG不存PNG。1080p一帧PNG约2 MB且编码慢一个数量级，JPEG(q93)约300 KB。一千五百多帧，PNG要3 GB，JPEG只要450 MB。（定稿55秒×30 fps＝1650帧；源记录里那条-frames 1515是中间版本留下的。）

open -a Build/Park-Play.app --args -logfile /tmp/vc.log \
     -capture /tmp/frames -cine -frames 1650

ffmpeg -y -framerate 30 -i /tmp/frames/f%04d.jpg \
  -c:v libx264 -preset slow -crf 17 \
  -pix_fmt yuv420p -movflags +faststart out.mp4

镜头编排连错三次，三个不同的盲区

同一件事我错了三次，每次错法都不同，所以记下来。

错法一：分镜里漏了资产。第一版10个镜头里没有海盗船，因为列机位的时候它还不存在，我凭记忆列，记忆里就没有那个还没做出来的东西。列分镜要把所有资产过一遍。

错法二：镜头路径穿过实体。把海盗船排在摩天轮之后，两者相隔46米，而镜头位置是线性插值的，它不会绕开几何体。结果那5秒里镜头从船体正中穿了过去，画面全是木板。「两点之间直线最短」在镜头编排里是缺点不是优点。

错法三：看向点跟着位移一起插值，镜头全程在甩头。这是最难发现的一个。

float er = SmoothStep(Mathf.Clamp01(u * 1.9f));      // 先转头
transform.position = Vector3.Lerp(a.pos, b.pos, e);  // 再位移
Vector3 lookAt = Vector3.Lerp(a.look, b.look, er);
transform.rotation = Quaternion.LookRotation(
    lookAt - transform.position, Vector3.up);

看向点要跑得比位置快，而且朝向要每一帧从当前位置朝当前看向点重新解算。先转过去对准主体、再推近，这才是运镜；插值两个四元数只是甩头。

还有一脚：应用失焦后暂停，录到第194帧卡死了63分钟。Unity应用默认runInBackground = false，一失焦整个应用就暂停。这和浏览器里后台标签页rAF被暂停是同一类问题：宿主认为你不在前台，就停掉你的渲染循环。两层都要修：应用内设Application.runInBackground = true，外面用caffeinate -dims防App Nap。

发布：WebGL目录扔上去就行

构建用的是Brotli加decompressionFallback，加载器自带JS解压，不要求托管方为压缩文件配Content-Encoding头，Vercel、Cloudflare Pages、GitHub Pages都能直接扔整个目录。

产物文件后缀是.unityweb而不是.br。判断它到底压没压，看文件头：

xxd -l 40 Build/WebGL/Build/WebGL.data.unityweb
# 00000000: 6b8d 0055 6e69 7479 5765 6220 436f 6d70  k..UnityWeb Comp
# 00000010: 7265 7373 6564 2043 6f6e 7465 6e74 2028  ressed Content (
# 00000020: 6272 6f74 6c69)…                          brotli)

注意要取40字节，head -c 32只会截到左括号为止，看不到brotli。

§15谁负责哪一层

Who Owns Which Layer — A Relay, Not a Race

一条能让你当场决定「这件事交给谁」的分工线：资产交给3D生成，规划和组装交给coding agent。再加一条只有一句话、但我整本书都在用的取舍判据，和一份诚实到写了「没测」的分层诊断。

那个问题本身问错了

做这本书的过程里，我被问得最多的一句是「Tripo和Blender谁强」。偶尔换个版本：「有了AI生成还要不要学Three.js」。

这个问题有个陷阱。它们在流水线的不同环节上，压根不在一个赛道。问谁强，就像问钻头和螺丝刀谁强。

但我把巴黎、游乐园、小王子这三条线全部做完之后，发现连「几个工具之间怎么排」都不是最该先问的那一层。真正把人卡住的分界在更前面：一边是资产，一边是把资产变成一个能玩的东西。这两件事的性质完全不同，需要的能力也完全不同。

接力：资产只是一半

我在片子最后说的那句判断，是这一整节的地基：

不是替代关系，是接力关系。接力棒从左往右传，两棒解决的问题完全不一样，谁也替不了谁。

「只是一半」这四个字不是客套。巴黎那23件GLB躺在硬盘上的时候，它们什么都不是：没有比例、没有碰撞、没有摆放规则、没有可视距离分级，甚至没有一个统一的朝向。把它们变成一座能开着车穿过去的城，是另一件完全独立的活，而那件活是coding agent干的。

反过来也一样。第二棒再强，手上没有像样的资产，做出来的就是一堆方块。我那座城在换掉行道树之前，抬头看到的是一排深绿色的积木（§17那两张对比图），代码再怎么写也长不出树皮和叶片的层次。

这本书的编排其实就是照这个顺序来的：§01到§14在讲怎么跑好第一棒，§16到§19在讲第二棒怎么把接力棒接住。这一节是中间那个交接区。

你会开到跟前细看的，才值得生成

知道了有两棒，下一个问题马上就来：具体到场景里的每一个东西，它该走第一棒（生成一件资产），还是根本不用走，直接让第二棒用代码画出来？

这条判据是我做完整座城之后能给出的、唯一一条可以照抄的工程判据：

它好用是因为它把一个技术问题翻译成了一个玩家视角的问题。你不需要先懂三角面预算、不需要先懂draw call，你只需要问：玩家的脸会不会凑到这个东西前面去。

巴黎那座城真实的归属是这么分的，我在片子里也是这么说的：

所以这不是一整座城都是AI建模出来的，真实情况是混搭的。这句话我在片子里专门留了一拍来说，这里也要留一段来说，因为它是这整套方法能不能被复制的前提。看一个漂亮的demo然后以为「它整个是AI生成的」，照着做一定会撞墙：你会为了铺满一座城去生成上千件模型，钱、时间、帧率三样一样都不够。

注意卢浮宫和圣母院这两个例外。它们是地标，按理说该生成，但玩家在我这条赛道上只会从河对岸掠过，所以它们被划到了「远远瞥一眼」那一侧。判据认的是玩家的实际路线，不是这个东西在现实里有多重要。

这条判据的第二次兑现是在游乐园那条线上，而且分得更干净：木马、摩天轮的吊舱、飞椅、茶杯、鬼屋是Tripo生成的，转的圈、轨道、转轴这些结构件是代码写的。游客的脸会贴到木马上去看鬃毛，但没人会去数摩天轮那一圈钢架的接头（那一轮的完整分工表在§14）。

三件工具的真实位置

把接力棒的路径摊开，中间会经过的几件东西就各就各位了：

三者摊开成一张表就没什么可争的了。最后一行是我建议你真正记住的那一行，它写的是交接时你要自己付的账。

Blender在这张表里的位置值得多说一句。它不是必经的一站，而是第一棒的返修车间：需要绑定、需要动力学、需要面部的东西才拐进去，其余的直接往第二棒传。我巴黎那批资产一件都没进过Blender。

结合使用的三种真实模式

框架讲完，问题就变成「我这件活走哪条」。实际跑下来只有三条。

模式A：Tripo → Blender → 引擎

角色走这条。需要绑定、需要动力学、需要面部的东西，绕不开Blender那一棒。X上做角色的创作者普遍是这么干的：Tripo分别生成头发、头、身体，然后在Blender里合并、绑定、做摇摆物理，半天做完一个角色。

模式B：Tripo → 引擎直连，跳过Blender

这条是我自己验证的。巴黎那23件资产，建筑、道具、载具、行人、地标，生成完直接导GLB、压缩、进Three.js，全程没有经过Blender。

实证结论：对场景类资产，这条路完全走得通。我由此省掉了整个Blender环节。

边界条件也是实测出来的三条。面数要压，Tripo默认输出1.6到1.8万三角面，装进Web场景必须减面加压缩。减面有下限，我那两棵巴黎梧桐压到7473面就交付了，再往下分枝拓扑就崩（各类资产的减面下限见§04；这两棵是09-10那版，后来被P2.0的七叶树换掉，见§18）。贴图档位影响近距离观感，我选的1k档，凑到墙上看会糊。

模式C：AI生成+程序化混搭

这是最容易被忽略的一条，因为它不是「用不用AI」的二选一，而是上面那条判据在同一个场景里同时落两次。

巴黎全城近景行道树用Tripo生成的GLB替换，中景、远景和公园球冠保留程序化几何——近景要细节，远景只需要「那儿有个绿色的东西」，而AI模型的面数成本撑不住两万株的量。替换前后的对照图和这笔面数账在§17，集成时踩的坑在§18。

量化的账在§13：14栋高细节Tripo建筑的总代价是多17个draw call、多15%三角面，帧率完全没掉。用15%的三角预算买下赛道沿线全部的高细节，其余程序化铺满。

同一个场景里，代码和AI怎么分

「跟前细看还是远远瞥一眼」管的是距离。还有一类东西距离很近、但照样不该生成，那就是尺寸必须精确的件。

四冲程发动机那轮给出了这条补充判据（那台机器本身、以及我花50积分生了一根曲轴又放弃的经过，在§20）。那台机器的零件来源是这么分的：

两条判据合起来，覆盖面就完整了：先问玩家会不会凑近看，再问它错了会不会被一眼看穿。前一条管画面预算，后一条管正确性。巴黎那座城里的桥面高程、街廓碰撞、路网走向全部落在后一条上，所以它们哪怕就在车轮底下，也照样是代码算的。

七步变四步，省掉的是哪几步

第一棒内部还能再拆细一点。行业里讲这件事常用的拆法是：传统流程里一个角色从概念到进引擎要走七步，AI流程是四步。（下面这张表是行业通用口径，不是我自己的实测；我没有请一位熟练模型师来跑对照组。）

被压掉的三步是高模雕刻、低模拓扑、展UV。这三步恰好是最需要手上功夫、也最消磨人的三步。

但注意「收尾看要求」这五个字。压掉三步不等于那三步的产出不再需要，只是它们的质量由模型给你定了，你要么接受，要么回Blender自己收。我在E3和E4里测到的碎片化、权重塌，本质上就是「低模拓扑」这一步被跳过之后留下的账。

独立评测普遍提到AI网格的几条技术特征，和我自己测出来的能对上：多边形分布均匀、不集中在细节密集区；边环不贴合解剖结构，做动画时容易挤压变形；手指、耳朵这类复杂区域有n-gon和捏缩顶点，UV有接缝；高精度档直接导进引擎会严重拖帧，必须再优化。这几条都有对应的绕法，分别在§04、§06、§12里。

最后那条我在§14量到了具体数字：六个8K贴图的资产让WebGL构建从51 MB膨胀到165 MB。这就是「引擎调整」那一步没有消失的证据。

接力棒掉在地上的三个地方

接力赛真正丢时间的地方从来不是某一棒跑得慢，是交接。这套流程里有三个交接面，每一个都有固定的成本。

这三张账单加起来，比任何一棒本身的耗时都长。知道它们存在，比知道哪个工具更强有用得多。

卡在哪一层：一份带「没测」的诊断

「AI能不能做3D角色」这个问题，答不出「能」或「不能」。我把它拆开一层一层判，判到哪算哪：前五层有结论，第六层是边界。

第2层拆成两行，是因为它在我这里出过两个相反的结果，而两个都对：同样是一辆AI生成的车，用几何的刀切不出轮子，用语义的刀切得出来。连通分量只认「这堆三角形彼此连着吗」，而AI生成的网格本来就是一层碎壳，轮胎和挡泥板之间根本没有几何缝；语义分件认的是「这块是什么」，所以它能在没有缝的地方划一刀。这两行的差别，正是§05那一节存在的理由——如果只看2a那一行就收工，你会得出「轮子转不了」这个错结论，而它只是「别用那把刀」。

关于「AI做不到的那一层」，一条我决定不当论据用的话

调研时我拿到一段转述，说VAST的首席科学家在一次访谈里划过一条边界：环境道具、场景组件、简单NPC、载具已经接近可直接使用；核心角色和复杂动画，尤其是面部和动力学绑定，仍是下一阶段最难解决的门槛。

这段话和我那六层诊断的结果吻合得有点好，正因为如此我更要说清楚它的来路。

能自己测出来的，就不要靠别人的一句话。

那我到底该用哪个

把这一节压成四句话，贴在你工位上。

拿不准的时候，问自己这五句

上面四句是大方向。具体到手上这一件东西，我用的是这五个问题，按顺序问，问到哪停在哪。它们其实就是前面那两条判据的展开。

五个问题里没有一个问「哪个工具更强」。问题永远是「这件活属于哪一棒」，工具是答案的副产品。

还有一句是留给不会写代码的人的，也是这本书的前提：这两棒你都不需要亲手写代码。Tripo是点界面或者跟agent说人话；引擎那边的代码是coding agent写的。你要做的是知道这件活该交给哪一棒，然后把这句话说清楚。

这个判断本身没法外包。它是这一节全部的内容。

§16从选题到资产清单

From Topic to Asset List

这一节结束的时候，你手上会有一张表：这个项目需要几件模型、分成哪几类、哪些交给Tripo生成、哪些交给代码长出来。这张表是整个项目里唯一能在动手之前就写完的东西，也是后面每一步的依据。

先把话说在前面：这座城里只有23件是生成的

我最后做出来的东西叫「巴黎来信」：一座能开车的巴黎，有塞纳河、有24座桥、有竞速也有自由漫游，手机上能玩，打包成静态网站能发。

但这座城不是Tripo生成的。

Tripo生成的只有23件模型：铁塔、凯旋门、圣心堂、三台车、一批街边建筑、五个行人、几件街具。剩下的那些：1375个街廓、24座桥、6975米河道、河堤、双岛、游船和它拖出来的尾迹、水面反射，全是程序化代码生成的，来自我自己2026年8月做的另一个项目「巴黎3D地图」，地理数据源自OpenStreetMap，做过艺术化改编。卢浮宫、圣母院、圣礼拜堂也是代码画的，不是模型。

我把这条说在最前面，是因为它太容易被说糊。做完一个这样的demo，最省事的说法是「我用AI生成了一座巴黎」——那句话是假的，而且一旦说出口，读者照着做一定会撞墙。这条分工线本身就是这一章最值钱的内容，它决定了你要花多少积分、等多久、以及最后跑不跑得动。

还有一件事必须在这儿一次性说清，不然你往后翻会撞见三个不一样的数：23、25、29，数的不是同一批东西。

29比23多出来的6件，是第二批里生成并下载成功的那几件：三棵树、三件街具。其中只有两款梧桐最后接进了游戏（那就是25的来历），剩下四件躺在目录里没找到槽位。第二批清单上原本列了更多，但列在清单上和落到硬盘上是两回事，这一节后面会讲。

后来还有第三批，一口气40件，也就是本节开头那张总览图，后面单开了一段讲；它不在上面那三个数里的任何一个，因为29那一轮数面数的时候它还没生成。

这三个数各有各的量法，不能混用，也不用去凑一个「对的」数——它们回答的是三个不同的问题：装了几件、看得见几件、一共生成了几件。你自己做项目的时候也会同时有这三个数，提前知道它们会对不上，比事后去对账省事。

为什么是巴黎

选题这件事，我的判据只有三条，都很土。

第一条：观众不需要你解释它是什么。奥斯曼公寓的弧形转角、锌板孟莎屋顶、黑色锻铁阳台，加一座铁塔和一台雪铁龙2CV，画面里出现半秒钟就没人会问「这是哪」。做3D demo最怕的不是模型糙，是观众看了五秒还在猜你做的是什么地方。辨识度高的选题，等于你把讲解的预算省下来，全花在手感上。

第二条：风格能统一。巴黎的好处是它天然有一套配色：奶油色石材、藏青灰蓝屋顶、黑铁、黄铜。一批资产要批量生成，最怕的是每件单看都不错、摆到一起互相打架。一个有明确时代和色系的题材，等于提前帮你把提示词里的风格段落写死了（这一段怎么写，§09有完整模板）。

第三条：我手上已经有一半。前面提过的那个程序化巴黎城市层是我自己做的，能直接复用。选题的时候优先选你已经有一半材料的那个。说是偷懒也行，但省下来的生成预算全压在真正缺的那一半上了。

还有一条是我从市场数据里得到的，得单独说。做这个项目之前我扫过X上101条同题帖子，点赞过千的有87条。有两条结论直接影响了选题的形态。一是爆款的分界线在于观众能不能点进去自己玩：可交互作品更容易冲进最高那一档，静态渲染的高赞帖大量堆在1000到5000赞之间（这不等于静态一定输，纯Blender的别墅场景就拿过15061赞）。二是审美疲劳已经从高赞账号开始了，Greg Isenberg（@gregisenberg）那条3331赞的帖子原话是「我见过100多个人发GPT-6 Astra做3D游戏的demo，挺酷的，但老实说那不是我一直在想的部分」（https://x.com/gregisenberg/status/2096311243652952229）。

这两条合起来的意思是：再做一个「我也做了个3D demo」已经不新鲜，差异化只能落在分工、边界和真实成本上。所以这一章不只讲我做了什么，更多篇幅花在讲每一步花了多少积分、哪一步靠代码、哪一步AI做不到。

我动手前唯一的参照，是创作者海辛Hyacinth（@ring_hyacinth）的一个公开案例，原帖在这里：
https://x.com/ring_hyacinth/status/2096704996381266424
我当时给自己定的目标是做得比它更完整。但这句话到今天也只是目标，我没有统一量表，也没做过对照的用户测试，所以「提升1000%」「超过100%」这种话不能当实测结论。项目文档里我把这条单独写了一行，防止自己后来忘了。

那条线画在哪：会开到跟前的才生成

这是全书我最想让你记住的一条判据，也是我在片子里唯一拿出来让观众抄走的一条：

写清单的时候，这句话就是你的分栏依据。再补一条管正确性的：尺寸必须精确、后面要参与计算的件，哪怕它就在车轮底下，也归代码。

这条线在游乐园那一轮又原样走了一遍，而且因为游乐设施天然分得开，分得比巴黎还干净：木马、摩天轮的吊舱、飞椅、茶杯、鬼屋是Tripo生成的；转的圈、轨道、转轴这些结构件是代码写的。游客会趴到木马跟前看鬃毛和缰绳，但没人会去数摩天轮那圈钢架有几个接头；反过来，那个圈只要不是正圆，所有人一眼就看出来不对（那一轮的完整分工表在§14）。同一条判据，换个题材照样用。

为什么不能反过来？算一笔账就清楚了。那一批资产我实测下来是一件40积分（当时的账本记得很清楚：2190积分生成一棵树之后剩2150。40是4K贴图那一档，默认的8K档要50，整条阶梯在§07）。1375个街廓如果每个都生成，就是55000积分，专业版十八个月的额度。而且得排队等：2026-09-10做巴黎那批资产的时候（高精度模型、4K贴图那一档），我盯着其中一个生成任务过了20多分钟还没返回，当天的开发笔记里原样记着这一行——「生成很慢：一个任务实测20+分钟仍未完成（倒计时显示不准）」（paris-demo/迭代笔记-细节扩展-20260910.md）。这是单次观察，不是耗时基准，我没有第二笔复现，正经的耗时口径在§05和§07。界面上那个倒计时是估算，别把它当承诺：提交完就走开，Pro的10个并发是拿来一次丢一批、回头统一收的（§07）。不过真正让「每个街廓都生成」这件事不成立的，是上面那个数量级，等多久只是顺带。

更要命的是，生成出来的街廓没法用。街廓要参与碰撞计算、要和路网对齐、要按桥面实际高程放车，这些都需要精确的数值，而生成模型给你的是一坨好看的网格。尺寸件用代码、形体件用AI，这条分工不是成本妥协，是能力边界。

23件是怎么定下来的

我后来反复复用的模板是五分类：建筑池/地标/街道小品/人物/载具。巴黎这一批因为地标只有三件，我把建筑池和地标并成了一栏，落到纸上是四类。这套分法基本能套所有「AI生成城市场景」的需求，换个城市也一样用。

建筑池之所以要留9种，是因为它们要沿街循环复用。真正摆上赛道的是其中7种，代码里就是一行buildingKeys[i % 7]，轮着来，每种出现两次。开着车其实能认出来，这是当时一个明确的短板。

四类各挑一张输入设计图放在这里，你能直观看到风格是怎么统一的：同一段风格描述、同一个浅灰背景、同一个四分之三视角，只换「画面内容」那一段。

清单要先于生成写完

我的做法是：在跑任何一次生成之前，先把整张清单写成一个jobs.jsonl文件，一行一件。一个资产=一行JSON =一张设计图=一个GLB =一个文件名，全程不换名字。

文件名长这样：

这个前缀不是为了好看。后面批量清洗的脚本要按资产类型分配减面率，判断依据就是文件名前缀（pedestrian和car敢砍，building和tree保守）。命名规范在这里就是给脚本用的接口。§17会讲这个判断在什么情况下会判错。

清单不是一次写完的

第一批23件跑完、游戏能开起来之后，我做了一轮巡查，96张截图逐帧看。最刺眼的短板不是建筑不够精细，是树。全城1.6到2.3万株行道树全是程序化的深绿色方块，开在街上抬头就是一排绿色积木。

于是有了第二批清单，判据只有一条：哪个东西在画面里出现得最多、同时做得最差。

这张表列了12件，真正生成并下载下来的只有6件：三棵树，和华莱士喷泉、莫里斯柱、鸽子群这三件街具。剩下的卡在下载环节没落盘（长链接和批量下载的坑在§10）。这6件最后接进游戏的又只有两款梧桐，另外四件没找到能放的槽位。

所以这一批对三个数的贡献是这样的：给硬盘上添了6个独立网格（23变29），给城里添了2件（23变25），给清单上添了12行。但那两棵树带来的画面变化，比前面九栋建筑加起来都大。

第三批：一次补40件，能进城的只有8个槽位

第二批那几棵树把画面顶上去之后，清单又长了一轮。这一轮我换成智能网格（P2.0）批量重做，一口气出了40件，就是这一节开头那张总览图。分类和前两批一个路子，但缺口填得更准：

另外还有一个目录叫glb-1024-新，13件，装的是老槽位的重做版：面包店、花店、报刊亭、凯旋门、圣心堂、铁塔、出租车、载货三轮、西装男、绑骨行人、骑行者、长椅、咖啡馆门面。这一批不是新增内容，是同一个位置换一件更好的。

但这一轮最该说的不是40这个数，是40件里真正装进城里的只有8个槽位（行道树那件是另一条线单独换的，算第9个，过程在§18）。而且这几个槽位全是「换掉老件」，不是新开位置，所以前面那个25没变——城里能看见的还是25件，只是其中几件换成了更好的版本。剩下的躺在目录里等下一轮。原因有三类，每一类都是写清单时该预见到的：

三条合起来是同一句话：清单上的一行不等于一件能用的资产。我第一批23件之所以没踩到这些，是因为那批是「先画设计图、再按图生成」，图什么样模型就什么样；到了批量重做这一轮，件是先有的、槽位是后配的，中间就多出了一道对不上的风险。

这一节的产出

到这里你应该有三样东西：一张分四类的资产清单、一份写好的jobs.jsonl、一条画清楚的分工线（哪些生成、哪些代码）。下一节把这张清单变成能进引擎的文件：逐件生成、批量减面、归一化尺寸，以及我在这条流水线上踩的三个坑。

§17生成与清洗流水线

The Generate-and-Clean Pipeline

把§16那张清单变成能进引擎的文件，中间有四步：逐件生成、导出GLB、批量减面、归一化尺寸。这一节给你能直接复制的命令，以及我在每一步踩到的坑：一个「减面减不动」的下限，和一个让整排树糊成一片的缩放基准错误。

四步，最贵的那步是等

先给你一个心理预期：整条流水线里，真正吃时间的是第一步的排队，不是后面的处理。25个资产（§16那23件，加后来补的两棵梧桐）的批量清洗我实测跑完只要131秒，平均5.2秒一个；而生成那一步的耗时是会波动的，我盯过一个任务20多分钟还没返回（高精度模型加4K贴图那一档，出处和「这是单次观察不是耗时基准」那句在§16），界面上那个倒计时是估算不是承诺，正经的耗时口径在§05。

所以这条流水线正确的跑法是并行提交、串行清洗：生成那一步全部丢出去排队，等的时候去写游戏代码，模型陆续回来之后再一把清洗。

第一步：逐件生成

巴黎那23件走的都是网页版的「高精度模型」，一件一件提交。表单长这样：

首页生成入口见§01那张：传一张设计图，左边选高精度模型还是智能网格，右边按钮直接标着这次要花多少积分。

积分账我当时记得很细：生成一棵树之前账户是2190，之后是2150，一件40积分。40是4K贴图那一档的价，同一个「高精度模型」默认走8K就是50，几何底价固定15，差额全在贴图档上（2K 30 / 4K 40 / 8K 50，再开Ultra网格65），完整阶梯在§07。23件加上中途几次重试，开发笔记当时估的是700到800积分——那是估数不是逐笔加出来的，真要按40一件硬算会更高一些。无论按哪个口径，都不到专业版月度额度的三分之一，对一个中等规模的场景生产任务，额度是够用的，不用刻意省。

两个观察值得单独说。

一是成功率高得有点意外。23件用同一套「Codex出设计图 → Tripo图生3D」的流程跑下来，材质质感、比例、可辨识度全部在线，其中留了设计图、能照着复现的19件全部一次通过，没有一件因为明显失败要重跑（23和19这两个数怎么回事，§08里说清楚了）。

二是面数落在了一个很舒服的区间。这批资产普遍在1.5到2万三角面，直接就是游戏能用的量级，不需要再走重拓扑那道工序。但我不想把这个说成「面数可控」。准确的说法是默认值恰好落在可用区间，不是我主动调出来的。同样关掉超清几何精度，镂空精细的奥斯曼建筑天生92.7万面，结构简单的铁塔天生只有1.9万面。面数由对象本身的复杂度决定，不由你写的提示词决定（写「low poly」它也不听）。

资产页（图见§03）是并行提交之后的看板：卡片上标着每件已经等了多少秒，顶部那四个筛选，后面找模型全靠它。

第二步：导出GLB

导出弹层里只有三个选项要管：文件名、格式选GLB、贴图分辨率。

导出弹层见§03那张图。格式与贴图分辨率这两个选项在高精度模式下是一样的，贴图分辨率这里选1k，原因见下一段。

贴图分辨率在这一步就要降下来。Tripo默认导8192×8192，17件这样的资产实测吃掉5.0 GiB显存（＝十进制的5.38 GB，口径见§12），降到1024×1024之后是0.22 GiB。游戏视距下你看不出区别，但显存是实打实的。

导出这一步有两个和模型质量无关、但一定会拦住你的东西。一个是免费档的导出受限：官方对照表里Free那列的Exports原文是15 (H2.5 only)，同列的Private Models和Commercial Use都是❌，所以免费档能试质量、不能交付，全书统一口径见§07与附录C。另一个是浏览器的原生「另存为」对话框。如果你像我一样让AI agent代跑，那个系统弹窗是所有浏览器自动化工具的停手线，谁都不该替你点。解法是走API直链取GLB，完全绕开导出按钮，方法在§03。

第三步：批量减面

这一步是纯收益，没有理由跳过。我第一遍用的是统一参数：

npx @gltf-transform/cli optimize in.glb out.glb \
  --compress quantize --texture-size 512 \
  --simplify true --simplify-ratio 0.6

23个资产平均减重65%，37 MB压到13 MB，肉眼看不出画质损失。

--compress quantize这个选择是有理由的：量化不需要额外的运行时解码器，浏览器直接就能播；换成draco或meshopt，都要在Three.js里另挂一个WASM解码器，而在某些沙盒环境里那个解码器本身的加载就会失败。为了一点压缩率换一个可能加载不上的依赖，不划算。

减面的下限，由几何有多光滑决定

统一参数跑完之后我做了一个实验，想知道每类资产到底能砍到多少。方法是对11个资产各跑一遍：

npx @gltf-transform/cli simplify in.glb out.glb --ratio 0.1 --error 1

ratio从0.5一路试到0.02，记录面数不再下降的那个拐点。那张11行的减面下限表和它的完整读法在§04，这里不重抄；两个口径要交代：表里的「原始面数」指进这轮实验时的面数（都已经压过一遍，那棵梧桐的7473刚生成出来是18414面，见下面「树的三个坑」；奥斯曼建筑那行的41106，Tripo直出时是92.7万面）。

拿到流水线上来讲，这张表只有一个生产含义：减面率要按资产类型分配，不能一刀切。人体那类连续曲面砍得最狠，建筑上全是直角窗洞栏杆砍不动，树和铁塔几乎砍不动。判断函数和两条命令都在§04。

25个资产跑完的账与§04那张表相同：14600 KiB降到9433 KiB（减35%），总耗时131秒、平均5.2秒一个——那5.2秒大部分是npx的启动开销，不是计算。

这一轮也抓到一个反例：prop-03-planter按前缀判成道具、给了0.25的激进比例，结果只减到7652面。它叫prop，几何却像建筑，花坛全是直角结构。文件名前缀是个够用的近似，但它会判错，判错的表现就是「明明给了激进参数却没减下去」。

树的三个坑

梧桐是整批资产里最难处理的一件，三个问题一个个来。

坑一，optimize子命令里的--simplify对它不生效。必须用独立的simplify子命令，并且带上--error参数，减面才真的发生。

坑二，减面有硬下限。18414面用meshoptimizer最多减到7473面，ratio 0.1和0.05的结果一模一样，再减就破坏分枝拓扑。这和上面那张表里95.3%那一行是同一件事。

坑三，三角面预算会爆。城市层原来用程序化实例画树，全城2万株只占9个绘制调用、8.4万三角面。按它原来的近景实例上限直接换成15000面的GLB树，光近景这一档就是225万三角面，是整层预算的26倍。当时的做法是近景只放36株GLB树、中景和远景继续用程序化，这是画面和帧率之间唯一走得通的折中。这个36后来提到110，实测几乎不花钱，见§18。

第四步：归一化尺寸

这一步最容易被跳过，也最容易在集成那天炸给你看。

生成出来的GLB，每一件的尺寸基准都不一样：有的模型原点在几何中心，有的在脚底，整体高度也是随机的。引擎那边要的是一个统一契约。我给城市层定的契约是两条：y=0落地、整体高度归一到1个单位，之后由引擎按真实米数缩放。代码就这么几行：

const box = new THREE.Box3().setFromObject(g.scene);
const size = box.getSize(new THREE.Vector3());
const center = box.getCenter(new THREE.Vector3());
geo.translate(-center.x, -box.min.y, -center.z);   // 水平居中、脚底落到 y=0
geo.scale(1/size.y, 1/size.y, 1/size.y);           // 整体高度归一到 1

然后我踩了这一节最丢人的一个坑：缩放基准选错了。

GLB树的宽高比接近1比1，而原来的程序化树是「宽8高11」的瘦高个。我一开始按整树高度等比放大，冠幅直接放到14米，而巴黎行道树的间距只有8米。结果就是整排树的树冠彼此重叠，糊成一堵绿墙。改成按冠幅缩放（高度系数1.2，冠幅落到8.4米）才对。

同一个坑的第二种长法：包围盒一样，几何不一样

后来批量替换资产的时候，这个坑换了张脸又来了一次，而且这次更阴。

新的咖啡露台套件要去替换街上那套咖啡桌椅。两件包围盒的比例看着都正常，但新件比旧件多了一根两米高的户外取暖伞。引擎按包围盒总高归一化到1.1米，于是桌椅从1.1米掉到约0.5米，旁边就站着1.72米的行人。

发现它的办法不是肉眼看，是量顶点高度的分布：

这件最后没换。要换的话也只是一行的事：把那个槽位的目标高度从1.1米改到约2.1米，或者干脆把取暖伞裁掉重出一版。但我不想为了凑一件资产去动摆放代码里的常数，那是把资产的问题记到引擎头上。

批量那一档：38件一次过，两道工序

上面那条流水线是给「二十几件」这个量级写的。等到智能网格那批一口气出了38件，有两道工序必须换个做法，不然光是手工点导出就够点一下午。

工序一：降贴图不开Blender，直接改文件

这38件出来已经是GLB了，所以这一道我没走Blender，也没走gltf-transform，而是直接改GLB里的glTF JSON和BIN数据块：只动两样东西，images那几段字节，以及可选的顶点数据。其余字节原样搬过去。

这么做的好处不是快（虽然确实快），是「三角面不变、包围盒不变、扩展依赖不变」这三条不需要事后去核验捞回来，构造上它们就动不了。你没碰的字节不会自己变。

逐件核验八项，38件全过：三角面不变、顶点数不变、图元全是三角形、带UV和法线、扩展依赖为空、包围盒偏差不超过1e-5、单面、贴图确实是1024²。逐件日志一件一个文件存着，出了事能追到具体是哪一件哪一项。

这一批每件只带一张base color贴图，所以降贴图这一步不用管法线图和ORM图的对应关系，一张换一张就完了。要是你手上的资产带多张贴图，记住一条：按原图名一一对应地换，不要「把所有贴图槽位都换成第一张图」。我第一版脚本就是那么写的，出租车只有一张图所以看不出问题，换成带法线图的资产就会把法线图也替成颜色图，而这个错误渲出来还挺好看，不看文件根本发现不了。

降贴图这一步为什么非做不可，看显存账最直观：一张8192²的底图展开268 MB、带mipmap约358 MB，26件就是9.3 GB——这个数不需要讨论，它直接就是「开不起来」；降到1024²之后每件5.59 MB、26件145 MB。完整算法、进位口径、以及为什么显卡工具读数会小约7%，都在§12那笔账里，这里不重算。

一个诚实的交代：1024这一档我是照配方定的，没和512、2048做过A/B，所以我只能说它在这个项目里够用，不能说它是最优解。

工序二：FBX转GLB，让两套读数互相不信任

智能网格带贴图导出给的是FBX，而Web这边吃的是GLB，中间得有一道转换。本机没有现成的命令行工具能读FBX，最后用的是Blender的无头模式：

python3 fbx2glb.py taxi-p2-smartmesh-textured.fbx \
    -o out/car-01-taxi.glb --yaw -90 --dump-texture

选Blender有一条硬理由：这批FBX的Creator字段写的就是Blender的FBX导出器。用同一个实现读回来，轴向和单位的往返最不容易出岔子。

但转换器自己的读数不能当证据。我让它同时跑三条互不相干的通道去量同一个包围盒：

三条通道的最大偏差是1.0e-08。这个数的意思是浮点误差级别，也就是三条路量的是同一个东西。出租车那件的实测账：

一个省钱的岔路：同几何换贴图

前面提过，沿街的建筑是七种循环复用，开着车能认出来在重样。解决重样最直觉的办法是多生成几栋楼，但还有一条便宜得多的路：几何不动，只换贴图。

实测下来几何是零改动的，17366面进、17366面出。对游戏来说这是双重的好处：消除重样感，同时几何还能在多个实例之间共享，省显存。给核心的几栋建筑各配一两张贴图变体，比再生成几栋楼划算得多。

这一节的产出

一个assets/目录，里面是命名规范、尺寸归一、面数在预算内的GLB。下一节把它们接进引擎：五个文件各管一摊，加上车辆手感、会走路的行人，和两个把我卡了半天的坑。

§18组装：把23件模型变成一个能开的城

Assembly: From 23 Files to a Drivable City

这一节讲怎么把清洗好的GLB接进引擎，五个文件各管一摊；也讲我作为一个不写代码的人，是怎么指挥编程agent干这件事的，包括我说过的原话、以及「不许做」那一栏为什么比「要做」那一栏更值钱。

先看它长成了什么样

这个东西有三种玩法（两圈竞速、单圈幽灵计时、自由漫游），一条约2.12公里的赛道，8处可探索地标，能拍照导出明信片，手机触屏能玩。全部跑在浏览器里，不依赖任何CDN。

五个文件，各不认识对方

整个项目的代码分成五个模块，划分依据是各自不需要知道什么：

这个划分是被逼出来的。项目有一个特殊约束：城市层从另一个项目原样搬过来，那个项目必须只读。所有适配只能发生在边界上：坐标系从「北向+Z」转成「北向−Z」、r160的立面图集UV、水面shader的输出格式、六层构建回执的强制核对，全部塞进city-loader.mjs一个文件里。

我是怎么指挥的

我不写代码，这个项目的每一行都是AI写的。所以怎么指挥这件事，对我来说比怎么实现重要得多。

我的做法是每一轮开工之前先写一张纸，就五栏：成品长什么样（我的原话逐字抄进去）、背景、不许做、三条可判真假的过关标准、什么时候该问我。

巴黎这一轮，第一栏是这么写的：

地图那一轮是这么写的：

加资产那一轮是这么写的：

行人那一轮是这么写的：

你看这四句的共同点：全是方向和判据，没有一句是实现。我没说用什么算法做漂移，没说行人的动画该怎么驱动，没说城市层该怎么接。我说的是哪里不够好、保留什么、这个方向能不能参考、什么样算毫无意义。

这不是因为我懂得少所以只能这么说。而是我说得越具体，agent的方案空间就越小，而它在实现层面的判断力其实比我强。我该占住的是另一头：这东西给谁玩、玩到哪一步算好、哪些事绝对不许做。

「不许做」那一栏

五栏里我花时间最多的是第三栏。巴黎这轮写了五条：

• 不把「1000%」和「100%」写成验证结果
• 不改其他项目（城市层那个参考项目必须只读）
• 不付费生成、不擅自发布
• 保留旧版
• 静态GLB不冒充骨骼动画

这五条里，第一条和第五条直接决定了这本书里哪些话能说。如果当时没写死，今天我大概率会拿着「提升1000%」当成果去讲，而那是一句没有量表、没有对照测试支撑的话。第五条更要命：如果允许把位移加上下起伏说成「走路动画」，我就不会去测真正的骨骼绑定，而那恰恰是这个项目后来最有价值的一段。

车辆手感：一个变量拆成两个

第一版车开起来很怪。不是慢、不是飘，是「太跟手了」。方向一打，车就立刻整个换方向，像用鼠标拖一个图标，没有任何重量感。

原因是当时只有一个heading变量，同时负责「车头指向哪」和「实际往哪走」。转向输入100%立刻体现在位移上，没有任何滞后。

改法是把它拆成两个：

// heading：车身朝向，转向输入直接改它
p.heading += p.steer * (drifting ? 2.3 : 1.65) * ... * dt;

// moveDir：实际移动方向，每帧用一个"抓地力"系数向 heading 追赶
p.moveDir += angleDelta(p.moveDir, p.heading) * (1 - Math.exp(-(drifting ? 3.0 : 11) * dt));

p.x += Math.sin(p.moveDir) * p.speed * dt;
p.z += Math.cos(p.moveDir) * p.speed * dt;

关键在那个抓地力系数：正常驾驶是11，按住漂移键掉到3.0。数值高的时候moveDir追得紧，车贴地；数值低的时候moveDir明显落后于heading，车身指着一个方向、实际往另一个方向滑，这就是甩尾。

一个改动同时解决了太跟手和不会漂移两个问题，是这个项目里性价比最高的一条经验。漂移超过0.35秒松开给冲刺奖励，超过1.05秒给大奖励，连击还会翻倍加分，这套东西全部长在那两个变量的差值上。

同一个思路还救了另外两处。碰撞不需要物理引擎：每个静止物体注册一个圆心加半径，每帧检查距离、重叠就推出去，几百个碰撞体对现代浏览器毫无压力。AI对手不需要导航网格：赛道是固定闭环，路点巡航就够了，朝向做平滑插值，转弯处天然带弧度。通用寻路是为「任意起点到任意终点」设计的，用在这里是高射炮打蚊子。

后来又补了一刀：高速转向要收敛

手感这条线后面还改过一次。原来的转向角速度只有一个「停着不能原地打转」的限制，7 m/s就到顶了，也就是25 km/h和83 km/h打方向的角速度完全一样。83 km/h下转弯半径只有13.9米，车发飘、点一下方向就画圆，高速段没有任何重量。更要命的是漂移比抓地只快了不到四成，漂移在手感上没有存在的必要。

改法是给转向乘一个随速度衰减的抓地系数，13 m/s以下完全不动（低速灵活是这台车的性格，不能碰），高速段再加一条「满舵会蹭掉一点速度」。实测的稳态转弯半径：

低速一模一样，顶速收到71%。漂移的价值第一次成立：23 m/s下漂移14.0米对抓地19.5米，差28%，「高速弯要么减速要么漂」这句话从手感上真的兑现了。

这一改差点被验错，而且错得很彻底。那个故事放在§19，因为它是关于验收方法的，不是关于车的。

行人：从滑行到真的在走

第一版的行人是会动的静态雕塑。Tripo那批没开绑骨的图生3D资产是单一整体网格（用工具解析确认过：车辆模型只有1个mesh节点、0个动画片段），车轮转不动，人物只能靠整体位移加上下起伏假装走路。

我说那句「肯定要做骨骼能动的游戏」之后，这条路径被单独跑了一遍，跑通了。

在Tripo这一侧

三个版本的对照，能看清每一步到底加了什么：

那个行走动画拆开看：123个通道，其中16个带关键帧（真正在动的腿、臂、脊柱，最多57帧、最少51帧），采样间隔0.042秒（约24 fps），时长2.375秒一个完整走路循环；剩下107个是保持不动的关节（手指之类），这是正常结构。

在引擎这一侧，改了三处

一，实例化必须走SkeletonUtils.clone()。带骨骼的模型不能用普通的clone()，否则所有实例共享同一套骨骼，一街的行人会做一模一样的动作。

import {clone as skeletonClone} from 'three/addons/utils/SkeletonUtils.js';

const root = skeletonClone(walkScene);
const mixer = new THREE.AnimationMixer(root);
mixer.clipAction(walkClip).play();

二，每个行人一个自己的AnimationMixer，每帧调mixer.update(dt)。

三，相位要错开。用行人自己的坐标算一个偏移量喂给setTime()：

mixer.setTime((x * 0.37 + z * 0.11) % walkClip.duration);

不错开的话，一排人会像仪仗队一样齐步走。这个细节没人会告诉你，但少了它整条街都是假的。

还有一个坑值得单独记：three/addons/utils/SkeletonUtils.js在项目的vendor目录里根本不存在。我为了不依赖CDN，vendor里只精选了GLTFLoader、OrbitControls、BufferGeometryUtils三个，import一个不存在的文件会让整个游戏白屏。补一个对应版本的文件进去才通。

这一步走通的时候，场景里18个行人全部挂上了那具骨骼和那段行走动画。整条路走通花了两次20积分。唯一不满意的是只测了「行走」这一个动画，近一百个预设里还有跑步、挥手、打电话，质量稳不稳定我没验过，这条得说清楚。

梧桐的注入时机

把§17那两棵梧桐接进城市层，技术上只有三十几行改动，但有一个时序约束必须先说：城市层是在build的时候就建好实例池的，等它建完再给树就来不及了。所以加载顺序是死的：

window.__PARIS_TREE_GLB = await loadCityTree();   // 必须在前
await buildReferenceCity(...);                     // 城市层 build 时读它

其余三处小改都在城市层副本的家具模块里：近景树冠池的几何和材质改成读注入值；填树函数的近景分支分两条路径算实例变换；GLB树自带树干，所以不再叠画程序化树干。集成之后的性能账里有一条反直觉的：

绘制调用反而少了，因为近景池从四套程序化变体合并成了同一个GLB，白赚。帧时间看着翻倍，其实是从119 fps掉到60 fps的垂直同步上限，原本那点余量被吃掉了，60 fps本身是满帧流畅的。这种数字要看清楚再下结论，不然会把「用光了余量」误读成「性能塌了」。

这件事我后来又撞了一次：换完资产在街上机位量到146个绘制调用，和上面说的77对不上。查下来两个原因都排除不掉，一是那次基线没记相机坐标、我复现不了同一个机位，二是那半天里另外两条线也在改代码。所以那个读数只能当「新资产下的现场读数」，不能当「和基线的严格对比」。性能数字的第一要求不是准，是能说清它是在什么条件下量的。

三轮修复：四条反馈，七个根因

上面那些是把东西装起来。装起来之后我自己开着玩了几轮，报了四条反馈，一条比一条口语：「树会突然刷新和消失」「碰撞机制需要做得更好，还是很容易穿模」「巴黎街边哪有这么奇怪的植物。。。莫名其妙啊」「试试撞车，体验下异常的效果」。

这四句话追下去，挖出七个根因，没有一个的根因是「机器不够快」。我把它们完整写在这里，因为这是这本书里最像真实工程现场的一段：看见的症状、猜错的方向、最后量出来的数。

根因一：抢不到坑位就整棵不画

「树会突然刷新和消失」，我第一反应是GPU顶不住了，准备去砍面数。结果一条都不用砍。

近景的树是放在一个实例池里画的，池子有容量上限，代码大概是这个意思：

if (距离 < 近景半径){
  if (这个变体的坑位已满) ok = false;   // ← 落到这里就什么都不画
  else { ...放进近景池... }
} else if (中景池还有空){ ...放中景冠... } // ← 这个 else 够不着

问题全在那行注释上。一棵树只要落在近景半径里、又没抢到坑位，它就什么都不画，而不是退一步画成简化的中景树冠。那个能降级的分支挂在else上，近处的树根本走不到。

后果是反直觉的：165米圈内抢不到坑位的树凭空消失，而200米外的树好好画着。那条大道上165米内实测有96株候选，旧配额只给36个坑，也就是有60株是看不见的。

加上另外两件事，「突然刷新」也解释了：近景配额是按变体均分的，36棵被拆成两个18，这一段街要是树种偏向某一个变体，那个变体先占满、后面的抢不到，而另一个变体的坑位还空着；再加上重排的触发条件是相机每走满80米重填一次，开到60 km/h就是每5秒整批换一次。不是渐变，是定时集体重排。

改完在浏览器里复核，不是推算：同一机位，近景GLB树的距离分布是0到164.5米，中景程序化冠从165.1米起，中间没有断档。沿大道每12米采一次，240米里每步只换0到14棵，多数步是0；旧版是每80米整批36棵重排。

根因二：同一个bug还在另外两处

修完树，我让agent做了一次全量体检：全城60个采样点，把每个实例池的占用率打出来。37个池里有11个跑满。跑满本身不是bug，关键看溢出的时候丢的是远处还是近处。查下来又找到两处和树同源的。

路灯和长椅：半径被配额锁死。池子一旦跑满，LOD的实际半径就由配额决定，而不是由距离环决定。路灯那一环名义上是1100米，实际被100盏的上限锁在约300米；而那个由配额决定的边界又跟着相机每80米重排一次，于是一批批地进出。把上限从100提到420之后，实测有效半径从300米变成629米，已经在雾里了，看不见了。

奥斯曼屋顶的烟囱：和树一模一样。烟囱分两个池，近池620个完整烟囱（每个116三角），远池是剪影（每个10三角）。代码同样是「近了就放近池，否则放远池」，而近池满了推入会失败，500米以内抢不到那620个坑的烟囱整根消失，600米外的反倒画着剪影。实测近池在密集街区275米就填满了。修法是一行：近池满了退到远池的剪影，不是不画。

根因三：配额调高几乎免费

三处配额全部调高之后的总账，是这一整节我最想让你看见的一张表：

多出来的100万三角面全部走既有的实例池，绘制调用一个没加。这是这套架构最值钱的地方。

这句话我想请你在自己的项目里念一遍。实例池这套东西的成本结构是：提交一次绘制调用很贵，往里多塞几百个实例几乎不要钱。所以「怕卡所以把上限压低」这个直觉，在这套架构里是反的，它省不下多少，却会让近处的东西凭空消失。

根因四：那棵树根本不像树

把近景配额从36提到110之后，我在游戏里截了一张图发过去：「巴黎街边哪有这么奇怪的植物。。。莫名其妙啊」。

我是对的，但这不是agent改坏的。它把一直就有的问题放大了。

把那个树模型单独渲出来看（不是在游戏里找角度，是拿Blender出六视图），问题一眼就清楚了：7,473个三角面撑不起一个树冠，出来是几十片巨大的独立叶片挂在细枝上，像一棵幼苗或者某种奇怪的室内植物，完全不是巴黎那种被反复修剪、树冠密实的行道树。配额36的时候一屏里只有几棵，混在程序化冠里看不太出来；提到110之后满街都是它，一眼就假。

换件之后的账：

担心的是面数涨了会不会把刚修好的余量吃掉。实测把两个树池的数量依次砍到八成、六成、三成五，中位渲染耗时是3.1、4.1、4.0、3.3毫秒，非单调。非单调的意思是树的数量在这个机位根本不是主导开销，四个读数全在噪声里。所以110这个配额不用回收。

顺带把株距也放宽了。原来的间距是照巴黎实际行道树写的，但从车里看出去是一道连续的绿墙；放宽之后读起来才是「一排一棵一棵的树」。全城树候选从2.27万降到10,765，同一机位近景树96棵降到65棵，三角面321万降到247万，帧时间6.6毫秒降到5.8毫秒。画面更像巴黎，机器还更轻松，这种改动不多见。

根因五：拿一个1.1米的圆去代表一台3.57米的车

「碰撞机制需要做得更好，还是很容易穿模」这条，根因藏在一个参数里：碰撞检测一直是拿半径1.1米的圆去代表玩家那台车。

而2CV实测是1.58米宽、3.57米长、1.62米高，半宽0.79、半长1.79。一个1.1的圆：

• 横着比车宽（0.79变成1.1），贴边过窄巷会被莫名其妙挡住
• 纵着远比车短（1.79变成1.1），车心还没碰到墙，车头已经插进去0.7米

这就是「很容易穿模」的全部。改法三条：

验收方法是把车全速怼进墙里，全城取61个撞墙点，二分量车头的插入深度：

剩下那2个是同一个点，两个实心块叠着，而且那个测试起点本身就在实心块内部，兜底闸要求「上一帧是安全的」才触发，所以没兜住。游戏里车不会凭空出现在建筑里，这个状态到不了。但我也没能证伪，如实记着。高速（每帧0.57米，约122 km/h）和中速（每帧0.35米，约76 km/h）两档结果一致，没有隧穿。

根因六：码表永远显示2 km/h，是一个不动点

「试试撞车，体验下异常的效果」。前台截图抓不到撞墙那一瞬间（标签页不在前台的时候，浏览器的动画循环是停的），所以改成把撞墙那几十帧逐帧打出来。异常一眼就看见了：

f222  v=23.00  位移=0.383   ← 撞击前
f223  v=14.95  位移=0.361   ← 撞上
f224  v=9.92   位移=0
f240  v=0.60   位移=0
f248  v=0.59   位移=0       ← 永远停在 0.59，不会归零

位移确实是0，车被挡住了，但速度永远降不到0，稳定在0.59 m/s。

这不是玄学，是一行代码的不动点。碰撞的处理是speed *= .65，而每帧油门加19 * dt = 0.317，解方程v = (v + 0.317) × 0.65，得0.589。它就停在那儿了。

三个后果：码表贴着墙一直显示约2 km/h，车明明没动；撞墙没有任何回弹或反馈，是「贴住」不是「撞到」；那点残留速度会在打方向的瞬间释放出去。

改法是不再无脑乘一个系数，而是按墙的法线把速度拆成两份：撞进墙里的那一份（法向）去掉，并且多去15%，那15%就是回弹；沿着墙的那一份（切向）留86%，那就是摩擦。

const vn = vx*nx + vz*nz;              // 法向分量，撞进去时为负
if (vn < 0){
  vx -= nx*vn*1.15; vz -= nz*vn*1.15;  // 去掉法向 + 15% 回弹
  vx *= .86; vz *= .86;                // 切向摩擦
}

改后正面撞墙是23 m/s在一帧内卸到2.97，之后在0.05到1.5之间小幅抖动（油门顶着墙、墙推回来），位移0.006到0.029米，贴着墙轻微蹭动，不再是个死值。撞完打方向，速度从0.46平滑爬到1.27、位移持续增加，车顺着墙滑出去了。这是改之前完全没有的行为，「贴着墙过弯」这种开法第一次成立。

根因七：街上18个行人其实是同一个人

这条是并行的另一条线在做资产替换时发现的：它换了两个静态行人的槽位，却发现画面里根本不出现它们。

根因在生成行人的那个函数makeWalker(key, height, x, z, rotation)上。它第一行就是「如果绑骨行人加载成功就走这一支」，而绑骨行人当然加载成功了，所以传进来的key从头到尾没有被用过一次。结果街上每一个行人都是同一个藏青西装、戴礼帽、拎公文包的男人。另外五件静态行人资产的处境更微妙：它们被加载进了显存，但一个实例都没有画出来。

改法：三个人里挑一个用绑骨那具会走的（全场只有这一具有骨骼和行走循环），其余用各自的静态模型，五种轮换。所以前面那句「18个行人全部用上了真动画」，正确的说法是「18个行人里有6个在真的走，其余12个是五种不同的人站着」，这比满街同一个人可信得多。

顺带修掉第二个假点：静态行人不再左右滑动。原来所有行人都吃一个左右各3米的正弦摆动，配合走路循环是对的，配在一个静止的模型上就是「人在地上滑」。现在不走路的那些，摆动量直接给0，站着不动。

七个根因的共同点

回头看，它们长得完全不一样：LOD配额、碰撞体形状、速度衰减的不动点、一个从没被读过的参数、一件形体不对的资产。但它们有两个共同点，我觉得比每一条的修法更值得记：

一，全都伪装成了别的问题。树的问题看着像显卡不够，实际是逻辑；撞墙的问题看着像玄学，实际是一行乘法的不动点；行人的问题根本没表现成问题，它表现成「一切正常」。如果我按症状去优化，会去砍面数、去调物理参数、去给行人加更多变体，几个方向全是错的。

二，那四条反馈全是我开着车玩出来的，没有一条是自动化验收发现的。这不是说自动化验收没用，下一节会讲它抓到了什么。而是说这两类检查的覆盖面根本不重叠：程序验证「它有没有按代码跑」，人验证「它像不像那么回事」。后者目前没有任何办法可以外包。

两个卡了我半天的坑

坑一：追尾镜头方向算反了。镜头一度卡在车前面而不是车后面，开起来是在倒着看自己。这类错误没有报错，只有「感觉不对」，定位全靠把符号一个个试过去。

坑二：沙盒环境禁用fetch()，模型渲染成纯黑色，没有任何报错。

这一条值得展开，因为它是个通用坑。Three.js的GLTFLoader加载贴图时会优先走ImageBitmapLoader，而它内部用的是fetch()。某些沙盒预览环境会完全禁用fetch()（哪怕是同源的 data: URI），于是贴图静默加载失败，模型全黑，控制台干干净净。

解法是一行：

window.createImageBitmap = undefined;  // 逼 Three.js 退回走 <img> 标签的经典路径

更根本的一条是：多文件加载还是base64内联，由发布平台决定，不是技术偏好。早期版本因为锁定在那种沙盒里，只能把模型全转成base64塞进单个HTML，3个模型就吃掉12.5 MB，23个资产根本塞不下。一旦改成普通静态网页，真实HTTP环境没有这个限制，直接用相对路径加载.glb就行，问题从「怎么塞进16 MB」变成「怎么让加载别太慢」，完全是另一个问题。先问清楚要发到哪，再决定用哪种加载方式。

这一节的产出

一个能在本地HTTP服务上跑起来的完整游戏。但「能跑起来」离「能发出去」还有一整套验收：三套QA、一轮独立质控、一个离线可用的发布包。下一节讲那个。

§19验收与发布

QA and Release

「能跑起来」和「能发出去」之间隔着三套QA、一轮独立质控和一个离线可用的发布包。这一节给你我实际用的验收清单、独立质控挑出来的三个真问题，发布到B站Toy那条路上的几个硬约束，以及不走Toy时那条更省事的静态托管路。顺便把一句不能当结论的话说清楚。

三套QA，各盯一件事

我跑了三套自动化验收，各自的职责分得很开：

第一套里有一项特别值得学：24座桥的桥面高度逐座采样，记下每一座的坐标和实际高度（0.39到1.38之间）。车的落地高度要是直接套街面y=0，过桥的时候就会嵌进桥面里。凡是「代码算出来的地形」和「玩家实际会走过去」有交集的地方，都要逐点采样，不能抽查。

第二套的口径我写得很硬：没有把模拟器结果当成实体手机性能。桌面高画质下是202个绘制调用、248万三角面；移动端低画质是82个绘制调用、91万三角面，两边帧时间中位数都锁在16.7毫秒，但那是无头浏览器的帧间隔，不等于GPU耗时，也不等于任何一台真实手机上的帧率。这条边界不划清楚，后面就会有人拿着这个数字去承诺性能。

独立质控：写它的AI不审它

三套QA是主线程自己跑的，所以还要有一道独立的。我的规矩是写内容的AI不审自己的产出。另开一个只读游戏和参考项目、完全不看开发过程的agent，专职找问题。它交回来的那份报告，比我预期的狠。

两轮审查挑出三个真问题，每一个都值得抄进你自己的清单：

第二条是我最想让你记住的。它推翻的是一个所有人都在用的验收习惯：「页面能打开、控制台没报错」什么都不证明。独立质控自己在报告末尾写了一节叫「检查方法本身的盲区」，三条：

• 零pageerror不代表对象坐标有效，行人NaN就是反例
• 为了加速而关掉渲染的那次键盘测试，它的16毫秒帧时不能当性能证据
• 赛道中心线畅通、两圈完赛，推不出1375个街廓和全部桥头都有正确碰撞

两条会把结论验反的教训

上面讲的是「验了什么」。这一段讲更要命的一层：验法本身错了，你会拿到一个看起来很扎实、方向却完全相反的结论。我在同一个项目里栽了两次，两次都差一点按着假结论去改代码。

一、手感类改动只在简化赛道上验，会把结论验反

§18那个「高速转向要收敛」的改动，第一版给的抓地系数比定稿激进得多（23 m/s下是0.62，定稿是0.71）。在自动化验收自带的那条546米简化赛道上，它的表现好得没话说：单圈从46.7秒降到43.4秒，风格分翻了2.4倍。

差一点就这么定稿了。拦住这件事的只有一个念头：546米、弯道很缓的测试赛道，和2116米的真实城市赛道，真的是一回事吗。于是把旧引擎挂到同一个真实赛道上直接对跑，五档抓地系数各跑一遍：

0.71和0.62之间是一道断崖。0.62那档在城市赛道上全程推头、全程漂移，单圈从91秒崩到166秒，大偏航的帧数从71涨到3001。而0.71这档反而是全场最快的一档，比原版还快3.6%，撞车仍然是0。

还有一条边界要说清楚：这一整轮没有人手真试驾过。自动验证器回答的是「能不能开完、快不快」，不是「好不好开」。上面那张表的真正用途是当调参的地图：往0.79走更保守，往0.66走更飘。

二、游戏循环每帧都在覆盖你的相机

为了确认八个地标是不是真的都长出来了，我让agent做了一个巡检脚本：八个地标逐个把相机放过去、朝它该看的方向看，各截一张图，回答「站在那儿到底能不能看见它该有的东西」。

第一版结果很吓人：八个里七个看不见该看的。「金色桥梁」那一张没有桥，「岛上的钟楼」是一面白墙，卢浮宫是一片空地。差一点就去把新生成的那批地标资产往城里塞了，而那是一整个下午的活。

拦住它的是一个不对劲的读数：第6个「双层桥的风」完美拍到了铁塔。如果真是资产缺失，不可能只有一个是好的。

根因：这套demo的相机是游戏循环拥有的。页面在无头浏览器里是「可见」的，动画循环照跑，游戏每帧都用跟车相机把我设进去的那个相机覆盖掉。我截到的根本不是我摆的机位，是跟车相机在那个坐标上、朝着玩家当前车头方向的随机视角。

正解是不要去设相机，把车头转向地标，让跟车相机自己对过去，再等1.4秒让它插值到位。重做之后八个全部正常：站在铁塔腿下、桥上金柱在前、卢浮宫中庭看得见玻璃金字塔、凯旋门拱下、圣心堂白色穹顶、比尔阿凯姆双层钢桥、街角咖啡，一个不缺。

顺着这条还有两个截图相关的坑，一起记在这：浏览器标签页不在前台的时候动画循环是停的，所以前台截不到撞墙那几帧，得改成逐帧打印数值；后台标签页的WebGL根本不渲染，截出来是纯黑，别把黑图当成「渲染坏了」。

还有一条在§18已经讲过，但它和这两条是同一类，值得在验收清单里再写一遍：模型的形体对不对，必须把它单独渲出来看，不能靠游戏里某个角度的截图判断。游戏里总能找到一个角度让它看起来还行。

发布包怎么构建

本地开发和发布是两件事。这个项目的启动和构建各一条命令：

# 本地预览（ES 模块和 GLB 必须走 HTTP）
python3 -m http.server 8765 --bind 127.0.0.1

# 构建发布包
python3 build.py

build.py干的事很朴素：把入口文件和三个目录（assets、vendor、city-reference）复制进发布包/web/，顺手把来源清单和所有.md排除掉（发布包里不能带本机路径），再打一个ZIP，最后吐一份构建回执：

{
  "files": 52,
  "uncompressedBytes": 18170667,
  "zipBytes": 11935880,
  "entry": "web/index.html",
  "externalRuntimeDependencies": false
}

最后那一行externalRuntimeDependencies: false是这份回执里最重要的一个字段。Three.js固定在项目的vendor目录里，运行时不碰任何CDN，这是为了让这个包在断网、在任何子路径下、在别人的服务器上都一样能开。package-results.json里那条「屏蔽外网之后仍然加载成功」就是在验它。

还有一条容易被忽略的：旧的构建产物不删，移进_archive/带时间戳存着。构建脚本每次跑都会先归档上一版，这样任何时候都能拿出上一个能跑的包做对照。

这条好习惯后来咬了我一口

换完一批资产之后我重建了发布包，顺手查了一遍包里到底装了什么。build.py里那个复制目录的调用没有排除_archive，所以每一个被换下来的旧件都被整包带走了：11个旧版资产，约7.9 MB死重。玩家下载的包里，有将近三分之一是已经不用的东西。

同时还看见另一件事：中文的归档目录名在ZIP里是乱码，显示成一串问号方块。这是macOS的zip不写UTF-8标志位那个老问题，不是文件坏了，但用户解压出来看见乱码目录，第一反应一定是包有问题。

顺手把__pycache__、.DS_Store和源FBX也一起排除掉，账是这样的：

这条会一直复发，因为它是那条好习惯的必然副作用：每换一次资产，旧件进_archive，包就胖一圈。所以修法不能是「记得手工清一下」，必须是把排除规则写进构建脚本，让它自己不去看那个目录。改完重跑发布包验收，仍然通过、仍然锁60 fps、零报错。

发到B站Toy的三条硬约束

Toy支持纯静态的前端项目，把发布包目录或ZIP直接交给官方CLI就行。但有三条不看清楚就会翻车。

这三条落到命令上就是几个参数。toy create --help的输出抄在这儿，省得你自己装一遍才知道有哪些开关：

创建 Toy 并提交审核。

  <path> 可以是目录、单个 HTML 文件或现成 zip。未传 --title / --slug 时，
  CLI 会从路径名自动推导；带包体的创建会先生成预览链接，确认后才提交审核。
  分类使用服务端枚举；图标支持 PNG/JPEG/WebP，大小不超过 512KB，宽高不超过 1024px。

Usage:
  toy create <path> [flags]

Examples:
  toy create ~/fire-emblem-web
  toy create ~/fire-emblem-web --title "Fire Emblem Web" --category GAME --icon ./icon.png --yes

Flags:
      --access-password string   访问密码；创建密码访问 Toy 时使用
      --category string          Toy 分类（GAME|INTERACTIVE_PLAY|TOOL|TEST|GUIDE|COLLECTION|OTHER）
  -h, --help                     help for create
      --icon string              Toy 图标图片路径（PNG/JPEG/WebP，≤512KB，宽高≤1024px）
      --poster string            封面图片路径
      --slug string              Toy slug/sub_dir，默认从路径推导
      --title string             Toy 名称，默认从路径推导
      --visibility string        发布可见性（link-only|password|public），默认 link-only
      --yes                      预览后直接提交审核

Global Flags:
      --json   读操作输出 JSON 而非文本

第1条里说的那个「确认参数」，就是最后一行的--yes。

说明一下：到本书写作为止，这个demo还没有对外发布过。技术路径验证过可行，发布包也构建好了，但对外发布是一个需要人拍板的动作，不该由agent自己按下去。这条也写在了那张纸的第五栏里。

不走Toy的话：扔到静态托管

Toy是B站生态里的那条路。如果你只是想做个东西发给朋友玩，还有一条更省事的：静态托管。§12里那句「Vercel、Cloudflare Pages、GitHub Pages都能直接扔」说的就是它——整个目录传上去，对方拿到一条链接就能开，不用等审核。

好消息是上面那三条硬约束里，只有第1条是Toy特有的。第2条「页面跑在子路径下」和第3条「必须走HTTP」在任何静态托管上都一样成立，所以自检动作是同一套。传上去之后再看白屏，比在本地先彩排一遍贵得多。

我拿资源包里的demo/巴黎/把这套彩排实跑了一遍，三条命令：

# 1. 扫绝对路径引用：这一条有输出，传上去就是白屏
grep -rnoE '(src|href|from)="/[^"]*"' .

# 2. 把整个目录塞进一个两级子路径，模拟托管商给你的地址
mkdir -p /tmp/subpath/demo/paris && cp -R . /tmp/subpath/demo/paris/

# 3. 从上层起真实HTTP服务，浏览器开 /demo/paris/
cd /tmp/subpath && python3 -m http.server 8891 --bind 127.0.0.1

结果：第1条零输出；服务起来之后，入口页和app.mjs、engine.mjs、city-loader.mjs、city-map.mjs、style.css、vendor/three.module.js逐个取，全是200。这个目录一共52个文件、18170667字节，和前面那份构建回执的"files": 52、"uncompressedBytes": 18170667逐字对得上——资源包里放的就是09-10那一版发布包。2026-09-13实跑。

剩下的只有上传那一下。这一步我同样没按，理由和上一段是同一个：对外发布是要人拍板的动作。所以这条路上我能交给你的，是到「本地子路径彩排通过」为止的部分；再往后是三家托管各自的登录和上传流程，它们的文档里都是一条命令的事。彩排这一关过了，最常见的那类「传上去就白屏」不会再找上你。

那句不能当结论的话

项目一开始我给的目标里有两个数字：「提升1000%+的产品体验」「比海辛的案例出色100%以上」。

这两句是创作目标，不是实测结论。我没有统一量表，也没做过对照的用户测试，所以它不能出现在任何一句「我测出了什么」的表述里。项目README里我把这句单独写了一行，就是怕过几个月自己忘了。海辛的公开案例原帖在这里：

https://x.com/ring_hyacinth/status/2096704996381266424

这件事我想多说一句。做完一个东西之后，最诱人的时刻就是给它安一个倍数。但倍数是要有量表的，没有量表的倍数是情绪，不是结论。把「我当时想做到什么程度」和「我最后测出了什么」分成两句话说，是这一行最基本的体面。

已验证的和没验证的

右边这一栏不是失败清单，是下一轮的工作清单。把它写出来，比含糊地说一句「测试通过」诚实得多，也有用得多。而且这一栏每一轮都会变长，不会变短：你测得越多，知道自己没测什么的能力也越强。第一版的时候我根本写不出「没有人手试驾过」这一条，因为那时我还不知道自动验证器和真实手感是两件事。

Part IV到这里结束

四节走完，你手上应该有一条完整的路：一张分工清楚的资产清单（§16）、一条能复用的生成与清洗流水线（§17）、一套模块边界清楚的组装方式和一份指挥agent的写法（§18）、三套验收和一个能独立活的发布包（§19）。

下一部分换个题目：同样这套方法，怎么用来做教学演示——一台能拆开的四冲程发动机、一幅能展开的油画、一颗能走进去的星球。

两张收尾的图

§20机构类：一台能拆能装的发动机

Teaching Demos I: A Four-Stroke Engine You Can Take Apart

这节读完，你能自己判断一台机器里哪些零件该写代码、哪些该交给Tripo，并且知道怎么把「拆开看」升级成「装回去玩」。我用一个晚上做了一台单缸四冲程汽油机，一共只生成了两个零件。

先看结果

这台发动机能转、能剖开、能拆成六大件，还能让你按顺序装回去，装错了它会告诉你为什么装不进去。所有运动都是按曲柄滑块的公式实时算的，没有一帧是事先录好的动画。

做它的起因很直接。前一天晚上我做完一版《星月夜》的立体拆解，自己的判断是「组件构成还是有些怪，效果不够理想，但是这种拆解的方式非常有趣」。既然有趣的是拆解本身，那就该找一个天生就该被拆开看的东西。发动机是最好的那个。

整台机器的运动只由一行公式决定，活塞销的位置从曲轴转角精确推出，连杆两端实时连上曲柄销和活塞销：

// R = 曲柄半径，L = 连杆长度，th = 曲轴转角
function pinPos(th){                    // 活塞销
  return new THREE.Vector3(0, R*Math.cos(th) + Math.sqrt(L*L - R*R*Math.sin(th)*Math.sin(th)), 0);
}

四冲程的相位跟着走：曲轴转两圈（720°）是一个循环，进气门在0到180°开、排气门在540°到720°开，升程走一段正弦窗。这些都是查得到的机械常识，你不需要懂，Codex懂，你只要知道它必须由公式算、不能由动画摆，否则观众拖到某个角度就会发现活塞和气门打架。

那条分工判据

这台机器一共六种零件，只有两种是Tripo生成的。当时怎么分的，后来成了整本书里我最常回头用的一条判据。

这条判据后来在游乐园那一轮又验了一次，摩天轮的圈和辐条必须是正圆、过山车轨道必须闭合平滑，这些全归代码；吊舱、木马、茶杯这些只决定好不好看的，全归Tripo。这条判据是撞出来的，我一开始并没有它。

曲轴：我真的去生成过，然后放弃了

「曲轴该写代码」这句话，是花了50积分换来的。我先老老实实送了一张四缸曲轴的照片进Tripo。

问题不在质量。曲轴的功能全部藏在两个数字里：曲柄销偏离主轴中心多少（决定行程），以及四个拐之间的相位差。这两个数字在生成出来的网格里测不出来，只能量个大概，而量个大概的曲轴装进机构，活塞的上下止点就全是错的。我可以写个脚本去网格里拟合销半径，那比直接用代码画一根曲轴贵十倍。

所以最后的成品里，那根曲轴是十几行代码画的几个圆柱，丑，但每一个尺寸都是我自己定的。丑而正确，胜过好看而错误，教学演示尤其如此，因为观众是冲着「机器到底怎么动」来的。

活塞和连杆：两张图，100积分

这两件走的是标准的图生3D。原始参考图取自维基，图页上标的是公有领域，我先在本地裁成单物体、白底、四分之三视角。（当时拿它生成模型和把成品随书再分发是两个标准：我没有逐张回核许可证版本与附加条件，所以这两件在随包素材里被剔掉了，口径见§00。）

两次生成各50积分，一共100。按Pro套餐¥140 / 3000积分换算，这台发动机的模型成本是4.7元。

耗时口径这一节和后面两节通用：本书引用平台侧的秒数一律是算子耗时（算子耗时口径，不含上传与排队；端到端要往上加，两个口径的实测差见§01，词条见附录D）。你自己坐在界面前等的是另一个数，中间夹着上传、排队、出预览、下载。

把生成件接进机构的三条手艺

Tripo给你的是一个模型，机构要的是一个带着安装接口的零件。中间这一步没人替你做，好在只有三件事：

白底那一课

v1是深色界面。做v2时我想换成纸感白底，理由在X上那一轮案例分析里：同期高赞的3D demo几乎全是深色赛博风，已经有人在公开抱怨审美疲劳，而拿到10060赞的@tomkrcha那条《蒸汽图鉴》（https://x.com/tomkrcha/status/2096082580554777041，2026-09-05）是白底、衬线排版、编辑设计级的。一片深色里，白底本身就是差异化。

换白底那一下，画面直接黑了。

解法不需要任何外部HDR文件：用canvas画一张从白到深灰的渐变，当成全景环境贴图喂给PMREMGenerator，再赋给scene.environment。完整代码和三个配套细节（渐变必须留一块暗部当黑旗、白底别开ACESFilmic、金属度压下来）在§12，附录B第一条也收了这段代码。这台机器上唯一要补的是那个数值：Tripo的PBR材质默认金属度偏高，实测压到0.85以下、同时补高环境光强度才对得上。

从「拆开看」到「装回去」

v1做完我就写下了一条自评：拆解是「看」，装配才是「玩」。这台机器当时只能拆开、合上、转一转，缺的是那条「装错了会卡」的交互。v2把它补上了。

正确顺序是曲轴、连杆、活塞、缸筒、缸盖（含气门）、火花塞。点错了不扣分，弹出来的是一条真实的机械约束：

• 先点连杆：「曲轴还没进去，连杆大头得抱在曲柄销上，销子都还没有，它抱谁？」
• 先点活塞：「活塞得靠活塞销挂在连杆小头上，不然它在缸筒里没东西带动，纯粹是块铁。」
• 先点缸筒：「缸筒一罩下来，活塞就没法从上面压进去了，真实装配里这一步装反了就得全拆。」
• 先点缸盖：「缸盖是压在缸筒上端面的，下面悬空压什么？」
• 先点火花塞：「火花塞是拧在缸盖上的螺纹孔里的。」

装对了它也不夸你，接着讲这一件为什么长成这样：连杆的工字截面是干嘛的、燃烧室到底指哪块空间。六件齐了自动开始运转，收尾一句：这个顺序是几何定死的，每一件都挡着后一件的路。

装配模式实现时踩的两个坑

第一个：偏移不能在每帧的位置计算里累加。曲轴、连杆、活塞每帧都被运动学重新赋值，给它们加偏移没事，下一帧会重置；但缸筒、缸盖、火花塞是初始化时设一次的静态件，每帧+=会让它们一路飞出屏幕。气门更麻烦，它的y每帧被升程动画覆盖，加了也白加。

解法是让偏移只在渲染那一刻生效：

asmApply();                       // 记录原位，加偏移
renderer.render(scene, camera);
asmRestore();                     // 渲染完立刻还原

第二个：凡是scene.add进去的东西都要有归属。缸筒内壁那两道细环是独立的mesh，一开始没归进「缸筒」这一件，于是装配模式下缸筒明明还没装，画面上却飘着两道环。

v2.1：空画布和隐形的淡影

装配模式上线后第二天复核，一进去画布全空，第一眼像页面坏了。改成六件以淡影留在画面里的待装位，进装配模式时相机先归位（淡影的摆位是按默认机位排的）。又踩两个坑：

• 淡影必须用不受光材质。这个场景四盏灯加环境贴图，亮度很足，MeshStandardMaterial的中灰会被打成近白，在白底上等于隐形。
• 火花塞里的「火花」不能和淡影共用一份材质。它每帧被写opacity，共用之后整份淡影材质被抹成全透明。症状是「材质挂上了、visible也是true、就是看不见」，靠页尾挂的window.__eng探针才查出来。

这一台的账

一台能转、能拆、能装、能讲出四个冲程的教学演示，模型这一块的全部花费是四块七。贵的从来不是生成，是你决定生成什么。

§21艺术类：把一幅画拆成五层

Teaching Demos II: Unfolding a Painting into Five Layers

这节读完，你能判断一幅画里哪一层该保持平面、哪一层该做成真的立体，并且知道Tripo在艺术素材上能保住什么、会丢掉什么。用的是《星月夜》，19分钟做出第一版，全部花费200积分。

先看结果

起因是2026-09-10我在X上刷到@HoodyLiu的一条（https://x.com/HoodyLiu/status/2097536045881704688），用Three.js把《星月夜》做成了可以拆开的「3D油画」。我用1440p原片逐帧看了一遍，它的真身是五层带alpha的平面抠图，在Z轴上等距错开，加一个展开合拢按钮和一个层间距离滑块。他自己也说了灵感来自乐高版。

这个形式的软肋很清楚：柏树和教堂是一张竖着的纸。背景层平着没问题，它们本来就远；主体层一平，整个立体感就塌了。

先花100积分回答一个问题

动手做demo之前，有一个问题不回答就白做：Tripo能不能把画里的一层做成真3D，同时保住画家的笔触和颜色？能，这条路成立；不能，整条路作废。

所以我先做了两次可行性测试，一次拿梵高的柏树，一次拿《千里江山图》的一段山，两个画种、两种笔法，看看边界在哪。两次都是v3.1最高质量加8K贴图，各约四分钟。这个四分钟是我坐在界面前等的墙钟，不是算子耗时，里面含着上传、排队和下载。两个口径差多少，§20那条已经量过了：现场实测生成端到端约31秒，其中算子16秒。本书引用平台侧的秒数一律按算子耗时口径。

三个结论，一个都不是坏消息

风格保真度不是问题。Tripo用输入图烘焙纹理，笔触和矿物色原样保留。这是整条路能不能成立的分水岭，答案是能。

形体语义会漂移。柏树出来叫rocky spire，火焰般的枝叶变成了一整块尖塔，根因在§02。顺带说一句，rocky spire这个名字本身就是一条免费的验收信号——Tripo给每个模型自动起的名字就是它对形体的理解，名字不对，模型八成也不对，不用渲染就知道。

地景比物件更需要一个「底」。山段出来是一块矩形浮雕板，这其实是对的方向：它变成了一件青绿山水雕件，玉山、木雕山水，都是中国人本来就熟悉的形态。把国画立体化，其实就是把它还原成它最容易被立体化的那个形态。

哪层该平，哪层该立

可行性过了，回到那幅画。五层同名同构，但其中两层的判断和原帖不一样：

判据其实只有两条：这一层有没有正面和侧面之分，以及它挡不挡别的东西。远山既没有侧面、也不挡谁，做成立体纯属浪费。

demo里因此有两个按钮，展开合拢之外，还有一个「全平面/真立体」，一按就把那两条立体层换回画里的平面抠图。差异摆在眼前，观众自己判断，不需要旁白解释。

怎么把一幅画切成图层

这一步没有AI参与，纯手工，但它决定了后面所有事。

切出来的资产分两套：三张平面层是带alpha通道的全分辨率PNG（夜空、星月与旋涡、远山），立体层除了GLB，还要另存一份平面版的抠图。后面那份就是「全平面/真立体」按钮要切的东西，一开始没做，后来发现没有它就没法把差异摆给观众看，只能靠嘴说。

整个页面是一个不依赖CDN的静态目录，three.js本地内置，两个GLB各约9到10 MB。但它必须走http打开，python3 -m http.server起一个就行，双击用file://打开会被CORS挡住，GLB根本加载不了（纯静态、无外部资源的HTML不受此限，这也是很多人第一次做3D网页时最先撞的墙）。

四条只有做过才知道的

秋叶那一课：改一张贴图，等于多一件资产

这一条发生在巴黎那个城市demo里，但它讲的是「怎么调一张画出来的颜色」，方法论上属于这一节，所以放这儿。

巴黎那条街上要两种行道树，绿叶的和秋黄的。Tripo那边只生成了一棵七叶树。按常规做法，另一棵是再送一张秋天的设计图进去，再付一次生成加一次贴图的钱。但这两棵树的几何本来就该完全一样，差别只在叶子的颜色。所以我换了个做法：不重新生成，直接改那张基色贴图。

这件事在文件层面很干净。GLB里顶点数据和贴图是两段独立的字节，重建贴图那一段、其余原样搬运，几何就不可能变。这不是「事后核验发现没变」，是构造上就动不了。三角面11,825，改色前后逐位相同，花费0积分。

难的是颜色本身。第一版我按直觉调：把叶子那段的色相推到28°到51°那一带，同时把饱和度推高18%，想着秋天嘛，颜色总该更浓一点。出来是一片铁锈褐，像枯死的，不像秋天。

正解和直觉正好反着来：

还有两个细节，不处理这条路就走不通。

选画：不是每幅都能这么拆

做完这一版，「下一幅画选什么」就有判据了：构图本身是不是深度分层的。

还有一条边界要提前说：雕塑和建筑本来就是3D的，对它们做「3D化」这个动作根本不成立，得换动作，换素材没用。

这一幅的账，以及那50积分的教训

这张账我只能给到总账这一级，原因写在表后面。

上面那两个余额是当时从界面上抄下来的实读值，5次生成也是实数。但逐笔是哪一次花了多少，我当时没有一笔一笔记。所以别去做200÷5这道除法：它得出的40只是个平均数，不等于任何一档的单价，同一轮里不同贴图档位的价格本来就不一样。这本书里凡是出现「这一件多少积分」的地方，背后都有一条对得上的余额流水；这一幅没有，那就只报总账。有总账没逐笔就直说，比硬凑一张看起来很完整的表可信。

可行性过关之后，第一版能点的成品只花了19分钟。这个数字我自己也愣了一下。制作是快的，慢的是前面那一下判断：哪层该立。而判断不花积分。

已知不足

这一版摆在这儿的问题，我没打算藏：3D柏树比画里那棵略大略高，合拢时画里的会露出一点边；村庄模型偏暗、辨识度不如柏树；星月层的Z间隔太小，展开后几乎看不出它是独立一层；每层点开只有一句我自己的判断，还没接梵高书信原文（要接就必须去vangoghletters.org逐句核实，不能凭印象写）；移动端没测。

§22世界类：一颗你走得完的星球

Teaching Demos III: Building a Small World You Can Live In

这节读完，你能用一条流水线把十几个资产成批做出来并接进一个能走进去的世界，也会知道这类项目真正的瓶颈在哪（提示：不是三角形）。我用《小王子》做了三个版本的星球，16个资产全部一次命中，840积分。

先看结果：同一本书，三种星球观

为什么做三个。星球观不定下来，后面全是白做，而它又是看图才定得了的判断。与其写三段文字让人想象，不如三个都做出来，同一个页面按123切换。让选择变成三个能走进去的东西，而不是三段形容词。

流水线：Codex出设计图，Tripo出3D

这一轮定的规矩是，每一个摆进世界的模型都先由Codex生成一张精细设计图，再送Tripo生成3D。这条流水线本身就是要验的东西。

端到端跑下来，15个静态资产加1个绑骨角色，16个全部正确。验收方式是我最推荐的那一条：读Tripo给模型自动起的名字。它给的slug就是它对形体的理解，名字里出现的东西，模型上都有。

球面本身不走Tripo。星球的几何是代码生成的（一个球加顶点位移），球面数学自己算更准；但地表长什么样交给Codex，两张2048×1024的等距圆柱贴图，白天版是暖赭石地表配鼠尾草绿地块，夜版是冷靛蓝。这又是那条分工判据的一次应用：尺寸和拓扑（附录D）归代码，观感归AI。

让主角自己走路

绑骨走的是Tripo自带的自动绑定，20积分。硬约束§06讲了全套——骨架预设要从默认的「适用于动物」换成「适用于类人角色」、第一次失败重试也扣20、导出带两条动画按下标取会取错、位移轨要切、朝向差90°。这个项目里咬过我的就是前两条。

贴图性能那一课：先量，再动手

第一版跑起来，反馈是「过于卡顿了」「性能需要优化500%」。我没有直接去减面，先量了一次，量出来的结论和直觉完全相反。下面这几张表里的毫秒数全部是浏览器侧的读数，和§20说的那个「算子耗时」是两码事，别混着读：一个量的是你的网页每帧花多久，一个量的是Tripo那边模型算多久。

渲染链只用掉了预算的八分之一。那卡顿从哪儿来？把场景里所有材质的贴图列出来，答案立刻出现：31张唯一贴图，其中8192²的10张、4096²的20张，估算显存5.0 GiB（这是按1024进位的读数，换成本书算显存的十进制口径是5.38 GB，两边是同一笔账的两种进位，口径见§12）。

处理方式是只降贴图、不碰几何，一条命令：

gltf-transform resize 产出/x.glb 网页/assets/tripo/x.glb --width 1024 --height 1024

用resize而不是optimize，后者默认会连减面一起跑，而几何根本不是瓶颈，没有理由动它。主角给2048²（他是特写对象），其余1024²。

结果是贴图显存5.0 GiB降到0.22 GiB，23倍；GLB载荷89.87 MiB降到12.30 MiB，7.31倍；三角面一个没动。逐项对照表、以及「当天记录写的97.6 MB我没能复现」这件事怎么处理的，都在§12那一节。

画质在这个观看距离上肉眼无损，王座的木纹红绒金冠、主角的脸和扣子，特写下都还在。

玫瑰的表演：把一段文本做成一套机制

原作第八章其实是一份角色机制说明书，它把动机都写明了：她因为被拆穿一个天真的谎而恼羞，于是咳嗽，好让他觉得是自己不对。而这一章的结论就是这套玩法本身，我本该照她的行为判断她，而不是照她的话。

做成机制就是：你看着的时候，她把花瓣撑起来装没事；你一走开，垂才回来。

台词全部逐字取自第八章，一句没编，四条触发规则：渴（渴到一定程度只有一半概率说实话）、冷、被拆穿、久不来看她。

整个A方向的地基只有一句话：做一件事等于把这一天的时钟往前拨。六个动词（拔树苗、打水、浇水、通火山、陪她说话、罩玻璃罩）全做一遍要1.29个单位，而一个白天只有0.56。一天绝对做不完所有事，取舍不是一条规则，是天空自己算出来的，因此也不需要任何进度条，太阳的位置就是那个进度条。

抬头那一刻，和一个相机的难题

别的星球从第一帧就挂在天上，游戏永远不提示它们。你之所以直到某一天才看见，是因为在那之前你一直低着头做那六件事。实测（站在玫瑰旁边扫八个朝向）：平视一颗都看不见，俯仰压到−0.35冒出一颗，抬到−0.95、再把镜头拉到最近，扫一圈总共能找到六颗——但同一帧里最多只装得下五颗，第六颗永远在画面外。这个区别值得说一句：六是「转一圈能看全几颗」，五才是「你一眼能看见几颗」，我一开始把两个数记混了。

三个静默的bug，全都是画面看不出来的

其一，道具埋进地里。加载时有一句grp.position.y -= bb.min.y把模型底面挪到y=0，但克隆时写的是c.position.y = y（赋值），把这个偏移抹掉了。实测王座埋了0.950米、路灯1.025米、商人的书桌反过来悬空0.430米。改成+=就好：一个字符的bug，只在把模型摆到地上那一刻才显形。

其二，一行动画把整张书桌拎走了。本来只想让抽屉里锁着的星星转一转，写的是遍历children里所有isGroup的节点，而Tripo模型正是作为一个Group挂进书桌的，于是整张桌子跟着转起来、被拎到0.9米高。修法是给星星那一组起名字、点名操作。一个容器里既有你的零件又有外来的模型，按类型遍历就是定时炸弹。

其三，主角的身高从来就没对过。第一版我以为解决了，收敛出一组很精确的数字，实际渲染出来的人只有0.79米，和1.01米的书桌摆在一起比桌面还矮。根因是三处测量问题叠在一起：量的是世界Y的极值（人一摆到球面上就是斜的）、蒙皮矩阵没刷新、于是在一组假数据上做了一次正确的拟合。三处的完整拆解和修法在§06。

这三条的共同点是：画面只会告诉你「这东西看着不对」，告诉你「埋了0.95米」的是数。所以我写了一个无头浏览器的自检脚本，逐个道具瞬移取景、量真高和离地间隙、出图。有它之前，我靠肉眼从截图上估比例，连续判错了三次。

还有一次，我把好模型判成了坏模型

我曾经判定玫瑰和狐狸都重建失败了，两次都是错的。错在读图的方式：我是在夜景、低角度、贴得很近的截图里判的，那种条件下低面数模型会退化成剪影。更关键的是，我没有先去看Tripo自己的预览就下了结论，而那是免费、直接、权威的一手证据。

这一颗的账

三个能走进去的世界、17个资产、一个会走路会表演的主角，不到四十块钱。花掉的小时数才是大头，而那些小时几乎全用在两件事上：搭一条能重复跑的流水线，和一套能揪出静默错误的自检。

附录A资源包索引

Appendix A · Resource Kit Index

这本书用到的全部模型的逐件数据：多少面、几张贴图、有没有骨骼、对应哪张设计图、当初那句提示词怎么写的、花了多少积分。要复现哪一件，从这张表开始查。

先说这些数字是怎么来的。不是抄Tripo界面上显示的，是用脚本直接读每个GLB文件的12字节头和后面的JSON块算出来的，贴图尺寸从二进制块里的PNG / JPEG文件头取，不装任何三方库、全程只读，没有改动过任何源文件。所以这些数字是文件本身的数字，和你把同一个文件拖进Blender或three.js量出来的应该一致。

体积这一列按1024进位，单位写作MiB（1 MiB等于1,048,576字节）。拿它对文件的时候：Windows资源管理器也按1024进位，读数和这里对得上；macOS的访达按1000进位，同一个文件它显示的数会比这里大4.9%，不是拷贝出了问题。全书正文讲贴图与显存那笔账用的是另一个口径——十进制MB，1 MB当100万字节（§12写了为什么），差的也是这4.9%。看单位就能分辨：写MiB的是这份索引里的文件体积，写MB的是正文那笔账。下面G组那段把同一批文件的两套数并排放了一次。

大多数组给两张表：前一张是几何与贴图，后一张是它从哪张设计图、哪句提示词来的（G组和H组因为输入图都还在Tripo账号里能原样取回，后一张表改成列生成参数与积分）。几个列要先说清楚（这几列里的术语——贴图、ORM、绑骨、关节——附录D都用人话讲过一遍）：

• 三角面/顶点：glTF accessor里的真实计数。纯动画文件没有网格，两列都是「—」
• 贴图（张数 × 最大尺寸）：这一列必须连着生成模式一起读，两种模式给的东西不一样。v3.1（高精度模型）出三张：基色、法线、金属粗糙度（ORM），所以A到F这六组全是「3 ×」。P2.0（智能网格）只出一张基色，没有法线图、也没有ORM，所以G和H两组全是「1 ×」。这不是导出时漏勾了什么，是模式本身的差别，后果是同一盏灯下P2.0的件会比v3.1的哑一点，接场景之前值得在真实光照里先看一眼（§12讲怎么处理）。列里给的是张数和其中最大的那张的分辨率
• 绑骨/动画：关节数+动画片段名。全资源包只有E组这三件有骨骼
• 提示词：这批提示词都是「风格：…。画面内容：…」的两段式，风格那段一组里共用，单独引在表前；表格里给的是画面内容那段的逐字前60字，后面用省略号截断。完整提示词在资源包的jobs.jsonl里

A ·巴黎街景原件（1K贴图档）· 19件· 26.4 MiB

来源项目是巴黎街景·原件（调研/实测记录/assets/），整个资源包的主干。全套走「Codex出设计图 → Tripo图生3D」这条流水线，设计图和提示词都在本地，没有第三方素材混进来。正文里巴黎那批说的是23件，那是最终进游戏的总数；这里的19件是其中留了设计图和提示词、你能照着复现的那一批。19件里9件用的是下面这句风格前缀打底，另外三种变体是角色版5件、去掉配色括号的简写版3件、载具版2件：