1. 为什么模板 Skill 总差一口气得自己搓一个先说结论Skill 的本质就是一个SKILL.md文件靠 name、description、触发词加工作流约定把一项能力封装成随装随用的能力包。它能做什么让 AI 在你开口的瞬间自动调起对应工具把重复动作一次干完。适合谁天天跟 PDF 合同、报价单、扫描件打交道又不想每次手动点转换按钮的人。我试过从平台装一堆现成 Skill用起来总觉得差口气。那个报错脚本的没按我的格式输出那个能做表格的触发词老对不上我说话的方式我想给它加一句「合同抽关键条款」翻遍设置也没地儿写。原因不复杂这些 Skill 是别人搓给你用的照顾的是大多数人的普遍场景不会专门迁就你手上那堆活儿。可你的痛点偏偏最私人。你天天在转合同 PDF你那句「把老板甩来的 PDF 转成 Word 顺便抽个表格」就是你的高频动作别人没这份需求模板当然覆盖不到。这就是很多人没想通的一层Skill 不一定要靠别人给自己也能搓一个而且搓出来的才是真正贴合你日常的。这篇就拿福昕 PDF 转 Word MCP服务名foxit-pdf365-convert当底子手把手带你把一个「转合同 抽表格」的专属 Skill 搓出来。Skill 本身的写法用通用范式讲保证你在别的平台也能照做。同时把 TaoToken 统一 Key 配置接进来让你后面不管换哪个模型、哪个工具Key 和 API 通道都只维护一份不用每个 Skill 单独配一遍。先把「Skill 到底是个啥」说清这是全文唯一绕不开的概念讲清一次后面全是动手。Skill技能是指 WorkBuddy 这类 Agent 办公/开发平台上一种可重复使用、随装随用的「能力包」把「某个能力 它的一句自然语言描述 什么话能触发它 该怎么做的工作流」打包成一份文件。AI 装上它遇上对应场景就自动调起来完成对应任务。大白话Skill 是写给 AI 的一段「说明书」——它不一定要带复杂代码核心是那份「规定」。AI 遇到符合触发词的话就照着执行约定帮你把它干了。它的实体通常就是一个文件SKILL.md。往里写清楚这四个部分一个 Skill 的框架就立起来了写什么是什么有什么用nameSkill 的名字服务名让 AI / 系统识别它是谁description一段自然语言的能力描述决定 AI 什么时候该想起来用它触发词keywords patterns用户说到什么就是叫它上岗执行约定工作流 / 步骤 / 前置条件规定它具体怎么干、先干哪步而 Skill 底下要真的把「活」干出来常常还要接一个 MCP。MCPModel Context Protocol模型上下文协议你可以理解成「AI 的 USB 接口」定一套标准协议各种外部工具即插即用AI 不用给每个工具单独写对接代码。一句话记住Skill 是「能力包」MCP 是它调用外部工具的那根「插座」。那为什么还要 TaoToken因为当你搓到第三个、第五个 Skill每个都要填一遍模型 Key、改一遍 Base URL维护成本就上来了。TaoToken 提供统一 Key 和 API 通道把模型调用收敛到一个入口Skill 里只认这一个地址换模型不动 Skill。官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 后面配置里会反复用到。2. 拆一份真实的 SKILL.md福昕 PDF 转 Word 骨架长什么样既然说「一个 Skill 就是一个 SKILL.md」那最直观的办法是拆一份真实存在的给你看。下面这份以福昕官方foxit-pdf365-convert/SKILL.md为蓝本我把它整理成可复制的骨架你照着改就能用。--- name: foxit-pdf365-convert # Skill 名服务名 description: PDF 转 Word 文档格式转换 metadata: version: 1.1.x author: Foxit --- # 触发词keywords keywords: - pdf转word - pdf to word - pdf to docx - pdf convert # 触发条件patterns正则 patterns: - (pdf|PDF).*(转|convert|转换).*(word|Word|docx|doc|文档) # 执行约定简化示意 工作流 1. 检查本地 API Key 是否存在 2. 让用户提供 PDF≤100MB 3. 上传 → 建任务 → 轮询每 3000ms最多 60 次 4. 下载结果返回原文件目录注意拿到这份文件你其实已经握住了 Skill 的全部骨架身份name/description、触发keywords/patterns、干活执行约定。剩下三件具体的事——怎么接福昕 MCP、怎么把 TaoToken 统一 Key 接进来、怎么改造成自己的——下面挨个来。这里有个细节值得单独说SKILL.md的 YAML 头别乱写。缺 name 或 descriptionAgent 可能都认不出这包 Skill装上了也不触发。patterns 用的是正则写的时候注意转义别把.*写成*否则匹配不到。keywords 是给「人话」用的patterns 是给「模糊表达」兜底的两个都写命中率才高。再补一句关于 description 的写法。很多人把它写成一句干巴巴的功能名比如「PDF 转换」。这其实浪费了它最大的价值——description 是 AI 判断「要不要想起你」的主要依据。你写得越像你的日常场景AI 越会在对的时候调你。比如改成「把老板发来的 PDF 合同转成 Word并尽可能保留表格」AI 一听到「合同」「转 Word」就会优先想到这个 Skill而不是等你精确说出「pdf to word」。骨架立住之后下一步就是让它能真的干活——接 MCP。这一步做完你的 Skill 才从「一份说明书」变成「一个能跑的工具」。3. 接入福昕 MCP 与 TaoToken 统一 Key 配置Skill 的「魂」在触发与流程但要真的把活干出来得让它能调到转换服务。这一步就是接 MCP。福昕这个服务名是foxit-pdf365-mcp-server接入方式streamableHttp接入地址open.pdf365.cn认证走X-API-KEY请求头。Key 的格式是pdf365_mcp_xxxxxxxx注意pdf365_mcp_是不可分割的前缀漏了或截断直接认证失败。一份可用的 MCP 配置通用范式把 Key 换成你自己的pdf365_mcp_开头的真实 Key{ mcpServers: { foxit-pdf365-mcp-server: { type: streamableHttp, url: https://open.pdf365.cn/mcp, headers: { X-API-KEY: pdf365_mcp_xxxxxxxx } } } }服务名按官方写法是foxit-pdf365-mcp-serverKey 前缀是pdf365_mcp_且绝不省略。接下来是这篇的重点之一把 TaoToken 统一 Key 接进来。为什么要接因为你的 Skill 里除了调福昕 MCP往往还要调模型做「抽表格」「写摘要」这类动作。如果每个 Skill 都单独填一遍模型 Key换一次模型就要改一堆文件。TaoToken 的做法是给你一个统一入口Base URL 固定Key 固定模型 ID 按需切换。先拿 Key。打开 https://taotoken.net/api-keys 登录后创建一个 API Key复制出来。这个 Key 就是你所有 Skill 共用的那一把。然后在你的项目里建一个config.toml把模型通道写进去# config.toml —— TaoToken 统一 Key 配置 [llm] base_url https://taotoken.net/api api_key sk-你的TaoTokenKey model claude-sonnet-4-5 [llm.headers] Content-Type application/json如果你用的是 Claude Code 这类读settings.json的工具等价配置长这样{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的TaoTokenKey, ANTHROPIC_MODEL: claude-sonnet-4-5 } }三件套记牢Base URL 是https://taotoken.net/apiKey 是你在控制台创建的那把Model ID 按你实际要用的填。这三样在 MCP 配置、config.toml、settings.json里保持一致后面排查问题就只看这三处。如果你用的是 Codex 系工具认证文件通常在~/.codex/auth.json把 Key 和 Base URL 填进去即可{ OPENAI_BASE_URL: https://taotoken.net/api, OPENAI_API_KEY: sk-你的TaoTokenKey }配置完记得重载 MCP 和工具让新配置生效。到这里福昕 MCP 负责「转文档」TaoToken 负责「调模型」两条通道各司其职你的 Skill 骨架就有了完整的执行底座。4. 验证一次 MCP 工具调用从 PDF 到 Word 的完整闭环配置写完不算完得跑一次真实调用确认链路是通的。接上之后一次 PDF 转 Word 的完整闭环长这样传 PDF≤100MB作为 file 传上去建任务调createConvertTask(fileUrl, PDF_2_WORD)拿到 taskId轮询调getConvertTaskStatus(taskId)每 3000ms 查一次、最多 60 次等stateFINISH successtrue下载调downloadConvertResult(taskId)只传 taskId有额度就返回下载链接没额度会让用户去支付页回目录把结果写回原 PDF 所在目录如~/Desktop/报告.pdf→~/Desktop/报告.docx。这套就是「老板甩 PDF → 自动转 Word」的底层全部。你自己搓的 Skill只要把这一套流程约定写进SKILL.md「执行约定」里AI 就会照着串。验证的时候我建议先单独测 MCP再测模型通道别一上来就全链路跑出错了不好定位。先测 MCP 是否通。在支持 MCP 的客户端里手动触发一次工具列表拉取看能不能列出foxit-pdf365-mcp-server下的工具。如果列不出来多半是配置没重载或者 URL 写错了。再测模型通道是否通。用 curl 打一次 TaoToken 的接口curl https://taotoken.net/api/v1/messages \ -H Content-Type: application/json \ -H x-api-key: sk-你的TaoTokenKey \ -H anthropic-version: 2023-06-01 \ -d { model: claude-sonnet-4-5, max_tokens: 64, messages: [{role: user, content: 只回复两个字通了}] }返回里能看到content字段带「通了」说明模型通道没问题。这一步过了再回到 Skill 里跑完整流程。完整流程验证时准备一个小的 PDF几页就行别一上来就传 100MB 的触发你的 Skill观察日志里是不是按「上传 → 建任务 → 轮询 → 下载」的顺序走。轮询阶段会打印多次状态正常的话几十秒内会看到FINISH。下载完成后去原 PDF 所在目录看有没有生成同名.docx。如果一切顺利你会看到类似这样的结果原目录下多了一个 Word 文件打开后表格结构基本保留文字可编辑。到这一步你的 Skill 就算真正跑通了。5. 本篇常见报错排查401、local proxy failed、reading choices跑不通是常态别慌。下面这几个报错是我实测下来最常撞见的对照着查基本能定位。401 Unauthorized。这个最常见八成是 Key 的问题。先看福昕那边X-API-KEY的值是不是完整的pdf365_mcp_xxxxxxxx前缀有没有被截断。再看 TaoToken 这边sk-开头的 Key 有没有复制全有没有多空格。还有一种情况是 Key 创建后没生效回控制台确认一下状态。401 基本就是「认证没通过」把两把 Key 分别单独测一遍很快能分清是哪边的问题。local proxy failed。这个报错通常出现在你本地配了转发或代理层的时候。先检查你的config.toml或settings.json里 Base URL 是不是写成了https://taotoken.net/api有没有多写斜杠、少写https。如果本地有额外的网络层配置确认它没有把请求拦下来。这个错的关键词是「local」说明问题出在你本机的配置不在远端服务。reading choices 相关报错。这类报错一般出现在解析模型返回的时候提示读不到choices字段。原因通常是返回体结构和预期不一致——比如你按 OpenAI 格式解析但实际返回的是 Anthropic 格式或者反过来。检查你的 Model ID 和解析逻辑是否匹配。用 TaoToken 的时候Base URL 统一但不同模型的返回结构可能不同解析层要按模型类型分支处理。OAuth 相关报错。如果你用的是 Claude Code 这类带 OAuth 流程的工具报错里出现 OAuth 字样先确认你是用 API Key 模式还是 OAuth 模式。用 TaoToken 统一 Key 的话走的是 API Key不需要 OAuth。如果工具默认走 OAuth去设置里切成 Key 模式把ANTHROPIC_API_KEY填上。轮询超时。这个不算报错但很常见。官方节奏是每 3000ms 一次、最多 60 次大文件耐心等别疯狂打接口。如果你自己写轮询逻辑别写死循环按官方节奏来。超过 60 次还没FINISH检查文件是不是超了 100MB或者格式不被支持。排查的通用思路先分清是 MCP 的问题还是模型通道的问题再分清是本地配置还是远端服务。把 Base URL、Key、Model ID 这三件套逐项核对一遍大部分问题都能自己解决。需要对照文档的话接入文档在 https://taotoken.net/doc API Keys 管理在 https://taotoken.net/api-keys 。6. 改造成你自己的三处加诉求再走统一通道接上了、验证过了还要让它「长成你的样子」。改三个地方就行成本极低。第一处改 description让它知道「该想起你」。你把福昕的 description「PDF 转 Word 文档格式转换」扩成你自己那套AI 才知道什么时候调用你。比如写成「把老板发来的 PDF 合同转成 Word并尽可能保留表格」「处理销售部日常的 PDF 报价单、合同扫描件」。描述写得越像你的日常AI 越会在「对的时候」想起来用它而不是装了一堆 Skill 却没一个出场。第二处改触发词让它听得懂你说的话。你天天怎么说的就怎么加。官方已带pdf转word、pdf to word、pdf to docx等通用词你可以再补几个你的「黑话」keywords: - 合同转word - 报价单转word - 把合同转成可编辑 patterns: - (合同|报价单|文件).*(转|转换).*(word|可编辑)这样你以后随口一句「把这份合同转成能改的」就能命中而不是必须打字「pdf to word」。第三处改执行约定把你的流程「钉」进去。福昕默认是「转 Word → 返回原目录」。你要是想要「转 Word 顺手抽表」就在执行约定里补一条工作流 1. 检查本地 API Key 是否存在 2. 让用户提供 PDF≤100MB 3. 上传 → 建任务 → 轮询每 3000ms最多 60 次 4. 下载结果返回原目录 5. 额外调用 TaoToken 模型通道把 Word 里各表格的标题与关键列抽出来整理成一段文字摘要注意第 5 步调模型时用的就是第 3 节配好的 TaoToken 统一 Key不用再单独填一遍。这就是统一通道的好处Skill 里只写「调模型」具体走哪个模型、哪把 Key全在config.toml里管。一句话总结它的诀窍Skill 长得像你的才是你的——描述写你的场景触发词说你的黑话工作流加你的步骤。三步大约五分钟一套专属工具就落地了。如果你后面要长期跑编码类、Agent 类的任务可以考虑 Coding Plan把模型调用额度也统一管起来入口在 https://taotoken.net/coding-plan 。想先验证模型效果可以直接在模型对话里试 https://taotoken.net/models 。配置过程中卡住了回接入文档翻一遍 https://taotoken.net/doc 或者去控制台重新生成一把 Key 试试 https://taotoken.net/api-keys 。到这里你已经把三件事走完了Skill 的本质只是一份SKILL.md接一个福昕 PDF 转 Word MCP 让它能真正干活再用 TaoToken 统一 Key 把模型通道收口最后在描述、触发词、执行约定里塞进你自己的诉求搓出专属工具。剩下的就是把它用起来然后按你的实际痛点继续加步骤。