企业官网建设流程全解析

1. 小说拆短剧素材的真实痛点：为什么手工拆解跑不通

把一本几十万字的小说改成短剧拍摄素材，听起来像是"读一遍、列个表"的事，真上手才知道是个体力活。我拿一本 38 万字的长篇试过，光是角色出场统计就花了两天：谁在第几章出现、和主角什么关系、有没有外貌描写、说话什么调性，全靠人肉翻。等角色表勉强成型，场景清单又来了——同一间咖啡馆在书里被写成"街角那家店""她常去的咖啡厅""落地窗边的位置"，你得判断这是不是同一个景，不然美术出图会重复劳动。

短剧行业的节奏不允许这么磨。一部竖屏短剧从立项到开机常常只有两三周，素材准备阶段要同时产出角色设定集、分集大纲、场景道具清单三套东西。传统做法是编剧、策划、美术各拆一遍，信息对不齐，改一版小说就得全部重来。更麻烦的是质量没法验证：大纲写得好不好、角色有没有漏，全靠人盯，换个执行的人标准就变了。

这就是 shuohao-skills 想解决的问题。它把"小说→短剧素材"拆成三个可独立运行的 Agent Skill：novel-characters 负责角色设定集，novel-outline 负责短剧改编大纲，novel-art 负责美术设定集。每个 Skill 自带 SKILL.md 给 Agent 读、scripts/ 放零依赖的 Node.js 脚本、references/ 存详细指令、examples/ 放样例数据。你不需要 npm install，Node 标准库就够跑。

它最有意思的设计是质量门脚本化。传统 AI 写作工具靠模型自己判断"写得好不好"，同一段提示词跑两次结果可能天差地别。shuohao-skills 反过来，novel-outline 有 13 道质量门、novel-art 有 11 道质量门，全部用确定性脚本检查，每个 skill 自带 selftest.mjs，不调用模型、不花额度，一秒跑完。这意味着质量评估可重复、可验证，不是"薛定谔的 AI"。

但要让这套流程真正跑起来，你得先解决一个前置问题：Claude Code、Codex 这些 Agent 各自要配 Key、配 Base URL、配模型 ID，三个 Skill 串起来跑的时候，Key 管理会变成新的体力活。这篇就按"小说→短剧素材自动化拆解"这条线，把 shuohao-skills 和 TaoToken 统一 Key 的接入一起讲清楚，给出可复制的 Node.js 脚本配置、接入步骤，以及用样例小说跑通并校验输出完整性的验证动作。

适合谁看：写小说想做短剧改编的作者、短剧工作室的技术同学、已经在用 Claude Code 或 Codex 的 Agent 使用者。如果你只是想要个简单文字生成工具，这篇的流程对你偏重了。

2. TaoToken 统一 Key 前置：给三个 Agent Skill 配一套凭证

shuohao-skills 本身不依赖外部 API，它的脚本只用 Node 标准库。但它的三个 Skill 是要交给 Claude Code、Codex 这类编码 Agent 去执行的，Agent 干活时得调用模型，这就绕不开凭证配置。如果你同时用 Claude Code 和 Codex，两边各配一套 Key、各记一个 Base URL，切换时容易搞混，尤其是把三个 Skill 串成流水线跑的时候，中间某个 Agent 认证失败，整条链就断在那里。

TaoToken 在这里的角色是统一入口：一个 Key 覆盖多个模型，Base URL 固定，模型 ID 按需切换。你不用为每个 Agent 单独申请凭证，也不用在多个控制台之间来回找配置。对 shuohao-skills 这种"三个 Skill 接力跑"的场景，统一 Key 的价值很直接——角色抽取用哪个模型、大纲生成用哪个模型、美术清单用哪个模型，你只改 Model ID，认证部分不动。

先把账号和 Key 准备好。打开官网 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 注册登录，进控制台 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite 创建 API Key。Key 只在创建时完整显示一次，复制后先存到本地环境变量，别直接写进脚本提交到 git。

创建完 Key，去 API Keys 页面 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite 可以随时查看和管理已有 Key。如果你要确认某个模型当前可用、或者想先手动试一段提示词，用模型对话页面 https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=chat&utm_campaign=rewrite 直接对话验证，比在脚本里反复调试快。

API 的基础地址是 https://taotoken.net/api，注意这个地址不带 UTM 参数，配置时原样填。模型 ID 按你实际要用的填，比如跑角色抽取这种需要长上下文理解的任务，选上下文窗口大的模型；跑大纲结构整理这种偏格式化的任务，选响应快的模型。具体可用模型列表在文档 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 里查，别凭记忆填。

