一篇从创建、发布到治理 Skill 的完整指南，并介绍一站式开发助手。
原文标题：重新定义Skill开发：保姆级教程&一站式开发助手发布
原文作者：阿里云开发者
冷月清谈：
文章还覆盖了 Skill 的安装、发布、更新与管理流程，重点提到 Aone Skills、Aone Copilot、AccioWork 等平台中的使用方式。后半部分进一步讨论了跨平台兼容、版本管理、更新分发、调试效率和自我进化等现实问题，建议把 Skill 当作“代码包”治理，而不仅是文档。
最后，作者引出一站式 Skill 开发助手 skill-dev-aio，试图把创建、发布、评分优化、检查、迁移、批量更新等环节整合起来，降低普通开发者使用 Skill 的门槛。
怜星夜思：
2、如果团队里开始大量沉淀 Skill，最应该先建立哪类规范：命名、评测、安全，还是版本管理？
3、文章提到让 Skill 自我进化，你觉得这事靠谱吗？会不会越改越乱？
4、对于普通开发者来说，学习写 Skill 的最大门槛到底是语法，还是把自己的工作流讲清楚？
原文内容
阿里妹导读
从入门到蒸馏，20 分钟以内学会创建、管理和发布你的第一个 Skill —— 让 AI Agent 真正成为你的超级助手。（文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。）
零、写在最前：Skill 会替代我吗？
每当我向同事介绍 Skill 时，最常被问到的一个问题是：
"你把自己的工作流写进 Skill，让 AI 自动跑——那以后还需要你吗？还需要我吗？"
这其实是同一道题的两面：当 AI 学会了我们的"流程"，我们的"价值"还在哪里？
黄仁勋在那段访谈里给了一个非常性感的回答——任务（Task）会被自动化，但体验（Experience）和判断（Judgment）不会。AI 看片子比放射科医生准，结果放射科医生不降反升，因为医生的工作从"看片子"升级成了"诊断疾病"。
把这个逻辑放回 Skill 的语境里：
-
❌ Skill 替代的不是"你"，而是替代你身上那些重复、冗长、易错、本来就不该占用大脑的"任务"。
-
✅ Skill 替代不了的"你"，是你生成的Skill在体验上的丝滑和你对Skill执行的准确性的判断成为你新的价值。
💡 **你需要焦虑的不是"被 Skill 替代"，而是"还没学会用 Skill"**。当别人开始用 Skill 把自己的经验沉淀、复用、放大时，你还在反复手工执行同一套流程——这才是差距的开始。
至于"那以后到底还需要做什么？"，这个问题我会在最后一章 《六、其实你只要一个 Skill》 给出我的解答。先别急着翻到最后，先跟着这份指南把 Skill 的本质看明白，再回头看那个答案，会更有体感。
接下来，让我们从「什么是 Skill」开始 👇
一、一分钟了解什么是 Skill（推荐看）
💡 一句话说清楚
Skill 是一份结构化的指令文档，它告诉 AI Agent「在什么场景下、按什么步骤、用什么工具、完成什么任务」。你可以把它理解为 Agent 的 「技能卡」—— 插上就能用，拔掉就没有。
类比理解
想象你是新入职的员工刘一航（化名），公司给了你一本《阿里开发操作手册》：
|
现实世界
|
Skill 世界
|
|---|---|
|
阿里开发操作手册
|
SKILL.md
文件
|
|
手册封面（标题 + 简介）
|
YAML frontmatter（ name + description）
|
|
开发操作步骤
|
Markdown 正文中的工作流指令
|
|
附录（Aone、语雀、中间件等）
|
Bundled Resources（ scripts/ / references/ / assets/）
|
|
你按开发手册干活
|
Agent 按 Skill 执行任务
|
Skill 的三级加载机制
Skill 并不是一股脑全部塞给 Agent 的，它采用渐进式加载策略，按需提供信息：
💡 为什么要分级加载？
Agent 的上下文窗口是有限的。如果所有 Skill 的全部内容都一次性加载，会迅速耗尽上下文空间。分级加载让 Agent 只在需要时才读取详细指令，既节省资源又保证精准执行。
二、三分钟安装使用 Skill（可以不看）
2.1 Skill 平台介绍
Skill 平台是 Skill 的发布、搜索与安装中心，类似于应用商店。你可以在平台上浏览他人发布的 Skill、一键安装到本地，也可以将自己编写的 Skill 发布出去供他人使用。
|
平台
|
渠道
|
简介
|
搜索方式
|
速度
|
规模
|
认证
|
|---|---|---|---|---|---|---|
|
⚪ skills.sh[1]
|
外部
|
开源工作流自动化，快速安装
|
CLI: npx skills find
|
⚡ 快速
|
~千级
|
❌ 无需
|
|
⚪ ClawHub[2]
|
外部
|
社区驱动，支持版本管理与发布
|
CLI: clawhub search
|
⚡ 快速
|
社区级
|
⚠️ 可选
|
|
⚪ SkillsMP[3]
|
外部
|
最大数据库，AI 语义搜索，适合细分/研究场景
|
REST API
|
🐢 5–15s
|
283K+
|
✅ 需要
|
|
⚪ alphashop
|
内部
|
跨境电商场景社区 Skill 中心，聚焦 1688 选品 / 找商 / 素材处理 / 店铺管理 / 智能营销 / 数据分析等电商工作流
|
平台 UI 分类浏览
|
⚡ 即时
|
社区级
|
⚠️ 可选
|
|
🟡 Aone Skills
|
内部 | 阿里内部 Skill 发布与安装平台，与 Aone Copilot 深度集成，内网安全可控、即装即用 | 平台 UI 搜索 | ⚡ 即时 | 内部 | ✅ 内网 |
2.2 Agent 平台中的 Skill
除了专门的 Skill 平台，各类 Agent 工具也原生支持 Skill 的加载与使用。以下是常见 Agent 平台的 Skill 使用方式：
|
Agent 平台
|
定位
|
Skill 使用方式
|
|---|---|---|
| Aone Copilot |
阿里内部 IDE AI 编程助手，深度集成 Aone DevOps 全链路
|
将 Skill 目录放入 ~/.aone_copilot/skills/，或从 Aone Skills 市场一键安装，Agent 自动识别加载
|
| AccioWork |
阿里内部通用办公 Agent 平台，支持多场景任务自动化
|
内置Skill直接安装，自定义Skill需要安装包上传安装
|
| QCoder |
轻量级 AI 编码助手，专注代码生成与补全
|
将 Skill 文件夹放入项目级 .skills/ 目录，随项目仓库一起管理
|
| 悟空 |
阿里内部多模态 Agent 平台，支持浏览器操作与视觉理解
|
通过平台 UI 上传 Skill 文件，或在系统提示词中加载 Skill 指令
|
2.3 快速安装 Skill（以 Aone Copilot 为例）
方式一：从 Skill Market 一键安装
-
访问 Aone Skill Market
-
搜索你需要的 Skill，点击「安装」
-
Skill 自动下载到本地 ~/.aone_copilot/skills/目录，立即生效
方式二：下载 zip 手动安装
从 Aone Skills 市场或其他平台下载 Skill 的 zip 包后，解压到对应平台的 Skill 目录：
# Aone Copilot
unzip my-skill.zip -d ~/.aone_copilot/skills/
# QCoder（项目级）
unzip my-skill.zip -d .skills/
# 其他平台参考各平台文档，将解压后的目录放入对应 Skill 目录即可
方式三：使用 aone-kit CLI 安装（推荐）
aone-kit 是阿里内部的 Skill 管理命令行工具，支持从 Aone Skills 市场一键搜索、安装和管理 Skill。
第 1 步：安装 aone-kit
前提：需要 Node.js 18 或以上版本
npm install -g @ali/aone-kit --registry=https://registry.anpm.alibaba-inc.com
第 2 步：安装 Skill
在项目目录下执行以下命令，Skill 默认安装到项目下的 .agents/skills/{name}/ 目录：
aone-kit skill install <skill-name>
常用参数：
|
参数
|
说明
|
示例
|
|---|---|---|
--location <path> |
指定安装目录
|
--location ~/.aone_copilot/skills |
--global |
全局安装到 ~/.agents/skills/
|
aone-kit skill install <name> --global |
第 3 步：查看已安装 Skill
aone-kit skill list
方式三：直接创建
在 ~/.aone_copilot/skills/ 下新建一个文件夹，创建 SKILL.md 文件，写入 Skill 内容即可。详见第三章。
2.4 验证安装成功
安装完成后，直接在 Aone Copilot 查看Skill模块或者在输入中用"/"唤起。
三、五分钟创建你的第一个 Skill（可以不看）
别紧张，跟着下面的步骤走，5 分钟就能搞定你的第一个 Skill 🎉
3.1 准备工作
创建 Skill 推荐使用 skill-creator（一个专门用来创建 Skill 的 Skill 🤯）。当然，你也完全可以手动创建。
🎯 使用 skill-creator 的好处
它会引导你完成意图确认、草稿编写、测试用例设计和迭代优化的完整流程，就像有一位经验丰富的 Skill 工程师在旁边手把手教你。只需对 Agent 说：
"帮我创建一个 Skill，用来 xxx"，skill-creator 就会自动接管。
3.2 Skill 的目录结构
一个 Skill 本质上就是一个文件夹，最简单的情况下只需要一个文件：
my-awesome-skill/
├── SKILL.md ← 唯一必需的文件！
└── (可选) 附加资源
├── scripts/ ← 可执行脚本（Python、Node.js、Shell 等）
├── references/ ← 参考文档（按需加载到上下文）
└── assets/ ← 静态资源（模板、图标、字体等）
3.3 编写 SKILL.md
这是 Skill 的灵魂文件。它由两部分组成：YAML 头部和 Markdown 正文。
YAML 头部（frontmatter）
---
# 必需字段
name: dingtalk-webhook-skill
description: 通过钉钉自定义机器人 Webhook 发送群消息。当用户提到钉钉、机器人、webhook、群消息、通知、dingtalk、发消息时触发。
# 可选字段（按需添加）
license: MIT
compatibility:
- claude-3.5+
- aone-copilot
allowed-tools: Read Bash WebFetch
metadata:
author: zefei.szf
version: 1.2.0
category: communication
tags: [dingtalk, webhook, notification]
---
|
字段
|
是否必需
|
说明
|
|---|---|---|
name |
必需 |
Skill 的唯一标识符。最长 64 字符，仅允许小写字母/数字/连字符，如 dingtalk-webhook-skill
|
description |
必需 |
Skill 的触发描述。这是 Agent 判断是否使用该 Skill 的核心依据，最长 1024 字符，务必写清「做什么」和「什么时候用」
|
license |
可选
|
许可证名称或对 LICENSE 文件的引用，如 MIT、Apache-2.0
|
compatibility |
可选
|
适配的 Agent / 平台 / 模型范围，如 claude-3.5+、aone-copilot
|
allowed-tools |
可选
|
预授权工具白名单，空格分隔，如 Read Edit Bash
|
metadata |
可选
|
任意 KV 元数据，常用子字段： author（作者）、version（语义化版本，如 1.0.0）、category（分类）、tags（标签数组）
|
📖 字段规范来源：以上字段遵循 Anthropic Agent Skills[4] v0.1 开源规范（业界事实标准），同时兼容 skills.sh / ClawHub / Aone Skills 等主流平台。其中
name和description是所有平台都强制要求的核心字段，其余按需添加。
⚠️ description 是触发的关键
Agent 目前倾向于「少触发」而非「多触发」。因此，description 要写得稍微「积极」一些，多列举可能的触发关键词和场景。例如：
发送钉钉消息的技能通过钉钉自定义机器人 Webhook 发送群消息。当用户提到钉钉、机器人、webhook、群消息、通知、dingtalk、发消息时触发。
Markdown 正文
正文就是你给 Agent 的「操作手册」，通常包含以下部分：
3.4 Skill规范与最佳实践
创作思维
在动笔写 SKILL.md 之前，先按下面的四步思考，能让你的 Skill 结构更清晰、触发更精准、行为更可控：
💡 顺序很重要：很多人一上来就写第 3 步流程，结果触发不准（缺第 1 步）或者交付不稳（缺第 2 步）。务必从「触发时机」开始倒推。
写作原则
-
📝 用祈使句 — 直接告诉 Agent 该做什么，而不是描述性地说明
-
✅
从用户输入中提取 webhook_url 参数 -
❌
Agent 应该从用户输入中提取参数 -
🎯 解释「为什么」 — 与其堆砌 MUST / SHOULD，不如解释原因，让 Agent 理解意图后自主决策
-
✅
使用 --headed 模式打开浏览器，因为会议室平台会检测 headless 环境并拒绝访问 -
📏 控制篇幅 — SKILL.md 正文建议控制在 500 行以内。超出时，将详细内容拆分到
references/目录，在正文中用链接引用 -
🌍 保持通用性 — Skill 应该是通用的，不要过度绑定到特定的示例。用理论指导代替硬编码的特例
description 编写技巧
description 是 Skill 被触发的唯一入口，它的质量直接决定了 Skill 的可用性。
|
|
写法
|
问题
|
|---|---|---|
|
❌
|
帮助用户处理工单 |
太笼统，Agent 不知道什么时候该触发
|
|
✅
|
工单批量预处理技能。当用户提到"处理所有工单"、"排查所有工单"、"批量处理工单"、"我的工单有多少"、"帮我看看工单"时，立即触发此技能。 |
关键词丰富，触发场景明确
|
资源组织模式
当 Skill 需要支持多个变体（如不同框架、不同平台）时，推荐按变体组织 references：
cloud-deploy/
├── SKILL.md ← 通用工作流 + 变体选择逻辑
└── references/
├── aliyun.md ← 阿里云部署指南
├── aws.md ← AWS 部署指南
└── azure.md ← Azure 部署指南
Agent 会根据用户的实际需求，只读取相关的 reference 文件，避免无关信息占用上下文。
脚本编写建议
- 零依赖优先：脚本尽量使用语言标准库，避免需要额外安装依赖
- 多语言 fallback：提供 Python → Node.js → Shell 的降级方案，适配不同环境
- 结构化输出：脚本输出 JSON 到 stdout，方便 Agent 解析结果
- 明确退出码：成功返回 0，失败返回非 0，让 Agent 能判断执行结果
💡 脚本的妙用
scripts/目录下的脚本可以不加载到上下文就直接执行。这意味着你可以把复杂的、确定性的操作（如签名计算、数据格式转换）封装成脚本，Agent 直接调用即可，既省上下文又保证准确性。
3.5 一个完整的Skill示例
让我们来看一个真实的 Skill 示例 —— 一个用于发送钉钉群消息的 Skill：
---
name: dingtalk-notifier
version: 1.0.0
description: 通过钉钉机器人发送群消息通知。当用户提到"发钉钉消息"、
"钉钉通知"、"群消息"、"webhook"时触发。
---
# 钉钉群消息通知
通过钉钉自定义机器人 Webhook 发送群消息。
## 快速开始
用户输入示例：
> 帮我发一条钉钉消息到部署群，内容是：v2.1.0 已发布上线
## 参数列表
| 参数 | 必需 | 默认值 | 说明 |
|------|------|--------|------|
| webhook_url | 是 | - | 机器人的 Webhook 地址 |
| message | 是 | - | 消息正文 |
| msg_type | 否 | markdown | 消息类型 |
## 工作流
### Step 1：解析参数
从用户输入中提取 webhook_url、message 等参数。
缺少必要参数时，友好地向用户询问。
### Step 2：发送消息
执行 scripts/send.py 发送消息：
python3 scripts/send.py --url URL --msg "消息内容"
### Step 3：确认结果
检查返回的 errcode，向用户报告发送结果。
## 错误处理
| 错误 | 处理方式 |
|------|---------|
| token 无效 | 提示用户检查 Webhook 地址 |
| 签名错误 | 提示用户检查加签密钥 |
🎉 恭喜！ 如果你跟到了这里，你已经掌握了创建 Skill 的核心知识。接下来我们来看看如何让你的 Skill 写得更好。
四、十分钟学会管理我的 Skill（可以不看）
一个 Skill 从诞生到被广泛使用，需要经历完整的生命周期：发布、更新、安装。
4.1 管理流程总览
✏️ 编写 → 🧪 测试 → 📤 发布 → 📥 安装 → 🔄 更新 → 📊 反馈迭代4.2 发布到 Aone 开放平台
为什么选择 Aone 平台发布 Skill
Aone 平台的 Skill 发布分为 2 种方式：git 仓库发布、zip 发布。
推荐使用 git 仓库发布，方便做后续的版本管理。Aone 创建 Skill 时会自动生成对应的 git 仓库，你只需将你本地待发布的 Skill 代码 push 到该仓库。
💡 特别注意！！！
Aone Skill 的 git 仓库默认的主分支（发布分支）是
main分支而不是master。
git 仓库上传后，回到 Aone 的 Skill 页面，点击发布，审核通过后即发布成功，在你项目目录下自动生成 package.json 文件做版本控制。
4.3 更新 Skill
重复上述发布流程即可。
五、阶段性总结（推荐看）
一个正常的教程应该到这就结束，我们仿佛已经学完了完整的 Skill 发布、管理流程，但我们明显不正常，一切才刚刚开始...
坦诚地说，Skill 生态还在早期阶段，你在后续的迭代过程中可能会遇到一系列的疑惑和痛点。
😤 痛点一：跨平台、跨模型一致性
不同平台对 Skill 的解析行为有差异。只要严格按 name + description + 正文的标准结构写，至少 80% 的内容天然可移植，问题出在那 20% 的"平台增量语法"。
三种常见的"污染"
|
污染类型
|
例子
|
干扰
|
|---|---|---|
| 平台语法污染 |
Accio Work 的 @团队成员、Aone Copilot 的 /cmd、Claude Code 的 !bash
|
不识别的平台当成普通文本，或被 LLM 误解（如 @ 当成邮件抄送）
|
| 工具命名污染 |
写死 Bash、WebFetch、Read
|
不同平台工具名不同（Claude= Bash、Codex=Shell、Cursor=Terminal），写死会导致工具找不到
|
| 路径环境污染 |
硬编码 ~/.claude/skills/、process.env.ACCIO_*
|
仅在特定平台生效
|
badcase：
应对：三纯净 + 注释隔离 + 三检测
写作期：「三纯净」原则
隔离期：用 HTML 注释隔离平台增量
<!-- platform: accio-work -->
当任务需要团队协作时，使用 `@团队成员` 触发分配。
<!-- /platform -->
<!-- platform: aone-copilot -->
当任务需要工单流转时，使用 `/ticket assign` 命令。
<!-- /platform -->
<!-- platform: default -->
当任务需要分配时，输出"建议指派给：<候选人>"，由用户手动操作。
<!-- /platform -->
支持的平台按需渲染，不支持的平台 LLM 通常会忽略注释。
发布期：「三检测」清单
|
检查项
|
通过标准
|
|---|---|
| 跨平台冒烟 |
至少在 2 个目标平台跑一遍（如 Aone Copilot + Accio Work），输出一致
|
| 降级路径 |
每段平台特定能力都有"另一平台没有时怎么办"的兜底
|
| description 中性化 |
description 不出现具体平台名（除非 Skill 本就只服务某一平台）
|
兜底原则：确定性逻辑下沉到 scripts/
把"必须确定执行"的逻辑放进 scripts/*.py——Python 脚本天然跨平台，只要平台支持 shell 就能跑，避免靠 LLM 在不同平台"复述"指令。这是 Anthropic Skill spec 反复强调的 determinism through code 原则。
Anthropic 已于 2025-12 把 SKILL.md 格式开源为 Agent Skills v0.1[5] 标准，目前 16+ 平台已对齐（Claude Code、Cursor、Codex、Gemini CLI、Copilot、Aone Skills、Accio Work 等）。优先遵循该标准，是降低跨平台成本的最佳起点。
😤 痛点二：版本管理和更新分发
Skill 生态目前没有 npm/pip 那样的成熟包管理，发布与分发链路上有两个突出问题。
问题一：发布严肃性不足
写一个 SKILL.md push 一下就发版了，没有 CR、灰度、SPE 评审、自动化测试。在阿里内部应用发布场景这些都是默认配置，但 Skill 长期处于"个人项目"状态——一个错别字、一个被污染的指令，可能直接打到全公司用户。
|
阶段
|
做法
|
业内参考
|
|---|---|---|
| 仓库治理 |
Skill 仓强制 PR + 至少 1 人 CR；保护 main；CODEOWNERS 锁核心 SKILL.md
|
JFrog: Agent Skills are New AI Packages[6]
|
| 自动化校验 |
CI 跑 schema 校验、关键词扫描、prompt-lint、 scripts/ 单测
|
skill-eval[7]
|
| 评测门禁 | skill-creator
跑回归 eval，通过率不低于上一版才能合入
|
Anthropic skill-creator
|
| 灰度发布 |
平台支持 channel 时优先发 beta，验证后升 stable
|
Claude Code plugin marketplace channels[8]
|
| SPE/安全扫描 |
Skill 仓当代码资产接入扫描：注入风险、敏感信息、越权工具
|
JFrog Xray、Snyk for AI
|
核心观念转变：把 Skill 当"代码包"而不是"文档"。Skill 一旦被加载就拥有类工具的执行能力，理应享受与代码同等的发布严肃度。
问题二：已安装用户无法自动感知更新
Skill 更新后，已装用户不会自动收到推送。同一个 Skill 在生态里长期存在多个"僵尸版本"，bug 修了但用户用的还是旧版。
|
阶段
|
做法
|
业内参考
|
|---|---|---|
| 显式 version |
在 metadata.version 标语义化版本号，每次发布同步更新
|
Anthropic spec
|
| 平台自动更新 |
用支持 manifest + auto-update 的渠道（Aone Skills、Claude Code Plugin Marketplace）；自托管时配 git fetch 定时拉取
|
Claude Code plugin marketplaces[9]
|
| CHANGELOG + 订阅 |
仓内维护 CHANGELOG.md，团队 IM 建"Skill 发版机器人"，tag 触发推送
|
GitHub Releases webhook
|
| 弃用与告警 |
旧版在 description 加 [DEPRECATED] 请升级到 vX.Y，触发时立即可见
|
npm deprecate
|
| 锁版本兜底 |
团队/项目级支持锁版本（pin commit SHA / 语义版本），避免上游强制更新破坏稳定性
|
Claude Code v2.1.14+ commit pin
|
社区正在推进 Skill Package Manifest RFC[10]，目标对齐 npm 的 "manifest + lockfile + registry" 模型，预计 2026 年内更多平台会原生支持。
😤 痛点三：开发和调试的效率低
创建 Skill 很快，但调试与迭代很慢。常见反模式：改一行 SKILL.md → 跟 Agent 说"重新加载" → Agent 没加载到 → 手动重启会话 → 复测一次……一个小修改 5–10 分钟。**真正的瓶颈不在写，在"改完之后让 Agent 看到改完的版本"**。
社区已把这归纳为 Skill local-dev-loop 问题，2025 H2 起出现了一批方案。
|
做法
|
说明
|
业内参考
|
|---|---|---|
| Hot Reload |
用支持热加载的平台（Claude Code 2.1+），改完无需重启
|
Claude Code 2.1 hot-reload[11]
|
| Symlink 软链 | ln -s
把开发中的 Skill 仓链到平台 skill 目录，编辑器改的就是平台读的
|
asm link[12]
|
| Local Dev Loop 模板 |
一键搭"hot reload + 自动测试 + 文件 watcher"的开发环境
|
exa-local-dev-loop[13]
|
| Eval-Driven Dev | skill-creator
预设回归用例，每次改完跑一遍，通过率不达标自动阻断
|
Anthropic skill-creator
|
| 双窗口对照 |
一个会话开 dev 版、一个开 prod 版，并排对比同一指令的输出，快速定位是 Skill 还是 LLM 问题
|
社区调试技巧
|
跑通这套环，单次迭代从 5–10 分钟压到 30 秒以内——Reddit 上 Claude Code 2.1 用户报告的 "24x faster iteration" 就是这么来的。
进阶：让 Skill 自我进化
前面 5 项解决的是"人快速迭代 Skill"。2026 年业内出现了更激进的方向——让 Skill 自己迭代自己：每次执行记录成功/失败信号，用反思机制提炼"经验补丁"，再回写到 SKILL.md。
4 步反馈闭环
执行 Skill → Binary Eval 自动打分 → 失败时 Reflection Agent 提炼修复 patch → 通过 eval 复测 → 自动 git commit
业内代表性方案
|
方案
|
机制
|
出处
|
|---|---|---|
| Claude Skills 2.0 |
每次执行后 A/B 测试 + eval 自动调优 SKILL.md
|
Claude Skills 2.0[14]
|
| Binary Evals + Self-Improving Loop |
二元（pass/fail）评估器替代主观打分，failure case 自动触发改 Skill
|
MindStudio (2026-03)[15]
|
| Singularity Claude |
开源 self-evolving skill engine，支持 auto / manual 两种评分
|
Shmayro/singularity-claude[16]
|
| Cognee |
把执行 trace 喂给知识图谱，从失败案例归纳新规则反写 SKILL.md
|
Cognee Self-Improving Skills[17]
|
| AGENTS.md 元指令法 |
在 SKILL.md 嵌"调试后请自更新本文件"的元指令，会话结束自动反思修订
|
LinkedIn 案例[18]
|
| 学术：RL + Skill Library |
强化学习训 Agent 自主管理 Skill 库（增/删/改）
|
arXiv 2512.17102 (2026-03)[19]
|
穷人版落地（不需要复杂基建）
1.SKILL.md 末尾加元指令：
## 自我进化机制
每次执行完本 Skill 后：
1. 评估输出是否达成目标（pass / fail）
2. fail 时反思失败原因，在 diary/YYYY-MM-DD.md 追加「失败案例 + 修复建议」
3. 某条修复建议在最近 3 次执行中被反复提及时，提炼为正式规则，提交 PR 修改本 SKILL.md
2.配 scripts/log-execution.py：每次触发自动记录 prompt + 输出 + 用户反馈到 JSONL。
3.用 skill-creator eval 做兜底：自我修改后必须通过既有回归用例才能 commit，避免自我退化。
⚠️ 风险：没有 eval 兜底的自我修改 = 慢性自杀——Agent 可能为通过单个 case 而引入与其他场景冲突的规则，越改越烂。务必配套 binary eval + 版本快照 + 关键节点人工 review。
Anthropic 已在 Claude Code 2.x roadmap[20] 中暗示原生支持 skill auto-evolution，预计 2026 H2 落地。在那之前，"元指令 + binary eval + git 兜底"是最稳过渡方案。
六、其实你只要一个 Skill（必须看）
讲了这么多，到目前为止我们的文章还是限定在原有的人类思维中，即学习工具然后使用工具。然后扪心自问，AI时代技术井喷式发展，你真的能学得过来，也许你学会了上述的所有内容，可是明天可能还没等你去实践，技术已经更新换代。
所以回到我们开头聊的，我们应该把我们的价值放到体验（Experience）和判断（Judgment），无论你是大神还是小白，关于目前的 Skill 技术，你应该需要更好的使用体验，只需做出自己宝贵的判断。因此，以上关于 Skill 的内容，一个 SKill 就可以搞定：skill-dev-aio：一站式Skill开发助手
产品理念（一站式Skill开发闭环）
功能一演示：快速创建Skll
功能二演示：一键发
功能三演示：优跑分
功能四演示：检查询
功能五演示：跨平台迁移
功能六演示：批更新
相关链接：
[1] https://www.skills.sh/