本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下全是我自己手搓，没有ai味（我用最真实、最不绕、最直接的方式跟你讲 hhhhh），放心品尝
很多人以为 Skill 迭代最难的是"怎么改"。
但我越来越强烈地觉得，真正难的其实不是改，而是：
你改完之后，根本不知道它到底有没有真的变好。
补描述、调 prompt、加例子、补边界、改结构。
Skill 看起来越来越完整，文档越来越像样，语气越来越专业。
但问题是：看起来更完整，不等于真的更强。 skill的实际行为未必更稳定，边界未必更清晰，失败处理也未必更好。
所以很多 Skill 维护最别扭的地方，其实不是"不会写"，而是你明明已经改了很多轮，却还是说不清：
上一次改动，到底有没有真正产生作用。
我后来专门跑了 100 个高下载 Skill，发现问题并不是"不能用"
（是的，烧我自己的token）结果最有意思的地方，不是烂 Skill 特别多。恰恰相反，大多数 skill 其实都能用：
- 70 个通过
- 29 个在 caution 区间
- 1 个 fail
- 平均分 73.8
真正的问题不是：大多数 Skill 完全不能用。
而是很多 Skill 停在一个很尴尬的状态：能用，但不容易被继续有效优化。
你一旦想认真往上修，就会发现问题不少，但很难判断到底该先修哪一块。
也就是说，难点不是"没法写"，而是没有诊断，所以不知道怎么有效地继续改。
更关键的是，这种"不对劲"还不是随机的。
我看到的弱点主要集中在几个地方：
- Trigger quality 平均 6.2
- Functional quality 平均 6.6
- 大约 80% 缺少 not_for 边界
- 大约 60% 的 D4 弱项 Skill 缺少像样的 error recovery guidance
- 还有接近 40% 更像"写给人看的说明书"，而不是"写给模型执行的操作说明"
这里翻译成人话就是：
很多 Skill 不是坏在"完全不能用"，而是坏在几个特别重复的地方：不会划边界，不会处理失败，也没有把行为写得足够可执行。
所以我后来做了 SkillCompass
我想解决的，不是"怎么把 Skill 写得更长、更完整"，而是另一件更关键的事：
在你动手优化之前，先看清问题到底在哪；在你改完之后，再验证这次修改有没有真的产生提升。
所以对我来说，SkillCompass 不是一个"给 Skill 打个分"的工具而已。
它更像一个给 Skill 迭代提供方向感的东西：
- 现在最弱的是哪一维
- 下一步该先修哪里
- 这轮修改有没有真的带来提升
- 有没有把别的地方一起改坏
【这里插一句compass 这个名字，指南针🧭，其实也是这个意思。不是替你做决定，而是先帮你定位方向。 】
所以它背后的设计原则也很简单：
- 本地优先：所有数据都留在本机，除非你明确要求，否则不会主动发起网络请求
- 默认只读：评估和报告默认不改文件，improve、merge、rollback 这类写入操作都要明确开启
- 被动追踪，主动决策：Hooks 会收集使用数据，但系统只给建议，不会自动替你执行
- 双通道交互：既支持键盘选择，也支持自然语言查询，两种方式始终都可用
同时我把评估分成了6个维度；把判定标准分成3档
它不是在帮你"多改一点"，而是在帮你把迭代变成一个可验证的流程
与其盲目地"再多写一点"，不如把 Skill 迭代拆成一个更清晰的 workflow。下面拿agile-product-owner作为一个例子展开讲讲：
1）先诊断
不要一上来就改。先看清楚最弱的是哪一维。
很多时候你以为问题在 wording，实际可能卡在 trigger、边界、失败处理，或者执行指令根本不够可操作。
先把最弱项找出来，后面的修改才不是瞎试。
接着它出一个初步的报告，包含维度1-3，后面会有一个完整的全方位维度1-6的测评报告（看下图）：
2）再看单项到底在说什么
我觉得这一步特别重要。
因为很多人一看到分数，会下意识觉得"哦，这项低，那我去多写一点"。
但 SkillCompass 真正有价值的地方，不是只给分，而是会把某个维度为什么高、为什么不满分、它到底在判断什么，说得更清楚。
比如拿 D6 = Uniqueness（独特性 / 不容易被替代） 来说，它看的不是"你这段话写得顺不顺"，而是在看：
- 这个 skill 是不是真的有独立价值
- 有没有明显重复品
- 跟相似 skill 重合度高不高
- 是不是一句普通 prompt 就能替代
- 它是不是很快就会过时
这里个skill的这一维最后给到 8 分，不是说它不好，而是说：它已经有明确领域专属性，也不太容易被普通 prompt 替代，但还没有强到"极其不可替代"的程度。
3）定点修复，而不是整份 Skill 重写
找到弱项之后，不是整份 skill 重写一遍。
而是只修最该修的那一块。所以我们把弱项加强，不好的修正，但不污染上下文
**这里要敲重点！！！**它做了那段分数解释，并且新版分更高的同时也没有把别的地方改坏，因为修改目标清楚，而且不会为了补一个问题，把别的地方一起搅乱。
此时，SkillCompass 已经完成这轮评估/优化结果的写入（提升了 D5），没有出现回归，然后把新的评估记录和最新扫描时间写进本地文件。
4）改完再验证，千万不要靠感觉收工
改完不能靠"看起来更完整了"就结束。要重新验证这次修改到底有没有带来真实提升。
分数有没有上去，解释有没有更扎实，别的维度有没有被改坏，这些都得重新看。
（（（兄弟们，有效的优化才叫"迭代"，不然就是屎上雕花。）））
5）再找下一个瓶颈
一个问题修完，不代表 skill 就完成了。
通常是这个瓶颈被拿掉之后，下一个瓶颈才会浮出来。
所以真正有效的迭代，不是一次性改到完美，而是持续地：
诊断问题 → 定向修复 → 验证提升 → 找到下一个瓶颈
这也是我现在更认同的一种 Skill 迭代方式：不是凭感觉打磨，而是把迭代变成一个更可验证的 workflow。
适合什么人，不适合什么人
适合：
- 任何在维护 agent skills，并且希望质量能够被量化的人
- 想要有明确改进方向的开发者—不是靠猜，而是清楚知道下一步该修哪个维度
- 需要质量门槛的团队—任何会改动 skill 的工具，都可以在改动后自动接受评估
- 安装了很多 skills、想看清哪些真的在用、哪些已经陈旧、哪些存在风险的用户
不适合：
- 通用代码审查或运行时调试
- 从零创建新 skill（这个更适合用 skill-creator）
- 评估非 skill 类型的文件
项目在这里：
GitHub - Evol-ai/SkillCompass: Evaluate agent skill quality. Find the weakest…
有兴趣的佬欢迎去 GitHub 点个 star 支持一下。
如果你手上也有自己的 SKILL.md，欢迎直接贴出来，我这边也可以顺手用 SkillCompass 帮你跑一遍测评。
有问题也欢迎一起聊，也可以 fork 回去自己改着玩
2 个帖子 - 2 位参与者