1. Skills 到底是什么一次搞懂这轮新玩法的底层逻辑最近半年AI 编程助手圈子里最让我觉得值得花时间研究的概念就是 skills。我最早是在 Claude Code 里接触到的当时团队里一个同事把代码评审的规范做成了一个技能包丢到共享仓库里让大家批量安装效果出奇地好。后来发现 Codex、OpenCode 也都在往这个方向走GitHub 上各种skills 推荐常用 skills 源网站的热度一直没下去。但我也看到大量用户把 skills 等同于提示词模板觉得换了个名字而已。说实话这种理解会耽误很多事。一个 skill 和一个 prompt 最大的区别在于它是一套有边界、可命名、可复用、可被 AI 主动检索的能力模块。它不是塞进上下文里的一段话而是一个结构化的包。你可以把它理解成给 AI 装一个可随时调用的小插件平时不占对话空间一旦任务相关AI 会自动识别到这个该用技能 X 来处理然后才把技能内容加载进来。这个机制带来的直接好处是你不用再每回手动复制粘贴大段提示词也不用担心项目一复杂、上下文一长技能就淹没在无关信息里。在这一章里我不打算讲太玄的理论只想把 skills 的结构、加载机制以及它到底解决了什么痛点说清楚。这是后面所有实操的基础也是你判断该不该自己写一个技能时的核心依据。1.1 一个 Skill 的典型构成一个标准技能包的目录结构通常长这样my-skill/ ├── SKILL.md ├── scripts/ ├── references/ └── assets/最关键、唯一必需的文件是SKILL.md。它的开头是 YAML 格式的元信息包含name技能名称、description技能描述之后是正文指令。scripts/放可执行脚本或辅助程序references/放参考文档、代码片段、样例输出assets/放静态资源或模板。看起来不复杂但要注意几点。第一元信息的质量决定 AI 会不会用这个技能。description不能写成一个帮你做代码审查的工具这种毫无触发点的废话。好的描述是这样的对项目代码变更进行系统性审查重点关注安全性、性能、可维护性问题适用于提交前检查、Pull Request 评审前后阶段。 这段话包含了适用的任务场景AI 一看到代码审查相关指令就会想到这个技能。第二正文指令决定 AI 的实际表现。它不需要很长但必须把思考顺序、执行步骤、输出格式写清楚。我给自己的要求是一个技能正文尽量控制在 300 到 800 字之间说清楚先看什么后看什么什么情况下输出什么结构就行。第三支持资源不是越多越好。很多人喜欢往技能包里塞一堆文档结果 AI 加载时上下文容量被撑爆反而拖慢响应。我一般只在技能涉及外部工具、公式、数据模板时才放资源且只放必要的那一两份。1.2 为什么 Skills 能提升 AI 的表现上限我从自己的使用体验说一个观点Skills 最大的价值不是让模型变聪明而是让模型的每分力气都花在刀刃上。模型的能力上限其实是固定的但有效输出质量会随上下文质量大幅波动。你把项目规范、编码风格、安全红线、行业常识全部混在一段对话里模型很容易被无关信息带偏反过来如果你能在恰当的时机只把相关内容交给它它的表现会稳定非常多。Skills 就是这个恰当筛选的机制。举个例子。我有一次让 AI 帮我审查一个前端项目的改动如果不挂技能它会关注一些鸡毛蒜皮的地方比如某个变量命名不够优雅、某段代码可以拆成函数——不是说这些不对而是它不是代码评审最该抓的东西。挂上写好的 code-review 技能后它的行为马上变了先去读 diff再看有没有重复请求、内存泄漏、可访问性受损最后按严重程度分级输出。这就是技能在起作用它把人的工程经验编码进了模型的决策路径。另一个容易忽略的好处是团队协作。以前团队里定义完代码规范想执行约束得靠每个人自己遵守。现在我可以把规范直接做成技能包放进仓库让同事一次性安装大家用同一套审查规则输出质量自然对齐。这是纯提示词做不到的也是 skills 能在社区里快速火起来的核心原因。2. 手动安装 GitHub 上的 Skills以 Claude Code 为例的完整实操热词里那句claude code 怎么手动装 github 上的 skills被搜索量很高说明很多人都在这一步卡住了。我理解你的感受GitHub 上的技能包那么多下载下来却不知道该往哪放。其实安装的本质非常简单就是把仓库里的技能文件夹放到工具指定的技能目录下让工具能扫描到。我用 Claude Code 把整个过程拆开讲。2.1 安装前后目录结构与最短路径Claude Code 的默认技能目录是~/.claude/skills。安装前先确认这个目录存在mkdir -p ~/.claude/skills ls ~/.claude/skills如果目录还空着说明你还没装过任何技能安装就从零开始。如果你用的是 Windows路径类似是C:\Users\你的用户名\.claude\skills原理一致。到 GitHub 上找一个技能仓库比如某个人写的frontend-review-skill仓库内部结构通常是frontend-review-skill/ ├── SKILL.md ├── scripts/ └── README.md你要做的就是把包含SKILL.md的那个文件夹整体复制到~/.claude/skills/下。这样做完技能目录的最终结构应该是~/.claude/skills/frontend-review-skill/SKILL.md这里有个非常常见的坑很多人用git clone直接把整个仓库克隆进技能目录导致结构变成~/.claude/skills/frontend-review-skill/frontend-review-skill/SKILL.md多了一层嵌套工具就识别不了。判断标准很简单SKILL.md必须在技能文件夹的第一层不能藏在更深的路径里。2.2 命令实操与常见报错我喜欢的安装方式是用一条命令完成克隆并安放cd ~/.claude/skills git clone https://github.com/你的用户名/你的技能仓库.git克隆完后进入仓库检查结构如果发现仓库根目录下就是SKILL.md那这个技能可以直接用如果仓库里同时包含多个技能比如每个技能一个子目录那你得把每个技能子目录单独复制出来cp -r ~/.claude/skills/大仓库/技能A ~/.claude/skills/技能A_component/ cp -r ~/.claude/skills/大仓库/技能B ~/.claude/skills/技能B_component/装完技能不等于完事。我建议你立刻验证一下直接打开 Claude Code给出一个和技能描述吻合的任务观察它是否自动加载了对应技能。如果没有任何反应按下面三个方向排查。报错一目录层级不对。检查SKILL.md是否在技能文件夹第一层不要在技能文件夹里面再包一层同名文件夹。报错二YAML 元信息格式错误。name和description顶格写冒号后面要有空格缩进别乱用 Tab用空格。格式错了工具无法解析技能头部会直接跳过这个技能。报错三描述写得太模糊。如果description是代码审查这种泛泛的词AI 可能在遇到任务时判断不出来该用这个技能。改成带触发场景的描述比如适用于提交前检查或代码重构评审场景。2.3 远程仓库安装的正确姿势与安全提示有些技能仓库提供了自动安装脚本命令往往是curl -fsSL https://example.com/install.sh | bash我的原则是执行任何脚本前先下载下来看一眼内容再决定是否运行。虽然大多数仓库是可信的但先确认再执行应该成为使用开源资源的基本习惯。你可以先curl -fsSL 地址 -o install.sh打开文件检查没有异常行为后再bash install.sh。如果是自己手动从网页下载 ZIP 包解压后注意一个问题macOS 默认会给 ZIP 解压出来的目录加一层__MACOSX隐藏目录Windows 也可能多出一些辅助文件。这些都不影响使用直接忽略即可但要小心别把压缩包里的外层文件夹也一并复制进去。还有一个值得说的点纯提示词型技能只有SKILL.md一个文件不带脚本几乎适用于所有工具而带scripts/的技能对执行环境有依赖。安装前先看 README搞清楚它依赖的是 Python 还是 Node.js避免装完才发现跑不起来。3. 不同业务场景的 Skills 推荐清单与选型思路技能装多了你会发现真正好用的从来不是那种包罗万象的全能技能而是针对单一场景做到极致的专用技能。下面我按最近社区讨论热度最高的三个方向来说前端开发、数学建模竞赛、AI 创意内容生产。这三个方向最能体现 skills 的实用价值。3.1 前端开发的 Skills 组合前端方向最值得优先配置的技能是代码评审类。一个成熟的 frontend code review 技能应该把审查维度固定下来而不是泛泛地看哪里有 bug。我给团队配置的技能里审查优先级大致是是否有重复或冗余的网络请求、是否存在内存泄漏风险尤其事件监听和定时器、可访问性是否受损、改动是否破坏了既有状态管理逻辑。这种技能输出的审查意见会非常结构化分为严重问题、建议修复、可选优化三个级别并且会给出具体修复示例。第二推荐的是组件生成类技能。这种技能内置了团队的目录约定、命名规范、常用 UI 组件库的使用方式AI 生成 React 或 Vue 组件时就会自动遵守这些约束。比如团队规定所有页面级组件文件放在pages/组件级别文件放在components/技能加载后 AI 会自动按这个路径去生成不会再把文件位置写得乱七八糟。第三是 TypeScript 类型安全类。这类技能对类型设计的要求是能用字面量联合类型就不用string能用接口正常定义就不用any函数参数要显式标注返回类型。实际体验下来这类型技能能把代码里的any数量压得非常低代码可维护性提升明显。我的建议是别一次性装十几个前端技能只需要把代码评审 组件生成 类型安全这三板斧配齐基本能覆盖日常 80% 的场景。3.2 数学建模与竞赛场景的 Codex Skills华为杯建模比赛好用的 codex skills这个词条能进热搜说明大量参赛者已经在尝试用 AI 工具提升效率。数学建模的流程极度结构化非常适合用技能把规范操作固化下来。我推荐按阶段拆成三件套。第一件是数据处理技能。它的职责很窄读取原始数据文件识别字段类型、缺失值和异常值输出清洗后的标准化数据并自动生成描述性统计报告。别小看这一步比赛前期大量时间都耗在数据清洗上。第二件是模型选型技能。它内部维护了一张问题类型到算法模型的映射表。看到预测未来值就往时间序列、回归模型方向走看到分类就自动比较决策树、SVM、随机森林甚至浅层神经网络的适用条件看到优化问题就往线性规划、动态规划方向带。它会为每个候选模型给出复杂度、适用数据量和预期精度的对比帮你更快做决策。第三件是论文排版技能。比赛最痛苦的不是算不出来而是算出来了不知道怎么在论文里讲清楚。一个排版的技能会固定摘要结构背景、方法、结果、结论四段式、固定图表编号规则、固定公式排版方式。LaTeX 用户尤其推荐配置一个这类技能它能直接输出标准格式的论文片段节省大量时间。我个人的体会是别指望一个技能从数据处理帮你写到论文排版那是功能堆叠会互相打架。拆成三个独立技能反而每个都能保持小而精。3.3 AI 漫剧与创意内容生产方向AI 漫剧是内容和 AI 技术结合的新玩法核心痛点是角色一致性。同一个角色在中景、特写、不同光线条件下脸不能崩服装不能变。而普通提示词换个语气、换个上下文结果就飘了。Skills 在这里能做三件事。第一件是角色设定提炼。把一段描述性的角色介绍压缩成结构化的稳定标签发型、发色、瞳色、脸型、服饰特征、标志性道具每一个都用短词固定。这样后续所有镜头生成都在同一个角色约束集合下工作。第二件是分镜脚本拆分。把一个 300 字的故事段落切分成 6 到 8 个镜头序列每个镜头标明景别、运镜、角色状态、环境光线。这个技能的输出格式一旦固定后续生成效率会明显上升。第三件是文生图参数固定。同一个技能内置风格词、光线词、负面提示词的黑名单每次调用时自动补充上防止画面风格突然变化。如果你正在做 AI 漫剧这类一致性维护技能比任何灵感生成技能都值钱。因为灵感你随时都有但画面稳定只能靠规范约束来实现。4. 从零写一个自己的 Skill结构、命名与调试要点聊完现成的技能包我想花一整章说说怎么写自己的技能。只下载别人的你永远只是使用者真正自己写一个你会重新理解 AI 工具的设计逻辑。而且写一个技能的门槛没有你想得那么高关键在于思路清晰。4.1 Skill 文件格式与元信息设计我直接给一个最小可用的SKILL.md示例你就照着这个结构去写--- name: api-error-debug description: 分析后端接口报错日志定位错误根因适用于 API 联调、线上问题排查、日志分析场景。输入为错误日志或接口返回信息输出为根因分析报告。 --- # API 接口错误排查 你在协助开发者排查 API 接口报错问题。请按以下步骤执行 1. 先读完整的错误日志或错误响应不要跳过任何前缀信息 2. 分类错误类型网络层、鉴权层、参数校验层、业务逻辑层、数据库层 3. 对每类错误给出根因判断标准 4. 按以下结构输出 - 错误类型 - 根因概率排序从高到低 - 每条根因对应的验证建议 - 修复示例如果能在现有代码上下文中给出注意头部 YAML 的description这是 AI 将来决定是否加载技能的关键。你应该多花十分钟反复打磨它。一个技巧是在描述里嵌入任务动词和目标场景比如分析定位适用于输入为输出为这样 AI 检索时匹配的维度会更多。正文的编号列表也很关键。我发现以数字步骤开头的指令比自由段落文本更容易让模型按顺序执行。指令里可以加约束比如不要贴折行后的代码这种负面约束效果也很好。你还可以引导 AI 的探索行为让它主动查询代码库或读取相关文件。4.2 指令内容撰写的黄金法则写指令正文这件事我总结了三条比较实用的法则你自己写的时候可以直接套用。法则一一个技能只解决一个问题。如果你把写代码、写测试、写文档塞进同一个技能AI 会经常跑偏。技能不是流程手册它是单项能力模块。法则二给出正反例而非抽象规则。直接对比反例注意代码规范。正例函数命名使用动宾结构例如fetchUserData不要用getData或uData这类模糊命名。正反例比抽象规则可靠得多因为模型的模仿能力整体强于演绎能力。法则三把输出结构定死。模型默认的输出习惯是啰嗦的你要提前告诉它最终报告长什么样、顺序是什么、哪些信息必须包含。比如结论放最前面紧接着证据链最后才是建议这种有一个明确顺序的指令能显著改善调试体验。4.3 本地调试与效果验证技能写完一定要测我的标准流程分三步。第一步检查元信息是否能被正确解析。进入技能目录运行ls ~/.claude/skills/my-skill/ cat ~/.claude/skills/my-skill/SKILL.md确认目录层级正确、YAML 头部没有语法错误、正文没有畸形 Markdown。第二步主动触发测试。在对话里明确说请用 my-skill 的方式处理这个问题看模型是否加载技能、是否按照指令顺序执行。如果模型没有按步骤来大概率是正文指令写得太宽泛或被其他指令覆盖了。第三步诱捕式测试。不给模型任何明确技能名直接给一个含糊但相关的任务看它能否根据description自动选中并加载技能。如果它能做到说明技能的触发能力是合格的。很多情况下诱捕式测试失败了问题都出在description上——描述内容没有覆盖到实际任务场景。还有一个通常被忽略的点技能引用脚本时要确认执行权限。比如你在scripts/下放了analyze.py那它得是chmod x可执行的或者用python显式调用。否则 AI 尝试调用脚本失败常常会静默降级直接绕开技能输出一个不完整的结果你还不容易察觉。5. 技能库、下载源与生态工具的分布情况现在 GitHub 上的 skill 资源已经多到找不过来。很多人到处搜集技能库网址但真正决定体验的不是数量而是你知道去哪找、找什么类型、装完能不能用。这一章把资源分布的现状讲清楚。5.1 值得关注的开源技能库社区资源目前大致分三类。第一类是综合型技能集合仓库。这种仓库通常一口气收录几十个甚至上百个技能适合新手一次性批量安装然后逐个体验。在 GitHub 上搜 awesome claude skills 或 skills collection 能发现不少这类项目。它们的优点是全面缺点是质量参差不齐有些技能明显是凑数的。我的建议是别全装挑和你工作流匹配的装。第二类是框架型项目。它们不只是给技能还给技能定义了一套标准的写法、参数接口甚至让技能之间可以互相调用。社区里讨论度很高的 superpowers 就是这一类。它解决了一个很现实的问题单一技能只能做单一功能但如果技能之间能协作就能完成复杂的多步骤任务。这类框架学习成本高一些但它带来的能力升级是值得的。第三类是特定领域小仓库。只解决一个问题比如日志分析、论文润色、Excel 数据清洗。这种仓库通常质量很高但需要你自己有目的地检索。找的时候可以围绕业务关键字 skills组合比如 excel skills github 或 dataclean skill。5.2 不同工具对 Skills 的兼容性差异必须给大家提个醒skills 目前并没有统一的行业标准。Claude Code、Codex、OpenCode 对技能的支持程度和规范细节不一样。我自己用下来Claude Code 的 SKILL.md 形态比较成熟对 YAML 元信息、脚本资源、文件目录的解析都比较完善。Codex 也在加这块能力但在技能加载机制或目录约定上略有差异尤其对scripts/资源的处理方式不一定直接兼容。OpenCode 目前更多是吸收社区规范玩家众多功能迭代更快。所以我建议你在安装技能包时先看一下它是否是纯提示词型。如果是纯SKILL.md那几乎在所有工具里都能通用。如果带了scripts/和特定依赖就要考察一下目标工具的脚本执行方式是不是匹配。一句话总结能复用通用格式的技能就不要铤而走险硬塞带依赖的技能。技术选型上我给一个更务实的建议如果你刚开始接触选一个主力工具研究透彻即可不要同时在几款工具里各装一份同类技能。把主力的技能机制、目录结构、脚本加载方式搞清楚再去横向迁移效率会高很多。6. Skills 的清理、边界与长期维护经验热词里有一条很具体的问题问tibo 关于清理 skills 的方法推荐一看就是被技能堆积问题折磨过的人。我自己大概装过五六十个技能最后稳定使用的不到二十个。大部分技能不是没用而是在特定场景下才偶发挥价值。但如果不管不顾技能库就会变成数字杂物间AI 每次扫描负载增大还可能选错技能。这一章把我清理和维护的经验完整分享一下。6.1 什么时候该清理 Skills我的判断标准很直接一个技能如果连续两周都没被自动加载过一次它就进入了退化区间。这里的没被加载指的不是你没用过而是你在对话里发出相关任务时AI 并没有主动选中它。另一个需要清理的信号是技能之间发生冲突。比如你有两个代码审查类技能它们的描述高度接近AI 有时加载 A 有时加载 B输出风格完全不一样。这种结果对用户是灾难因为每次输出都不可预测。正确做法是果断合并。还有一个容易忽略的是脚本依赖过期的技能。技能引用的 Python 包升级了、API 字段变了或者工具链版本提升了旧技能就会过保质期。这类问题往往在你某天突然用到它时才发现那时候再排查非常痛苦。定期盘点能减少这类突发问题。6.2 清理方法论与推荐做法我的清理流程一般分三步。第一步是盘点。进入技能目录把每个技能包列出来ls ~/.claude/skills/逐个打开SKILL.md看name和description问自己三个问题这个技能在过去两周有没有被加载过它解决的问题我现在还用不用它和别的技能有没有重复第二步是分类。我习惯在~/.claude/下建一个skills_archive/文件夹把冷门、暂时不用但以后可能用到的技能移过去。这不等于删掉只是让主目录更干净。命令很简单mkdir -p ~/.claude/skills_archive mv ~/.claude/skills/冷门技能 ~/.claude/skills_archive/第三步是合并。职责重叠的技能合并成一个。合并不是简单地把两段文字拼在一起而是把两个技能的描述和指令重新梳理成结构化模式。比如把frontend review和accessibility check合并成web-quality review描述涵盖两类任务指令里用条件分支区分场景。做完这步技能库通常会缩水一半但效果会明显提升。6.3 我的维护习惯与个人经验最后分享几个我长期坚持的小习惯。第一我习惯在技能描述的最后加上日期标记。比如在description末尾写最后验证2025-07。这样做的好处是每个月盘点时只要一看描述就能知道哪些技能需要重新测试哪些可以直接退役。日期标记虽然看起来不起眼但它能有效防止过期技能继续带病运行。第二我每个季度做一次实测回归。挑出自己最常用的六到八个技能逐个用诱捕式测试触发一遍检验它们是否还能被 AI 正确加载、指令是否还适应当前模型版本。模型升级很频繁技能描述里的某些措辞可能突然就失效了定期回归能及时发现问题。第三我不建议在不同工具里各装一份同款技能。Claude Code、Codex、OpenCode 各自的加载机制不一样维护成本会翻倍。挑一个主力工具深入研究它的技能解析逻辑、脚本运行方式、上下文注入机制把它玩透比到处收集技能包要高效得多。我自己的主力工具是 Claude Code平时新发现一个技能包先手工安装到它的目录下测试确认效果后再决定是否供其他场景复用。清理和维护这件事短期内看不出多大差别但长期下来它会决定你的 AI 工具到底处于越用越顺的状态还是装了很多却什么也不稳定的状态。技能库不是收藏夹少而精永远比多而杂靠谱。最后再分享一个小技巧给你的技能统一命名规范比如都用领域-功能的结构像web-perf-audit、> AI编程助手Skills完全指南：从概念到安装、编写与维护
1. Skills 到底是什么一次搞懂这轮新玩法的底层逻辑最近半年AI 编程助手圈子里最让我觉得值得花时间研究的概念就是 skills。我最早是在 Claude Code 里接触到的当时团队里一个同事把代码评审的规范做成了一个技能包丢到共享仓库里让大家批量安装效果出奇地好。后来发现 Codex、OpenCode 也都在往这个方向走GitHub 上各种skills 推荐常用 skills 源网站的热度一直没下去。但我也看到大量用户把 skills 等同于提示词模板觉得换了个名字而已。说实话这种理解会耽误很多事。一个 skill 和一个 prompt 最大的区别在于它是一套有边界、可命名、可复用、可被 AI 主动检索的能力模块。它不是塞进上下文里的一段话而是一个结构化的包。你可以把它理解成给 AI 装一个可随时调用的小插件平时不占对话空间一旦任务相关AI 会自动识别到这个该用技能 X 来处理然后才把技能内容加载进来。这个机制带来的直接好处是你不用再每回手动复制粘贴大段提示词也不用担心项目一复杂、上下文一长技能就淹没在无关信息里。在这一章里我不打算讲太玄的理论只想把 skills 的结构、加载机制以及它到底解决了什么痛点说清楚。这是后面所有实操的基础也是你判断该不该自己写一个技能时的核心依据。1.1 一个 Skill 的典型构成一个标准技能包的目录结构通常长这样my-skill/ ├── SKILL.md ├── scripts/ ├── references/ └── assets/最关键、唯一必需的文件是SKILL.md。它的开头是 YAML 格式的元信息包含name技能名称、description技能描述之后是正文指令。scripts/放可执行脚本或辅助程序references/放参考文档、代码片段、样例输出assets/放静态资源或模板。看起来不复杂但要注意几点。第一元信息的质量决定 AI 会不会用这个技能。description不能写成一个帮你做代码审查的工具这种毫无触发点的废话。好的描述是这样的对项目代码变更进行系统性审查重点关注安全性、性能、可维护性问题适用于提交前检查、Pull Request 评审前后阶段。 这段话包含了适用的任务场景AI 一看到代码审查相关指令就会想到这个技能。第二正文指令决定 AI 的实际表现。它不需要很长但必须把思考顺序、执行步骤、输出格式写清楚。我给自己的要求是一个技能正文尽量控制在 300 到 800 字之间说清楚先看什么后看什么什么情况下输出什么结构就行。第三支持资源不是越多越好。很多人喜欢往技能包里塞一堆文档结果 AI 加载时上下文容量被撑爆反而拖慢响应。我一般只在技能涉及外部工具、公式、数据模板时才放资源且只放必要的那一两份。1.2 为什么 Skills 能提升 AI 的表现上限我从自己的使用体验说一个观点Skills 最大的价值不是让模型变聪明而是让模型的每分力气都花在刀刃上。模型的能力上限其实是固定的但有效输出质量会随上下文质量大幅波动。你把项目规范、编码风格、安全红线、行业常识全部混在一段对话里模型很容易被无关信息带偏反过来如果你能在恰当的时机只把相关内容交给它它的表现会稳定非常多。Skills 就是这个恰当筛选的机制。举个例子。我有一次让 AI 帮我审查一个前端项目的改动如果不挂技能它会关注一些鸡毛蒜皮的地方比如某个变量命名不够优雅、某段代码可以拆成函数——不是说这些不对而是它不是代码评审最该抓的东西。挂上写好的 code-review 技能后它的行为马上变了先去读 diff再看有没有重复请求、内存泄漏、可访问性受损最后按严重程度分级输出。这就是技能在起作用它把人的工程经验编码进了模型的决策路径。另一个容易忽略的好处是团队协作。以前团队里定义完代码规范想执行约束得靠每个人自己遵守。现在我可以把规范直接做成技能包放进仓库让同事一次性安装大家用同一套审查规则输出质量自然对齐。这是纯提示词做不到的也是 skills 能在社区里快速火起来的核心原因。2. 手动安装 GitHub 上的 Skills以 Claude Code 为例的完整实操热词里那句claude code 怎么手动装 github 上的 skills被搜索量很高说明很多人都在这一步卡住了。我理解你的感受GitHub 上的技能包那么多下载下来却不知道该往哪放。其实安装的本质非常简单就是把仓库里的技能文件夹放到工具指定的技能目录下让工具能扫描到。我用 Claude Code 把整个过程拆开讲。2.1 安装前后目录结构与最短路径Claude Code 的默认技能目录是~/.claude/skills。安装前先确认这个目录存在mkdir -p ~/.claude/skills ls ~/.claude/skills如果目录还空着说明你还没装过任何技能安装就从零开始。如果你用的是 Windows路径类似是C:\Users\你的用户名\.claude\skills原理一致。到 GitHub 上找一个技能仓库比如某个人写的frontend-review-skill仓库内部结构通常是frontend-review-skill/ ├── SKILL.md ├── scripts/ └── README.md你要做的就是把包含SKILL.md的那个文件夹整体复制到~/.claude/skills/下。这样做完技能目录的最终结构应该是~/.claude/skills/frontend-review-skill/SKILL.md这里有个非常常见的坑很多人用git clone直接把整个仓库克隆进技能目录导致结构变成~/.claude/skills/frontend-review-skill/frontend-review-skill/SKILL.md多了一层嵌套工具就识别不了。判断标准很简单SKILL.md必须在技能文件夹的第一层不能藏在更深的路径里。2.2 命令实操与常见报错我喜欢的安装方式是用一条命令完成克隆并安放cd ~/.claude/skills git clone https://github.com/你的用户名/你的技能仓库.git克隆完后进入仓库检查结构如果发现仓库根目录下就是SKILL.md那这个技能可以直接用如果仓库里同时包含多个技能比如每个技能一个子目录那你得把每个技能子目录单独复制出来cp -r ~/.claude/skills/大仓库/技能A ~/.claude/skills/技能A_component/ cp -r ~/.claude/skills/大仓库/技能B ~/.claude/skills/技能B_component/装完技能不等于完事。我建议你立刻验证一下直接打开 Claude Code给出一个和技能描述吻合的任务观察它是否自动加载了对应技能。如果没有任何反应按下面三个方向排查。报错一目录层级不对。检查SKILL.md是否在技能文件夹第一层不要在技能文件夹里面再包一层同名文件夹。报错二YAML 元信息格式错误。name和description顶格写冒号后面要有空格缩进别乱用 Tab用空格。格式错了工具无法解析技能头部会直接跳过这个技能。报错三描述写得太模糊。如果description是代码审查这种泛泛的词AI 可能在遇到任务时判断不出来该用这个技能。改成带触发场景的描述比如适用于提交前检查或代码重构评审场景。2.3 远程仓库安装的正确姿势与安全提示有些技能仓库提供了自动安装脚本命令往往是curl -fsSL https://example.com/install.sh | bash我的原则是执行任何脚本前先下载下来看一眼内容再决定是否运行。虽然大多数仓库是可信的但先确认再执行应该成为使用开源资源的基本习惯。你可以先curl -fsSL 地址 -o install.sh打开文件检查没有异常行为后再bash install.sh。如果是自己手动从网页下载 ZIP 包解压后注意一个问题macOS 默认会给 ZIP 解压出来的目录加一层__MACOSX隐藏目录Windows 也可能多出一些辅助文件。这些都不影响使用直接忽略即可但要小心别把压缩包里的外层文件夹也一并复制进去。还有一个值得说的点纯提示词型技能只有SKILL.md一个文件不带脚本几乎适用于所有工具而带scripts/的技能对执行环境有依赖。安装前先看 README搞清楚它依赖的是 Python 还是 Node.js避免装完才发现跑不起来。3. 不同业务场景的 Skills 推荐清单与选型思路技能装多了你会发现真正好用的从来不是那种包罗万象的全能技能而是针对单一场景做到极致的专用技能。下面我按最近社区讨论热度最高的三个方向来说前端开发、数学建模竞赛、AI 创意内容生产。这三个方向最能体现 skills 的实用价值。3.1 前端开发的 Skills 组合前端方向最值得优先配置的技能是代码评审类。一个成熟的 frontend code review 技能应该把审查维度固定下来而不是泛泛地看哪里有 bug。我给团队配置的技能里审查优先级大致是是否有重复或冗余的网络请求、是否存在内存泄漏风险尤其事件监听和定时器、可访问性是否受损、改动是否破坏了既有状态管理逻辑。这种技能输出的审查意见会非常结构化分为严重问题、建议修复、可选优化三个级别并且会给出具体修复示例。第二推荐的是组件生成类技能。这种技能内置了团队的目录约定、命名规范、常用 UI 组件库的使用方式AI 生成 React 或 Vue 组件时就会自动遵守这些约束。比如团队规定所有页面级组件文件放在pages/组件级别文件放在components/技能加载后 AI 会自动按这个路径去生成不会再把文件位置写得乱七八糟。第三是 TypeScript 类型安全类。这类技能对类型设计的要求是能用字面量联合类型就不用string能用接口正常定义就不用any函数参数要显式标注返回类型。实际体验下来这类型技能能把代码里的any数量压得非常低代码可维护性提升明显。我的建议是别一次性装十几个前端技能只需要把代码评审 组件生成 类型安全这三板斧配齐基本能覆盖日常 80% 的场景。3.2 数学建模与竞赛场景的 Codex Skills华为杯建模比赛好用的 codex skills这个词条能进热搜说明大量参赛者已经在尝试用 AI 工具提升效率。数学建模的流程极度结构化非常适合用技能把规范操作固化下来。我推荐按阶段拆成三件套。第一件是数据处理技能。它的职责很窄读取原始数据文件识别字段类型、缺失值和异常值输出清洗后的标准化数据并自动生成描述性统计报告。别小看这一步比赛前期大量时间都耗在数据清洗上。第二件是模型选型技能。它内部维护了一张问题类型到算法模型的映射表。看到预测未来值就往时间序列、回归模型方向走看到分类就自动比较决策树、SVM、随机森林甚至浅层神经网络的适用条件看到优化问题就往线性规划、动态规划方向带。它会为每个候选模型给出复杂度、适用数据量和预期精度的对比帮你更快做决策。第三件是论文排版技能。比赛最痛苦的不是算不出来而是算出来了不知道怎么在论文里讲清楚。一个排版的技能会固定摘要结构背景、方法、结果、结论四段式、固定图表编号规则、固定公式排版方式。LaTeX 用户尤其推荐配置一个这类技能它能直接输出标准格式的论文片段节省大量时间。我个人的体会是别指望一个技能从数据处理帮你写到论文排版那是功能堆叠会互相打架。拆成三个独立技能反而每个都能保持小而精。3.3 AI 漫剧与创意内容生产方向AI 漫剧是内容和 AI 技术结合的新玩法核心痛点是角色一致性。同一个角色在中景、特写、不同光线条件下脸不能崩服装不能变。而普通提示词换个语气、换个上下文结果就飘了。Skills 在这里能做三件事。第一件是角色设定提炼。把一段描述性的角色介绍压缩成结构化的稳定标签发型、发色、瞳色、脸型、服饰特征、标志性道具每一个都用短词固定。这样后续所有镜头生成都在同一个角色约束集合下工作。第二件是分镜脚本拆分。把一个 300 字的故事段落切分成 6 到 8 个镜头序列每个镜头标明景别、运镜、角色状态、环境光线。这个技能的输出格式一旦固定后续生成效率会明显上升。第三件是文生图参数固定。同一个技能内置风格词、光线词、负面提示词的黑名单每次调用时自动补充上防止画面风格突然变化。如果你正在做 AI 漫剧这类一致性维护技能比任何灵感生成技能都值钱。因为灵感你随时都有但画面稳定只能靠规范约束来实现。4. 从零写一个自己的 Skill结构、命名与调试要点聊完现成的技能包我想花一整章说说怎么写自己的技能。只下载别人的你永远只是使用者真正自己写一个你会重新理解 AI 工具的设计逻辑。而且写一个技能的门槛没有你想得那么高关键在于思路清晰。4.1 Skill 文件格式与元信息设计我直接给一个最小可用的SKILL.md示例你就照着这个结构去写--- name: api-error-debug description: 分析后端接口报错日志定位错误根因适用于 API 联调、线上问题排查、日志分析场景。输入为错误日志或接口返回信息输出为根因分析报告。 --- # API 接口错误排查 你在协助开发者排查 API 接口报错问题。请按以下步骤执行 1. 先读完整的错误日志或错误响应不要跳过任何前缀信息 2. 分类错误类型网络层、鉴权层、参数校验层、业务逻辑层、数据库层 3. 对每类错误给出根因判断标准 4. 按以下结构输出 - 错误类型 - 根因概率排序从高到低 - 每条根因对应的验证建议 - 修复示例如果能在现有代码上下文中给出注意头部 YAML 的description这是 AI 将来决定是否加载技能的关键。你应该多花十分钟反复打磨它。一个技巧是在描述里嵌入任务动词和目标场景比如分析定位适用于输入为输出为这样 AI 检索时匹配的维度会更多。正文的编号列表也很关键。我发现以数字步骤开头的指令比自由段落文本更容易让模型按顺序执行。指令里可以加约束比如不要贴折行后的代码这种负面约束效果也很好。你还可以引导 AI 的探索行为让它主动查询代码库或读取相关文件。4.2 指令内容撰写的黄金法则写指令正文这件事我总结了三条比较实用的法则你自己写的时候可以直接套用。法则一一个技能只解决一个问题。如果你把写代码、写测试、写文档塞进同一个技能AI 会经常跑偏。技能不是流程手册它是单项能力模块。法则二给出正反例而非抽象规则。直接对比反例注意代码规范。正例函数命名使用动宾结构例如fetchUserData不要用getData或uData这类模糊命名。正反例比抽象规则可靠得多因为模型的模仿能力整体强于演绎能力。法则三把输出结构定死。模型默认的输出习惯是啰嗦的你要提前告诉它最终报告长什么样、顺序是什么、哪些信息必须包含。比如结论放最前面紧接着证据链最后才是建议这种有一个明确顺序的指令能显著改善调试体验。4.3 本地调试与效果验证技能写完一定要测我的标准流程分三步。第一步检查元信息是否能被正确解析。进入技能目录运行ls ~/.claude/skills/my-skill/ cat ~/.claude/skills/my-skill/SKILL.md确认目录层级正确、YAML 头部没有语法错误、正文没有畸形 Markdown。第二步主动触发测试。在对话里明确说请用 my-skill 的方式处理这个问题看模型是否加载技能、是否按照指令顺序执行。如果模型没有按步骤来大概率是正文指令写得太宽泛或被其他指令覆盖了。第三步诱捕式测试。不给模型任何明确技能名直接给一个含糊但相关的任务看它能否根据description自动选中并加载技能。如果它能做到说明技能的触发能力是合格的。很多情况下诱捕式测试失败了问题都出在description上——描述内容没有覆盖到实际任务场景。还有一个通常被忽略的点技能引用脚本时要确认执行权限。比如你在scripts/下放了analyze.py那它得是chmod x可执行的或者用python显式调用。否则 AI 尝试调用脚本失败常常会静默降级直接绕开技能输出一个不完整的结果你还不容易察觉。5. 技能库、下载源与生态工具的分布情况现在 GitHub 上的 skill 资源已经多到找不过来。很多人到处搜集技能库网址但真正决定体验的不是数量而是你知道去哪找、找什么类型、装完能不能用。这一章把资源分布的现状讲清楚。5.1 值得关注的开源技能库社区资源目前大致分三类。第一类是综合型技能集合仓库。这种仓库通常一口气收录几十个甚至上百个技能适合新手一次性批量安装然后逐个体验。在 GitHub 上搜 awesome claude skills 或 skills collection 能发现不少这类项目。它们的优点是全面缺点是质量参差不齐有些技能明显是凑数的。我的建议是别全装挑和你工作流匹配的装。第二类是框架型项目。它们不只是给技能还给技能定义了一套标准的写法、参数接口甚至让技能之间可以互相调用。社区里讨论度很高的 superpowers 就是这一类。它解决了一个很现实的问题单一技能只能做单一功能但如果技能之间能协作就能完成复杂的多步骤任务。这类框架学习成本高一些但它带来的能力升级是值得的。第三类是特定领域小仓库。只解决一个问题比如日志分析、论文润色、Excel 数据清洗。这种仓库通常质量很高但需要你自己有目的地检索。找的时候可以围绕业务关键字 skills组合比如 excel skills github 或 dataclean skill。5.2 不同工具对 Skills 的兼容性差异必须给大家提个醒skills 目前并没有统一的行业标准。Claude Code、Codex、OpenCode 对技能的支持程度和规范细节不一样。我自己用下来Claude Code 的 SKILL.md 形态比较成熟对 YAML 元信息、脚本资源、文件目录的解析都比较完善。Codex 也在加这块能力但在技能加载机制或目录约定上略有差异尤其对scripts/资源的处理方式不一定直接兼容。OpenCode 目前更多是吸收社区规范玩家众多功能迭代更快。所以我建议你在安装技能包时先看一下它是否是纯提示词型。如果是纯SKILL.md那几乎在所有工具里都能通用。如果带了scripts/和特定依赖就要考察一下目标工具的脚本执行方式是不是匹配。一句话总结能复用通用格式的技能就不要铤而走险硬塞带依赖的技能。技术选型上我给一个更务实的建议如果你刚开始接触选一个主力工具研究透彻即可不要同时在几款工具里各装一份同类技能。把主力的技能机制、目录结构、脚本加载方式搞清楚再去横向迁移效率会高很多。6. Skills 的清理、边界与长期维护经验热词里有一条很具体的问题问tibo 关于清理 skills 的方法推荐一看就是被技能堆积问题折磨过的人。我自己大概装过五六十个技能最后稳定使用的不到二十个。大部分技能不是没用而是在特定场景下才偶发挥价值。但如果不管不顾技能库就会变成数字杂物间AI 每次扫描负载增大还可能选错技能。这一章把我清理和维护的经验完整分享一下。6.1 什么时候该清理 Skills我的判断标准很直接一个技能如果连续两周都没被自动加载过一次它就进入了退化区间。这里的没被加载指的不是你没用过而是你在对话里发出相关任务时AI 并没有主动选中它。另一个需要清理的信号是技能之间发生冲突。比如你有两个代码审查类技能它们的描述高度接近AI 有时加载 A 有时加载 B输出风格完全不一样。这种结果对用户是灾难因为每次输出都不可预测。正确做法是果断合并。还有一个容易忽略的是脚本依赖过期的技能。技能引用的 Python 包升级了、API 字段变了或者工具链版本提升了旧技能就会过保质期。这类问题往往在你某天突然用到它时才发现那时候再排查非常痛苦。定期盘点能减少这类突发问题。6.2 清理方法论与推荐做法我的清理流程一般分三步。第一步是盘点。进入技能目录把每个技能包列出来ls ~/.claude/skills/逐个打开SKILL.md看name和description问自己三个问题这个技能在过去两周有没有被加载过它解决的问题我现在还用不用它和别的技能有没有重复第二步是分类。我习惯在~/.claude/下建一个skills_archive/文件夹把冷门、暂时不用但以后可能用到的技能移过去。这不等于删掉只是让主目录更干净。命令很简单mkdir -p ~/.claude/skills_archive mv ~/.claude/skills/冷门技能 ~/.claude/skills_archive/第三步是合并。职责重叠的技能合并成一个。合并不是简单地把两段文字拼在一起而是把两个技能的描述和指令重新梳理成结构化模式。比如把frontend review和accessibility check合并成web-quality review描述涵盖两类任务指令里用条件分支区分场景。做完这步技能库通常会缩水一半但效果会明显提升。6.3 我的维护习惯与个人经验最后分享几个我长期坚持的小习惯。第一我习惯在技能描述的最后加上日期标记。比如在description末尾写最后验证2025-07。这样做的好处是每个月盘点时只要一看描述就能知道哪些技能需要重新测试哪些可以直接退役。日期标记虽然看起来不起眼但它能有效防止过期技能继续带病运行。第二我每个季度做一次实测回归。挑出自己最常用的六到八个技能逐个用诱捕式测试触发一遍检验它们是否还能被 AI 正确加载、指令是否还适应当前模型版本。模型升级很频繁技能描述里的某些措辞可能突然就失效了定期回归能及时发现问题。第三我不建议在不同工具里各装一份同款技能。Claude Code、Codex、OpenCode 各自的加载机制不一样维护成本会翻倍。挑一个主力工具深入研究它的技能解析逻辑、脚本运行方式、上下文注入机制把它玩透比到处收集技能包要高效得多。我自己的主力工具是 Claude Code平时新发现一个技能包先手工安装到它的目录下测试确认效果后再决定是否供其他场景复用。清理和维护这件事短期内看不出多大差别但长期下来它会决定你的 AI 工具到底处于越用越顺的状态还是装了很多却什么也不稳定的状态。技能库不是收藏夹少而精永远比多而杂靠谱。最后再分享一个小技巧给你的技能统一命名规范比如都用领域-功能的结构像web-perf-audit、>