编程 1300人收藏的元Skill创建框架：yao-meta-skill工程化构建可复用技能包

2026-06-21 07:12:20 +0800 CST views 10

1300 人收藏的元 Skill 创建框架：yao-meta-skill 工程化构建可复用技能包

标签: AI / Skill工程 / Agent / 开源 / 提示词 / 工程化 / MCP / 跨平台 / 评估 / 治理
原文: 微信公众号「开源星探」https://mp.weixin.qq.com/s/5kM-fJcTwHiZCPsgC6v_6A
GitHub: https://github.com/yaojingang/yao-meta-skill

从 Prompt 工程到 Skill 工程

AI 开发者社区里有一句越来越多人认同的话：如果你还在用长长的提示词和 AI 对话，那你已经落后了。

过去三年，大模型交互方式经历了三轮演进：

阶段	方式	代表
第一轮	裸提示词时代	层层嵌套的 prompt，"提示词工程师"
第二轮	RAG 与工具调用	Function Call、MCP 协议、插件系统
第三轮	Skill 工程时代	AI 自动加载专业技能包

核心变化：AI 从「每次都需要你手把手教」的工具，进化成「能自动加载专业技能包」的智能体。

但问题来了：怎么才能做出一个高质量、可复用、经得起考验的 Skill？

很多人以为写 Skill 就是把 prompt 存进一个 SKILL.md 文件——那就太低估这件事了。一个真正可以在团队里长期使用的 Skill，需要解决路由识别、质量评估、版本治理、跨平台兼容等一系列工程问题。

这正是 yao-meta-skill 要解决的核心问题。

yao-meta-skill 简介

Build reusable skill packages, not long prompts.
构建可复用的技能包，而不是写长长的提示词。

yao-meta-skill 是开发者 yaojingang 开源的框架，核心理念：Skill 的目标不是生成更多提示词文本，而是产出真正能用的 AI 资产，解决真实的运营问题。

它提供了一套完整的工程化流程，把各种"原始材料"——工作流笔记、重复提示词、会议纪要、便签操作清单——转化为结构化、可评估、可治理、可打包的 Skill 目录。

工程化流程：不是写文件，而是造产品

yao-meta-skill 的 Skill 创建不是"写一个文件"，而是包含多个阶段的工程流程：

原始输入 → 意图对话 → 路由设计 → 基准扫描 → 质量评估 → 打包发布 → 生命周期治理

阶段	产出	说明
原始输入	工作流笔记/提示词/对话记录/文档	任何形式的"原始材料"
意图对话	`reports/intent-dialogue.md`	先聊清楚"解决什么问题、产出什么、不做什么"
路由设计	`SKILL.md` + `agents/interface.yaml`	精简入口文件，让 Agent 准确识别触发时机
基准扫描	`reports/reference-synthesis.md`	参考行业标杆 + 用户偏好风格
路由评估	`evals/trigger_cases.json`	真实 prompt 测试触发准确性
报告生成	`reports/skill-overview.html`	可视化技能概览
打包分发	跨平台兼容成品包	OpenAI / Claude / 通用格式

整个链路留下的每一份证据文件，不是给外人看的文档，而是让你自己能放心地把 Skill 交给团队使用——因为你清楚它是怎么一步步造出来的。

亮点一：从对话式草稿到工程化成品

传统写 Skill 的流程：脑子里想个大概 → 编辑器敲一段 SKILL.md → 复制到项目里。

yao-meta-skill 给你一个完整闭环，每一步都有证据文件留存，确保可追溯、可审查。

亮点二：三种运行模式——轻量但不简陋

Skill 工程最容易犯的病是"过度设计"。yao-meta-skill 的哲学：用最轻的流程，但要让 Skill 可靠。

模式	场景	治理程度
Scaffold（脚手架）	个人探索/快速原型	最必要结构
Production（生产）	团队复用	质量门槛 + 评估流程
Library（库）	共享基础设施/元技能	完整治理和文档

