2026年【实战】Skill也能自己进化了：skill-evolver如何用「训模型」的思路实现AI技能包全自动优化

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

本文深度解析 skill-evolver 开源项目的核心架构——8阶段进化循环、三层评测流水线、5维AND门控、分层变异策略，以及用自举测试从88.9%跑到100%的完整实验记录。适合正在写Skill/Plugin的AI开发者。

写Skill不难，调Skill要命。

说实话吧，做过AI Agent开发的应该都有体会——写一个能跑的Skill可能半天搞定，但把它调到在各种边界case下都稳定输出、触发率够高、不回归，那可能得一两周。改完prompt发现A好了B坏了，修了B发现C又冒出来了。

这个循环我自己经历过太多次了。

最近在GitHub上看到一个叫 skill-evolver 的项目，作者 FishSerrie，MIT协议开源。核心定位一句话：用训模型的方式训Skill，全自动、零人工。

看完架构设计和自举测试数据后，我觉的这个项目值得认真聊一聊。

1.1 概念映射

skill-evolver 的设计哲学是把机器学习的核心概念完整映射到Skill优化场景：

训模型训 Skill（skill-evolver） Training data Ground Truth (GT) — evals.json 里的 test cases + assertions Loss function 8种 assertion 类型 + 5维 AND 门控 梯度下降/迭代 8阶段 loop — search → modify → evaluate → gate → keep/discard → repeat 选 Checkpoint best_versions/ — 每次 keep 的版本快照 Overfitting 检测 Holdout split — 迭代期间绝不暴露给 proposer Regression test Regression split — 防止改好了 A 坏了 B Learning rate 分层 mutation — description → body → scripts Early stopping stuck detection + convergence

这不是那种“AI优化AI”的概念demo。每个环节都有落地实现,跑得通。

1.2 一条命令启动进化

# 核心命令——跑到收敛或达到最大迭代次数 python3 scripts/evolve_loop.py ./my-skill/ –gt ./evals.json –run –max-iterations 20

或者通过 slash command：

/skill-evolver evolve ./my-skill/

你给它一个skill目录和一份GT数据，它自己跑8阶段循环。全程零人工。

2.1 完整流程

Phase 0: 准备 → 创建 workspace + 生成评测计划 + 建立基线 Phase 1: 回顾 → 读取记忆（results.tsv + experiments.jsonl + git log） Phase 2: 构思 → 分析失败模式，决定改什么 Phase 3: 修改 → 对 skill 做一个原子改动 Phase 4: 提交 → Git commit Phase 5: 验证 → 三层测评流水线（L1/L2/L3） Phase 6: 门控 → 多维度门控决策：保留/丢弃/回滚 Phase 7: 记录 → 写入实验记忆 Phase 8: 循环 → 继续、升层、或停止

2.2 关键设计点

原子改动原则：Phase 3 每轮只做一个改动，不搞“一次大改”。这跟模型训练里小步迭代的思路一样，出了问题容易定位。

实验记忆：Phase 1 会读取之前所有迭代的结果（results.tsv + experiments.jsonl + git history），避免重复走弯路。这一点很多手工优化都做不到——你还记得上上次改了什么导致回归的吗？

Stuck Detection：连续 N 轮不 keep 就自动升层（从改 description 升级到改 SKILL.md 正文），或者直接 early stopping。不会无限空转。

3.1 架构设计

层级名称检查内容速度触发条件 L1 Quick Gate YAML 语法、SKILL.md 有正文、目录结构、GT 文件结构秒级每轮必跑 L2 Dev Eval dev split 所有 case 逐条断言打分（6种程序 + 2种LLM语义） 分钟级 每轮跑 L3 Strict Eval holdout split + regression split + 盲评 A/B ~10分钟 条件触发

3.2 Fail-fast 原则

这是整个评测体系里我觉得最聪明的设计：

# 伪代码逻辑 if not L1_pass:

git_revert() return "DISCARD" # L2 根本不跑，烂改动成本压到最低

if L2_pass_rate < threshold:

git_revert() return "DISCARD"

if should_run_L3(): # 每 N 轮 / dev 超阈值 / 升层前

run_L3()

L1 挂了直接丢掉，L2 根本不跑。这把“烂改动”的计算成本压到了最低。

3.3 8种断言类型

{ “assertions”: [

{"type": "contains", "value": "预期文本"}, {"type": "not_contains", "value": "不该出现的"}, {"type": "regex", "value": "\d{4}-\d{2}-\d{2}"}, {"type": "path_hit", "value": "references/api.md"}, {"type": "fact_coverage", "value": "必须覆盖的事实"}, {"type": "script_check", "value": "scripts/check.py"}, {"type": "json_schema", "value": {"type": "object"}}, {"type": "file_exists", "value": "output/result.md"}

] }

前6种由 Python 程序评分（确定性），后2种中 path_hit 和 fact_coverage 由 LLM 二元分类（BinaryLLMJudge，只答 YES/NO），程序汇总。这个“LLM 二元分类 + 程序算分”的评测哲学挺巧妙的——让LLM做它擅长的语义判断，但不让它做最终评分决策。

4.1 门控逻辑

# evolve_plan.md 中定义 gates: min_delta: 0.02 # 最小提升幅度 max_regression: 0.05 # 最大回归容忍度 max_tokens: 50000 # 单次评测 token 预算 holdout_floor: 0.60 # holdout 最低分数

五个维度：

质量：dev pass_rate 必须提升 ≥ min_delta
触发 F1：description 改动后触发准确率不能下降
成本：单次评测 token 不能超预算
时延：响应时间不能恶化
回归：regression split 通过率不能低于基线

