尧图网页设计 
1. 从“skills”这个热词说起它到底是什么最近几个月不管是在技术社区还是各种开发者群里“skills”这个词出现的频率高得离谱。很多人第一次看到它会以为是某个新出的编程语言或者框架其实不是。这里说的skills特指围绕 Claude 生态尤其是 Claude Code、Claude Desktop 这类工具构建的一套可复用的能力模块机制。你可以把它理解成给 AI 助手装的“技能插件”——每个 skill 就是一份结构化的说明文档告诉 AI 在遇到某类任务时应该怎么做、按什么流程做、注意哪些坑。核心载体是一个叫SKILL.md的文件。这个文件用 Markdown 写里面包含技能名称、适用场景、操作步骤、注意事项等结构化信息。当你在 Claude Code 里触发某个任务时它会自动匹配对应的 skill然后按照里面定义的流程来执行。这跟以前那种“每次都要重新写一大段 prompt”的方式完全不同skills 把 prompt 工程变成了可版本管理、可分享、可复用的资产。那它解决了什么问题最直接的痛点就是重复劳动。比如你经常要做数学建模、要写前端组件、要处理 STM32 的寄存器配置每次都要跟 AI 解释一遍背景、约束、输出格式烦不烦有了 skills你把这些前置知识固化成一个文件下次直接调用就行。另一个痛点是质量不稳定——同一个任务今天 AI 心情好给你输出得很规范明天可能就漏了关键步骤。skills 通过强制结构化流程把输出质量的下限拉高了。适合谁来用三类人最受益一是经常用 Claude Code 做开发的工程师尤其是前端、嵌入式、数据科学方向二是做数学建模、算法竞赛的学生华为杯、美赛这类比赛里 skills 能大幅提升效率三是AI 应用开发者需要把 AI 能力封装成标准化模块对外提供服务。哪怕你只是刚接触 Claude 的新手花半小时搞懂 skills 的基本写法后面能省下几十个小时的重复沟通成本。提示skills 不是 Claude 独有的概念OpenCode、Codex 等工具也在逐步支持类似的技能机制但目前在 Claude 生态里最成熟、社区资源最多。2. 核心机制拆解SKILL.md 到底怎么写才管用2.1 SKILL.md 的文件结构与字段含义一个标准的 SKILL.md 文件结构其实不复杂但每个字段都有讲究。我拆过几十个社区里流传的 skills 文件发现写得好的和写得烂的差距主要在触发条件的精确度和步骤的可执行性上。先看基本结构。一个典型的 SKILL.md 包含以下几个部分--- name: frontend-component-generator description: 根据需求描述生成 React 函数式组件包含 TypeScript 类型定义和基础样式 trigger: 当用户要求创建前端组件、生成 React 代码、或提到组件开发时触发 --- ## 适用场景 - 需要快速生成标准化的 React 组件骨架 - 需要包含 Props 类型定义和默认值 - 需要生成配套的样式文件 ## 操作步骤 1. 解析用户需求提取组件名称、Props 列表、交互行为 2. 生成 TypeScript 接口定义 3. 生成函数式组件主体 4. 生成对应的 CSS Module 或 styled-components 5. 输出文件结构说明 ## 注意事项 - 组件命名必须使用 PascalCase - Props 必须有完整的类型注解禁止使用 any - 样式文件必须与组件文件同名这里面的关键字段是trigger。很多人写 skills 的时候忽略了这个字段结果就是 AI 根本不知道什么时候该调用这个技能。trigger 写得越具体越好最好包含用户可能说的原话关键词。比如“生成组件”“创建 React 组件”“写一个前端模块”这些都应该覆盖到。description字段也很重要它决定了 AI 在扫描可用 skills 时能不能快速判断这个技能是干什么的。我见过有人写“这是一个很有用的技能”这种描述等于没写。好的 description 应该是一句话讲清楚输入是什么、输出是什么、解决什么问题。2.2 触发机制与匹配逻辑Claude Code 在启动时会扫描指定目录下的所有 SKILL.md 文件建立一个技能索引。当你输入一个请求时它会拿你的请求去跟每个 skill 的 trigger 和 description 做语义匹配。匹配度超过某个阈值就会激活对应的 skill。这个机制听起来简单但实际用起来有几个坑。第一个坑是技能冲突。如果你装了两个功能相近的 skills比如一个叫“react-component”一个叫“frontend-generator”它们都声称能处理组件生成任务那 Claude 可能会随机选一个或者两个都触发导致输出混乱。解决办法是在 trigger 里写清楚边界比如前者专门处理“带状态的类组件”后者专门处理“无状态的函数组件”。第二个坑是触发不灵敏。有时候你明明说了“帮我写个组件”但 skill 就是没触发。这通常是因为 trigger 里的关键词太窄了。我的经验是trigger 里至少要包含 5-8 个同义表达覆盖用户可能用的各种说法。比如“组件”“模块”“部件”“UI 元素”“前端代码”这些都应该列进去。第三个坑是过度触发。有些 skill 的 trigger 写得太宽泛比如只写了“代码”两个字结果你让 AI 写个 Python 脚本它也给你按 React 组件的流程走。这种就要在 trigger 里加上排除条件或者把 description 写得更精确。2.3 技能库的组织方式与目录规范Skills 文件放哪里Claude Code 默认会扫描几个位置项目根目录下的.claude/skills/文件夹、用户主目录下的.claude/skills/、以及通过环境变量指定的额外路径。我建议按领域分类来组织目录比如.claude/skills/ ├── frontend/ │ ├── react-component/SKILL.md │ ├── vue-component/SKILL.md │ └── css-layout/SKILL.md ├── embedded/ │ ├── stm32-init/SKILL.md │ └── uart-config/SKILL.md ├── math-modeling/ │ ├── linear-programming/SKILL.md │ └──>--- name:>## 依赖技能 -> Claude Skills 实战：SKILL.md 编写与技能库搭建指南
1. 从“skills”这个热词说起它到底是什么最近几个月不管是在技术社区还是各种开发者群里“skills”这个词出现的频率高得离谱。很多人第一次看到它会以为是某个新出的编程语言或者框架其实不是。这里说的skills特指围绕 Claude 生态尤其是 Claude Code、Claude Desktop 这类工具构建的一套可复用的能力模块机制。你可以把它理解成给 AI 助手装的“技能插件”——每个 skill 就是一份结构化的说明文档告诉 AI 在遇到某类任务时应该怎么做、按什么流程做、注意哪些坑。核心载体是一个叫SKILL.md的文件。这个文件用 Markdown 写里面包含技能名称、适用场景、操作步骤、注意事项等结构化信息。当你在 Claude Code 里触发某个任务时它会自动匹配对应的 skill然后按照里面定义的流程来执行。这跟以前那种“每次都要重新写一大段 prompt”的方式完全不同skills 把 prompt 工程变成了可版本管理、可分享、可复用的资产。那它解决了什么问题最直接的痛点就是重复劳动。比如你经常要做数学建模、要写前端组件、要处理 STM32 的寄存器配置每次都要跟 AI 解释一遍背景、约束、输出格式烦不烦有了 skills你把这些前置知识固化成一个文件下次直接调用就行。另一个痛点是质量不稳定——同一个任务今天 AI 心情好给你输出得很规范明天可能就漏了关键步骤。skills 通过强制结构化流程把输出质量的下限拉高了。适合谁来用三类人最受益一是经常用 Claude Code 做开发的工程师尤其是前端、嵌入式、数据科学方向二是做数学建模、算法竞赛的学生华为杯、美赛这类比赛里 skills 能大幅提升效率三是AI 应用开发者需要把 AI 能力封装成标准化模块对外提供服务。哪怕你只是刚接触 Claude 的新手花半小时搞懂 skills 的基本写法后面能省下几十个小时的重复沟通成本。提示skills 不是 Claude 独有的概念OpenCode、Codex 等工具也在逐步支持类似的技能机制但目前在 Claude 生态里最成熟、社区资源最多。2. 核心机制拆解SKILL.md 到底怎么写才管用2.1 SKILL.md 的文件结构与字段含义一个标准的 SKILL.md 文件结构其实不复杂但每个字段都有讲究。我拆过几十个社区里流传的 skills 文件发现写得好的和写得烂的差距主要在触发条件的精确度和步骤的可执行性上。先看基本结构。一个典型的 SKILL.md 包含以下几个部分--- name: frontend-component-generator description: 根据需求描述生成 React 函数式组件包含 TypeScript 类型定义和基础样式 trigger: 当用户要求创建前端组件、生成 React 代码、或提到组件开发时触发 --- ## 适用场景 - 需要快速生成标准化的 React 组件骨架 - 需要包含 Props 类型定义和默认值 - 需要生成配套的样式文件 ## 操作步骤 1. 解析用户需求提取组件名称、Props 列表、交互行为 2. 生成 TypeScript 接口定义 3. 生成函数式组件主体 4. 生成对应的 CSS Module 或 styled-components 5. 输出文件结构说明 ## 注意事项 - 组件命名必须使用 PascalCase - Props 必须有完整的类型注解禁止使用 any - 样式文件必须与组件文件同名这里面的关键字段是trigger。很多人写 skills 的时候忽略了这个字段结果就是 AI 根本不知道什么时候该调用这个技能。trigger 写得越具体越好最好包含用户可能说的原话关键词。比如“生成组件”“创建 React 组件”“写一个前端模块”这些都应该覆盖到。description字段也很重要它决定了 AI 在扫描可用 skills 时能不能快速判断这个技能是干什么的。我见过有人写“这是一个很有用的技能”这种描述等于没写。好的 description 应该是一句话讲清楚输入是什么、输出是什么、解决什么问题。2.2 触发机制与匹配逻辑Claude Code 在启动时会扫描指定目录下的所有 SKILL.md 文件建立一个技能索引。当你输入一个请求时它会拿你的请求去跟每个 skill 的 trigger 和 description 做语义匹配。匹配度超过某个阈值就会激活对应的 skill。这个机制听起来简单但实际用起来有几个坑。第一个坑是技能冲突。如果你装了两个功能相近的 skills比如一个叫“react-component”一个叫“frontend-generator”它们都声称能处理组件生成任务那 Claude 可能会随机选一个或者两个都触发导致输出混乱。解决办法是在 trigger 里写清楚边界比如前者专门处理“带状态的类组件”后者专门处理“无状态的函数组件”。第二个坑是触发不灵敏。有时候你明明说了“帮我写个组件”但 skill 就是没触发。这通常是因为 trigger 里的关键词太窄了。我的经验是trigger 里至少要包含 5-8 个同义表达覆盖用户可能用的各种说法。比如“组件”“模块”“部件”“UI 元素”“前端代码”这些都应该列进去。第三个坑是过度触发。有些 skill 的 trigger 写得太宽泛比如只写了“代码”两个字结果你让 AI 写个 Python 脚本它也给你按 React 组件的流程走。这种就要在 trigger 里加上排除条件或者把 description 写得更精确。2.3 技能库的组织方式与目录规范Skills 文件放哪里Claude Code 默认会扫描几个位置项目根目录下的.claude/skills/文件夹、用户主目录下的.claude/skills/、以及通过环境变量指定的额外路径。我建议按领域分类来组织目录比如.claude/skills/ ├── frontend/ │ ├── react-component/SKILL.md │ ├── vue-component/SKILL.md │ └── css-layout/SKILL.md ├── embedded/ │ ├── stm32-init/SKILL.md │ └── uart-config/SKILL.md ├── math-modeling/ │ ├── linear-programming/SKILL.md │ └──>--- name:>## 依赖技能 ->