1. 从一张鸭血粉丝汤海报说起WorkBuddy 设计 Skill 到底解决什么问题如果你正在搜「WorkBuddy 设计 Skill 怎么配置」「design-master 和 theme-factory 怎么配合用」大概率你已经踩过这样的坑装了一堆 Skill每个单独跑都能出东西但串起来就乱套——配色前后不一致、字体层级打架、画布尺寸对不上最后生成的海报像四个设计师各画了一块拼起来的。WorkBuddy 的设计类 Skill 本质上是一套「设计流水线」design-master 负责定策略theme-factory 负责锁规范canvas-design-2 负责出成品frontend-design-pro 负责质检。它们能协作的前提是——每一步的输出都能被下一步稳定读取而这背后需要一个统一的模型调用入口。这就是我把 TaoToken 接进来的原因一个 Key 打通所有 Skill 的模型请求不用在每个 Skill 里重复填不同的 Base URL 和 Key。这篇以「南京鸭血粉丝汤」小红书宣传海报为实操案例把三个核心 Skilldesign-master、theme-factory、canvas-design-2的配置片段、调用链路、验证动作完整走一遍。适合谁看已经在用 WorkBuddy 但 Skill 协作总出问题的、想复现一套可复用设计工作流的、以及需要给团队统一模型入口的开发者。全程可跟做配置片段直接复制改路径就能用。先说清楚一个概念避免后面混淆Skill 不是插件市场里点一下就完事的黑盒它的本质是一个SKILL.md文件加上可选的脚本和资源目录。SKILL.md里写的是「遇到什么任务、按什么流程、用什么标准执行」相当于把一位设计师的工作经验固化成了可被模型读取的指令集。所以 Skill 的质量上限取决于它调用的模型能不能稳定理解这些指令——这也是统一 Key 接入的价值所在。2. TaoToken 前置准备统一 Key 接入与 Skill 目录结构在动任何 Skill 之前先把模型调用入口统一掉。WorkBuddy 的每个 Skill 在运行时都会发起模型请求如果每个 Skill 各自配置一套鉴权信息排查问题时你根本不知道是哪个环节挂了。TaoToken 的作用就是提供一个统一的 API 入口所有 Skill 共用同一个 Key 和 Base URL。先拿到 Key。访问 https://taotoken.net/api-keys 创建你的 API Key建议按用途命名比如workbuddy-design方便后面在多个 Skill 间区分。创建后复制保存页面关闭后不再完整显示。Base URL 统一填https://taotoken.net/api。注意这里不要带任何查询参数保持干净。接下来是 Skill 的目录结构。WorkBuddy 加载 Skill 时按约定路径扫描我实测下来这套结构最稳~/.workbuddy/skills/ ├── design-master/ │ ├── SKILL.md │ └── resources/ ├── theme-factory/ │ ├── SKILL.md │ └── themes/ └── canvas-design-2/ ├── SKILL.md └── templates/每个 Skill 目录下的SKILL.md是入口resources、themes、templates是可选资源。第三方下载的 zip 包解压后确认顶层就是 Skill 名目录不要多套一层文件夹否则 WorkBuddy 扫描不到。模型配置我建议单独放一个全局文件而不是散落在每个 Skill 里。在~/.workbuddy/下建一个config.toml[model] provider taotoken base_url https://taotoken.net/api api_key sk-你的TaoToken密钥 default_model claude-sonnet-4-5 [skills.design-master] model claude-sonnet-4-5 temperature 0.7 [skills.theme-factory] model claude-sonnet-4-5 temperature 0.3 [skills.canvas-design-2] model claude-sonnet-4-5 temperature 0.5这里有个细节值得说design-master 负责策略发散temperature 给 0.7 让风格定位更有想象力theme-factory 要的是稳定匹配0.3 保证每次选主题不飘canvas-design-2 出成品0.5 居中。这三个值是我反复调出来的你可以先照抄再微调。如果你更习惯 JSON 格式等价写法{ model: { provider: taotoken, base_url: https://taotoken.net/api, api_key: sk-你的TaoToken密钥, default_model: claude-sonnet-4-5 }, skills: { design-master: { model: claude-sonnet-4-5, temperature: 0.7 }, theme-factory: { model: claude-sonnet-4-5, temperature: 0.3 }, canvas-design-2: { model: claude-sonnet-4-5, temperature: 0.5 } } }配置写完后Skill 里就不需要再出现任何 Key。这样做的直接好处换模型、换 Key 只改一个文件所有 Skill 同步生效。接入文档在 https://taotoken.net/doc 有更细的参数说明遇到字段不识别可以去对一下。3. 可复制配置design-master、theme-factory、canvas-design-2 三件套这一节给出三个 Skill 的SKILL.md核心片段重点是让它们的输入输出能对接上。很多人 Skill 协作失败不是模型不行是上一步的输出格式下一步读不懂。先看 design-master 的配置。它的职责是接收自然语言需求输出结构化设计策略--- name: design-master description: 设计策略规划输出风格定位、配色、字体、排版建议 model: claude-sonnet-4-5 --- # design-master ## 触发条件 用户提到「设计策略」「视觉方向」「风格定位」时激活。 ## 输出格式必须严格遵守 输出 JSON字段如下 - style: 风格定位字符串 - palette: 配色方案数组每项含 name 和 hex - typography: 字体搭配对象含 title 和 body - layout: 排版建议字符串 - theme_keyword: 主题关键词字符串供 theme-factory 匹配 ## 执行标准 1. 先理解目标受众和使用场景 2. 配色必须给出具体 hex 值不要写「暖色调」这种模糊描述 3. theme_keyword 只输出一个词用于下一步匹配关键在最后那个theme_keyword。design-master 输出策略后theme-factory 靠这个词去匹配主题而不是重新理解一遍需求。这样链路才稳。theme-factory 的配置--- name: theme-factory description: 根据主题关键词匹配视觉规范输出字号、行高、间距参数 model: claude-sonnet-4-5 --- # theme-factory ## 输入 读取上一步 design-master 输出的 theme_keyword 和 palette。 ## 内置主题 - warm-retro: 复古暖调 - fresh-minimal: 清新极简 - street-bold: 街头粗犷 - elegant-classic: 典雅经典 共 10 套themes/ 目录下可扩展 ## 输出格式 输出 JSON - theme_name: 匹配到的主题名 - font_size: { h1, h2, body } - line_height: { h1, h2, body } - spacing: { section, element } - color_override: 若 design-master 的 palette 与主题冲突以 palette 为准注意color_override这条规则。我试过让 theme-factory 完全接管配色结果它把鸭血粉丝汤的「老鸭汤色 #8B2500」换成了主题自带的橙色食欲感全没了。所以规则要写死配色以 design-master 为准theme-factory 只管字号行高间距。canvas-design-2 的配置--- name: canvas-design-2 description: 整合策略与主题规范输出高清 PNG 或印刷 PDF model: claude-sonnet-4-5 --- # canvas-design-2 ## 输入 - design-master 的 palette、typography、layout - theme-factory 的 font_size、line_height、spacing - 用户指定的画布尺寸 ## 输出 - 竖版 1080×1920 PNG小红书 - 或 A4 300dpi PDF印刷 ## 执行标准 1. 严格沿用输入中的 hex 色值不得自行替换 2. 字体层级按 theme-factory 的 font_size 执行 3. 生成后输出文件路径和尺寸信息三个 Skill 的配置核心就这些。你会发现它们之间没有重复的鉴权信息全部走config.toml里的统一入口。这就是 TaoToken 统一 Key 的价值Skill 只管业务逻辑模型调用交给全局配置。4. 验证请求从主题生成到画布输出的完整跑通配置写完必须验证不然你不知道是 Skill 没加载还是 Key 没生效。我按「先单点、后串联」的顺序来。第一步验证 TaoToken 入口本身通不通。用 curl 发一个最小请求curl https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的TaoToken密钥 \ -d { model: claude-sonnet-4-5, messages: [{role: user, content: 回复 OK 两个字母}], max_tokens: 10 }返回里能看到choices数组且内容为 OK说明 Key 和 Base URL 没问题。如果这一步就报错先别往下走去第 5 节对报错。第二步单点验证 design-master。在 WorkBuddy 里输入使用 /design-master 技能帮我完成一张南京鸭血粉丝汤的宣传海报设计策略 用于小红书推广。目标受众是 20-35 岁年轻食客和游客。 风格要求地道老南京味 年轻化表达温暖食欲感不要廉价快餐感。 突出「一碗好汤半城烟火」的主题。预期输出是一段 JSON包含 style、palette、typography、layout、theme_keyword。重点检查 palette 里有没有具体 hextheme_keyword 是不是单个词。如果输出的是大段散文而不是 JSON说明SKILL.md里的输出格式约束没生效回去检查 frontmatter 和格式段落。第三步串联 theme-factory根据上面的设计策略用 theme-factory 匹配一个最合适的主题 输出完整的视觉规范参数。这一步会读取上一步的 theme_keyword。实测下来鸭血粉丝汤这个场景匹配到的是warm-retro字号行高输出正常。如果 theme-factory 报「找不到输入」说明两个 Skill 之间的上下文没传递检查是不是在同一个会话里连续调用。第四步canvas-design-2 出成品用 canvas-design-2 生成成品海报。沿用前面的配色老鸭汤色 #8B2500 为主色、 字体站酷高端黑标题 思源宋体副标和布局线稿。 输出竖版 1080×1920 高清 PNG。 产品图用俯拍鸭血粉丝汤碗中有鸭血、粉丝、香菜、油豆腐热气腾腾。跑通后你会拿到一个 PNG 文件路径。检查三件事尺寸是不是 1080×1920、主色是不是 #8B2500、标题字体是不是站酷高端黑。这三项对上了说明整条链路的数据传递是通的。不满意可以迭代比如「汤碗再大一点热气效果更明显」「标题换成手书体」「配色再暖一点」。canvas-design-2 支持局部调整每次只改你指出的部分不会推翻重来。5. 本篇常见报错排查401、local proxy failed、reading choices、OAuth这一节按真实报错来对都是我或读者踩过的。401 Unauthorized。最常见九成是 Key 问题。先确认config.toml里的api_key是不是完整复制有没有多余空格。再确认 Base URL 是不是https://taotoken.net/api不要写成带/v1的完整路径又和 Skill 内部拼接冲突。如果 Key 是对的还报 401去 https://taotoken.net/api-keys 看这个 Key 是不是被禁用或额度耗尽。local proxy failed。这个报错通常出现在 Skill 尝试走本地代理时。检查你的环境变量里有没有残留的HTTP_PROXY、HTTPS_PROXY。有的话清掉unset HTTP_PROXY unset HTTPS_PROXY unset ALL_PROXY然后重启 WorkBuddy。TaoToken 的入口是直连的不需要任何本地代理层多一层反而容易断。reading choices 相关报错。典型信息是cannot read property choices of undefined或reading choices。这说明请求发出去了但返回体结构不对模型没正常响应。排查顺序先用第 4 节第一步的 curl 确认入口通再看config.toml里default_model填的模型名是不是 TaoToken 支持的最后检查 Skill 的SKILL.md里有没有硬编码了别的模型名覆盖全局配置。OAuth 相关报错。如果你在配置里看到OAuth字样或跳转鉴权说明某个 Skill 还在走旧的鉴权方式。WorkBuddy 的设计类 Skill 应该走 API Key不走 OAuth。检查对应 Skill 的SKILL.md把鉴权相关字段删掉统一由config.toml接管。Skill 加载了但没反应。不是报错但更烦人。先确认目录结构对不对SKILL.md是不是在 Skill 名目录的顶层。再看 frontmatter 里的name和目录名是否一致不一致会导致触发词匹配失败。最后看description里有没有写清楚触发条件写得太模糊模型不知道什么时候该激活。输出不是 JSON 而是散文。这是格式约束没生效。在SKILL.md里把输出格式段落写得更硬加上「必须严格遵守」「只输出 JSON不要任何解释文字」这类约束。temperature 也可以调低一点0.3 以下格式更稳。排查的核心思路就一条先确认 TaoToken 入口通再确认单个 Skill 能跑最后确认 Skill 之间能传数据。任何一环断了按这个顺序往回找比盲目改配置快得多。6. 把设计工作流固化下来统一 Key 与 Skill 复用跑通一次不算本事能反复跑通才是工作流。这套东西固化下来有三个动作值得做。第一把config.toml纳入版本管理。模型名、temperature、Base URL 这些是会变的改一次记一次团队里谁改了能追溯。Key 不要提交到仓库用环境变量注入或者本地单独放。第二给每个 Skill 写一份最小验证用例。比如 design-master 的用例就是那句鸭血粉丝汤的 prompt每次改完配置先跑用例输出符合预期再上生产。这比出问题再回头查省太多时间。第三Skill 之间约定好数据契约。design-master 输出什么字段、theme-factory 读什么字段、canvas-design-2 整合什么字段写清楚。契约稳定了你换任何一个 Skill 的实现都不影响其他环节。长期做编码和 Agent 类任务的可以考虑 Coding Plan把模型调用额度固定下来避免设计任务和编码任务抢资源。需要验证不同模型在设计场景下的表现差异可以去模型对话页面直接对比输出。接入过程中遇到文档没覆盖的字段接入文档里有更细的参数表。回到鸭血粉丝汤这个案例。它验证的不只是一张海报能不能生成而是「策略 → 规范 → 成品」这条链路能不能稳定复用。你把主题换成别的比如「苏州桂花糖粥」「成都冒菜」只要改 design-master 的输入后面两步自动跟着走。这才是 Skill 协作真正的价值——不是单点能力有多强而是串起来之后你只需要描述需求剩下的交给流水线。