做前端开发这几年我养成一个不太好的习惯跟 AI 对话时把同样的上下文反复贴进去。写个组件要贴一遍技术栈说明做个 code review 要贴一遍团队规范排查构建问题还要贴一遍项目结构。直到最近把工作流迁移到 Claude Code 和 Codex 这类终端型 AI 工具上开始认真整理自己的 skills才发现以前那种“会话内临时叮嘱”的方式本质上是把技能长在了一个个提示词里换项目就全废了。Skills 要做的事情很朴素把可复用的工作方法、规则、模板沉淀成一个目录让 AI 在对应场景自动加载。这篇东西我不打算讲概念标语就按我这几周实际折腾的经验把 skills 是什么、去哪下、怎么装、怎么写、怎么清理全部过一遍。1. 先想清楚skills 到底解决什么问题1.1 把“临时叮嘱”变成“固定流程”很多人第一次听说 skills 时会把它理解成“一个更高级的 prompt”这么理解不算错但会少想一层。Prompt 是一次性的技能是可复用的。同样是让 AI 做代码审查我过去会写“你是一个资深前端工程师请按照团队的代码契约、性能要求、可维护性标准逐条检查以下代码……”这段话每次都要手打或者从笔记里复制。有了 skill 之后这一段变成frontend-review目录下的固定文件AI 只要看到我丢给它一段 React 组件代码就自动知道启用这套审查流程。往深了说这里面的本质变化是“控制粒度”。Prompt 能控制一次会话的输入输出skill 控制的是 AI 在某个场景下的一整套行为包括判断标准、执行顺序、产出格式甚至跑去调用外部脚本。你可以把它想象成给 AI 配了一本工作手册而不是每次都派发一份口头任务单。工作手册的好处是你可以反复修订它把踩过的坑写进去把团队规范的变化同步进去所有用了这个 skill 的会话都能吃到最新版本。我自己的经验是一套好的 skill 必须回答三个问题什么时候用、按什么步骤做、输出成什么样子。这三个问题回答不清楚写出来的 skill 就是一堆提示词碎片带不来多少确定性。1.2 一个 skill 目录里到底装了什么以 Claude Code 为例一个 skill 本质上就是一个目录目录里至少要有一个SKILL.md入口文件其余内容按需组织。入口文件的开头是一段 YAML frontmatter里面最重要的字段是name和description。name是技能名description是给 AI 看的触发说明写得越具体AI 越容易在合适的时机把它捞起来。结构大致长这样~/some-dir/.claude/skills/frontend-review/ ├── SKILL.md ├── rules/ │ ├── code-style.md │ └── performance.md ├── templates/ │ └── review-report.md └── scripts/ └── check-imports.py很多人在这一步会犯一个错误以为只要把SKILL.md写好就行。实际上当文件内容变长时全部塞进一个文件会让 AI 上下文消耗很快而且查找规则也乱。合理的做法是把规则拆到rules/子目录把报告模板放到templates/把可执行脚本放到scripts/入口文件里只保留触发条件和执行流程并通过相对路径告诉 AI 去读哪个子文件。这样做的逻辑和代码分层是一样的入口尽量薄逻辑尽量外置AI 需要哪块读哪块。1.3 Claude Code、Codex 与 OpenCode各自怎么加载市面上的终端型 AI 工具对 skills 的支持方式不完全一样。Claude Code 的机制最直观有~/.claude/skills/和项目级.claude/skills/两种存放位置/skills命令可以直接列出当前可用技能。Codex 这边没有完全同名的一套目录它更强调AGENTS.md这类从项目根目录开始逐级加载的指令文件可复用的“技能”通常会被组织成独立的 md 文件放进统一目录由AGENTS.md统一引用。OpenCode 也支持类似的 skills 体系社区生态最近热得很快很多新技能包会优先在那边发布。不必纠结哪个工具“最正宗”核心思路是一致的把固定流程从会话里挪到文件系统里。我在本机同时装了 Claude Code 和 Codex实际用下来同一个技能内容会根据工具的加载机制做一点适配但SKILL.md那套组织方式基本都能直接迁移。真正决定体验的是你对目录结构和触发描述的经营而不是工具品牌。2. 社区源头与安装实操从 GitHub 到本机2.1 值得收藏的 skill 仓库和源站点我刚开始找 skills 时第一反应是疯狂搜索“常用 skills 源网站”结果发现社区里比较有影响的大概是这几类按值得收藏的顺序说。第一类是带“superpower skills”这类名字的综合技能包典型特征是作者已经把大量的项目管理、代码审查、研究分析类技能整理成开箱即用的结构clone 下来就能跑。整体质量高但要注意包体比较大别一次全装。第二类是 awesome 清单仓库比如awesome-claude-skills这种本身不包含技能但整理了目录按类别推荐技能适合用来“逛”。我会定期去逛一次把新出现的高星技能记下来再按需安装。第三类是特定技术栈的开源技能集比如typesafe ai skills这类偏工程体系的仓库里面通常自带 TypeScript 项目脚手架、测试生成、package 升级之类的技能适配度比通用技能高。还有像cola skills这种聚合型仓库会把零散的技能包收集到一个源里方便集中管理。源码站点的地址我就不放具体的了因为这类仓库迭代太快你直接在 GitHub 搜索框里敲claude skill、codex skills、awesome claude skills就能摸到最活跃的一批。我的建议是收藏两三个你最常用的源比收藏十个都不碰强。2.2 先把 skill 手动装进来再说不管从哪个仓库下载手动安装的流程都很固定。以 Claude Code 为例先确认你的 skills 根目录存在不存在就新建mkdir -p ~/.claude/skills cd ~/.claude/skills git clone https://github.com/xxx/awesome-skill ./awesome-skill这里有个细节有些仓库的目录结构本来就是skills/xxx/SKILL.mdclone 下来之后得把里层的xxx目录拷出来放进~/.claude/skills/xxx而不是整个仓库直接丢进去。如果路径变成了~/.claude/skills/awesome-skill/skills/xxx/SKILL.md入口文件层级就乱了Claude Code 可能找不到。装完以后要重启当前终端和 Claude Code 会话让技能扫描重新执行。这个“重启”步骤很容易被忽略尤其在你改了目录文件之后不重启就发现 skill 没生效很容易误判成安装失败。如果是 Codex 那一类工具安装思路是把它引导到你的技能目录并确保入口文件被根目录的AGENTS.md引用。最简单的做法是把 skill 目录放在项目里然后在AGENTS.md里写一句“当遇到 XX 任务时读取.codex-skills/xxx/SKILL.md”效果一样。2.3 装完如何确认它就算生效了装完不等于生效我在这一步吃过亏。验证手段我按顺序排一下在 Claude Code 里输入/skills看列表里有没有目标技能。如果列表里没有先检查目录位置对不对再查入口文件名是不是SKILL.md最后确认是否重启。如果列表里有但对话里调用不积极多半是description写得不够具体AI 没识别出触发场景。更彻底的办法是打开调试日志或导出系统提示词直接看这个 skill 有没有被塞进上下文。有些工具支持/context之类命令查看上下文摘要里面能看到当前加载了哪些 skill 文件。安装这件事难度真的不大但非常考验细节点。路径差一级、文件名大小写不对、仓库读取逻辑变了都会让技能静默失效。所以我的习惯是每装一个技能立刻用一句话触发一次能用再继续不能就用清理流程把它删掉不让自己不知不觉囤一硬盘不生效的花架子。3. 动手写一个“前端 code review”skill3.1 先定边界好 skill 不做“全能超人”很多人写技能时容易贪心想一个 skill 覆盖需求分析、代码生成、测试、文档一条龙。结果就是描述写得又长又宽AI 看到什么任务都觉得能触发反而在不需要时也加载污染上下文。我的原则是一个 skill 只干一件事。拿“前端 code review”举例它的边界就是审查不做补丁生成不负责重写代码只负责按既定规则检查代码并输出报告。这样写起来逻辑清晰也方便单测。如果你需要“重构助手”那就再写一个 skill让两个技能各司其职。3.2 一个可直接抄的 SKILL.md 示例下面这个是我实际在用的一套前端审查技能的精简版你按自己的技术栈调整即可。目录结构放在~/.claude/skills/frontend-review/。--- name: frontend-review description: 审查前端 React TypeScript 代码。 当用户提供 JSX/TSX 组件、hooks 文件或要求进行代码审查、PR review 时使用。 不适合做代码重构或直接生成修改补丁。 --- # Frontend Code Review ## 任务目标 按照本目录定义的规范对输入的代码做一次系统审查输出结构化报告。 ## 执行步骤 1. 读取 rules/code-style.md 和 rules/performance.md作为审查依据。 2. 逐条检查传入的代码给出问题位置、违反的具体规则、修复建议。 3. 不要直接改写用户代码只输出报告中“建议”部分。 4. 如果用户要求修改代码请明确给出 diff 建议但不执行。 ## 输出格式 必须按照 templates/review-report.md 的模板输出包括 - 总体评价 - 问题清单按严重程度排序 - 整改建议摘要实际的代码里我还会在rules/performance.md里写团队约定的性能底线比如“避免在 render 中创建内联对象”、“大列表必须虚拟化”之类把团队规范的演变沉淀为文件skill 就会越用越贴合团队。3.3 让 skill 学会调用脚本和查外部文档如果要审查的内容涉及依赖分析光靠 AI 自己读代码是不够的。这时候可以在 skill 里加脚本调用## 依赖检查 运行 python3 scripts/check_imports.py --dir 目标目录 读取输出结果并把循环依赖、未使用依赖列入问题清单。这里我想强调一个容易被忽略的点skill 里的相对路径是相对于 skill 目录的不是相对于当前用户工作目录的。我在早期写技能时脚本里直接写./scripts/xx.py结果实际执行时 AI 从项目根目录找脚本怎么调都找不到。后来所有脚本路径都改成scripts/check_imports.py并把运行前提写清楚“该路径是相对 skill 目录而言”基本就没再出问题。不止脚本外部的规范文档、技术设计文档也可以用类似方式引用。把大段规则放到独立 md 文件里AI 按需读取一方面减少上下文浪费另一方面文档可以单独维护不用每次改动都碰 skill 主文件。3.4 写完之后怎么调三个调试入口写完 skill 不代表能用调试是必须的。我试过的三个办法按效率排序第一个是看触发结果。用一个最小样例触发技能观察 AI 行为是否符合预期。比如拿一个 20 行的小组件让它审查如果它上来就长篇大论而没走“读取 rules → 检查 → 输出模板”的流程说明主文件里的步骤指令不够约束力或者被 system prompt 干扰了。第二个是导出上下文日志。很多终端工具能打印当前会话的 system prompt 或上下文片段直接看 skill 内容有没有被成功加载、加载了哪几个文件。这个方法比猜更快。第三个是逐步增量改。不要一次性写一个超大 skill先写SKILL.md的 5 行主流程跑通再加 rules加 templates加脚本。每次只变更一个变量出问题能立刻定位。4. 实战组合数学建模比赛里的 skills 工作流4.1 建模现场需要哪些 skills聊到技能开发很多人默认是针对编程场景但我在准备华为杯这类数学建模比赛时反而对 skills 的组合价值体会更深。建模比赛的特点是时间集中、任务链长、输出物固定正是技能发挥作用的地方。赛题一般涉及数据读取、特征处理、模型选型、结果解读和论文撰写。这些环节之间是强依赖顺序如果每个环节都用 AI 现场“调教”效率损失太大。我的做法是提前准备这几个技能>