如果你最近在折腾 Claude Code、Codex 或者 OpenCode，大概率已经撞见过一个高频词：AI Skills。我最近大概有一半的编码时间都花在这些 skills 上——从 GitHub 扒别人写好的技能包，到改造成自己能用的，再到自己动手写新的。这东西说白了，就是把“怎么干一件事”的经验打包成一个小文件夹，扔给 AI 编程工具就能用。这篇文章不聊虚的，直接讲三件事：skills 到底是什么、怎么从 GitHub 手动装到本地、怎么自己写一个能跑的 skill。适合正在用 AI 编程工具但不满足于默认行为的同学，也适合那些想在团队里沉淀一套“AI 工作法”的人。
1. 先从根上理解：AI Skills 到底是个什么东西
1.1 用“给后厨递菜谱”来理解 Skills
我经常用一句话解释 Skills：它是一份结构化的“工作手册”，让 AI 在遇到对应任务时，知道按什么流程、用什么工具、产出什么格式。
你可以把大语言模型想象成一个特别聪明但有点“脸皮薄”的新人厨师。你直接说“帮我做一道剁椒鱼头”，他大概率能做得像模像样，但每次都会自由发挥，火候、摆盘、调料比例全看心情。如果你递给他一份写好的菜谱，里面清楚标注了原料清单、步骤顺序、成品标准，他就能稳定复现。Skills 就是这个菜谱。
一个典型的 AI Skill，在文件系统层面就是一个文件夹，里面通常有一个SKILL.md文件，记录“这个技能用来干什么、怎么干”；还可以带上参考文档、脚本、模板等附属文件。AI 工具会在对话过程中根据用户需求，自动判断要不要调用这个技能，调用后按SKILL.md的指示去执行。
1.2 它跟 Prompt 模板、插件有什么本质区别
很多人第一次接触 Skills，会把它和“ Prompt 模板”“插件”混在一起。我用一个表说清楚差异：
| 对比维度 | Prompt 模板 | 插件 / MCP 工具 | AI Skills |
|---|---|---|---|
| 本质 | 一段文本 | 代码级扩展，可调用外部服务 | 结构化文档 + 可选脚本/资源 |
| 稳定性 | 每次都要模型重新理解，结果飘 | 确定性强，但重、要改运行环境 | 介于两者之间，模型按手册执行 |
| 是否可复用 | 需要复制粘贴，分散在各处 | 可复用，但开发成本高 | 可复用，文件夹即单元 |
| 适合场景 | 临时任务、一句话指令 | 需要确定性工具调用 | 沉淀团队经验、批量复用工作流 |
一句话总结：Prompt 是“口述”，插件是“外挂机器”，Skills 是“培训手册”。它的核心优势在于轻——不需要改代码、不需要注册服务，就是一个文档驱动的协议，任何会写 Markdown 的人都能做。
1.3 为什么 2025 年 Skills 突然成了 AI 编程的标配
过去我们觉得，模型上下文窗口越来越大，直接把背景资料一股脑塞给 AI 不就行了？实际用过就明白，窗口大不代表会用，塞进去一堆无关信息反而会干扰判断。Skills 解决的是“知识可用性”问题：把任务相关的操作说明、注意事项、判断规则整理好，在需要的时刻才被触发，不占用对话上下文，也不会被遗忘。
另一个原因是多智能体协作。现在 Claude Code、Codex 这类工具越来越强调 Agent 自主规划、自动执行，每个 Agent 需要统一的“技能协议”才能互相读懂彼此的产出。Skills 恰好提供了一个轻量的公共约定：一个文件夹、一个 Markdown 文件，就能让你的 Agent“学会”一门手艺。所以你会看到 GitHub 上出现了大量 skills 仓库，社区里也开始讨论“技能资产”的沉淀和管理，可以说这已经成了 AI 工程实践里的一个新兴方向。
2. 从 GitHub 手动安装 Skills：最实用的完整流程
2.1 动手前先搞懂三件事：格式、路径、触发
装 skills 之前，得先把三个关键概念理清楚，否则很容易出现“明明装了但 AI 就是不用”的情况。
第一是格式。绝大多数社区 skills 遵循一套约定：一个文件夹内至少有一个SKILL.md文件，文件头部是 YAML frontmatter，包含 name 和 description 字段；正文部分写具体的操作流程、规则、注意事项。AI 工具就是靠解析 description 来判断“什么时候该用这个技能”。
第二是路径。以 Claude Code 为例，用户级 skills 一般放在~/.claude/skills目录下，项目级 skills 放在当前项目的.claude/skills目录下；Codex 也有类似约定，通常放在~/.codex/skills或对应配置目录；OpenCode 则常见于~/.config/opencode/skills。具体以你所用工具的最新文档为准，但大思路一致：找到一个“技能目录”，把文件夹放进去。
第三是触发。Skills 不是显式命令，而是由模型根据对话内容自动判断是否调用。所以 description 写得好不好、路径放得对不对，直接决定了触发率。我见到太多人装了一堆技能，结果 AI 一次都没用过，八成是 description 太差或者路径错了。
2.2 手动安装五步走
下面是我实际操作中验证过的一套流程，以 Claude Code 为例，其他工具换一下路径就行。
第一步，打开 GitHub，搜索awesome claude skills、agent skills这类关键词，或者直接找superpower skills这类知名项目。你会看到大量集合型仓库和单技能仓库。
第二步，进入某个仓库后，先看它的目录结构，确认是不是有skills/子目录或者多个技能文件夹。不要心急，先扫一眼 README，搞清楚作者约定的安装方式。
第三步，把仓库拉到本地。可以用 git clone，也可以直接下载 ZIP 包：
git clone https://github.com/your-name/your-skill-repo.git我习惯先 clone 到临时目录，再挑选需要的子目录复制过去，而不是直接原地安装，因为你往往只需要整个仓库里的某一个技能，全塞进去会让 AI 的选择器“选择困难”。
第四步，把选中的技能文件夹复制到正确路径。假设我要安装一个叫latex-helper的技能：
mkdir -p ~/.claude/skills cp -r ~/tmp/your-skill-repo/skills/latex-helper ~/.claude/skills/注意复制后确认目录结构是~/.claude/skills/latex-helper/SKILL.md，而不是~/.claude/skills/latex-helper/skills/latex-helper/SKILL.md。这种“套娃”错误是我见过最多的问题。
第五步，重启你的 AI 编程工具，或者在工具里手动触发一次技能扫描（不同工具入口不同，有的在设置面板，有的重启即自动加载）。然后找一个真实任务测试，而不是问“你有哪些技能”——这种问题模型不一定老实回答，直接用真实需求测才靠谱。
2.3 验证安装是否生效
验证这一步千万别省。我会按顺序做三个检查：
先看文件系统，确认路径没错：
find ~/.claude/skills -name "SKILL.md"再看工具日志或配置界面，确认技能被加载。有的工具会在启动时输出加载了哪些 skills，有的需要你打开命令面板查看。
最后做一次实际测试。比如我装了一个“代码审查”技能，就拿一段有明显问题的代码让它走一遍审查流程，看它的输出是否符合SKILL.md里约定的格式。如果输出和普通回答没区别，那基本可以断定技能没有触发，赶紧回头查路径和 description。
这里有个小技巧：你可以在SKILL.md的正文里加一句固定输出标记，比如“本报告由 code-review skill 生成”，这样一看到标记就知道技能确实被调用成功了。
3. 写一个自己的 Skill：SKILL.md 拆解与模板实战
3.1 最小可用 Skill 长什么样
安装别人的技能只是第一步，真正有价值的是写自己的技能。你不需要会写代码——一个纯文档型 Skill 就足以覆盖很多场景。
先看一个最小可用的SKILL.md：
--- name: meeting-notes description: 根据会议录音转写文本生成结构化会议纪要，适合项目复盘、周会、客户沟通等场景。输入是一段对话文本，输出是包含结论、待办、风险三部分的纪要。 --- ## 任务目标 把用户提供的会议对话转成结构化纪要。 ## 处理步骤 1. 通读文本，识别发言人角色。 2. 提取关键决策和结论。 3. 整理待办事项，标注重负责人和截止时间（若原文有）。 4. 识别风险点，用一句话概括风险内容。 ## 输出格式 - 会议结论：三到五条，每条不超过五十字。 - 待办事项：表格展示，列为“事项 / 负责人 / 截止时间”。 - 风险记录：每条包含“风险描述 / 影响程度（高/中/低）/ 建议动作”。这段内容看起来简单，但它已经定义了 AI 该在什么场景用、该怎么一步步做、最后输出什么结构。模型看到description里的关键词，比如“会议纪要”“周会”“转录文本”，就很容易在合适时机触发。
3.2 写好 description 的 3 个技巧
description 是整个 skill 的“触发命门”。我踩过不少坑，总结出三个技巧：
第一，写清楚“什么时候用”。不要写“这是一个有用的工具”这种空话，要写“当用户提供会议录音转写文本并要求整理纪要时使用”。直接点出输入信号。模型是靠关键词和意图匹配的，不是你写得越长越好。
第二，写清楚“输入是什么、输出是什么”。比如“输入是转录文本，输出是结构化 md 文件”，这让模型知道触发条件，也提前锁定了产出格式，避免自由发挥。
第三，加上“不适用”的反例。比如“当用户只是想闲聊会议内容时不要使用本技能”。反例能显著降低误触发率，这一点很多人忽略。我给自己的每个技能都会加一句“若非以下情况，请忽略本技能”。
3.3 让 Skill 学会调脚本：进阶玩法
纯文档型 skill 覆盖知识性任务没问题，但如果你想让它真正“干活”，比如批量处理文件、调用 API、跑数据清洗，就需要让 skill 调用外部脚本。
做法很简单：在 skill 文件夹下放一个scripts/子目录，把 Python、Node 或 Shell 脚本放进去，然后在SKILL.md正文里告诉模型“执行某个脚本时需要用什么命令、传什么参数”。
## 工具调用 当需要计算数据集的统计指标时，使用项目内脚本： python3 ~/.claude/skills/data-helper/scripts/stats.py --input <文件路径> --output <结果路径>这里有个安全红线：不要给模型任意执行命令的权限。我一般只会授权它执行技能目录内固定脚本，并限制参数范围。具体做法是在脚本入口写白名单逻辑，只允许处理当前工作目录下的文件，禁止危险操作；同时要求模型在执行前先打印命令，由你确认。
3.4 常见设计误区
写 skills 最大的问题不是写不出来，而是写得“让 AI 不会用”。我复盘过自己踩过的坑：
一是把SKILL.md写成长篇大论，恨不得塞进整个项目文档。模型处理超长文档的成本很高，而且重点会被淹没。正确做法是正文只写任务流程和关键约束，详细参考内容放到references/子目录，并按需引用。
二是把 description 写成“营销文案”。比如“本技能可以大幅提升效率，帮助你写出更好的代码”——模型听完完全不理解何时触发。正确做法是描述输入信号和场景，而不是吹嘘效果。
三是脚本没有错误处理。如果脚本一遇到非法输入就抛异常，模型会被卡住，它会尝试各种方式绕过问题，最后可能直接放弃。我在脚本里都会加try/catch并输出友好错误，让模型能拿到“可理解”的报错信息继续处理。
四是忽略命名规范。文件夹名最好用短横线命名，比如>
QT内嵌浏览器实现GB/T 28181国标摄像头网页播放
1. 为什么国标摄像头网页端播放成了“三不管”地带你有没有遇到过这种场景：项目现场部署了几十路GB/T 28181国标摄像头，甲方领导掏出手机说：“能不能直接在浏览器里点开看？别装客户端了。”你点头说“可以”，转身打开电…
李华
用MCP把Cursor接到蓝湖：设计稿参数直连代码，告别手动还原
先交代一下背景。今年年初我们把设计协作平台从 Sketch 手工切图彻底切到了蓝湖，设计师出稿、标注、切图全部在蓝湖上完成。稿子倒是集中了，但紧接着就冒出一个新的麻烦：每个迭代，设计师都要在群里追着问"还原了吗"&am…
李华
LangChain实战：从RAG到Agent的工程化落地指南
先说个结论：LangChain本身不是模型，也不是某种“大模型能力外挂”，它是一个工程框架。它的价值在于把大模型应用开发里那些重复造的轮子——提示词管理、模型调用、外部工具接入、记忆状态、文档检索——做成了一套相对统一的抽象接口。我个人…
李华
基于LSTM的外汇预测模型：Python源码、数据与训练全流程
简介：这是一份基于LSTM网络的外汇预测模型学习资源，面向计算机相关专业学生、教师及企业员工，可用于深度学习与时间序列分析的入门实践，也可作为课程设计、毕业设计或作业的参考案例。资源包共31个文件，约13.41MB&…
李华
从断言到评估：AI系统测试的核心方法论与转型路线图
1. 先在“为什么断言思维失效”上想明白在测试圈子里待久了，你会发现一个很有意思的现象：很多从传统软件测试转到AI系统测试的朋友，初期最大的障碍不是不会写代码，不是不懂算法，而是整个人处于一种“使不上劲”的状态。…
李华
大模型蒸馏实战指南：从数据清洗到SFT与DPO的完整路线
最近被问到最多的问题，就是大模型蒸馏。很多团队手里已经有一个大模型，或者一个调好的开源大模型，推理质量不错，但每次调用的延迟和成本都很让人抓狂。于是大家自然想到一条路：用大模型生成数据，去训练一个…
李华