1. 从AI看起来很聪明但总觉得差口气说起天天用AI编程的人大概率都经历过同一个瞬间对话窗口里问了半天AI还是写不出你想要的代码。不是它笨是它缺少一种叫经验的东西。这个词近半年在AI编程圈被反复提及我指的是Skill——一套让AI在特定场景下秒变老手的可复用技能包。标题里那个1500个现成Skill指的就是目前社区里已经沉淀出来的、覆盖各种开发场景的现成技能库从Claude Code、Cursor到Codex都在往这个方向走。我自己是重度AI结对编程用户过去一年里Cursor、Windsurf、VS Code Copilot、Trae这几个主流工具都深度用过。坦白说如果只把它们当高级自动补全那确实谁都能上手但如果你想让它真的像一个干了五年的同事一样帮你干活——知道项目结构该怎么摆、知道某些坑根本不该踩、知道代码风格和测试策略怎么配合——那你需要的就是Skill而不是更长的提示词。这篇文章我不打算讲空泛的AI改变编程只聊一件事Skill到底是什么为什么它能让AI从会写代码变成懂开发以及那1500个现成Skill到底怎么用、怎么选、怎么改造成自己的。我还会把最近社区里讨论度很高的Book to Skill、Claude Code Skill开发指南、Codex安装Skill这类玩法串起来讲清楚保证你读完可以直接上手。适合谁看两种情况最对口一是你已经用AI写过代码但总觉得它在具体项目里有知识没经验想突破这个瓶颈二是你听说过Skill这个词也看到各种Skill推荐列表但不知道装到哪个目录、怎么写一份真正能被AI读懂和调用的Skill文件。这两种需求这篇文章都能覆盖。2. 为什么有知识和有经验之间隔着一道鸿沟2.1 知识是知道说什么经验是知道什么时候该说什么我先举一个特别直观的例子。你让AI写一个登录接口它的知识储备能让它在五秒内给你吐出一段标准代码接收参数、查库、比对密码、返回token。这段代码你拿到手能跑但放到真实项目里问题一个接一个参数校验不够严格、日志埋点缺失、异常处理只写了try-catch里面放了个空pass、数据库查询没有考虑索引、接口返回格式和你们团队统一规范不一致。你当然可以继续追加提示词说注意参数校验加日志用统一返回格式。但每追一句AI只能改一处你忘了说的它就默认不做。这就是有知识没经验的典型表现——它的知识库里装着无数种做法但它不知道该在什么场景下主动选择哪一种。Skill解决的恰恰是这个问题。它不是给AI更多知识而是给AI一套在某个场景下应该遵循的作业流程和判断标准。就像你带新人不会天天给他背语法手册而是给他一份团队开发规范文档告诉他拿到需求先干什么、代码结构怎么组织、异常怎么处理、命名用哪种风格、提交前跑哪些检查。AI拿到Skill之后就成了那个读过团队规范再上手干活的新人而不是一个背完了整本语法书但没有任何工作习惯的实习生。2.2 一个让我彻底改变认知的实测我自己做过一次对比测试用的是Claude Code加一个Vue组件开发Skill。同样让它写一个带搜索和分页的用户列表组件不挂Skill的时候它给我的是一个单文件组件将近300行所有逻辑挤在一起搜索是前端filter分页是自己手写的splice没有任何缓存策略也没考虑搜索防抖。挂了Skill之后同样一句话它先给我列出实现计划组件目录放哪、Props怎么定义、事件怎么向外抛、搜索用防抖还是节流、分页是前端翻还是后端查、空数据状态怎么处理、单元测试用例覆盖哪些场景。然后才开始写代码。写完的组件拆成了三个子文件有自己的类型定义还有配套的测试文件。整个过程我一句话都没多说。那一刻我意识到提示词的长度决定AI的认真程度而Skill的质量决定AI的专业程度。一个写三千字的提示词不如一份结构清晰的SKILL.md更有用因为提示词是一次性的SKILL.md是可复用的提示词是告诉AI这次你要做对SKILL.md是告诉AI这类事你每次都该这么做。这个差异正是Skill在2025年到2026年快速成为AI编程圈核心话题的根本原因。3. Skill的底层逻辑一个带作业标准的提示词工程化方案3.1 拆开一个SKILL.md看看里面有什么很多人一听Skill以为是某种神秘的新技术其实它的核心载体就是一个Markdown文件通常叫SKILL.md放在特定的目录里。拿我自己写的一个API接口开发Skill举例这个文件的结构大同小异--- name: api-endpoint-development description: 用于开发RESTful API接口。当用户需要新增、修改或调试后端接口时使用。包括参数校验、错误处理、日志规范、统一返回格式等。触发关键词写接口、新增API、接口调试。 --- # RESTful API 接口开发规范 ## 1. 输入分析 - 明确接口的入参类型、边界值、必填与非必填 - 明确接口的鉴权要求是否需要登录态、用户权限级别 ## 2. 代码模板 - 统一返回格式{ code: 0, message: success, data: ... } - 参数校验使用独立的校验层不写在业务逻辑里 - 数据库查询必须考虑索引命中避免全表扫描 ## 3. 异常处理规范 - 业务异常和系统异常分开捕获 - 日志必须包含请求ID、用户ID、接口路径、耗时 - 不要把原始异常信息直接返回给客户端 ## 4. 完成标准 - 单元测试覆盖率不低于80% - 接口文档同步更新 - 构造边界输入验证通过你会发现这不是什么黑魔法就是把一组最佳实践、流程规范、模板代码写成了一个结构化的操作手册。AI读到这个文件之后会在执行任务时把它当作最高优先级的上下文指令相当于你给AI上了一次岗前培训。3.2 Skill和普通提示词、Agent到底什么关系这个问题是热词榜里被问得最多的。很多人把Skill、Prompt、Agent混在一起说实际上它们是三个完全不同的层次我打个比方你就明白了。Prompt是你对临时工说的一句今天把厨房打扫干净。Skill是你递给临时工的一本《厨房清洁标准作业手册》里面写了先清理台面还是先擦油烟机、用什么清洁剂、多久换一次水、最后怎么验收。它描述的是一件事该怎么做而不是你自己看着办。Agent则是那个拿着手册、有自主决策权限的全职保姆你只需要告诉她今天有人来家里做客自己安排打扫和做饭她会自己决定几点开始、先做哪一步、中间发现问题怎么调整。所以在实际项目里的关系是Agent负责统筹和决策Skill负责提供作业标准和方法论Prompt负责临时传达需求。三者不是竞争关系而是协作关系。Claude Code里Agent会主动读取它认为相关的Skill清单Cursor里可以通过Rules或特定目录加载SkillCodex也有自己的skills目录机制——但底层都一样给AI一个遇到这类问题就按这套标准来的操作包。这里面有一个特别重要的细节Skill的description写得好不好直接决定AI会不会调用它。如果description写得模糊比如关于代码质量AI在真实任务里根本不会联想到它。正确写法应该包含三要素触发场景、具体任务类型、关键词。就像接口文档里的接口触发条件一样AI会先做一次语义匹配匹配上了才加载执行。这个细节后面我会在实操环节展开讲。4. 1500个现成Skill什么人该存什么人该删4.1 这份资源到底从哪来1500个现成Skill这个数字并不是某个厂商官方发布的数字而是目前社区主流Skill仓库粗略汇总的结果。大致分布是这样的Claude官方推出的Agent Skills体系提供了从首版开始就内置的官方Skill集合会有官方文档和示例GitHub上各类Awesome Skill清单类仓库比如awesome-claude-skills这类聚合项目收集了社区贡献的数百个Skill各类Skill Marketplace或者第三方站点专门做Skill的上架和分发方便按领域筛选许多开发者在博客里分享的我自己的Skill合集这类质量参差不齐但往往最有针对性根据我个人的翻库体验这1500个里面真正素质过硬的我认为大概在三成左右。另外七成要么是同一个Skill换个名字重复上传要么就是差不多先生——什么都会一点但什么场景都说不透属于典型的凑数内容。4.2 需求分流这五类人适合直接灌库虽然我建议你保持克制但对于下面这五类人直接装一大批现成Skill是正确的选择不用太纠结第一类刚入门AI编程的新手。你本身连结构化的思维方式都还没建立看一份写得好的Skill等于看一个老师傅写的作业模板远比看书学得实在。这类人我建议直接装尤其是前端、后端、测试、重构这四种基础类型的Skill各挑一个好好研究比装一百个都值。第二类跨领域临时接活的人。比如你是个后端工程师突然要写一个Vue3前端页面这时候一个vue-best-practices Skill比你自己啃文档快得多。热词榜里vue-best-practices skill怎么下载运用能冲上热搜说明有大量后端同行正在这么干。第三类做数学建模、PPT、论文写作这类非典型编程任务的人。热词榜里的数学建模SkillPPT Skill本质上就是把某类任务的方法论打包给了AI。AI本来就会写作、会计算但按照数学建模竞赛的要求去搭论文结构、做灵敏度分析、画图表需要专门的经验指导这不属于会计算的范畴属于知道竞赛评委想看到什么的范畴。第四类搞硬件和工业方向的人。热词里AI Agent与PLC编程AI编程FPGAAI PLC编程排得很靠前说明了这个方向的热度。这类领域的特点是文档重、规范多、易错点隐蔽有现成的Skill相当于请了个懂行的顾问。第五类内容创作者和知识工作者。看热词里的倪海厦Skill仓颉Skill这类垂直内容型Skill你就会发现Skill的应用范围早就超出了写代码。它可以是用AI解读传统医学知识的方式也可以是用AI帮你写仓颉Cangjie语言项目的方式。本质上都是在给AI补行业经验。4.3 筛选判断的三个硬标准不管你是从哪个渠道拿到的Skill我建议用这三个标准快速过一遍不合格的直接删别心疼看description是不是会说人话。一份好Skilldescription会清楚写出在什么场景下、解决什么问题、包含哪些关键步骤。如果description写得模棱两可比如优化开发体验那这份Skill大概率是个空壳AI也根本不会在正确的时候调用它。看正文有没有完成标准或验收清单。Skill和普通文档最大的区别就是它必须定义做成什么样才算完。没有验收标准的Skill只是把一堆规范抄了一遍AI执行起来没有闭环。看示例是不是完整可跑的。好Skill不会只给一段伪代码而是会给一个完整的输入输出示例甚至附带场景说明。如果一个Skill正文连一个示例都没有那它对AI的指导价值非常有限。我自己这么多库翻下来一个很深的感触是Skill这个生态正在从拼数量走向拼质量。刚开始大家都疯狂上传你传一个我也传一个看着数量过千其实大量雷同现在逐渐分化出精品维护型和一次性搬运型两条路径。你作为使用者真正需要的是少数几个精品而不是全部。5. 一次完整的上手实操从选Skill到调通Skill5.1 装Skill之前先确认你用的工具支持哪种目录规范不同AI编程工具对Skill的目录约定不完全一样我实际测下来主流的加载方式大致如下工具目录/加载方式备注Claude Code~/.claude/skills/skill-name/SKILL.md或项目.claude/skills/官方支持Agent会自动读取相关SkillCursor通过.cursor/rules文件或手动在项目里放置.prompts需要配合Rules机制使用很多第三方Skill会以.prompts形式分发Codex~/.codex/skills/skill-name/SKILL.md新版Codex已支持skills目录部分旧版本需要配置文件指定OpenCode安装后通过配置skill资源目录加载社区工具按各自README配置通用方式在项目根目录建.skills/很多开源工具默认会扫描该目录如果你用的工具没在上面也别慌。通用的做法是先找项目的配置目录一般是.claude、.codex、.cursor、.opencode这类隐藏文件夹看里面有没有skills子目录没有就自己建一个。然后下载Skill的时候看清楚它的安装说明是放在用户全局目录还是项目目录。这里有个非常关键的取舍全局目录的Skill会在所有项目里生效项目目录的Skill只对当前仓库生效。我个人建议通用型的比如代码规范、测试体系放全局领域型的比如某特定框架的架构规范放项目里。别把所有东西都堆全局否则跨项目时会互相干扰。5.2 实操案例给Claude Code装一个数学建模Skill我拿最近很多人问的数学建模Skill作为完整例子一步步走一遍。第一步找个靠谱来源的数学建模Skill。GitHub上搜索时过滤条件建议用stars:50 skill mathematics model少走很多弯路。第二步看它包含哪些文件。好的数学建模Skill一般不止一个SKILL.md还会带上论文模板目录、算法代码示例、绘图脚本示例。这说明作者是真心想把一次完整竞赛经验打包给你不是只写几句空话。第三步放进目录。假设我用的是Claude Code命令很简单# 在用户级目录建好技能文件夹 mkdir -p ~/.claude/skills/math-modeling # 把下载的Skill内容复制进去 cp -r ~/Downloads/math-modeling-skill/* ~/.claude/skills/math-modeling/第四步验证能不能被识别。打开Claude Code输入一句明显跟数学建模相关的指令比如我需要写一篇数学建模论文的摘要问题是某城市交通流量预测试分析建模思路观察AI的输出。如果它主动提到了模型选择、灵敏度分析、论文结构说明Skill已经被加载了。第五步调优。如果AI没反应大概率是description跟你的触发语句匹配度不够。打开SKILL.md改description里的关键词把这个场景下的常见说法全补上比如数学建模数模竞赛MCM/ICM建模论文预测模型然后重试。5.3 实操案例用Book to Skill方式把一本书变成AI的操作手册热词榜里Book to Skill排名不低这个玩法今年非常火我自己试过几次效果出奇地好。它的思路特别简单与其等别人做好Skill不如把你手上那本行业内公认的好书转化成一份AI能用的技能包。具体分四步把书的目录结构拆出来梳理出核心模块。比如你把一本《代码整洁之道》拆成命名、函数、注释、错误处理、单元测试五个模块。对每个模块提炼出可执行的规则而不是正确的道理。比如命名要清晰是道理不是规则函数名里禁止出现无意义的data、info这类词才是规则。把规则组织成SKILL.md按执行流程—具体规则—验收标准三层结构写。让AI自己测试一遍。给它一个小任务看它是否按Skill里的规则执行哪些规则它忽略了回头想想是描述不够具体还是规则本身太模糊修改后再测。我拿《代码整洁之道》做完之后明显感觉到AI写出来的代码风格确实变了——函数短了、命名具体了、注释少了但更有信息量了。这就是Skill的神奇之处它在改变AI的默认行为。6. 自己动手写Skill一份能真正被AI执行的文件该怎么写6.1 我踩过的第一个坑把Skill写成了知识说明文档我第一次写Skill的动机很简单想让我常用的AI助手在帮我做前端重构时不要再写出祖传意大利面条代码。我当时写了一大篇什么是好的前端架构组件设计原则设计模式介绍——写得非常详尽满篇都是正确无比的大道理。结果测下来AI确实认真读了但输出几乎没变化。因为它根本没有获得任何它原本不知道的东西。它本来就知道组件要拆分、函数要短小它真正缺的是在接到一个具体任务时应该先做什么、后做什么、每一步做到什么程度才算完。简单说Skill要输出的是Where和When的决策逻辑以及How的具体标准而不是What的抽象原则。后来我把那份文档彻底推翻改成下面这种结构效果立刻不一样--- name: vue-component-refactoring description: 用于Vue3组件重构与代码拆分。当用户要求重构一个过长组件、拆分复杂页面逻辑或优化组件性能时使用。触发关键词重构vue组件、拆分代码、组件优化、code splitting。 --- # Vue3组件重构操作手册 ## 1. 前期诊断清单 - 组件文件是否超过300行 - 是否存在超过10个的单项state集中在一个setup中 - 是否有组件同时负责数据请求、UI渲染和状态管理 - 列出所有需要拆分的点并说明拆分原因 ## 2. 拆分策略按优先级顺序 - 优先拆出独立业务逻辑Hook命名格式use业务名 - 再拆UI子组件每个子组件只负责一块UI区域 - 最后抽公共类型定义到src/types目录 ## 3. 重构后的验收标准 - 最大组件文件行数不超过250行 - 所有子组件能独立渲染不依赖父组件的内部方法 - 原组件测试用例全部通过 - 附上重构前后代码对比说明你可以明显感觉到区别它给AI的是遇到一个任务怎么一步步拆解而不是什么是好代码这种形而上的道理。6.2 结构模板一个稳妥的SKILL.md骨架结合我写过十几个Skill和帮别人改过的经验下面这个骨架是当前社区认可度最高、执行稳定性最好的模板你照着填就行--- name: skill-标识名短横线连接 description: 何时使用该Skill解决什么问题包含哪些关键能力以及触发关键词。 --- # 技能名称 ## 2. 任务拆解 - 第一步做什么、第二步做什么、每一步的完成标准 ## 2.1 输入要求 - 需要用户提供哪些信息、哪些是必填、哪些可选 ## 3. 执行规范 - 具体做法和标准尽量给边界条件和反例不要只给抽象原则 ## 4. 检查清单 - 任务结束时逐项检查的验收标准AI会按此判断是否完成 ## 5. 示例 - 至少一个完整示例从输入到输出全过程注意一点我给A类描述写的YAML里name和description不是随意写的它们直接决定了AI在什么情况下会主动加载这个Skill。你可以在description里放心使用当用户...时候使用这类句式AI对这是有较强的语义匹配能力的。6.3 四种我自己验证有效的写作技巧技巧一给规则配反例。与其写代码要有良好的错误处理不如写如果用户传入的ID不存在不要返回500应该返回404并附带友好提示反例直接抛异常让调用方看到堆栈。AI对大模型来讲正例加反例的组合比只有正例的语义约束力强一倍。技巧二每个环节给出口条件。我写Skill的习惯是每个小节最后都写一句完成本节后检查xxx确认无误再进入下一节。这能有效避免AI跳过中间步骤直接跳到结尾是实测下来最管用的防止AI偷工减料的手段。技巧三明确不要做什么。AI的执行逻辑往往是只要没被禁止就默认可以做。所以把最容易犯的错直接单列一节禁止事项效果奇佳。比如禁止把数据库查询放到for循环里禁止在不做字段级权限校验的情况下返回全量用户信息。这些明确的禁止能堵住它发挥过头造成的麻烦。技巧四让它先输出计划再执行。在SKILL.md开头加一句开始任务时先输出你的执行计划然后按计划逐步执行。这个动作会强迫AI在全神贯注前先做一次全局规划出来的结果质量明显更稳。对AI编程来说这个动作带来的收益是最被低估的。7. 用Skill用得越久越要注意这五个隐蔽的坑7.1 坑一Skill装多了AI不是变聪明了是变分裂了这是我在一个项目里真实踩过的。那时候我装了大概十几个Skill什么领域都有。结果有一次让它写一个简单的工具函数它居然自动触发了两三个Skill的逻辑一会儿按企业级后端规范来一会儿按性能极致优化来最后产出一段要求过度设计的代码。AI不是CPU不会并行的去执行所有Skill它只能按上下文相关性做取舍但Skill之间如果场景边界不清晰它就会反复横跳。我的建议是全局Skill保持五六个以内且领域不要重叠。更多的按项目去装项目结束就撤。7.2 坑二上下文膨胀是隐形的性能杀手每个Skill被触发时其全文都会进入AI的上下文窗口。如果你装了很多大而全的Skill每个三四千行AI光读取它们就要占掉巨额上下文留给实际代码分析的token就少了表现自然会变差。解决思路是两个第一Skil的内容保持短小精准重质不重量宁可30行讲透一个点不要300行講十个点第二给不同项目配不同的Skill组合不要一个全局配置文件全带上。7.3 坑三Skill描述和实际内容不符有些第三方Skill的description写得很诱人什么AI自动化架构师一站式全栈工程师结果下载下来正文就两三行。这就会让AI的判断失准——它看到description觉得该用这个真加载了又拿不到任何有用的指导白白浪费一次上下文和一轮执行。遇到这种删掉就好别试图修补补出来的也是缝合怪。7.4 坑四直接用普通提示词文件冒充Skill这也是热词问题榜里的常客。很多人下载的所谓Skill其实就是别人写好的提示词改名成SKILL.md扔到目录里。它缺了关键的YAML头信息、缺了结构化的执行步骤、缺了验收标准AI根本不会把它当成Skill来主动调用只会当成一堆普通文本参考。我教你一个快速识别的办法把文件拖进编辑器看它开头有没有用---包裹的YAML块name和description。没有的本质就不是Skill是一个提示词文档。不是不能用但你别指望它能被自动触发。7.5 坑五跨工具迁移Skill时的目录陷阱Skill跨工具复用理论上只需把SKILL.md文件复制过去但实际没那么简单。不同工具读取Skill的目录不同、触发优先级不同、对YAML字段的要求也不同。我曾经把Claude Code的Skill直接复制到Codex里结果废了半小时才排查到是Codex要求description里必须包含特定的trigger字段。最稳妥的办法是跨工具迁移时先在该工具的官方文档里查清楚目录规范和YAML字段要求再动手。热词里deepseek harness安装Skillcodex安装Skillopencode Skill安装使用搜索量那么高就是大家在这个环节卡住的直接证据。8. Skill的边界与延伸它不是万能药但确实改变了玩法Skill现在最大的一个争议点是AI编程缺经验靠堆Skill真的够吗 我的回答是够但不是靠堆。靠的是把经验结构化这件事本身的价值。你想传统软件开发里团队经验是怎么传承的靠文档、靠Code Review、靠老带新。现在Skill相当于把这三件事同时压缩进了一个可以被AI直接加载的文件里文档是SKILL.md本身Code Review是验收清单老带新是AI在读Skill时就像刚入职的同事在看团队手册。这个变化本质上改变了经验的流转方式。所以相比一味追求1500个我更建议你花一晚上时间把手头经常做的三类任务各写一个自己的SKILL.md哪怕每个只有三五十行。这个动作带来的收益比你下载一百个别人的Skill都大。因为写的过程本身就是你把自己脑子里的隐性经验显性化的过程一份能明确告诉你该怎么做、怎么算完成的Skill远胜于一百份正确无比的空道理。而且这个生态还在飞快变化。从热词里你可以看到Skill和Agent的区别Skill开发指南Claude如何写一个完善的SkillAI Agent与PLC编程仓颉Skill——这些话题的密集出现说明已经有人把Skill当成一门正式的技能工程在做研究的粒度早就超过写个提示词了。我个人的体会是Skill这个东西用一天是技巧用一年是方法论。你先别想着把所有Skill都收藏起来先选一个你最常做、最容易翻车的任务找一份用心的现成Skill装上或者自己写一份然后用两周时间反复调、反复改——等你跑通了这个循环再回头看那些1500个Skill的列表你会自然地知道该要什么、该扔什么。