环境变量这样设，macOS 和 Linux 用 export，Windows 用 set 或写进系统环境变量：

export TAOTOKEN_API_KEY="sk-你的Key" export TAOTOKEN_BASE_URL="https://taotoken.net/api"

设完验证一下有没有生效：

echo $TAOTOKEN_API_KEY echo $TAOTOKEN_BASE_URL

两个都打印出正确值再往下走。如果第一个是空的，说明当前终端会话没读到，检查是不是写进了别的 shell 配置文件，或者新开一个终端窗口重试。

这里有个容易踩的坑：Claude Code 和 Codex 读取环境变量的时机不一样。Claude Code 通常在启动时读一次，你中途改了环境变量它不认；Codex 有些版本每次请求都读。所以配好环境变量后，把两个 Agent 都重启一遍，别在运行中的会话里改配置然后纳闷为什么不生效。

如果你打算长期跑这套短剧素材流水线，尤其是要反复处理多本小说，可以考虑 Coding Plan https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite，它在连续编码和 Agent 长任务场景下更省心，不用每次盯着额度。

3. 可复制配置：shuohao-skills 与 Agent 的 settings 片段

这一节给可直接复制的配置。shuohao-skills 的安装脚本会自动检测本机装了 Claude Code 还是 Codex，然后软链过去，git pull 后立刻生效。但软链只解决 Skill 文件的位置问题，Agent 调用模型时的认证配置还得你自己写。下面按 Claude Code、Codex、以及一个通用的 Node.js 调用脚本三部分给。

先克隆并安装：

git clone https://github.com/eternityspring/shuohao-skills.git cd shuohao-skills ./scripts/install.sh

前置条件是 Node ≥ 18。装完检查一下 Node 版本：

node -v

低于 18 的话先升级，脚本里用了一些较新的标准库 API，低版本会报错。

3.1 Claude Code 的 settings 配置

Claude Code 的配置放在用户目录下的 settings 文件里。路径按你的系统来，macOS 和 Linux 通常是~/.claude/settings.json，Windows 是%USERPROFILE%\.claude\settings.json。内容这样写：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_API_KEY": "sk-你的Key", "ANTHROPIC_MODEL": "你的模型ID" } }

三件套齐了：Base URL 指向 TaoToken 的 API 地址，Key 用你创建的那把，Model ID 填你要用的模型。注意 JSON 里不能有注释，末尾不能有多余逗号，否则 Claude Code 启动时会静默忽略整个配置，你会以为配了其实没配。

改完重启 Claude Code。验证配置有没有被读到，可以在 Claude Code 里问它当前用的模型是什么，或者直接跑一个简单任务看有没有认证报错。

3.2 Codex 的 auth.json 配置

Codex 的凭证放在~/.codex/auth.json，Windows 是%USERPROFILE%\.codex\auth.json。这个文件同时管认证和模型设置，格式如下：

{ "OPENAI_API_KEY": "sk-你的Key", "OPENAI_BASE_URL": "https://taotoken.net/api", "model": "你的模型ID" }

同样三件套：Base URL、Key、Model ID。Codex 对 Base URL 的末尾斜杠比较敏感，填https://taotoken.net/api就行，别多加/v1之类的后缀，除非文档明确说明。改完重启 Codex。

如果你两个 Agent 都要用，建议把 Key 存成环境变量，配置文件里引用环境变量而不是硬编码。这样换 Key 的时候只改一处。不过要注意，不是所有版本的 Agent 都支持在配置文件里写环境变量引用语法，写之前先确认你的版本支持，不支持就老老实实填明文，但别把配置文件提交到公开仓库。

3.3 通用 Node.js 调用脚本

shuohao-skills 的 Skill 是给 Agent 读的，但你可能想自己写个脚本把三个 Skill 串起来跑，或者在 CI 里做批量处理。下面这个 Node.js 脚本用标准库的 fetch 调用 TaoToken API，不依赖任何 npm 包：

