1. 先说清楚Skills到底是什么为什么一夜之间到处都是最近不管是刷前端群还是逛开源社区总能看到有人在聊 skillsClaude Code、Codex、OpenCode这些 AI 编程助手的热搜词全都跟它绑在一起。很多人第一反应是“这不就是提示词吗怎么换个名字就火成这样”。还真不是Skills 这套机制比单纯堆提示词要重得多它本质上是在给 AI 助手“外挂能力模块”让模型在特定场景下知道自己该调什么工具、按什么流程干活、输出什么格式。我用一个生活化的类比以前的提示词相当于你给实习生口述一句“帮我整理一下数据”他能干成什么样全看悟性。而 Skills 相当于你直接把一套《部门工作手册》塞给他里面写了数据从哪取、清洗规则是什么、结果要输出成什么表格、遇到异常找谁确认。同样是干活后者稳定得多也靠谱得多。这个机制之所以突然爆发是因为各家 AI 编程工具在 2024 年底到 2025 年初集中开放了自定义技能体系。Claude Code 的 Skills 目录、Codex 的技能仓库、OpenCode 的插件生态虽然实现细节不一样思路基本殊途同归把高频、可复用的工作流固化成文件让模型在合适的时机自动加载并执行。这篇文章我会从安装、开发、场景推荐、问题排查四个维度把 Skills 从入门到进阶的完整链路捋一遍。不管你是刚听说这个概念想试试还是已经在用但想自己写一套高效技能应该都能在这篇里找到能直接抄作业的东西。2. 怎么装从 GitHub 手动安装到技能市场一条龙2.1 最稳妥的手动安装流程以 Claude Code 为例网上教程很多但不少人卡在“装完不生效”。我这里给一套实测最稳的流程跟着走基本不会出问题。先确认你的 Claude Code 版本支持 Skills 功能老的版本没有这个目录。在项目终端里执行claude --version如果版本偏老先升级npm update -g anthropic-ai/claude-code装 Skills 的核心逻辑其实就三步把技能文件放到指定目录让 Claude Code 能扫描到然后验证加载。第一步进入项目目录创建技能文件夹cd your-project mkdir -p .claude/skills第二步把从 GitHub 上 clone 下来的技能文件放进去。大多数技能是一个文件夹结构大概长这样.claude/skills/ └── pdf-report-builder/ ├── SMITH.md └── scripts/ ├── build_pdf.py └── template.html第三步重启 Claude Code 会话然后在对话中直接输入技能名来触发。比如装了一个叫pdf-report-builder的技能你就可以说“使用 pdf-report-builder 帮我生成这周的数据周报”。如果配置正确Claude 会加载 SMITH.md 里的指令并按里面的流程执行。提示手动安装最容易踩的坑是目录层级放错。SMITH.md必须放在技能文件夹的根目录不能嵌套更深否则扫描不到。2.2 通过 Marketplace 和自动化工具安装手动 clone 适合技能数量少的时候一旦你开始囤十几个技能管理成本就上来了。这时候可以用社区里的技能市场方案。我常用的方式是找一个开源的 skills registry 仓库然后通过配置方式批量引入。以 Claude Code 为例现在比较流行的做法是在项目根目录放一个.claude/settings.json里面声明要加载的外部技能源{ skills: { sources: [ { name: community-skills, repo: https://github.com/your-favorite/skills-registry, path: skills } ] } }配置完之后Claude Code 启动时会自动从对应仓库拉取技能清单。不用手动逐个 clone也不用担心技能版本更新要重新覆盖。不过要说清楚这套机制现在各家还处于“各玩各的”阶段没有一个统一的“技能应用商店”。社区里常说的skills 网页版入口其实多半是指某个开源仓库的在线文档站把技能说明、预览、安装命令做成了网页本质还是指向 GitHub 仓库。所以你在网上看到“Skills 下载”这类词心里要有个底人家给的基本都是仓库地址不是像 App Store 那样的商业分发平台。2.3 安装后的验证与管理装完不要急着直接用先花一分钟验证技能是否真的被识别了。在 Claude Code 里输入/help或者直接问它“你现在加载了哪些技能”。如果列表里出现了刚装的那个技能说明加载成功。如果没出现大概率是目录层级或文件权限的问题下面第 5 节会细讲。管理上我有一条建议别把技能一股脑全塞进全局配置。Claude Code 支持全局技能目录和项目级技能目录全局放通用型技能比如代码审查、测试生成项目级放跟当前业务强绑定的技能比如这项目的部署规范、数据库表结构说明。这样切换项目时不会把无关技能带到上下文中能省不少上下文窗口。3. 从 0 到 1 写一个自己的 Skill3.1 技能开发的基本工程结构装别人写的技能只是第一步真正让 Skills 的价值翻倍的是自己写。因为只有你自己最清楚团队的业务流程长什么样通用技能解决不了你项目的独有问题。开发一个技能目录结构通常是这样my-custom-skill/ ├── SMITH.md // 技能的核心指令文件 ├── scripts/ // 实际执行的脚本 ├── assets/ // 模板、静态资源 └── config.json // 技能元信息可选SMITH.md是这个体系的灵魂。它命名来自“Skills Made Interactive for Task Handling”的缩写思路作用就是用结构化文本告诉模型你这个技能是干嘛的、什么时候该用、按什么步骤执行、需要哪些输入参数、输出格式是什么。3.2 写 SMITH.md 的实操技巧我拆一个实际项目里用过的技能片段这个技能是“生成前端发布检查清单”--- name: frontend-release-checklist description: 在前端发布前生成完整的上线检查清单包括构建检查、环境配置、兼容性验证。 when_to_use: 当你需要执行前端发布流程或审查发布准备情况时 --- # 前端发布检查技能 ## 输入 - 发布分支名 - 目标环境staging / production ## 执行步骤 1. 检查目标分支是否已合并最新主分支代码 2. 扫描项目构建配置确认生产环境 API 地址没有被替换为测试地址 3. 核对 CI 配置中的环境变量是否与目标环境匹配 4. 生成包含以下结构的检查清单 - 代码分支状态 - 构建结果 - 环境配置核对项 - 兼容性验证项Safari、Chrome、移动端 ## 输出格式 以 Markdown 表格输出检查项、状态说明、风险等级。写这种文件有几个关键经验第一description 要写得足够具体。这是模型判断“什么时候自动加载这个技能”的依据。你写“用于前端发布”模型可能在写业务代码时也加载它浪费上下文写成“在前端发布前生成检查清单”触发时机就准确多了。第二执行步骤要像菜谱一样细。不要让模型自己去发挥“该怎么检查”你得把检查点列清楚。模型不是不聪明是不知道你们项目的“约定”。第三输出格式必须明确。你要什么结构直接写在 SMITH.md 里。这是很多人容易忽略的地方我见过不少人写完技能发现 Claude 每次输出格式都不一样重新翻文档才想起来自己压根没规定输出格式。3.3 参数设计和上下文注入的几个坑写技能脚本的时候很多人会把所有逻辑塞进 SMITH.md 的步骤描述里这其实是低效的。更合理的做法是把执行逻辑写成脚本SMITH.md 只负责告诉模型“调哪个脚本、传什么参数”。比如我写过一个数据库备份的技能SMITH.md 里只写了这样一段## 执行步骤 1. 运行 scripts/backup.sh --db {database_name} --env {environment} 2. 等待脚本执行完成 3. 将备份结果汇总为文件路径、备份耗时、备份大小真正的备份逻辑全在backup.sh里面。这样做的优势很明显脚本逻辑可以单独测试不依赖模型生成代码的能力稳定性和可调试性都更强。参数设计上有几个高频失误我踩过之后总结成三条参数取值范围要在 SMITH.md 里写清楚。否则模型可能给你传一个根本不存在的环境名。不要把敏感信息直接写在技能文件里。数据库密码、API Key 不要硬编码用环境变量或者让模型在执行时从配置读取。上下文注入要注意体积。SMITH.md 越长每次加载消耗的 token 越多。保持精炼放“流程框架”而不是“完整手册”。细节放到脚本和 assets 里。4. 场景向技能推荐数学建模、前端开发、AI 漫剧都有好货4.1 比赛党的数学建模技能组合华为杯、国赛、美赛这类数学建模比赛是 Skills 应用最活跃的场景之一。为什么因为建模比赛的流程高度标准化读题、查文献、数据清洗、模型选择、求解、论文排版。这整个链路拆成技能之后效率提升非常明显。我推荐的组合是三件套数据预处理技能专门处理“脏数据”包括缺失值填充策略、异常值检测方法、数据标准化方式。数学建模比赛给的数据集往往需要大量清洗这个技能可以直接把常用 pandas 操作组合成标准化流程。模型适配技能输入问题特征回归/分类/优化输出候选模型和对应求解代码模板。它不替你决定用哪个模型但能给你一个从数据量、特征维度、精度要求出发的推荐逻辑。论文图表技能数学建模最烦人的是画图同一份数据要出散点图、热力图、残差图。技能里预设好 matplotlib 和 seaborn 的绘图模板统一风格和分辨率论文阶段能省一晚上的时间。4.2 前端开发者的效率型技能前端可能是 Skills 受益最直接的工种。日常开发里大量工作是重复劳动搭组件、写样式、调接口、修兼容性。我目前常用的前端技能有这几个组件生成技能输入组件需求描述输出完整的 TypeScript 组件文件包含 props 定义、样式模块、测试用例。接口对接技能根据 OpenAPI 文档自动生成类型定义和请求函数省去手写 interface 的过程。HTML 转模板技能把设计稿里的 HTML 结构转成项目里的模板文件自动套用项目现有的类名规范。这类技能的来源很丰富GitHub 上搜frontend skills或者web dev skills就能翻到不少。安装方式跟上面第 2 节完全一样没有特别的门槛。4.3 内容创作者与 AI 漫剧的技能流AI 漫剧这个方向最近很热热搜词里也出现了AI 漫剧常用 skills我研究过一段时间发现创作者们主要在用两类技能一类是分镜生成技能输入一段剧情文字输出分镜表包含镜头号、画面描述、景别、运镜方式。这背后通常接的是大模型 绘图模型的组合技能负责把剧情拆成绘图模型能理解的结构化描述。另一类是角色一致性技能AI 漫剧最大的痛点是角色在不同镜头里长相连贯性差。解决思路是在技能里固化角色特征描述的模板输出时自动带上统一的人物外貌设定词这样每个分镜的角色描述差异被压缩到最小。顺便说一句如果你看到网上有人卖“AI 漫剧全套技能包”先别急着付费。这类技能的技术含量不高核心通常就是几个写得很好的 SMITH.md 文件和提示词模板。你学会了本文第 3 节的开发方法完全可以自己攒一套。4.4 常用技能源站点汇总聊几个我自己会定期逛的技能源GitHub 上的 awesome-skills 类仓库搜索awesome claude skills或awesome codex skills会有不少人维护汇总列表质量参差不齐以“看 star 数 看最近更新时间”作为过滤条件。Hugging Face 上的 Agent Skills 板块Hugging Face 现在也支持发布技能标签过滤之后能看到不少人上传的成品技能好处是自带描述和测试用例适合学习别人怎么写。各工具官方文档的示例库Claude Code、Codex 的官方仓库里都有示例技能这些是质量最高的学习材料毕竟跟框架同步更新。注意下载技能时务必看一眼脚本内容再执行。社区技能鱼龙混杂有些脚本里写了奇怪的操作。安全底线是先读一遍 scripts 目录下的代码再决定要不要装。5. 常见问题与排查实录5.1 装完技能不生效从哪几个方向查这个问题遇到的人最多。技能文件放进去了但模型就是“看不到”。按顺序排查第一确认目录位置。Claude Code 扫描的是.claude/skills不是skills也不是.claude/skills/xxx/skills。我用树状图再看一次正确结构.claude/ └── skills/ └── skill-name/ ├── SMITH.md └── scripts/第二确认 SMITH.md 格式。用带有 frontmatter开头的---包裹块的写法里面至少要有name和description字段。只写正文没有元信息的文件模型没法识别触发条件。第三确认会话已重启。技能文件的加载发生在会话启动时不是对话中途实时扫描。改完文件记得重启 Claude Code 会话。第四确认技能没被全局配置禁用。有些版本支持在 settings 里配置禁用的技能列表检查一下配置里有没有写disabled: true。5.2 上下文窗口被技能塞满怎么办用了大量技能之后会遇到新的问题启动会话时模型加载了太多技能描述还没开始干活上下文窗口就被占掉一大截。尤其在 Claude Code 这类工具里每个技能被“看见”都会消耗 token。我的做法是控制技能可见性。全局配置里只保留 2 到 3 个真正每次都要用的技能其余放进项目级配置用到哪个项目才加载哪个。每次任务开始时明确告诉模型“请使用 xxx 技能完成任务”也能避免模型过度主动加载不相关的内容。上下文窗口管理的核心原则是技能是给特定场景准备的不是越多越好。很多人的技能库膨胀到几十个之后模型反而开始“糊涂”会自己判断错触发条件。定期做减法比做加法更重要。5.3 技能清理与卸载的正确姿势关于清理技能社区里有个叫tibo 分享的清理方法讨论度挺高核心思路跟我自己实践下来的结论一致先评估使用频率。连续两周没用过的技能考虑归档出全局配置。卸干净不留垃圾。删除技能文件夹之外还要检查 settings.json 里有没有残留的技能源配置否则下次启动时可能又自动拉回来。保留 SMITH.md清掉脚本。如果技能以后可能还要用但当前阶段用不上可以把 SMITH.md 留档删掉体积大的脚本和 assets节省磁盘空间的同时保留可恢复性。清完技能之后重启会话再跑一遍“你现在加载了哪些技能”验证一下确保没有残留项影响上下文。这步很多人会漏结果技能明明删了上下文还是被占用白白浪费不少 token。尽管理论上 Skills 能覆盖的场景很广但我个人还是建议从一个小切口开始。别一上来就追求“全家桶”先挑一个你每周都会遇到的重复性任务写一个技能跑通再用到顺手。这个流程走下来你对这套机制的理解会远远超过看十篇教程。我自己就是在写完第一个技能之后才真正意识到“给 AI 交代清楚流程”和“让 AI 自己发挥”之间差距有多大。另外一个小技巧写 SMITH.md 的时候把之前踩过的坑直接写进其中的“注意事项”部分。技能文件不光给模型看也是给未来的自己看的操作手册。这个习惯保持半年之后你再回来看会发现它比任何笔记软件都好用。