最近后台一直有人问我同一件事GitHub 上那些铺天盖地的“skills”到底是什么Claude Code 怎么手动装别人的 skills数学建模该装哪些 skills甚至还有人问 skills 到底要不要自己写。我干脆把这段时间折腾 skills 的完整记录整理成一篇从原理到安装、从选品到自写、从清理到排坑一次性讲清楚。这篇文章适合三类人刚接触 Claude Code / Codex CLI 但被 skills 绕晕的新手想给数学建模、前端开发、AI 漫剧这类具体场景找现成技能的实践者以及已经装了不少 skills、想自己写一个然后好好管起来的老手。1. Skills到底是什么给AI装一张“职业模板”1.1 一个SKILL.md包起来的专业工作流先说结论一个 skill 本质上就是一个以 SKILL.md 为核心的文件夹。SKILL.md 是 markdown 文件开头有一段 YAML 格式的 frontmatter里面写 name、description 这些元信息正文则是一套完整的作业流程。AI 编程工具启动时会扫描 skills 目录把所有可用技能的描述加载进系统提示词。等到对话里出现了符合某个 skill 描述的场景模型就会自动“调用”这个技能把 SKILL.md 正文注入当前上下文然后按里面写的步骤干活。这个机制和生活里“给新人发工作手册”非常像。你招一个数据分析师光说“你帮我处理一下数据”是不够的你得给他一张流程图、一份质检标准、几个能照着写的表格模板。skills 就是干这件事的把“怎么处理数据、用什么库、输出什么格式、哪些坑不要踩”全部编译成一份标准作业程序。AI 每次遇到同类任务直接照单执行效率和一致性立刻上来了。为什么大家最近都在聊 skills因为 Claude Code 把 Agent Skills 的规范公开之后GitHub 上的生态一下就起来了。官方有 anthropics/skills 仓库社区有 awesome-claude-skills 这类合集连专门聚合 skill 的第三方站点也冒了出来。这些仓库里存的不再是单纯的“提示词”而是一整套经过实战验证的工作流。再加上 Codex CLI、OpenCode 这些工具也在跟进skills 这个概念就从一个工具的私货变成了整个 AI 编程领域通用的标准做法。1.2 它和普通提示词有什么本质区别很多人第一反应是这不就是预设提示词吗其实差别挺大。普通提示词是你每次对话前手动粘贴一段话AI 只能在那次对话里记住它。skills 是把这段“话”变成文件、放进固定目录、由工具在启动时自动加载模型再根据业务场景自动决定用哪个。换句话说普通提示词是“人肉接线员”每一次都要手工接通skill 是“自动路由”AI 遇到对应场景自己拿起正确的手册。具体差别我整理了一张表维度普通提示词Skill加载方式手动复制/输入工具启动时自动加载触发逻辑靠用户主动模型按 description 自动判断复用性每次重贴文件持久化跨会话复用版本管理无Git 管理可迭代附带资源纯文本可带脚本、模板、参考文件共享方式复制粘贴发布到 GitHub直接 clone这个差异带来的直接好处是skill 可以像代码一样被 review、被贡献、被版本控制。社区里一个成熟的 skill 往往经过很多人迭代你 clone 下来就能用比自己贴提示词靠谱得多。而且由于它是“按场景自动触发”你不需要记住自己装过什么只要干活的时候提到了对应场景AI 会自动把合适的工具翻出来。1.3 各工具对skills的支持方式目前主流几款工具对 skills 的支持方式大同小异都是“放进特定目录→启动时扫描→注入描述”。差别只在目录和命名约定上工具用户级目录项目级目录说明Claude Code~/.claude/skills/.claude/skills/官方 Agent Skills 规范Codex CLI~/.codex/skills/.codex/skills/社区兼容规范持续演进OpenCode各有不同.opencode/skills/支持但文档还不算完善装的时候先分清这两个目录再动手比什么都重要。用户级目录对所有项目生效适合放通用技能项目级目录只对当前项目生效适合放业务专属技能。下面进入实操。2. 手动安装GitHub上的skillsClaude Code全流程实录2.1 先把安装位置和来源搞清楚安装的方法一句话就能说清把目标 skill 文件夹放进工具的 skills 目录然后重启会话。但你要是真去 GitHub 上 clone 一个仓库回来会发现里面结构乱七八糟有的仓库是整个合集有的仓库里套着仓库有的直接就是一套配置散在十几个子目录里。所以先弄清楚来源类型再规划安装方式。对着三种常见来源我的处理办法是官方 / 成熟合集仓库比如 anthropics/skills整个 clone 下来把里面需要的子目录拷贝或软链到自己的 skills 目录。单一 skill 仓库目录顶层就是 SKILL.md直接 clone 到 skills 目录下保持文件夹名与 skill 的 name 一致。聚合型站点比如 skillsmp.com 这类市场聚合站通常会提供下载包或者 git 源按页面说明操作即可。不管哪种来源最终落到磁盘上的结构都必须是skills/skill-name/SKILL.md。这是所有工具约定俗成的扫描规则层级稍微套错工具就扫不到。2.2 手动安装的每一步下面以 Claude Code 为例完整走一遍手动安装 GitHub 上某个 skills 的流程。假设你想装一个叫 demo-skill 的 skill仓库地址是https://github.com/xxx/demo-skill。第一步建目录mkdir -p ~/.claude/skills cd ~/.claude/skills第二步把仓库 clone 下来git clone https://github.com/xxx/demo-skill.git注意 clone 下来的目录名可能叫 demo-skill也可能叫别的。确保它里面有一个 SKILL.md 文件目录名尽量和 frontmatter 里的 name 对齐。不对齐也能用但之后如果想手动更新、做校验对不上会很难受。第三步检查文件结构find ~/.claude/skills/demo-skill -maxdepth 2 -type f | head -20只要看到 SKILL.md 在顶层就算是装上了。如果仓库里带了 scripts、templates、references 这些子目录不用管skill 被触发时这些资源会自动作为上下文的一部分被加载。第四步重启 Claude Code 会话让它重新扫描。这里没有“安装”动作工具启动时扫一次目录重启即生效。提示不要在 skills 根目录直接扔一堆没有 SKILL.md 的散文件。很多合集仓库根目录下并没有 SKILL.md直接整包丢进去工具扫不到还会污染目录。正确姿势是把合集仓库里需要的子目录单独拷贝进来或者用ln -s软链到技能目录下。软链的好处是以后git pull更新合集仓库你的链接自动指向新内容。2.3 装完怎么验证它生效了装完别急着干活先验证一下。最简单的验证方法是直接在当前会话里“演一个触发场景”。比如你刚装的是一个数据清洗 skill就说“我有一份销售数据CSV 格式里面有缺失值帮我看看怎么处理。”这时候模型如果开始按 skill 里的流程走比如先概览 shape、dtype再给缺失值统计说明已经触发成功。如果它完全没有反应先不急着下结论按下面几步排查输入/status或类似的会话状态命令看当前会话加载的 skills 列表里有没有目标 skill。Claude Code 的/status能列出已加载的 skills。检查 SKILL.md 的 frontmatter 是否完整name 和 description 字段缺失时工具会直接跳过这个文件。确认目录层级必须是skills/skill-name/SKILL.md多套一层目录都不行。验证这一步很关键因为很多 skill 装上之后“没反应”八成是目录层级或 frontmatter 的问题跟模型本身没关系。3. 场景化skills推荐数学建模、前端与AI漫剧怎么选3.1 数学建模华为杯等竞赛的skills组合华为杯、国赛、美赛这类数学建模比赛是热词里被提到最多的场景。原因很简单建模过程的代码量极大而且步骤高度套路化——数据读取→清洗→可视化→建模→结果分析→论文排版每一步都有固定的最佳实践。把整个流程拆成几个 skills你的 AI 助手就能在比赛里像流水线一样稳定输出。我推荐的组合大概是这个方向数据处理 skill管缺失值、异常值、分布检查、单位统一、日期格式。这步是拿奖的地基数据不对后面全白搭。可视化 skill规定中文字体、DPI、配色和图表风格避免每张图长得不像同一个人画的。评审翻论文时图的一致性特别影响观感。模型库 skill把常见算法的适用条件和调用模板固定下来。综合评价类用熵权 TOPSIS预测类用回归和时间序列优化类用遗传算法、模拟退火。论文成稿 skill负责 LaTeX 三线表、公式编号、图表引用规范让排版阶段少加班。为什么热词里专门说“好用的 codex skills”因为 Codex CLI 本身就是终端里跑代码的 agent处理 CSV、执行 Python 脚本、反复出图它都能直接干。把数据处理流程做成 skill 之后比赛期间你只需要把题目的 CSV 丢给它它自动跑清洗、出图、建模效率是传统手写代码完全没法比的。几个社区里比较知名的 skills 集合比如 codex nature skills、cola skills也基本都是朝这个方向整理的想尝鲜的直接去 GitHub 按“codex skills”搜排行榜靠前的都能用。3.2 前端开发场景的skills选品前端开发是继建模之后第二个高频场景。这里选 skill 的思路不是“一个 skill 全搞定”而是按任务边界拆组件生成 skill约束文件结构、TypeScript 类型风格、样式方案生成页面组件时直接按规范输出。代码审查 skill按性能、可访问性、语义化、依赖合理性几个维度逐项过代码把机械性检查交给 AI。重构 / 升级 skill比如帮你在跑测试后自动修复 lint 错误、处理依赖升级的破坏性变更。前端类 skills 比较值得关注的两个来源一个是 superpowers 系列作者把软件工程实践拆成了几十个相互配合的小 skills适合喜欢“组合拳”的人另一个是 awesome-claude-skills 里归类的 web 开发合集。装之前建议先看 skill 正文里的示例确认它假设的框架和你的技术栈一致否则生成的代码风格会怪怪的。比如有的 skill 默认你用 Tailwind你项目里是纯 CSS生成出来的东西就得手动改半天。前端技能的另一个用法是“约束已有的编辑工作流”。我试过把团队自己的代码规范写成 skill 放进项目级目录生成代码时自动遵守实测下来比每次粘贴规范要稳得多也省了反复提醒 AI 的沟通成本。3.3 AI漫剧相关的技能包AI 漫剧是热词里比较新的方向。它本质上是批量生产带剧情的动画短片环节包括人物设定、分镜剧本、生图提示词、配音脚本每一环都是高度模板化的工作。把一个角色设定写成 skillAI 每集都能保持人物性格一致把“分镜转生图提示词”的转换规则写成 skill输出的提示词风格基本不会跑偏画面质量也更稳定。这类 skills 的存量没有编程领域多所以更多是自己写。后面第四节我会讲怎么写你只需要记住一个判断标准凡是“每次都要重复、而且有固定规范”的流程都值得写成 skill。AI 漫剧的设定卡、脚本模板、提示词风格全部符合这个条件。比如镜头描述用什么句式、角色外貌放在哪个字段、画面风格词缀固定在哪些选项里一条条列进 skill产出的内容才会像同一个团队批量做的。4. 手把手写一个自己的Skills4.1 SKILL.md 的正确写法写一个 skill 最核心的就是写对 SKILL.md。文件结构要求很固定--- name: my-cool-skill description: 当用户需要做某件事场景写清楚时使用。如果场景不匹配不要使用。 --- # 技能说明 ## 何时使用 - 场景列表 - 适用数据特征 ## 步骤 1. 详细步骤越具体越好。 2. 每一步写明输入、输出和校验方式。 ## 示例 - 好的示例 - 坏的示例 ## 禁止事项 - 不要做的事明确写出来。frontmatter 里 name 用全小写加连字符description 要写“何时用、何时不用”而不是堆砌“强大、高效、全面”这类形容词。因为模型是根据 description 来决定调不调用的描述写得太泛模型遇到无关任务也容易误触发写得太窄该触发时又完全没反应。这是整个 skill 里最值得花时间打磨的部分。正文部分的关键是“具体到可以执行”。不要写“分析数据”要写“先读取文件输出行数和列数检查每个字段的缺失率缺失率超过 20% 的列进入候选删除列表缺失率低的列按插值/众数填充”。步骤越具体模型输出越稳定。你写得越模糊模型自由发挥的空间就越大结果就越不可控。4.2 让skill更可靠的几个小技巧写多了你会发现决定 skill 质量的高低往往不在步骤而在三个容易被忽略的细节。第一给示例。好的示例让模型照葫芦画瓢坏的示例帮模型避坑。这俩比任何描述都管用。比如你写数据报表生成的 skill给一个“合格报表”的例子再给一个“看起来像合格但实际日期格式错了”的反例模型很快就能理解你要的边界在哪里。第二写“不做什么”。模型默认会自由发挥你必须在 skill 里明确禁止一些行为。比如“不要使用 pandas 的inplaceTrue修改原始数据”“不要在最终报告里保留调试输出”“不要用中文字体缺失的默认字体出图”。这类负向约束能明显减少返工而且改起来成本极低一句话的事。第三保持单技能聚焦。一个 skill 解决一类问题别想一口气搞定所有数据工作。宁可拆成三个小 skill也别写一个又大又全的“全能”技能后者往往哪个场景都触发得不好。模型在匹配多技能描述时会有优先级问题描述之间互相打架结果就是稳定的误触发。4.3 自测与迭代的完整闭环写完先别急着“发布”。我习惯用下面的流程自测在一个干净会话里用一段故意贴近 description 的话触发它看它是否按步骤走。用一段偏离场景的话测试看它是不是乱调用。让 skill 实际跑完一个最小任务检查输出是否符合正文里的格式要求。发现问题就改正文改完重复第 1 步。这个循环跑两轮基本就能把一个 skill 磨到可以日常使用的水平。你要是把写好的 skill 放到自己的 GitHub 仓库里再写清楚 README过一段时间甚至能收到别人的 issue 和 PR这也算是写 skill 的一种正反馈。我自己最初写的几个技能现在早就不用了但被社区里的人改造过的新版本还在被 fork看着还挺有成就感的。5. 管理、清理与排查别让skills变成垃圾场5.1 装了一堆skills之后清理与规范skills 装多了以后最大的问题是互相干扰。目录里堆着二三十个合集启动扫描变慢description 太多模型还容易误判。GitHub 上一位叫 tibo 的开发者分享的清理方法我试验过后一直沿用核心就三条定期列出现有 skills 清单记录每一个的触发次数长期不用的直接标灰。功能重叠的合并比如三个数据清洗类 skill合并成一个保留你最顺手的那份步骤。不要在工具里“卸载”直接删目录。一个 skill 就是普通文件删掉也不会丢什么反正 clone 一条命令能装回来。清理之后还有一个习惯值得养成把用户级目录里常用的几个 skill 用 git 管起来定期 commit。这等于给自己的技能库做版本管理回滚、同步都方便。你也可以通过软链把 dotfiles 仓库和 skills 目录连起来换新机器一条命令就能恢复整套配置。维护这块的个人建议不要追求数量。我现在用户级目录常驻的就五六个通用 skill剩下的全部放项目级目录按需加载。任何“我要不要装它”的犹豫一律先装到项目级试试稳定好用再提升为用户级。这个策略帮我避开了大量目录污染问题也不容易把自己辛辛苦苦调好的配置搞乱。5.2 常见问题与排查速查表最后把这段时间踩过的坑整理成一张排查表。遇到问题先对着表查能省下大半时间。现象可能原因排查/修复skill 完全没反应目录层级不对SKILL.md 不在顶层调整为skills/skill/SKILL.md总是误触发description 写得太泛重写 description加上“什么时候不要用”触发但步骤执行得乱正文步骤不够具体细化步骤写代码示例和反例新装的 skill 不知道装没装没重启会话重启后用/status查看加载列表多个 skill 互相抢任务frontmatter name 冲突改名或合并确保 name 唯一装完无法更新git 仓库没有 remoteclone 时保留.git之后用git pull更新还有一个容易被忽略的坑不同工具对 description 的解析优先级不一样。同一个 skills 目录拿给 Codex 和 Claude Code 用表现会有差异跨工具使用前最好先在目标工具上做一趟前面 2.3 节里的触发验证。不要图省事让所有工具共用同一个目录各开各的目录、用脚本同步能少踩很多莫名其妙的兼容问题。写到最后再分享一个小经验。很多人觉得 skills 玄乎其实它的演进逻辑和插件系统、和“工具集”没有区别先解决自己的一个具体痛点写一个 skill用熟了再扩展。我最早写第一个 skill 就是嫌每周处理报表太重复后来才慢慢把数据清洗、可视化、论文排版这些流程都成了固定配置。你现在从 GitHub 上装别人 skills 没什么门槛但真正让你工作效率拉开差距的一定是从自己流程里长出来的那部分。装完之后第一件事也别忘了用一个小任务让它实际跑一遍而不是看完 README 就当装完了——这一步几乎能帮你避开 80% 的问题。
最近后台一直有人问我同一件事GitHub 上那些铺天盖地的“skills”到底是什么Claude Code 怎么手动装别人的 skills数学建模该装哪些 skills甚至还有人问 skills 到底要不要自己写。我干脆把这段时间折腾 skills 的完整记录整理成一篇从原理到安装、从选品到自写、从清理到排坑一次性讲清楚。这篇文章适合三类人刚接触 Claude Code / Codex CLI 但被 skills 绕晕的新手想给数学建模、前端开发、AI 漫剧这类具体场景找现成技能的实践者以及已经装了不少 skills、想自己写一个然后好好管起来的老手。1. Skills到底是什么给AI装一张“职业模板”1.1 一个SKILL.md包起来的专业工作流先说结论一个 skill 本质上就是一个以 SKILL.md 为核心的文件夹。SKILL.md 是 markdown 文件开头有一段 YAML 格式的 frontmatter里面写 name、description 这些元信息正文则是一套完整的作业流程。AI 编程工具启动时会扫描 skills 目录把所有可用技能的描述加载进系统提示词。等到对话里出现了符合某个 skill 描述的场景模型就会自动“调用”这个技能把 SKILL.md 正文注入当前上下文然后按里面写的步骤干活。这个机制和生活里“给新人发工作手册”非常像。你招一个数据分析师光说“你帮我处理一下数据”是不够的你得给他一张流程图、一份质检标准、几个能照着写的表格模板。skills 就是干这件事的把“怎么处理数据、用什么库、输出什么格式、哪些坑不要踩”全部编译成一份标准作业程序。AI 每次遇到同类任务直接照单执行效率和一致性立刻上来了。为什么大家最近都在聊 skills因为 Claude Code 把 Agent Skills 的规范公开之后GitHub 上的生态一下就起来了。官方有 anthropics/skills 仓库社区有 awesome-claude-skills 这类合集连专门聚合 skill 的第三方站点也冒了出来。这些仓库里存的不再是单纯的“提示词”而是一整套经过实战验证的工作流。再加上 Codex CLI、OpenCode 这些工具也在跟进skills 这个概念就从一个工具的私货变成了整个 AI 编程领域通用的标准做法。1.2 它和普通提示词有什么本质区别很多人第一反应是这不就是预设提示词吗其实差别挺大。普通提示词是你每次对话前手动粘贴一段话AI 只能在那次对话里记住它。skills 是把这段“话”变成文件、放进固定目录、由工具在启动时自动加载模型再根据业务场景自动决定用哪个。换句话说普通提示词是“人肉接线员”每一次都要手工接通skill 是“自动路由”AI 遇到对应场景自己拿起正确的手册。具体差别我整理了一张表维度普通提示词Skill加载方式手动复制/输入工具启动时自动加载触发逻辑靠用户主动模型按 description 自动判断复用性每次重贴文件持久化跨会话复用版本管理无Git 管理可迭代附带资源纯文本可带脚本、模板、参考文件共享方式复制粘贴发布到 GitHub直接 clone这个差异带来的直接好处是skill 可以像代码一样被 review、被贡献、被版本控制。社区里一个成熟的 skill 往往经过很多人迭代你 clone 下来就能用比自己贴提示词靠谱得多。而且由于它是“按场景自动触发”你不需要记住自己装过什么只要干活的时候提到了对应场景AI 会自动把合适的工具翻出来。1.3 各工具对skills的支持方式目前主流几款工具对 skills 的支持方式大同小异都是“放进特定目录→启动时扫描→注入描述”。差别只在目录和命名约定上工具用户级目录项目级目录说明Claude Code~/.claude/skills/.claude/skills/官方 Agent Skills 规范Codex CLI~/.codex/skills/.codex/skills/社区兼容规范持续演进OpenCode各有不同.opencode/skills/支持但文档还不算完善装的时候先分清这两个目录再动手比什么都重要。用户级目录对所有项目生效适合放通用技能项目级目录只对当前项目生效适合放业务专属技能。下面进入实操。2. 手动安装GitHub上的skillsClaude Code全流程实录2.1 先把安装位置和来源搞清楚安装的方法一句话就能说清把目标 skill 文件夹放进工具的 skills 目录然后重启会话。但你要是真去 GitHub 上 clone 一个仓库回来会发现里面结构乱七八糟有的仓库是整个合集有的仓库里套着仓库有的直接就是一套配置散在十几个子目录里。所以先弄清楚来源类型再规划安装方式。对着三种常见来源我的处理办法是官方 / 成熟合集仓库比如 anthropics/skills整个 clone 下来把里面需要的子目录拷贝或软链到自己的 skills 目录。单一 skill 仓库目录顶层就是 SKILL.md直接 clone 到 skills 目录下保持文件夹名与 skill 的 name 一致。聚合型站点比如 skillsmp.com 这类市场聚合站通常会提供下载包或者 git 源按页面说明操作即可。不管哪种来源最终落到磁盘上的结构都必须是skills/skill-name/SKILL.md。这是所有工具约定俗成的扫描规则层级稍微套错工具就扫不到。2.2 手动安装的每一步下面以 Claude Code 为例完整走一遍手动安装 GitHub 上某个 skills 的流程。假设你想装一个叫 demo-skill 的 skill仓库地址是https://github.com/xxx/demo-skill。第一步建目录mkdir -p ~/.claude/skills cd ~/.claude/skills第二步把仓库 clone 下来git clone https://github.com/xxx/demo-skill.git注意 clone 下来的目录名可能叫 demo-skill也可能叫别的。确保它里面有一个 SKILL.md 文件目录名尽量和 frontmatter 里的 name 对齐。不对齐也能用但之后如果想手动更新、做校验对不上会很难受。第三步检查文件结构find ~/.claude/skills/demo-skill -maxdepth 2 -type f | head -20只要看到 SKILL.md 在顶层就算是装上了。如果仓库里带了 scripts、templates、references 这些子目录不用管skill 被触发时这些资源会自动作为上下文的一部分被加载。第四步重启 Claude Code 会话让它重新扫描。这里没有“安装”动作工具启动时扫一次目录重启即生效。提示不要在 skills 根目录直接扔一堆没有 SKILL.md 的散文件。很多合集仓库根目录下并没有 SKILL.md直接整包丢进去工具扫不到还会污染目录。正确姿势是把合集仓库里需要的子目录单独拷贝进来或者用ln -s软链到技能目录下。软链的好处是以后git pull更新合集仓库你的链接自动指向新内容。2.3 装完怎么验证它生效了装完别急着干活先验证一下。最简单的验证方法是直接在当前会话里“演一个触发场景”。比如你刚装的是一个数据清洗 skill就说“我有一份销售数据CSV 格式里面有缺失值帮我看看怎么处理。”这时候模型如果开始按 skill 里的流程走比如先概览 shape、dtype再给缺失值统计说明已经触发成功。如果它完全没有反应先不急着下结论按下面几步排查输入/status或类似的会话状态命令看当前会话加载的 skills 列表里有没有目标 skill。Claude Code 的/status能列出已加载的 skills。检查 SKILL.md 的 frontmatter 是否完整name 和 description 字段缺失时工具会直接跳过这个文件。确认目录层级必须是skills/skill-name/SKILL.md多套一层目录都不行。验证这一步很关键因为很多 skill 装上之后“没反应”八成是目录层级或 frontmatter 的问题跟模型本身没关系。3. 场景化skills推荐数学建模、前端与AI漫剧怎么选3.1 数学建模华为杯等竞赛的skills组合华为杯、国赛、美赛这类数学建模比赛是热词里被提到最多的场景。原因很简单建模过程的代码量极大而且步骤高度套路化——数据读取→清洗→可视化→建模→结果分析→论文排版每一步都有固定的最佳实践。把整个流程拆成几个 skills你的 AI 助手就能在比赛里像流水线一样稳定输出。我推荐的组合大概是这个方向数据处理 skill管缺失值、异常值、分布检查、单位统一、日期格式。这步是拿奖的地基数据不对后面全白搭。可视化 skill规定中文字体、DPI、配色和图表风格避免每张图长得不像同一个人画的。评审翻论文时图的一致性特别影响观感。模型库 skill把常见算法的适用条件和调用模板固定下来。综合评价类用熵权 TOPSIS预测类用回归和时间序列优化类用遗传算法、模拟退火。论文成稿 skill负责 LaTeX 三线表、公式编号、图表引用规范让排版阶段少加班。为什么热词里专门说“好用的 codex skills”因为 Codex CLI 本身就是终端里跑代码的 agent处理 CSV、执行 Python 脚本、反复出图它都能直接干。把数据处理流程做成 skill 之后比赛期间你只需要把题目的 CSV 丢给它它自动跑清洗、出图、建模效率是传统手写代码完全没法比的。几个社区里比较知名的 skills 集合比如 codex nature skills、cola skills也基本都是朝这个方向整理的想尝鲜的直接去 GitHub 按“codex skills”搜排行榜靠前的都能用。3.2 前端开发场景的skills选品前端开发是继建模之后第二个高频场景。这里选 skill 的思路不是“一个 skill 全搞定”而是按任务边界拆组件生成 skill约束文件结构、TypeScript 类型风格、样式方案生成页面组件时直接按规范输出。代码审查 skill按性能、可访问性、语义化、依赖合理性几个维度逐项过代码把机械性检查交给 AI。重构 / 升级 skill比如帮你在跑测试后自动修复 lint 错误、处理依赖升级的破坏性变更。前端类 skills 比较值得关注的两个来源一个是 superpowers 系列作者把软件工程实践拆成了几十个相互配合的小 skills适合喜欢“组合拳”的人另一个是 awesome-claude-skills 里归类的 web 开发合集。装之前建议先看 skill 正文里的示例确认它假设的框架和你的技术栈一致否则生成的代码风格会怪怪的。比如有的 skill 默认你用 Tailwind你项目里是纯 CSS生成出来的东西就得手动改半天。前端技能的另一个用法是“约束已有的编辑工作流”。我试过把团队自己的代码规范写成 skill 放进项目级目录生成代码时自动遵守实测下来比每次粘贴规范要稳得多也省了反复提醒 AI 的沟通成本。3.3 AI漫剧相关的技能包AI 漫剧是热词里比较新的方向。它本质上是批量生产带剧情的动画短片环节包括人物设定、分镜剧本、生图提示词、配音脚本每一环都是高度模板化的工作。把一个角色设定写成 skillAI 每集都能保持人物性格一致把“分镜转生图提示词”的转换规则写成 skill输出的提示词风格基本不会跑偏画面质量也更稳定。这类 skills 的存量没有编程领域多所以更多是自己写。后面第四节我会讲怎么写你只需要记住一个判断标准凡是“每次都要重复、而且有固定规范”的流程都值得写成 skill。AI 漫剧的设定卡、脚本模板、提示词风格全部符合这个条件。比如镜头描述用什么句式、角色外貌放在哪个字段、画面风格词缀固定在哪些选项里一条条列进 skill产出的内容才会像同一个团队批量做的。4. 手把手写一个自己的Skills4.1 SKILL.md 的正确写法写一个 skill 最核心的就是写对 SKILL.md。文件结构要求很固定--- name: my-cool-skill description: 当用户需要做某件事场景写清楚时使用。如果场景不匹配不要使用。 --- # 技能说明 ## 何时使用 - 场景列表 - 适用数据特征 ## 步骤 1. 详细步骤越具体越好。 2. 每一步写明输入、输出和校验方式。 ## 示例 - 好的示例 - 坏的示例 ## 禁止事项 - 不要做的事明确写出来。frontmatter 里 name 用全小写加连字符description 要写“何时用、何时不用”而不是堆砌“强大、高效、全面”这类形容词。因为模型是根据 description 来决定调不调用的描述写得太泛模型遇到无关任务也容易误触发写得太窄该触发时又完全没反应。这是整个 skill 里最值得花时间打磨的部分。正文部分的关键是“具体到可以执行”。不要写“分析数据”要写“先读取文件输出行数和列数检查每个字段的缺失率缺失率超过 20% 的列进入候选删除列表缺失率低的列按插值/众数填充”。步骤越具体模型输出越稳定。你写得越模糊模型自由发挥的空间就越大结果就越不可控。4.2 让skill更可靠的几个小技巧写多了你会发现决定 skill 质量的高低往往不在步骤而在三个容易被忽略的细节。第一给示例。好的示例让模型照葫芦画瓢坏的示例帮模型避坑。这俩比任何描述都管用。比如你写数据报表生成的 skill给一个“合格报表”的例子再给一个“看起来像合格但实际日期格式错了”的反例模型很快就能理解你要的边界在哪里。第二写“不做什么”。模型默认会自由发挥你必须在 skill 里明确禁止一些行为。比如“不要使用 pandas 的inplaceTrue修改原始数据”“不要在最终报告里保留调试输出”“不要用中文字体缺失的默认字体出图”。这类负向约束能明显减少返工而且改起来成本极低一句话的事。第三保持单技能聚焦。一个 skill 解决一类问题别想一口气搞定所有数据工作。宁可拆成三个小 skill也别写一个又大又全的“全能”技能后者往往哪个场景都触发得不好。模型在匹配多技能描述时会有优先级问题描述之间互相打架结果就是稳定的误触发。4.3 自测与迭代的完整闭环写完先别急着“发布”。我习惯用下面的流程自测在一个干净会话里用一段故意贴近 description 的话触发它看它是否按步骤走。用一段偏离场景的话测试看它是不是乱调用。让 skill 实际跑完一个最小任务检查输出是否符合正文里的格式要求。发现问题就改正文改完重复第 1 步。这个循环跑两轮基本就能把一个 skill 磨到可以日常使用的水平。你要是把写好的 skill 放到自己的 GitHub 仓库里再写清楚 README过一段时间甚至能收到别人的 issue 和 PR这也算是写 skill 的一种正反馈。我自己最初写的几个技能现在早就不用了但被社区里的人改造过的新版本还在被 fork看着还挺有成就感的。5. 管理、清理与排查别让skills变成垃圾场5.1 装了一堆skills之后清理与规范skills 装多了以后最大的问题是互相干扰。目录里堆着二三十个合集启动扫描变慢description 太多模型还容易误判。GitHub 上一位叫 tibo 的开发者分享的清理方法我试验过后一直沿用核心就三条定期列出现有 skills 清单记录每一个的触发次数长期不用的直接标灰。功能重叠的合并比如三个数据清洗类 skill合并成一个保留你最顺手的那份步骤。不要在工具里“卸载”直接删目录。一个 skill 就是普通文件删掉也不会丢什么反正 clone 一条命令能装回来。清理之后还有一个习惯值得养成把用户级目录里常用的几个 skill 用 git 管起来定期 commit。这等于给自己的技能库做版本管理回滚、同步都方便。你也可以通过软链把 dotfiles 仓库和 skills 目录连起来换新机器一条命令就能恢复整套配置。维护这块的个人建议不要追求数量。我现在用户级目录常驻的就五六个通用 skill剩下的全部放项目级目录按需加载。任何“我要不要装它”的犹豫一律先装到项目级试试稳定好用再提升为用户级。这个策略帮我避开了大量目录污染问题也不容易把自己辛辛苦苦调好的配置搞乱。5.2 常见问题与排查速查表最后把这段时间踩过的坑整理成一张排查表。遇到问题先对着表查能省下大半时间。现象可能原因排查/修复skill 完全没反应目录层级不对SKILL.md 不在顶层调整为skills/skill/SKILL.md总是误触发description 写得太泛重写 description加上“什么时候不要用”触发但步骤执行得乱正文步骤不够具体细化步骤写代码示例和反例新装的 skill 不知道装没装没重启会话重启后用/status查看加载列表多个 skill 互相抢任务frontmatter name 冲突改名或合并确保 name 唯一装完无法更新git 仓库没有 remoteclone 时保留.git之后用git pull更新还有一个容易被忽略的坑不同工具对 description 的解析优先级不一样。同一个 skills 目录拿给 Codex 和 Claude Code 用表现会有差异跨工具使用前最好先在目标工具上做一趟前面 2.3 节里的触发验证。不要图省事让所有工具共用同一个目录各开各的目录、用脚本同步能少踩很多莫名其妙的兼容问题。写到最后再分享一个小经验。很多人觉得 skills 玄乎其实它的演进逻辑和插件系统、和“工具集”没有区别先解决自己的一个具体痛点写一个 skill用熟了再扩展。我最早写第一个 skill 就是嫌每周处理报表太重复后来才慢慢把数据清洗、可视化、论文排版这些流程都成了固定配置。你现在从 GitHub 上装别人 skills 没什么门槛但真正让你工作效率拉开差距的一定是从自己流程里长出来的那部分。装完之后第一件事也别忘了用一个小任务让它实际跑一遍而不是看完 README 就当装完了——这一步几乎能帮你避开 80% 的问题。
