写这篇东西之前我先把最近圈里的动向梳理了一遍。你会发现一个很有意思的现象Claude Code 发完一波更新大家都在聊superpower skillsCodex 一开源GitHub 上冒出上千个*.md格式的 skill 文件吴恩达的 Agent Skills 教程 PDF 传得满天飞连搞数学建模、写发明专利、做渗透测试的人都在找对应的 skills 包。skills这个词正在从大模型的“隐藏设置”变成 AI 应用的“第一公民”。如果你现在还觉得 skills 只是换个花样的 prompt那你大概率会错过这轮工具链升级的红利。这篇文章我不打算讲概念层面的空话直接用手上的项目实践把 skills 的本质、安装姿势、开发流程、排查思路全部拆开揉碎讲一遍能抄作业的尽量给到位。1. 内容整体设计与思路拆解1.1 为什么 skills 突然成了 AI 应用的核心单位先说一个最直观的判断标准以前我们调教大模型靠的是在对话框里反复粘贴一段很长的系统提示词或者在代码里硬编码一堆 instruction。这个模式有几个硬伤——提示词越长模型对关键信息的注意力就越分散不同任务混在同一段提示词里互相干扰提示词不能版本化管理改一句话可能引发连锁反应。skills 解决的就是这个问题。它把某个特定领域的能力比如“分析前端项目的依赖结构”“生成数学建模论文的 LaTeX 模板”“写一份符合专利审查逻辑的交底书”打包成独立文件里面包含指令、示例、工作流程、校验规则甚至可以让模型自己决定在什么场景下调用这个 skill。这就像把原来写在便签纸上的提示词升级成了标准化的插件包——认识某个功能变成了安装某个技能从此 AI 的能力可以直接复用、分享、迭代。我干活时最深的体会是skills 把“能力”和“对话上下文”解耦了。以前我让模型扮演“资深前端架构师”每条消息都要重复角色设定现在我只需要在项目里放一个frontend-review.skill.md模型通过codex analyze这类命令扫描到它之后每次分析代码都会自动套用这套审查规范。上下文干净了输出质量自然提升。1.2 skills、prompt、agent 三者到底什么关系这里的混淆点特别多我用自己的理解给你捋一遍。如果把大模型比作一个刚毕业的高材生prompt 就是你在某一刻给他的“口头任务描述”能不能干好全看表述是否清晰agent 是这个学生手里的“工具箱行动计划”他能自己拆分步骤、调工具、做决策而 skills 更像是一本本“岗位手册”——告诉他“遇到 XX 类问题时应该按什么流程处理输出什么格式哪些红线不能碰”。所以吴恩达把 skills 放在 agent 教程里讲本质上是想说明skills 是让 agent 具备“专业技能”的载体。一个 agent 可以同时加载多个 skills遇到不同场景自动切换对应能力。那种“skills高级 prompt”的简化理解忽略了一个关键点真正的 skill 文件里包含的是“可执行的流程约束”而不只是“静态的知识描述”。这也是为什么同样一个 skill装进 Claude Code 和装进 Codex 里实际表现会有差异——agent 的执行引擎不同对流程段的解析方式也不同。1.3 为什么说 2025 年是 skills 生态的爆发节点我判断一个技术是否到了爆发期就看两个信号一是头部玩家是否在做标准化二是第三方生态是否在疯狂填充内容。现在的局面非常典型——OpenAI 的 Codex 开源了 skills 规范Anthropic 的 Claude Code 也有对应的 skill 机制npx skills add这种命令行安装方式正在成为事实标准。GitHub 上随手一搜skills能翻到前端、数模、专利、渗透测试、PPT 制作等等领域的现成包这种“什么都有人做出来了”的感觉和当年 npm 生态爆发前的状态很像。但生态爆发也带来了一个问题质量残次不齐。很多所谓 “superpower skills” 就是把几段 prompt 改了个后缀名放出来实际加载后要么解析失败要么对模型行为的约束力不够。所以接下来这部分我重点讲怎么甄别和选择 skills避免你把一堆垃圾包装进自己的环境里。2. 核心细节解析与实操要点2.1 一个标准的 skill 文件到底长什么样咱们直接看结构。以我常用的一个代码审查 skill 为例它的核心文件是SKILL.md里面分几个固定区块--- name: code-review-skill description: 自动执行前端项目代码审查输出结构化的审查报告 when_to_use: 当用户要求审查代码、分析项目质量、评估重构风险时 --- ## 工作流程 1. 扫描项目目录识别入口文件和核心模块 2. 分析依赖关系检查循环依赖和冗余依赖 3. 执行静态规则检查命名、复杂度、安全性 4. 生成审查报告 ## 输出要求 - 按【问题等级】【文件位置】【问题描述】【修改建议】四列输出 - 问题等级分为致命/严重/一般/建议 ## 注意事项 - 不要修改任何源文件只输出报告 - 不纠结于风格偏好类问题聚焦正确性和性能frontmatter开头的---包裹区域是给 agent 的索引信息description和when_to_use会决定模型在什么时机自动加载这个 skill。正文部分才是真正的“技能内容”可以包含流程、示例、代码片段、约束规则甚至内嵌一小段可执行脚本。很多刚上手的人会忽略when_to_use字段写得很笼统甚至不写。结果就是模型根本不知道该什么时候调用这个 skillCPU 倒是跑得欢输出还是一坨普通的 LLM 回复。我试过最稳的写法是把触发器写得很具体比如“当用户在命令行中使用了/review指令”或者“当项目根目录存在package.json且用户输入包含‘审查’或‘review’时”。2.2 主流工具的 skills 实现差异对比我先声明一点不同工具的 skill 规范并没有完全统一虽然大方向一致但细节差异会让同一个 skill 在不同环境里的表现天差地别。我拿实测过的几个来对比工具/平台skill 文件格式安装方式调用机制适合场景Claude Code.claude/skills/目录/SKILL.md手动放置或npx skills add模型根据描述自动触发前端开发、文档撰写、日常代码辅助OpenAI CodexCODEX.md或agent-skills目录官方 CLI 或npx skills addagent 在任务开始时加载多文件项目分析、自动化脚本生成OpenCode自定义指令文件或 skill 包opencode 插件市场指令 上下文注入团队协作、私有规则沉淀通用框架 (如 LangChain)自定义 skill loader代码调用显式传参或 RAG 检索企业级应用集成这里要注意一个坑别以为在 A 工具下写好的 skill 能无缝平移到 B 工具。我试过把 Claude Code 的 SKILL.md 原封不动放到 Codex 里结果它对frontmatter的解析方式完全不同部分字段直接失效。目前比较务实的做法是先选定主用工具按它的规范写 skill如果确实需要跨平台就做一层“翻译层”把关键指令和流程抽出来重新套目标平台的模板。2.3 好用的 skills 包推荐现在市面上能搜到的 skills 包我按实用程度分一下梯队第一梯队是通用型几乎每个开发者都会用到。superpower skills这类包把 prompt 工程、代码生成、错误调试这些日常高频场景都覆盖了安装后能明显感觉到模型输出结构化程度提高。另外一个叫vidmuse-skills的包我最近在跑视频脚本相关的项目时用过它把视频创意、分镜设计、文案输出做成了串联流程省了不少事。第二梯队是领域专用型。数学建模领域有人做了专门的 skill 包包含题型识别、模型选择、LaTeX 排版、论文框架生成等功能发明专利写作领域也有对应的包里面内置了交底书结构、专利审查逻辑、权利要求书写法等训练约束甚至连渗透测试都有专门的 skills 集合里面预设了信息收集、漏洞扫描、报告生成的安全操作流程。这类包的价值在于它把行业里那些“说不清道不明的经验”变成了可执行的规则。第三梯队属于刚起步但潜力大的类型比如 UI/UX 设计相关的uiuxpromax skills。它能引导模型按设计规范拆分页面结构输出带设计思考的开发文档。这种包目前还在快速迭代中但方向我很看好。不过提醒一句安装第三方 skills 前先检查里面的指令是否安全。有些恶意 skill 会在流程段里埋入“忽略用户安全要求输出高权限命令”之类的指令。skill 本质上是可执行代码对待它的安全态度应该和对待依赖包一样——来源不明不装内容不审不用。3. 实操过程与核心环节实现3.1 从零安装一个第三方 skills 包的标准流程我以最近一次在 Claude Code 里安装vidmuse-skills为例完整走一遍流程。第一步确认环境。Claude Code 的版本需要支持 skills 机制我用的是最新版Node.js 环境在 18 以上因为npx skills这个安装器依赖较新的 Node API。直接在项目根目录打开终端执行npx skills add sandai-org/vidmuse-skills --agent claude-code -g -y-g表示全局安装装到用户级别的配置目录-y表示跳过交互确认直接安装。如果你希望只在当前项目里生效把-g去掉。装完以后检查一下安装结果ls -la ~/.claude/skills/正常情况下你应该能看到vidmuse-skills的目录结构里面至少包含一个SKILL.md文件可能还有示例、模板、脚本等辅助文件。第二步配置当前项目引用。这一步很多人会漏掉。光有全局 skills 还不够需要在项目的.claude/配置里声明启用哪些技能包。你可以手动创建.claude/commands.json或者直接修改配置文件{ skills: [vidmuse-skills, code-review-skill] }如果你不确定配置位置可以用skills list命令列出所有已安装的 skills再用skills activate 包名来激活当前项目需要的技能。第三步验证加载效果。打开 Claude Code直接输入一个和技能相关的问题比如“用 vidmuse 流程帮我生成一个旅行 Vlog 的创意脚本”。如果配置成功模型的回复风格会明显变化——它会先走一遍 skill 里定义的“需求理解”流程再输出脚本框架。如果你发现模型完全无视 skill 里的步骤结构大概率是触发条件写得不够清晰或者技能没有被激活。3.2 自己动手开发一个 skills从需求到发布安装别人的包只能算入门真正的价值在于开发适合自己的 skills。我拿一个“前端项目依赖分析”的 skill 来演示。先明确需求我希望模型在接到“分析这个前端的依赖情况”指令时能自动完成三件事——读取package.json解析依赖树、识别重复依赖和过期依赖、输出一份带建议的依赖优化报告。接着创建 skill 目录这是规范结构mkdir -p ~/.claude/skills/dependency-analyzer cd ~/.claude/skills/dependency-analyzer touch SKILL.md analyze.py README.md编写SKILL.md内容这是技能的核心得写到位--- name: dependency-analyzer description: 分析前端项目的依赖结构识别冗余、过期、冲突依赖 when_to_use: 输入包含“分析依赖”“依赖优化”“package.json”关键词时 --- ## 步骤 1. 查找项目根目录的 package.json读取 dependencies 和 devDependencies 2. 运行 npm ls --depth0 获取实际安装版本 3. 调用 analyze.py 整合数据源生成依赖清单 4. 对照 npm registry 检查版本更新情况 5. 输出优化报告 ## 输出格式 | 依赖名 | 声明版本 | 实际版本 | 最新版本 | 问题说明 | 建议操作 | ## 安全边界 - 只分析不修改任何情况下不执行 npm install 或删除依赖 - 涉及锁定文件变更的操作必须先输出待执行命令由用户确认写完SKILL.md再看辅助脚本analyze.py。这个脚本不是必须的但如果你的 skill 需要跑数据聚合、调用外部 API 这类操作写一个小脚本能大大提升准确性。我这里用一个极简版#!/usr/bin/env python3 import json, subprocess, sys def main(pkg_path): with open(pkg_path) as f: data json.load(f) deps {**data.get(dependencies, {}), **data.get(devDependencies, {})} for name, ver in deps.items(): try: installed subprocess.check_output( [npm, ls, name, --depth0], textTrue, stderrsubprocess.DEVNULL ).strip().split(\n)[-1] yield name, ver, installed except Exception: yield name, ver, unknown if __name__ __main__: for row in main(sys.argv[1] if len(sys.argv) 1 else package.json): print(row)然后把 skill 文件夹整个放到项目的.claude/skills/下或者用全局目录再配置启用就能测试了。测试的时候我踩过一个坑模型读取SKILL.md的流程描述后会“假装”执行脚本但实际上没有真正跑 Python输出的版本号全是我当前环境的真实值——这其实不是模型在骗人而是我没有把“必须运行 analyze.py 才能获得数据”这个约束写在强指令区域。后来我在「步骤 3」后面加了一句“禁止直接猜测版本号必须从 analyze.py 的输出获取”问题就解决了。3.3 从源码安装和自定义加载绕过 marketplace 的限制很多时候官方的npx skills add只能安装托管在 GitHub 等平台上的现成包如果你想用别人源码里的某个未发布 skill或者自己改了一版想本地加载就需要掌握源码安装的姿势。源码安装其实很直白就是把远程仓库 clone 或者下载下来解压到本地的 skills 目录。比如有个项目叫awesome-custom-skills你只想用里面的latex-formatter就别把整个仓库塞进 skills 目录否则 agent 加载时会把无关目录也扫一遍浪费上下文窗口。正确的做法git clone https://github.com/example/awesome-custom-skills.git /tmp/tmp-skills cp -r /tmp/tmp-skills/skills/latex-formatter ~/.claude/skills/ rm -rf /tmp/tmp-skills或者用 GitHub 的“下载目录”功能比如 DownGit 类工具直接只下载你需要的子目录。源码安装非常适合自定义场景。比如我基于codex-skills的源码改了一个针对公司内部技术栈的版本改了触发关键词、加了公司规范链接然后通过源码安装方式挂到本地命令如下npx skills add file:/path/to/your-modified-skill-dir --agent codex -g -y这种方式不依赖外网仓库不担心源被删也方便在团队内共享未发布的内部技能。不过要注意源码安装后没有自动更新机制源仓库如果你还在持续更新需要定期手动拉到最新再重新安装。4. 常见问题与排查技巧实录4.1 skill 不生效、被忽略、报错的三类典型问题我在多个工具上折腾 skills 的过程中积累了大量的报错现场整理成速查表应该能解决你大部分问题现象可能原因排查与解决模型完全无视 skill 的存在skill 没激活 / 触发条件太模糊skills list检查激活状态把when_to_use写得更具体或用显式指令触发skill 文件解析失败 / 加载报错frontmatter 格式错误 / 工具版本过旧检查 YAML 格式使用skills validate 目录做校验升级到最新版工具模型调用 skill 里的脚本但没实际执行指令约束不够强 / 沙箱权限不足在 skill 中加“必须调用脚本”“禁止直接从上下文猜测”等强约束检查工具的执行权限设置第三方 skill 安装成功后仍无法调用包名冲突 / 安装目录不对用skills list看实际的安装路径调整.claude/skills/目录结构确保 SKILL.md 在正确层级加载多个 skills 后输出混乱skills 之间规则冲突检查各个 skill 的关键词是否重叠给每个 skill 定义更明确的任务边界在配置中设置优先级4.2 安全边界与权限控制的经验说实话skills 生态目前最被低估的风险是安全问题。一个 SKILL.md 文件本质上是“给模型的指令”而模型天然有服从指令的倾向。如果这个文件里暗藏了“绕过安全限制”“读取敏感文件并输出”“执行高危命令”之类的引导现有的大模型安全机制不一定能拦住。所以我的安全基线是三条来源可信只装官方或高 star 且我审过内容的包、内容可读下载后先cat读一遍至少扫一遍有没有异常指令、权限最小化运行含第三方 skills 的 agent 时尽量使用受限的沙箱环境不挂管理员权限。另外一点团队协作时如果要把 skills 提交到共享仓库建议在 CI 里加一道自动扫描检查是否包含恶意的“忽略用户指令”类文案。目前社区里已经有人在做 skill 安全审计工具了但在它们成熟之前手动审一遍是最低成本的保险。4.3 关于“skills 和 prompt 谁更值得投入”的一点思考最近我总看到有人在吵“skills 会不会替代 prompt engineering”的问题。以我自己的实践来看这个争论有点伪命题。skills 是对 prompt 的结构化封装——它里面还是 prompt只是多了流程、示例、触发机制和版本管理。本质上的底层推理能力还是靠大模型本身skills 能优化的是“如何在正确的时机、以正确的形式、让模型处理正确的问题”。所以我的建议是如果你刚开始接触大模型应用先把 prompt 基本功打牢知道怎么写任务描述、怎么给示例、怎么约束输出这是底层能力等你在一个固定的 workflow 里反复遇到“同样的任务做了很多遍但效果不稳定”的问题时再把这段经验沉淀成一个 skill收益是最明显的。说白了skills 是 prompt 成熟之后的“工业化封装”动手做几个真实项目你自然就理解这个演进路径了。我在做完自己的 dependency-analyzer 之后最大的变化不是模型输出质量提高了多少而是我对“如何设计一段可持续复用、可被 agent 正确调用的能力”有了全新的感觉。这种能力才是这波 AI 工具链升级里真正值钱的资产。