重新定义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 Copilotunzip 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-skilldescription: 通过钉钉自定义机器人 Webhook 发送群消息。当用户提到钉钉、机器人、webhook、群消息、通知、dingtalk、发消息时触发。# 可选字段（按需添加）license: MITcompatibility:  - claude-3.5+  - aone-copilotallowed-tools: Read Bash WebFetchmetadata:  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 的「操作手册」，通常包含以下部分：

1.快速开始 / 使用示例 — 给出 1-2 个典型的用户输入示例，让 Agent 快速理解使用场景

2.参数列表 — 用表格清晰列出每个参数的名称、是否必需、默认值和说明

3.工作流 / 执行步骤— Skill 的核心，用分步骤的方式描述 Agent 应该如何执行任务

4.错误处理 — 列出常见的错误场景和对应的处理方式

5.附加资源引用 — 如果有 scripts/ 或 references/，明确指出何时、如何使用

3.4 Skill规范与最佳实践

创作思维

在动笔写 SKILL.md 之前，先按下面的四步思考，能让你的 Skill 结构更清晰、触发更精准、行为更可控：

1.确定触发时机：先想清楚”用户在什么场景会用到”，把关键词、口令、上下文条件梳理出来 —— 这直接决定description 怎么写。

2.确定输入与输出：明确 Skill 需要哪些参数、最终交付什么产物，避免后续流程发散。

3.确定大致流程：把核心步骤、调用的工具、依赖的外部资源用 3-7 步串起来，先骨架后细节。

4.补充细节与规则：补全边界情况、错误处理、约束条件，并准备好示例或模板，让 Agent 在执行时有据可依。

💡 顺序很重要：很多人一上来就写第 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-notifierversion: 1.0.0description: 通过钉钉机器人发送群消息通知。当用户提到"发钉钉消息"、  "钉钉通知"、"群消息"、"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

🔗 打通 Code 平台、关联 Git 仓库，开发体验友好：创建 Skill 时自动生成对应的 Git 仓库，本地 push 即可触发发布，告别”压 zip → 上传 → 替换”的繁琐流程，写代码与发版无缝衔接。

🏷️ 自动版本管理，无需手动维护版本号：平台基于 Git commit 自动生成版本信息，不用自己在 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：

应对：三纯净 + 注释隔离 + 三检测

写作期：「三纯净」原则

1.正文纯文本：不写任何平台特定的 @、/、! 触发符。必须提及就用引号当例子讲，而不是当指令用。

2.工具用能力描述：写「调用 shell 命令执行 xxx」而非「调用 Bash 工具」，让平台自己映射。

3.路径不写死：用相对路径或 ~/<workspace>/ 占位。

隔离期：用 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开发助手