// pipeline.mjs const API_KEY = process.env.TAOTOKEN_API_KEY; const BASE_URL = process.env.TAOTOKEN_BASE_URL; const MODEL_ID = process.env.TAOTOKEN_MODEL_ID || "你的模型ID"; if (!API_KEY || !BASE_URL) { console.error("缺少 TAOTOKEN_API_KEY 或 TAOTOKEN_BASE_URL"); process.exit(1); } async function callModel(prompt, systemPrompt = "") { const res = await fetch(`${BASE_URL}/v1/chat/completions`, { method: "POST", headers: { "Content-Type": "application/json", "Authorization": `Bearer ${API_KEY}` }, body: JSON.stringify({ model: MODEL_ID, messages: [ ...(systemPrompt ? [{ role: "system", content: systemPrompt }] : []), { role: "user", content: prompt } ], temperature: 0.3 }) }); if (!res.ok) { const text = await res.text(); throw new Error(`请求失败 ${res.status}: ${text}`); } const data = await res.json(); return data.choices[0].message.content; } // 示例：抽取一章的角色出场 const chapterText = `把小说某一章的正文放这里`; const result = await callModel( `从下面这段小说文本中抽取所有出场角色，输出 JSON 数组，每个元素包含 name、role、first_appearance、description 四个字段。\n\n${chapterText}`, "你是一个短剧素材拆解助手，只输出合法 JSON，不要额外解释。" ); console.log(result);

跑之前设好环境变量：

export TAOTOKEN_MODEL_ID="你的模型ID" node pipeline.mjs

这个脚本是骨架，实际串流水线时，你把 novel-characters、novel-outline、novel-art 三个 Skill 的 references 里的指令读出来当 system prompt，把上一环的输出当下一环的输入，就形成了一条链。temperature 设 0.3 是为了让结构化输出稳定一些，角色抽取和大纲生成都不需要太高的创造性。

4. 验证请求：用样例小说跑通并校验输出完整性

配置写完不算完，得用真实数据跑一遍，确认三个 Skill 的输出能接上。shuohao-skills 的 examples/ 目录里有样例数据，先用它验证流程，再换你自己的小说。

第一步，确认 Skill 被 Agent 识别到。在 Claude Code 里输入类似"列出当前可用的 skills"的指令，看 novel-characters、novel-outline、novel-art 三个有没有出现在列表里。没有的话检查 install.sh 的软链目标对不对，或者手动把 skills 目录拷到 Agent 的 skills 路径下。

第二步，跑 novel-characters。把样例小说的前几章喂进去，让它输出角色设定集。观察输出结构：每个角色是不是有名字、定位、外貌提示词、音色建议这些字段。这一步的验证点是"角色有没有漏"——你可以人工数一下样例文本里明显有名字的角色数量，和输出对比。

第三步，跑 novel-outline。它吃的是小说结构，输出分集梗概和爽点表。跑完看它有没有生成 outline.json，这个文件是给 novel-art 用的接口。验证点是 13 道质量门有没有全过。质量门是脚本检查，不调模型，你可以单独跑：

node skills/novel-outline/scripts/selftest.mjs

一秒出结果。如果有门没过，脚本会告诉你哪一项不达标，比如"分集数量少于预期""爽点表字段缺失"之类。按提示补数据重跑，别跳过。

第四步，跑 novel-art。它读 outline.json 预填场景和道具清单，然后生成美术设定。验证点是 11 道质量门，同样用 selftest.mjs 跑：

node skills/novel-art/scripts/selftest.mjs

注意出图功能依赖 Codex 的 $imagegen，没配置的时候会跳过出图，只输出清单和提示词。这不影响流程验证，你先把清单跑通，出图后面再补。

第五步，做端到端校验。三个 Skill 都跑完后，检查数据接口有没有断：novel-outline 输出的 outline.json 里的场景名，和 novel-art 读进去预填的清单是不是一致；novel-characters 输出的角色名，在大纲的分集梗概里有没有对应出现。这一步是人工抽查，抽三五个角色和场景对一下，确认没有"角色表里有、大纲里没提"或者"大纲里有场景、美术清单漏了"的情况。

我实测下来，样例小说跑完整条链大概几分钟，主要时间花在模型调用上，脚本检查部分基本是秒级。跑通之后换你自己的小说，先拿一章试，确认输出结构对，再整本跑。整本跑的时候注意上下文长度，超长的文本要按章节切分后分批喂，别一次性塞进去。

5. 本篇常见错排查：401、local proxy failed 与 choices 读取失败

跑这套流程会碰到几类典型报错，这里按真实报错信息对照排查。

401 Unauthorized。最常见的原因是 Key 没读到或者填错。先确认环境变量：

echo $TAOTOKEN_API_KEY

