但是对于一些重复性、特定领域的任务，我们每次执行任务时都需要对AI进行重复的调教。
┌─────────────────────────────────────────────────────────────┐│ ││ AI 是一个"超级通才" ││ ││ 它什么都会，但什么都不精 ││ ││ 它不记得你上次是怎么要求的 ││ ││ 它不知道你们团队的规范和偏好 ││ │└─────────────────────────────────────────────────────────────┘
我们需要的是：
一种方式，让 AI 记住"怎么做某件事"，下次只需说一句话，它就能按照我们定义的方式执行。
这就是 Skill。
Skill 是什么
01 官方定义
Skill = 可复用的专家知识包
它是一组打包好的指令、知识和工具，让 AI 在特定领域从"通才"变成"专家"
Skill可以教会Qoder如何以特定的SOP完成特定任务
02 让人眼前一亮的优势
03 一个 Skill 长什么样
# ~/.qoder/skills/api-mocker/SKILL.md---name: api-mockerdescription: |根据 API 定义生成 Mock 测试数据。当用户说"生成mock数据"、"造测试数据"时使用。---# API Mock 数据生成器## 规则1. 分析用户提供的接口定义2. 根据字段名推断数据语义（name→姓名，email→邮箱）3. 生成 5 条真实感数据## 字段映射- name/姓名 → 中文姓名（王晓明、刘思远）- email → user_xxx@example.com- phone → 138-XXXX-XXXX- avatar → https://api.dicebear.com/7.x/avataaars/svg?seed=随机## 输出JSON 数组，用代码块包裹
就这么简单：一个目录 + 一个 SKILL.md 文件。
04 Prompt vs. Skills
“Skill不就是一个保存Prompt的地方吗？”
没错，但是并没有体现Skill厉害之处。
Prompt告诉AI来做什么，而Skills则告诉AI如何判断以及整个流程如何进行。
Skills让我们能把自己的判断逻辑、处理流程写成一个Qoder可以反复执行的模块。
05 Skill 的三层结构
┌─────────────────────────────────────────────────────────────┐│ Layer 1: 元数据│ ├── name: skill 的名字 ││ └── description: 什么时候该用这个 skill（触发条件） │├─────────────────────────────────────────────────────────────┤│ Layer 2: 核心指令（触发时才加载） ││ └── SKILL.md 正文：具体怎么做 │├─────────────────────────────────────────────────────────────┤│ Layer 3: 附加资源（按需加载） ││ ├── scripts/ → 可执行脚本（Python/Bash） ││ ├── references/ → 参考文档（API 文档、规范说明） ││ └── assets/ → 资源文件（模板、图片） │└─────────────────────────────────────────────────────────────┘
为什么要分层？
-
AI 的上下文窗口是有限的"公共资源"
-
如果所有 Skill 的内容都一直在上下文里，会浪费大量 Token
-
分层设计：只有 name 和 description 始终存在，正文和资源按需加载
这就是渐进式加载（Progressive Disclosure）设计。
怎么使用 Skill
01 Skill 的存储位置
全局 Skill（所有项目可用）~/.qoder/skills/├── pdf-processing/│ └── SKILL.md├── code-reviewer/│ └── SKILL.md└── ...项目 Skill（仅当前项目可用）your-project/└── .qoder/└── skills/└── project-specific-skill/└── SKILL.md
02 查看已安装的 Skill
在 Qoder CLI 中输入：
/skills
你会看到类似这样的界面：
> /skills------------------------------------------------------------------------------------------------------------Skill Commands: [User] ProjectSkill list:→ code-reviewer : [user] 审查代码并提供改进建议。当需要代码审查、查找潜...- pdf-processing : [user] -Extract text, fill forms, merge PDFs. Use when working with PDF files,...Press Enter to select · Esc to exit · Tab to cycle tabs · ↑↓ to navigate
三个级别：
-
User：存储在 ~/.qoder/skills/ ，所有项目可用
-
Project：存储在 项目/.qoder/skills/ ，仅当前项目可用
03 使用 Skill 的两种方式
方式一：自动触发
你只需正常描述你的需求，AI 会根据 Skill 的 description 自动判断是否使用，例如，pdf-processing技能。
帮我查看这个xxx.pdf的内容
这就是为什么 description 很重要 —— 它是 AI 判断"何时使用这个 Skill"的依据。
方式二：手动调用
如果你想强制使用某个 Skill，可以用命令：
/pdf-processing
或者在对话中明确指定：
使用 pdf-processing skill 帮我查看这个xxx.pdf的内容
Skill实战
01 微服务应用问题排查
场景
在 K8s 集群中部署了一套微服务应用，某天突然发现接口报错 500。需要快速定位是哪个服务出了问题。
传统方式：登录各个 Pod → 翻日志 → 分析调用链 → 定位问题
使用 Skill：进入 Pod → 跟 Qoder CLI 说一句"帮我排查问题" → 自动完成排查
核心思路
这个 Skill 的价值在于：把项目架构知识固化下来
-
服务有哪些？调用关系是什么？
-
出问题时该调用哪些接口验证？
-
日志里哪些关键字代表什么含义？
这些"确定性知识"写进 Skill，让 AI 按照 SOP 自主排查。
Skill 内容
存储到/.qoder/skills/microservice-troubleshooter/SKILL.md
---name: microservice-troubleshooterdescription: |微服务问题排查专家。自动诊断 A、B、C 三个服务组成的微服务架构中的问题，生成排查报告和修复建议。触发场景：用户请求 "排查微服务问题"、"诊断错误"、"分析日志"、"查找异常"等直接触发这个SKILL进行排查---# 微服务问题排查## 项目架构本项目由 3 个 Spring Boot 微服务组成，通过 HTTP (RestTemplate) 进行链式调用：
用户请求 → A服务(/a) → B服务(/b) → C服务(/c) → 返回结果
### 服务说明| 服务 | 端口 | 职责 | 下游依赖 ||------|-------|------|----------|| A | 20001 | 入口服务，接收用户请求 | 调用 B 服务 || B | 20002 | 中间层服务 | 调用 C 服务 || C | 20003 | 末端服务，返回最终结果 | 无 |### 注册中心说明/root/nacos/naming/目录是微服务注册中心的缓存，当前已用【直接】依赖的服务，订阅的微服务实例的地址会缓存到这个目录下，其中包含所有订阅服务的实例列表因此可以在/root/nacos/naming/目录下查找阅读依赖服务的相关信息### 调用链路
HTTP 链路: A(/a) –RestTemplate–> B(/b) –RestTemplate–> C(/c)
## 排查流程### Step 1: 在当前 Pod 测试本地接口通过 curl 调用本地接口，观察返回结果或错误信息：**A 服务接口** (在 A Pod 中执行)```bashcurl localhost:20001/a # HTTP 全链路调用 A→B→Ccurl localhost:20001/a-zone # 同城多活链路curl localhost:20001/actuator/health # 健康检查
B 服务接口(在 B Pod 中执行)
curl localhost:20002/b # 调用 C 服务curl localhost:20002/b-zone # 同城多活curl localhost:20002/actuator/health # 健康检查
C 服务接口(在 C Pod 中执行)
curl localhost:20003/c # 返回 C 服务信息 (末端，不依赖其他服务)curl localhost:20003/c-zone # 同城多活curl localhost:20003/actuator/health # 健康检查
Step 2: 查看当前服务日志中的错误
# 搜索日志中的异常信息grep -i "exception|error|失败" *.log | tail -50
Step 3: 分析调用链
-
如果看到 [A] 调用服务B失败 → 问题在 B 或 C
-
如果看到 [B] 调用服务C失败 → 问题在 C
-
如果看到 C service error → C 服务内部错误
注意
如果上述方式都无法找到具体问题，可以在A入口应用Pod中通过
curl localhost:20001/dubbo # Dubbo 全链路调用
通过Dubbo全链路调用排查调用链路问题
**Skill 扩展脚本**```markdown## 优先批量检查B服务实例通过 `/b` 接口批量检测多个B服务实例的状态：```bash用法: ./check_b_instances.sh <ip1> <ip2> ....qoder/skills/microservice-troubleshooter/scripts/check_b_instances.sh 10.192.168.34 10.192.168.35# 实例IP可从 /root/nacos/naming/ 目录获取
状态说明：
-
[存活-正常] – 服务正常响应
-
[存活-有错误] – 服务存活但返回5xx错误（业务异常）
-
[不可达] – 服务无法连接
>存储到<project-path>/.qoder/skills/microservice-troubleshooter/scripts/check_b_instances.sh>```markdown#!/bin/bash## B服务多实例健康检查脚本# 通过 /b 接口判断服务状态# 用法: ./check_b_instances.sh <ip1> <ip2> <ip3> ...# 示例: ./check_b_instances.sh 10.192.168.34 10.192.168.35 10.192.168.36#PORT=20002TIMEOUT=3# 颜色定义RED='
