聊到“skills”如果是半年前我会以为是简历上那行“精通XXX”现在再聊“skills”圈子里默认说的是AI编程工具里的技能包是Claude Code、Codex这类Agent工具的灵魂。你可能也有这种感觉同样是Claude Code别人跑一个前端项目像开了挂代码风格统一、架构分层清晰、连提交信息都写得漂漂亮亮轮到自己用它就像个记忆力只有30秒的实习生答一句忘一句改一版崩一版。差别在哪大概率就是别人装了skills你没有。这玩意儿说白了就是给AI提前塞好的一套“工作手册”——你把它要遵守的规范、要走的流程、要调用的命令写成Markdown文件放进指定目录它每次干活就先翻手册再动手。我今天把这些东西从头到尾捋一遍包括它为什么灵、怎么装GitHub上的现成包、怎么自己手写一个、装坏了怎么清再附一份按场景做的推荐清单。看完你大概率能把自己的AI工具从“聊天机器人”调教成“半个资深工程师”。初阶玩家可以直接跳到第2章学安装中阶玩家重点看第3章手写Skill的逻辑已经在用但被搞到烦躁的建议直接看第4章的排查和清理。我尽量用干活的时候踩过的坑来说话不是给你念官方文档。1. 先搞明白skills到底在解决什么1.1 为什么AI有时候很强有时候像个傻子很多人的直觉是AI越懂越多给个大模型啥都能干。这个直觉在“聊天”维度成立在“干活”维度完全失效。聊天是单轮交互你问一句它答一句上下文短信息量小干活是多步流程要拆解任务、选型、写文件、跑测试、看报错、再改上下文越长模型越容易丢失细节尤其是那些“没有写进提示词、但老手默认该知道”的工程习惯。举个具体例子。我早期用Claude Code写一个REST API它能写但写出来的东西是典型的“大锅烩”所有路由堆在一个文件错误处理只有try/catch没有全局拦截数据库连接每次请求都重新建。你说它错了吗没完全错但项目稍大一点就能把你的维护成本拉爆。这时候如果我给它预先加载一个“后端开发skill”它就会按这个skill里定义好的分层架构、目录规则、错误码规范一步步来controller/service/repository拆开连接池统一管理连日志格式都跟我团队里其他项目保持一致。这就是skills的杀伤力——它把“老手脑子里的隐性流程”变成了“AI能读的显性文件”。1.2 Skills到底是个什么文件先打破神秘感skills不是一个插件、不是一个程序也不是什么API密钥。它本质上就是一组结构化的Markdown文档放在约定好的目录里AI在干活前会主动检索并阅读这些文档然后按照文档里的指示行动。不同工具对技能的称呼略有区别Claude Code里叫Agent Skills目录一般是.claude/skills/或者~/.claude/skills/Codex里叫custom prompts或者skills常见路径是.codex/skills/OpenCode这类开源工具也有类似的.opencode/skills/目录。文件格式通常是SKILL.md里面用固定的字段描述这个技能的名字、用途、适用场景、操作步骤。我见过最精简的SKILL.md长这样--- name: frontend-refactor description: 用于前端项目的代码重构自动识别重复代码并抽取组件。 --- ## 使用范围 - 适用于React / Vue项目 - 不适用于Node后端 ## 执行步骤 1. 扫描当前文件的组件层级 2. 识别重复渲染逻辑 3. 将重复部分抽取为独立组件 4. 更新引用 ## 验收标准 - 业务逻辑不变 - 组件命名符合项目规范所以你别把“安装一个skill”想得太复杂本质上就是下载一个这样的文件或文件夹放到约定路径让AI能读得到。1.3 为什么superpower skills在社区突然火了去年到今年社区里冒出一批热门的skills集合“superpower skills”就是其中之一。它的核心思路并不是给你几百个孤立的技能碎片而是给Claude Code提供了一套“元技能”比如教它怎么做计划、怎么写代码、怎么自我反思、怎么在项目之间转移知识。我自己的体会是单独装某个skill解决的是“某一件具体事后不AI能不能做得好”而superpower这类集合解决的是“AI作为一个整体协作对象的思考质量”。后者给人带来的体感提升更大因为它让AI的编码风格更像一个有经验的工程师而不是每次都是机械式复读。超级技能包之所以火还有一个很现实的原因很多人的提示词写得实在太差。与其让用户费劲研究提词工程不如社区里的高手把“正确的工作流”直接封装成文件你只要复制粘贴AI立刻就上了一个档次。这个思路跟当年“UI组件库”有点类似——你要的不是从零造轮子而是开箱即用的生产力。2. 从GitHub装一个现成skills的完整过程2.1 先准备好你的项目目录如果你用的是Claude Code最推荐的安装位置是项目内部的.claude/skills/。这样这个技能只对当前项目生效适合公司里某个特定技术栈的规范。如果你希望所有项目都能用就装到用户目录下的~/.claude/skills/全局生效。我第一次装的时候犯了个低级错误把skill文件丢到了项目根目录结果Claude Code完全没识别到。后来才知道它只扫描特定目录不是所有Markdown都会被当成技能。装之前一定先确认好路径宁可先建一个空目录试一次也别一下丢一堆进去然后全不生效。2.2 手动装一个GitHub上的skills的操作步骤这里以“拉一个GitHub仓库里的skills集合”为例。很多技能包在GitHub上是整个仓库发布的你需要进仓库看一下目录结构决定是整体clone还是只下载某个子文件夹。在项目根目录执行# 1. 如果只要某个skill文件夹先clone整个仓库到临时目录 git clone https://github.com/your-name/awesome-skills.git temp-skills # 2. 把技能目录复制到项目内 cp -r temp-skills/your-skill .claude/skills/ # 3. 验证文件结构 find .claude/skills -name SKILL.md不要小看第三步这行命令它能帮你确认这个skill包的文件夹里到底是不是标准的SKILL.md。我遇到过有的仓库把技能封装在src/目录下还有的仓库把SKILL.md直接写成了README.md这种你就算装进去也不生效必须手动重命名。2.3 不同工具之间的路径差异如果你用的是Codex路径名字变化比较大通常是.codex/skills/# 以OpenAI Codex CLI为例 mkdir -p ~/.codex/skills cp -r my-skill ~/.codex/skills/OpenCode则是.opencode/skills/或阅读项目文档确认。这个差异坑了不少人我见过有人把技能装到Claude Code的目录里却拿OpenCode去跑半天没反应还以为是技能包坏了。我再给个通用排查思路任何AI工具先确认它官方文档里“skills目录”到底叫什么。如果实在找不到文档就直接在对话里问它“你的skills目录路径是什么”大部分主流工具都能回答或者你在终端跑tool --help/tool config list比如claude config list看到skills相关的配置项路径自然就清楚了。2.4 网页版能用skills吗这是个高频问题。Claude.ai网页版现在支持上传文件让它读但严格意义上的“自动加载技能目录”还是以CLI为主流。网页版能做的是把SKILL.md作为附件上传再做一次性的任务。我个人的建议是如果你主要工作在网页版就别太折腾“装技能”这件事了因为每次都要手动挂载。真正效率提升是CLI版本的“常驻技能”。3. 自己手写一个Skill到底怎么写3.1 大纲结构拆解与其总等着社区喂不如自己学会写技能因为只有你自己知道团队项目的规范是什么、你想要AI输出什么风格。写一个Skill不需要会编程但需要你会“结构化表达”。标准SKILL.md我只推荐四个模块frontmatter元信息name、description这是让AI判断“什么时候该调用它”的关键写清楚适用范围比堆形容词有用。Why/背景告诉AI这个技能存在的目的与原因避免它机械执行。HowTo/步骤一步步执行清单越具体越好。验收标准/Checklist让AI自己检查是否做对了。我举个例子。假设你的团队用ESLint Prettier但每次AI提交代码总是不跑lint。你可以写一个“lint-fix”的技能--- name: lint-fix description: 检查并修复项目中的lint错误确保提交前通过ESLint和Prettier检查。 --- ## 为什么需要这个技能 - 团队成员频繁提交不符合规范的代码浪费review时间。 ## 执行步骤 1. 运行 npx eslint . --ext .js,.jsx,.ts,.tsx 检查问题 2. 自动修复可以安全修复的问题npx eslint . --fix 3. 运行 npx prettier --write . 4. 重新执行步骤1确认结果为0 error ## 验收标准 - eslint 输出 0 problems - 没有改变功能逻辑只修改格式问题3.2 让Skill触发率更高的描述技巧很多人写完Skill发现“AI根本不调用”问题通常出在description写得模糊。比如写代码时用这个技能这种描述AI根本判断不了什么时候触发。更好的写法是给出“触发条件”而不是定义例如当用户要求重构React组件时当项目需要生成API接口文档时当提交代码前需要检查格式时我这个实践里最有效的一句话是在description里明确写“必须”。比如description: 每次处理Node.js的package.json时必须使用该技能禁止直接修改依赖版本。“必须”这个词能显著提高技能的触发率因为Claude Code会自动匹配与任务相关的技能文件如果它不确定就会跳过明确“必须”能减少跳过的概率。3.3 调试技能的“回环技巧”写完技能不等于一劳永逸。我调试技能的方式是先在会话里明确说“请使用xxx技能处理这个任务”确认技能被加载后观察AI的输出是否符合预期如果不妥就打开SKILL.md修改具体步骤再跑一次直到稳定。如果你想知道技能到底加载没有可以在对话里直接问“你刚才有没有读过xxx文件”。有时候你会发现它说“读了”但做的事还是按默认行为来的这时候多半是Skill内容结构有问题比如步骤太少它找不到可执行的信息。修复方法是把步骤细化到“可主动执行”程度不要写“认真分析需求”这种废话要写“列出约束条件、性能指标、兼容性要求”。4. 不生效、报错、卡死安装后的真实排查与清理4.1 技能没触发先查路径再查描述遇到技能不生效我的排查顺序是确认路径打开终端输入find . -type d -name skills看看技能文件夹是不是歪了。确认文件名必须是SKILL.md不要叫skill.mdLinux/Unix系统大小写敏感。确认格式用编辑器打开该文件frontmatter是否位于最顶部不能有BOM头不能有空行在前。确认描述如果上面都对但没有触发把description写得更有指向性重新加载会话。我踩过的一个最隐蔽的坑文件里有中文字符但编码被存成了GBKAI读取时直接乱码。后来统一改成UTF-8无BOM编码问题再也没出现过。4.2 怎么清理不再需要的技能技能装多了以后AI每次会检索大量文件反而拖慢响应、增加误触发概率。大家熟知的“tibo关于清理skills的方法”其实是社区里流传的一套操作先列出所有技能目录识别出不再需要的直接删除或移动到备份目录而不是直接删光避免想找回时费力。具体排查命令如下ls -la ~/.claude/skills/ ls -la .claude/skills/ du -sh ~/.claude/skills/* | sort -hrdu那行很好用有些技能包看起来猛实际占了好几MB甚至几十MB里头可能带了完整的示例项目代码这些其实可以精简。我会把每个skill目录都打开看一看删掉里面没用的example/、tests/等无关文件只保留SKILL.md和必须的模板。4.3 装了“来路不明”的技能包怎么办GitHub上有很多“collector”型仓库它们把一个几十个技能的合集打包里面总有那么几个质量很低甚至可能引导AI执行危险操作比如“删除生产数据库”“跳过测试提交代码”之类。我的建议是不熟悉来源的技能包只做“代码审查式安装”——打开SKILL.md全文读一遍凡是有敏感操作、含糊表述一律拒绝。安全上一定要留一层底线生产环境项目不要随便装来路不明的技能包因为技能本质上是一段会被自动执行的指令跟直接运行脚本没有本质区别。5. 按场景推荐的skills不走弯路5.1 前端开发该配哪些技能前端开发工作流最值得配的技能一般是代码规范检查、组件抽取、CSS清理、构建工具调试、依赖升级。我现在的前端项目配置了这样一个组合技能名作用关键触发词frontend-lint统一ESLint/Prettier规范检查代码、格式化、lintcomponent-extractor从大文件中抽离可复用组件组件、重构、重复代码tailwind-cleanup清理无用tailwind类名样式清理、classdependency-upgrade安全升级依赖并修复破坏性变更升级、依赖、breaking尤其是dependency-upgrade这个技能社区里常见做法是让它先读取package.json分析当前主版本再运行npm outdated然后选择小版本升级——每一步都需要人工确认避免AI自己一声不吭升级个大版本把项目搞挂。前端开发环境还有个特例如果你用代码沙箱或在线IDE路径要额外小心有些在线环境的文件系统是虚拟的skills目录不一定在预期位置需要先查看环境变量的PWD和HOME。5.2 数学建模比赛和华为杯场景华为杯这类数学建模比赛很多人用上AI工具以后发现最耗时间的不是建模推导而是把想法写成规范论文和数据处理。这个场景下skills能做的比想象中多。我帮学弟学妹配置过比赛用的Codex skills核心是四大件paper-writer按比赛论文模板生成LaTeX章节统一公式编号和图表引用避免“格式丑陋被扣分”。plot-skill根据数据特征选择图表类型自动生成美观的matplotlib或ggplot代码。> AI编程技能包Skills：从安装到自写，把Agent调教成资深工程师
聊到“skills”如果是半年前我会以为是简历上那行“精通XXX”现在再聊“skills”圈子里默认说的是AI编程工具里的技能包是Claude Code、Codex这类Agent工具的灵魂。你可能也有这种感觉同样是Claude Code别人跑一个前端项目像开了挂代码风格统一、架构分层清晰、连提交信息都写得漂漂亮亮轮到自己用它就像个记忆力只有30秒的实习生答一句忘一句改一版崩一版。差别在哪大概率就是别人装了skills你没有。这玩意儿说白了就是给AI提前塞好的一套“工作手册”——你把它要遵守的规范、要走的流程、要调用的命令写成Markdown文件放进指定目录它每次干活就先翻手册再动手。我今天把这些东西从头到尾捋一遍包括它为什么灵、怎么装GitHub上的现成包、怎么自己手写一个、装坏了怎么清再附一份按场景做的推荐清单。看完你大概率能把自己的AI工具从“聊天机器人”调教成“半个资深工程师”。初阶玩家可以直接跳到第2章学安装中阶玩家重点看第3章手写Skill的逻辑已经在用但被搞到烦躁的建议直接看第4章的排查和清理。我尽量用干活的时候踩过的坑来说话不是给你念官方文档。1. 先搞明白skills到底在解决什么1.1 为什么AI有时候很强有时候像个傻子很多人的直觉是AI越懂越多给个大模型啥都能干。这个直觉在“聊天”维度成立在“干活”维度完全失效。聊天是单轮交互你问一句它答一句上下文短信息量小干活是多步流程要拆解任务、选型、写文件、跑测试、看报错、再改上下文越长模型越容易丢失细节尤其是那些“没有写进提示词、但老手默认该知道”的工程习惯。举个具体例子。我早期用Claude Code写一个REST API它能写但写出来的东西是典型的“大锅烩”所有路由堆在一个文件错误处理只有try/catch没有全局拦截数据库连接每次请求都重新建。你说它错了吗没完全错但项目稍大一点就能把你的维护成本拉爆。这时候如果我给它预先加载一个“后端开发skill”它就会按这个skill里定义好的分层架构、目录规则、错误码规范一步步来controller/service/repository拆开连接池统一管理连日志格式都跟我团队里其他项目保持一致。这就是skills的杀伤力——它把“老手脑子里的隐性流程”变成了“AI能读的显性文件”。1.2 Skills到底是个什么文件先打破神秘感skills不是一个插件、不是一个程序也不是什么API密钥。它本质上就是一组结构化的Markdown文档放在约定好的目录里AI在干活前会主动检索并阅读这些文档然后按照文档里的指示行动。不同工具对技能的称呼略有区别Claude Code里叫Agent Skills目录一般是.claude/skills/或者~/.claude/skills/Codex里叫custom prompts或者skills常见路径是.codex/skills/OpenCode这类开源工具也有类似的.opencode/skills/目录。文件格式通常是SKILL.md里面用固定的字段描述这个技能的名字、用途、适用场景、操作步骤。我见过最精简的SKILL.md长这样--- name: frontend-refactor description: 用于前端项目的代码重构自动识别重复代码并抽取组件。 --- ## 使用范围 - 适用于React / Vue项目 - 不适用于Node后端 ## 执行步骤 1. 扫描当前文件的组件层级 2. 识别重复渲染逻辑 3. 将重复部分抽取为独立组件 4. 更新引用 ## 验收标准 - 业务逻辑不变 - 组件命名符合项目规范所以你别把“安装一个skill”想得太复杂本质上就是下载一个这样的文件或文件夹放到约定路径让AI能读得到。1.3 为什么superpower skills在社区突然火了去年到今年社区里冒出一批热门的skills集合“superpower skills”就是其中之一。它的核心思路并不是给你几百个孤立的技能碎片而是给Claude Code提供了一套“元技能”比如教它怎么做计划、怎么写代码、怎么自我反思、怎么在项目之间转移知识。我自己的体会是单独装某个skill解决的是“某一件具体事后不AI能不能做得好”而superpower这类集合解决的是“AI作为一个整体协作对象的思考质量”。后者给人带来的体感提升更大因为它让AI的编码风格更像一个有经验的工程师而不是每次都是机械式复读。超级技能包之所以火还有一个很现实的原因很多人的提示词写得实在太差。与其让用户费劲研究提词工程不如社区里的高手把“正确的工作流”直接封装成文件你只要复制粘贴AI立刻就上了一个档次。这个思路跟当年“UI组件库”有点类似——你要的不是从零造轮子而是开箱即用的生产力。2. 从GitHub装一个现成skills的完整过程2.1 先准备好你的项目目录如果你用的是Claude Code最推荐的安装位置是项目内部的.claude/skills/。这样这个技能只对当前项目生效适合公司里某个特定技术栈的规范。如果你希望所有项目都能用就装到用户目录下的~/.claude/skills/全局生效。我第一次装的时候犯了个低级错误把skill文件丢到了项目根目录结果Claude Code完全没识别到。后来才知道它只扫描特定目录不是所有Markdown都会被当成技能。装之前一定先确认好路径宁可先建一个空目录试一次也别一下丢一堆进去然后全不生效。2.2 手动装一个GitHub上的skills的操作步骤这里以“拉一个GitHub仓库里的skills集合”为例。很多技能包在GitHub上是整个仓库发布的你需要进仓库看一下目录结构决定是整体clone还是只下载某个子文件夹。在项目根目录执行# 1. 如果只要某个skill文件夹先clone整个仓库到临时目录 git clone https://github.com/your-name/awesome-skills.git temp-skills # 2. 把技能目录复制到项目内 cp -r temp-skills/your-skill .claude/skills/ # 3. 验证文件结构 find .claude/skills -name SKILL.md不要小看第三步这行命令它能帮你确认这个skill包的文件夹里到底是不是标准的SKILL.md。我遇到过有的仓库把技能封装在src/目录下还有的仓库把SKILL.md直接写成了README.md这种你就算装进去也不生效必须手动重命名。2.3 不同工具之间的路径差异如果你用的是Codex路径名字变化比较大通常是.codex/skills/# 以OpenAI Codex CLI为例 mkdir -p ~/.codex/skills cp -r my-skill ~/.codex/skills/OpenCode则是.opencode/skills/或阅读项目文档确认。这个差异坑了不少人我见过有人把技能装到Claude Code的目录里却拿OpenCode去跑半天没反应还以为是技能包坏了。我再给个通用排查思路任何AI工具先确认它官方文档里“skills目录”到底叫什么。如果实在找不到文档就直接在对话里问它“你的skills目录路径是什么”大部分主流工具都能回答或者你在终端跑tool --help/tool config list比如claude config list看到skills相关的配置项路径自然就清楚了。2.4 网页版能用skills吗这是个高频问题。Claude.ai网页版现在支持上传文件让它读但严格意义上的“自动加载技能目录”还是以CLI为主流。网页版能做的是把SKILL.md作为附件上传再做一次性的任务。我个人的建议是如果你主要工作在网页版就别太折腾“装技能”这件事了因为每次都要手动挂载。真正效率提升是CLI版本的“常驻技能”。3. 自己手写一个Skill到底怎么写3.1 大纲结构拆解与其总等着社区喂不如自己学会写技能因为只有你自己知道团队项目的规范是什么、你想要AI输出什么风格。写一个Skill不需要会编程但需要你会“结构化表达”。标准SKILL.md我只推荐四个模块frontmatter元信息name、description这是让AI判断“什么时候该调用它”的关键写清楚适用范围比堆形容词有用。Why/背景告诉AI这个技能存在的目的与原因避免它机械执行。HowTo/步骤一步步执行清单越具体越好。验收标准/Checklist让AI自己检查是否做对了。我举个例子。假设你的团队用ESLint Prettier但每次AI提交代码总是不跑lint。你可以写一个“lint-fix”的技能--- name: lint-fix description: 检查并修复项目中的lint错误确保提交前通过ESLint和Prettier检查。 --- ## 为什么需要这个技能 - 团队成员频繁提交不符合规范的代码浪费review时间。 ## 执行步骤 1. 运行 npx eslint . --ext .js,.jsx,.ts,.tsx 检查问题 2. 自动修复可以安全修复的问题npx eslint . --fix 3. 运行 npx prettier --write . 4. 重新执行步骤1确认结果为0 error ## 验收标准 - eslint 输出 0 problems - 没有改变功能逻辑只修改格式问题3.2 让Skill触发率更高的描述技巧很多人写完Skill发现“AI根本不调用”问题通常出在description写得模糊。比如写代码时用这个技能这种描述AI根本判断不了什么时候触发。更好的写法是给出“触发条件”而不是定义例如当用户要求重构React组件时当项目需要生成API接口文档时当提交代码前需要检查格式时我这个实践里最有效的一句话是在description里明确写“必须”。比如description: 每次处理Node.js的package.json时必须使用该技能禁止直接修改依赖版本。“必须”这个词能显著提高技能的触发率因为Claude Code会自动匹配与任务相关的技能文件如果它不确定就会跳过明确“必须”能减少跳过的概率。3.3 调试技能的“回环技巧”写完技能不等于一劳永逸。我调试技能的方式是先在会话里明确说“请使用xxx技能处理这个任务”确认技能被加载后观察AI的输出是否符合预期如果不妥就打开SKILL.md修改具体步骤再跑一次直到稳定。如果你想知道技能到底加载没有可以在对话里直接问“你刚才有没有读过xxx文件”。有时候你会发现它说“读了”但做的事还是按默认行为来的这时候多半是Skill内容结构有问题比如步骤太少它找不到可执行的信息。修复方法是把步骤细化到“可主动执行”程度不要写“认真分析需求”这种废话要写“列出约束条件、性能指标、兼容性要求”。4. 不生效、报错、卡死安装后的真实排查与清理4.1 技能没触发先查路径再查描述遇到技能不生效我的排查顺序是确认路径打开终端输入find . -type d -name skills看看技能文件夹是不是歪了。确认文件名必须是SKILL.md不要叫skill.mdLinux/Unix系统大小写敏感。确认格式用编辑器打开该文件frontmatter是否位于最顶部不能有BOM头不能有空行在前。确认描述如果上面都对但没有触发把description写得更有指向性重新加载会话。我踩过的一个最隐蔽的坑文件里有中文字符但编码被存成了GBKAI读取时直接乱码。后来统一改成UTF-8无BOM编码问题再也没出现过。4.2 怎么清理不再需要的技能技能装多了以后AI每次会检索大量文件反而拖慢响应、增加误触发概率。大家熟知的“tibo关于清理skills的方法”其实是社区里流传的一套操作先列出所有技能目录识别出不再需要的直接删除或移动到备份目录而不是直接删光避免想找回时费力。具体排查命令如下ls -la ~/.claude/skills/ ls -la .claude/skills/ du -sh ~/.claude/skills/* | sort -hrdu那行很好用有些技能包看起来猛实际占了好几MB甚至几十MB里头可能带了完整的示例项目代码这些其实可以精简。我会把每个skill目录都打开看一看删掉里面没用的example/、tests/等无关文件只保留SKILL.md和必须的模板。4.3 装了“来路不明”的技能包怎么办GitHub上有很多“collector”型仓库它们把一个几十个技能的合集打包里面总有那么几个质量很低甚至可能引导AI执行危险操作比如“删除生产数据库”“跳过测试提交代码”之类。我的建议是不熟悉来源的技能包只做“代码审查式安装”——打开SKILL.md全文读一遍凡是有敏感操作、含糊表述一律拒绝。安全上一定要留一层底线生产环境项目不要随便装来路不明的技能包因为技能本质上是一段会被自动执行的指令跟直接运行脚本没有本质区别。5. 按场景推荐的skills不走弯路5.1 前端开发该配哪些技能前端开发工作流最值得配的技能一般是代码规范检查、组件抽取、CSS清理、构建工具调试、依赖升级。我现在的前端项目配置了这样一个组合技能名作用关键触发词frontend-lint统一ESLint/Prettier规范检查代码、格式化、lintcomponent-extractor从大文件中抽离可复用组件组件、重构、重复代码tailwind-cleanup清理无用tailwind类名样式清理、classdependency-upgrade安全升级依赖并修复破坏性变更升级、依赖、breaking尤其是dependency-upgrade这个技能社区里常见做法是让它先读取package.json分析当前主版本再运行npm outdated然后选择小版本升级——每一步都需要人工确认避免AI自己一声不吭升级个大版本把项目搞挂。前端开发环境还有个特例如果你用代码沙箱或在线IDE路径要额外小心有些在线环境的文件系统是虚拟的skills目录不一定在预期位置需要先查看环境变量的PWD和HOME。5.2 数学建模比赛和华为杯场景华为杯这类数学建模比赛很多人用上AI工具以后发现最耗时间的不是建模推导而是把想法写成规范论文和数据处理。这个场景下skills能做的比想象中多。我帮学弟学妹配置过比赛用的Codex skills核心是四大件paper-writer按比赛论文模板生成LaTeX章节统一公式编号和图表引用避免“格式丑陋被扣分”。plot-skill根据数据特征选择图表类型自动生成美观的matplotlib或ggplot代码。>