原文作者开了一个“套娃”的脑洞既然 Skill 能把专业知识、工作流和工具集成封装成模块那就先做一个专门生产 Skill 的 Skill命名为 skill-creator。它不写死任何业务逻辑只理解用户给出的功能描述、使用场景和示例用法然后输出结构完整的 SKILL.md并规划好 references/、scripts/、assets/ 该放什么内容。我读了这份设计稿决定让它产出我的第一个交付物Docker 部署 Ollama 模型的操作型 Skill。动手前先把 Claude Code 的模型通道指到 TaoToken打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建 API Key再把环境变量指到新的 Base URL剩下的事情交给 skill-creator 按渐进式展开原则逐层生成。1. 为什么要造一个“自动生成 Skill”的 Skill1.1 入口很轻产地很重平时写 Skill 容易把入口写得很重。description 写得含糊Claude 不知道什么场景触发它正文一股脑塞几百行细节token 全被吃掉。skill-creator 给出的解法是先定骨架再填血肉最后把重量内容拆到按需加载的文件里。用户只需要给三个要素功能描述、使用场景、示例用法。这个设计思路对应一个朴素判断Skill 不是文档而是“另一个 Claude 实例的入职指南”。它要为那个不太了解你业务的模型省去摸索时间把该知道的程序性知识提前整理好。所以入口文件必须轻到能一眼看清“什么时候用”而重内容放在按需加载区用到才读。1.2 三个输入一套输出例如我这次要生成 Docker 部署 Ollama 的 Skill可以先在对话里这样描述功能描述在 Docker 容器中部署 Ollama 模型服务包含镜像拉取、模型下载、端口映射、持久化存储、健康检查。使用场景本机或 Linux 服务器上没有现成 Ollama 环境需要容器化交付、排查容器日志。示例用法“帮我写一个 Docker 部署 Ollama 的 Skill要求模型目录挂载到宿主机。”这段描述不需要很完美关键是让 skill-creator 知道边界做什么、给谁用、用户会怎么触发。后面的结构设计交给它。skill-creator 的价值不在于替你写代码而在于把散乱的需求翻译成一套符合上下文节约原则的 Skill 目录结构。2. 配置模型通道先拿 Key再把 Claude Code 指向 TaoToken2.1 去 TaoToken 创建 API Key准备材料只有两样一个 API Key一个模型 ID。Key 在 TaoToken 的“创建 Key”页面生成模型 ID 不要凭记忆敲打开官网模型广场以列表里当时显示的 ID 为准。TaoToken 做的是统一接入Claude Code、Codex 这类工具都可以把它的 API 当作模型通道来用Anthropic 兼容和 OpenAI 兼容都有对应接入方式这篇只走 Claude Code 路线。2.2 把环境变量写进 ~/.claude/settings.jsonClaude Code 原生读几个环境变量不用改程序本身只需在配置文件里加一段 env{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: 以 TaoToken 模型广场为准 } }这里有两个易错点。第一Base URL 是https://taotoken.net/api末尾不要加/v1第二ANTHROPIC_MODEL不要写死具体型号因为模型 ID 会随模型广场列表更新而变化填之前对照 2.1 的官网链接。Key 就是占位符YOUR_API_KEY从控制台复制后不要带多余空格。改完保存重启 Claude Code 让配置生效。2.3 先做一次连通性确认配置完发一条不碰业务的消息比如“只回答 OK, no tool calls”。如果正常收到回复说明这条通道已经通了如果一直转圈或者直接抛 401跳到第 6 章排障。确认连通之后再加载 skill-creator避免把 Key 问题和 Skill 问题混在一起排查。这个顺序很重要——通道没通时所有报错都长得很像你分不清是模型不可用还是 Skill 写坏了。3. skill-creator 的内部骨架SKILL.md 的渐进度3.1 元数据是唯一的触发开关skill-creator 生成的第一个文件永远是 SKILL.md它的头部 YAML 会被 Claude 常驻在上下文中所以 name 和 description 必须把“什么时候使用”说清楚。以 Docker/Ollama Skill 为例description 要包含镜像、容器、端口映射、模型下载这几个触发词但别把操作步骤写进去——步骤只在触发后加载写在 description 里既浪费常驻 token又不会让触发更准确。--- name: docker-ollama-deploy description: 在 Docker 容器中部署 Ollama 模型服务的操作指南。当用户需要拉取 Ollama 镜像、下载模型、映射端口、挂载模型目录、查看容器日志时触发。 ---3.2 正文只保留路径细节全部外置skill-creator 的核心理念是“上下文窗口是公共资源”。每个 Skill 都要跟系统提示词、对话历史、其他元数据争抢 token所以它的 SKILL.md 正文通常不超过 500 行接近这个上限就把内容拆到 references/。比如本 Skill 的正文只写主干流程拉镜像、起容器、映射端口、下载模型、健康检查每步一句指引详细的官方参数表放到 references/ollama-params.md。3.3 三种资源的放法scripts/放需要在本地执行的确定性脚本比如deploy_ollama.sh。脚本只在运行时被读取不占用常驻上下文。references/放按需加载的文档比如 Ollama 模型清单、GPU 配置说明。SKILL.md 里写明“遇到 GPU 问题先 grep references/gpu.md”。assets/放最终输出的模板比如 docker-compose.yml 样板。这套结构既保证入口极简又让复杂任务有地方展开。skill-creator 生成时会自动补齐目录结构并初始化示例文件省掉手工建目录的步骤。3.4 自由度Docker 部署该给多少自由skill-creator 的原文里有一组“自由度”设计直接决定 SKILL.md 的口吻。高自由度适合文本类指令比如“调整镜像选择策略”低自由度适合容易出错的固定操作比如端口映射和磁盘挂载。Docker 部署 Ollama 属于典型的中低自由度镜像版本、挂载路径、端口冲突这些敏感参数必须给具体示例而“先用哪个模型试跑”这种决策可以留给你自己判断。生成 Skill 时可以让 skill-creator 把关键命令做成带占位符的脚本放 scripts/SKILL.md 只留一句“按实际环境修改变量后执行”既保住确定性又不让正文显得啰嗦。4. 让 skill-creator 生成 Docker 部署 Ollama 的 Skill4.1 五步流程在对话里怎么走skill-creator 自带的流程不是让用户一次性交全所有信息。它先问一两个问题确认边界“部署在 Linux 还是 macOS”“要不要 GPU 支持”然后按五步走理解示例、规划可复用内容、初始化目录、编辑 SKILL.md、打包迭代。在 Claude Code 里加载这个 Skill 之后把第 2 节的三要素输入它会先给出规划清单再逐步生成文件。4.2 给 skill-creator 的需求示例为了让输出更贴近实际我在对话里补了一条约束所有 Docker 部署命令要在正文中注明“由读者在本地终端执行AI 只负责生成和解释命令”不要让模型误以为自己能操作宿主机。完整的输入大致是请用 skill-creator 生成一个 Skill 名称docker-ollama-deploy 功能描述在 Docker 容器中部署 Ollama 模型服务覆盖镜像拉取、模型下载、端口映射、持久化目录、健康检查。 使用场景开发者在 Linux 服务器或本地容器环境部署 Ollama需要步骤化指导并解决常见报错。 示例用法“帮我部署 Ollama 并下载 llama3.2 模型” 约束docker 命令只在读者本地终端执行Skill 只提供命令和解释说明。4.3 生成结果的小样按这套输入skill-creator 生成的目录结构大致是docker-ollama-deploy/ ├── SKILL.md ├── scripts/ │ └── deploy_ollama.sh ├── references/ │ ├── ollama-models.md │ └── gpu-support.md └── assets/ └── docker-compose.example.ymlSKILL.md 正文里会写出本地执行命令时的重要提醒执行docker run之前先确认宿主机端口是否被占用模型目录的挂载路径要提前创建ollama pull需要等容器健康检查通过后进入容器内执行。skill-creator 生成的草稿通常已经包含这些提示你负责审核命令的准确性和路径是否符合自己的环境。4.4 生成后一定要做一次真实验收Skill 生成完不等于结束。我在临时目录里实际跑了一遍deploy_ollama.sh把报错贴回对话让 Claude Code 对照 SKILL.md 修改 references 里的参数说明。这一步对应 skill-creator“基于实际使用进行迭代”的原则——没有经过真实环境验证的 Skill 只是纸面流程。Docker 命令、镜像 tag、端口号这些信息很容易随着上游变更而过时验收时以官方仓库和模型广场当前列表为基准。5. 用 Token 消耗检验 SKILL.md 是否够精简5.1 三个加载层级对照skill-creator 把成本绑死在加载层级上元数据约 100 字常驻、SKILL.md 正文在触发后加载、references/scripts/assets 按需进入。如果生成的 SKILL.md 里出现了一大段 Docker 参数对照表就是不合格——这些内容属于 references/。我特意让 Claude Code 在新会话里重新加载这个 Skill看它在面对“部署 Ollama 失败日志看不到模型”时会不会先 grep references 而不是重新解释一遍全部参数。这一步最能暴露正文冗余。5.2 回 TaoToken 账本看数字验证不只看效果也看成本。打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的用量页能看到这次 skill-creator 生成过程的请求次数和 Token 消耗。重点观察生成后第一次实际调用的数字如果常驻上下文一直很高说明 description 或者正文有冗余如果按需加载生效你会发现第二次对话重新加载 Skill 时 Token 消耗明显低于第一次完整生成过程——这意味着 Skill 已经把知识固化到文件里了。5.3 五条检验清单SKILL.md 正文是否只写了流程和触发条件没有大段手册式内容references 中信息是否与正文重复重复则删掉一边scripts 是否真的可执行建议在临时目录跑一遍部署脚本description 里是否包含足够触发词能让 Claude 准确识别使用时机用会话里的实际 token 读数判断精简度不用主观感觉6. 接通 TaoToken 后最容易翻车的两个现场6.1 Base URL 多写了 /v1Claude Code 走 Anthropic 兼容通道时很容易习惯性写成https://taotoken.net/api/v1翻车现场就是请求全部 404。Anthropic 风格接口在 TaoToken 这一层已经把路由对齐好Base URL 填https://taotoken.net/api即可末尾不要跟任何路径。遇到 404 时优先检查 settings.json 的这个字段而不是去改模型 ID。6.2 模型 ID 是凭记忆填的“我记得有个模型叫 xx”最容易出问题。TaoToken 模型广场列出的 ID 才是有效的填错的结果是 400 或者 model not found通常不是 URL 的问题。处理方法是回到模型广场复制 ID再检查ANTHROPIC_MODEL的值不要手动加引号或日期后缀。另外如果 Key 复制时带了空格会出现类型非常奇怪的 401从控制台复制而不是手打能省掉一堆排查时间。7. 跑通后把 Docker 部署 Skill 沉淀成自己的模板这套流程跑通之后我留下的不止一份 docker-ollama-deploy更重要的是看到了 skill-creator 拆解问题的顺序先确认示例再规划可复用资源然后初始化、编辑、打包迭代。以后遇到新场景我也可以照这个套路把技术笔记拆成 SKILL.md references scripts。如果只是想试验模型对话、确认 Key 是否可用可以直接进 TaoToken 模型对话想为写代码单独规划额度看 Coding Plan创建新 Key 在 控制台 API Keys。Claude Code 接入参数的完整对照在 接入文档。下一次再要生成别的 Skill我大概率会沿用这个 Skill 的骨架——毕竟套娃的乐趣就在于第一层造好了后面每一层都省力。