如果打印为空，说明当前会话没读到。检查你是不是在配置文件里写了 Key 但 Agent 没重启，或者环境变量写进了~/.bashrc但当前用的是 zsh。另一个原因是 Key 复制时带了空格或换行，重新复制一遍，注意首尾不要有多余字符。还有一种情况是 Key 被删了或者过期了，去 API Keys 页面 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite 确认一下状态。

local proxy failed。这个报错通常出现在 Agent 尝试走本地代理但代理没起来的时候。检查你的环境变量里有没有HTTP_PROXY、HTTPS_PROXY这类设置，如果有但代理服务没运行，请求就会失败。把这两个变量临时清掉再试：

unset HTTP_PROXY unset HTTPS_PROXY

如果清了就好了，说明是代理配置的问题，不是 TaoToken 的问题。另外确认 Base URL 填的是https://taotoken.net/api，没有多写路径或者拼错。

reading 'choices' 报错。典型信息是Cannot read properties of undefined (reading 'choices')。这说明脚本拿到了响应，但响应结构里没有 choices 字段。原因通常是 API 返回了错误信息而不是正常结果，但脚本没检查 res.ok 就直接读 data.choices。上面给的 Node.js 脚本里加了if (!res.ok)的判断，如果你自己写的脚本没加，补上。另一个原因是模型 ID 填错了，API 返回了"模型不存在"之类的错误，同样会走到读 choices 那一步失败。去文档 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 核对模型 ID 的准确写法。

OAuth 相关报错。如果你用的是 Claude Code，可能会碰到 OAuth token 相关的提示。这通常是因为 Claude Code 同时存在 OAuth 登录态和 API Key 配置，两者冲突了。解决办法是明确用 API Key 模式，在 settings.json 里配好ANTHROPIC_API_KEY和ANTHROPIC_BASE_URL，然后退出 OAuth 登录态。Codex 那边类似，auth.json 里配了 API Key 就不要再用 OAuth 登录。

Skill 没被识别。install.sh 跑完但 Agent 里看不到 skill，检查软链目标。macOS 和 Linux 下：

ls -la ~/.claude/skills/

看三个 skill 目录是不是软链到了 shuohao-skills 的 skills 目录下。如果软链断了（比如你移动了仓库位置），重新跑 install.sh。Windows 下软链需要管理员权限，如果 install.sh 没成功，手动把 skills 目录拷过去。

selftest.mjs 报错。质量门脚本报错通常是输入数据格式不对。检查上一环输出的 JSON 是不是合法，字段名有没有拼错。selftest 不调模型，所以报错一定是数据问题，不是认证问题。用node -e "JSON.parse(require('fs').readFileSync('outline.json','utf8'))"验证一下 JSON 合法性。

6. 把流水线跑顺：从单本试跑到批量处理的接入路径

三个 Skill 单独跑通之后，真正的效率提升来自把它们串成流水线。我的做法是写一个调度脚本，按 novel-characters → novel-outline → novel-art 的顺序调用，每一环的输出落盘成 JSON，下一环读上一环的文件。这样中间任何一环出问题，你可以单独重跑那一环，不用从头来。

调度脚本的核心逻辑不复杂：读小说文本、按章节切分、对每一章调角色抽取、汇总去重、把汇总结果喂给大纲生成、大纲输出 outline.json、再喂给美术清单。切分章节的时候注意保留章节标题，大纲生成需要靠标题判断结构。去重角色的时候按名字合并，同一个人在不同章节的不同称呼要人工确认一下，脚本可以做模糊匹配但别全自动，容易把两个人合成一个。

批量处理多本小说的时候，给每本书建一个独立目录，输入、中间产物、最终输出分开存。这样出问题好定位，也方便对比不同书的输出质量。Key 的管理用环境变量，别在每本书的配置里重复写。如果你要跑的量比较大，Coding Plan https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite 在长任务场景下比按次调用更合适。

接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite，里面有针对不同 Agent 的配置说明和模型列表。遇到认证或者接口格式的问题，先翻文档，大部分报错文档里都有对应说明。想快速验证某个模型适不适合你的小说拆解任务，用模型对话 https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=chat&utm_campaign=rewrite 手动试几段，比在脚本里反复改参数快得多。

最后提醒一句：shuohao-skills 目前主要在 macOS + Node 24 上验证过，Linux 和低版本 Node 没测试。你在别的环境跑，碰到脚本报错先确认 Node 版本，再确认文件路径分隔符。Windows 下路径用反斜杠，脚本里如果写死了正斜杠可能会找不到文件。这些环境差异不影响流程本身，但会让你多花时间排查，提前知道能省事。