拓冰网站定制 
先聊个事儿如果你最近刷 X、逛 GitHub Trending一定被一个词刷屏了——skills。前端开发有 skillsClaude Code 能装 GitHub 上的 skillsOpenCode 在搞 skills数学建模比赛有人用 codex skills 拿奖AI 漫剧创作者靠 skills 批量出片。这个原本平淡的英文单词在 2025 年成了 AI 编程圈最火的“包”概念。我电脑里现在躺着十几个 skills从写周报到读论文、从调参 bug 到画架构图日常的 AI 协作效率大概提了有三四倍今天就把我攒下的这套经验完整拆给你。这篇内容会覆盖 skills 的底层逻辑、主流工具Claude Code / Codex / OpenCode的安装玩法、如何手写一个属于自己的 skill、有哪些现成技能库值得收藏以及我踩过的坑和清理方法。不管你是刚接触 AI 编程工具的新手还是已经在用但想搞懂“技能到底怎么武装”的老手这篇应该都能给你点实在的参考。1. skills 到底是什么从提示词到“可复用技能包”1.1 skills 解决的第一个痛点每次都在重复教 AI先说个我自己的真实经历。2024 年底我用 Claude Code 写项目每开一个新仓库都要在对话里花十几分钟重新“调教”模型你该怎么读这个项目、遇到报错怎么处理、测试要写到什么程度、代码风格偏好是什么。好不容易这套话术跑顺了换个项目全得重来。这种重复劳动特别折磨人而且每次复述都会有信息损耗——今天忘了说“不要改测试文件”明天忘了提“提交前先跑 lint”结果就是模型时不时给你搞出点“蠢操作”。后来我看到 Anthropic 官方推了 Agent Skills 的概念一下就通了skill 就是把“如何完成某类任务”的完整经验封装成一个可复用、可分享、可版本化的文件包。它跟提示词的本质区别在于提示词是每次对话临时打的草稿skill 是沉淀下来的标准作业程序。你不需要再给 AI 讲一遍该怎么做事只要说一句“用一下我的 code-review skill”它就知道按什么步骤、看哪些点、以什么格式输出审查结论。用生活化一点的类比提示词相当于你每次请一个新来的实习生都得从“怎么用复印机”开始教而 skill 相当于给这个实习生一份岗位手册他翻开就知道流程和标准。前者是每换一个人重新教后者是一劳永逸地沉淀经验。1.2 skills 的“技能包”结构为什么它比提示词更靠谱真正用过之后你会发现skill 不是简单把提示词换个后缀名而是一整套结构化资产。一个规范的 skill 通常包含三个部分SKILL.md 主文件定义这个技能的用途、适用场景、执行步骤、输出规范是整个技能包的大脑。脚本与工具代码比如 Python / Shell 脚本机器能执行的动作交给脚本模型负责调度和判断人机互补。参考资料与模板比如领域知识文档、输出模板、示例样本给模型“现成的答案素材”减少从零生成的不确定性。这种结构与纯文本提示词相比最大的优势是可编程性。模型在运行 skill 时不只是读一段文字然后照做而是可以调用脚本、解析文件、生成结构化输出。相当于你把“怎么做这件事”的每个环节都拆开、编码、固化AI 干起活来像是用规范工具而非靠聊天直觉。这个设计直接影响了后来所有 AI 编程工具的演进方向。Claude Code 在 2025 年把 skills 作为核心特性之一OpenAI 的 Codex 也加入了基于 AGENTS.md 的技能机制而开源生态里 OpenCode、Cline 等工具则各自实现了兼容或扩展方案。可以说skills 已经不只是提示词工程的花式玩法而是成了 AI 协作工作流的基础设施。2. 主流 AI 编程工具的 skills 支持现状选型2.1 四款主流工具横向对比我实际用过的、对 skills 支持比较成熟的有四款Claude Code、CodexOpenAI、OpenCode、Cline。这四款各有各的设计思路放个对照表让你一眼看明白差异。工具技能格式存放位置加载方式我的使用评价Claude CodeAgent Skills 官方格式SKILL.md 资源~/.claude/skills/或项目.claude/skills/关键词自动触发或/skills手动调用最成熟稳定生态最丰富我的主力CodexOpenAIAGENTS.md 驱动 prompt 约定项目根目录AGENTS.md项目级自动加载跟“代码补全”场景绑定较深适合仓库级约束OpenCode兼容多种格式含 SKILL.md项目.opencode/skills/等配置声明 自动发现开源灵活适合爱折腾的人Cline自定义规则文件 插件化插件市场 / 项目规则文件插件安装后按规则运行更像是“规则包”还没到完全体技能库先说结论如果只选一个工具深度玩 skills我推荐 Claude Code。原因不复杂——它的 skills 机制设计得最完整、文档最清晰、社区沉淀的现成技能最多而且~/.claude/skills/的全局目录设计让跨项目复用变得极其自然。但这不代表其他工具不值得了解因为技能生态正在快速融合很多 skills 格式也开始互相兼容。2.2 各工具的安装与管理差异安装体验上这四款差别还挺大值得单独说说。Claude Code 装一个 skill 最简单粗暴的方式就是把仓库克隆到~/.claude/skills/目录下一个子目录就是一个技能。比如你把skill-name这个仓库克隆到~/.claude/skills/skill-name然后在对话里提起相关需求模型就会自动去读 SKILL.md 并按流程执行。手动控制的话配置里加一个allowedSkills声明即可。Codex 的做法不太一样它更强调“项目级约束”。你需要在项目根目录维护一份AGENTS.md里面写清楚当前项目的技术栈、目录结构、编码规范、常用命令。Codex 每次启动都会自动加载这份文件相当于给模型装了一个“裸机环境驱动”。想更新技能就直接改文件不用重装什么包。OpenCode 是最有野心的一个它的 skills 系统允许你挂载多种格式本地目录、远程 Git 仓库、甚至 npm 包里的内置技能。安装时改一个opencode.json配置文件就可以。这个灵活性对进阶玩家很友好但对新手来说配置项有点多容易踩坑。Cline 目前更像“规则包 插件”的混合体它有一些内置的插件市场也支持你自己写.clinerules文件。跟前面几款比Cline 的技能生态还没那么丰富但如果你本身主力工具就是 Cline它的规则文件依然能覆盖大部分“固化流程”的需求。3. 手把手实操如何安装和使用 GitHub 上的 skills3.1 快速安装克隆命令与目录结构无论你用哪款工具从 GitHub 装 skills 的底层逻辑基本一致把远程仓库拉到本地指定目录让工具能发现并使用它。我以 Claude Code 为例给出一套最通用、最不容易出错的完整流程。# 1. 确保技能目录存在 mkdir -p ~/.claude/skills # 2. 克隆你找到的技能仓库示例为超级技能合集包 git clone https://github.com/superpowerlabs/superpower-skills.git ~/.claude/skills/superpower-skills # 3. 查看是否安装成功应能看到 SKILL.md 文件 ls ~/.claude/skills/superpower-skills装完不是就完事了你需要在 Claude Code 的配置里确认是否允许这个技能被加载。打开工具设置找到allowedSkills相关配置把技能名加进去。现在这个工具就可以在对话里自动识别相关任务并加载技能了。Codex 的安装思路是“无全局目录”模式更简洁——直接把 AGENTS.md 放到你的项目根目录即可# 把下载的 AGENTS.md 放到项目根目录 curl -o AGENTS.md https://raw.githubusercontent.com/xxx/awesome-codex/main/AGENTS.md # 验证 cat AGENTS.mdOpenCode 的配置方式稍微绕一点但它支持远程技能库这一点我特别喜欢。在opencode.json里声明一个技能{ skills: { my-skill: { path: ~/.opencode/skills/my-skill, enabled: true } } }也可以直接用 CLIopencode skills install github-username/repo-name3.2 superpower skills 这类“聚合包”到底装不装现在 GitHub 上有很多所谓的“超级技能包”最出名的就是 superpower-skills宣称包含了几十个实用技能。这类包我的态度是可以装但别无脑用。聚合包的优点是省事——克隆下来就有一堆技能而且能启发你对“原来这也算一个技能”的认知。缺点是很多技能质量良莠不齐有的跟你的工作流根本不匹配还有些技能之间会有指令冲突挂在~/.claude/skills/下反而增加了模型判断负担甚至拉低响应速度。我的做法是把聚合包装在一个独立目录里比如~/.claude/skills/superpower-skills/而不是直接平铺进skills根目录。这样我可以随时按需引入而不是让所有技能都自动可见。等我把里面真正有用的技能挑出来了再单独摘出来放到自己维护的技能目录中。3.3 实操心得安装后最好做一遍“技能体检”很多人装完技能就急着用结果发现 AI 根本没按预期工作。这里有个关键经验每个 skill 的最佳触发词和输入格式跟你以为的不一定一样。我装完一个新技能第一件事是看它的 SKILL.md搞清楚两个问题——它的name和description里写了什么触发条件以及它的执行步骤里第一步要什么样的输入。举个例子我装过一个“周报生成”技能SKILL.md 里写的触发场景是“weekly report / weekly summary”但你直接说“帮我写个周报”也能命中。可它期望的输入格式是“本周做了这些事勾选列表”而不是一段散文。你要是第一步就给了一段散文它生成的周报质量会大打折扣。建议流程装完技能 → 读 SKILL.md → 用一行最简洁的指令测试 → 对比输出质量 → 调整输入方式。整个过程不超过十分钟但能避免后面的大量返工。4. 从零手写一个属于自己的 skill附完整示例4.1 SKILL.md 的文件结构与编写套路一个能被模型正确理解和执行的 SKILL.md其实有比较固定的套路。我用一个“代码评审”技能作为例子直接给你看能跑的完整结构--- name: code-review description: 对代码变更进行系统化评审识别潜在缺陷、安全隐患和改进空间。当用户要求审查代码、分析 PR 或检查改动时使用。 --- # Code Review 技能 按以下步骤对用户提供的代码或代码变更进行评审 ## 步骤 1理解变更上下文 - 要求用户提供变更范围描述或 diff - 确认当前项目的语言与技术栈 ## 步骤 2分维度检查 1. **正确性**逻辑是否完整边界条件是否处理 2. **安全性**输入校验、注入风险、权限检查 3. **性能**循环复杂度、不必要的重复计算、资源释放 4. **可维护性**命名、函数长度、结构分层、注释质量 ## 步骤 3输出评审报告 按以下 Markdown 模板输出 - 变更概述 - 关键问题按严重程度排序 - 改进建议给出代码示例 - 是否建议合并approve / request changes这里有个很重要的细节——frontmatter 里的name和description是触发机制的灵魂。模型是通过读 description 来判断“什么时候该用这个技能”的所以写 description 一定要具体用到跟用户表达习惯匹配的关键词。比如你写“评审代码”用户说“帮我看看这段代码有没有问题”就命中不了更好的写法是包含多种可能说法“审查代码 / code review / 看看这段代码有什么问题 / review this PR”。4.2 结合真实场景给数学建模比赛写一个 skill先交代背景——现在数学建模竞赛包括华为杯、国赛等越来越卷很多参赛队伍开始用 Codex 或 Claude Code 搭配 skills 来提效。我看到的热搜词里就有人在找“数学建模 skills 推荐”这确实是个非常实用且容易上手的场景。我写过一个“数学建模论文评审”skill目标用途非常聚焦让 AI 像数模教练一样审阅论文从摘要凝练度、模型合理性、结果分析、排版规范几个维度给意见。核心 SKILL.md 片段--- name: math-model-paper-review description: 对数学建模竞赛论文进行系统性评审。当用户提供论文文件、要求评审建模论文、检查论文摘要或模型方法时使用。 --- # 数模论文评审流程 ## 输入要求 - 优先接收 PDF / Markdown / Word 格式论文 - 若是图片或扫描件先进行 OCR 转换 ## 评审维度按权重排序 1. 摘要35%研究问题概述、模型创新点、求解算法、结果精炼 2. 模型构建30%假设合理性、数学表达规范性、与问题的贴合度 3. 求解与结果20%算法选择、结果呈现、敏感性分析 4. 排版与表达15%图表规范、公式编号、参考文献 ## 输出格式 - 总评分满分 100 - 每个维度的得分与一句评语 - 优先级最高的三个改进建议附修改示例有了这个 skill 之后队员写完一版论文直接在终端发一句“用数学建模评审技能看一下这篇论文”AI 就会自动按这个程序走完输出结论。这比一遍遍人工复读 prompt 稳定太多了。同样的套路你可以往任何竞赛场景扩展数据清洗脚本模板、时间序列预测代码生成、论文公式排版修正等都能封装成独立技能。4.3 测试与迭代技能不是“写一次”就完了写完一个 skill离“好用”还有很大距离。我的习惯是分三轮迭代第一轮基础可用性测试。给一个最简单的输入看模型能不能正确读取 SKILL.md 并按步骤走。如果它压根没触发多半是 description 写得不够明确或者触发词覆盖不全。第二轮边界输入测试。喂一个不好处理的输入比如“这个 PDF 里的表格很乱怎么办”看技能有没有兜底逻辑。没有的话加一个“输入格式异常时”的处理分支。第三轮真实场景打磨。把自己真实工作里最典型的三五个请求各跑一遍把 SKILL.md 里输出模板反复调整。比如我的数模评审技能第一次输出的“改进建议”太笼统我就加了“每一条建议必须附带一个具体的修改代码或重写片段”这个约束质量才上来。注意写技能最忌讳的是贪大求全。一个 skill 只解决一个高度聚焦的任务多任务场景就拆成多个小型技能编排使用。写得越宽泛触发准确率越低执行质量也越差。5. 常用技能库与场景实战5.1 值得收藏的开源技能库我把常用的、质量相对可靠的技能库整理成了一张清单你可以直接当导航用。注意这些库的热度变化比较快clone 之前先看下最近是否有 commit。仓库主要特色适用工具superpower-skills聚合技能包覆盖文档处理、图像、研究、日程等Claude Codeanthropics/skills官方展示技能库含 PDF、PPT、docx、xlsx 处理Claude Codetypesafe-ai/skills面向浏览器自动化、Markdown 处理等专项技能Claude Code / 兼容工具opencode 官方技能市场围绕开源开发流程的技能安装方便OpenCodeawesome-codex / AGENTS.md 合集项目级约束模板适用于 Codex 工作流Codex这里特别提一下 Anthropic 官方出品的那些文档处理类技能。我试过它的 PDF 技能能把一份几百页的 PDF 抽取成结构化 Markdown支持自动识别目录、提取表格、保留标题层级效果比自己写正则脚本好太多。日常办公场景下这种“顺序思考 文档拆解”的能力正是普通人最缺的。5.2 场景一前端开发的 skills 组合前端开发是我个人用得最深的方向也最能体现技能组合的威力。我给你列一套我常用的“前端开发技能栈”component-review skill让模型像高级前端工程师一样评审组件代码重点看 props 设计、渲染性能、可访问性、状态管理方式。css-refactor skill接收一段 CSS 文件自动识别重复样式、无用的选择器、可抽取的设计变量输出重构方案。website-fetcher skill抓取目标网站页面结构并生成“改版建议报告”适合做竞品分析。release-note skill从最近的 git log 和 PR 标题里生成精炼的版本更新说明。这套组合的用法很灵活。比如我在重构一个长期维护的老项目时会让模型先跑 component-review把有问题的组件清单列出来再针对高优先级的组件让 css-refactor 技能出重构方案。这样每个技能只干一件事但组合在一起就是一个完整的“前端健康检查 重构”流水线。5.3 场景二AI 漫剧创作的批量流程AI 漫剧最近特别火很多人用 AI 生成分镜、角色、台词和配音。但真正做起来你会发现最耗时间的不是“生成画面”这一下而是“把脚本转成分镜描述、把分镜描述转成提示词、把几千个提示词批量喂给生图工具”这种重复性工作流。Skills 在这块的价值被很多人低估了。我见过一个团队分享的“AI 漫剧常用技能”配置看完觉得思路很值得复制script-to-storyboard skill把一段剧本文本按场景切分输出表格化的分镜包含镜头编号、景别、角色、动作、台词、情绪。storyboard-to-prompt skill把分镜表格转成生图模型的提示词会根据角色设定自动添加风格词、光线词、质量标签。caption-style skill把生成的台词批量套用统一的字幕格式输出带时间轴标记的 SRV 文件。这里面最核心的并不是某个单一技能而是技能接力——上一个技能的输出格式正好是下一个技能的输入格式。设计技能时留好“接口”可以让多个技能像流水线一样协作。你在写自己的技能时如果在 SKILL.md 里明确了输出格式后面的人或者你自己的下一个技能就能无缝接上。5.4 场景三数学建模竞赛提效说回数学建模。我看热搜里提到“华为杯建模比赛好用的 codex skills”确实有不少队伍在往这个方向押注。但作为建议我不推荐你去网上找一个“全家桶”就完事更实用的做法是围绕竞赛的三个核心赛道各配一个技能数据探索技能自动识别数据集类型、列分布、缺失值、相关性输出一份“数据体检报告”。模型选择技能根据问题类型分类、回归、优化、预测推荐 3 种候选模型比较优缺点并给出调参建议。论文排版技能把杂乱的结果输出转成规范的论文图表和公式描述。这三件套几乎覆盖了建模比赛从数据处理到论文写作的主链路。而且每一件的输入输出都很清晰适合在比赛最后冲刺阶段让 AI 快速处理重复性工作把人力从“写代码调参”中解放出来集中到建模思路和创新点上。6. 实用避坑指南与技能清理6.1 我踩过的 5 个 skills 大坑技能用多了坑自然就踩出来了。这里挑五个最常见的按遭遇到的频率排序每一条都是真金白银的教训。第一坑装了太多技能模型判断混乱。我一度把二三十个技能全挂进~/.claude/skills/结果模型面对一个简单问题时要先做“超集匹配”经常挑错技能甚至出现两个技能同时响应导致指令冲突。解决方式是只保留日常高频前 8~10 个低频的单独放扩展目录用时再挂载。第二坑description 写得太文艺触发不精准。我早期写过一个“文档整理”技能description 写的是“让混乱的内容变得有序”结果它基本从未被自动触发。后来改成“将 Markdown 文档按标题结构重组并生成目录当用户要求整理文档结构、重新组织文章层级时使用”触发率直接起飞。记住description 是给模型看的索引不是给人看的介绍。第三坑忽略上下文溢出。有些技能喜欢在 SKILL.md 里堆大量示例和背景知识模型每次触发都要读入一大段 token不仅拖慢响应还挤占上下文窗口导致对话中后期质量下滑。现在我的经验是SKILL.md 控制在 200 行以内外部参考文件放 resources只有需要时才读取。第四坑脚本权限没配好。有的技能会带 Python 或 Shell 脚本但工具默认可能不允许执行。在查看日志时经常会看到“Action permission denied”之类的错误。配置里需要手动开放特定脚本的执行权限不然技能就是“读了没做”的状态。第五坑跨工具格式混用。我试过把 Claude Code 的技能文件直接丢到 Codex 的 AGENTS.md 里结果组织方式完全不同模型理解的是“项目上下文”而不是“可执行技能”。现在我的原则是同一个仓库里每个工具的技能文件单独建目录各维护各的格式规范。6.2 技能清理方法论tibs 推荐的思路实践关于技能清理我在网上看到过 tibo 分享的一套思路自己实操后觉得确实有效结合自己的习惯改良成了“三步清理法”第一步盘存量。把所有技能目录列出来按最近 30 天的实际调用次数排序。为零使用和低使用率的技能单独标记移出自动加载目录。第二步看依赖。检查哪些技能引用了重复的脚本或资源比如我有三个不同的技能都内置了一份“日期处理”脚本清理时统一抽到一个公共工具目录技能内改为引用路径。这样既减小体积也方便后续升级。第三步建仓库。把清理后保留的技能纳入你自己的 git 仓库管理写清楚 README标注适用场景、触发词、责任人。别人拿到你的技能库看一遍 README 就知道怎么用这才是“可交付”的技能资产。清理方法论之所以重要是因为技能库跟代码库一样不维护就会腐化。每写完一个技能我都在 README 里加一条“最近使用场景”备注三个月后回看哪些技能在吃灰一目了然。提示清理不是删掉就完事。把低频技能挪到一个archive/目录里比直接删除更稳妥万一哪天需要重启你不需要重新下载和配置。6.3 加速加载与配置管理小技巧最后分享几个实用小技巧都是我在长时间使用中磨出来的。环境变量隔离不同项目的技能需求可能不同通过工具的环境配置为每个项目单独指定技能目录避免项目间互相“污染”。技能软链接如果你同时用多个工具想共享同款技能可以用符号链接把技能目录挂到各工具的对应路径下不用复制多份。定期跑“技能审计”每个月花十五分钟检查哪些技能版本落后了哪些技能已经没人用了哪些技能和另一款工具的新特性冲突。掌握技能的 CLI 命令比如 OpenCode 有opencode skills list和opencode skills doctor能列出当前技能和诊断潜在问题建议把这些高级命令用起来比手动翻目录高效得多。最后再分享一点个人心得技能这个事儿说到底是一种“AI 时代的个人知识管理”方式。你现在写的每个 skill不只是给 AI 用的说明书更是对自己工作流的一次梳理和抽象。我写了几十个技能之后最大的感触不是“AI 变强了”而是“我对自己的做事方法更清楚了”。比如我原来从不觉得自己的代码评审流程有章法可循直到为了写技能被迫把步骤一条条列出来才发现原来我一直在凭感觉审代码而这个技能反过来帮我把评审水准拉齐了。关于 skills 的学习路径我建议你按这样的顺序走先用现成的、再改现成的、最后写自己的。前面 20 个技能用下来基本就能建立起对“什么封装成技能、什么不该封装”的判断力。后面越写越顺你甚至会开始给生活里非编程的场景做技能——做菜步骤、学习计划、PPT 模板凡事皆可技能化。技能库会越攒越厚值得定期整理归档。技术变化快今天好用的技能下个月可能就被模型能力本身取代了但“把经验固化为资产”这一点永远不会过时。 先聊个事儿如果你最近刷 X、逛 GitHub Trending一定被一个词刷屏了——skills。前端开发有 skillsClaude Code 能装 GitHub 上的 skillsOpenCode 在搞 skills数学建模比赛有人用 codex skills 拿奖AI 漫剧创作者靠 skills 批量出片。这个原本平淡的英文单词在 2025 年成了 AI 编程圈最火的“包”概念。我电脑里现在躺着十几个 skills从写周报到读论文、从调参 bug 到画架构图日常的 AI 协作效率大概提了有三四倍今天就把我攒下的这套经验完整拆给你。这篇内容会覆盖 skills 的底层逻辑、主流工具Claude Code / Codex / OpenCode的安装玩法、如何手写一个属于自己的 skill、有哪些现成技能库值得收藏以及我踩过的坑和清理方法。不管你是刚接触 AI 编程工具的新手还是已经在用但想搞懂“技能到底怎么武装”的老手这篇应该都能给你点实在的参考。1. skills 到底是什么从提示词到“可复用技能包”1.1 skills 解决的第一个痛点每次都在重复教 AI先说个我自己的真实经历。2024 年底我用 Claude Code 写项目每开一个新仓库都要在对话里花十几分钟重新“调教”模型你该怎么读这个项目、遇到报错怎么处理、测试要写到什么程度、代码风格偏好是什么。好不容易这套话术跑顺了换个项目全得重来。这种重复劳动特别折磨人而且每次复述都会有信息损耗——今天忘了说“不要改测试文件”明天忘了提“提交前先跑 lint”结果就是模型时不时给你搞出点“蠢操作”。后来我看到 Anthropic 官方推了 Agent Skills 的概念一下就通了skill 就是把“如何完成某类任务”的完整经验封装成一个可复用、可分享、可版本化的文件包。它跟提示词的本质区别在于提示词是每次对话临时打的草稿skill 是沉淀下来的标准作业程序。你不需要再给 AI 讲一遍该怎么做事只要说一句“用一下我的 code-review skill”它就知道按什么步骤、看哪些点、以什么格式输出审查结论。用生活化一点的类比提示词相当于你每次请一个新来的实习生都得从“怎么用复印机”开始教而 skill 相当于给这个实习生一份岗位手册他翻开就知道流程和标准。前者是每换一个人重新教后者是一劳永逸地沉淀经验。1.2 skills 的“技能包”结构为什么它比提示词更靠谱真正用过之后你会发现skill 不是简单把提示词换个后缀名而是一整套结构化资产。一个规范的 skill 通常包含三个部分SKILL.md 主文件定义这个技能的用途、适用场景、执行步骤、输出规范是整个技能包的大脑。脚本与工具代码比如 Python / Shell 脚本机器能执行的动作交给脚本模型负责调度和判断人机互补。参考资料与模板比如领域知识文档、输出模板、示例样本给模型“现成的答案素材”减少从零生成的不确定性。这种结构与纯文本提示词相比最大的优势是可编程性。模型在运行 skill 时不只是读一段文字然后照做而是可以调用脚本、解析文件、生成结构化输出。相当于你把“怎么做这件事”的每个环节都拆开、编码、固化AI 干起活来像是用规范工具而非靠聊天直觉。这个设计直接影响了后来所有 AI 编程工具的演进方向。Claude Code 在 2025 年把 skills 作为核心特性之一OpenAI 的 Codex 也加入了基于 AGENTS.md 的技能机制而开源生态里 OpenCode、Cline 等工具则各自实现了兼容或扩展方案。可以说skills 已经不只是提示词工程的花式玩法而是成了 AI 协作工作流的基础设施。2. 主流 AI 编程工具的 skills 支持现状选型2.1 四款主流工具横向对比我实际用过的、对 skills 支持比较成熟的有四款Claude Code、CodexOpenAI、OpenCode、Cline。这四款各有各的设计思路放个对照表让你一眼看明白差异。工具技能格式存放位置加载方式我的使用评价Claude CodeAgent Skills 官方格式SKILL.md 资源~/.claude/skills/或项目.claude/skills/关键词自动触发或/skills手动调用最成熟稳定生态最丰富我的主力CodexOpenAIAGENTS.md 驱动 prompt 约定项目根目录AGENTS.md项目级自动加载跟“代码补全”场景绑定较深适合仓库级约束OpenCode兼容多种格式含 SKILL.md项目.opencode/skills/等配置声明 自动发现开源灵活适合爱折腾的人Cline自定义规则文件 插件化插件市场 / 项目规则文件插件安装后按规则运行更像是“规则包”还没到完全体技能库先说结论如果只选一个工具深度玩 skills我推荐 Claude Code。原因不复杂——它的 skills 机制设计得最完整、文档最清晰、社区沉淀的现成技能最多而且~/.claude/skills/的全局目录设计让跨项目复用变得极其自然。但这不代表其他工具不值得了解因为技能生态正在快速融合很多 skills 格式也开始互相兼容。2.2 各工具的安装与管理差异安装体验上这四款差别还挺大值得单独说说。Claude Code 装一个 skill 最简单粗暴的方式就是把仓库克隆到~/.claude/skills/目录下一个子目录就是一个技能。比如你把skill-name这个仓库克隆到~/.claude/skills/skill-name然后在对话里提起相关需求模型就会自动去读 SKILL.md 并按流程执行。手动控制的话配置里加一个allowedSkills声明即可。Codex 的做法不太一样它更强调“项目级约束”。你需要在项目根目录维护一份AGENTS.md里面写清楚当前项目的技术栈、目录结构、编码规范、常用命令。Codex 每次启动都会自动加载这份文件相当于给模型装了一个“裸机环境驱动”。想更新技能就直接改文件不用重装什么包。OpenCode 是最有野心的一个它的 skills 系统允许你挂载多种格式本地目录、远程 Git 仓库、甚至 npm 包里的内置技能。安装时改一个opencode.json配置文件就可以。这个灵活性对进阶玩家很友好但对新手来说配置项有点多容易踩坑。Cline 目前更像“规则包 插件”的混合体它有一些内置的插件市场也支持你自己写.clinerules文件。跟前面几款比Cline 的技能生态还没那么丰富但如果你本身主力工具就是 Cline它的规则文件依然能覆盖大部分“固化流程”的需求。3. 手把手实操如何安装和使用 GitHub 上的 skills3.1 快速安装克隆命令与目录结构无论你用哪款工具从 GitHub 装 skills 的底层逻辑基本一致把远程仓库拉到本地指定目录让工具能发现并使用它。我以 Claude Code 为例给出一套最通用、最不容易出错的完整流程。# 1. 确保技能目录存在 mkdir -p ~/.claude/skills # 2. 克隆你找到的技能仓库示例为超级技能合集包 git clone https://github.com/superpowerlabs/superpower-skills.git ~/.claude/skills/superpower-skills # 3. 查看是否安装成功应能看到 SKILL.md 文件 ls ~/.claude/skills/superpower-skills装完不是就完事了你需要在 Claude Code 的配置里确认是否允许这个技能被加载。打开工具设置找到allowedSkills相关配置把技能名加进去。现在这个工具就可以在对话里自动识别相关任务并加载技能了。Codex 的安装思路是“无全局目录”模式更简洁——直接把 AGENTS.md 放到你的项目根目录即可# 把下载的 AGENTS.md 放到项目根目录 curl -o AGENTS.md https://raw.githubusercontent.com/xxx/awesome-codex/main/AGENTS.md # 验证 cat AGENTS.mdOpenCode 的配置方式稍微绕一点但它支持远程技能库这一点我特别喜欢。在opencode.json里声明一个技能{ skills: { my-skill: { path: ~/.opencode/skills/my-skill, enabled: true } } }也可以直接用 CLIopencode skills install github-username/repo-name3.2 superpower skills 这类“聚合包”到底装不装现在 GitHub 上有很多所谓的“超级技能包”最出名的就是 superpower-skills宣称包含了几十个实用技能。这类包我的态度是可以装但别无脑用。聚合包的优点是省事——克隆下来就有一堆技能而且能启发你对“原来这也算一个技能”的认知。缺点是很多技能质量良莠不齐有的跟你的工作流根本不匹配还有些技能之间会有指令冲突挂在~/.claude/skills/下反而增加了模型判断负担甚至拉低响应速度。我的做法是把聚合包装在一个独立目录里比如~/.claude/skills/superpower-skills/而不是直接平铺进skills根目录。这样我可以随时按需引入而不是让所有技能都自动可见。等我把里面真正有用的技能挑出来了再单独摘出来放到自己维护的技能目录中。3.3 实操心得安装后最好做一遍“技能体检”很多人装完技能就急着用结果发现 AI 根本没按预期工作。这里有个关键经验每个 skill 的最佳触发词和输入格式跟你以为的不一定一样。我装完一个新技能第一件事是看它的 SKILL.md搞清楚两个问题——它的name和description里写了什么触发条件以及它的执行步骤里第一步要什么样的输入。举个例子我装过一个“周报生成”技能SKILL.md 里写的触发场景是“weekly report / weekly summary”但你直接说“帮我写个周报”也能命中。可它期望的输入格式是“本周做了这些事勾选列表”而不是一段散文。你要是第一步就给了一段散文它生成的周报质量会大打折扣。建议流程装完技能 → 读 SKILL.md → 用一行最简洁的指令测试 → 对比输出质量 → 调整输入方式。整个过程不超过十分钟但能避免后面的大量返工。4. 从零手写一个属于自己的 skill附完整示例4.1 SKILL.md 的文件结构与编写套路一个能被模型正确理解和执行的 SKILL.md其实有比较固定的套路。我用一个“代码评审”技能作为例子直接给你看能跑的完整结构--- name: code-review description: 对代码变更进行系统化评审识别潜在缺陷、安全隐患和改进空间。当用户要求审查代码、分析 PR 或检查改动时使用。 --- # Code Review 技能 按以下步骤对用户提供的代码或代码变更进行评审 ## 步骤 1理解变更上下文 - 要求用户提供变更范围描述或 diff - 确认当前项目的语言与技术栈 ## 步骤 2分维度检查 1. **正确性**逻辑是否完整边界条件是否处理 2. **安全性**输入校验、注入风险、权限检查 3. **性能**循环复杂度、不必要的重复计算、资源释放 4. **可维护性**命名、函数长度、结构分层、注释质量 ## 步骤 3输出评审报告 按以下 Markdown 模板输出 - 变更概述 - 关键问题按严重程度排序 - 改进建议给出代码示例 - 是否建议合并approve / request changes这里有个很重要的细节——frontmatter 里的name和description是触发机制的灵魂。模型是通过读 description 来判断“什么时候该用这个技能”的所以写 description 一定要具体用到跟用户表达习惯匹配的关键词。比如你写“评审代码”用户说“帮我看看这段代码有没有问题”就命中不了更好的写法是包含多种可能说法“审查代码 / code review / 看看这段代码有什么问题 / review this PR”。4.2 结合真实场景给数学建模比赛写一个 skill先交代背景——现在数学建模竞赛包括华为杯、国赛等越来越卷很多参赛队伍开始用 Codex 或 Claude Code 搭配 skills 来提效。我看到的热搜词里就有人在找“数学建模 skills 推荐”这确实是个非常实用且容易上手的场景。我写过一个“数学建模论文评审”skill用途非常聚焦让 AI 像数模教练一样审阅论文从摘要凝练度、模型合理性、结果分析、排版规范几个维度给意见。核心 SKILL.md 片段--- name: math-model-paper-review description: 对数学建模竞赛论文进行系统性评审。当用户提供论文文件、要求评审建模论文、检查论文摘要或模型方法时使用。 --- # 数模论文评审流程 ## 输入要求 - 优先接收 PDF / Markdown / Word 格式论文 - 若是图片或扫描件先进行 OCR 转换 ## 评审维度按权重排序 1. 摘要35%研究问题概述、模型创新点、求解算法、结果精炼 2. 模型构建30%假设合理性、数学表达规范性、与问题的贴合度 3. 求解与结果20%算法选择、结果呈现、敏感性分析 4. 排版与表达15%图表规范、公式编号、参考文献 ## 输出格式 - 总评分满分 100 - 每个维度的得分与一句评语 - 优先级最高的三个改进建议附修改示例有了这个 skill 之后队员写完一版论文直接在终端发一句“用数学建模评审技能看一下这篇论文”AI 就会自动按这个程序走完输出结论。这比一遍遍人工复读 prompt 稳定太多了。同样的套路你可以往任何竞赛场景扩展数据清洗脚本模板、时间序列预测代码生成、论文公式排版修正等都能封装成独立技能。4.3 测试与迭代技能不是“写一次”就完了写完一个 skill离“好用”还有很大距离。我的习惯是分三轮迭代第一轮基础可用性测试。给一个最简单的输入看模型能不能正确读取 SKILL.md 并按步骤走。如果它压根没触发多半是 description 写得不够明确或者触发词覆盖不全。第二轮边界输入测试。喂一个不好处理的输入比如“这个 PDF 里的表格很乱怎么办”看技能有没有兜底逻辑。没有的话加一个“输入格式异常时”的处理分支。第三轮真实场景打磨。把自己真实工作里最典型的三五个请求各跑一遍把 SKILL.md 里输出模板反复调整。比如我的数模评审技能第一次输出的“改进建议”太笼统我就加了“每一条建议必须附带一个具体的修改代码或重写片段”这个约束质量才上来。注意写技能最忌讳的是贪大求全。一个 skill 只解决一个高度聚焦的任务多任务场景就拆成多个小型技能编排使用。写得越宽泛触发准确率越低执行质量也越差。5. 常用技能库与场景实战5.1 值得收藏的开源技能库我把常用的、质量相对可靠的技能库整理成了一张清单你可以直接当导航用。注意这些库的热度变化比较快clone 之前先看下最近是否有 commit。仓库主要特色适用工具superpower-skills聚合技能包覆盖文档处理、图像、研究、日程等Claude Codeanthropics/skills官方展示技能库含 PDF、PPT、docx、xlsx 处理Claude Codetypesafe-ai/skills面向浏览器自动化、Markdown 处理等专项技能Claude Code / 兼容工具opencode 官方技能市场围绕开源开发流程的技能安装方便OpenCodeawesome-codex / AGENTS.md 合集项目级约束模板适用于 Codex 工作流Codex这里特别提一下 Anthropic 官方出品的那些文档处理类技能。我试过它的 PDF 技能能把一份几百页的 PDF 抽取成结构化 Markdown支持自动识别目录、提取表格、保留标题层级效果比自己写正则脚本好太多。日常办公场景下这种“顺序思考 文档拆解”的能力正是普通人最缺的。5.2 场景一前端开发的 skills 组合前端开发是我个人用得最深的方向也最能体现技能组合的威力。我给你列一套我常用的“前端开发技能栈”component-review skill让模型像高级前端工程师一样评审组件代码重点看 props 设计、渲染性能、可访问性、状态管理方式。css-refactor skill接收一段 CSS 文件自动识别重复样式、无用的选择器、可抽取的设计变量输出重构方案。website-fetcher skill抓取目标网站页面结构并生成“改版建议报告”适合做竞品分析。release-note skill从最近的 git log 和 PR 标题里生成精炼的版本更新说明。这套组合的用法很灵活。比如我在重构一个长期维护的老项目时会让模型先跑 component-review把有问题的组件清单列出来再针对高优先级的组件让 css-refactor 技能出重构方案。这样每个技能只干一件事但组合在一起就是一个完整的“前端健康检查 重构”流水线。5.3 场景二AI 漫剧创作的批量流程AI 漫剧最近特别火很多人用 AI 生成分镜、角色、台词和配音。但真正做起来你会发现最耗时间的不是“生成画面”这一下而是“把脚本转成分镜描述、把分镜描述转成提示词、把几千个提示词批量喂给生图工具”这种重复性工作流。Skills 在这块的价值被很多人低估了。我见过一个团队分享的“AI 漫剧常用技能”配置看完觉得思路很值得复制script-to-storyboard skill把一段剧本文本按场景切分输出表格化的分镜包含镜头编号、景别、角色、动作、台词、情绪。storyboard-to-prompt skill把分镜表格转成生图模型的提示词会根据角色设定自动添加风格词、光线词、质量标签。caption-style skill把生成的台词批量套用统一的字幕格式输出带时间轴标记的文件。这里面最核心的并不是某个单一技能而是技能接力——上一个技能的输出格式正好是下一个技能的输入格式。设计技能时留好“接口”可以让多个技能像流水线一样协作。你在写自己的技能时如果在 SKILL.md 里明确了输出格式后面的人或者你自己的下一个技能就能无缝接上。5.4 场景三数学建模竞赛提效说回数学建模。我看热搜里提到“华为杯建模比赛好用的 codex skills”确实有不少队伍在往这个方向押注。但作为建议我不推荐你去网上找一个“全家桶”就完事更实用的做法是围绕竞赛的三个核心赛道各配一个技能数据探索技能自动识别数据集类型、列分布、缺失值、相关性输出一份“数据体检报告”。模型选择技能根据问题类型分类、回归、优化、预测推荐 3 种候选模型比较优缺点并给出调参建议。论文排版技能把杂乱的结果输出转成规范的论文图表和公式描述。这三件套几乎覆盖了建模比赛从数据处理到论文写作的主链路。而且每一件的输入输出都很清晰适合在比赛最后冲刺阶段让 AI 快速处理重复性工作把人力从“写代码调参”中解放出来集中到建模思路和创新点上。6. 实用避坑指南与技能清理6.1 我踩过的 5 个 skills 大坑技能用多了坑自然就踩出来了。这里挑五个最常见的按遭遇到的频率排序每一条都是真金白银的教训。第一坑装了太多技能模型判断混乱。我一度把二三十个技能全挂进~/.claude/skills/结果模型面对一个简单问题时要先做“超集匹配”经常挑错技能甚至出现两个技能同时响应导致指令冲突。解决方式是只保留日常高频前 8~10 个低频的单独放扩展目录用时再挂载。第二坑description 写得太文艺触发不精准。我早期写过一个“文档整理”技能description 写的是“让混乱的内容变得有序”结果它基本从未被自动触发。后来改成“将 Markdown 文档按标题结构重组并生成目录当用户要求整理文档结构、重新组织文章层级时使用”触发率直接起飞。记住description 是给模型看的索引不是给人看的介绍。第三坑忽略上下文溢出。有些技能喜欢在 SKILL.md 里堆大量示例和背景知识模型每次触发都要读入一大段 token不仅拖慢响应还挤占上下文窗口导致对话中后期质量下滑。现在我的经验是SKILL.md 控制在 200 行以内外部参考文件放 resources只有需要时才读取。第四坑脚本权限没配好。有的技能会带 Python 或 Shell 脚本但工具默认可能不允许执行。在查看日志时经常会看到“Action permission denied”之类的错误。配置里需要手动开放特定脚本的执行权限不然技能就是“读了没做”的状态。第五坑跨工具格式混用。我试过把 Claude Code 的技能文件直接丢到 Codex 的 AGENTS.md 里结果组织方式完全不同模型理解的是“项目上下文”而不是“可执行技能”。现在我的原则是同一个仓库里每个工具的技能文件单独建目录各维护各的格式规范。6.2 技能清理方法论tibs 推荐的思路实践关于技能清理我在网上看到过 tibo 分享的一套思路自己实操后觉得确实有效结合自己的习惯改良成了“三步清理法”第一步盘存量。把所有技能目录列出来按最近 30 天的实际调用次数排序。为零使用和低使用率的技能单独标记移出自动加载目录。第二步看依赖。检查哪些技能引用了重复的脚本或资源比如我有三个不同的技能都内置了一份“日期处理”脚本清理时统一抽到一个公共工具目录技能内改为引用路径。这样既减小体积也方便后续升级。第三步建仓库。把清理后保留的技能纳入你自己的 git 仓库管理写清楚 README标注适用场景、触发词、责任人。别人拿到你的技能库看一遍 README 就知道怎么用这才是“可交付”的技能资产。清理方法论之所以重要是因为技能库跟代码库一样不维护就会腐化。每写完一个技能我都在 README 里加一条“最近使用场景”备注三个月后回看哪些技能在吃灰一目了然。提示清理不是删掉就完事。把低频技能挪到一个archive/目录里比直接删除更稳妥万一哪天需要重启你不需要重新下载和配置。6.3 加速加载与配置管理小技巧最后分享几个实用小技巧都是我在长时间使用中磨出来的。环境变量隔离不同项目的技能需求可能不同通过工具的环境配置为每个项目单独指定技能目录避免项目间互相“污染”。技能软链接如果你同时用多个工具想共享同款技能可以用符号链接把技能目录挂到各工具的对应路径下不用复制多份。定期跑“技能审计”每个月花十五分钟检查哪些技能版本落后了哪些技能已经没人用了哪些技能和另一款工具的新特性冲突。掌握技能的 CLI 命令比如 OpenCode 有opencode skills list和opencode skills doctor能列出当前技能和诊断潜在问题建议把这些高级命令用起来比手动翻目录高效得多。最后再分享一点个人心得技能这个事儿说到底是一种“AI 时代的个人知识管理”方式。你现在写的每个 skill不只是给 AI 用的说明书更是对自己工作流的一次梳理和抽象。我写了几十个技能之后最大的感触不是“AI 变强了”而是“我对自己的做事方法更清楚了”。比如我原来从不觉得自己的代码评审流程有章法可循直到为了写技能被迫把步骤一条条列出来才发现原来我一直在凭感觉审代码而这个技能反过来帮我把评审水准拉齐了。关于 skills 的学习路径我建议你按这样的顺序走先用现成的、再改现成的、最后写自己的。前面 20 个技能用下来基本就能建立起对“什么封装成技能、什么不该封装”的判断力。后面越写越顺你甚至会开始给生活里非编程的场景做技能——做菜步骤、学习计划、PPT 模板凡事皆可技能化。技能库会越攒越厚值得定期整理归档。技术变化快今天好用的技能下个月可能就被模型能力本身取代了但“把经验固化为资产”这一点永远不会过时。 AI Skills 技能包实战：从提示词到可复用工作流
先聊个事儿如果你最近刷 X、逛 GitHub Trending一定被一个词刷屏了——skills。前端开发有 skillsClaude Code 能装 GitHub 上的 skillsOpenCode 在搞 skills数学建模比赛有人用 codex skills 拿奖AI 漫剧创作者靠 skills 批量出片。这个原本平淡的英文单词在 2025 年成了 AI 编程圈最火的“包”概念。我电脑里现在躺着十几个 skills从写周报到读论文、从调参 bug 到画架构图日常的 AI 协作效率大概提了有三四倍今天就把我攒下的这套经验完整拆给你。这篇内容会覆盖 skills 的底层逻辑、主流工具Claude Code / Codex / OpenCode的安装玩法、如何手写一个属于自己的 skill、有哪些现成技能库值得收藏以及我踩过的坑和清理方法。不管你是刚接触 AI 编程工具的新手还是已经在用但想搞懂“技能到底怎么武装”的老手这篇应该都能给你点实在的参考。1. skills 到底是什么从提示词到“可复用技能包”1.1 skills 解决的第一个痛点每次都在重复教 AI先说个我自己的真实经历。2024 年底我用 Claude Code 写项目每开一个新仓库都要在对话里花十几分钟重新“调教”模型你该怎么读这个项目、遇到报错怎么处理、测试要写到什么程度、代码风格偏好是什么。好不容易这套话术跑顺了换个项目全得重来。这种重复劳动特别折磨人而且每次复述都会有信息损耗——今天忘了说“不要改测试文件”明天忘了提“提交前先跑 lint”结果就是模型时不时给你搞出点“蠢操作”。后来我看到 Anthropic 官方推了 Agent Skills 的概念一下就通了skill 就是把“如何完成某类任务”的完整经验封装成一个可复用、可分享、可版本化的文件包。它跟提示词的本质区别在于提示词是每次对话临时打的草稿skill 是沉淀下来的标准作业程序。你不需要再给 AI 讲一遍该怎么做事只要说一句“用一下我的 code-review skill”它就知道按什么步骤、看哪些点、以什么格式输出审查结论。用生活化一点的类比提示词相当于你每次请一个新来的实习生都得从“怎么用复印机”开始教而 skill 相当于给这个实习生一份岗位手册他翻开就知道流程和标准。前者是每换一个人重新教后者是一劳永逸地沉淀经验。1.2 skills 的“技能包”结构为什么它比提示词更靠谱真正用过之后你会发现skill 不是简单把提示词换个后缀名而是一整套结构化资产。一个规范的 skill 通常包含三个部分SKILL.md 主文件定义这个技能的用途、适用场景、执行步骤、输出规范是整个技能包的大脑。脚本与工具代码比如 Python / Shell 脚本机器能执行的动作交给脚本模型负责调度和判断人机互补。参考资料与模板比如领域知识文档、输出模板、示例样本给模型“现成的答案素材”减少从零生成的不确定性。这种结构与纯文本提示词相比最大的优势是可编程性。模型在运行 skill 时不只是读一段文字然后照做而是可以调用脚本、解析文件、生成结构化输出。相当于你把“怎么做这件事”的每个环节都拆开、编码、固化AI 干起活来像是用规范工具而非靠聊天直觉。这个设计直接影响了后来所有 AI 编程工具的演进方向。Claude Code 在 2025 年把 skills 作为核心特性之一OpenAI 的 Codex 也加入了基于 AGENTS.md 的技能机制而开源生态里 OpenCode、Cline 等工具则各自实现了兼容或扩展方案。可以说skills 已经不只是提示词工程的花式玩法而是成了 AI 协作工作流的基础设施。2. 主流 AI 编程工具的 skills 支持现状选型2.1 四款主流工具横向对比我实际用过的、对 skills 支持比较成熟的有四款Claude Code、CodexOpenAI、OpenCode、Cline。这四款各有各的设计思路放个对照表让你一眼看明白差异。工具技能格式存放位置加载方式我的使用评价Claude CodeAgent Skills 官方格式SKILL.md 资源~/.claude/skills/或项目.claude/skills/关键词自动触发或/skills手动调用最成熟稳定生态最丰富我的主力CodexOpenAIAGENTS.md 驱动 prompt 约定项目根目录AGENTS.md项目级自动加载跟“代码补全”场景绑定较深适合仓库级约束OpenCode兼容多种格式含 SKILL.md项目.opencode/skills/等配置声明 自动发现开源灵活适合爱折腾的人Cline自定义规则文件 插件化插件市场 / 项目规则文件插件安装后按规则运行更像是“规则包”还没到完全体技能库先说结论如果只选一个工具深度玩 skills我推荐 Claude Code。原因不复杂——它的 skills 机制设计得最完整、文档最清晰、社区沉淀的现成技能最多而且~/.claude/skills/的全局目录设计让跨项目复用变得极其自然。但这不代表其他工具不值得了解因为技能生态正在快速融合很多 skills 格式也开始互相兼容。2.2 各工具的安装与管理差异安装体验上这四款差别还挺大值得单独说说。Claude Code 装一个 skill 最简单粗暴的方式就是把仓库克隆到~/.claude/skills/目录下一个子目录就是一个技能。比如你把skill-name这个仓库克隆到~/.claude/skills/skill-name然后在对话里提起相关需求模型就会自动去读 SKILL.md 并按流程执行。手动控制的话配置里加一个allowedSkills声明即可。Codex 的做法不太一样它更强调“项目级约束”。你需要在项目根目录维护一份AGENTS.md里面写清楚当前项目的技术栈、目录结构、编码规范、常用命令。Codex 每次启动都会自动加载这份文件相当于给模型装了一个“裸机环境驱动”。想更新技能就直接改文件不用重装什么包。OpenCode 是最有野心的一个它的 skills 系统允许你挂载多种格式本地目录、远程 Git 仓库、甚至 npm 包里的内置技能。安装时改一个opencode.json配置文件就可以。这个灵活性对进阶玩家很友好但对新手来说配置项有点多容易踩坑。Cline 目前更像“规则包 插件”的混合体它有一些内置的插件市场也支持你自己写.clinerules文件。跟前面几款比Cline 的技能生态还没那么丰富但如果你本身主力工具就是 Cline它的规则文件依然能覆盖大部分“固化流程”的需求。3. 手把手实操如何安装和使用 GitHub 上的 skills3.1 快速安装克隆命令与目录结构无论你用哪款工具从 GitHub 装 skills 的底层逻辑基本一致把远程仓库拉到本地指定目录让工具能发现并使用它。我以 Claude Code 为例给出一套最通用、最不容易出错的完整流程。# 1. 确保技能目录存在 mkdir -p ~/.claude/skills # 2. 克隆你找到的技能仓库示例为超级技能合集包 git clone https://github.com/superpowerlabs/superpower-skills.git ~/.claude/skills/superpower-skills # 3. 查看是否安装成功应能看到 SKILL.md 文件 ls ~/.claude/skills/superpower-skills装完不是就完事了你需要在 Claude Code 的配置里确认是否允许这个技能被加载。打开工具设置找到allowedSkills相关配置把技能名加进去。现在这个工具就可以在对话里自动识别相关任务并加载技能了。Codex 的安装思路是“无全局目录”模式更简洁——直接把 AGENTS.md 放到你的项目根目录即可# 把下载的 AGENTS.md 放到项目根目录 curl -o AGENTS.md https://raw.githubusercontent.com/xxx/awesome-codex/main/AGENTS.md # 验证 cat AGENTS.mdOpenCode 的配置方式稍微绕一点但它支持远程技能库这一点我特别喜欢。在opencode.json里声明一个技能{ skills: { my-skill: { path: ~/.opencode/skills/my-skill, enabled: true } } }也可以直接用 CLIopencode skills install github-username/repo-name3.2 superpower skills 这类“聚合包”到底装不装现在 GitHub 上有很多所谓的“超级技能包”最出名的就是 superpower-skills宣称包含了几十个实用技能。这类包我的态度是可以装但别无脑用。聚合包的优点是省事——克隆下来就有一堆技能而且能启发你对“原来这也算一个技能”的认知。缺点是很多技能质量良莠不齐有的跟你的工作流根本不匹配还有些技能之间会有指令冲突挂在~/.claude/skills/下反而增加了模型判断负担甚至拉低响应速度。我的做法是把聚合包装在一个独立目录里比如~/.claude/skills/superpower-skills/而不是直接平铺进skills根目录。这样我可以随时按需引入而不是让所有技能都自动可见。等我把里面真正有用的技能挑出来了再单独摘出来放到自己维护的技能目录中。3.3 实操心得安装后最好做一遍“技能体检”很多人装完技能就急着用结果发现 AI 根本没按预期工作。这里有个关键经验每个 skill 的最佳触发词和输入格式跟你以为的不一定一样。我装完一个新技能第一件事是看它的 SKILL.md搞清楚两个问题——它的name和description里写了什么触发条件以及它的执行步骤里第一步要什么样的输入。举个例子我装过一个“周报生成”技能SKILL.md 里写的触发场景是“weekly report / weekly summary”但你直接说“帮我写个周报”也能命中。可它期望的输入格式是“本周做了这些事勾选列表”而不是一段散文。你要是第一步就给了一段散文它生成的周报质量会大打折扣。建议流程装完技能 → 读 SKILL.md → 用一行最简洁的指令测试 → 对比输出质量 → 调整输入方式。整个过程不超过十分钟但能避免后面的大量返工。4. 从零手写一个属于自己的 skill附完整示例4.1 SKILL.md 的文件结构与编写套路一个能被模型正确理解和执行的 SKILL.md其实有比较固定的套路。我用一个“代码评审”技能作为例子直接给你看能跑的完整结构--- name: code-review description: 对代码变更进行系统化评审识别潜在缺陷、安全隐患和改进空间。当用户要求审查代码、分析 PR 或检查改动时使用。 --- # Code Review 技能 按以下步骤对用户提供的代码或代码变更进行评审 ## 步骤 1理解变更上下文 - 要求用户提供变更范围描述或 diff - 确认当前项目的语言与技术栈 ## 步骤 2分维度检查 1. **正确性**逻辑是否完整边界条件是否处理 2. **安全性**输入校验、注入风险、权限检查 3. **性能**循环复杂度、不必要的重复计算、资源释放 4. **可维护性**命名、函数长度、结构分层、注释质量 ## 步骤 3输出评审报告 按以下 Markdown 模板输出 - 变更概述 - 关键问题按严重程度排序 - 改进建议给出代码示例 - 是否建议合并approve / request changes这里有个很重要的细节——frontmatter 里的name和description是触发机制的灵魂。模型是通过读 description 来判断“什么时候该用这个技能”的所以写 description 一定要具体用到跟用户表达习惯匹配的关键词。比如你写“评审代码”用户说“帮我看看这段代码有没有问题”就命中不了更好的写法是包含多种可能说法“审查代码 / code review / 看看这段代码有什么问题 / review this PR”。4.2 结合真实场景给数学建模比赛写一个 skill先交代背景——现在数学建模竞赛包括华为杯、国赛等越来越卷很多参赛队伍开始用 Codex 或 Claude Code 搭配 skills 来提效。我看到的热搜词里就有人在找“数学建模 skills 推荐”这确实是个非常实用且容易上手的场景。我写过一个“数学建模论文评审”skill目标用途非常聚焦让 AI 像数模教练一样审阅论文从摘要凝练度、模型合理性、结果分析、排版规范几个维度给意见。核心 SKILL.md 片段--- name: math-model-paper-review description: 对数学建模竞赛论文进行系统性评审。当用户提供论文文件、要求评审建模论文、检查论文摘要或模型方法时使用。 --- # 数模论文评审流程 ## 输入要求 - 优先接收 PDF / Markdown / Word 格式论文 - 若是图片或扫描件先进行 OCR 转换 ## 评审维度按权重排序 1. 摘要35%研究问题概述、模型创新点、求解算法、结果精炼 2. 模型构建30%假设合理性、数学表达规范性、与问题的贴合度 3. 求解与结果20%算法选择、结果呈现、敏感性分析 4. 排版与表达15%图表规范、公式编号、参考文献 ## 输出格式 - 总评分满分 100 - 每个维度的得分与一句评语 - 优先级最高的三个改进建议附修改示例有了这个 skill 之后队员写完一版论文直接在终端发一句“用数学建模评审技能看一下这篇论文”AI 就会自动按这个程序走完输出结论。这比一遍遍人工复读 prompt 稳定太多了。同样的套路你可以往任何竞赛场景扩展数据清洗脚本模板、时间序列预测代码生成、论文公式排版修正等都能封装成独立技能。4.3 测试与迭代技能不是“写一次”就完了写完一个 skill离“好用”还有很大距离。我的习惯是分三轮迭代第一轮基础可用性测试。给一个最简单的输入看模型能不能正确读取 SKILL.md 并按步骤走。如果它压根没触发多半是 description 写得不够明确或者触发词覆盖不全。第二轮边界输入测试。喂一个不好处理的输入比如“这个 PDF 里的表格很乱怎么办”看技能有没有兜底逻辑。没有的话加一个“输入格式异常时”的处理分支。第三轮真实场景打磨。把自己真实工作里最典型的三五个请求各跑一遍把 SKILL.md 里输出模板反复调整。比如我的数模评审技能第一次输出的“改进建议”太笼统我就加了“每一条建议必须附带一个具体的修改代码或重写片段”这个约束质量才上来。注意写技能最忌讳的是贪大求全。一个 skill 只解决一个高度聚焦的任务多任务场景就拆成多个小型技能编排使用。写得越宽泛触发准确率越低执行质量也越差。5. 常用技能库与场景实战5.1 值得收藏的开源技能库我把常用的、质量相对可靠的技能库整理成了一张清单你可以直接当导航用。注意这些库的热度变化比较快clone 之前先看下最近是否有 commit。仓库主要特色适用工具superpower-skills聚合技能包覆盖文档处理、图像、研究、日程等Claude Codeanthropics/skills官方展示技能库含 PDF、PPT、docx、xlsx 处理Claude Codetypesafe-ai/skills面向浏览器自动化、Markdown 处理等专项技能Claude Code / 兼容工具opencode 官方技能市场围绕开源开发流程的技能安装方便OpenCodeawesome-codex / AGENTS.md 合集项目级约束模板适用于 Codex 工作流Codex这里特别提一下 Anthropic 官方出品的那些文档处理类技能。我试过它的 PDF 技能能把一份几百页的 PDF 抽取成结构化 Markdown支持自动识别目录、提取表格、保留标题层级效果比自己写正则脚本好太多。日常办公场景下这种“顺序思考 文档拆解”的能力正是普通人最缺的。5.2 场景一前端开发的 skills 组合前端开发是我个人用得最深的方向也最能体现技能组合的威力。我给你列一套我常用的“前端开发技能栈”component-review skill让模型像高级前端工程师一样评审组件代码重点看 props 设计、渲染性能、可访问性、状态管理方式。css-refactor skill接收一段 CSS 文件自动识别重复样式、无用的选择器、可抽取的设计变量输出重构方案。website-fetcher skill抓取目标网站页面结构并生成“改版建议报告”适合做竞品分析。release-note skill从最近的 git log 和 PR 标题里生成精炼的版本更新说明。这套组合的用法很灵活。比如我在重构一个长期维护的老项目时会让模型先跑 component-review把有问题的组件清单列出来再针对高优先级的组件让 css-refactor 技能出重构方案。这样每个技能只干一件事但组合在一起就是一个完整的“前端健康检查 重构”流水线。5.3 场景二AI 漫剧创作的批量流程AI 漫剧最近特别火很多人用 AI 生成分镜、角色、台词和配音。但真正做起来你会发现最耗时间的不是“生成画面”这一下而是“把脚本转成分镜描述、把分镜描述转成提示词、把几千个提示词批量喂给生图工具”这种重复性工作流。Skills 在这块的价值被很多人低估了。我见过一个团队分享的“AI 漫剧常用技能”配置看完觉得思路很值得复制script-to-storyboard skill把一段剧本文本按场景切分输出表格化的分镜包含镜头编号、景别、角色、动作、台词、情绪。storyboard-to-prompt skill把分镜表格转成生图模型的提示词会根据角色设定自动添加风格词、光线词、质量标签。caption-style skill把生成的台词批量套用统一的字幕格式输出带时间轴标记的 SRV 文件。这里面最核心的并不是某个单一技能而是技能接力——上一个技能的输出格式正好是下一个技能的输入格式。设计技能时留好“接口”可以让多个技能像流水线一样协作。你在写自己的技能时如果在 SKILL.md 里明确了输出格式后面的人或者你自己的下一个技能就能无缝接上。5.4 场景三数学建模竞赛提效说回数学建模。我看热搜里提到“华为杯建模比赛好用的 codex skills”确实有不少队伍在往这个方向押注。但作为建议我不推荐你去网上找一个“全家桶”就完事更实用的做法是围绕竞赛的三个核心赛道各配一个技能数据探索技能自动识别数据集类型、列分布、缺失值、相关性输出一份“数据体检报告”。模型选择技能根据问题类型分类、回归、优化、预测推荐 3 种候选模型比较优缺点并给出调参建议。论文排版技能把杂乱的结果输出转成规范的论文图表和公式描述。这三件套几乎覆盖了建模比赛从数据处理到论文写作的主链路。而且每一件的输入输出都很清晰适合在比赛最后冲刺阶段让 AI 快速处理重复性工作把人力从“写代码调参”中解放出来集中到建模思路和创新点上。6. 实用避坑指南与技能清理6.1 我踩过的 5 个 skills 大坑技能用多了坑自然就踩出来了。这里挑五个最常见的按遭遇到的频率排序每一条都是真金白银的教训。第一坑装了太多技能模型判断混乱。我一度把二三十个技能全挂进~/.claude/skills/结果模型面对一个简单问题时要先做“超集匹配”经常挑错技能甚至出现两个技能同时响应导致指令冲突。解决方式是只保留日常高频前 8~10 个低频的单独放扩展目录用时再挂载。第二坑description 写得太文艺触发不精准。我早期写过一个“文档整理”技能description 写的是“让混乱的内容变得有序”结果它基本从未被自动触发。后来改成“将 Markdown 文档按标题结构重组并生成目录当用户要求整理文档结构、重新组织文章层级时使用”触发率直接起飞。记住description 是给模型看的索引不是给人看的介绍。第三坑忽略上下文溢出。有些技能喜欢在 SKILL.md 里堆大量示例和背景知识模型每次触发都要读入一大段 token不仅拖慢响应还挤占上下文窗口导致对话中后期质量下滑。现在我的经验是SKILL.md 控制在 200 行以内外部参考文件放 resources只有需要时才读取。第四坑脚本权限没配好。有的技能会带 Python 或 Shell 脚本但工具默认可能不允许执行。在查看日志时经常会看到“Action permission denied”之类的错误。配置里需要手动开放特定脚本的执行权限不然技能就是“读了没做”的状态。第五坑跨工具格式混用。我试过把 Claude Code 的技能文件直接丢到 Codex 的 AGENTS.md 里结果组织方式完全不同模型理解的是“项目上下文”而不是“可执行技能”。现在我的原则是同一个仓库里每个工具的技能文件单独建目录各维护各的格式规范。6.2 技能清理方法论tibs 推荐的思路实践关于技能清理我在网上看到过 tibo 分享的一套思路自己实操后觉得确实有效结合自己的习惯改良成了“三步清理法”第一步盘存量。把所有技能目录列出来按最近 30 天的实际调用次数排序。为零使用和低使用率的技能单独标记移出自动加载目录。第二步看依赖。检查哪些技能引用了重复的脚本或资源比如我有三个不同的技能都内置了一份“日期处理”脚本清理时统一抽到一个公共工具目录技能内改为引用路径。这样既减小体积也方便后续升级。第三步建仓库。把清理后保留的技能纳入你自己的 git 仓库管理写清楚 README标注适用场景、触发词、责任人。别人拿到你的技能库看一遍 README 就知道怎么用这才是“可交付”的技能资产。清理方法论之所以重要是因为技能库跟代码库一样不维护就会腐化。每写完一个技能我都在 README 里加一条“最近使用场景”备注三个月后回看哪些技能在吃灰一目了然。提示清理不是删掉就完事。把低频技能挪到一个archive/目录里比直接删除更稳妥万一哪天需要重启你不需要重新下载和配置。6.3 加速加载与配置管理小技巧最后分享几个实用小技巧都是我在长时间使用中磨出来的。环境变量隔离不同项目的技能需求可能不同通过工具的环境配置为每个项目单独指定技能目录避免项目间互相“污染”。技能软链接如果你同时用多个工具想共享同款技能可以用符号链接把技能目录挂到各工具的对应路径下不用复制多份。定期跑“技能审计”每个月花十五分钟检查哪些技能版本落后了哪些技能已经没人用了哪些技能和另一款工具的新特性冲突。掌握技能的 CLI 命令比如 OpenCode 有opencode skills list和opencode skills doctor能列出当前技能和诊断潜在问题建议把这些高级命令用起来比手动翻目录高效得多。最后再分享一点个人心得技能这个事儿说到底是一种“AI 时代的个人知识管理”方式。你现在写的每个 skill不只是给 AI 用的说明书更是对自己工作流的一次梳理和抽象。我写了几十个技能之后最大的感触不是“AI 变强了”而是“我对自己的做事方法更清楚了”。比如我原来从不觉得自己的代码评审流程有章法可循直到为了写技能被迫把步骤一条条列出来才发现原来我一直在凭感觉审代码而这个技能反过来帮我把评审水准拉齐了。关于 skills 的学习路径我建议你按这样的顺序走先用现成的、再改现成的、最后写自己的。前面 20 个技能用下来基本就能建立起对“什么封装成技能、什么不该封装”的判断力。后面越写越顺你甚至会开始给生活里非编程的场景做技能——做菜步骤、学习计划、PPT 模板凡事皆可技能化。技能库会越攒越厚值得定期整理归档。技术变化快今天好用的技能下个月可能就被模型能力本身取代了但“把经验固化为资产”这一点永远不会过时。 先聊个事儿如果你最近刷 X、逛 GitHub Trending一定被一个词刷屏了——skills。前端开发有 skillsClaude Code 能装 GitHub 上的 skillsOpenCode 在搞 skills数学建模比赛有人用 codex skills 拿奖AI 漫剧创作者靠 skills 批量出片。这个原本平淡的英文单词在 2025 年成了 AI 编程圈最火的“包”概念。我电脑里现在躺着十几个 skills从写周报到读论文、从调参 bug 到画架构图日常的 AI 协作效率大概提了有三四倍今天就把我攒下的这套经验完整拆给你。这篇内容会覆盖 skills 的底层逻辑、主流工具Claude Code / Codex / OpenCode的安装玩法、如何手写一个属于自己的 skill、有哪些现成技能库值得收藏以及我踩过的坑和清理方法。不管你是刚接触 AI 编程工具的新手还是已经在用但想搞懂“技能到底怎么武装”的老手这篇应该都能给你点实在的参考。1. skills 到底是什么从提示词到“可复用技能包”1.1 skills 解决的第一个痛点每次都在重复教 AI先说个我自己的真实经历。2024 年底我用 Claude Code 写项目每开一个新仓库都要在对话里花十几分钟重新“调教”模型你该怎么读这个项目、遇到报错怎么处理、测试要写到什么程度、代码风格偏好是什么。好不容易这套话术跑顺了换个项目全得重来。这种重复劳动特别折磨人而且每次复述都会有信息损耗——今天忘了说“不要改测试文件”明天忘了提“提交前先跑 lint”结果就是模型时不时给你搞出点“蠢操作”。后来我看到 Anthropic 官方推了 Agent Skills 的概念一下就通了skill 就是把“如何完成某类任务”的完整经验封装成一个可复用、可分享、可版本化的文件包。它跟提示词的本质区别在于提示词是每次对话临时打的草稿skill 是沉淀下来的标准作业程序。你不需要再给 AI 讲一遍该怎么做事只要说一句“用一下我的 code-review skill”它就知道按什么步骤、看哪些点、以什么格式输出审查结论。用生活化一点的类比提示词相当于你每次请一个新来的实习生都得从“怎么用复印机”开始教而 skill 相当于给这个实习生一份岗位手册他翻开就知道流程和标准。前者是每换一个人重新教后者是一劳永逸地沉淀经验。1.2 skills 的“技能包”结构为什么它比提示词更靠谱真正用过之后你会发现skill 不是简单把提示词换个后缀名而是一整套结构化资产。一个规范的 skill 通常包含三个部分SKILL.md 主文件定义这个技能的用途、适用场景、执行步骤、输出规范是整个技能包的大脑。脚本与工具代码比如 Python / Shell 脚本机器能执行的动作交给脚本模型负责调度和判断人机互补。参考资料与模板比如领域知识文档、输出模板、示例样本给模型“现成的答案素材”减少从零生成的不确定性。这种结构与纯文本提示词相比最大的优势是可编程性。模型在运行 skill 时不只是读一段文字然后照做而是可以调用脚本、解析文件、生成结构化输出。相当于你把“怎么做这件事”的每个环节都拆开、编码、固化AI 干起活来像是用规范工具而非靠聊天直觉。这个设计直接影响了后来所有 AI 编程工具的演进方向。Claude Code 在 2025 年把 skills 作为核心特性之一OpenAI 的 Codex 也加入了基于 AGENTS.md 的技能机制而开源生态里 OpenCode、Cline 等工具则各自实现了兼容或扩展方案。可以说skills 已经不只是提示词工程的花式玩法而是成了 AI 协作工作流的基础设施。2. 主流 AI 编程工具的 skills 支持现状选型2.1 四款主流工具横向对比我实际用过的、对 skills 支持比较成熟的有四款Claude Code、CodexOpenAI、OpenCode、Cline。这四款各有各的设计思路放个对照表让你一眼看明白差异。工具技能格式存放位置加载方式我的使用评价Claude CodeAgent Skills 官方格式SKILL.md 资源~/.claude/skills/或项目.claude/skills/关键词自动触发或/skills手动调用最成熟稳定生态最丰富我的主力CodexOpenAIAGENTS.md 驱动 prompt 约定项目根目录AGENTS.md项目级自动加载跟“代码补全”场景绑定较深适合仓库级约束OpenCode兼容多种格式含 SKILL.md项目.opencode/skills/等配置声明 自动发现开源灵活适合爱折腾的人Cline自定义规则文件 插件化插件市场 / 项目规则文件插件安装后按规则运行更像是“规则包”还没到完全体技能库先说结论如果只选一个工具深度玩 skills我推荐 Claude Code。原因不复杂——它的 skills 机制设计得最完整、文档最清晰、社区沉淀的现成技能最多而且~/.claude/skills/的全局目录设计让跨项目复用变得极其自然。但这不代表其他工具不值得了解因为技能生态正在快速融合很多 skills 格式也开始互相兼容。2.2 各工具的安装与管理差异安装体验上这四款差别还挺大值得单独说说。Claude Code 装一个 skill 最简单粗暴的方式就是把仓库克隆到~/.claude/skills/目录下一个子目录就是一个技能。比如你把skill-name这个仓库克隆到~/.claude/skills/skill-name然后在对话里提起相关需求模型就会自动去读 SKILL.md 并按流程执行。手动控制的话配置里加一个allowedSkills声明即可。Codex 的做法不太一样它更强调“项目级约束”。你需要在项目根目录维护一份AGENTS.md里面写清楚当前项目的技术栈、目录结构、编码规范、常用命令。Codex 每次启动都会自动加载这份文件相当于给模型装了一个“裸机环境驱动”。想更新技能就直接改文件不用重装什么包。OpenCode 是最有野心的一个它的 skills 系统允许你挂载多种格式本地目录、远程 Git 仓库、甚至 npm 包里的内置技能。安装时改一个opencode.json配置文件就可以。这个灵活性对进阶玩家很友好但对新手来说配置项有点多容易踩坑。Cline 目前更像“规则包 插件”的混合体它有一些内置的插件市场也支持你自己写.clinerules文件。跟前面几款比Cline 的技能生态还没那么丰富但如果你本身主力工具就是 Cline它的规则文件依然能覆盖大部分“固化流程”的需求。3. 手把手实操如何安装和使用 GitHub 上的 skills3.1 快速安装克隆命令与目录结构无论你用哪款工具从 GitHub 装 skills 的底层逻辑基本一致把远程仓库拉到本地指定目录让工具能发现并使用它。我以 Claude Code 为例给出一套最通用、最不容易出错的完整流程。# 1. 确保技能目录存在 mkdir -p ~/.claude/skills # 2. 克隆你找到的技能仓库示例为超级技能合集包 git clone https://github.com/superpowerlabs/superpower-skills.git ~/.claude/skills/superpower-skills # 3. 查看是否安装成功应能看到 SKILL.md 文件 ls ~/.claude/skills/superpower-skills装完不是就完事了你需要在 Claude Code 的配置里确认是否允许这个技能被加载。打开工具设置找到allowedSkills相关配置把技能名加进去。现在这个工具就可以在对话里自动识别相关任务并加载技能了。Codex 的安装思路是“无全局目录”模式更简洁——直接把 AGENTS.md 放到你的项目根目录即可# 把下载的 AGENTS.md 放到项目根目录 curl -o AGENTS.md https://raw.githubusercontent.com/xxx/awesome-codex/main/AGENTS.md # 验证 cat AGENTS.mdOpenCode 的配置方式稍微绕一点但它支持远程技能库这一点我特别喜欢。在opencode.json里声明一个技能{ skills: { my-skill: { path: ~/.opencode/skills/my-skill, enabled: true } } }也可以直接用 CLIopencode skills install github-username/repo-name3.2 superpower skills 这类“聚合包”到底装不装现在 GitHub 上有很多所谓的“超级技能包”最出名的就是 superpower-skills宣称包含了几十个实用技能。这类包我的态度是可以装但别无脑用。聚合包的优点是省事——克隆下来就有一堆技能而且能启发你对“原来这也算一个技能”的认知。缺点是很多技能质量良莠不齐有的跟你的工作流根本不匹配还有些技能之间会有指令冲突挂在~/.claude/skills/下反而增加了模型判断负担甚至拉低响应速度。我的做法是把聚合包装在一个独立目录里比如~/.claude/skills/superpower-skills/而不是直接平铺进skills根目录。这样我可以随时按需引入而不是让所有技能都自动可见。等我把里面真正有用的技能挑出来了再单独摘出来放到自己维护的技能目录中。3.3 实操心得安装后最好做一遍“技能体检”很多人装完技能就急着用结果发现 AI 根本没按预期工作。这里有个关键经验每个 skill 的最佳触发词和输入格式跟你以为的不一定一样。我装完一个新技能第一件事是看它的 SKILL.md搞清楚两个问题——它的name和description里写了什么触发条件以及它的执行步骤里第一步要什么样的输入。举个例子我装过一个“周报生成”技能SKILL.md 里写的触发场景是“weekly report / weekly summary”但你直接说“帮我写个周报”也能命中。可它期望的输入格式是“本周做了这些事勾选列表”而不是一段散文。你要是第一步就给了一段散文它生成的周报质量会大打折扣。建议流程装完技能 → 读 SKILL.md → 用一行最简洁的指令测试 → 对比输出质量 → 调整输入方式。整个过程不超过十分钟但能避免后面的大量返工。4. 从零手写一个属于自己的 skill附完整示例4.1 SKILL.md 的文件结构与编写套路一个能被模型正确理解和执行的 SKILL.md其实有比较固定的套路。我用一个“代码评审”技能作为例子直接给你看能跑的完整结构--- name: code-review description: 对代码变更进行系统化评审识别潜在缺陷、安全隐患和改进空间。当用户要求审查代码、分析 PR 或检查改动时使用。 --- # Code Review 技能 按以下步骤对用户提供的代码或代码变更进行评审 ## 步骤 1理解变更上下文 - 要求用户提供变更范围描述或 diff - 确认当前项目的语言与技术栈 ## 步骤 2分维度检查 1. **正确性**逻辑是否完整边界条件是否处理 2. **安全性**输入校验、注入风险、权限检查 3. **性能**循环复杂度、不必要的重复计算、资源释放 4. **可维护性**命名、函数长度、结构分层、注释质量 ## 步骤 3输出评审报告 按以下 Markdown 模板输出 - 变更概述 - 关键问题按严重程度排序 - 改进建议给出代码示例 - 是否建议合并approve / request changes这里有个很重要的细节——frontmatter 里的name和description是触发机制的灵魂。模型是通过读 description 来判断“什么时候该用这个技能”的所以写 description 一定要具体用到跟用户表达习惯匹配的关键词。比如你写“评审代码”用户说“帮我看看这段代码有没有问题”就命中不了更好的写法是包含多种可能说法“审查代码 / code review / 看看这段代码有什么问题 / review this PR”。4.2 结合真实场景给数学建模比赛写一个 skill先交代背景——现在数学建模竞赛包括华为杯、国赛等越来越卷很多参赛队伍开始用 Codex 或 Claude Code 搭配 skills 来提效。我看到的热搜词里就有人在找“数学建模 skills 推荐”这确实是个非常实用且容易上手的场景。我写过一个“数学建模论文评审”skill用途非常聚焦让 AI 像数模教练一样审阅论文从摘要凝练度、模型合理性、结果分析、排版规范几个维度给意见。核心 SKILL.md 片段--- name: math-model-paper-review description: 对数学建模竞赛论文进行系统性评审。当用户提供论文文件、要求评审建模论文、检查论文摘要或模型方法时使用。 --- # 数模论文评审流程 ## 输入要求 - 优先接收 PDF / Markdown / Word 格式论文 - 若是图片或扫描件先进行 OCR 转换 ## 评审维度按权重排序 1. 摘要35%研究问题概述、模型创新点、求解算法、结果精炼 2. 模型构建30%假设合理性、数学表达规范性、与问题的贴合度 3. 求解与结果20%算法选择、结果呈现、敏感性分析 4. 排版与表达15%图表规范、公式编号、参考文献 ## 输出格式 - 总评分满分 100 - 每个维度的得分与一句评语 - 优先级最高的三个改进建议附修改示例有了这个 skill 之后队员写完一版论文直接在终端发一句“用数学建模评审技能看一下这篇论文”AI 就会自动按这个程序走完输出结论。这比一遍遍人工复读 prompt 稳定太多了。同样的套路你可以往任何竞赛场景扩展数据清洗脚本模板、时间序列预测代码生成、论文公式排版修正等都能封装成独立技能。4.3 测试与迭代技能不是“写一次”就完了写完一个 skill离“好用”还有很大距离。我的习惯是分三轮迭代第一轮基础可用性测试。给一个最简单的输入看模型能不能正确读取 SKILL.md 并按步骤走。如果它压根没触发多半是 description 写得不够明确或者触发词覆盖不全。第二轮边界输入测试。喂一个不好处理的输入比如“这个 PDF 里的表格很乱怎么办”看技能有没有兜底逻辑。没有的话加一个“输入格式异常时”的处理分支。第三轮真实场景打磨。把自己真实工作里最典型的三五个请求各跑一遍把 SKILL.md 里输出模板反复调整。比如我的数模评审技能第一次输出的“改进建议”太笼统我就加了“每一条建议必须附带一个具体的修改代码或重写片段”这个约束质量才上来。注意写技能最忌讳的是贪大求全。一个 skill 只解决一个高度聚焦的任务多任务场景就拆成多个小型技能编排使用。写得越宽泛触发准确率越低执行质量也越差。5. 常用技能库与场景实战5.1 值得收藏的开源技能库我把常用的、质量相对可靠的技能库整理成了一张清单你可以直接当导航用。注意这些库的热度变化比较快clone 之前先看下最近是否有 commit。仓库主要特色适用工具superpower-skills聚合技能包覆盖文档处理、图像、研究、日程等Claude Codeanthropics/skills官方展示技能库含 PDF、PPT、docx、xlsx 处理Claude Codetypesafe-ai/skills面向浏览器自动化、Markdown 处理等专项技能Claude Code / 兼容工具opencode 官方技能市场围绕开源开发流程的技能安装方便OpenCodeawesome-codex / AGENTS.md 合集项目级约束模板适用于 Codex 工作流Codex这里特别提一下 Anthropic 官方出品的那些文档处理类技能。我试过它的 PDF 技能能把一份几百页的 PDF 抽取成结构化 Markdown支持自动识别目录、提取表格、保留标题层级效果比自己写正则脚本好太多。日常办公场景下这种“顺序思考 文档拆解”的能力正是普通人最缺的。5.2 场景一前端开发的 skills 组合前端开发是我个人用得最深的方向也最能体现技能组合的威力。我给你列一套我常用的“前端开发技能栈”component-review skill让模型像高级前端工程师一样评审组件代码重点看 props 设计、渲染性能、可访问性、状态管理方式。css-refactor skill接收一段 CSS 文件自动识别重复样式、无用的选择器、可抽取的设计变量输出重构方案。website-fetcher skill抓取目标网站页面结构并生成“改版建议报告”适合做竞品分析。release-note skill从最近的 git log 和 PR 标题里生成精炼的版本更新说明。这套组合的用法很灵活。比如我在重构一个长期维护的老项目时会让模型先跑 component-review把有问题的组件清单列出来再针对高优先级的组件让 css-refactor 技能出重构方案。这样每个技能只干一件事但组合在一起就是一个完整的“前端健康检查 重构”流水线。5.3 场景二AI 漫剧创作的批量流程AI 漫剧最近特别火很多人用 AI 生成分镜、角色、台词和配音。但真正做起来你会发现最耗时间的不是“生成画面”这一下而是“把脚本转成分镜描述、把分镜描述转成提示词、把几千个提示词批量喂给生图工具”这种重复性工作流。Skills 在这块的价值被很多人低估了。我见过一个团队分享的“AI 漫剧常用技能”配置看完觉得思路很值得复制script-to-storyboard skill把一段剧本文本按场景切分输出表格化的分镜包含镜头编号、景别、角色、动作、台词、情绪。storyboard-to-prompt skill把分镜表格转成生图模型的提示词会根据角色设定自动添加风格词、光线词、质量标签。caption-style skill把生成的台词批量套用统一的字幕格式输出带时间轴标记的文件。这里面最核心的并不是某个单一技能而是技能接力——上一个技能的输出格式正好是下一个技能的输入格式。设计技能时留好“接口”可以让多个技能像流水线一样协作。你在写自己的技能时如果在 SKILL.md 里明确了输出格式后面的人或者你自己的下一个技能就能无缝接上。5.4 场景三数学建模竞赛提效说回数学建模。我看热搜里提到“华为杯建模比赛好用的 codex skills”确实有不少队伍在往这个方向押注。但作为建议我不推荐你去网上找一个“全家桶”就完事更实用的做法是围绕竞赛的三个核心赛道各配一个技能数据探索技能自动识别数据集类型、列分布、缺失值、相关性输出一份“数据体检报告”。模型选择技能根据问题类型分类、回归、优化、预测推荐 3 种候选模型比较优缺点并给出调参建议。论文排版技能把杂乱的结果输出转成规范的论文图表和公式描述。这三件套几乎覆盖了建模比赛从数据处理到论文写作的主链路。而且每一件的输入输出都很清晰适合在比赛最后冲刺阶段让 AI 快速处理重复性工作把人力从“写代码调参”中解放出来集中到建模思路和创新点上。6. 实用避坑指南与技能清理6.1 我踩过的 5 个 skills 大坑技能用多了坑自然就踩出来了。这里挑五个最常见的按遭遇到的频率排序每一条都是真金白银的教训。第一坑装了太多技能模型判断混乱。我一度把二三十个技能全挂进~/.claude/skills/结果模型面对一个简单问题时要先做“超集匹配”经常挑错技能甚至出现两个技能同时响应导致指令冲突。解决方式是只保留日常高频前 8~10 个低频的单独放扩展目录用时再挂载。第二坑description 写得太文艺触发不精准。我早期写过一个“文档整理”技能description 写的是“让混乱的内容变得有序”结果它基本从未被自动触发。后来改成“将 Markdown 文档按标题结构重组并生成目录当用户要求整理文档结构、重新组织文章层级时使用”触发率直接起飞。记住description 是给模型看的索引不是给人看的介绍。第三坑忽略上下文溢出。有些技能喜欢在 SKILL.md 里堆大量示例和背景知识模型每次触发都要读入一大段 token不仅拖慢响应还挤占上下文窗口导致对话中后期质量下滑。现在我的经验是SKILL.md 控制在 200 行以内外部参考文件放 resources只有需要时才读取。第四坑脚本权限没配好。有的技能会带 Python 或 Shell 脚本但工具默认可能不允许执行。在查看日志时经常会看到“Action permission denied”之类的错误。配置里需要手动开放特定脚本的执行权限不然技能就是“读了没做”的状态。第五坑跨工具格式混用。我试过把 Claude Code 的技能文件直接丢到 Codex 的 AGENTS.md 里结果组织方式完全不同模型理解的是“项目上下文”而不是“可执行技能”。现在我的原则是同一个仓库里每个工具的技能文件单独建目录各维护各的格式规范。6.2 技能清理方法论tibs 推荐的思路实践关于技能清理我在网上看到过 tibo 分享的一套思路自己实操后觉得确实有效结合自己的习惯改良成了“三步清理法”第一步盘存量。把所有技能目录列出来按最近 30 天的实际调用次数排序。为零使用和低使用率的技能单独标记移出自动加载目录。第二步看依赖。检查哪些技能引用了重复的脚本或资源比如我有三个不同的技能都内置了一份“日期处理”脚本清理时统一抽到一个公共工具目录技能内改为引用路径。这样既减小体积也方便后续升级。第三步建仓库。把清理后保留的技能纳入你自己的 git 仓库管理写清楚 README标注适用场景、触发词、责任人。别人拿到你的技能库看一遍 README 就知道怎么用这才是“可交付”的技能资产。清理方法论之所以重要是因为技能库跟代码库一样不维护就会腐化。每写完一个技能我都在 README 里加一条“最近使用场景”备注三个月后回看哪些技能在吃灰一目了然。提示清理不是删掉就完事。把低频技能挪到一个archive/目录里比直接删除更稳妥万一哪天需要重启你不需要重新下载和配置。6.3 加速加载与配置管理小技巧最后分享几个实用小技巧都是我在长时间使用中磨出来的。环境变量隔离不同项目的技能需求可能不同通过工具的环境配置为每个项目单独指定技能目录避免项目间互相“污染”。技能软链接如果你同时用多个工具想共享同款技能可以用符号链接把技能目录挂到各工具的对应路径下不用复制多份。定期跑“技能审计”每个月花十五分钟检查哪些技能版本落后了哪些技能已经没人用了哪些技能和另一款工具的新特性冲突。掌握技能的 CLI 命令比如 OpenCode 有opencode skills list和opencode skills doctor能列出当前技能和诊断潜在问题建议把这些高级命令用起来比手动翻目录高效得多。最后再分享一点个人心得技能这个事儿说到底是一种“AI 时代的个人知识管理”方式。你现在写的每个 skill不只是给 AI 用的说明书更是对自己工作流的一次梳理和抽象。我写了几十个技能之后最大的感触不是“AI 变强了”而是“我对自己的做事方法更清楚了”。比如我原来从不觉得自己的代码评审流程有章法可循直到为了写技能被迫把步骤一条条列出来才发现原来我一直在凭感觉审代码而这个技能反过来帮我把评审水准拉齐了。关于 skills 的学习路径我建议你按这样的顺序走先用现成的、再改现成的、最后写自己的。前面 20 个技能用下来基本就能建立起对“什么封装成技能、什么不该封装”的判断力。后面越写越顺你甚至会开始给生活里非编程的场景做技能——做菜步骤、学习计划、PPT 模板凡事皆可技能化。技能库会越攒越厚值得定期整理归档。技术变化快今天好用的技能下个月可能就被模型能力本身取代了但“把经验固化为资产”这一点永远不会过时。