核心原则：流程的重量应该与风险成正比。

亮点三：质量评估是默认行为

写好一个 SKILL.md 放在那儿，没法跑单元测试？yao-meta-skill 给出多层次评估体系：

评估工具	脚本	说明
触发词评估	`scripts/trigger_eval.py`	train/dev/holdout 三层测试集验证路由准确率
描述优化套件	`scripts/run_description_optimization_suite.py`	多版本 description 盲评对比
法官式盲评	`scripts/judge_blind_eval.py`	独立评分者模型二次验证
资源边界检查	`scripts/resource_boundary_check.py`	确保 Skill 不越权操作
治理检查	`scripts/governance_check.py`	验证元数据完整性
路由混淆检测	`reports/route_scorecard.md`	防止相似 Skill 互相干扰

亮点四：可操作的 Skill 工程方法论

yao-meta-skill 不只是代码和脚本，更沉淀了一套方法论，分布在 docs/、references/、failures/（反模式库）中：

意图对话手册：2-3 个高杠杆问题，把模糊需求变清晰定义
参考扫描策略：外部标杆 → 用户偏好 → 本地适配校准
原型选择指南：判断需求是否该变成 Skill，选最轻合适模式
门槛选择逻辑：哪些检查必要，哪些多余
迭代哲学：每次迭代只聚焦前三优先方向
非 Skill 决策树：识别"这不是 Skill，就是一次性任务"，避免过度工程化

亮点五：中立元数据 + 跨平台打包

平台碎片化是 Skill 生态的现实痛点：

Claude Code 用 ~/.claude/skills
Cursor 有自己的目录
OpenAI 实现逻辑又不一样

yao-meta-skill 通过 scripts/cross_packager.py 解决：

能力	说明
一源多包	单一源代码 → OpenAI / Claude / 通用三种格式
中立元数据	保留激活、执行、信任、降级元数据
可移植性评分	100/100

团队写的 Skill 不会被锁死在某一款工具上。

快速上手

方式一：克隆到 Skill 目录

直接克隆项目，解压放到 Agent 的 skill 目录下即可使用。

方式二：npx 一键安装

npx skills add https://github.com/yaojingang/yao-meta-skill --skill yao-meta-skill

可以一键链接到本地的所有 Agent 下。

典型目录结构

一个完整的、治理就绪的 Skill 目录：

my-skill/
├── SKILL.md                    # 入口路由文件
├── agents/
│   └── interface.yaml          # Agent 接口声明
├── references/                 # 参考材料（方法、示例等）
├── scripts/                    # 确定性脚本
├── evals/                      # 评估用例
│   ├── trigger_cases.json
│   └── blind_holdout/
├── reports/                    # 评估报告与迭代证据
│   ├── intent-dialogue.md
│   ├── skill-overview.html
│   ├── iteration-ledger.md
│   └── promotion-decisions.md
├── manifest.json               # 治理元数据（生产级别才需要）
└── VERSION                     # 版本号

注意：不是每个目录都必须有。yao-meta-skill 的设计理念是**"按需添加"**——个人使用的轻量 Skill，可能只有 SKILL.md 就够了。

总结

我们正在从 Prompt 工程时代进入 Skill 工程时代。这个转变带来的不仅是技术工具的变化，更是一种思维方式的升级。

yao-meta-skill 的核心价值：

🏗️ 工程化流程——从意图对话到打包分发，每一步都有证据留存
⚖️ 按需治理——三种模式适配不同风险等级
✅ 质量默认——多层次评估体系，不靠感觉靠数据
📦 跨平台——一源多包，可移植性 100/100
📖 方法论沉淀——不只是工具，更是可操作的知识

如果你认同 Skill 工程方向，又刚好在找一套真正工程化的 Skill 构建工具，yao-meta-skill 值得花一个下午认真研究。