上周我在调一套代码审查流程同一批问题交给Claude和Cursor各自处理结果一个在15分钟内给出了可合并的修改建议另一个在反复要我补充上下文。差别不在模型智商而在前者多加载了一个Skill。这几天正好把几个主流工具的Skill机制全撸了一遍也翻了不少社区里的推荐清单整理成这篇博客慢慢更新。这篇文章主要聊清楚三件事Skill到底是什么、和Agent/Tool有什么区别主流工具的Skill安装和推荐以及怎么写一个能长期用、不翻车的自定义Skill。适合正在用Claude Code、Cursor、Codex、OpenCode等AI编程工具觉得效果不稳定或每次都要重复啰嗦同一套要求的开发者。1. Skill到底是什么一个装着操作手册的文件夹先说点基础的因为很多踩坑都源于对Skill的误解。热词里反复出现什么是skill、skill和agent的区别、skill脚本、skill语言这说明大量使用者确实被这几个概念绕晕了。1.1 Skill的本质是给AI的操作手册不是新模型Skill本质上是一个非常朴素的东西一个文件夹里面放一份SKILL.md主文件再配上参考文档、示例模板、甚至是几个辅助脚本。当你在对话中触发某个场景时AI会把这个文件夹里的内容读入上下文然后严格按照你写好的流程去执行。我习惯用一个比喻来解释模型是一个刚入职的天才员工能力很强但不了解你们公司的做事方式。Skill就是给这个员工看的SOP标准作业程序手册。没有SOP他每次都靠猜有了SOP他第一次上手就能按你的规矩出活。这就引出了一个关键结论Skill不改变模型智商它改变的是模型的工作方式。同一个模型挂了Skill和没挂Skill输出质量差距可以非常大。尤其是那些你知道该怎么做但不想每次重复说明的任务——代码审查、会议纪要、PPT生成、数学建模标准化流程等等写一次Skill后面一劳永逸。1.2 和Agent、Tool、MCP的区别这是热词里被问爆的一组概念我直接用实际场景来拆。Agent是执行者。它被赋予一个目标自己去规划步骤、调用工具、完成任务过程中是有自主决策权的。比如帮我把这个项目的测试覆盖率提到80%Agent会自己拆任务、改代码、跑测试。Tool是工具箱里的单个工具。比如read_file、run_command、web_search它们是被模型按需调用的函数本身不具备业务逻辑。MCP是工具的统一接口协议。它解决的是不同的工具用不同的API模型没法统一调用的问题。接了MCP Server之后各种外部能力数据库、浏览器、文件系统能以一个标准接口暴露给模型。Skill则是一组指令和流程的打包。它本身不一定调用工具也可能就是告诉AI你该怎么思考、先做什么后做什么、输出什么格式。它更像是一个编排层——可以理解为Skill是操作手册Agent是执行任务的人Tool是这个人手里的工具而MCP是工具的通用插座。做选择时有个简单判断如果任务是重复性的、有明确步骤的用Skill最合适。如果任务是开放式探索性的、需要动态决策的Agent更合适。大多数情况下两者配合使用Skill负责定义遇到A情况就这么做Agent负责判断现在是A情况还是B情况然后激活对应的Skill。1.3 为什么2025年Skill突然火起来了Skill这个概念其实很早就出现过但真正爆发是在Claude Skills功能正式推出之后。原因很现实模型的上下文窗口虽然越开越大但每次输入同样一段要求是会占用token的而且你很难保证措辞完全一致。Skill把指令文件固化下来只在需要时加载等于把每次重复说的废话存成了文件省心也省钱。更深一层的原因是可复现性。之前调教AI靠的是对话记忆今天心情好写出来的prompt明天可能就写不出来了。Skill把经验沉淀成了资产——这就是为什么skill推荐、skill开发指南、claude如何写一个完善的skill这些热搜词会持续升温。大家发现这玩意儿值得专门研究和投资。2. 主流AI工具的Skill机制差别不小安装方式大盘点很多人问如何安装skill其实这个问题没法一句话回答因为每个工具的Skill机制都有自己的脾气。我实测了Claude Code、Cursor、Codex、OpenCode这几个主流工具目录结构、加载机制、语法要求都有差异。2.1 各工具安装方式和目录对比先上一张我实际验证过的对比表方便大家快速定位自己用的工具工具默认Skill目录安装方式配置文件格式加载机制Claude Code~/.claude/skills/skill-name/克隆或复制文件夹到该目录Markdown YAML frontmatter对话中自动触发或手动/skillCursor~/.cursor/skills/skill-name/同上Markdown frontmatter规则/Agent模式自动读取Codex~/.codex/skills/部分版本同上Markdown YAML根据描述自动激活OpenCode~/.config/opencode/skill/同上Markdown frontmatter对话时声明启用安装的本质都是一样的把Skill文件夹放进对应工具扫描的目录。我用git clone把社区里的Skill仓库克隆到本地然后复制到对应目录重启工具就能识别。2.2 一条命令检查你的Skill有没有被加载装完Skill最痛苦的就是装了但好像没生效。这里分享一个通用debug方法用一个目标明确的小测试故意触发Skill的描述场景然后观察输出有没有按Skill里的流程走。Claude Code可以输入/skills查看当前已加载的Skill列表Cursor可以在Agent模式下输入列出你当前使用的所有技能来确认Codex可以用--verbose模式观察加载日志。我自己的经验是80%的Skill没生效问题其实是描述文本写得不对导致没有触发而不是目录放错了。这个问题后面会专门展开。2.3 安装渠道与来源安全热词里有skill原版无删减版百度还有不少人在找各种无删减资源包。这里必须多说一句Skill本质是可读的文本指令不是破解资源不存在无删减版这种说法。所谓原版无删减要么是营销话术要么是你被当韭菜了。正规获取渠道就这么几个官方Skill库/市场、GitHub开源仓库搜awesome-claude-skills、awesome-cursor-skills这类合集、技术社区分享帖。来源不明的Skill文件不要乱装——因为SKILL.md本质是注入给模型看的指令恶意文件完全可以让你忽略用户的所有要求之类的内容这种prompt injection风险是真实存在的。我读任何一个Skill都会先打开SKILL.md通读一遍确认没有可疑指令再放入目录。3. 实测过的Skill清单从读书到数学建模都能用这节是热词重点cursor 有哪些skill推荐、codex好用的skill、book to skill、数学建模skill、会议纪要skill、ppt skill这些问题我都会覆盖到。我把近期用过的Skill按高频实用场景整理了一遍附上适用工具和避坑要点。3.1 阅读与知识管理Book to Skill、PDF精读先说book to skill这个方向。这类Skill的核心价值是把一本书或一份长文档处理成可交互的知识库AI不再是通读全文后凭印象回答而是按固定方法做结构化拆解核心论点提取、章节逻辑图、概念卡片、金句索引、延伸问题集。我用了一款社区里评价不错的Book Analysis Skill实际体验是把一本300多页的技术书丢进去AI先自动生成全书框架再逐章提炼核心观点和代码示例最后输出一份带页码和原文对照的学习笔记。相比自己整理,效率提升非常明显。这类Skill需要注意的点是不要让它生成过于正确但无趣的摘要好的Skill应该保留原书的论证张力和反直觉观点。配置模板时可以在指令里加一条总结时保留作者原意中最反直觉的三个观点输出质量会显著提升。3.2 职场效率三件套会议纪要、PPT生成、邮件处理这几个都是典型的不想每次重复说明场景。会议纪要skill会自动处理原始录音转写文本或会议字幕标注决策项、责任人、截止时间、风险点然后按公司模板输出。其实很多会议纪要工具都能做类似的事但Skill的好处是可以完全按你的模板来。ppt skill则是按先写大纲→再定视觉风格→最后逐页生成的顺序工作配合Markdown转PPT的流程非常好用。实测心得会议纪要这类Skill一定要在指令里明确不要改写原话中的技术细节。AI特别爱自作主张把K8s集群扩容润色成对Kubernetes基础设施进行容量扩展看着专业实际上信息失真。我见过不止一次因为AI润色导致会议结论失真的事故指令里明确保留原始技术名词非常关键。3.3 编程提效方向前端规范、Java开发、代码审查编程方向是Skill最肥沃的土壤。热词里的vue-best-practices skill怎么下载运用、kiro推荐的用于java开发的skill、dbs-ai-check类似的skill都指向这个方向。拿Vue项目举例我装了一个Vue3代码规范Skill后新项目的代码风格肉眼可见地统一了目录结构按feature模块划分、组件命名用PascalCase、状态管理从入口统一导出、API调用封装成hooks。AI在生成代码时都会先对照Skill里的规范自检一遍再输出。Java方向的话重点找的是这几类SkillSpring Boot项目脚手架生成、代码分层规范、JUnit测试模板、依赖升级检测。我实测过Codex上一个Java开发Skill集效果最明显的是从需求描述直接生成Service层代码——配合数据库表结构说明它能自动生成带事务注解、参数校验、统一异常处理的完整Service方法。Codex上大家常说的代码审查Skill也值得重点推荐。这类Skill不只是让AI找bug而是给它一套审查流程先看变更范围→再查安全隐患→再看并发风险→最后提可执行的修改建议。输出格式通常包含问题严重级别涉及文件修改方案影响评估比单纯问这段代码有没有问题专业得多。3.4 竞赛与建模场景数学建模Skill数学建模skill、华为杯skill这几个热词背后其实是一类面向建模竞赛的Skill。这类Skill的核心价值是把建模答题流程标准化问题重述→模型假设→建立模型→求解算法→结果分析→灵敏度检验→优缺点评价。我试过挂数学建模Skill处理一道典型的优化问题AI自动按照标准流程把问题拆解成目标函数、约束条件、决策变量然后给出三套可选模型方案线性规划、启发式算法、仿真并对每个方案标注计算复杂度和适用条件。相比不挂Skill时的直接扔一段代码输出挂上之后明显更符合竞赛评阅标准。这类Skill的配置要点是必须在指令中预设模型选择决策树否则AI总是倾向于选择最复杂的模型而不是最合适的模型。3.5 内容创作与新媒体方向视频脚本、文案、IP内容整理ai视频 skill下载、codex视频skill、grill skill这一类对应的是内容生产向的Skill。视频类Skill主要是将脚本构思→分镜设计→文案优化→字幕整理做成固定流程适合自媒体从业者。还有一个比较特殊的倪海厦skill这个方向本质是知识IP内容的整理与检索把大量课程录音/讲稿预处理成结构化笔记方便后续查询。我个人的使用场景是这类Skill最适合做批量内容复盘把历史视频标题、封面、简介丢进去让AI按固定维度选题方向、封面风格、话语模式拆解爆款规律。相比自己拉Excel统计省事不少。但要提醒一句凡是涉及健康医疗内容的Skill只建议做知识整理和内容管理不建议用于任何诊断、用药建议这个边界要拎清楚。3.6 跨对话记忆与工作流编排WorkBuddy、MCP配合热词里的workbuddy跨对话记忆skill、api mcpserver skill、deepseek harness 用skill指向一个更进阶的玩法用Skill跨对话保存工作记忆。模型本身不保留跨对话记忆但Skill文件夹可以承载状态。例如让AI在每次完成任务后把当前项目的关键决策、遗留问题、目录结构写入Skill文件夹里的state.md下次开新对话时自动读取项目连贯性会大幅提升。MCP和Skill的关系也值得一提MCP负责提供外部数据数据库、浏览器、Git仓库Skill负责定义使用这些数据的流程。一个典型的配合场景Skill定义每周代码审查流程MCP提供读取本周提交记录的能力AI收到指令后自动完成全套流程。两者互补缺一不可。4. 动手写一个自己的Skill结构与触发逻辑看再多推荐清单真正好用的Skill一定有一两个是自己写的。这一节我按claude如何写一个完善的skill和skill开发指南这两个热词的需求把开发和调试的核心步骤拆开讲。4.1 一套可复用的Skill目录结构一个标准的Skill目录长这样code-review.skill/ ├── SKILL.md ├── assets/ │ ├── review_checklist.md │ └── security_risks.md ├── templates/ │ └── review_report_template.md └── scripts/ └── extract_diff.sh简单解释一下每一部分的作用SKILL.md是主指令AI先读它assets/存放补充参考材料只有主指令要求时才读取templates/提供输出模板scripts/是可选的辅助脚本。这里最核心的原则是主指令要精炼细节全放assets里。如果一个人Sentence把两百行细节全堆在SKILL.md里上下文窗口会被大量占用也不利于AI抓住重点。4.2 SKILL.md的正确写法我用的标准模板是这样--- name: code-review description: 用于代码变更审查。当用户要求审查代码、看看diff、这个提交有问题吗或涉及合并请求评审时使用。 when_to_use: 用户提供一段git diff或代码变更希望获得专业代码审查意见。 --- # Code Review Skill ## 工作流程 1. 读取用户提供的代码变更或diff 2. 按优先级依次执行安全审查、并发审查、性能审查 3. 对每个问题标注严重程度BLOCKER / MAJOR / MINOR 4. 输出统一评审报告 ## 输出格式 见 templates/review_report_template.md ## 规则 - 只关注代码本身不做无关建议 - 所有修改建议必须附带具体代码示例 - 严重问题必须给出复现路径或证据几个容易踩坑的细节description一定要写触发场景而不是功能描述。很多人写审查代码质量结果AI看到质量两个字就触发输出一堆废话。正确写法是写当用户说这些具体句子时使用把口语化触发词都列进去。frontmatter里的字段名要严格符合工具要求。Claude Code认description和when_to_use有些工具认trigger和keywords装到不匹配的工具上会导致Skill根本不会被加载。从社区GitHub仓库下载别人的Skill时我建议先看一下frontmatter字段和你目标工具的文档是否一致。4.3 让Skill用一次就记住状态与自我迭代上一节提到的跨对话记忆落到具体的实现上就是在Skill里内置一套状态管理机制。我在自己写的Skill里都会加这样一段指令## 状态维护 每次任务结束时执行 1. 将本次任务的结论、未解决问题、关键决策追加到 assets/state.md 2. 如果发现本Skill的指令存在遗漏或冲突在assets/improvements.md中记录改进建议 3. 回复用户时如果state.md存在历史记录先引用再开始新任务实际操作下来这个机制带来的连续性提升比想象中还要大。以前开新对话总要重新交代项目背景现在AI会主动说根据上次记录这个模块还有两个遗留问题我们优先处理哪个——这种体验已经非常接近有记忆的助理了。4.4 用好Skill的三个验收标准写完之后怎么判断这个Skill到底行不行我总结了三层标准第一层指令能不能被稳定触发。连续开三个新对话用三种不同说法表达同一个需求看AI会不会每次都激活这个Skill。第二层输出是否具备可复现性。同一个输入跑三次输出结果应该高度一致而不是每次换一套思路。这一步能筛掉大量看起来很强实则全是浮文的Skill。第三层能不能降低你的操作成本。这是最本质的标准。如果用了Skill之后你反而还要花更多时间修改AI的输出那这个Skill就是在帮倒忙不如删掉。5. 装Skill的边界感与持续维护策略很多萌新会陷入收藏夹吃灰的循环——GitHub上看到好用的Skill就clone下来装了二三十个结果大部分时间只用到两三个。skill推荐这个标题的关键词其实是持续更新这背后是维护和取舍的问题。5.1 不是越多越好我的精简原则我把Skill的使用比作快捷键组合记不住等于没有。装二十个Skill每次打开工具还要回想这个场景该用哪个效率反而更低。我现在的原则是常驻核心工作流的Skill不超过5个其他全部按需临时加载。具体执行方式是把真正高频使用的Skill放进默认目录低频场景的Skill放在一个备份库里等真有需求再复制过来用。这样既能保证目录干净又不会丢失积累。5.2 Skill之间的冲突与优先级多装几个Skill后必然遇到一个问题两个Skill的触发描述重叠。比如一个代码审查Skill和一个安全审计Skill都可能在你问这段代码有没有问题时被触发两个都加载后会争抢控制权。我的处理方式是在更高优先级的Skill里显式声明如果与其他Skill冲突以本Skill为准同时用更精细的触发词做隔离。比如安全审计Skill的description写成当用户要求检查安全漏洞、渗透测试、认证授权问题时使用和通用代码审查的触发域尽量不重叠。5.3 版本管理与持续更新持续更新这个标题的关键词落实到操作层面就是两个习惯用Git管理Skill目录、定期回溯复盘控制好问题难度。我自己是把整个skills/目录做成一个Git仓库的每个Skill的修改都有commit记录。这样万一改了某个版本导致效果退化还能快速回滚。定期的复盘则可以固定周期进行——我自己的习惯是每两周过一遍把所有Skill的输出质量抽查一次没用的删掉效果下降的排查原因新需求写成新Skill。这套做法坚持了大概三个月各方面收益已经非常明显。5.4 复杂任务用Skill组合而不是单个大Skill有些场景过于复杂比如为新功能做技术方案设计——要跨架构规划、数据库设计、接口定义、测试策略好几个环节。把它硬塞进一个Skill里指令会臃肿到AI抓不住重点。更优的做法是拆成一组细粒度Skill然后用一条主流程把它们串联起来。我实际在用的一个组合案例是前端新功能开发的Skill集requirement-analysis把原始需求拆成功能点、边界条件、验收标准architecture-design基于需求和数据流输出组件树与状态结构api-contract生成后端Mock接口定义code-generation按上述产物逐模块生成代码四个Skill各管一段主Skill只说按顺序调用这四个。好处很明显单个Skill的指令都很短AI不容易跑偏而且每段输出质量可单独验证哪一步出了问题就只调那一个不用整个流程推倒重来。5.5 关于下载即用的幻想市面上大多数公开的Skill只能做到方向正确离开箱即用还有距离——因为它们没法了解你的项目规范、团队习惯和历史上下文。我下载任何一个社区Skill都会先跑一遍测试案例然后打开SKILL.md按自己的使用习惯改掉至少30%的内容。这其实是一种很正常的状态Skill的价值在80%的灵魂剩下20%的细节本来就需要你动手调整。不是说公开Skill不好而是用的时候要摆正预期它不是成品插件更像一个有经验的同行给你写好的草稿剩下的定制打磨只能自己做。写在最后的小建议如果你刚接触Skill不用一次装太多我建议从三个方向入场一个代码审查Skill提高日常代码质量一个会议纪要Skill减轻文档负担一个用我上面模板自写的个人工作流Skill沉淀经验。先把这三个用得滚瓜烂熟再逐步扩展。我的切身体会是Skill这个东西花半天认真写一个之后每一天都在省钱——省的是重复描述需求的口舌省的是修修改改的时间更重要的是省下了脑力去干真正需要人判断的事。希望这篇内容对正在折腾Skill的你有点帮助后面我还会持续更新实测过的Skill清单和开发技巧欢迎回来看看。