AI Agent(智能体)真正难用的地方,往往不是模型不会回答,而是每次都要重新解释背景、步骤、工具、边界条件和交付格式。Skill 解决的就是这个问题:把一套可复用的工作流写成结构化指令包,让 Agent 在合适的场景自动加载并执行。
Skill 不应该被理解成“替代人”的工具。它更像一个可复制的操作手册,适合接管重复、冗长、容易出错的任务;人仍然负责定义目标、判断结果、处理例外和决定是否发布到更大的范围。工程价值不在“把所有事交给 Agent”,而在“把稳定流程沉淀下来,让 Agent 少走弯路”。
Skill 是什么
Skill 是一个放在特定目录里的指令包,核心文件通常叫 SKILL.md。它告诉 Agent:
- 什么场景需要启用这个 Skill;
- 从用户输入里提取哪些信息;
- 按什么步骤执行任务;
- 需要调用哪些脚本、文档或外部资源;
- 出错时应该如何处理。
可以把 Skill 理解成 Agent 的“技能卡”。Agent 平时只知道技能卡的名字和说明,真正需要执行任务时,才会读取完整说明和附加资源。
| 现实里的概念 | Skill 里的对应物 |
|---|---|
| 操作手册 | SKILL.md |
| 手册封面标题和简介 | YAML front-matter 里的 name 和 description |
| 操作步骤 | Markdown 正文里的工作流 |
| 附录、模板、脚本 | references/、assets/、scripts/ |
| 员工按手册执行 | Agent 按 Skill 执行 |
一个最小 Skill 只需要一个文件:
my-skill/
└── SKILL.md
复杂 Skill 会带上脚本、参考资料和模板:
my-skill/
├── SKILL.md
├── scripts/
│ └── send.py
├── references/
│ ├── aliyun.md
│ └── aws.md
└── assets/
└── template.md
Skill 的三级加载机制
Skill 的设计重点不是“把所有说明一次性塞给模型”,而是“让 Agent 按需读取”。大语言模型的上下文窗口有限,如果每个 Skill 都完整加载,很快就会把上下文挤满,还会增加误触发和指令冲突的概率。
典型加载过程可以分成三层:
flowchart TD
A[用户提出任务] --> B[Agent 扫描所有 Skill 的 name 和 description]
B --> C{是否匹配某个 Skill}
C -- 否 --> D[按普通对话处理]
C -- 是 --> E[加载对应 SKILL.md 正文]
E --> F{执行中是否需要附加资源}
F -- 否 --> G[按正文工作流执行]
F -- 是 --> H[按需读取 references 或执行 scripts]
H --> G
G --> I[返回结果并说明关键步骤]
三层分别承担不同职责:
| 层级 | 加载内容 | 作用 |
|---|---|---|
| 第一级 | name、description | 判断用户任务是否需要启用某个 Skill |
| 第二级 | SKILL.md 正文 | 提供执行步骤、参数、错误处理规则 |
| 第三级 | scripts/、references/、assets/ | 处理确定性逻辑、长文档、模板和静态资源 |
这种设计有两个好处:Agent 平时只看很短的描述,不浪费上下文;任务复杂时又能逐步读取更细的资料,避免让主文件变成几千行的“万能提示词”。
安装和使用 Skill
不同平台对 Skill 的安装目录和市场形态不完全一样,但使用方式大致相同:获取 Skill 包,放到平台能识别的位置,重启或刷新 Agent 后生效。
常见渠道可以分成三类:
| 渠道 | 适合场景 | 使用方式 |
|---|---|---|
| Skill 市场 | 直接使用别人发布的 Skill | 搜索、安装、更新 |
| ZIP 包 | 离线分发或小范围试用 | 下载后解压到指定目录 |
| Git 仓库 | 团队维护、版本管理、持续迭代 | clone 或软链到 Skill 目录 |
以 Aone Copilot 为例,手动安装时可以把 Skill 解压到用户级目录:
unzip my-skill.zip -d ~/.aone_copilot/skills/
如果是项目级 Skill,可以放到项目目录中,让它跟随代码仓库一起管理:
unzip my-skill.zip -d .skills/
使用内部 CLI(命令行界面)工具时,安装过程可以进一步简化。以 aone-kit 为例:
npm install -g @ali/aone-kit --registry=https://registry.anpm.alibaba-inc.com
安装某个 Skill:
aone-kit skill install <skill-name>
安装到指定目录:
aone-kit skill install <skill-name> --location ~/.aone_copilot/skills
全局安装:
aone-kit skill install <skill-name> --global
查看已安装 Skill:
aone-kit skill list
安装完成后,通常可以在 Agent 的 Skill 面板中看到新增项,也可以在输入框中通过平台提供的快捷方式唤起。不同平台可能叫法不同,但核心判断标准只有一个:Agent 是否能读取到对应目录下的 SKILL.md。
创建第一个 Skill
一个 Skill 的核心是 SKILL.md。它由两部分组成:
- YAML front-matter:描述 Skill 的元信息和触发条件;
- Markdown 正文:写清楚 Agent 要怎么执行任务。
YAML front-matter
name 和 description 是最关键的两个字段。前者是唯一标识,后者决定 Agent 什么时候触发这个 Skill。
---
name: dingtalk-webhook-skill
description: 通过钉钉自定义机器人 Webhook 发送群消息。当用户提到钉钉、机器人、webhook、群消息、通知、dingtalk、发消息时触发。
license: MIT
compatibility:
- aone-copilot
- claude-3.5+
metadata:
version: 1.2.0
category: communication
tags:
- dingtalk
- webhook
- notification
---
字段建议如下:
| 字段 | 必需 | 说明 |
|---|---|---|
name | 是 | Skill 唯一标识,建议只使用小写字母、数字和连字符,例如 dingtalk-webhook-skill |
description | 是 | 触发描述,要写清“能做什么”和“什么场景该用” |
license | 否 | 许可证,例如 MIT、Apache-2.0 |
compatibility | 否 | 适配的平台、模型或 Agent |
metadata.version | 否 | 语义化版本号,例如 1.2.0 |
metadata.category | 否 | 分类信息 |
metadata.tags | 否 | 标签数组,便于检索 |
description 不要写得太抽象。Agent 通常会保守触发,如果描述里缺少关键词,它可能不会使用本来应该使用的 Skill。
| 写法 | 问题 |
|---|---|
发送钉钉消息的技能 | 过于笼统,缺少触发场景 |
通过钉钉自定义机器人 Webhook 发送群消息。当用户提到钉钉、机器人、webhook、群消息、通知、dingtalk、发消息时触发。 | 任务、工具和关键词都清楚 |
Markdown 正文
正文是给 Agent 的操作手册,建议固定包含这些部分:
| 模块 | 作用 |
|---|---|
| 快速开始 | 给 1 到 2 个用户输入示例,让 Agent 快速理解使用场景 |
| 参数列表 | 说明需要哪些输入、是否必需、默认值是什么 |
| 工作流 | 按步骤描述执行过程 |
| 错误处理 | 列出常见异常和处理方式 |
| 附加资源 | 告诉 Agent 何时读取 references/ 或执行 scripts/ |
一个完整的钉钉通知 Skill 可以这样写:
---
name: dingtalk-notifier
description: 通过钉钉机器人发送群消息通知。当用户提到“发钉钉消息”、“钉钉通知”、“群消息”、“webhook”时触发。
metadata:
version: 1.0.0
category: communication
tags:
- dingtalk
- webhook
- notification
---
# 钉钉群消息通知
通过钉钉自定义机器人 Webhook 发送群消息。
## 快速开始
用户输入示例:
> 帮我发一条钉钉消息到部署群,内容是:v2.1.0 已发布上线
## 参数列表
| 参数 | 必需 | 默认值 | 说明 |
|---|---|---|---|
| `webhook_url` | 是 | 无 | 钉钉机器人的 Webhook 地址 |
| `message` | 是 | 无 | 消息正文 |
| `msg_type` | 否 | `markdown` | 消息类型,支持 `text` 或 `markdown` |
## 工作流
### Step 1:解析参数
从用户输入中提取 `webhook_url`、`message` 和 `msg_type`。
缺少 `webhook_url` 或 `message` 时,不要猜测,向用户补充询问。
### Step 2:发送消息
调用本地脚本发送消息:
```bash
python3 scripts/send.py --url "$WEBHOOK_URL" --msg "$MESSAGE" --type markdown
不要在回复中泄露完整 Webhook 地址。
Step 3:确认结果
检查脚本返回的 JSON:
errcode为0,说明发送成功;errcode非0,根据错误信息提示用户检查配置。
错误处理
| 错误 | 处理方式 |
|---|---|
| Webhook 地址缺失 | 询问用户提供地址 |
| token 无效 | 提示用户检查 Webhook 是否复制完整 |
| 签名错误 | 提示用户检查加签密钥或机器人安全设置 |
| 网络失败 | 说明请求失败,并建议稍后重试 |
对应的脚本可以放在 `scripts/send.py`。确定性的网络请求、签名计算、格式转换都适合下沉到脚本里,避免让 Agent 每次临场拼代码。
```python
#!/usr/bin/env python3
import argparse
import json
import sys
import urllib.request
def main():
parser = argparse.ArgumentParser()
parser.add_argument("--url", required=True)
parser.add_argument("--msg", required=True)
parser.add_argument("--type", default="markdown", choices=["text", "markdown"])
args = parser.parse_args()
if args.type == "text":
payload = {
"msgtype": "text",
"text": {
"content": args.msg
}
}
else:
payload = {
"msgtype": "markdown",
"markdown": {
"title": "通知",
"text": args.msg
}
}
data = json.dumps(payload).encode("utf-8")
request = urllib.request.Request(
args.url,
data=data,
headers={"Content-Type": "application/json"},
method="POST",
)
try:
with urllib.request.urlopen(request, timeout=10) as response:
body = response.read().decode("utf-8")
print(body)
except Exception as exc:
print(json.dumps({"errcode": -1, "errmsg": str(exc)}, ensure_ascii=False))
sys.exit(1)
if __name__ == "__main__":
main()
脚本输出 JSON 到标准输出,Agent 就能稳定解析结果。成功时退出码为 0,失败时退出码非 0,这比让 Agent 根据一段自然语言猜测状态可靠得多。
写好 Skill 的四步
不要一上来就写流程。流程只是 Skill 的一部分,触发时机、输入输出和边界规则同样重要。
flowchart LR
A[确定触发时机] --> B[确定输入与输出]
B --> C[设计执行流程]
C --> D[补充规则、错误处理和示例]
1. 确定触发时机
先写清用户在什么情况下会用到这个 Skill。触发词、常见表达、上下文条件都应该进入 description。
例如工单处理 Skill:
description: 工单批量预处理技能。当用户提到“处理所有工单”、“排查所有工单”、“批量处理工单”、“我的工单有多少”、“帮我看看工单”时触发。
2. 确定输入与输出
Skill 需要哪些参数,最终产物是什么,都要提前定下来。输入输出不清楚,Agent 容易在执行过程中发散。
| 问题 | 示例 |
|---|---|
| 必要输入是什么 | 工单列表、项目 ID、时间范围 |
| 可选输入是什么 | 优先级、负责人、过滤条件 |
| 输出是什么 | 汇总表格、处理建议、变更 PR、通知消息 |
| 输出格式是什么 | Markdown 表格、JSON、代码补丁、命令执行结果 |
3. 设计执行流程
流程建议控制在 3 到 7 步。步骤太少,Agent 不知道怎么做;步骤太多,执行时容易丢失重点。
## 工作流
1. 从用户输入中提取项目 ID 和时间范围。
2. 查询目标时间范围内的工单列表。
3. 按状态、优先级和负责人分组。
4. 对高优先级未处理工单生成处理建议。
5. 输出 Markdown 汇总表格。
6. 对缺少负责人或信息不完整的工单单独列出。
4. 补充规则和错误处理
边界情况要写成明确规则,而不是依赖 Agent 自己猜。
## 规则
- 不要关闭用户没有明确授权关闭的工单。
- 缺少负责人时,只输出建议,不自动分配。
- 遇到接口超时,最多重试 2 次。
- 查询结果超过 200 条时,先输出分组摘要,再询问是否继续处理明细。
SKILL.md 的写作原则
Skill 写给 Agent 执行,不是写给人欣赏。表达越直接,执行越稳定。
| 原则 | 推荐写法 | 不推荐写法 |
|---|---|---|
| 用祈使句 | 从用户输入中提取 webhook_url 参数。 | Agent 应该从用户输入中提取参数。 |
| 解释原因 | 使用可见浏览器模式打开页面,因为目标站点会检测无头环境。 | 必须使用可见浏览器模式。 |
| 控制篇幅 | 主文件放核心流程,长资料放 references/ | 把所有背景资料都塞进 SKILL.md |
| 少绑定平台 | 调用 shell 命令执行脚本。 | 调用 Bash 工具执行脚本。 |
| 少硬编码示例 | 写通用规则和参数 | 只针对一个固定 case 写死流程 |
当 SKILL.md 超过几百行时,优先拆分:
cloud-deploy/
├── SKILL.md
└── references/
├── aliyun.md
├── aws.md
└── azure.md
SKILL.md 只保留通用流程和选择逻辑。用户要求部署到阿里云时,Agent 再读取 references/aliyun.md;要求部署到 AWS 时,只读取 references/aws.md。这样能减少上下文污染。
脚本也要遵守几条工程规则:
| 建议 | 原因 |
|---|---|
| 优先零依赖 | 减少用户环境问题 |
| 提供降级方案 | Python 不可用时可退到 Node.js 或 Shell |
| 输出结构化 JSON | 方便 Agent 解析 |
| 明确退出码 | Agent 能判断成功或失败 |
| 不打印敏感信息 | 避免 token、密钥、Webhook 泄露 |
发布和管理 Skill
Skill 从写出来到被团队稳定使用,需要经历完整生命周期:
flowchart LR
A[编写] --> B[测试]
B --> C[代码评审]
C --> D[发布]
D --> E[安装]
E --> F[使用反馈]
F --> G[更新]
G --> B
如果把 Skill 只当 Markdown 文档,发布会变得很随意;如果把 Skill 当成代码包,就会自然引入仓库治理、测试、版本、回滚和安全扫描。
发布方式
常见发布方式有两种:
| 方式 | 适合场景 | 优点 | 注意点 |
|---|---|---|---|
| Git 仓库发布 | 团队长期维护 | 方便代码评审、版本追踪、回滚 | 发布分支、权限和流水线要统一 |
| ZIP 包发布 | 小范围试用、离线交付 | 简单直接 | 更新分发和版本追踪较弱 |
以 Aone 平台为例,Git 仓库发布更适合长期维护。创建 Skill 后平台生成仓库,本地开发完成后 push 到发布分支,再到平台发起发布。很多平台默认发布分支是 main,不要把仓库误初始化成 master 后再排查发布失败。
版本管理
Skill 没有版本,后续更新会很难追踪。建议至少维护三样东西:
my-skill/
├── SKILL.md
├── CHANGELOG.md
├── package.json
└── scripts/
metadata.version 使用语义化版本:
metadata:
version: 1.3.0
版本号可以按这个规则更新:
| 变更类型 | 示例 | 版本变化 |
|---|---|---|
| 修复错误 | 修正参数名、补充错误处理 | 1.2.0 → 1.2.1 |
| 增加兼容能力 | 新增一种消息格式 | 1.2.0 → 1.3.0 |
| 破坏性变更 | 删除旧参数、改变输出结构 | 1.2.0 → 2.0.0 |
如果旧版本不再维护,可以在 description 或正文开头明确提示:
description: "[DEPRECATED] 旧版钉钉通知 Skill,请升级到 dingtalk-notifier v2。当用户仍调用旧版发送钉钉消息时,提示升级。"
这种做法能让已安装旧版的用户在触发时看到升级提醒。
跨平台 Skill 的兼容问题
不同 Agent 平台对工具名、路径、快捷命令和特殊语法的支持不同。一个 Skill 在 Aone Copilot 可用,不代表在 Claude Code、Cursor、Codex 或其他平台上行为一致。
常见污染有三类:
| 污染类型 | 示例 | 风险 |
|---|---|---|
| 平台语法污染 | @团队成员、/cmd、!bash | 不支持的平台会把它当普通文本,甚至误解含义 |
| 工具命名污染 | 写死 Bash、WebFetch、Read | 不同平台工具名不同,可能找不到工具 |
| 路径环境污染 | 写死 ~/.claude/skills/ 或某个平台环境变量 | 换平台后路径失效 |
跨平台写作可以遵守“三纯净”原则:
| 原则 | 做法 |
|---|---|
| 正文纯文本 | 不把平台专属触发符当通用指令 |
| 工具写能力 | 写“调用 shell 命令执行脚本”,少写具体工具名 |
| 路径不写死 | 使用相对路径或 <workspace> 这类占位符 |
确实需要平台专属能力时,可以用 HTML 注释隔离:
<!-- platform: accio-work -->
当任务需要团队协作时,使用 `@团队成员` 触发分配。
<!-- /platform -->
<!-- platform: aone-copilot -->
当任务需要工单流转时,使用 `/ticket assign` 命令。
<!-- /platform -->
<!-- platform: default -->
当任务需要分配时,输出“建议指派给:<候选人>”,由用户手动操作。
<!-- /platform -->
支持的平台可以按需渲染,不支持的平台通常会忽略注释内容。为了更稳,还要给每段平台特定逻辑准备默认降级方案。
发布前至少做三项检查:
| 检查项 | 通过标准 |
|---|---|
| 跨平台冒烟测试 | 至少在两个目标平台跑同一组输入,输出结构一致 |
| 降级路径 | 平台专属能力不可用时,有替代方案 |
description 中性化 | 除非 Skill 只服务某个平台,否则不要在触发描述里绑定平台名 |
最重要的兜底策略是把确定性逻辑放进 scripts/。只要目标平台能执行 shell 命令,Python、Node.js 或 Shell 脚本就能提供更稳定的结果,减少 Agent 在不同平台上“自由发挥”的空间。
把 Skill 当代码包治理
Skill 一旦被加载,就会影响 Agent 的行为;如果它还能调用工具、读写文件、执行命令,那它就不只是文档,而是带有执行能力的代码包。
团队级 Skill 建议引入这些门禁:
| 阶段 | 做法 |
|---|---|
| 仓库治理 | 保护 main 分支,合并必须走 PR(Pull Request,合并请求) |
| 代码评审 | 核心 SKILL.md 至少 1 人 CR(Code Review,代码评审) |
| 自动校验 | CI(持续集成)运行 schema 校验、敏感词扫描、prompt lint |
| 脚本测试 | scripts/ 目录必须有单元测试 |
| 回归评测 | 每次变更跑固定用例,结果不能低于上一版 |
| 灰度发布 | 支持 channel 时先发 beta,验证后升 stable |
| 安全扫描 | 检查注入风险、敏感信息、越权工具调用 |
一个简单的 CI 流程可以这样设计:
flowchart TD
A[提交 PR] --> B[检查 SKILL.md 结构]
B --> C[扫描敏感信息]
C --> D[运行 scripts 单测]
D --> E[执行 Skill 回归评测]
E --> F{是否通过}
F -- 否 --> G[阻止合并]
F -- 是 --> H[允许合并]
H --> I[发布 beta]
I --> J[人工确认]
J --> K[发布 stable]
Skill 的质量问题通常不是模型能力不足,而是缺少工程约束。没有评测用例,改动就无法比较;没有版本,用户就无法定位问题;没有安全扫描,指令注入和敏感信息泄露会迟早出现。
提高本地调试效率
创建 Skill 很快,慢的是调试循环。常见低效流程是:改一行 SKILL.md,让 Agent 重新加载,发现没生效,重启会话,再重新输入测试用例。小改动也可能耗费几分钟。
更合理的本地开发循环是:
flowchart LR
A[编辑 SKILL.md] --> B[热加载或软链同步]
B --> C[运行固定测试输入]
C --> D[比较输出差异]
D --> E{是否通过}
E -- 否 --> A
E -- 是 --> F[提交变更]
几种实用做法:
| 做法 | 说明 |
|---|---|
| 热加载 | 使用支持热加载的平台,修改后无需重启会话 |
| 软链开发 | 把开发仓库软链到平台 Skill 目录 |
| 文件监听 | 保存文件后自动跑校验和评测 |
| 评测驱动 | 先写测试用例,再改 Skill |
| 双会话对照 | 一个会话加载开发版,一个会话加载稳定版,对比同一输入的输出 |
软链方式很适合本地开发:
# 在 Skill 仓库根目录执行
ln -s "$(pwd)" ~/.aone_copilot/skills/my-skill
这样编辑器里改的就是平台读取的目录,不需要反复复制文件。
可以再加一个简单的 watcher:
# 示例:文件变化时运行校验脚本
fswatch SKILL.md scripts references | while read file; do
./scripts/check-skill.sh
done
check-skill.sh 可以包含 front-matter 校验、敏感信息扫描和回归测试:
#!/usr/bin/env bash
set -euo pipefail
python3 scripts/validate-frontmatter.py SKILL.md
python3 scripts/scan-secrets.py .
python3 scripts/run-evals.py evals/
用评测驱动 Skill 迭代
Skill 的回归评测不需要一开始就做得很复杂。最小可用形式是一组输入和期望输出规则。
[
{
"name": "缺少 webhook 时询问用户",
"input": "帮我发一条钉钉消息:部署完成",
"expect": {
"must_ask": ["webhook_url"],
"must_not_contain": ["https://oapi.dingtalk.com/robot/send"]
}
},
{
"name": "正常发送消息",
"input": "使用 webhook_url=*** 发送钉钉通知:v2.1.0 已上线",
"expect": {
"must_call_script": "scripts/send.py",
"must_contain": ["发送结果"]
}
}
]
评测重点不是追求复杂指标,而是覆盖容易退化的场景:
| 场景 | 为什么要测 |
|---|---|
| 缺少必需参数 | 防止 Agent 瞎猜 |
| 敏感信息处理 | 防止 token、密钥、Webhook 泄露 |
| 错误返回 | 防止失败时仍报告成功 |
| 平台差异 | 防止迁移后工具名或路径失效 |
| 输出格式 | 防止表格、JSON、代码补丁结构漂移 |
当 Skill 每次修改后都能跑一遍固定用例,迭代就有了基准线。通过率下降时不要合入,避免为了修一个 case 破坏其他场景。
Skill 的自我进化要有护栏
更进一步的做法是让 Skill 记录自己的执行情况,并根据失败案例提出修改建议。这个方向很有用,但不能让 Agent 无限制改自己的规则,否则容易为了通过单个场景引入更大的冲突。
安全的闭环应该是这样:
flowchart TD
A[执行 Skill] --> B[记录输入、输出和用户反馈]
B --> C[Binary Eval 判断 pass 或 fail]
C --> D{是否失败}
D -- 否 --> E[归档成功样例]
D -- 是 --> F[提炼失败原因和修复建议]
F --> G[生成补丁 PR]
G --> H[运行回归评测]
H --> I{评测是否通过}
I -- 否 --> J[拒绝修改]
I -- 是 --> K[人工评审后合并]
Binary Eval 指二元评测,只判断 pass / fail。它比“打 1 到 5 分”更适合自动门禁,因为结果清晰,容易和 CI 流程结合。
可以在 SKILL.md 末尾加入元指令,但必须配合评测:
## 自我改进记录
每次执行完本 Skill 后:
1. 判断任务是否达成目标,只记录 `pass` 或 `fail`。
2. `fail` 时,在 `diary/YYYY-MM-DD.md` 追加失败案例、失败原因和修复建议。
3. 同一类修复建议在最近 3 次失败中重复出现时,生成修改 `SKILL.md` 的 PR。
4. 修改后必须通过 `evals/` 中的全部回归用例,未通过时不要合并。
再配一个执行日志脚本:
python3 scripts/log-execution.py \
--skill dingtalk-notifier \
--input "$USER_INPUT" \
--output "$AGENT_OUTPUT" \
--result fail
日志建议使用 JSONL(按行存储的 JSON)格式:
{"time":"2026-06-07T10:00:00+08:00","skill":"dingtalk-notifier","result":"fail","reason":"missing webhook was not requested"}
没有评测兜底的自我修改风险很高。Agent 可能把一次偶然失败写成永久规则,导致其他场景退化。更稳的策略是“记录失败 → 生成建议 → 跑评测 → 人工确认”。
用一个开发助手 Skill 管理完整闭环
当 Skill 数量变多,真正耗时的不只是写 SKILL.md,还有创建模板、迁移平台、跑评测、发布、批量更新和诊断问题。一个更高效的方式是把 Skill 开发流程本身也封装成 Skill,例如 skill-dev-aio 这种一站式开发助手。
它不应该替代人的判断,而是接管机械环节:
flowchart TD
A[用户描述要做的 Skill] --> B[澄清触发场景和输入输出]
B --> C[生成 SKILL.md 草稿]
C --> D[生成 scripts 和 references]
D --> E[生成 evals 回归用例]
E --> F[运行本地评测]
F --> G{是否通过}
G -- 否 --> H[定位问题并修改]
H --> F
G -- 是 --> I[发布到目标平台]
I --> J[记录版本和变更]
J --> K[收集反馈并批量更新]
可以把能力拆成六块:
| 能力 | 自动化内容 | 人需要判断什么 |
|---|---|---|
| 快速创建 Skill | 生成目录、SKILL.md、示例和参数表 | 目标是否定义准确 |
| 一键发布 | 打包、提交仓库、触发平台发布 | 是否允许发布到目标范围 |
| 优化评测 | 根据失败用例调整描述和流程 | 调整是否符合真实业务 |
| 检查诊断 | 扫描格式、敏感信息、平台污染、缺失资源 | 风险是否可接受 |
| 跨平台迁移 | 改写工具名、路径和平台语法 | 目标平台能力是否等价 |
| 批量更新 | 修改多个 Skill 的版本、规则或依赖 | 是否需要灰度和回滚方案 |
这种“用 Skill 开发 Skill”的模式,能把经验沉淀到工具里。人的主要工作变成定义需求、确认边界、审核结果和控制发布风险;Agent 负责把重复步骤跑稳。
常用资料入口
- Agent Skills 规范与介绍:
https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview - Agent Skills 社区规范:
https://agentskills.io/ - skills.sh:
https://www.skills.sh/ - ClawHub:
https://clawhub.ai/skills - SkillsMP:
https://skillsmp.com/ - Claude Code Plugin Marketplaces:
https://code.claude.com/docs/en/plugin-marketplaces
Skill 开发的核心不是写一段更长的提示词,而是把可复用流程工程化:有清晰触发、有稳定执行、有脚本兜底、有评测门禁、有版本治理。做到这些,Agent 才能从“每次都要重新教”的聊天工具,变成能稳定复用经验的工作流执行器。