最近被问得最多的一个问题不是“你用的哪个模型”而是“你摆弄一堆工具到底有啥用”。说实话我自己从最早写裸prompt到四处挂MCP服务再到给Claude Code、Codex、Cursor配各种插件中间绕了不少路。回头一看真正的转折点不是“又多了一个工具”而是想明白了一个很朴素的东西光有一堆工具不够Skill才是把零散动作固化下来变成可复用业务能力的那层关键。在AI Agent圈子里Skill这个词最近非常热。Claude的Agent Skills、Codex的skill、OpenCode的skill安装、Cursor里的skill推荐到处都是。但很多人把它当成又一个插件装几个就完事。我觉得这种理解有点浪费。Skill真正的价值是把“怎么做”沉淀下来——你不需要每次重新告诉模型你的会议纪要规范、你的代码审查清单、你的周报格式。写完一次就能在所有后续对话里稳定复用。这篇文章我不聊装了多少个skill这种表面功夫我想聊聊怎么判断什么能力值得固化、怎么写一个真正好用的skill、以及踩过的那些坑。1. Skill到底是什么为什么“工具很多”不够用1.1 从一次会议纪要说起先说个特别日常的场景。我每周要开三次项目例会每次一个多小时记完流水账之后还得整理发到群里。之前我的做法是把录音转写文本贴给模型然后打一大段prompt“请提取待办、负责人、截止时间格式用表格……”这段话我写了不下二十遍。后来我把它写进了系统提示结果其他对话里模型也会背着这段规则反而干扰。再后来我挂了各种工具转录有转录的工具日历有日历的工具但是模型还是不知道“你到底想让我按什么格式输出”。这个困惑的答案其实就是Skill。Skill不是给你一个接口而是给模型一份“怎么完成任务”的说明书。它记录的是流程、约束、输出格式、注意事项必要的时候还能带上脚本和示例文件。我把会议纪要的规范写进一个叫meeting-minutes的Skill之后只需要丢一句“整理今天下午的会”模型就会自动加载这个技能按我事先定义好的结构输出。动作从“每次手打prompt”变成了“一次定义、永久复用”。1.2 Skill、MCP工具、插件、Agent到底啥关系很多人分不清这几个概念我刚接触的时候也特别乱。用大白话总结一下。MCP工具像是一把螺丝刀提供某个原子操作。它解决的是“能干什么”的问题比如“读写某个文件”“查询某个数据库”。有了工具模型有了手但不会有方法论。Skill像是一本操作手册。它解决的是“怎么干得对、干得稳”的问题。它不提供新的API而是告诉模型在什么场景下用哪些工具、按什么步骤、输出什么格式。插件偏代码层面的封装一般指编译好的功能扩展。有些插件会自带skill但skill本身并不强制要求是代码。Agent像是一个项目经理。它负责拆解目标、安排步骤、决定调用哪个工具或加载哪个技能。Skill是Agent手里可以调用的“经验卡片”Agent是调度者。我用了一个词叫“经验卡片”这里面有个很关键的技术细节Skill通常不需要经过复杂的API注册它就是一个文档或者一个目录写在约定的路径下。模型在对话开始时会扫描这些skill的元数据如果发现当前需求匹配某个skill的描述就自动把这个skill的内容注入上下文然后按其中的指引干活。所以它天然跨工具、跨场景Claude能读Codex也能读类似结构的文件。这也是为什么Skill能在短时间内火起来——它把抽象的“智能体能力”变成了大家都能写、都能分享的普通文件。1.3 Skill的本质是“给AI看的SOP”我经常跟朋友说Skill的本质就是SOP标准作业程序。企业里带新人光给新人一堆工具没用你给他一个清单“客户投诉进来第一步安抚情绪第二步确认订单第三步补偿方案第四步登记。”新人照着做就能干得差不多。这个清单的价值不在“用到了什么系统”而在“把每一步固化下来了”。Skill干的是一模一样的事。区别仅仅是这套SOP是写给大模型看的所以它必须写得足够无歧义、可执行。模型没有“从业多年”的潜意识它看过的东西会遗忘每次对话都是全新的。如果你不把经验固化出来它就每次都在瞎猜。这也是为什么我强调“工具一堆不如一个靠谱的skill”——工具解决的是能不能操作skill解决的是会不会干活。2. 什么样的能力值得固化成Skill2.1 三条判断标准高频、稳定、边界清晰不是什么东西都值得做成skill。做得太多太碎反而会变成新的负担。我自己习惯用三条标准卡一下。第一高频。你一周至少用几次如果一个月都用不了一两次那就别急着固化先写个临时prompt凑合。第二稳定。任务的步骤和输出格式是不是相对固定像会议纪要、周报、代码审查、发布检查清单这些事每次的流程差异都不大非常适合固化成skill。第三边界清晰。输入是什么、输出是什么能不能说清楚比如“撰写月度经营分析PPT大纲”输入是经营数据输出是PPT大纲边界非常清楚这就是个合格的skill。反过来需要大量创意的任务比如“帮我的新产品想一个slogan”这个就不太容易固化。因为好slogan本身是靠发散想出来的你写死了流程反而限制它。这类任务更适合直接对话而不是做成技能。2.2 拆分比合并更重要我见过有人一个skill试图既管会议纪要又管周报还管项目管理。听着很全能实际很惨。为什么因为description写得越宽模型越容易误触发。本来只是写封工作周报它把会议纪要的规则也加载进来输出风格乱七八糟。这里的思路跟设计接口很像宁可拆小不要搞大。每个skill只负责一个明确的动作域。会议纪就是一个skill周报是另一个skill如果两者的规范有交叉可以做一个父级的“文档规范”skill来引用。就像代码拆模块职责单一才容易维护也才容易在多个团队之间互换。2.3 典型Skill案例从文档到开发都能用拿最近很火的几个方向举例。论文写作类skill把摘要、引言、方法论、结论每个部分的写作要求固化成模板配合引用格式校验脚本投期刊前直接让模型按模板自查一遍。数学建模类的skill把常见的建模步骤、报告结构和评分要点写进SKILL.md比赛时能让不同队员的产出风格统一。PPT制作skill负责把一篇长文档压缩成逻辑树再生成符合公司视觉规范的幻灯片大纲。还有更激进的book-to-skill把一本书的框架、核心观点、关键方法论提炼成一份技能文档让模型遇到相关问题时先查“书里的方法”再回答。开发领域也一样。代码审查skill里面堆积了你所在团队的编码规范、禁止事项、以及最近几次评审中沉淀下来的高频问题模型在review时能直接套用。发布检查skill把测试、打标签、构建、通知这几个动作按顺序固化下来减少漏步骤。甚至有些团队会写一个harness生成skill让模型批量产出测试脚手架代码省掉大量重复样板。2.4 Skill的标准结构与目录一个完整的skill核心是SKILL.md文件这个文件就是一个Markdown文档。文件最开头是YAML格式的元数据至少包含name和description。name是这个技能的唯一标识description是给模型看的触发描述。接着是正文正文怎么写决定了技能好用不好用。除了SKILL.md一个成熟的skill往往还带三个东西辅助脚本比如会议纪要skill里有个脚本能把转写文本里的时间戳统一格式。这样模型可以自己决定要不要跑一下脚本。模板文件比如PPT大纲模板、周报模板放在reference目录下让模型照着填。示例输出放一两个“正确的成品案例”模型可以通过类比知道你要什么质量。目录大致是这个样子meeting-minutes/ ├── SKILL.md ├── reference/ │ ├── meeting-template.md │ └── example-output.md └── scripts/ └── normalize-timestamps.py这个目录可以被整体放到Claude Code的skills目录、OpenCode的skill目录或者直接作为git仓库分发。你不需要针对不同工具写多份同一套结构绝大部分场景都适用。3. 手把手写一个真正可复用的Skill3.1 创建SKILL.md从YAML元数据开始我手把手写一个例子就用会议纪要skill因为大家最有体感。第一步建目录mkdir -p meeting-minutes/reference meeting-minutes/scripts第二步创建SKILL.md顶部写--- name: meeting-minutes description: 将会议转写文本或会议笔记整理为结构化纪要提炼决策、待办事项、负责人和截止时间。当用户提供会议录音转写内容、聊天记录或“整理会议纪要”等请求时使用。 ---description这段特别重要等下我单独展开。元数据写完之后正文就按下面这个逻辑写任务目标一句话说清楚这个skill要完成什么。输入要求明确模型应该拿到什么输入如果没有输入要让模型先提问。处理步骤把整理纪要的步骤一项项列出来比如先提取议题、再记录决策、再整理待办。输出格式直接给出模板最好用代码块形式让模型照着套。注意事项哪些是红线比如不要编造未在会上出现过的决策。模板大致是## 会议纪要 **主题** {会议主题} **时间** {日期时间} **参会人** {人员列表} ### 会议结论 1. ... ### 待办事项 | 待办 | 负责人 | 截止时间 | 备注 | |------|--------|----------|------| | ... | ... | ... | ... |模型看到这个模板输出的稳定性会立刻上一个台阶。因为你不再依赖它“临场发挥”而是让它按结构填充。3.2 description是触发命门你该怎么写skill能不能被正确触发七成靠description。很多人的description写得像简历“该技能可以用于整理会议纪要。”模型看完了毫无感觉触发概率低。我建议把它当成一段“搜索查询”来写包含三个要素任务动词、输入材料的描述、输出物类型。举个例子description: 将原始会议记录、录音转写文本或对话笔记整理成结构化会议纪要输出包含决策、待办、负责人和截止时间的Markdown文档。当用户说“整理纪要”“会议总结”“待办提取”时应该使用。这里包含了触发词包含了输入包含了输出。模型在理解用户需求时会把这个description和当前对话做语义匹配越具体匹配越准。但description也不是越长越好写太细模型反而抓不住重点。我一般控制在150字以内把最核心的触发场景和输出说清楚就行。3.3 从“能用”到“好用”加脚本、加例子、加反例第一版skill能用之后我建议做三件升级。第一加一个辅助脚本。比如原始转写文本里时间戳很乱模型处理起来浪费时间。我在scripts里放了一个normalize.py负责把“3:05 PM”之类的时间转成标准格式。SKILL.md里明确写一行“如果输入文本包含时间戳先运行scripts/normalize.py处理。”这样模型就不用自己头疼了。第二加一个示例输出。我在reference/example-output.md里放了一份完整成品模型在遇到“不确定你期望什么格式”的时候会主动参考它。这比写一百句说明都管用。第三加一段“反例”说明。比如“不要在纪要里写‘据说’‘可能’这类模糊词”“不要主动补充会上没提到的建议”。大模型很听话你把红线写清楚它就不太会越界。3.4 实测反馈不断迭代skill写完了不等于完事我每次写新skill都会专门开一个新对话测试只输入一句话“帮我整理这段会议记录”然后看三个东西有没有触发skill、步骤有没有走偏、输出格式是不是我要的。发现问题我就回到SKILL.md里改描述或步骤再开一个新对话重测。千万不要在同一个对话里一直改一直试因为模型会记住上下文里的修正测试结果会失真。用这种方式迭代一个skill通常三四轮就能稳定。之后我会把目录推到git仓库作为团队共享资产。3.5 Skill与Agent配合单个技能还是组合编排Skill解决的是单点任务Agent解决的是全局编排。在一套多智能体系统里一个agent可能同时调度几个skill先调用research-skill查资料再调用outline-skill搭框架最后调用report-skill生成文档。skill之间也可以互相引用比如报告类skill统一引用一个company-style skill保证所有对外文档的口径一致。我见过一个比较成熟的用法让Agent在规划阶段主动声明“我将使用哪些skill”并在执行过程中记录每个skill的调用结果。这样整个流程是可追溯、可回放的。如果某个环节出了问题可以直接定位到是哪个skill的哪种规则不适用。说白了skill不是一个个孤岛而是agent工作流里的积木。你把积木做扎实了agent才能搭出复杂的业务能力。4. 主流工具里Skill的安装与使用4.1 Claude Code与Cursor目录放对位置即可Claude Code最近对skill的支持做得非常顺。你只要把skill目录放到项目的.claude/skills/下或者用户级目录下Claude就能自动识别。比如mkdir -p .claude/skills cp -r meeting-minutes .claude/skills/在会话里敲一句“整理今天的会议”Claude会在思考链路中检索skills目录下的SKILL.md描述匹配之后自动读取完整文件按技能指导执行。如果某个skill不需要所有项目都用可以用permission设置做权限控制。Cursor的思路类似它的Rules机制本质上也是一种skill形态只是命名不同。你可以把SKILL.md放到.cursor/rules或者直接作为全局规则导入。Cursor的好处是编辑器UI方便可以直接在设置里管理哪些skill全局生效、哪些只对当前项目生效。4.2 Codex与OpenCode命令行场景下的SkillOpenAI的Codex CLI引入了AGENTS.md作为项目技能描述结构和SKILL.md异曲同工都依赖一个人可读、模型可读的Markdown文件来固化行为准则。OpenCode则更直白一些有专门存放skills的目录。我在实际项目里发现只要把同样的SKILL.md内容稍作格式调整就能够在Codex和OpenCode之间复用。这里我提一个通用做法把skill的定义与工具解耦。写SKILL.md时不要写“Windows系统路径”不要写某个工具特定的说法就写纯业务逻辑和步骤。这样同一个skill今天放到Claude明天挪到Codex后天换到OpenCode都能直接跑。我甚至见过有人把一套skill同时挂进三个工具node上测试后放Claude用体验都是一样的。4.3 跨工具复用的通用技巧要做到跨工具复用需要注意几个细节。第一SKILL.md的正文里避免出现“Claude”“Codex”这类特定模型名直接用“请你”或“模型”称呼即可。第二脚本调用不要依赖某个工具的全局变量或自动注入参数直接写成标准命令行让模型自己决定传什么参数。第三输出路径不要写死优先要求模型“询问用户后决定”。还有一个容易被忽略的点不同工具对frontmatter字段的容忍度不同。有些工具要求必须有version字段有些工具会自动忽略额外字段。我建议在SKILL.md里至少保留name、description、version三个字段其他自定义字段尽量放在正文末尾不要全部塞进frontmatter否则在某个工具里可能直接解析失败。4.4 团队怎么沉淀和共享Skill个人用好skill只是第一步团队层面形成沉淀才算把“业务能力”这个说法做实。我建议用git仓库管理所有skill每个skill单独一个目录配README说明适用场景和维护人。团队里谁发现某个skill输出不稳直接提issue。这样可以避免“每个人各自写一套规则”的混乱。还要有一个评审机制。skill一旦进入正式目录至少要有两个人试用过。我吃过亏自己写的技能自己觉得挺好别人一用就“不触发”“格式不对”。原因往往是description里有个人化的缩写词团队其他人根本不说这个词。评审的目的不是走流程而是把触发词和输出模板磨到团队公共语言的水平。5. 高频踩坑与排查实录5.1 Skill不生效先查三件事第一路径对不对。Claude Code只扫描.claude/skills目录你放到外面肯定没反应。第二权限够不够。有些工具默认不允许skill执行脚本需要单独授权。第三文件格式对不对。SKILL.md开头必须严格是YAML frontmatter两个---不能少description里不能有换行缩进错误。我遇到过好几次看起来格式没问题实际上是缩进用了Tab导致解析失败。还有一个容易被忽略的问题模型需要新上下文才能“看到”skill。同一个会话里你刚改完SKILL.md继续在当前对话里测试可能还是旧行为。重启对话或者清了缓存再测往往会变正常。5.2 乱触发都是description惹的祸描述太宽泛模型什么请求都会想起它。比如我写过“会议纪要”和“项目管理”两个skill前者description里有“组织和提取信息”这类通用词结果用户问“有没有关于公司流程的信息”它也要加载会议纪要。这种问题唯一的解法就是把description改窄明确触发条件是“提供会议转写或笔记”。记住触发宁可保守一点别太激进。没触发最多就是用户再补一句说明乱触发则是整段输出文不对题。如果你想让某个skill“必须触发”除了description写精确还可以在用户输入里明确提一句“用meeting-minutes处理”。这不是作弊而是给模型一个显式的调度信号。在自动化流程里我甚至会写一个调度逻辑先根据关键词判断该加载哪些skill再注入上下文。这样等于在agent外面又加了一层路由可靠性会高不少。5.3 工具和Skill互相打架怎么办Skill经常强调“按照模板输出文件”而MCP里也有一个文件写入工具两边都在指挥模型模型就可能重复写文件或者不知道听谁的。我的经验是在SKILL.md里明确划分职责说清楚哪些步骤用工具、哪些步骤靠推理。比如“如果输出目标文件使用MCP的write_file工具但如果只是返回文本给用户直接在对话中展示即可”。另外不要在一个skill里同时调用过多外部工具每多一个工具模型的决策路径就多一个分叉出错概率跟着涨。还有一类冲突是skill之间的优先级问题。两个skill都匹配当前任务时模型不知道该听谁的。解决方法是给skill的description里加上明确的范围词比如“当任务以代码审查为主时使用”“仅用于Android项目”。优先级不是靠权重设置而是靠description的语义边界来划分。5.4 版本管理与安全问题Skill会随业务变化而变化所以要像代码一样做版本管理。我习惯在每个SKILL.md末尾加一个ChangeLog记录改动。每次大改都更新frontmatter里的version字段。这样对话里如果模型加载了旧版skill至少能看出是不是过期。安全方面也要认真对待。Skill本质上是一组“高权重指令”如果有人往git仓库里塞了一个恶意skill模型可能被引导去执行危险操作。所以不要盲目信任网上分享的skill尤其是那些要求“跳过安全检查”“直接用root权限跑脚本”的。我见过一些skill会要求模型执行任意shell命令必须仔细读源码。团队用的话建议做skill白名单没评审过的技能不允许进入正式目录。5.5 常见问题速查表现象最可能的原因处理方式skill完全不触发路径或frontmatter格式错误检查目录位置和YAML格式skill偶尔触发description触达不准确精简description补触发词输出格式乱正文模板不具体给出标准模板和示例输出执行脚本失败权限没开或脚本依赖缺失检查权限、依赖或改用纯文本步骤多个skill同时冲突description范围重叠拆分范围增加适用边界更新后无变化上下文缓存旧文件新开对话或清缓存重测这个表格是我平时排障的第一入口大部分问题不用深入调试就能定位。6. 关于“可复用业务能力”我最后想说的我在写skill的过程中最大的体会是这个事的门槛根本不是语法而是你有没有把日常工作“流程化”的思维。很多人技能写得烂不是不会Markdown是压根没想清楚自己的动作到底分几步、每步的输入输出是什么。只要想清楚这一点哪怕SKILL.md写得很朴素效果也不会差。另外分享一个小技巧我给自己建了一个golden-skill它不是用来完成某项工作而是用来“规范其他skill的写法”。它包含我总结的一套skill模板、常见字段说明、以及五六个优秀示例。每当我准备给团队新写一个skill的时候都会先让模型读取这个golden-skill然后照着框架生成。这样做之后新skill的质量下限一下子抬高了不少。你如果刚开始接触这套玩法不妨先抄一个模板逼自己把一个高频动作写成skill用两周时间体验一下“同一句话每次输出都一个水准”到底是什么感受。