1. 从skills这个模糊词说起它到底指什么第一次看到skills这个标题很多人会一头雾水。它太宽泛了宽泛到像是随手敲下的一个占位符。但结合热搜词里高频出现的 Claude、Agent Skills、SKILL.md、Claude Code 这些词方向其实很明确——这里说的 skills指的是围绕 AI 编程助手尤其是 Claude Code 这类命令行/桌面工具构建的技能包体系也就是用一份结构化的 SKILL.md 文件把某类任务的处理逻辑、工具调用方式、输出规范固化下来让 AI 在遇到对应场景时能按预设套路干活。说白了skills 就是给 AI 助手准备的操作手册合集。你平时让 AI 帮你写代码、做数学建模、生成漫剧脚本、处理 STM32 嵌入式任务每次都要重新解释一遍背景、格式、注意事项累不累skills 的思路就是把这些重复性的交代沉淀成文件一次写好反复调用。它解决的核心问题是让 AI 从每次都要从头教变成装好技能就能直接上手。这套东西适合谁三类人最该关注。第一类是天天用 Claude Code、Codex 这类工具写代码的开发者skills 能显著减少重复沟通成本第二类是做数学建模、数据分析的科研党热搜里华为杯建模比赛好用的 codex skills数学建模 skills 推荐就是明证第三类是做 AI 内容创作的人比如AI 漫剧常用 skills这类需求本质是把创作流程模板化。需要先厘清一个概念边界skills 不是插件不是模型微调也不是什么神秘的黑科技。它更像是一份约定俗成的提示词工程产物——用 Markdown 写清楚什么时候用我、我该怎么干、干完输出什么然后放到 AI 工具能读取的目录里。理解这一点后面所有的安装、编写、调试就都有了落脚点。2. SKILL.md 的骨架一份技能文件该长什么样2.1 为什么是 Markdown 而不是 JSON 或 YAML很多人第一反应会问既然是给机器读的配置为什么不用 JSON答案在于 skills 的使用场景。它需要被人频繁阅读、修改、分享而 Markdown 在可读性上碾压结构化数据格式。你打开一份 SKILL.md能一眼看懂这个技能干什么、怎么触发、有哪些注意事项换成 JSON满屏括号和引号改一个字段都提心吊胆。另一个原因是 AI 模型对 Markdown 的解析能力天然更强。训练语料里 Markdown 占比极高模型对标题层级、列表、代码块的理解非常成熟。用 Markdown 写技能描述等于顺着模型的母语说话触发准确率和执行质量都会更好。2.2 一份可用的 SKILL.md 包含哪些字段根据社区里流传的各类 skills 实践一份能跑起来的技能文件通常包含这几块区块作用是否必需技能名称与描述告诉 AI 这个技能是干什么的必需触发条件什么情况下该调用这个技能必需执行步骤具体怎么操作分几步必需输入输出规范需要什么参数产出什么格式建议注意事项容易踩的坑、边界情况建议示例一两个真实调用例子强烈建议描述部分要短而准。我见过有人把描述写成三百字的小作文结果 AI 反而抓不住重点。正确做法是用一句话说清这个技能解决什么问题比如将用户提供的原始数据整理成符合华为杯建模论文格式的图表和文字说明。触发条件是新手最容易忽略的部分。你不写清楚什么时候用AI 要么该用的时候不用要么不该用的时候乱用。写法上可以用当用户提到 X、Y、Z 时这种自然语言描述不需要什么特殊语法。2.3 描述字段的写法直接决定触发率这里展开讲一个实操心得。触发率低是 skills 使用中最常见的问题十有八九出在描述字段上。我的经验是描述里要包含用户可能说的原话。比如你做一个清理 skills的技能描述里就该出现清理删除移除整理这些用户真会打的词而不是只写对技能库进行维护操作这种书面语。还有一个技巧是把技能名起得具体一点。data-helper这种名字太泛AI 很难判断该不该用math-modeling-chart-formatter就明确多了。名字本身就是触发信号的一部分。3. 把 skills 装进 Claude Code路径、命令与常见报错3.1 技能目录到底放在哪Claude Code 读取 skills 的位置不同版本、不同平台略有差异但核心逻辑一致放在工具能扫描到的技能目录下。常见做法是在用户主目录下建一个专门的 skills 文件夹每个技能一个子目录子目录里放 SKILL.md。结构大概是这样~/.claude/skills/ ├── math-modeling/ │ └── SKILL.md ├── ai-comic/ │ └── SKILL.md └── stm32-helper/ └── SKILL.md注意目录名和技能名不必完全一致但建议保持一致方便你自己管理。子目录里除了 SKILL.md还可以放辅助脚本、模板文件技能执行时可以引用。3.2 手动安装 GitHub 上的 skills热搜里claude code 怎么手动装 github 上的 skills是个高频问题。流程其实不复杂找到目标 skills 仓库确认里面有 SKILL.md 文件把整个技能目录克隆或下载到本地复制到你的 skills 目录下重启 Claude Code 或重新加载让工具重新扫描用命令表达就是git clone https://github.com/某仓库/某技能.git cp -r 某技能 ~/.claude/skills/Windows 用户把路径换成对应的用户目录即可。复制完记得检查一下 SKILL.md 的编码有些仓库用 UTF-8 with BOM个别工具读起来会出问题用编辑器转成纯 UTF-8 更稳妥。3.3 那些让人抓狂的报错怎么破claude : 无法将claude项识别为 cmdlet、函数、脚本文件或可运行程序的名称——这个报错在 Windows 上极其常见本质是环境变量没配好。Claude Code 的可执行文件路径没加进 PATH系统自然找不到。解决办法是把安装目录加进系统环境变量或者用完整路径调用。claudes workspace requires the virtual machine platform on windows. enable——这个提示指向 Windows 的虚拟机平台功能没开启。按系统提示在启用或关闭 Windows 功能里勾选对应项重启即可。这不是 skills 本身的问题是运行环境的前置依赖。note: claude code might not be available in your country——遇到这类地域提示说明当前网络环境或账号区域不匹配。这类问题涉及具体环境配置建议查阅工具官方文档了解支持范围本文不展开。3.4 安装后的验证动作装完 skills 别急着用先做一次验证。最直接的办法是在对话里问 AI你现在有哪些可用技能看它能不能列出你刚装的。如果列不出来检查三件事目录层级对不对、SKILL.md 文件名大小写对不对、文件内容有没有语法错误导致解析失败。我踩过的一个坑是技能目录嵌套太深工具只扫描一层子目录结果放在两层下面的技能死活加载不出来。后来统一改成一层结构问题消失。这个细节官方文档不一定写但实际用起来很关键。4. 从零写一个自己的 skill以数学建模场景为例4.1 先想清楚这个技能替我省了什么写 skill 之前先回答一个问题这个技能存在的意义是什么如果只是把一句话的指令固化下来不值得写。真正值得做成 skill 的是那些步骤多、格式要求严、每次都要重复交代的任务。数学建模就是典型。一次完整的建模任务涉及理解题目、选模型、写代码求解、生成图表、按论文格式组织文字。每次都要跟 AI 重复图表要带标题公式要用 LaTeX结论要分点写烦不胜烦。把这些固化成一个 skill后面直接调用效率提升非常明显。4.2 把流程拆成 AI 能执行的步骤拆步骤的原则是每一步都要是可验证的动作而不是模糊的期望。对比一下模糊写法对数据进行合理分析可执行写法读取用户提供的 CSV 文件计算各列均值、方差、缺失值比例输出为 Markdown 表格后者 AI 一看就知道干什么前者它只能猜。写 skill 时尽量往后者靠。一个数学建模 skill 的步骤骨架可以是读取题目描述提取关键约束条件根据问题类型推荐 2-3 个候选模型说明各自适用场景针对选定模型生成求解代码标注依赖库运行代码并输出结果生成可视化图表按论文格式组织文字说明公式用 LaTeX4.3 输入输出规范怎么写才不歧义输入规范要明确用户需要提供什么。比如数学建模 skill 可以要求用户提供题目原文、数据文件路径、期望的输出格式。输出规范要明确产出长什么样是 Markdown、是代码文件、还是两者都要。这里有个实用技巧在输出规范里给出一个最小示例。比如输出格式参考先一段 200 字的问题分析再一个模型选择表格最后附求解代码。有了示例AI 的输出稳定性会高很多。4.4 注意事项区块是经验的沉淀池这个区块最容易被忽略但恰恰是 skill 价值最高的地方。把你踩过的坑写进去数据缺失怎么处理、模型不收敛怎么办、图表中文乱码怎么解决。这些是通用文档里不会写、只有实操过才知道的东西。比如我会在数学建模 skill 的注意事项里写如果数据量超过十万行优先用向量化操作而非循环否则求解时间会爆炸Matplotlib 默认字体不支持中文需提前设置字体参数。这类提示能让 AI 少走很多弯路。5. 技能库的维护清理、分类与版本管理5.1 技能装多了为什么会变慢变乱skills 不是越多越好。装到几十个之后会出现两个问题一是 AI 在触发判断上容易混淆两个技能描述相近时可能选错二是加载和扫描本身有开销技能库臃肿会拖慢响应。热搜里tibo 关于清理 skills 的方法推荐能火说明这是普遍痛点。清理的核心思路是按使用频率分层。高频技能常驻低频技能归档到单独目录需要时再移回来。5.2 一套可操作的清理流程我自己的清理流程是这样的列出所有已装技能标注最近一次使用时间超过一个月没用过的移到 archive 目录功能重叠的合并成一个描述模糊、触发率低的要么重写描述要么删掉执行时可以用简单的脚本辅助# 列出所有技能目录 ls ~/.claude/skills/ # 查看某个技能的最后修改时间 stat ~/.claude/skills/某技能/SKILL.md定期清理一次技能库保持在三四十个以内用起来最舒服。5.3 分类与命名约定分类方式因人而异但命名约定值得统一。我的习惯是领域-功能两段式比如math-modeling-chart、ai-comic-script、stm32-codegen。这样一眼能看出技能归属排序时同领域的也会聚在一起。版本管理方面如果技能是自己写的建议用 Git 管理起来。改坏了能回滚换设备能同步。社区里分享的 skills 仓库大多也是这么做的。6. 跨工具使用skills 在 Codex、OpenCode 等场景的差异6.1 不同工具对 skills 的支持程度skills 这个概念不是 Claude Code 独有的。热搜里出现的 Codex、OpenCode 也都有类似机制。差异主要在读取路径、文件命名、触发方式上。有的工具认 SKILL.md有的认别的文件名有的自动扫描目录有的需要手动注册。跨工具使用的策略是把技能内容写成工具无关的纯 Markdown然后针对不同工具做一层薄薄的适配。核心逻辑不变只改触发和加载部分。6.2 数学建模、AI 漫剧等垂直场景的适配垂直场景的 skills 适配重点在输出格式。数学建模要的是论文格式AI 漫剧要的是分镜脚本格式STM32 要的是寄存器配置和代码。这些格式要求写进 skill 的输出规范里换工具时基本不用改。热搜里华为杯建模比赛好用的 codex skillsAI 漫剧常用 skills反映的正是这种垂直需求。通用技能解决不了领域特有的格式和流程问题必须针对性编写。6.3 接入不同模型时的注意事项有些用户会把 Claude Code 接入其他模型使用。这种情况下skills 的触发效果会受模型能力影响。能力强的模型对描述的理解更准能力弱的可能需要把触发条件写得更直白。我的建议是换模型后重新测一遍触发率别想当然认为原来的 skill 还能照常工作。7. 让技能真正好用的几个实操心得7.1 描述要像用户说话不要像文档这一点前面提过但值得再强调。技能描述是给 AI 看的触发信号而 AI 判断该不该用时参考的是用户的实际表达。所以描述里要埋用户会说的词而不是你作为作者觉得专业的词。写完可以自己念一遍像不像人话。7.2 一个技能只干一件事贪多是大忌。有人想用一个 skill 覆盖整个建模流程结果步骤写了二十条AI 执行到一半就乱了。正确做法是拆成多个小技能各管一段需要时组合调用。单一职责原则在 skills 编写上同样适用。7.3 定期用真实任务回归测试技能写完不是终点。隔一段时间拿真实任务跑一遍看触发准不准、输出对不对。模型在更新你的使用习惯也在变技能需要跟着调整。我一般每个月抽几个常用技能做一次回归发现触发率下降就重写描述。7.4 分享与复用站在别人的肩膀上社区里已经有不少现成的 skills 仓库热搜里skills 技能库网址typesafe ai skills github就是大家在找资源。与其从零写不如先找现成的改。改的时候注意看许可证尊重原作者。自己写的技能如果通用性好也可以分享出去。分享时把 SKILL.md 写清楚附上使用示例别人接手成本低反馈也会更有价值。7.5 别把 skills 当银弹最后说句实在话。skills 能提升效率但它解决不了模型本身的能力边界问题。任务太复杂、需求太模糊时再好的 skill 也救不了。它的定位是把重复劳动标准化而不是让 AI 无所不能。想清楚这一点用起来心态会稳很多。我在实际使用中最大的体会是skills 的价值不在于数量而在于那几个真正贴合自己工作流的技能。与其装一百个用不上的不如精心打磨十个天天用的。这个道理装得越多越明白。