1. 从一堆散装工具到可复用能力为什么“Skill”才是分水岭手里攒了一堆工具这大概是每个做 AI 应用落地的人都会经历的阶段。浏览器扩展装了一排命令行里躺着几个脚本某个文件夹里还存着几段调 API 的 Python 代码Notion 里记着各种提示词模板。工具确实不少但每次遇到一个新任务还是得从头翻一遍想想这次该用哪个、参数怎么填、上一步的输出怎么接到下一步。这种状态说白了就是工具是散的能力没有沉淀下来。我管这个阶段叫“工具箱阶段”。它的典型特征是你知道自己能做很多事但每件事都要重新组装一遍。就像家里有一整套螺丝刀、扳手、电钻但每次修东西都得把整个工具箱倒出来翻找用完再塞回去。工具本身没问题问题是它们之间没有形成稳定的协作关系也没有被封装成“遇到某类问题就自动走这套流程”的能力单元。Skill 这个概念要解决的正是从“有工具”到“有能力”之间的那道坎。它不是一个新工具而是一种组织方式——把零散的动作、调用、判断逻辑固化成一段可复用、可组合、可迭代的业务能力。你给它一个明确的输入它按既定流程走完给你一个稳定的输出。中间那些“该调哪个接口”“参数怎么传”“失败了怎么重试”的细节全部被封装在 Skill 内部。这件事为什么现在变得重要因为 LLM 的能力边界在快速扩张Function Calling、ReAct、MCP 这些机制让模型可以调用外部工具、可以多步推理、可以连接各种数据源。但能力越强组合爆炸的问题就越严重。一个 LLM 面前摆着二十个可用工具它每次都要重新判断该用哪个、怎么串起来这不仅慢而且不稳定。Skill 的价值就在于把这种“每次重新判断”变成“一次定义、多次复用”。适合读这篇内容的人大概有这么几类正在做 AI Agent 落地、手里已经有一堆 API 和脚本但不知道怎么系统化的人在用 Dify、Coze 这类平台搭工作流发现流程越搭越乱的人还有就是对 MCP、Function Calling 这些概念有了解但还没想清楚它们和 Skill 之间是什么关系的人。我会尽量把这几层关系讲透同时给出可以直接抄的操作思路。2. 拆解 Skill 的核心设计它到底封装了什么2.1 Skill 与 Function Calling、ReAct、MCP 的关系很多人第一次听到 Skill 会懵因为它和 Function Calling、ReAct、MCP 这些词经常混在一起出现。我试着用一层一层剥开的方式来讲。Function Calling 是最底层的机制。它解决的是“模型怎么知道有哪些工具可用、怎么把自然语言转成结构化的调用参数”这个问题。你定义一个函数写好参数 schema模型在需要的时候就会输出一个 JSON告诉你它想调哪个函数、传什么参数。但 Function Calling 本身不管多步编排也不管失败重试它只负责“一次调用”的翻译工作。ReAct 是一种推理模式。它让模型在“思考”和“行动”之间交替先想一步决定要不要调工具调完看结果再想下一步。ReAct 解决了多步任务的问题但它每次都要重新推理没有记忆也没有固化下来的流程。你这次让它查天气再决定穿什么下次它还得重新想一遍。MCP 是连接协议。它定义了一套标准让不同的工具、数据源能够以统一的方式暴露给模型。你可以把它理解成“工具侧的 USB-C 接口”——不管你是数据库、文件系统还是某个 SaaS 服务只要按 MCP 协议封装模型就能用同一种方式访问。MCP 解决的是“工具怎么接进来”的问题但它不解决“接进来之后怎么组织成业务能力”的问题。Skill 站在它们之上。一个 Skill 内部可能包含多个 Function Calling可能用 ReAct 做决策可能通过 MCP 连接外部服务。但 Skill 本身是一个更高层的封装它定义了“这类任务的标准流程是什么”。比如“竞品分析”这个 Skill内部可能是先用 MCP 拉取竞品官网数据再用 Function Calling 调 LLM 做摘要再用 ReAct 判断是否需要补充搜索最后按固定模板输出报告。这一整套流程被固化下来下次遇到同类任务直接触发这个 Skill 就行。用一句话概括Function Calling 是动词MCP 是管道ReAct 是思考方式Skill 是把这些组织起来的“业务剧本”。2.2 一个 Skill 的最小结构应该包含什么我试过几种不同的 Skill 定义方式踩过一些坑之后发现一个能稳定跑起来的 Skill至少需要包含这几个部分触发条件什么情况下该用这个 Skill。可以是关键词匹配也可以是语义判断还可以是上游 Skill 的输出指定。触发条件写得太宽会导致 Skill 被滥用写得太窄又经常该触发的时候不触发。我的经验是先用几个典型场景把边界画出来再根据实际使用情况调整。输入契约这个 Skill 需要什么输入格式是什么哪些是必填、哪些是可选。这一步非常关键因为很多 Skill 跑失败不是因为逻辑不对而是因为上游传进来的数据格式不对。把输入契约写清楚相当于给 Skill 加了一道防线。执行步骤按顺序列出每一步做什么。每一步可以是调用一个 Function、执行一段代码、请求一次 LLM、或者等待一个人工确认。步骤之间要有明确的依赖关系和数据传递方式。输出契约Skill 执行完之后输出什么格式是什么。输出契约要和输入契约一样严格因为下游可能还有别的 Skill 在等这个结果。异常处理某一步失败了怎么办是重试、跳过、还是终止整个 Skill。这部分最容易被忽略但恰恰是区分“玩具 Skill”和“生产级 Skill”的关键。我见过很多人写 Skill 只写执行步骤输入输出全靠“到时候再说”结果就是每次调用都要人工干预根本谈不上复用。把契约写死把异常处理写清楚这个 Skill 才算真正固化下来了。2.3 为什么“固化”比“灵活”更难也更有价值这里有一个反直觉的点很多人觉得 Skill 应该越灵活越好最好能适应各种情况。但实际用下来真正有价值的 Skill 往往是那些“不灵活”的——它把一类任务的流程锁死换来的是稳定性和可预测性。举个例子。我做过一个“周报生成”的 Skill流程非常死从指定数据源拉取本周数据按固定维度做汇总用固定模板生成文字最后输出到指定位置。整个过程没有任何“智能判断”就是一条直线走到底。但正是因为它足够死我才能放心地把它挂到定时任务上每周五下午自动跑从来不用管。如果我让它“灵活判断这周该重点写什么”反而每次都要人工检查输出对不对复用就无从谈起了。固化的本质是把决策成本前置。你在定义 Skill 的时候把“遇到 A 情况走哪条路、遇到 B 情况走哪条路”全部想清楚、写死。之后每次执行都不需要再重新决策。这就像工厂里的流水线设计流水线的时候很费脑子但一旦跑起来每个环节做什么都是确定的不需要工人现场发挥。当然固化不等于僵化。好的 Skill 会在关键节点留出“可配置参数”比如周报的日期范围、数据源地址、输出格式这些可以在触发时传入。但核心流程本身是锁死的。把变化的部分参数化把不变的部分固化这是 Skill 设计的基本原则。3. 从零搭建一个可复用 Skill 的完整实操3.1 选一个真实场景以“技术资讯日报”为例光讲概念没意思我拿一个自己实际做过的 Skill 来拆解。这个 Skill 叫“技术资讯日报”功能是每天自动收集指定几个来源的技术文章做摘要和分类生成一份日报。为什么选这个场景因为它足够典型涉及多个数据源、需要 LLM 做摘要、有固定的输出格式、需要定时触发。基本上把 Skill 该有的要素都覆盖了。先明确这个 Skill 的边界。它只做“收集-摘要-分类-输出”这四件事不做深度分析不做趋势判断也不做人工推荐。这些不做的事情就是 Skill 的边界。边界清晰了后面定义流程才不会跑偏。3.2 定义输入输出契约输入契约我设计成这样字段类型必填说明datestring是日期格式 YYYY-MM-DDsourcesarray是数据源列表每个元素包含 name 和 urlmax_itemsnumber否每个来源最多取几条默认 5output_formatstring否输出格式默认 markdown输出契约字段类型说明datestring对应输入日期itemsarray每条包含 title、source、summary、category、urlgenerated_atstring生成时间戳这里有个细节输入里的 sources 我设计成必填而不是在 Skill 内部写死。为什么因为数据源是会变的今天看这几个博客明天可能想加几个。如果写死在 Skill 里每次改都要动 Skill 定义做成参数改的时候只需要改调用方传的参数。这就是前面说的“把变化的部分参数化”。输出里的 category 字段我一开始想做成自由文本后来改成了枚举值前端、后端、AI、工具、其他。为什么因为下游如果要按分类做统计或者过滤枚举值比自由文本稳定得多。LLM 有时候会输出“前端开发”“前端技术”这种变体统一成枚举就避免了这个问题。3.3 执行步骤的详细拆解整个 Skill 的执行流程我拆成了六步第一步拉取原始数据。对 sources 里的每个来源用对应的方式获取内容。这里有个坑不同来源的获取方式可能不一样。有的提供 RSS有的需要爬页面有的有 API。我的做法是在 Skill 内部维护一个“来源类型到获取方法”的映射调用时根据来源配置自动选择。如果某个来源拉取失败记录错误但继续处理其他来源不因为一个源挂了就整个 Skill 失败。第二步内容清洗。拉回来的原始内容往往包含大量噪音导航栏、广告、页脚、相关阅读链接。这一步用简单的规则做清洗比如去掉 script 和 style 标签、去掉长度小于一定阈值的段落、去掉包含特定关键词的块。清洗规则不需要太复杂能去掉大部分噪音就行剩下的交给 LLM 处理。第三步逐条摘要。对每篇文章调 LLM 生成摘要。提示词大概是“用两到三句话概括这篇文章的核心内容不要评价不要延伸只做概括。”这里的关键是限制输出长度和风格否则 LLM 容易写出一大段评论。我试过不加限制结果摘要比原文还长完全失去了“日报”的意义。第四步分类打标。同样调 LLM但这次是分类任务。提示词里给出枚举值和每个值的定义让模型选一个最匹配的。如果模型输出的不在枚举范围内做一次重试重试还不行归入“其他”。第五步组装输出。把前面几步的结果按输出契约组装成结构化数据再渲染成 markdown。渲染模板我单独放在一个文件里方便调整格式而不动 Skill 逻辑。第六步落盘和通知。把结果写到指定目录同时发一条通知可以是邮件、消息或者只是写个日志。通知这一步是可选的但建议保留因为你需要知道 Skill 有没有正常跑完。3.4 异常处理的具体策略异常处理这块我单独拿出来讲因为它太重要了。我的策略是分三级可重试异常比如网络超时、API 限流。这类异常自动重试最多三次每次间隔递增。可跳过异常比如某个来源拉取失败、某篇文章摘要生成失败。记录错误跳过这一条继续处理后面的。致命异常比如输入契约不满足、输出目录不可写。这类异常直接终止 Skill并发出告警。这里有个经验不要试图在 Skill 内部处理所有异常。有些异常应该往上抛让调用方决定怎么处理。比如“输入日期格式不对”这种Skill 自己没法修抛出去让调用方修才是对的。Skill 内部只处理那些“自己能修”的异常。4. 实操中踩过的坑和排查技巧4.1 常见问题速查表问题现象可能原因排查方法解决思路Skill 不触发触发条件太窄检查触发日志看输入是否匹配放宽触发条件或增加语义匹配输出格式不对输出契约没写清楚对比实际输出和契约定义补充契约约束加格式校验某一步经常失败上游数据格式不稳定打印每一步的输入输出在步骤间加数据校验和转换LLM 输出不稳定提示词约束不够收集失败案例分析模式加 few-shot 示例收紧输出格式执行时间过长串行步骤太多看各步骤耗时把无依赖的步骤改成并行结果不可复现有随机因素没控制固定随机种子记录中间状态把随机性收敛到可控范围4.2 三个我踩过的真实坑第一个坑把 Skill 写得太“聪明”。一开始我在摘要步骤里加了很多判断逻辑比如“如果文章长度超过多少就分两段摘要”“如果包含代码就单独提取”。结果就是 Skill 变得极其复杂每次改一个判断都要重新测试整条链路。后来我把这些判断全部去掉摘要就是摘要不管文章多长都只输出固定长度的概括。复杂度降下来之后稳定性反而上去了。第二个坑忽略中间状态的记录。有段时间 Skill 偶尔会输出空结果但看日志又看不出哪一步出了问题。后来我在每一步都加了中间状态落盘把该步的输入和输出都存下来。再出问题的时候直接看中间文件就知道是哪一步断了。这个习惯救了我很多次强烈建议你也加上。第三个坑没有版本管理。Skill 定义改来改去有时候改坏了想回退发现不记得之前是什么样。后来我把 Skill 定义也纳入版本管理每次改动都提交改坏了直接回退。Skill 定义本质上就是代码该有的工程实践一样不能少。4.3 让 Skill 真正可复用的几个关键习惯第一个习惯是命名要具体。不要叫“数据处理 Skill”要叫“技术资讯日报生成 Skill”。名字越具体越不容易被误用也越容易在需要的时候被想起来。第二个习惯是文档和 Skill 放在一起。Skill 定义文件旁边放一个 README写清楚这个 Skill 做什么、输入输出是什么、有什么注意事项。别指望几个月后还记得细节。第三个习惯是定期清理。有些 Skill 做完一个项目就不用了留着只会让列表越来越长。定期 review 一遍把不再用的归档或删掉。Skill 库的价值不在于多而在于每一个都是活的、能用的。5. 从单个 Skill 到 Skill 网络下一步的扩展方向单个 Skill 能解决一类任务但真实业务往往需要多个 Skill 串联。比如“技术资讯日报”这个 Skill 的输出可以作为“周报生成”Skill 的输入而“周报生成”的输出又可以作为“月报汇总”的输入。当 Skill 之间形成依赖关系就构成了一个 Skill 网络。构建 Skill 网络的时候有几个点需要特别注意。接口要稳定因为一个 Skill 的输出会被多个下游消费接口一变下游全挂。依赖要显式声明不要靠隐式约定否则时间一长没人记得谁依赖谁。要有全局的监控单个 Skill 失败可能影响不大但关键路径上的 Skill 失败会导致整个网络瘫痪。我现在维护的 Skill 网络大概有十几个节点覆盖了从信息收集到报告生成的完整链路。跑了大半年最大的体会是前期在契约和异常处理上多花的时间后期都会以“不用管”的形式还回来。真正好的 Skill 网络应该是你早上打开电脑发现该跑的都跑完了该生成的都生成了你只需要看结果就行。这个方向后续还可以继续扩展比如把 Skill 的触发从定时改成事件驱动把执行从单机改成分布式把 Skill 定义从文件改成数据库存储。但这些都是后话先把单个 Skill 做扎实比什么都重要。