1. 新机器上 Skill 能加载但模型通道还没接上WorkBuddy 的 Skill 系统有个很实用的设计技能就是纯文件SKILL.md 加几个脚本打包拷到新机器解压回~/.workbuddy/skills/重启就能被识别。原文《把AI训练成你的专属员工》把这条链路讲得很完整尤其是 6.2 的项目专属部署流程和 4.2 的跨机器迁移步骤照着做基本不会翻车。但原文写到「重启 WorkBuddySkill 自动加载」就收尾了。加载之后呢你喊一句「跑一下部署」WorkBuddy 确实会去读deploy-skill/SKILL.md按里面的检查清单和回滚步骤往下走——可它执行这些步骤时调用的模型走的是哪条通道Token 从哪个账户出这个问题原文没交代而它恰恰是迁移到新机器后第一个会卡住的地方。我试过在一台全新环境里把技能目录解压回去deploy-skill能被正确识别触发词也命中但一执行就提示模型请求失败。原因不复杂Skill 只负责「告诉 AI 怎么做」不负责「AI 用什么通道思考」。这两件事是分开配置的。这篇就把缺口补上——SKILL.md 的 YAML frontmatter、trigger 触发词、scripts/deploy.sh全部照原文写一个字不动只把 WorkBuddy 的模型接入 Base URL 改到 TaoToken让 Skill 跑起来时有稳定的模型通道可用。适合谁看已经按原文建好 Skill、正在做跨机器迁移或者团队里多人共用同一套部署 Skill、需要统一模型出口的开发者。核心检索词就三个WorkBuddy、SKILL.md、Base URL 配置。2. 先把 TaoToken 的 Key 和 Base URL 准备好TaoToken 在这个流程里只做一件事提供一把 Key 和一个 Base URL。它不碰你的 SKILL.md不改你的触发词也不动scripts/deploy.sh。你可以把它理解成给 WorkBuddy 换了一个模型请求的出口地址Skill 的逻辑层完全不受影响。先打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册账号。注册流程很常规邮箱加密码收个验证邮件就完事。登录之后进控制台找到 API Keys 页面创建一把新 Key。创建时建议给 Key 起个能认出来的名字比如workbuddy-deploy这样以后在多个 Skill 之间排查问题时一眼能看出这把 Key 是给谁用的。Key 创建完只显示一次复制下来存到安全的地方。如果你打算把这套配置同步给团队其他人注意 Key 是个人凭证不要直接写进项目仓库里的 SKILL.md 或任何会被提交的文件。正确做法是每人各自创建自己的 KeyBase URL 共用同一个。Base URL 填这个https://taotoken.net/api两个细节必须说清楚。第一结尾不要带/v1。WorkBuddy 的接入配置里如果多写了/v1请求路径会拼成/api/v1/...和实际接口对不上直接报 404。第二这个地址不要加任何 UTM 参数。UTM 是给网页链接做来源统计用的填进 API Base URL 里会变成请求路径的一部分同样导致请求失败。注册页面的链接可以带 UTMAPI 地址不行这两者要分开记。控制台里还能看到用量和调用记录后面验证 Skill 是否真的走通了通道这里是最直接的证据。相关入口整理一下模型对话在 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite API Keys 管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。如果你后面要长期跑编码类 Skill可以了解下 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。3. 把 Base URL 填进 WorkBuddy 的模型接入配置这一步是整篇的核心操作。前提是你已经按原文 4.2 的步骤把旧机器的技能目录打包、传到新机器、解压回~/.workbuddy/skills/并且重启 WorkBuddy 确认deploy-skill能被识别。先确认技能目录结构没问题# 确认用户级技能目录存在 ls -la ~/.workbuddy/skills/ # 应该能看到 deploy-skill 目录 ls -la ~/.workbuddy/skills/deploy-skill/ # 确认核心文件齐全 cat ~/.workbuddy/skills/deploy-skill/SKILL.md | head -20SKILL.md开头的 YAML frontmatter 里name、description、trigger三个字段照原文写就行不用因为换了模型通道就改。比如部署 Skill 的触发词保持[跑一下部署, 执行部署, 部署到测试机]这类写法WorkBuddy 的匹配逻辑是包含匹配用户说「帮我跑一下部署流程」也能命中。接下来打开 WorkBuddy 的模型接入设置。不同版本的入口位置略有差异一般在设置里的「模型」或「API 接入」区域。找到 Base URL 这一栏填入https://taotoken.net/api然后在 API Key 栏填入刚才在控制台创建的那把 Key。模型名称按你实际要用的填TaoToken 侧支持的主流模型标识可以直接在文档里对照。配置项对照表配置项填写内容注意事项Base URLhttps://taotoken.net/api结尾不带/v1不加 UTMAPI Key控制台创建的 Key只显示一次妥善保存模型名称按文档对照填写与 Skill 用途匹配即可SKILL.md照原文不改frontmatter、trigger 全部保留scripts/deploy.sh照原文不改脚本逻辑与模型通道无关这里要强调一个容易搞混的点Skill 的存储位置分用户级和项目级~/.workbuddy/skills/是用户级项目/.workbuddy/skills/是项目级项目级同名会覆盖用户级。但无论 Skill 存在哪一级它们执行时用的模型通道都是同一套接入配置。也就是说你只需要配一次 Base URL用户级的「公司代码规范 Skill」、项目级的deploy-skill、以及internal-apiSkill全都走这一个出口。如果你在项目级也放了deploy-skill记得检查一下是不是和用户级同名。同名时项目级优先如果你改的是用户级版本却发现「没生效」多半就是这个原因。命名上加个项目前缀能避开这类问题比如project-alpha-deploy-skill。4. 喊触发词验证 Skill 是否真的跑通配置填完保存重启 WorkBuddy 让接入配置生效。然后按原文的说法直接喊触发词跑一下部署预期行为是WorkBuddy 识别到触发词加载deploy-skill/SKILL.md按里面的「部署前检查」章节逐项执行然后调用scripts/deploy.sh完成部署动作。整个过程你能在对话里看到它读 SKILL.md、执行脚本、汇报结果的步骤。怎么判断通道真的配好了看两个信号。第一个信号是 Skill 执行过程中不再出现模型请求失败。如果 Base URL 填错通常会在 AI 开始读 SKILL.md 之前就报错提示连接失败或 404。这时候回到接入配置检查地址重点看结尾有没有多余的/v1。第二个信号是去 TaoToken 控制台的用量页面能看到刚才这次 Skill 执行产生的调用记录。有记录说明请求确实走了 TaoToken 的通道Key 和 Base URL 都生效了。验证通过之后同一把 Key 和同一个 Base URL 可以直接复用到其他 Skill 上。比如你有个「公司代码规范 Skill」放在用户级还有个internal-apiSkill 放在项目级它们的 SKILL.md 和脚本都不用动模型通道自动共用这套配置。这也是把 Base URL 统一到一处的价值——Skill 越多越不用逐个去配。如果你还想单独验证模型本身是否正常可以打开模型对话页面发一条测试消息https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。对话能正常返回说明 Key 和通道都没问题剩下的就是 Skill 逻辑层的事。5. 本篇常见错误排查错误一Base URL 结尾带了/v1现象是 Skill 一执行就报 404 或路径不存在。原因是 WorkBuddy 会在 Base URL 后面拼接具体接口路径多写的/v1导致最终路径重复。解决方法是把 Base URL 改回https://taotoken.net/api结尾不带任何多余路径。错误二Base URL 里混进了 UTM 参数有人从浏览器地址栏直接复制链接把?utm_source...一起粘进了配置。UTM 参数会被当成请求路径的一部分导致请求失败。记住注册页链接可以带 UTMAPI 地址不能带。错误三Skill 能识别但执行时报模型错误先确认接入配置里的 Key 没有多余空格。从控制台复制 Key 时容易带上首尾空白粘贴后肉眼看不出来。再确认 Key 没有过期或被删除。如果都正常去控制台用量页面看有没有调用记录没有记录说明请求根本没发出去问题在 Base URL有记录但报错问题在 Key 权限或模型名称。错误四项目级和用户级 Skill 同名改了没效果这是原文坑3 提到的问题在迁移场景里特别容易撞上。项目级同名 Skill 优先级更高你改用户级版本自然不生效。解决方法是给项目级 Skill 加项目前缀或者确认你改的就是当前生效的那一份。错误五scripts/deploy.sh没有执行权限Skill 加载正常、模型通道也通但脚本跑不起来。检查一下解压后脚本的可执行位有没有丢chmod x ~/.workbuddy/skills/deploy-skill/scripts/deploy.sh ls -l ~/.workbuddy/skills/deploy-skill/scripts/deploy.sh打包传输过程中权限位丢失是常见情况解压后统一补一次执行权限能省不少排查时间。错误六Skill 依赖的外部命令在新机器上不存在deploy.sh里如果用了rsync、ssh之类的命令新机器没装就会报 command not found。这跟模型通道无关属于环境依赖问题。在 SKILL.md 里显式声明依赖或者放一个install_deps.sh能让 AI 主动帮你补环境。6. 通道配好之后Skill 才真正可迁移回到最初那个缺口原文把 Skill 的创建、存储、迁移讲透了但「加载之后走哪条模型通道」是空的。补上这一块之后整套迁移流程才算闭环——技能目录解压回~/.workbuddy/skills/deploy-skill被识别Base URL 指向https://taotoken.net/api喊一句触发词就能跑通。TaoToken 在这里的角色很清晰一把 Key一个 Base URL仅此而已。SKILL.md 的 YAML frontmatter、trigger 触发词、scripts/deploy.sh全部照原文写一个字不用动。你迁移的是技能逻辑配置的是模型出口两件事分开管互不干扰。同一把 Key 继续用在「公司代码规范 Skill」和internal-apiSkill 上填同一个 Base URL 就行。Skill 越攒越多通道只配一次这才是把经验固化下来之后该有的复利。接入过程中卡住了先翻接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 大部分路径和参数问题里面都有对照。