1. 先把链路入口钉死TaoToken Key 与 https://taotoken.net/api这篇文章只讲一条链路从 GPT-6 产出参考图到 Hyper3D Rodin 把参考图变成 3D 模型再到 BANG 把模型按结构拆成独立零件、在前端做零件级动画。整条链路里的每一次模型调用入口都在同一处——TaoToken。你要做的第一件事不是写前端也不是调 Rodin 的 MCP而是先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentchain_gpt6_rodin 拿到 Key回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentchain_gpt6_rodin 确认你的模型权限然后把请求地址统一写成https://taotoken.net/api。这件事为什么要放在最前面因为后面三段用的工具完全不同但只有入口一致你才能把三段的消耗放在同一本账上对。GPT-6 出参考图是对话 图像类请求Rodin 建模是图生 3D 的任务式请求BANG 拆零件是结构解析请求。如果每段各用一套 Key、各填一个地址链路一旦跑不通你就分不清到底是图片输入不合格、3D 任务排队还是前端装配拿了错的层级数据。入口统一之后排障顺序立刻从「猜」变成「查日志」。还有一个收益经常被忽略链路中间产物是会反复重跑的。参考图不满意要重出Rodin 的拓扑不满意要重生成零件切分粒度不对要重拆。重跑意味着重复扣 Token。只有当三段都走https://taotoken.net/api你才能在同一个调用记录里看到「哪一段在烧 Token」而不是凭感觉判断。所以本文的产出是三样东西全部可复现一张链路图、一份入口配置、三段各自的日志样例。你照着做能得到一条自己电脑上就能跑通的漏斗形流程。2. 三段式链路拆解GPT-6 出参考图、Rodin 建模、BANG 拆零件先看链路图把它当成后面所有配置的坐标系[1] 参考图阶段 prompt(风格/视角/材质) --GPT-6-- ref_01.png ... ref_0N.png 选出 1 张作为建模输入 | v [2] 建模阶段 ref_selected.png --Hyper3D Rodin-- task_id 轮询 task_id -- scene.glb (场景内含约 35 个 Object) | v [3] 拆件阶段 scene.glb --BANG 结构解析-- parts/*.glb parts.json (记录父子层级与包围盒) | v [4] 前端装配 three.js / R3F --交互代码-- 可逛、可点的 3D 作品集第一段GPT-6 出参考图。参考图不是「随便画一张好看的图」它是 Rodin 的输入契约。你要在这一段就把后面要用的信息锁死主体轮廓、正侧视角、材质倾向、光照方向。参考图越像工程图纸Rodin 的产出越稳。这一段的特点是请求次数多、单次便宜、失败成本低——你可以一次生成七八张再挑一张这在 Token 账上完全划得来。第二段Rodin 建模。这一段是异步任务模型提交图片拿到task_id然后轮询直到返回模型文件。它和第一段最大的差别在于——提交失败和生成失败是两回事。提交失败往往是鉴权或参数问题立刻能改生成失败可能是输入图对比度太低、背景太杂甚至是任务排队超时。所以这一段必须有日志否则你分不清「Key 有问题」和「图有问题」。第三段BANG 拆零件。Rodin 吐出来的scene.glb是一个整体你要做零件级动画就得按结构把它切成独立件并输出一份parts.json描述层级关系。这一段决定了前端能不能做「悬停高亮某个零件」「点击展开某个部件」这类交互。拆得太细前端渲染压力大拆得太粗动画就没有粒度。关于 Token 视角。很多人会默认「建模又不吃 Token」。但在统一入口下这三段都是调用记录里的一行。GPT-6 那段吃的是对话与图像额度Rodin 那段吃的是任务提交额度BANG 那段吃的是解析额度。视角槽里说的「GPT-6 与 Rodin 消耗 Token」本质是提醒你不要只盯着第一段做预算第二段单次消耗比第一段高一个量级而它偏偏最容易因为输入图不合格而重跑。3. 入口配置实操Claude Code、Codex、CC Switch 三件套进入配置环节。先把环境变量写好这是所有工具的共同底座# ~/.taotoken/env.sh export TAOTOKEN_BASE_URLhttps://taotoken.net/api export TAOTOKEN_API_KEYYOUR_API_KEY然后做一次连通性自检确认 Key 与 Base URL 都是通的source ~/.taotoken/env.sh curl -sS $TAOTOKEN_BASE_URL/v1/models \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ | head -c 400返回里能看到模型列表说明入口没问题。如果这里就 401别往下走先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentchain_gpt6_rodin 核对 Key 是否复制完整、是否有多余空格或换行。3.1 Claude Codesettings.json 与 ANTHROPIC_*Claude Code 走的是 Anthropic 协议族配置项是ANTHROPIC_*。推荐写进项目的.claude/settings.json这样换机器不用重新记{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: claude-sonnet-4-5, ANTHROPIC_SMALL_FAST_MODEL: claude-haiku-4-5 } }三个点必须说清楚第一ANTHROPIC_BASE_URL后面不要再加/v1。Claude Code 会自己在路径上补齐你多写一层就会 404。第二ANTHROPIC_AUTH_TOKEN和ANTHROPIC_API_KEY不是一回事。前者会直接作为 Bearer 值发出去后者在某些版本里会被包装。用ANTHROPIC_AUTH_TOKEN行为更可预期。第三ANTHROPIC_MODEL填你在控制台里实际可用的模型 ID不要照抄本文。模型列表会变以控制台为准。如果你更习惯用引号拼临时命令ANTHROPIC_BASE_URLhttps://taotoken.net/api \ ANTHROPIC_AUTH_TOKEN$TAOTOKEN_API_KEY \ claude --model claude-sonnet-4-5这种方式适合临时切换但不利于复现建议只在排障时用。3.2 Codexconfig.tomlCodex 走的是 OpenAI 兼容协议用 TOML配置项结构完全不同于 Claude Code。不要把ANTHROPIC_*套到 Codex 上那是最常见的配置事故# ~/.codex/config.toml model gpt-6 model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api wire_api chat env_key TAOTOKEN_API_KEY [profiles.rodin_chain] model gpt-6 model_provider taotoken注意env_key填的是环境变量名不是 Key 本身。真正的 Key 放在TAOTOKEN_API_KEY里通过source ~/.taotoken/env.sh注入。这样配置文件可以进 Git密钥不会。wire_api用来声明协议类型。如果你的 Codex 版本对响应式接口有要求把它改成对应的值再试改完记得重启终端环境变量不会热加载。3.3 CC Switch 三件套如果你同时维护多条链路比如一条走参考图、一条走代码补全来回改配置文件会崩溃。CC Switch 的思路是把「一套可用配置」抽象成三件套三件套 1. 供应商地址 : https://taotoken.net/api 2. 密钥 : YOUR_API_KEY 3. 模型名 : 按控制台可用列表填写在 CC Switch 里新建一个 profile把这三项填进去命名成taotoken-rodin-chain。之后在项目里切 profile而不是手改settings.json或config.toml。三条链路的差异就收敛成「切哪张 profile」而不是「今天又改坏了哪个文件」。三件套里最容易填错的是第三项。地址对了、Key 对了模型名写了控制台没开的那个报错会伪装成「鉴权失败」。遇到这种「Key 明明是对的却 401」先怀疑模型名。4. 各段日志怎么读Token 消耗与失败定位配置跑通之后真正的工作才刚开始读日志。下面三段日志是链路跑通时的正常形态你可以拿它当基线做对照。第一段参考图生成[chainref] POST https://taotoken.net/api/v1/chat/completions [chainref] modelgpt-6 streamtrue [chainref] prompt_tokens812 completion_tokens346 total1158 [chainref] status200 latency3.1s [chainref] artifactref_03.png selectedtrue读法prompt_tokens大而completion_tokens小说明你在提示词上写得很细这是好事。参考图阶段的对手是「重出次数」不是单次 Token。一次生成 8 张成本也远低于 Rodin 重跑一次。如果这一段反复 400先看提示词里有没有超长描述或者结构化字段写错而不是急着换模型。第二段Rodin 建模[chainrodin] POST https://taotoken.net/api/v1/tasks [chainrodin] inputref_03.png modeimage_to_3d [chainrodin] task_idrdn_xxxxxxxx statusqueued [chainrodin] poll#1 statusrunning progress18% [chainrodin] poll#9 statussucceeded elapsed214s [chainrodin] artifactscene.glb objects35 [chainrodin] usage: task_credits1 total_tokens0读法这一段的关键字段是status和elapsed。queued停留时间过长是排队不是你的问题running卡在某个百分比不动通常是输入图的问题。判断依据很简单——如果连续两次重跑都卡在同一个 progress换参考图别换 Key。objects35是后面 BANG 拆件的输入规模这个数字要记下来它直接决定前端渲染压力。第三段BANG 拆件[chainbang] POST https://taotoken.net/api/v1/chat/completions [chainbang] inputscene.glb modestructural_split [chainbang] parts_detected35 groups7 [chainbang] artifactparts/ parts_indexparts.json [chainbang] usage: prompt_tokens1204 completion_tokens891 total2095 [chainbang] warn: 3 parts share identical bounding box读法parts_detected和上一段的objects对不上说明有零件被合并或漏切。最后那行warn很有价值——多个零件共用包围盒意味着它们在前端无法独立做动画悬停时会被一起选中。这是需要回炉的信号。三段对账。把三段日志按chain前缀捞出来你就能算出这条链路的总消耗结构第一段便宜且高频第二段贵但低频第三段中等且和模型复杂度正相关。这个结构决定了优化方向——优化第一段的提示词收益是省下第二段的重跑优化第三段的分组策略收益是省下前端返工。这才是「GPT-6 与 Rodin 消耗 Token」这个视角真正想让你看见的东西。5. 可复现产出链路图、配置快照与日志归档链路能跑一次不算数能重复跑才算数。建议在项目根目录建三个文件3d-chain/ ├── chain.md # 第 2 节那张链路图标注每段的输入输出 ├── config.snapshot/ # settings.json config.toml CC Switch profile 导出 └── logs/ ├── ref.log ├── rodin.log └── bang.logconfig.snapshot/里所有 Key 一律写成YOUR_API_KEY真实值只留在环境变量里。这样快照可以进 Git团队里换个人也能照着复现而不是来问你「你那个地址填的是啥」。日志归档有个小技巧每段日志开头固定打一行[chainxxx]和一行时间戳后面用grep就能按段切分grep ^\[chainrodin\] logs/*.log | tail -n 50 grep -E status(4|5)[0-9]{2} logs/*.log第二条命令是排障主力它能一次性把所有失败请求捞出来你不用一页页翻。还有一个容易漏的产出参考图与模型的版本对应表。因为参考图会重出、模型会重生成如果不记录「scene_v3 用的是 ref_03」一周后你根本不知道当前线上模型是哪张图来的。用最朴素的方式记就行ref_01.png - scene_v1.glb (废弃: 拓扑断裂) ref_03.png - scene_v2.glb (使用中: objects35 parts35) ref_05.png - scene_v3.glb (实验: objects41)6. 常见坑与排查清单把这条链路里最容易踩的坑按出现频率排一下。坑一Base URL 写成带 /v1。Claude Code 会在ANTHROPIC_BASE_URL后面自动补路径你写成https://taotoken.net/api/v1最终请求就多一层。统一写https://taotoken.net/api。坑二把 ANTHROPIC_配到 Codex。* 两套协议、两套字段互不通用。Codex 只认config.toml里的model_providers结构。坑三Key 里混进换行。从控制台复制时很容易带上尾部空格或换行表现为「明明是对的却 401」。用echo -n $TAOTOKEN_API_KEY | wc -c数一下长度和页面上显示的对比。坑四参考图背景太杂。Rodin 的输入越干净越好。纯色背景、单一主体、明确视角这三条做到了第二段的重跑率会明显下降。坑五BANG 拆件粒度失控。一次拆出几百个小件前端直接卡死。合理的做法是先按功能分组再在组内决定是否需要到零件级。分组数量控制在个位数到十几个之间比较稳妥。坑六把建模任务当成同步接口调。Rodin 是异步的必须轮询。轮询间隔别太短也别太长十几秒一次是常见区间。坑七前端直接消费 scene.glb。零件级动画需要的是parts.json里的层级关系不是整包 glb。先把层级读进来建索引再去挂动画。排查顺序建议固定下来先curl验入口 → 再跑第一段日志 → 再跑第二段任务 → 最后跑第三段拆件。哪一步断了就停在哪一步不要跳步。跳步的代价是你会同时面对两个变量而排障最忌讳多变量。7. 从一条链路到可复用工作流到这里链路、配置、日志三样都齐了。回看一下这条链路的形状入口只有一处中间有三段每段都有明确的输入输出和可归档的日志。GPT-6 负责把模糊的创意变成结构化的参考图Rodin 负责把 2D 参考变成 3D 资产BANG 负责把整体资产变成可编程的零件集合前端把零件集合变成可交互的体验。它的可复用性不在代码里而在那三个产出文件里。链路图让你知道每段该接什么配置快照让新机器十分钟能跑起来日志归档让你在第三周还能定位到问题。这三样东西加起来才叫「一条链路」。如果你准备把这条链路接到自己的项目里建议按下面的顺序动手先去模型对话页把 GPT-6 的参考图提示词调顺确认自己能稳定出干净的输入图再回来配 Coding Plan把三段调用统一到https://taotoken.net/api然后创建 Key把YOUR_API_KEY替换进环境变量跑通连通性自检最后对着 Claude Code 文档把settings.json落地把链路固化下来。四个入口按顺序走完你会得到一条自己机器上随时能重跑的链路而不是一篇看完就忘的教程模型对话https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchain_gpt6_rodinCoding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentchain_gpt6_rodinAPI Keyshttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentchain_gpt6_rodinClaude Code 文档https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentchain_gpt6_rodin最后提醒一句整条链路里真正贵的从来不是第一段。参考图便宜、可重试Rodin 那一跳才是成本大头而它的成败几乎完全由第一段的输入质量决定。把功夫花在参考图上是这条链路上性价比最高的投资。
