1. “skills”是什么AI编程助手的一次“外挂化”演进先说一个我自己的观察过去一年多我折腾过的AI编程工作流里最容易被低估、后劲又最大的东西不是某个模型的推理能力而是那一层层可以复用、可以组合、可以分享的“技能包”——也就是大家现在习惯叫的skills。搜索热词里排着“前端开发skills”“数学建模skills”“AI漫剧常用skills”说明它早就不是某个大厂文档里的冷门术语而是很多人正在寻找的“生产力外挂”。1.1 从对话补全到可复用技能包你可以把普通对话式的AI编程想象成“临时请了个很聪明但不熟悉公司规矩的实习生”。你每次都要重新解释一遍项目结构是什么、代码规范怎么定、测试应该怎么跑、交付文档长什么样。而skills做的事情就是把这一大坨“解释”提前打包好让AI在遇到对应场景时自动拿出那套流程来执行。它和提示词工程有个本质区别提示词是“一次性说的话”skills是“一个可以在不同会话里反复加载的岗位说明书”。同一个技能你可以今天在A项目上用明天在B项目上用甚至可以分享给团队其他人。技能里除了指令文本还能附带示例文件、脚本、模板、参考文档甚至参数配置。模型在需要的时候不只是“知道”有这么个流程而是能真正调用配套的资源去完成一件完整的事。1.2 一个最简skills包的内部结构以目前最主流的做法为例一个技能通常就是一个独立目录里面放一个核心说明文件常见命名是SKILL.md必要时候再带上辅助脚本、模板和examples。这个SKILL.md的开头会有一小段“元信息”用来告诉AI这个技能叫什么名字、什么时候该用它、它的描述是什么正文里则是详细的执行步骤、输出规范、注意事项。我把这个结构和“菜谱”类比过很多次。SKILL.md 就像菜谱正文告诉你食材和步骤元信息段的 description 相当于菜谱封面上的“适合什么场合、口味偏向”AI要根据这行字决定要不要翻开这本菜谱。如果封面信息写得太模棱两可AI要么不翻要么乱翻这是新手写技能最容易踩的坑。1.3 为什么围绕skills的讨论这么多从搜索热度也能看出大家关心的问题很集中怎么下载、怎么手动装GitHub上的、怎么自己开发、哪些数学建模比赛里好用、装多了怎么清理。这背后其实是同一个诉求——大家想把手头常用的工作方法沉淀下来而不是每次开会话都从零开始。很多人把skills和模型能力混为一谈总以为它是某个模型的隐藏功能这其实是个误解。skills是“模型之外的工程层”它依附在CLI工具上和具体用什么基座模型没有强绑定关系。理解了这一点后面的安装、开发、踩坑就都顺了。2. 常见的skills源社区和选型思路搜哪里、收藏什么、怎么判断质量有人问我“skills去哪里找”我的回答是先找对源头再学会挑货。这跟逛开源软件社区一个道理仓库多得是但优质技能和凑数技能之间的差距比想象中还要大。2.1 技能源网站和GitHub仓库怎么找目前主流的获取渠道主要有三类第一类是GitHub上的项目仓库这也是最核心的渠道。直接在GitHub搜索框里输入“claude skills”、“codex skills”、“opencode skills”或者搜“awesome x skills”这类榜单就能发现大量集合包。比如“superpower skills”这类社区项目就是一批结构化技能的合集特点是分工明确、互相能协作。第二类是技能库站点有人把很多技能整理成网页支持在线浏览和下载这就是大家说的“skills技能库网址”和“skills网页版”入口。我的建议是网页版适合快速浏览和筛选真正干活还是要回到本地目录别指望在网页里直接“运行”一个技能。第三类是垂直领域的专项仓库。比如某些团队会开源自己做数据分析、前端审查、数学建模用的技巧集。这些仓库通常质量高因为它们是在真实项目里磨出来的。搜索时不要只搜“skills”这个大词带上场景去搜比如“frontend code review skills”、“math modeling skills”命中率会高很多。2.2 给前端开发、数学建模、AI漫剧挑技能的思路挑技能不能只看热度要看你自己的使用场景。结合最近的搜索热词我拎三个典型的场景说说选型思路。前端开发优先找那种“带明确执行链路”的技能比如组件生成、代码审查、规范检查、状态管理重构。判断标准是看它有没有在SKILL.md里写出“先读什么文件、再改哪些类型、最后跑什么命令”只有这种流程化的东西才能在真实项目里落地。如果一个前端技能只是一堆空泛的“请写出优雅的组件代码”那基本没什么用。数学建模这是我看到讨论特别密集的领域尤其是“华为杯数学建模比赛好用的codex skills”这类问题。建模场景的特点是时间紧、任务链长、输出要求固定。推荐选那些覆盖“问题分析→模型选择→算法实现→结果可视化→论文排版”整条链路的技能包而不是只解决“画图”或者“求最优解”的零散技能。很多建模技能会内置常见算法模板比如线性规划、遗传算法、神经网络这些代码骨架直接适配代码运行环境这种是实战里最香的。AI漫剧这个方向挺特别它的核心痛点不是编程而是一致性和量产效率。漫剧项目往往需要批量生成分镜脚本、统一角色特征、保持画风稳定。我建议重点找角色一致性管理、分镜规划、提示词批次生成这类的技能。好的漫剧技能一般会规定一个固定的输出模板把“角色外貌描述”“场景描述”“镜头语言”拆成字段这样后面所有生成任务都能用同一个标准去对齐。2.3 判断一个skills是否值得装的“三看”清单我把选型经验浓缩成一个三看清单照着检查能避开大部分坑看结构完整性打开仓库检查技能目录里是否有SKILL.md且位于根目录是否自带readme、示例或测试样本。只有SKILL.md而没有配套文件的技能往往说明作者没经过真实场景打磨。看描述精确度读description那几行字看看它是否明确说明“适用场景、触发条件、输出物”说清楚这些的技能模型才能准确调用。描述写得像废话的基本可以关掉了。看维护活跃度看最后更新时间、issue和PR情况。一个长期无人维护、问题无人回应的技能遇到版本更新时大概率会失效别指望它能在关键时刻救场。提示装技能克制一点。书架塞满没读过的书不是阅读能力强是焦虑。技能装得太多不仅管理混乱还会挤占上下文窗口反而降低模型表现。后面第5章我会专门讲清理方法。3. 手动安装一个GitHub上的skills从clone到验证的完整流程关于“claude code怎么手动装github上的skills”我估计是被问得最多的一个问题。其实剥开外壳底层就三步把仓库拉下来、把技能塞到约定目录里、重启会话触发加载。这里我用Claude Code、Codex、OpenCode这些常见CLI工具为例讲一遍带着验证环节的完整流程。3.1 先确认你的CLI工具支持什么目录安装之前先搞清楚一件事不同工具约定存放技能的路径不一样而且随着版本迭代还可能变化。以我目前接触到的常见约定来举例Claude Code通常认两个位置用户级目录比如~/.claude/skills和项目级目录比如.claude/skillsCodex类的工具大致对应~/.codex/skills或项目.codex/skillsOpenCode一般用.opencode/skills。项目级目录的好处是跟着仓库走团队成员clone下来就能共享用户级目录则是全局生效偏向个人习惯类技能。我把常用的路径整理成一张表你安装前先对照自己的工具和版本确认一下以官方文档为准工具用户级目录示例项目级目录示例Claude Code~/.claude/skills/.claude/skills/Codex~/.codex/skills/.codex/skills/OpenCode~/.opencode/skills/.opencode/skills/3.2 clone、放置、改名的完整步骤假设你在GitHub上看到一个名为awesome-project-skills的仓库想单独把其中frontend-review这个技能装进Claude Code实际操作大概长这样# 1. 克隆仓库到临时目录先别直接clone到技能目录避免把整个仓库塞进去 git clone https://github.com/example/awesome-project-skills.git /tmp/awesome-skills # 2. 查看仓库里技能的组织形式可能是 skills/frontend-review/ cd /tmp/awesome-skills ls -la skills/ # 3. 把目标技能目录复制到 Claude Code 的用户级技能目录 mkdir -p ~/.claude/skills cp -r skills/frontend-review ~/.claude/skills/ # 4. 检查目标目录里是否真的有 SKILL.md ls -la ~/.claude/skills/frontend-review/这里有一个我自己刚开始时踩过的坑很多集合仓库不会把技能直接放在仓库根目录而是放在skills/或src/skills/这种二级目录下。如果你图省事把整个克隆出来的仓库一股脑扔进技能目录只会得到一堆根本不会被识别的东西。一定要先ls看结构定位到真正包含SKILL.md的那一层。还有个细节是改名。技能目录名不一定等于SKILL.md里的name字段但多数工具会以目录名或name字段来做查询键。发现重名时我建议以sk额里定义的name为准目录名尽量保持一致否则可能出现“能看到目录却加载不了”的怪问题。3.3 验证技能是否被加载的检查清单装完之后不要急着干别的先做一轮验证。不同工具的入口不一样但思路共通。以Claude Code为例我会做这么几步在项目目录下重新启动会话确保它重新扫描了技能目录。输入斜杠命令比如/skills看有没有列出刚安装的技能以及它的描述是否正确。直接问模型一句“你现在加载了哪些技能各自负责什么场景”看它能不能准确说出来。检查技能目录权限有些技能会带可执行脚本目录权限不对的话即使能被扫描到调用时也会报错。如果在/skills里看不到目标技能先回头检查SKILL.md是否真的存在于该目录的根层级这是最常见的失败原因。其次看YAML格式有没有解析问题比如漏了闭合的---或者description里混入了不支持的字符。3.4 安装之后必须要做的“冒烟测试”验证技能“能被看到”只完成了一半更关键的是验证“能干活”。我会立刻用一个小而真实的输入做一次冒烟测试。比如装了前端代码审查技能就丢一段有明显问题的代码给它命令要求“按frontend-review的流程执行”装了数学建模技能就给一个简化的线性规划例子让它按照技能里定义的步骤输出。冒烟测试要选“最简单但能跑通全链路”的任务因为如果连最小任务都执行不下去说明技能内部指令和实际环境不匹配需要马上排查而不是等到正式项目里才暴露。提示从GitHub装回来的第三方技能建议养成先读一遍SKILL.md的习惯。它可能涉及脚本执行或文件读写不看过一遍内容就盲装相当于把不明来历的代码交给你的AI助手执行。我把这当作基本的安全底线。这类问题在“skills下载”场景里最容易被忽视很多人急着安装连仓库描述都没读。4. 自己动手写一个skillsSKILL.md的正确打开方式如果说装别人的技能是“开箱即用”那自己写技能就是从被动消费到主动生产的质变。网上搜“ai skills怎么写”能翻出各种模板但很多人还是写不好原因无非是没理解技能文件的本质它不是给模型看的作文而是给模型用的操作手册。4.1 写作模板和字段说明一个典型SKILL.md的开头会长这样--- name: log-analysis description: 分析博客或服务端日志文件提取错误分布、热门请求路径和异常趋势。适合nginx日志、应用系统日志的快速排查场景。 --- # 日志分析 ## 适用时机 - 当用户提供日志文件路径或文本内容时 - 当用户要求定位错误原因、统计请求分布时 ## 执行步骤 1. 先确认日志格式读取前20行识别字段。 2. 统计Error、Warn、Info级别出现的次数和占比。 3. 按请求路径聚合找出响应异常的Top 10。 4. 输出结构化报告包含错误摘要、Top请求、可疑根因。 ## 输出格式 - 报告必须包含三个小节概览、异常清单、修复建议。 - 修复建议不要超过5条按优先级排序。 ## 注意事项 - 如果日志文件超过1万行先做抽样分析不要尝试全部加载进上下文。 - 不要臆造日志里不存在的字段。这里面最容易被忽视也最重要的字段是description。我反复强调模型判断“什么时候该用这个技能”靠的就是这行描述。它越具体匹配越准。不要说“分析日志”这种大路货要说“分析nginx日志提取错误分布和Top请求路径”这样模型在遇到相关问题时才会精准触发。description里顺带写一下“不适合什么场景”能有效减少误触发。4.2 从零写一个“日志分析”技能的过程上面这个log-analysis其实就是一个能直接跑起来的最简版本我拆解一下它的写作过程。先把目标限定清楚我手上服务出问题了我需要AI帮我快速定位异常而不是做一份精美报表。所以执行步骤的核心就是“识别格式→统计级别→聚合路径→给结论”。这个技能我最初写的时候只有两行——“帮我看看日志有什么问题”结果模型每次给的答案都太散有时贴一堆原文有时跳过统计。后来改成强制输出“概览、异常清单、修复建议”三个小节输出质量立刻稳定了。4.3 指令粒度写细则还是留白给模型这是写技能最需要拿捏的分寸。我的经验是流程和格式要写细具体实现要留白。比如“先统计Error级别出现次数”是流程必须写清楚“用什么函数去统计”是实现细节不用写模型自己会选。如果不留白指令过多会占用上下文反而压缩了模型发挥的余地。有个简单判断标准如果一条指令离了具体项目环境就无法成立那多半属于实现细节把它从技能里删掉。4.4 迭代测试把技能当代码一样维护写完技能不迭代就跟提交代码不测试一样危险。我建议在开发阶段就给技能配一组测试输入比如日志分析技能就准备一份几百行的样例日志每次修改SKILL.md之后跑一遍看输出是否符合预期。修改技能时要注意版本习惯我会在技能目录里留一个CHANGELOG片段记录每次改了什么不然过两个月再看完全忘了当初为什么把这个步骤删掉。另一个贴近实战的心得是别把技能写得像教科书。技能是给高强度工作中用的设计目标永远是让AI更稳定地产出可用结果。凡是不能让你在重复劳动里省时间的修饰都可以砍掉。5. 规模化使用的高频问题上下文被撑爆、技能互相打架、清理方法技能用多了之后你会进入一个新阶段不是“找不到技能用”而是“技能太多不知道怎么管”。搜索热词里专门有“tibo关于清理skills的方法推荐”“常用skills”“skills下载”这些说明大家普遍面对同一个困境——装了删、删了装最后目录乱成一锅粥。这一节我集中讲问题和出路。5.1 为什么装多了反而变蠢先说一个反直觉的现象技能装到一定数量后AI的表现可能不升反降。原因在上下文策略上。不同工具对技能的处理方式不太一样有的是把所有技能的元信息都放进上下文有的按需加载但共同点是技能描述和指令终究会占用一定的上下文空间。当几百个技能的描述一起堆在上下文里模型要做两件事——理解你的实时提问、同时从几百个候选里挑技能两者互相挤占表现自然下滑。所以我的第一原则是按项目装技能而不是按人生装技能。项目A只需要前端审查和数据模拟那就只装相关的几个和这个项目无关的全局技能宁可放在备用目录里也不要全部铺开。如果你的CLI工具支持“项目级技能目录”尽量多用项目级隔离而不是把所有东西都塞进用户级目录。5.2 排查“技能去哪儿了”的调试路径遇到“明明装了技能但它不干活”的情况我有一套固定的排查路径先重启会话确认不是缓存问题。用工具的技能列表命令比如/skills类入口确认技能是否在列表中。检查触发语句是否命中技能的description场景有时技能加载了但你的提问用词和描述不匹配模型没意识到该用它。这种情况我会直接说“请使用log-analysis技能处理这份日志”手动点名。再检查技能正文里是否有冲突指令比如某个步骤明确说“不要分析Error日志”那它在特定场景下自然表现得不听话。最后看输出是否被人为截断技能正文太长会导致它只按前半段执行典型表现是做到一半就停了。这个过程做多了之后你会形成直觉大部分技能“不生效”不是因为工具坏了而是门槛没匹配上——要么描述不准确要么正文有冲突要么项目环境不对。5.3 清理技能的具体操作和整理习惯关于清理我把我平时用的“三步整理法”分享出来和社区里一些博主总结的思路大致相通也算是我消化后的版本第一步归档而不是删除。建一个~/.claude/skills-archive类似的目录把暂时不用的技能移过去。这样既不敢误删又不会让它们在当前会话里生效。第二步定期清点。每个月花十分钟看一遍技能列表问自己三个问题这个技能近两周用过吗它解决的问题现在还存在吗有没有另一个技能可以覆盖它只要有一个回答不好就把技能扔进归档目录。第三步给技能写一句话备注。直接在技能目录下放一个README片段或者用description字段记上“什么时候装的、当时为了解决什么问题”下次清点时一眼就能想起来。别信自己脑子目录会超过记忆容量。还有一个经常被忽视的清理维度指令碎片化。很多人遇到小问题不写技能而是每次在对话里补一句“记住以后都这样做”。这些话散落在历史会话里工具不会自动把它们聚合进技能里结果就是你反复解释、模型反复遗忘。清理技能的深层含义其实是把零散的“口头约束”升级成结构化的技能文件这样每次会话都能稳定继承。6. 把skills当成一种“工作方法”而非“工具包”写到这里我最想表达的观点是skills表面上是一堆目录和Markdown文件实质上是一种工作方法。它的价值不在于“给你一个更听话的AI”而在于“逼你把做事的流程想清楚”。6.1 技能与项目配置的配合真正成熟的用法是把技能项目和项目配置文件绑在一起。我在团队里推荐的做法是每个项目仓库自带一份技能目录里面放的是这个项目专属的代码规范、发布流程、测试习惯。新成员clone仓库之后不需要看几十页wikiAI就能按这套技能库工作。这种“技能随项目走”的方式比任何培训文档都更直接。技能和项目配置结合得越紧AI产出的结果越像“自己人写的”。6.2 从“抄技能”到“造技能”的转变大多数人接触skills都是从抄开始——抄别人的仓库装别人的技能包。这没问题但真正的分水岭是你开始造属于自己的技能。我建议的路径是先挑一个你天天做、做到想吐的任务把流程写成技能。比如我最早自建的技能就是“日志分析”后来是“生成周报”再后来是“接口字段映射”。每一个都是从实际工作里长出来的效果远比下载的通用技能好。造技能的过程本质上是把你个人的隐性经验变成显性知识这种知识跟着你走换任何工具都能迁移。6.3 给零基础读者的一条最小起步路径如果你现在完全没有接触过skills我建议你按这个顺序来只安装一个和你当前工作最相关的技能跑通一次完整调用感受技能和普通对话的差异。用/skills类命令或工具日志观察技能是什么时候被加载、什么时候被忽略的建立“触发条件”的直觉。把技能目录拆开看读一遍SKILL.md的每一行对照自己的使用体验理解description和正文的作用。复制一个已有的技能改掉其中一半内容替换成自己的工作流程跑一轮冒烟测试。当你改了第三个技能后你已经具备独立写技能的能力了。坦白说这个领域更新很快今天记下的安装路径和命令格式过两三个月可能就变了。真正值得沉淀的是那套思考和排查的方法以及“把重复工作变成可复用资产”的意识。我现在的习惯是每做完一个有点复用价值的任务就顺手评估一下“要不要把这个流程沉淀成一个技能”。哪怕只是一个很小的技能聚少成多之后你会发现自己做项目的方式变了——不是从零开始而是从一套自己长期打磨的工具箱出发。这才是skills真正让我着迷的地方。
AI编程助手skills指南：从下载安装到自建技能包
1. “skills”是什么AI编程助手的一次“外挂化”演进先说一个我自己的观察过去一年多我折腾过的AI编程工作流里最容易被低估、后劲又最大的东西不是某个模型的推理能力而是那一层层可以复用、可以组合、可以分享的“技能包”——也就是大家现在习惯叫的skills。搜索热词里排着“前端开发skills”“数学建模skills”“AI漫剧常用skills”说明它早就不是某个大厂文档里的冷门术语而是很多人正在寻找的“生产力外挂”。1.1 从对话补全到可复用技能包你可以把普通对话式的AI编程想象成“临时请了个很聪明但不熟悉公司规矩的实习生”。你每次都要重新解释一遍项目结构是什么、代码规范怎么定、测试应该怎么跑、交付文档长什么样。而skills做的事情就是把这一大坨“解释”提前打包好让AI在遇到对应场景时自动拿出那套流程来执行。它和提示词工程有个本质区别提示词是“一次性说的话”skills是“一个可以在不同会话里反复加载的岗位说明书”。同一个技能你可以今天在A项目上用明天在B项目上用甚至可以分享给团队其他人。技能里除了指令文本还能附带示例文件、脚本、模板、参考文档甚至参数配置。模型在需要的时候不只是“知道”有这么个流程而是能真正调用配套的资源去完成一件完整的事。1.2 一个最简skills包的内部结构以目前最主流的做法为例一个技能通常就是一个独立目录里面放一个核心说明文件常见命名是SKILL.md必要时候再带上辅助脚本、模板和examples。这个SKILL.md的开头会有一小段“元信息”用来告诉AI这个技能叫什么名字、什么时候该用它、它的描述是什么正文里则是详细的执行步骤、输出规范、注意事项。我把这个结构和“菜谱”类比过很多次。SKILL.md 就像菜谱正文告诉你食材和步骤元信息段的 description 相当于菜谱封面上的“适合什么场合、口味偏向”AI要根据这行字决定要不要翻开这本菜谱。如果封面信息写得太模棱两可AI要么不翻要么乱翻这是新手写技能最容易踩的坑。1.3 为什么围绕skills的讨论这么多从搜索热度也能看出大家关心的问题很集中怎么下载、怎么手动装GitHub上的、怎么自己开发、哪些数学建模比赛里好用、装多了怎么清理。这背后其实是同一个诉求——大家想把手头常用的工作方法沉淀下来而不是每次开会话都从零开始。很多人把skills和模型能力混为一谈总以为它是某个模型的隐藏功能这其实是个误解。skills是“模型之外的工程层”它依附在CLI工具上和具体用什么基座模型没有强绑定关系。理解了这一点后面的安装、开发、踩坑就都顺了。2. 常见的skills源社区和选型思路搜哪里、收藏什么、怎么判断质量有人问我“skills去哪里找”我的回答是先找对源头再学会挑货。这跟逛开源软件社区一个道理仓库多得是但优质技能和凑数技能之间的差距比想象中还要大。2.1 技能源网站和GitHub仓库怎么找目前主流的获取渠道主要有三类第一类是GitHub上的项目仓库这也是最核心的渠道。直接在GitHub搜索框里输入“claude skills”、“codex skills”、“opencode skills”或者搜“awesome x skills”这类榜单就能发现大量集合包。比如“superpower skills”这类社区项目就是一批结构化技能的合集特点是分工明确、互相能协作。第二类是技能库站点有人把很多技能整理成网页支持在线浏览和下载这就是大家说的“skills技能库网址”和“skills网页版”入口。我的建议是网页版适合快速浏览和筛选真正干活还是要回到本地目录别指望在网页里直接“运行”一个技能。第三类是垂直领域的专项仓库。比如某些团队会开源自己做数据分析、前端审查、数学建模用的技巧集。这些仓库通常质量高因为它们是在真实项目里磨出来的。搜索时不要只搜“skills”这个大词带上场景去搜比如“frontend code review skills”、“math modeling skills”命中率会高很多。2.2 给前端开发、数学建模、AI漫剧挑技能的思路挑技能不能只看热度要看你自己的使用场景。结合最近的搜索热词我拎三个典型的场景说说选型思路。前端开发优先找那种“带明确执行链路”的技能比如组件生成、代码审查、规范检查、状态管理重构。判断标准是看它有没有在SKILL.md里写出“先读什么文件、再改哪些类型、最后跑什么命令”只有这种流程化的东西才能在真实项目里落地。如果一个前端技能只是一堆空泛的“请写出优雅的组件代码”那基本没什么用。数学建模这是我看到讨论特别密集的领域尤其是“华为杯数学建模比赛好用的codex skills”这类问题。建模场景的特点是时间紧、任务链长、输出要求固定。推荐选那些覆盖“问题分析→模型选择→算法实现→结果可视化→论文排版”整条链路的技能包而不是只解决“画图”或者“求最优解”的零散技能。很多建模技能会内置常见算法模板比如线性规划、遗传算法、神经网络这些代码骨架直接适配代码运行环境这种是实战里最香的。AI漫剧这个方向挺特别它的核心痛点不是编程而是一致性和量产效率。漫剧项目往往需要批量生成分镜脚本、统一角色特征、保持画风稳定。我建议重点找角色一致性管理、分镜规划、提示词批次生成这类的技能。好的漫剧技能一般会规定一个固定的输出模板把“角色外貌描述”“场景描述”“镜头语言”拆成字段这样后面所有生成任务都能用同一个标准去对齐。2.3 判断一个skills是否值得装的“三看”清单我把选型经验浓缩成一个三看清单照着检查能避开大部分坑看结构完整性打开仓库检查技能目录里是否有SKILL.md且位于根目录是否自带readme、示例或测试样本。只有SKILL.md而没有配套文件的技能往往说明作者没经过真实场景打磨。看描述精确度读description那几行字看看它是否明确说明“适用场景、触发条件、输出物”说清楚这些的技能模型才能准确调用。描述写得像废话的基本可以关掉了。看维护活跃度看最后更新时间、issue和PR情况。一个长期无人维护、问题无人回应的技能遇到版本更新时大概率会失效别指望它能在关键时刻救场。提示装技能克制一点。书架塞满没读过的书不是阅读能力强是焦虑。技能装得太多不仅管理混乱还会挤占上下文窗口反而降低模型表现。后面第5章我会专门讲清理方法。3. 手动安装一个GitHub上的skills从clone到验证的完整流程关于“claude code怎么手动装github上的skills”我估计是被问得最多的一个问题。其实剥开外壳底层就三步把仓库拉下来、把技能塞到约定目录里、重启会话触发加载。这里我用Claude Code、Codex、OpenCode这些常见CLI工具为例讲一遍带着验证环节的完整流程。3.1 先确认你的CLI工具支持什么目录安装之前先搞清楚一件事不同工具约定存放技能的路径不一样而且随着版本迭代还可能变化。以我目前接触到的常见约定来举例Claude Code通常认两个位置用户级目录比如~/.claude/skills和项目级目录比如.claude/skillsCodex类的工具大致对应~/.codex/skills或项目.codex/skillsOpenCode一般用.opencode/skills。项目级目录的好处是跟着仓库走团队成员clone下来就能共享用户级目录则是全局生效偏向个人习惯类技能。我把常用的路径整理成一张表你安装前先对照自己的工具和版本确认一下以官方文档为准工具用户级目录示例项目级目录示例Claude Code~/.claude/skills/.claude/skills/Codex~/.codex/skills/.codex/skills/OpenCode~/.opencode/skills/.opencode/skills/3.2 clone、放置、改名的完整步骤假设你在GitHub上看到一个名为awesome-project-skills的仓库想单独把其中frontend-review这个技能装进Claude Code实际操作大概长这样# 1. 克隆仓库到临时目录先别直接clone到技能目录避免把整个仓库塞进去 git clone https://github.com/example/awesome-project-skills.git /tmp/awesome-skills # 2. 查看仓库里技能的组织形式可能是 skills/frontend-review/ cd /tmp/awesome-skills ls -la skills/ # 3. 把目标技能目录复制到 Claude Code 的用户级技能目录 mkdir -p ~/.claude/skills cp -r skills/frontend-review ~/.claude/skills/ # 4. 检查目标目录里是否真的有 SKILL.md ls -la ~/.claude/skills/frontend-review/这里有一个我自己刚开始时踩过的坑很多集合仓库不会把技能直接放在仓库根目录而是放在skills/或src/skills/这种二级目录下。如果你图省事把整个克隆出来的仓库一股脑扔进技能目录只会得到一堆根本不会被识别的东西。一定要先ls看结构定位到真正包含SKILL.md的那一层。还有个细节是改名。技能目录名不一定等于SKILL.md里的name字段但多数工具会以目录名或name字段来做查询键。发现重名时我建议以sk额里定义的name为准目录名尽量保持一致否则可能出现“能看到目录却加载不了”的怪问题。3.3 验证技能是否被加载的检查清单装完之后不要急着干别的先做一轮验证。不同工具的入口不一样但思路共通。以Claude Code为例我会做这么几步在项目目录下重新启动会话确保它重新扫描了技能目录。输入斜杠命令比如/skills看有没有列出刚安装的技能以及它的描述是否正确。直接问模型一句“你现在加载了哪些技能各自负责什么场景”看它能不能准确说出来。检查技能目录权限有些技能会带可执行脚本目录权限不对的话即使能被扫描到调用时也会报错。如果在/skills里看不到目标技能先回头检查SKILL.md是否真的存在于该目录的根层级这是最常见的失败原因。其次看YAML格式有没有解析问题比如漏了闭合的---或者description里混入了不支持的字符。3.4 安装之后必须要做的“冒烟测试”验证技能“能被看到”只完成了一半更关键的是验证“能干活”。我会立刻用一个小而真实的输入做一次冒烟测试。比如装了前端代码审查技能就丢一段有明显问题的代码给它命令要求“按frontend-review的流程执行”装了数学建模技能就给一个简化的线性规划例子让它按照技能里定义的步骤输出。冒烟测试要选“最简单但能跑通全链路”的任务因为如果连最小任务都执行不下去说明技能内部指令和实际环境不匹配需要马上排查而不是等到正式项目里才暴露。提示从GitHub装回来的第三方技能建议养成先读一遍SKILL.md的习惯。它可能涉及脚本执行或文件读写不看过一遍内容就盲装相当于把不明来历的代码交给你的AI助手执行。我把这当作基本的安全底线。这类问题在“skills下载”场景里最容易被忽视很多人急着安装连仓库描述都没读。4. 自己动手写一个skillsSKILL.md的正确打开方式如果说装别人的技能是“开箱即用”那自己写技能就是从被动消费到主动生产的质变。网上搜“ai skills怎么写”能翻出各种模板但很多人还是写不好原因无非是没理解技能文件的本质它不是给模型看的作文而是给模型用的操作手册。4.1 写作模板和字段说明一个典型SKILL.md的开头会长这样--- name: log-analysis description: 分析博客或服务端日志文件提取错误分布、热门请求路径和异常趋势。适合nginx日志、应用系统日志的快速排查场景。 --- # 日志分析 ## 适用时机 - 当用户提供日志文件路径或文本内容时 - 当用户要求定位错误原因、统计请求分布时 ## 执行步骤 1. 先确认日志格式读取前20行识别字段。 2. 统计Error、Warn、Info级别出现的次数和占比。 3. 按请求路径聚合找出响应异常的Top 10。 4. 输出结构化报告包含错误摘要、Top请求、可疑根因。 ## 输出格式 - 报告必须包含三个小节概览、异常清单、修复建议。 - 修复建议不要超过5条按优先级排序。 ## 注意事项 - 如果日志文件超过1万行先做抽样分析不要尝试全部加载进上下文。 - 不要臆造日志里不存在的字段。这里面最容易被忽视也最重要的字段是description。我反复强调模型判断“什么时候该用这个技能”靠的就是这行描述。它越具体匹配越准。不要说“分析日志”这种大路货要说“分析nginx日志提取错误分布和Top请求路径”这样模型在遇到相关问题时才会精准触发。description里顺带写一下“不适合什么场景”能有效减少误触发。4.2 从零写一个“日志分析”技能的过程上面这个log-analysis其实就是一个能直接跑起来的最简版本我拆解一下它的写作过程。先把目标限定清楚我手上服务出问题了我需要AI帮我快速定位异常而不是做一份精美报表。所以执行步骤的核心就是“识别格式→统计级别→聚合路径→给结论”。这个技能我最初写的时候只有两行——“帮我看看日志有什么问题”结果模型每次给的答案都太散有时贴一堆原文有时跳过统计。后来改成强制输出“概览、异常清单、修复建议”三个小节输出质量立刻稳定了。4.3 指令粒度写细则还是留白给模型这是写技能最需要拿捏的分寸。我的经验是流程和格式要写细具体实现要留白。比如“先统计Error级别出现次数”是流程必须写清楚“用什么函数去统计”是实现细节不用写模型自己会选。如果不留白指令过多会占用上下文反而压缩了模型发挥的余地。有个简单判断标准如果一条指令离了具体项目环境就无法成立那多半属于实现细节把它从技能里删掉。4.4 迭代测试把技能当代码一样维护写完技能不迭代就跟提交代码不测试一样危险。我建议在开发阶段就给技能配一组测试输入比如日志分析技能就准备一份几百行的样例日志每次修改SKILL.md之后跑一遍看输出是否符合预期。修改技能时要注意版本习惯我会在技能目录里留一个CHANGELOG片段记录每次改了什么不然过两个月再看完全忘了当初为什么把这个步骤删掉。另一个贴近实战的心得是别把技能写得像教科书。技能是给高强度工作中用的设计目标永远是让AI更稳定地产出可用结果。凡是不能让你在重复劳动里省时间的修饰都可以砍掉。5. 规模化使用的高频问题上下文被撑爆、技能互相打架、清理方法技能用多了之后你会进入一个新阶段不是“找不到技能用”而是“技能太多不知道怎么管”。搜索热词里专门有“tibo关于清理skills的方法推荐”“常用skills”“skills下载”这些说明大家普遍面对同一个困境——装了删、删了装最后目录乱成一锅粥。这一节我集中讲问题和出路。5.1 为什么装多了反而变蠢先说一个反直觉的现象技能装到一定数量后AI的表现可能不升反降。原因在上下文策略上。不同工具对技能的处理方式不太一样有的是把所有技能的元信息都放进上下文有的按需加载但共同点是技能描述和指令终究会占用一定的上下文空间。当几百个技能的描述一起堆在上下文里模型要做两件事——理解你的实时提问、同时从几百个候选里挑技能两者互相挤占表现自然下滑。所以我的第一原则是按项目装技能而不是按人生装技能。项目A只需要前端审查和数据模拟那就只装相关的几个和这个项目无关的全局技能宁可放在备用目录里也不要全部铺开。如果你的CLI工具支持“项目级技能目录”尽量多用项目级隔离而不是把所有东西都塞进用户级目录。5.2 排查“技能去哪儿了”的调试路径遇到“明明装了技能但它不干活”的情况我有一套固定的排查路径先重启会话确认不是缓存问题。用工具的技能列表命令比如/skills类入口确认技能是否在列表中。检查触发语句是否命中技能的description场景有时技能加载了但你的提问用词和描述不匹配模型没意识到该用它。这种情况我会直接说“请使用log-analysis技能处理这份日志”手动点名。再检查技能正文里是否有冲突指令比如某个步骤明确说“不要分析Error日志”那它在特定场景下自然表现得不听话。最后看输出是否被人为截断技能正文太长会导致它只按前半段执行典型表现是做到一半就停了。这个过程做多了之后你会形成直觉大部分技能“不生效”不是因为工具坏了而是门槛没匹配上——要么描述不准确要么正文有冲突要么项目环境不对。5.3 清理技能的具体操作和整理习惯关于清理我把我平时用的“三步整理法”分享出来和社区里一些博主总结的思路大致相通也算是我消化后的版本第一步归档而不是删除。建一个~/.claude/skills-archive类似的目录把暂时不用的技能移过去。这样既不敢误删又不会让它们在当前会话里生效。第二步定期清点。每个月花十分钟看一遍技能列表问自己三个问题这个技能近两周用过吗它解决的问题现在还存在吗有没有另一个技能可以覆盖它只要有一个回答不好就把技能扔进归档目录。第三步给技能写一句话备注。直接在技能目录下放一个README片段或者用description字段记上“什么时候装的、当时为了解决什么问题”下次清点时一眼就能想起来。别信自己脑子目录会超过记忆容量。还有一个经常被忽视的清理维度指令碎片化。很多人遇到小问题不写技能而是每次在对话里补一句“记住以后都这样做”。这些话散落在历史会话里工具不会自动把它们聚合进技能里结果就是你反复解释、模型反复遗忘。清理技能的深层含义其实是把零散的“口头约束”升级成结构化的技能文件这样每次会话都能稳定继承。6. 把skills当成一种“工作方法”而非“工具包”写到这里我最想表达的观点是skills表面上是一堆目录和Markdown文件实质上是一种工作方法。它的价值不在于“给你一个更听话的AI”而在于“逼你把做事的流程想清楚”。6.1 技能与项目配置的配合真正成熟的用法是把技能项目和项目配置文件绑在一起。我在团队里推荐的做法是每个项目仓库自带一份技能目录里面放的是这个项目专属的代码规范、发布流程、测试习惯。新成员clone仓库之后不需要看几十页wikiAI就能按这套技能库工作。这种“技能随项目走”的方式比任何培训文档都更直接。技能和项目配置结合得越紧AI产出的结果越像“自己人写的”。6.2 从“抄技能”到“造技能”的转变大多数人接触skills都是从抄开始——抄别人的仓库装别人的技能包。这没问题但真正的分水岭是你开始造属于自己的技能。我建议的路径是先挑一个你天天做、做到想吐的任务把流程写成技能。比如我最早自建的技能就是“日志分析”后来是“生成周报”再后来是“接口字段映射”。每一个都是从实际工作里长出来的效果远比下载的通用技能好。造技能的过程本质上是把你个人的隐性经验变成显性知识这种知识跟着你走换任何工具都能迁移。6.3 给零基础读者的一条最小起步路径如果你现在完全没有接触过skills我建议你按这个顺序来只安装一个和你当前工作最相关的技能跑通一次完整调用感受技能和普通对话的差异。用/skills类命令或工具日志观察技能是什么时候被加载、什么时候被忽略的建立“触发条件”的直觉。把技能目录拆开看读一遍SKILL.md的每一行对照自己的使用体验理解description和正文的作用。复制一个已有的技能改掉其中一半内容替换成自己的工作流程跑一轮冒烟测试。当你改了第三个技能后你已经具备独立写技能的能力了。坦白说这个领域更新很快今天记下的安装路径和命令格式过两三个月可能就变了。真正值得沉淀的是那套思考和排查的方法以及“把重复工作变成可复用资产”的意识。我现在的习惯是每做完一个有点复用价值的任务就顺手评估一下“要不要把这个流程沉淀成一个技能”。哪怕只是一个很小的技能聚少成多之后你会发现自己做项目的方式变了——不是从零开始而是从一套自己长期打磨的工具箱出发。这才是skills真正让我着迷的地方。
