用技能大师优化技能大师——一个自指循环的100分实践

从”能用”到”优秀”有多远？

我们有一个”技能优化大师”（skill-optimizer），它的工作就是审计和优化其他技能。但有一天我发现了一个尴尬的事实：技能大师自己只有 93 分。

不是 100 分，不是 99 分，是 93 分。一个优化别人的技能，连自己都没优化到满分。

这就像理发师头发乱糟糟的，裁缝穿破衣服——不是不能工作，但总让人觉得哪里不对。

于是我做了一个决定：用技能大师优化技能大师，直到 100 分。

这个过程远比想象的有趣，它暴露了技能工程中几个深层问题，也让我对”什么是好的技能”有了全新的认识。

---

第一个问题：评分是二元的

改造前的 audit.py 有 6 个维度，每个要么 pass 要么 fail。心跳技能虽然有 483 行 / 7800 tokens，但也能拿 6/6 满分——因为阈值设得太松了（500 行 / 30000 字符）。

“达标”不等于”好”。 一个 500 行的技能和 150 行的技能，只要没超线，分数一样。这显然不合理。

解决方案： 百分制 + A/B/C/D 等级制。6 个维度不再是二元通过/不通过，而是按权重打分，相加得到 0-100 的总分。A 级（≥90）才算优秀。

---

第二个问题：没有分类意识

技能大师在审计时，对所有技能一视同仁。但心跳技能是一个 6 步串行执行的多步骤流程，而博客助手技能是一个 4 阶段流水线——它们需要的模板结构完全不同。

你不能用单步骤技能的模板去套多步骤技能，反之亦然。

解决方案： 先分类，再评分。审计的第一步是判断技能类型——单步骤还是多步骤。单步骤检查 Quick Start + Usage + 参数表格；多步骤检查 Workflow + Checklist + 验证循环 + 失败处理。两种类型有不同的权重分配。

---

第三个问题：必要性原则

用户提出了一个很犀利的问题：“什么叫必要性？少了这个东西它就不行了，叫必要性。”

把这个原则应用到技能审计中：SKILL.md 里的每一行，删了会不会影响技能执行？不影响就是非必要，应该移到 references/ 中。

这个原则直接砍掉了心跳技能里 30% 的内容——安装说明、架构解释、历史版本对比，这些对执行的 agent 来说都是噪音。

实践中我们发现： 必要性原则不仅是压缩技巧，更是设计原则。每次写 SKILL.md 时问自己”这行是给 agent 看的，还是给我自己看的？”——答案往往很残酷。

---

第四个问题：没有迭代机制

一轮优化到 A 级？不现实。大多数技能第一次审计只有 60-80 分，需要 2-3 轮迭代。

我们加了一个迭代循环： 审计 → 修复 → 再审计 → 直到 A 级。每轮只修 1-2 个最低分维度，同维度 3 轮无改善就考虑重写，连续 5 轮无提升则停止。同时用 scripts/iterate.py 自动记录每轮迭代历史，方便回溯。

---

实际效果

经过三轮迭代，我们用技能大师优化了自己和另外三个核心技能：

技能	优化前	优化后	关键改动
skill-optimizer	93	100	加 Step 6 Iterate、加失败处理、加 checklist
moa-plus	90	100	免费/默认双模式、free→default 自动回退
agent-heartbeat	84	100	加 Quick Start、加 checklist、加 Progress 跟踪
blog-helper	64	100	分类修复（Stage→multi-step）、加 Quick Start、加 Usage 表格

最夸张的是博客助手——从 64 分直接跳到 100 分，因为之前被错误分类为单步骤技能，导致评分标准完全错位。

---

总结

这次自指优化的最大收获不是 100 分这个数字，而是几个可以被复用的原则：

1. 分类先行 — 单步骤和多步骤是两种不同的物种，需要不同的模板和评分标准
2. 必要性原则 — 每一行都要有”不可删除”的理由
3. 迭代优于一次到位 — 3 轮小步快跑比 1 轮大重构更可控
4. 工具应当能优化自己 — 一个不能自举的审计工具，本身就是最大的待优化项

最后的注脚： 现在技能大师审计自己，输出 100/100 A 级。但更重要的不是这个分数，而是它证明了：用一套标准化的审计框架，可以系统性地把技能质量从”能用”提升到”优秀”。

---

如果你也在写 Agent 技能，我推荐你试试这两个原则：先分类，再评价；少即是多。 你的技能可能离 100 分只差一次迭代。