最近在开发者社区逛了一圈发现一个词出现的频率高得吓人Skills。GitHub上带Skills标签的仓库越来越多各家AI Agent产品也陆续把技能市场做成了标配。我实际动手做下来之后最大的感受是——这不只是一个新概念而是把以往靠堆Prompt调教AI的玩法彻底变成了按需让Agent自己读说明书、自己调工具的工程化模式。这篇文章我不打算谈虚的直接从我自己的踩坑和实操出发把这个东西到底是什么、底层怎么跑、怎么开发一个能用的Skill、以及哪些坑不能踩讲清楚。1. Skills到底是个什么东西把教一次变成复用一万次先说一个最容易混淆的地方Skills不是一个具体产品也不是某个模型独有的能力它更像一套约定俗成的组织方式。各个Agent产品把它包装成不同名字但底层逻辑趋于一致把一份技能打包成标准目录里面既有给Agent看的操作说明也有实际执行的脚本和资源Agent在接受任务时根据描述自主决定要不要加载这个技能包。这个设计的第一性原理我琢磨了很久归根结底就是——上下文资源有限。大模型处理文本的上限虽然越来越大但你不可能每次启动对话都塞几千字的步骤指南更不可能指望用户每次都把写好的方法论复述一遍。与其让用户重复描述我想要什么、应该怎么做不如把怎么做固化成一份机器可读的技能包。Agent拿到Skill相当于同时拿到了说明书和工具箱剩下的就是按图索骥。1.1 从长Prompt到Skills本质是注意力利用方式的升级早期调教Agent主流手段是写长Prompt。角色、任务、格式、示例一股脑写进去模型按着提示走。这个方法有效但有两个硬伤第一提示词一旦超过一定长度模型对关键信息的注意力会被稀释开头强调的重点到后面可能就模糊了第二Prompt是一次性的换个场景或者换个项目之前沉淀的思路很难直接复用。Skills解决的正好是这两个问题。一个Skill自带独立的描述字段Agent在接到任务时会先扫描所有可用的Skill描述如果匹配才把完整的SKILL.md加载进上下文。这种按需加载机制本质上把注意力资源做了精准分配平时技能包是沉睡的只有被调用时才苏醒。用户也不用费心维护超长Prompt把方法写进Skill之后下次再遇到同类问题Agent会自动找到它。我自己在反复试验中的体会是同一个分析任务用一套封装好的Skill来处理比直接贴一段很长的Prompt要求模型扮演专家要稳定得多。1.2 与插件、MCP、工作流的区别与协同现在市面上的概念实在太多插件、MCP、Workflow、Action再加上Skills初学者很容易懵。以我个人的理解它们的定位其实可以做个简单区分概念定位解决什么问题Prompt一次性指令告诉模型当前任务怎么做Skill可复用的技能包让Agent自主识别并调用通用流程MCP工具连接协议把外部数据源、操作系统接口标准化地接到Agent上插件 / Workflow上层编排绑定特定应用环境做自动化流程组合举个例子你就明白了。MCP解决的是怎么让Agent打开数据库、怎么调用某个API这类连接问题它很像给Agent装上的各种插头而Skills解决的是当你需要做代码审查、写周报、画分镜时该按什么步骤来这类方法问题它更像一个装着流程和脚本的工具包。两者还能协同Skill的脚本内部完全可以去调用MCP暴露的工具一边管方法一边管通道。搞清这层关系后面设计自己的Skill时你就知道什么东西该放进Skill什么东西该交给MCP或插件去管了。2. 核心机制拆解一个Skill从被调用到产出的完整链路要真正掌握Skills不能只停留在概念层面。我建议从一个任务进来之后到底发生了什么来理解它的内部链路。整条链路拆开看大约是任务输入 - Agent扫描所有Skill描述 - 命中某个Skill - 读取SKILL.md - 按指令执行脚本/引用资源 - 产出结果并返回。这个过程中最容易被忽视但影响最大的往往是SKILL.md和命名描述的设计。2.1 元信息是开关SKILL.md是操作手册大多数Skill规范里SKILL.md的开头都要求一段YAML格式的元信息里面最关键的就是name和description。很多人以为这只是装饰实际不然。name基本只有人类管理时用得上而description是Agent判断这个技能适不适用于当前任务的核心依据。description写得好不好直接决定Agent会不会在正确时机调用这个Skill。比如你写用于代码审查太笼统了Agent遇到和代码沾边的任务可能都会尝试调用很混乱如果写成对前端JS/TS代码做静态审查检测潜在错误、风格问题和安全风险适用于PR评审前的本地检查命中率和场景匹配度会明显提高。SKILL.md的正文部分则是给Agent看的操作手册它会指导Agent按步骤执行先看哪些文件、运行什么命令、如何解读脚本输出、最终按什么格式汇总。你可以把元信息理解为快递单上的收件地址正文就是包裹里的安装说明书。2.2 scripts、resources、assets目录里的分工逻辑打开一个设计良好的Skill仓库目录通常长这样my-skill/ ├── SKILL.md ├── scripts/ │ ├── analyze.py │ └── report.js └── assets/ ├── example-input.txt └── reference.mdscripts目录存放的是实际要执行的可执行文件或脚本Agent在需要时会调用命令行工具去运行它们assets目录存的是辅助资料比如模板、示例、参考文档Agent可以把它们作为输入或读取对象。有些实现还支持references目录用来装比较长的背景知识文档平时不占上下文只有相关时才按需读取。这套目录结构并不复杂但它是整个Skill能被Agent正确调用的基础。命名上保持清晰目录不要套太深脚本尽量做到自包含这些都是我在维护多个Skill之后得出的经验。依赖外部包越多Skill的可用性越差因为这个技能包一旦移到别的环境很可能因为缺少依赖直接跑不起来。2.3 命名、描述与触发影响调用效果的三个隐性因素在实际测试中有三个容易被忽略但会显著影响调用效果的因素。一是Skill的名字尽量用动作加对象的结构比如analyze-frontend-code明显比fe-helper更直白二是description中要写清楚什么时候用最好点名场景和排除项避免误触发三是脚本入口的说明Agent是通过自然语言去决定调用命令的如果你在SKILL.md中没有写清楚运行python scripts/analyze.py -i 它可能就会用错误的参数组合。这就像你给一个实习生交代任务光说去处理数据远远不够要说清楚先跑这个脚本、传什么参数、看哪个输出文件、什么情况算异常。这里我不厌其烦地推荐一个做法在SKILL.md正文中明确写一段执行步骤按顺序列出命令和结果判断标准并附带一个简单示例这个Skill的成功率会瞬间提高不少。3. 手把手开发一个前端代码审查Skill理论说得再多不如自己动手做一个。我拿自己经常用的一个场景来演示开发一个前端代码审查Skill。这个Skill的定位是在PR合并前或代码提交前对指定目录下的JS/TS代码做一遍自动化检查输出问题清单和修复建议。整个开发过程我拆成了五步你照着做基本都能复现。3.1 需求拆解先定义清楚边界和产出做任何Skill之前第一件事是定边界。我当时对前端审查Skill的要求是只针对前端项目只检查JS/TS文件不跑完整测试套件输出格式统一为严重程度 文件位置 问题描述 修复建议四要素。边界定得越清楚后续写description就越轻松。同时还要回答一个关键问题脚本到底要做什么我的方案是用Node脚本配合ESLint来做静态规则检查再额外跑一段正则风格的自定义扫描用来发现API Key硬编码、console.log遗漏这类ESLint默认规则不太管的问题。产出物是一份JSON中间结果后续交给Agent来解读并写成人类可读的审查报告。这一步明确了脚本开发和SKILL.md编写就有依据了不会出现Agent拿到Skill却不知道怎么用的尴尬。3.2 编写SKILL.md元信息、指令、示例三件套SKILL.md是技能包的大脑写法直接影响Agent执行质量。我常用的模板是YAML头部加正文正文分为概述、使用场景、执行步骤、注意事项、示例五个部分。以我的前端代码审查Skill为例--- name: frontend-code-review description: 对 JavaScript/TypeScript 前端项目进行静态审查检测代码规范、 常见错误、安全问题输出问题清单和修复建议。适用于 PR 评审、提交前自检 不适用于后端或全项目大范围重构。 ---正文部分我会写清楚操作流程第一步让Agent先读取指定的配置文件或目录结构第二步运行审查脚本并把输出定位到一个临时文件第三步要求Agent根据JSON结果输出Markdown报告按严重程度排序第四步明确禁止Agent擅自修改源码只能输出建议。这些边界提示很关键不然Agent很多时候会自作主张直接帮你改代码反而埋雷。示例部分我一般放一段简短的输入命令示例方便Agent参照。比如node scripts/audit.js --dir ./src --format json --output ./review-result.json顺便说一句SKILL.md别写得太啰嗦。我第一次写的时候把各种边缘情况全都写了进去结果Agent执行时总是在判断该走哪条分支反而效率变差。后来我精简成主流程 关键注意事项两级结构效果好很多。3.3 脚本实现Node还是Python怎么选写Skill的脚本时你首先会面临技术栈选型。我的经验是优先考虑目标Agent运行环境里最原生的语言。如果这个Skill主要跑在Node生态的前端项目里用Node.js写依赖安装方便调用也自然如果是数据类的处理任务Python更合适因为文件处理、数据加工、各类算法库都更顺手。以我的审查脚本为例我选了Node.js因为它能直接复用项目里的node_modules比如ESLint。脚本结构很简单入口读取命令行参数解析目录调用ESLint的Node API做lint再跑一段自定义的正则扫描最后汇总成JSON。伪代码风格如下const { ESLint } require(eslint); async function runAudit(directory) { const eslint new ESLint({ fix: false }); const results await eslint.lintFiles([${directory}/**/*.{js,ts}]); // 遍历 results提取 messages加上自定义扫描结果 const formatted results.flatMap(r r.messages.map(m ({ severity: m.severity 2 ? error : warning, file: r.filePath, line: m.line, message: m.message, ruleId: m.ruleId })) ); console.log(JSON.stringify(formatted, null, 2)); } runAudit(process.argv[2]);这里有个细节不要让脚本输出大段彩色日志或无关信息尽量输出纯净的格式化结果因为Agent需要依赖输出来生成报告。输出越结构化Agent解读越准确。3.4 本地验证与调试让Agent真的去用它开发完Skill不要直接丢进Agent环境就完事。我通常会在本地先做一轮手动验证确认脚本单独跑没有任何问题。然后才把Skill目录放到Agent的skills目录下给它一个真实的审查任务观察它是否会自动调用。这里我遇到过一个典型问题Agent确实识别出了这个Skill但执行脚本的时候参数传错了。原因是我在SKILL.md里没有写清楚参数的含义。后来我把参数说明加到了正文里比如--dir 指定要审查的目录、--output 指定临时输出文件路径再试就稳定多了。调试时建议开Agent的详细日志能清楚看到它读取了哪些文件、运行了什么命令、输出了什么方便定位问题出在哪个环节。3.5 安装、发布与多人协作做完本地验证之后就是安装与分发的问题了。不同产品对Skill的安装路径有各自约定但大体思路是一致的把整个技能包目录放进Agent能扫描的固定目录即可。我自己的习惯是把每个Skill维护成独立的Git仓库结构固定然后在本机做一个统一的skills目录里面通过git clone拉取或通过符号链接指向各个仓库。关于Skill的分享和下载现在已有不少社区平台做这件事包括各家的官方市场也有很多开发者把自己整理的Skill合集直接公开在GitHub仓库里。下载平台怎么选我的建议是优先选择那些有版本记录、有描述文档、更新活跃的仓库避免下到结构不完整或脚本有问题的技能包。下载之后先看一眼目录结构确认包含SKILL.md再使用这是最基本的辨别办法。多人协作时文档就变得更重要了。SKILL.md打包的既有代码也有方法论最好在仓库README里写明适用场景、依赖要求、已知限制减少团队里其他同事的上手成本。我在团队内部实践过一版把公共的审查、检查类流程都用Skills沉淀下来之后新人熟悉Agent的使用习惯就快了很多因为这些习以为常的检查流程已经变成了可复用的标准动作。4. 容易踩的坑与现场排查实录Skills这东西乍一看简单用起来却有不少暗坑。我把自己在开发和测试过程中真实遇到过的问题整理成了一份速查表附上排查思路。有些坑属于设计层面的有些是环境层面的都值得记一下。4.1 SKILL.md写得太抽象或太啰嗦这是我看到最多的问题。写得太抽象Agent不知道从哪里下手写得太啰嗦Agent在判断分支时反而混乱。我的标准是正文控制在300到600行以内执行步骤部分尽量用命令和明确的行为描述不要写分析文件这种空话要写运行node scripts/audit.js --dir ./src读取输出结果。同时把禁止做的事单独列一节比如禁止自动修改源码禁止直接删除测试文件这类负面约束对Agent的约束力往往比正面指令更强。4.2 脚本权限、依赖与路径问题环境相关的坑主要集中在这几个方向第一脚本没加执行权限Agent调用时直接Permission denied第二脚本依赖的npm包或Python包没有安装第三脚本里使用了绝对路径导致换台机器完全跑不了。这些问题在发布的时候特别容易坑到别人。我的排查思路很固定先在Shell里手动执行一遍脚本命令确认能跑通再检查依赖是否声明在package.json或requirements.txt里最后把路径改成相对当前Skill目录的写法这样移植性会好很多。还有一个很容易忽略的点Agent执行命令时的当前工作目录不一定是Skill所在目录所以脚本内部如果有文件读取要注意路径计算建议基于脚本自身位置来定位资源文件。4.3 多个Skill之间的互相干扰当你装了十几个Skill之后新的问题出现了Agent面对多个描述近似的Skill时会选择困难甚至选错。比如我同时装了前端代码审查和全栈代码规范检查两个Skill某个任务里Agent选错了输出风格完全不对。排查下来问题出在description写得有重叠。解药是给每个Skill的description增加明确的排除条件。比如前端代码审查里就写明不适用于Python或后端Java代码全栈代码规范检查则写明侧重配置文件与跨语言通用规范。这样Agent做匹配时就能把无关项过滤掉。这个调整看着不起眼但对整体调用准确率提升非常明显。4.4 常见问题速查表现象可能原因排查思路Agent从未调用Skilldescription太笼统或场景不匹配检查描述是否写明适用场景试着明确排除项调用了但结果不对SKILL.md步骤不清晰或参数未说明补全执行步骤明确命令参数含义脚本报Permission denied缺少执行权限执行chmod x或改用node xxx.js调用输出结果很长且混乱脚本输出包含无关日志让脚本只输出结构化结果重定向日志到临时文件Agent同时启用多个Skilldescription边界重叠为每个Skill添加排除使用场景的说明Skill换了环境跑不通依赖未声明或路径写死检查依赖文件路径改为基于Skill目录的相对路径还有一个我个人的经验比上面这些都重要每一个Skill都要配一个最小冒烟测试样例。比如前端审查Skill配一段有明显问题的代码片段分镜Skill配一段待拆解的剧本。每次改完Skill跑一遍冒烟测试确认基本链路仍通再放心的用。这个习惯帮我挡下了好几次回归问题。5. 实践心得Skills该怎么积累才不变成一次性玩具如果你只是把网上现成的Marketplace里别人做好的Skill下载来用那体验确实很省事但要真正发挥Skills的价值我还是建议亲自动手封装几个属于自己工作流的技能包。原因是真正贴合你工作流的方法论网上往往找不到完整的现成版本只有你自己最清楚一份合格报告长什么样一次代码审查该查哪些重点。我的一个体会是Skills的价值其实是慢慢浮现出来的。刚做好第一个Skill时可能会觉得这也没比我自己复制一段Prompt快多少啊。但当你把工作流程里那些重复发生、有明确判断规则、需要沉淀经验的任务一个一个包成技能后面再接到类似任务时就不需要从头组织思路直接交给Agent处理再上手检查结果就行。这种复利效果是临时写Prompt比不了的。最后分享一个小技巧Skill不是做一次就完事它是可以迭代的。每次运行之后如果发现输出格式不好、步骤不够完整、脚本误判率偏高就把修改记下来并更新到SKILL.md里。我自己实践中大多数Skill在前两三次使用后都会有一次明显的打磨期度过之后才算真正沉淀成了稳定可靠的能力。这也提醒我别指望一个Skill一步到位边用边改是这类技能包工程里最正常的节奏。
最近在开发者社区逛了一圈发现一个词出现的频率高得吓人Skills。GitHub上带Skills标签的仓库越来越多各家AI Agent产品也陆续把技能市场做成了标配。我实际动手做下来之后最大的感受是——这不只是一个新概念而是把以往靠堆Prompt调教AI的玩法彻底变成了按需让Agent自己读说明书、自己调工具的工程化模式。这篇文章我不打算谈虚的直接从我自己的踩坑和实操出发把这个东西到底是什么、底层怎么跑、怎么开发一个能用的Skill、以及哪些坑不能踩讲清楚。1. Skills到底是个什么东西把教一次变成复用一万次先说一个最容易混淆的地方Skills不是一个具体产品也不是某个模型独有的能力它更像一套约定俗成的组织方式。各个Agent产品把它包装成不同名字但底层逻辑趋于一致把一份技能打包成标准目录里面既有给Agent看的操作说明也有实际执行的脚本和资源Agent在接受任务时根据描述自主决定要不要加载这个技能包。这个设计的第一性原理我琢磨了很久归根结底就是——上下文资源有限。大模型处理文本的上限虽然越来越大但你不可能每次启动对话都塞几千字的步骤指南更不可能指望用户每次都把写好的方法论复述一遍。与其让用户重复描述我想要什么、应该怎么做不如把怎么做固化成一份机器可读的技能包。Agent拿到Skill相当于同时拿到了说明书和工具箱剩下的就是按图索骥。1.1 从长Prompt到Skills本质是注意力利用方式的升级早期调教Agent主流手段是写长Prompt。角色、任务、格式、示例一股脑写进去模型按着提示走。这个方法有效但有两个硬伤第一提示词一旦超过一定长度模型对关键信息的注意力会被稀释开头强调的重点到后面可能就模糊了第二Prompt是一次性的换个场景或者换个项目之前沉淀的思路很难直接复用。Skills解决的正好是这两个问题。一个Skill自带独立的描述字段Agent在接到任务时会先扫描所有可用的Skill描述如果匹配才把完整的SKILL.md加载进上下文。这种按需加载机制本质上把注意力资源做了精准分配平时技能包是沉睡的只有被调用时才苏醒。用户也不用费心维护超长Prompt把方法写进Skill之后下次再遇到同类问题Agent会自动找到它。我自己在反复试验中的体会是同一个分析任务用一套封装好的Skill来处理比直接贴一段很长的Prompt要求模型扮演专家要稳定得多。1.2 与插件、MCP、工作流的区别与协同现在市面上的概念实在太多插件、MCP、Workflow、Action再加上Skills初学者很容易懵。以我个人的理解它们的定位其实可以做个简单区分概念定位解决什么问题Prompt一次性指令告诉模型当前任务怎么做Skill可复用的技能包让Agent自主识别并调用通用流程MCP工具连接协议把外部数据源、操作系统接口标准化地接到Agent上插件 / Workflow上层编排绑定特定应用环境做自动化流程组合举个例子你就明白了。MCP解决的是怎么让Agent打开数据库、怎么调用某个API这类连接问题它很像给Agent装上的各种插头而Skills解决的是当你需要做代码审查、写周报、画分镜时该按什么步骤来这类方法问题它更像一个装着流程和脚本的工具包。两者还能协同Skill的脚本内部完全可以去调用MCP暴露的工具一边管方法一边管通道。搞清这层关系后面设计自己的Skill时你就知道什么东西该放进Skill什么东西该交给MCP或插件去管了。2. 核心机制拆解一个Skill从被调用到产出的完整链路要真正掌握Skills不能只停留在概念层面。我建议从一个任务进来之后到底发生了什么来理解它的内部链路。整条链路拆开看大约是任务输入 - Agent扫描所有Skill描述 - 命中某个Skill - 读取SKILL.md - 按指令执行脚本/引用资源 - 产出结果并返回。这个过程中最容易被忽视但影响最大的往往是SKILL.md和命名描述的设计。2.1 元信息是开关SKILL.md是操作手册大多数Skill规范里SKILL.md的开头都要求一段YAML格式的元信息里面最关键的就是name和description。很多人以为这只是装饰实际不然。name基本只有人类管理时用得上而description是Agent判断这个技能适不适用于当前任务的核心依据。description写得好不好直接决定Agent会不会在正确时机调用这个Skill。比如你写用于代码审查太笼统了Agent遇到和代码沾边的任务可能都会尝试调用很混乱如果写成对前端JS/TS代码做静态审查检测潜在错误、风格问题和安全风险适用于PR评审前的本地检查命中率和场景匹配度会明显提高。SKILL.md的正文部分则是给Agent看的操作手册它会指导Agent按步骤执行先看哪些文件、运行什么命令、如何解读脚本输出、最终按什么格式汇总。你可以把元信息理解为快递单上的收件地址正文就是包裹里的安装说明书。2.2 scripts、resources、assets目录里的分工逻辑打开一个设计良好的Skill仓库目录通常长这样my-skill/ ├── SKILL.md ├── scripts/ │ ├── analyze.py │ └── report.js └── assets/ ├── example-input.txt └── reference.mdscripts目录存放的是实际要执行的可执行文件或脚本Agent在需要时会调用命令行工具去运行它们assets目录存的是辅助资料比如模板、示例、参考文档Agent可以把它们作为输入或读取对象。有些实现还支持references目录用来装比较长的背景知识文档平时不占上下文只有相关时才按需读取。这套目录结构并不复杂但它是整个Skill能被Agent正确调用的基础。命名上保持清晰目录不要套太深脚本尽量做到自包含这些都是我在维护多个Skill之后得出的经验。依赖外部包越多Skill的可用性越差因为这个技能包一旦移到别的环境很可能因为缺少依赖直接跑不起来。2.3 命名、描述与触发影响调用效果的三个隐性因素在实际测试中有三个容易被忽略但会显著影响调用效果的因素。一是Skill的名字尽量用动作加对象的结构比如analyze-frontend-code明显比fe-helper更直白二是description中要写清楚什么时候用最好点名场景和排除项避免误触发三是脚本入口的说明Agent是通过自然语言去决定调用命令的如果你在SKILL.md中没有写清楚运行python scripts/analyze.py -i 它可能就会用错误的参数组合。这就像你给一个实习生交代任务光说去处理数据远远不够要说清楚先跑这个脚本、传什么参数、看哪个输出文件、什么情况算异常。这里我不厌其烦地推荐一个做法在SKILL.md正文中明确写一段执行步骤按顺序列出命令和结果判断标准并附带一个简单示例这个Skill的成功率会瞬间提高不少。3. 手把手开发一个前端代码审查Skill理论说得再多不如自己动手做一个。我拿自己经常用的一个场景来演示开发一个前端代码审查Skill。这个Skill的定位是在PR合并前或代码提交前对指定目录下的JS/TS代码做一遍自动化检查输出问题清单和修复建议。整个开发过程我拆成了五步你照着做基本都能复现。3.1 需求拆解先定义清楚边界和产出做任何Skill之前第一件事是定边界。我当时对前端审查Skill的要求是只针对前端项目只检查JS/TS文件不跑完整测试套件输出格式统一为严重程度 文件位置 问题描述 修复建议四要素。边界定得越清楚后续写description就越轻松。同时还要回答一个关键问题脚本到底要做什么我的方案是用Node脚本配合ESLint来做静态规则检查再额外跑一段正则风格的自定义扫描用来发现API Key硬编码、console.log遗漏这类ESLint默认规则不太管的问题。产出物是一份JSON中间结果后续交给Agent来解读并写成人类可读的审查报告。这一步明确了脚本开发和SKILL.md编写就有依据了不会出现Agent拿到Skill却不知道怎么用的尴尬。3.2 编写SKILL.md元信息、指令、示例三件套SKILL.md是技能包的大脑写法直接影响Agent执行质量。我常用的模板是YAML头部加正文正文分为概述、使用场景、执行步骤、注意事项、示例五个部分。以我的前端代码审查Skill为例--- name: frontend-code-review description: 对 JavaScript/TypeScript 前端项目进行静态审查检测代码规范、 常见错误、安全问题输出问题清单和修复建议。适用于 PR 评审、提交前自检 不适用于后端或全项目大范围重构。 ---正文部分我会写清楚操作流程第一步让Agent先读取指定的配置文件或目录结构第二步运行审查脚本并把输出定位到一个临时文件第三步要求Agent根据JSON结果输出Markdown报告按严重程度排序第四步明确禁止Agent擅自修改源码只能输出建议。这些边界提示很关键不然Agent很多时候会自作主张直接帮你改代码反而埋雷。示例部分我一般放一段简短的输入命令示例方便Agent参照。比如node scripts/audit.js --dir ./src --format json --output ./review-result.json顺便说一句SKILL.md别写得太啰嗦。我第一次写的时候把各种边缘情况全都写了进去结果Agent执行时总是在判断该走哪条分支反而效率变差。后来我精简成主流程 关键注意事项两级结构效果好很多。3.3 脚本实现Node还是Python怎么选写Skill的脚本时你首先会面临技术栈选型。我的经验是优先考虑目标Agent运行环境里最原生的语言。如果这个Skill主要跑在Node生态的前端项目里用Node.js写依赖安装方便调用也自然如果是数据类的处理任务Python更合适因为文件处理、数据加工、各类算法库都更顺手。以我的审查脚本为例我选了Node.js因为它能直接复用项目里的node_modules比如ESLint。脚本结构很简单入口读取命令行参数解析目录调用ESLint的Node API做lint再跑一段自定义的正则扫描最后汇总成JSON。伪代码风格如下const { ESLint } require(eslint); async function runAudit(directory) { const eslint new ESLint({ fix: false }); const results await eslint.lintFiles([${directory}/**/*.{js,ts}]); // 遍历 results提取 messages加上自定义扫描结果 const formatted results.flatMap(r r.messages.map(m ({ severity: m.severity 2 ? error : warning, file: r.filePath, line: m.line, message: m.message, ruleId: m.ruleId })) ); console.log(JSON.stringify(formatted, null, 2)); } runAudit(process.argv[2]);这里有个细节不要让脚本输出大段彩色日志或无关信息尽量输出纯净的格式化结果因为Agent需要依赖输出来生成报告。输出越结构化Agent解读越准确。3.4 本地验证与调试让Agent真的去用它开发完Skill不要直接丢进Agent环境就完事。我通常会在本地先做一轮手动验证确认脚本单独跑没有任何问题。然后才把Skill目录放到Agent的skills目录下给它一个真实的审查任务观察它是否会自动调用。这里我遇到过一个典型问题Agent确实识别出了这个Skill但执行脚本的时候参数传错了。原因是我在SKILL.md里没有写清楚参数的含义。后来我把参数说明加到了正文里比如--dir 指定要审查的目录、--output 指定临时输出文件路径再试就稳定多了。调试时建议开Agent的详细日志能清楚看到它读取了哪些文件、运行了什么命令、输出了什么方便定位问题出在哪个环节。3.5 安装、发布与多人协作做完本地验证之后就是安装与分发的问题了。不同产品对Skill的安装路径有各自约定但大体思路是一致的把整个技能包目录放进Agent能扫描的固定目录即可。我自己的习惯是把每个Skill维护成独立的Git仓库结构固定然后在本机做一个统一的skills目录里面通过git clone拉取或通过符号链接指向各个仓库。关于Skill的分享和下载现在已有不少社区平台做这件事包括各家的官方市场也有很多开发者把自己整理的Skill合集直接公开在GitHub仓库里。下载平台怎么选我的建议是优先选择那些有版本记录、有描述文档、更新活跃的仓库避免下到结构不完整或脚本有问题的技能包。下载之后先看一眼目录结构确认包含SKILL.md再使用这是最基本的辨别办法。多人协作时文档就变得更重要了。SKILL.md打包的既有代码也有方法论最好在仓库README里写明适用场景、依赖要求、已知限制减少团队里其他同事的上手成本。我在团队内部实践过一版把公共的审查、检查类流程都用Skills沉淀下来之后新人熟悉Agent的使用习惯就快了很多因为这些习以为常的检查流程已经变成了可复用的标准动作。4. 容易踩的坑与现场排查实录Skills这东西乍一看简单用起来却有不少暗坑。我把自己在开发和测试过程中真实遇到过的问题整理成了一份速查表附上排查思路。有些坑属于设计层面的有些是环境层面的都值得记一下。4.1 SKILL.md写得太抽象或太啰嗦这是我看到最多的问题。写得太抽象Agent不知道从哪里下手写得太啰嗦Agent在判断分支时反而混乱。我的标准是正文控制在300到600行以内执行步骤部分尽量用命令和明确的行为描述不要写分析文件这种空话要写运行node scripts/audit.js --dir ./src读取输出结果。同时把禁止做的事单独列一节比如禁止自动修改源码禁止直接删除测试文件这类负面约束对Agent的约束力往往比正面指令更强。4.2 脚本权限、依赖与路径问题环境相关的坑主要集中在这几个方向第一脚本没加执行权限Agent调用时直接Permission denied第二脚本依赖的npm包或Python包没有安装第三脚本里使用了绝对路径导致换台机器完全跑不了。这些问题在发布的时候特别容易坑到别人。我的排查思路很固定先在Shell里手动执行一遍脚本命令确认能跑通再检查依赖是否声明在package.json或requirements.txt里最后把路径改成相对当前Skill目录的写法这样移植性会好很多。还有一个很容易忽略的点Agent执行命令时的当前工作目录不一定是Skill所在目录所以脚本内部如果有文件读取要注意路径计算建议基于脚本自身位置来定位资源文件。4.3 多个Skill之间的互相干扰当你装了十几个Skill之后新的问题出现了Agent面对多个描述近似的Skill时会选择困难甚至选错。比如我同时装了前端代码审查和全栈代码规范检查两个Skill某个任务里Agent选错了输出风格完全不对。排查下来问题出在description写得有重叠。解药是给每个Skill的description增加明确的排除条件。比如前端代码审查里就写明不适用于Python或后端Java代码全栈代码规范检查则写明侧重配置文件与跨语言通用规范。这样Agent做匹配时就能把无关项过滤掉。这个调整看着不起眼但对整体调用准确率提升非常明显。4.4 常见问题速查表现象可能原因排查思路Agent从未调用Skilldescription太笼统或场景不匹配检查描述是否写明适用场景试着明确排除项调用了但结果不对SKILL.md步骤不清晰或参数未说明补全执行步骤明确命令参数含义脚本报Permission denied缺少执行权限执行chmod x或改用node xxx.js调用输出结果很长且混乱脚本输出包含无关日志让脚本只输出结构化结果重定向日志到临时文件Agent同时启用多个Skilldescription边界重叠为每个Skill添加排除使用场景的说明Skill换了环境跑不通依赖未声明或路径写死检查依赖文件路径改为基于Skill目录的相对路径还有一个我个人的经验比上面这些都重要每一个Skill都要配一个最小冒烟测试样例。比如前端审查Skill配一段有明显问题的代码片段分镜Skill配一段待拆解的剧本。每次改完Skill跑一遍冒烟测试确认基本链路仍通再放心的用。这个习惯帮我挡下了好几次回归问题。5. 实践心得Skills该怎么积累才不变成一次性玩具如果你只是把网上现成的Marketplace里别人做好的Skill下载来用那体验确实很省事但要真正发挥Skills的价值我还是建议亲自动手封装几个属于自己工作流的技能包。原因是真正贴合你工作流的方法论网上往往找不到完整的现成版本只有你自己最清楚一份合格报告长什么样一次代码审查该查哪些重点。我的一个体会是Skills的价值其实是慢慢浮现出来的。刚做好第一个Skill时可能会觉得这也没比我自己复制一段Prompt快多少啊。但当你把工作流程里那些重复发生、有明确判断规则、需要沉淀经验的任务一个一个包成技能后面再接到类似任务时就不需要从头组织思路直接交给Agent处理再上手检查结果就行。这种复利效果是临时写Prompt比不了的。最后分享一个小技巧Skill不是做一次就完事它是可以迭代的。每次运行之后如果发现输出格式不好、步骤不够完整、脚本误判率偏高就把修改记下来并更新到SKILL.md里。我自己实践中大多数Skill在前两三次使用后都会有一次明显的打磨期度过之后才算真正沉淀成了稳定可靠的能力。这也提醒我别指望一个Skill一步到位边用边改是这类技能包工程里最正常的节奏。