AND 逻辑：五个维度全部通过才 KEEP，任一不过就 git revert HEAD –no-edit。

4.2 为什么是 AND 不是加权平均

其实吧这个设计选择很有意思。加权平均的问题是——你质量提升了10%但成本翻了3倍，加权一算可能还是“净正”的。但在工程实践中这种 trade-off 往往不可接受。AND 门控更贴合“上线检查”的逻辑：任一红灯都不放行。

层级目标成本示例 Layer 1 description 字段低提升触发准确率（F1） Layer 2 SKILL.md 正文中改进指令、示例、约束 Layer 3 scripts/ 和 references/ 高新增脚本、优化协议

规则：当前层改不动了（连续 N 轮 stuck）才升级到下一层。单次迭代不允许跨层修改。

这跟调参的经验一样——先调学习率（低成本），调不动了再换 optimizer（中成本），最后才动网络结构（高成本）。别一上来就掀桌子。

这部分是最硬气的自证。作者用 skill-evolver 迭代 skill-evolver 自身。

6.1 完整迭代记录

迭代改动结果 Delta 决策基线 — 88.9%（ ³²⁄ ₃₆ 断言） — — Iter 1 添加 skill-creator 安装段落 94.4%（ ³⁴⁄ ₃₆） +5.6% ✅ KEEP Iter 2 添加 eval viewer 步骤 97.2%（ ³⁵⁄ ₃₆） +2.8% ❌ DISCARD（< min_delta 5%） Iter 3 bundled 文档对齐 100%（ ³⁶⁄ ₃₆） +5.6% ✅ KEEP

关键证据：

L1 gate 调用了 creator/scripts/quick_validate.py（真用了 Creator）
评测走 LocalEvaluator._evaluate_assertion()（真用了框架）
Iter 2 真被 discard 并执行了 git revert（真有试错）
每个 case 写了 trace 文件，Phase 2 cite trace 证据后才提改动（真有诊断）

3轮迭代，2次keep，1次discard。从88.9%到100%。零项目git污染（workspace git隔离）。

7.1 三大支柱

支柱来源提供的能力评测引擎 skill-creator（Anthropic）评测、打分、对比协议自主迭代外循环 AutoResearch（Karpathy） modify → verify → keep/discard → repeat 失败诊断 Meta-Harness（Stanford）执行轨迹结构化暴露给 proposer

7.2 与学术界的关系

Sentient 和弗吉尼亚理工发布的 EvoSkill 框架走的是另一条路——从失败中自动发现能力缺口并生成新 Skill。OfficeQA 准确率提升 7.3%，SealQA 提升 12.1%。

两者的区别：

EvoSkill：偏“从零发现和创建 Skill”
skill-evolver：偏“优化已有 Skill 到极致”

方向一致，侧重点不同。

7.3 跨平台支持

平台状态 Claude Code ✅ 完整支持（经过自举验证） OpenCode ✅ 已生成（适配 question 工具） Codex ✅ 已生成（适配 codex exec）

⚠️ OpenCode 和 Codex 版本已生成但未经实际测试。

8.1 前置条件

要求必需？用途 Python 3.10+ 是运行评测脚本 Git 是 workspace 版本控制 skill-creator 是（硬依赖） 提供 quick_validate、grader 协议 Claude Code CLI 语义断言需要 LLM 二元分类

8.2 安装步骤

# 方式 A：作为 Plugin 安装（推荐） cd ~/.claude/plugins git clone https://github.com/FishSerrie/skill-evolver.git

# 方式 B：全局 skill 安装 mkdir -p ~/.claude/skills/skill-evolver cp -R plugin/skills/skill-evolver/* ~/.claude/skills/skill-evolver/

8.3 准备 GT 数据

[ {

"id": 1, "prompt": "用户输入", "assertions": [ {"type": "contains", "value": "预期输出", "description": "必须包含X"} ], "split": "dev"

} ]

8.4 启动进化

/skill-evolver evolve ./my-skill/

就这么简单。跑到收敛它会自己停。

说几个我看文档过程中注意到的点：

坑点描述建议 GT 质量 GT 定义的不好，进化方向就是歪的先花时间写好 GT，垃圾进垃圾出 skill-creator 硬依赖找不到 Creator 就启动报错安装 Evolver 前先装好 Creator holdout 数据量 holdout split 太少会导致 L3 不稳定建议 dev:holdout:regression ≈ 6:2:2 跨平台版本 OpenCode/Codex 版本未经实测生产环境建议先用 Claude Code 版本

10.1 核心价值

skill-evolver 解决的是 Skill 开发中最痛的环节——调优。人类负责定义“什么叫好”（Ground Truth），机器负责“怎么变好”（进化循环）。

10.2 推荐场景

场景推荐度原因已有 Skill 的持续优化 ⭐⭐⭐⭐⭐ 核心场景，架构完整新 Skill 的 GT 驱动开发 ⭐⭐⭐⭐ 先写 GT，再让 Evolver 补完 Skill A/B 版本对比 ⭐⭐⭐⭐ benchmark 模式直接可用大规模 Skill 批量优化 ⭐⭐⭐ 需要脚本封装循环逻辑

10.3 一句话评价

Skill 的持续集成时代来了。CI/CD 不只是给代码用的。

skill-evolver GitHub
skill-creator (Anthropic)
AutoResearch (Karpathy)
EvoSkill 论文 (arXiv:2603.02766)
Meta-Harness (Stanford)

📢 你在写 Skill 的过程中遇到过哪些调优的坑？有没有用过自动化优化工具？欢迎评论区聊聊。

如果觉得有帮助，欢迎 点赞 👍 收藏 ⭐ 关注，持续输出 AI 实战干货！