最近上手了一轮 Claude Code 的 skills也翻了不少 GitHub 上的开源技能库。很多人把它叫作 AI 编程的 superpower第一次用确实有被震到原来一套准备好的 skills能让 AI 从“懂点工具”变成“按你的工作流干活”。但我也发现一个普遍问题——GitHub 上 skills 项目一大堆安装方式五花八门有的是复制文件夹有的是跑脚本有的只写了半句话让你自己琢磨。这篇整理一下我自己的折腾记录skills 到底是个什么机制怎么手动装到 Claude Code、Codex 这类工具里怎么自己写一个能用的 skill以及在华为杯数学建模这种实战场景里怎么组合使用。适合刚接触 skills、想把 AI 编程助手调教成“老兵”的开发者看。1. 先搞清楚 Skills 到底是什么1.1 从“聪明但没经验”到“带流程干活”的关键一步先说个很直观的比喻。一个刚毕业的高材生脑子很好使但第一天到公司如果你只丢给他一句话“把这份数据报告做了”他大概率会用自己的方式一顿操作产出和你预期差很远。如果你甩给他一本老员工沉淀下来的《数据处理标准流程》他照着走结果就稳多了。skills 在这套体系里就是那本岗位 SOP。在 Claude Code、Codex 这类工具里AI 每次对话其实都像一个“聪明但没经验的新人”。模型本身知识广、推理强但它不知道你这个项目里数据文件放在哪里、报告必须用哪个模板、代码风格有什么禁忌。你可以每次对话都把这些规则重新说一遍但这样既累又容易漏。skills 的做法是把一整套任务流程、判断标准、产出格式、甚至配套脚本预先打包成一个目录让 AI 在遇到匹配任务时自动读取并执行。我发现很多人把 skills 理解成“给 AI 加技能点”这其实不太准确。它更像“给 AI 发了一本工作手册”不是让模型变聪明而是让模型在你定义的场景里不跑偏。这就是为什么都说好的 skills 是 AI 时代的 superpower——它不是放大模型的智力而是放大你对模型的“调教能力”。1.2 一个标准 skill 包里装了什么从 GitHub 上随便拉一个成熟的 skills 项目下来看目录结构通常是这样的my-skill/ SKILL.md scripts/ preprocess.py visualize.py templates/ report.md latex_template.tex assets/ example_input.csv核心文件就一个SKILL.md。其它所有东西都是它的“弹药”。SKILL.md 通常分两部分开头是一段 YAML frontmatter用来登记这个 skill 的元信息比如名字、描述、适用场景后面是正文用自然语言写清楚任务目标、执行步骤、输入输出约定、注意事项。举个简化版的 SKILL.md 例子--- name:>~/.claude/skills/把下载的 skill 文件夹整个放进去重启会话即可。Codex 对应的是~/.codex/skills/放进去之后Codex 每次启动会扫描这个目录把 skill 注册进可用列表。项目级安装当前仓库生效只想让某个项目的 AI 助手拥有这套 skill就把文件夹放到项目的.claude/skills/或.codex/skills/下。这样做的好处是随仓库走团队成员 clone 下来就有特别适合比赛项目或者多人协作项目。会话内临时加载部分工具支持直接把某个 skill 文件夹的路径告诉当前会话让 AI 现场读取。这个方式适合测试一个还没写好的 skill不用重启改动即时生效。通过脚本自动安装一些热门仓库会提供一个install.sh或一键安装命令本质就是把仓库里的 skills 目录复制到对应配置目录。我不太建议无脑跑脚本最好先看一眼脚本内容确认它复制到哪里、会不会覆盖已有文件。2.3 装完怎么确认生效装好后的验证方式和工具本身强相关。Claude Code 里最直接的办法在对话里输入/skills或直接问“你现在有哪些可用的 skills”它会列出已加载的列表。Codex 那边类似启动时能看到加载日志或者直接问它。还有一个更实用的验证方法按 SKILL.md 的 description 设计一个测试请求。比如一个“代码审查”skill给它一段小代码说“帮我 review 一下这段”如果它输出的格式、步骤明显符合 SKILL.md 里写的内容说明已生效。如果回答泛泛而谈八成是没加载成功或者 description 和你的请求对不上。3. 自己写一个 Skills从零到可用3.1 先设计后编码SKILL.md 的结构自己写 skill最大的误区是上来就写代码脚本。我踩过这个坑——先花了半天写了个很复杂的 Python 处理脚本结果 SKILL.md 写得稀烂AI 根本不知道什么时候该用这个脚本。后来才明白SKILL.md 的优先级远高于脚本脚本只是工具SKILL.md 才是灵魂。一份合格的 SKILL.md我建议至少包含五块内容name简短唯一最好用连字符命名比如>--- name: model-data-preflight description: 数学建模前对表格数据进行快速预检。当用户提供 CSV、Excel 文件并要求做数据清洗、缺失值统计、字段分布分析或建模前准备时使用。 version: 1.2.0 --- # 数据预检流程 ## 目标 在建模开始前用最少的时间掌握数据全貌定位明显质量问题。 ## 执行步骤 1. 列出文件字段清单字段名、类型、每列非空数量。 2. 缺失值分析按列统计缺失比例标注超过 15% 的列和超过 5% 的行。 3. 异常值扫描对数值型字段用四分位距法标记离群点不直接删除只在报告中提示。 4. 分布快照输出每列直方图描述、数值列的均值/中位数/极差、类别列的频数 Top10。 5. 输出统一报告格式 - 数据概览表格 - 缺失值风险表 - 异常值清单 - 建议的清洗方案包括删除、填补、重编码等 ## 注意 - 不产出最终清洗后的文件除非用户明确要求。 - 所有结论必须基于实际统计禁止猜测。配合一个简单的preflight.py脚本用 pandas 直接读入数据生成统计结果AI 可以运行脚本后把输出整理成报告。这一步的收益非常大人只需要看结论不用一遍遍让 AI 自己读表格。3.3 写 skills 的易错点自己写了十几个 skill踩出来的坑可以列一串坑一正文步骤写太满变成“小作文”。AI 的上下文窗口有限SKILL.md 写太长真正重要的步骤反而被稀释。我后来给自己定了个规矩SKILL.md 不超过 150 行步骤尽量压缩到 8 步以内能用列表不用段落。坑二把变化的东西写死。比如在 SKILL.md 里写死“数据文件名是train.csv”换一个场景就废了。正确做法是用变量占位比如{{input_file}}或者让 AI 先从用户对话里推断文件名。坑三脚本和文分离。有些 skill 里脚本写得很好但 SKILL.md 没说明怎么调用。AI 不知道脚本参数是什么、输出什么。我一般会在 SKILL.md 里加“脚本用法”小节写清楚python scripts/xxx.py --help这类信息。坑四期望一次成型。skill 是一门手艺没有谁能一遍写完美。我现在的习惯是写好一个 skill先拿 3 个不同场景的请求去测看哪些句子触发了、哪些没触发、步骤能不能走通然后反复改 description 和步骤顺序。实际测试下来大部分 skill 都要改上三四轮才稳定。4. 我实测过好用的 Skills 推荐4.1 通用型代码审查、重构、写测试GitHub 上现在最热的一批 skills通用型占大头。我自己长期在用的有三个方向代码审查 skill。这类 skill 会定义审查维度正确性、性能、可读性、安全性、边界条件。装完之后我只要把一段代码丢给它说“按你的 review 规范检查”它输出的意见比默认回答结构清晰得多分类明确每条意见还带上严重级别和建议修法。测试生成 skill。它定义了一套分析逻辑先理解被测函数的输入输出、列出普通/边界/异常三类用例、把用例映射成pytest代码最后再自查一遍。默认写测试时 AI 容易顺着一个方向写一堆同质化用例有了这套 skill 后覆盖明显均匀。重构 skill。特点是不会直接改代码而是先输出一个“重构计划”目标结构、风险点、迁移步骤、验证方案。确认后才动手改非常适合给老项目做渐进式优化避免 AI 一把梭改得面目全非。4.2 场景型前端开发、AI漫剧、数学建模顺着搜索热词走一遍你会发现 skills 早就从纯代码场景扩散开了。前端开发 skills 是最成熟的一类。比如“组件生成”skill定义组件 API 风格、样式方案、状态管理约定前端项目装上它之后AI 写出的组件能和你手写代码保持同一套风格不再“一人一个审美”。还有“设计转代码”skill规定从 Figma 设计稿提取颜色、间距、层级的方式避免 AI 随机发挥。AI 漫剧类的 skills 我见过不少人在社区分享思路很一致把分镜、角色描述、台词风格、画面风格统一封装到 skill 里生成剧本文本时自动按固定模板输出。类似“角色一致性”skill会要求 AI 在描述人物时反复引用统一设定词条避免前后形象漂移。数学建模 skills 是竞赛圈最活跃的方向之一。GitHub 上搜“math modeling skills”能翻到不少仓库里面打包了数据预检、模型选型、敏感性分析、LaTeX 排版等一套流程。我自己对这类 skill 的评价是能省大量重复沟通成本但别指望它帮你拿奖奖还是靠自己建模思路skills 只是把杂活变快。4.3 去哪里找技能库找 skills 的渠道目前最稳定的是 GitHub。几个常用的搜索思路搜awesome-claude-skills、awesome-codex-skills会有整理好的列表按分类跳转。搜skills 你的场景关键词比如skills 数学建模、skill frontend。关注几个知名仓库superpower-skills、typesafe ai skills这些有段时间社区热度很高里面沉淀了不少高质量 skill。挑选时我一般看三点第一最近是否还在更新超过半年没动的仓库大概率不兼容新版本工具第二SKILL.md 写得到不到位看一个文件就知道作者有没有用心第三有没有示例测试有示例的仓库出问题概率低很多。还有一个思路直接看别人分享的“技能库网址”清单。有些开发者会把一堆 skill 仓库通过订阅源、书签页的方式收集起来这种导航站比你自己一个个翻 GitHub 高效得多。不过看导航站要注意时效性链接失效很常见建议以 GitHub 搜索为主导航站只作为补充线索。5. 华为杯数学建模竞赛里的 Skills 实战5.1 比赛场景下 skills 装什么选型逻辑华为杯这类数学建模赛事特点很鲜明时间紧、任务链固定、输出格式有硬要求。从拿到题目到交论文通常就是一条流水线选题分析、数据清洗、模型选择、求解与验证、论文撰写、排版检查。任何一环卡住后面全崩。这种情况下skills 的选型逻辑就很清晰优先选“能把固定流程固化成模板”的 skill而不是“能帮你思考”的 skill。比如数据预检、论文排版、结果表格生成这些都是重复劳动适合交给 skill。真正需要建模思路的部分反而不要用 skill 去框死否则 AI 容易陷入固定套路。我当时装的是这样几个数据预检 skill定位脏数据、缺失值、异常值统一输出预检报告。模型基线 skill给定特征和目标列后自动跑几种 baseline 模型并输出对比表。论文段落 skill按数学建模论文惯用结构生成方法论、结果分析等章节保证逻辑线索清晰。LaTeX 排版 skill把公式、三线表、图片编号按模板自动整理。5.2 比赛工作流的落地说一下实际落地时的做法。比赛第一天拿到数据我不会急着建模而是先触发数据预检 skill让它跑一遍全套预检流程。这里有个关键点在 skill 的 SKILL.md 里最好写好“统计结果必须以 Markdown 表格呈现并给出清洗建议”。这样一来同一份数据不管换谁执行出来的报告结构都是一样的这对后面算法模型的接入帮助很大。模型基线 skill 也一样。我会把常见任务类型写进 description 里比如“二分类问题”“回归问题”“时序预测”这样 AI 能在比赛第一天快速跑完几个 baseline给后面深入建模提供参照。跑出来之后输出统一格式的表格模型名、参数、指标、耗时方便对比。论文写作阶段我会用论文段落 skill 做“初稿生成器”先把骨架搭好再手动调整。数学建模论文的规范性很重格式错了要扣分LaTeX 排版 skill 就是一道保险。5.3 复盘一次比赛里我怎么用 skills按这套流程走下来最直观的变化是省时间。以前我们队三个人围着一份 CSV无数次来回询问、确认光数据清洗就能耗掉三四个小时。那次用 skill 之后数据预检加初步清洗建议大概四十分钟就出全貌了。这不是说 skill 有多神而是它把“反复解释需求”的时间压缩掉了——AI 第一步就知道你要什么格式、什么颗粒度、什么注意事项。但我也要提醒比赛场景里千万别贪多。skill 数量一旦上来了AI 在多个 skill 之间做选择就可能犹豫甚至误触发。我后来刻意只让 4 个核心 skill 常驻其余全部关闭。比赛是一个需要高度行动的场合宁可让 AI “普通但听话”也不要让它“聪明但犹豫”。6. 常见问题与排查技巧6.1 装了不生效怎么办最典型的问题就是“我明明装好了AI 就是不按 skill 走”。按照出现频次我整理过一个排查顺序现象可能原因排查方法对话里看不到 skill 列表目录放错检查路径是否在~/.claude/skills或项目.claude/skills下列表里有但请求不触发description 不匹配检查你的请求关键词是否在 description 覆盖范围内触发了但步骤执行不全SKILL.md 步骤太长缩短步骤或把冗长细节移到附件脚本同一个请求多个 skill 都想触发description 写太宽给 skill 增加“不适用”说明缩小触发域改完不生效缓存或未重启会话重启会话再试部分工具需要重新加载配置有一个我自己常用的方法直接问 AI“基于你现在加载的 skills我这条消息应该用哪个 skill为什么”它会把判断逻辑说出来问题到底出在描述、路径还是步骤一下就定位了。6.2 多个 skills 之间的“打架”装了十几个 skill 之后会出现一个新问题某个用户请求命中了两个甚至三个 skillAI 可能取了一个不相干的或者把几个 skill 的流程混在一起。这种情况在社区里有个很形象的词叫“污染”。我后来采用的规避手段主要是收敛触发条件。每个 skill 的 description 里我会加一行“不适用”说明比如“若用户是进行实时数据流分析不应使用本 skill应使用 streaming-analysis skill”。这相当于给 AI 一张冲突仲裁表。另外当多个 skills 同时匹配时AI 通常会根据任务相关性选择所以 description 里“何时使用”的权重比“做什么”更重要。6.3 清理 skills 也是必修课网上关于“清理 skills 的方法推荐”经常见有人提但大多是零散经验。我自己实践下来的标准做法是这样的每两周过一次列表超过 30 天没用过的 skill 移到~/.skills-backup/。保留的 skill 必须满足最近实际触发过、产出质量稳定、SKILL.md 无过时内容。同类场景只保留一个最佳 skill其余全部移除。用版本号管理 SKILL.md改动后自动 0.1避免“改来改去不知道哪个生效”。清理的核心逻辑不是“省空间”而是“减少决策噪声”。AI 在匹配 skill 时候选越多选错的概率越大。你留下的都是经过验证的精英整套体系才能保持稳定。最后再分享一个我的小习惯每个 skill 写好之后我会在 SKILL.md 末尾加一小段“变更记录”写下“哪天、因为什么、改了哪里”。这样三个月后再回来看还能知道当初为什么把某个步骤调整成现在的样子。skills 这个东西维护比创建更重要一套能长期不出乱子的技能库才是真正能跟着你越走越顺的超级能力。 Claude Code Skills 实战指南：从机制到数学建模工作流落地
最近上手了一轮 Claude Code 的 skills也翻了不少 GitHub 上的开源技能库。很多人把它叫作 AI 编程的 superpower第一次用确实有被震到原来一套准备好的 skills能让 AI 从“懂点工具”变成“按你的工作流干活”。但我也发现一个普遍问题——GitHub 上 skills 项目一大堆安装方式五花八门有的是复制文件夹有的是跑脚本有的只写了半句话让你自己琢磨。这篇整理一下我自己的折腾记录skills 到底是个什么机制怎么手动装到 Claude Code、Codex 这类工具里怎么自己写一个能用的 skill以及在华为杯数学建模这种实战场景里怎么组合使用。适合刚接触 skills、想把 AI 编程助手调教成“老兵”的开发者看。1. 先搞清楚 Skills 到底是什么1.1 从“聪明但没经验”到“带流程干活”的关键一步先说个很直观的比喻。一个刚毕业的高材生脑子很好使但第一天到公司如果你只丢给他一句话“把这份数据报告做了”他大概率会用自己的方式一顿操作产出和你预期差很远。如果你甩给他一本老员工沉淀下来的《数据处理标准流程》他照着走结果就稳多了。skills 在这套体系里就是那本岗位 SOP。在 Claude Code、Codex 这类工具里AI 每次对话其实都像一个“聪明但没经验的新人”。模型本身知识广、推理强但它不知道你这个项目里数据文件放在哪里、报告必须用哪个模板、代码风格有什么禁忌。你可以每次对话都把这些规则重新说一遍但这样既累又容易漏。skills 的做法是把一整套任务流程、判断标准、产出格式、甚至配套脚本预先打包成一个目录让 AI 在遇到匹配任务时自动读取并执行。我发现很多人把 skills 理解成“给 AI 加技能点”这其实不太准确。它更像“给 AI 发了一本工作手册”不是让模型变聪明而是让模型在你定义的场景里不跑偏。这就是为什么都说好的 skills 是 AI 时代的 superpower——它不是放大模型的智力而是放大你对模型的“调教能力”。1.2 一个标准 skill 包里装了什么从 GitHub 上随便拉一个成熟的 skills 项目下来看目录结构通常是这样的my-skill/ SKILL.md scripts/ preprocess.py visualize.py templates/ report.md latex_template.tex assets/ example_input.csv核心文件就一个SKILL.md。其它所有东西都是它的“弹药”。SKILL.md 通常分两部分开头是一段 YAML frontmatter用来登记这个 skill 的元信息比如名字、描述、适用场景后面是正文用自然语言写清楚任务目标、执行步骤、输入输出约定、注意事项。举个简化版的 SKILL.md 例子--- name:>~/.claude/skills/把下载的 skill 文件夹整个放进去重启会话即可。Codex 对应的是~/.codex/skills/放进去之后Codex 每次启动会扫描这个目录把 skill 注册进可用列表。项目级安装当前仓库生效只想让某个项目的 AI 助手拥有这套 skill就把文件夹放到项目的.claude/skills/或.codex/skills/下。这样做的好处是随仓库走团队成员 clone 下来就有特别适合比赛项目或者多人协作项目。会话内临时加载部分工具支持直接把某个 skill 文件夹的路径告诉当前会话让 AI 现场读取。这个方式适合测试一个还没写好的 skill不用重启改动即时生效。通过脚本自动安装一些热门仓库会提供一个install.sh或一键安装命令本质就是把仓库里的 skills 目录复制到对应配置目录。我不太建议无脑跑脚本最好先看一眼脚本内容确认它复制到哪里、会不会覆盖已有文件。2.3 装完怎么确认生效装好后的验证方式和工具本身强相关。Claude Code 里最直接的办法在对话里输入/skills或直接问“你现在有哪些可用的 skills”它会列出已加载的列表。Codex 那边类似启动时能看到加载日志或者直接问它。还有一个更实用的验证方法按 SKILL.md 的 description 设计一个测试请求。比如一个“代码审查”skill给它一段小代码说“帮我 review 一下这段”如果它输出的格式、步骤明显符合 SKILL.md 里写的内容说明已生效。如果回答泛泛而谈八成是没加载成功或者 description 和你的请求对不上。3. 自己写一个 Skills从零到可用3.1 先设计后编码SKILL.md 的结构自己写 skill最大的误区是上来就写代码脚本。我踩过这个坑——先花了半天写了个很复杂的 Python 处理脚本结果 SKILL.md 写得稀烂AI 根本不知道什么时候该用这个脚本。后来才明白SKILL.md 的优先级远高于脚本脚本只是工具SKILL.md 才是灵魂。一份合格的 SKILL.md我建议至少包含五块内容name简短唯一最好用连字符命名比如>--- name: model-data-preflight description: 数学建模前对表格数据进行快速预检。当用户提供 CSV、Excel 文件并要求做数据清洗、缺失值统计、字段分布分析或建模前准备时使用。 version: 1.2.0 --- # 数据预检流程 ## 目标 在建模开始前用最少的时间掌握数据全貌定位明显质量问题。 ## 执行步骤 1. 列出文件字段清单字段名、类型、每列非空数量。 2. 缺失值分析按列统计缺失比例标注超过 15% 的列和超过 5% 的行。 3. 异常值扫描对数值型字段用四分位距法标记离群点不直接删除只在报告中提示。 4. 分布快照输出每列直方图描述、数值列的均值/中位数/极差、类别列的频数 Top10。 5. 输出统一报告格式 - 数据概览表格 - 缺失值风险表 - 异常值清单 - 建议的清洗方案包括删除、填补、重编码等 ## 注意 - 不产出最终清洗后的文件除非用户明确要求。 - 所有结论必须基于实际统计禁止猜测。配合一个简单的preflight.py脚本用 pandas 直接读入数据生成统计结果AI 可以运行脚本后把输出整理成报告。这一步的收益非常大人只需要看结论不用一遍遍让 AI 自己读表格。3.3 写 skills 的易错点自己写了十几个 skill踩出来的坑可以列一串坑一正文步骤写太满变成“小作文”。AI 的上下文窗口有限SKILL.md 写太长真正重要的步骤反而被稀释。我后来给自己定了个规矩SKILL.md 不超过 150 行步骤尽量压缩到 8 步以内能用列表不用段落。坑二把变化的东西写死。比如在 SKILL.md 里写死“数据文件名是train.csv”换一个场景就废了。正确做法是用变量占位比如{{input_file}}或者让 AI 先从用户对话里推断文件名。坑三脚本和文分离。有些 skill 里脚本写得很好但 SKILL.md 没说明怎么调用。AI 不知道脚本参数是什么、输出什么。我一般会在 SKILL.md 里加“脚本用法”小节写清楚python scripts/xxx.py --help这类信息。坑四期望一次成型。skill 是一门手艺没有谁能一遍写完美。我现在的习惯是写好一个 skill先拿 3 个不同场景的请求去测看哪些句子触发了、哪些没触发、步骤能不能走通然后反复改 description 和步骤顺序。实际测试下来大部分 skill 都要改上三四轮才稳定。4. 我实测过好用的 Skills 推荐4.1 通用型代码审查、重构、写测试GitHub 上现在最热的一批 skills通用型占大头。我自己长期在用的有三个方向代码审查 skill。这类 skill 会定义审查维度正确性、性能、可读性、安全性、边界条件。装完之后我只要把一段代码丢给它说“按你的 review 规范检查”它输出的意见比默认回答结构清晰得多分类明确每条意见还带上严重级别和建议修法。测试生成 skill。它定义了一套分析逻辑先理解被测函数的输入输出、列出普通/边界/异常三类用例、把用例映射成pytest代码最后再自查一遍。默认写测试时 AI 容易顺着一个方向写一堆同质化用例有了这套 skill 后覆盖明显均匀。重构 skill。特点是不会直接改代码而是先输出一个“重构计划”目标结构、风险点、迁移步骤、验证方案。确认后才动手改非常适合给老项目做渐进式优化避免 AI 一把梭改得面目全非。4.2 场景型前端开发、AI漫剧、数学建模顺着搜索热词走一遍你会发现 skills 早就从纯代码场景扩散开了。前端开发 skills 是最成熟的一类。比如“组件生成”skill定义组件 API 风格、样式方案、状态管理约定前端项目装上它之后AI 写出的组件能和你手写代码保持同一套风格不再“一人一个审美”。还有“设计转代码”skill规定从 Figma 设计稿提取颜色、间距、层级的方式避免 AI 随机发挥。AI 漫剧类的 skills 我见过不少人在社区分享思路很一致把分镜、角色描述、台词风格、画面风格统一封装到 skill 里生成剧本文本时自动按固定模板输出。类似“角色一致性”skill会要求 AI 在描述人物时反复引用统一设定词条避免前后形象漂移。数学建模 skills 是竞赛圈最活跃的方向之一。GitHub 上搜“math modeling skills”能翻到不少仓库里面打包了数据预检、模型选型、敏感性分析、LaTeX 排版等一套流程。我自己对这类 skill 的评价是能省大量重复沟通成本但别指望它帮你拿奖奖还是靠自己建模思路skills 只是把杂活变快。4.3 去哪里找技能库找 skills 的渠道目前最稳定的是 GitHub。几个常用的搜索思路搜awesome-claude-skills、awesome-codex-skills会有整理好的列表按分类跳转。搜skills 你的场景关键词比如skills 数学建模、skill frontend。关注几个知名仓库superpower-skills、typesafe ai skills这些有段时间社区热度很高里面沉淀了不少高质量 skill。挑选时我一般看三点第一最近是否还在更新超过半年没动的仓库大概率不兼容新版本工具第二SKILL.md 写得到不到位看一个文件就知道作者有没有用心第三有没有示例测试有示例的仓库出问题概率低很多。还有一个思路直接看别人分享的“技能库网址”清单。有些开发者会把一堆 skill 仓库通过订阅源、书签页的方式收集起来这种导航站比你自己一个个翻 GitHub 高效得多。不过看导航站要注意时效性链接失效很常见建议以 GitHub 搜索为主导航站只作为补充线索。5. 华为杯数学建模竞赛里的 Skills 实战5.1 比赛场景下 skills 装什么选型逻辑华为杯这类数学建模赛事特点很鲜明时间紧、任务链固定、输出格式有硬要求。从拿到题目到交论文通常就是一条流水线选题分析、数据清洗、模型选择、求解与验证、论文撰写、排版检查。任何一环卡住后面全崩。这种情况下skills 的选型逻辑就很清晰优先选“能把固定流程固化成模板”的 skill而不是“能帮你思考”的 skill。比如数据预检、论文排版、结果表格生成这些都是重复劳动适合交给 skill。真正需要建模思路的部分反而不要用 skill 去框死否则 AI 容易陷入固定套路。我当时装的是这样几个数据预检 skill定位脏数据、缺失值、异常值统一输出预检报告。模型基线 skill给定特征和目标列后自动跑几种 baseline 模型并输出对比表。论文段落 skill按数学建模论文惯用结构生成方法论、结果分析等章节保证逻辑线索清晰。LaTeX 排版 skill把公式、三线表、图片编号按模板自动整理。5.2 比赛工作流的落地说一下实际落地时的做法。比赛第一天拿到数据我不会急着建模而是先触发数据预检 skill让它跑一遍全套预检流程。这里有个关键点在 skill 的 SKILL.md 里最好写好“统计结果必须以 Markdown 表格呈现并给出清洗建议”。这样一来同一份数据不管换谁执行出来的报告结构都是一样的这对后面算法模型的接入帮助很大。模型基线 skill 也一样。我会把常见任务类型写进 description 里比如“二分类问题”“回归问题”“时序预测”这样 AI 能在比赛第一天快速跑完几个 baseline给后面深入建模提供参照。跑出来之后输出统一格式的表格模型名、参数、指标、耗时方便对比。论文写作阶段我会用论文段落 skill 做“初稿生成器”先把骨架搭好再手动调整。数学建模论文的规范性很重格式错了要扣分LaTeX 排版 skill 就是一道保险。5.3 复盘一次比赛里我怎么用 skills按这套流程走下来最直观的变化是省时间。以前我们队三个人围着一份 CSV无数次来回询问、确认光数据清洗就能耗掉三四个小时。那次用 skill 之后数据预检加初步清洗建议大概四十分钟就出全貌了。这不是说 skill 有多神而是它把“反复解释需求”的时间压缩掉了——AI 第一步就知道你要什么格式、什么颗粒度、什么注意事项。但我也要提醒比赛场景里千万别贪多。skill 数量一旦上来了AI 在多个 skill 之间做选择就可能犹豫甚至误触发。我后来刻意只让 4 个核心 skill 常驻其余全部关闭。比赛是一个需要高度行动的场合宁可让 AI “普通但听话”也不要让它“聪明但犹豫”。6. 常见问题与排查技巧6.1 装了不生效怎么办最典型的问题就是“我明明装好了AI 就是不按 skill 走”。按照出现频次我整理过一个排查顺序现象可能原因排查方法对话里看不到 skill 列表目录放错检查路径是否在~/.claude/skills或项目.claude/skills下列表里有但请求不触发description 不匹配检查你的请求关键词是否在 description 覆盖范围内触发了但步骤执行不全SKILL.md 步骤太长缩短步骤或把冗长细节移到附件脚本同一个请求多个 skill 都想触发description 写太宽给 skill 增加“不适用”说明缩小触发域改完不生效缓存或未重启会话重启会话再试部分工具需要重新加载配置有一个我自己常用的方法直接问 AI“基于你现在加载的 skills我这条消息应该用哪个 skill为什么”它会把判断逻辑说出来问题到底出在描述、路径还是步骤一下就定位了。6.2 多个 skills 之间的“打架”装了十几个 skill 之后会出现一个新问题某个用户请求命中了两个甚至三个 skillAI 可能取了一个不相干的或者把几个 skill 的流程混在一起。这种情况在社区里有个很形象的词叫“污染”。我后来采用的规避手段主要是收敛触发条件。每个 skill 的 description 里我会加一行“不适用”说明比如“若用户是进行实时数据流分析不应使用本 skill应使用 streaming-analysis skill”。这相当于给 AI 一张冲突仲裁表。另外当多个 skills 同时匹配时AI 通常会根据任务相关性选择所以 description 里“何时使用”的权重比“做什么”更重要。6.3 清理 skills 也是必修课网上关于“清理 skills 的方法推荐”经常见有人提但大多是零散经验。我自己实践下来的标准做法是这样的每两周过一次列表超过 30 天没用过的 skill 移到~/.skills-backup/。保留的 skill 必须满足最近实际触发过、产出质量稳定、SKILL.md 无过时内容。同类场景只保留一个最佳 skill其余全部移除。用版本号管理 SKILL.md改动后自动 0.1避免“改来改去不知道哪个生效”。清理的核心逻辑不是“省空间”而是“减少决策噪声”。AI 在匹配 skill 时候选越多选错的概率越大。你留下的都是经过验证的精英整套体系才能保持稳定。最后再分享一个我的小习惯每个 skill 写好之后我会在 SKILL.md 末尾加一小段“变更记录”写下“哪天、因为什么、改了哪里”。这样三个月后再回来看还能知道当初为什么把某个步骤调整成现在的样子。skills 这个东西维护比创建更重要一套能长期不出乱子的技能库才是真正能跟着你越走越顺的超级能力。