为什么说大部分 Skill 都是没用的垃圾

来源：一次关于 EDD Skill benchmark、AI agent 工作流和 skill 设计的讨论整理。
核心问题：一个 skill 到底有没有改变 agent 的行为？这个改变能不能被验证？

先说结论：

大部分 AI agent skill，不是 skill。它们只是提示词收藏夹、工作流鸡汤、伪装成方法论的愿望清单。

它们看起来很专业：

• 要严谨。
• 要测试。
• 要安全。
• 要分步骤。
• 要考虑边界情况。
• 要输出高质量代码。

听起来都对。

问题是，这些话对 agent 来说，大部分时候等于没说。

真正的问题不是“有没有写好听的原则”，而是：

这个 skill 到底有没有改变 agent 的行为？
这个改变能不能被验证？
如果它没用，我们能不能看出来？

如果不能，那它就是垃圾。

不管它写了 500 行，还是 5000 行。

Skill 最大的骗局：把正确废话包装成能力

很多 skill 都长这样：

当你写代码时，请先理解需求，设计方案，编写测试，注意边界情况，保持代码简洁，并在完成后运行验证。

这话错吗？

没错。

有用吗？

大部分时候没用。

因为这不是 skill，这是软件工程八股文。它不会告诉 agent：

• 什么情况下触发？
• 具体先读哪个文件？
• 失败时怎么判断是测试错了还是实现错了？
• 哪些路径不能改？
• 什么输出才算通过？
• 哪些行为必须拒绝？
• 怎么防止自己生成一堆看起来很努力的垃圾证据？

一个真正有用的 skill，应该像一个“带验收标准的操作规程”。

垃圾 skill 更像墙上的标语。

比如：

请重视质量。

这不是方法。

这是公司走廊里的海报。

真 skill 和垃圾 skill 的区别

我现在判断 skill 有没有用，只看两个维度：

1. 触发是否具体。
2. 结果能不能验。

可以粗暴分成四类：

大部分 skill 卡在前三类。

尤其是“考试小抄”最迷惑人。它看起来很像工程实践，里面有 TDD、review、security、edge cases、verification。

但你一跑 benchmark 就会发现：agent 只是更会表演了。

报告更完整了。日志更多了。测试文件更长了。最后 bug 还在。

这就是 skill 领域最常见的幻觉：

把“过程更像回事”误认为“结果更正确”。

我们自己做 benchmark 后，反而更不敢吹 skill 了

我们最近在 EDD Skill 上跑了几轮 benchmark。

EDD 是什么？简单说，就是让 agent 在改实现之前，先定义怎么验证结果：

expected behavior -> tests/evals -> implementation -> evidence -> regressions

这已经比大部分 skill 认真很多了。不是一句“请写测试”糊弄过去，而是要求留下 red/green log、eval、report、regression evidence。

结果很有意思，也很打脸。

五任务 A/B benchmark

规模：

5 trials * 5 task families * 2 conditions = 50 agent runs

结果：

EDD 让 agent 的过程证据大幅提升。报告、测试、red/green log、regression evidence 都明显变好。

但隐藏测试通过率没变。

也就是说：

agent 看起来更像一个严谨工程师了。
但功能正确性没有变好。

这很关键。

如果一个 skill 最后只能让 agent “更会写报告”，那它不是没价值，但价值边界必须讲清楚。

它提升的是可审计性，不是自动提升正确性。

两任务、双模型、40-run sustainability matrix

后来我们又跑了一个更接近真实 agent workflow 的矩阵：

5 trials * 2 task families * 2 model tiers * 2 conditions = 40 runs

两个任务：

• agent-policy-evolution
• subscription-billing-evolution

两个模型层级：

• SOTA
• economical

结果更刺激。

Process 分数暴涨：

• economical: 7.9 -> 23.9
• SOTA: 9.7 -> 34.5

但 hidden pass 反而下降：

• economical: 1/10 -> 0/10
• SOTA: 4/10 -> 1/10

Seeded-bug 也没有明显提升：

{
  "economical_skill_delta": 0.25,
  "sota_skill_delta": -0.5
}

这说明什么？

就算是一个认真设计、认真评测、真的能改变 agent 行为的 skill，也不能轻易宣称：

我让 agent 更正确。

它最多能先证明：

我让 agent 更可审计。
我让 agent 更愿意留下证据。
我让 agent 的工作流更像工程流程。

这已经不错了。

但这离“更正确”还差一截。

所以，大部分 skill 为什么是垃圾？

因为它们连 EDD 这种相对认真做过的 skill 都不如。

EDD 至少有 benchmark，有失败样本，有边界声明。

大部分 skill 呢？

没有测试。没有对照组。没有失败案例。没有指标。没有版本。没有维护。没有说自己不适合什么场景。

只有一堆漂亮句子。

更糟的是，它们会制造一种错觉：

我给 agent 装了 skill，所以它现在更专业了。

不一定。

很多时候，你只是给 agent 装了一个“更会装专业”的滤镜。

它会：

• 多写几个小标题。
• 多生成几个 checklist。
• 多说几句“已验证”。
• 多留几个日志文件。
• 多写一段“风险与后续”。

然后核心 bug 还在那里。

你以为你买了安全带。

其实你买的是安全带贴纸。

垃圾 skill 的 7 个特征

1. 没有明确触发场景

它写的是：

当你需要高质量完成任务时……

这等于什么都没说。

真 skill 应该说：

当你修改 benchmark runner 的文件写入逻辑时，必须检查 absolute path、.. path、workspace direct write bypass。

这才叫触发场景。

2. 没有可观察输出

垃圾 skill 会说：

提高代码质量。

真 skill 会说：

输出 matrix-score.json，其中 prepared run 的 seeded-bug score 必须是 0；reference implementation + hidden tests 必须 kill all seeds。

前者是愿望。

后者是验收。

3. 只写价值观，不写操作

“要严谨”不是 skill。

“要安全”不是 skill。

“要考虑边界情况”也不是 skill。

这些都是废话，除非它告诉你：

• 哪些边界？
• 怎么测？
• 失败怎么办？
• 什么时候停止？
• 哪些路径不能碰？
• 什么结果算过？

没有这些，就是口号。

4. 没有反例

一个 skill 如果只告诉你“什么时候用”，不告诉你“什么时候不要用”，它通常不成熟。

好 skill 一定有边界。

比如：

• 不要在纯文档修 typo 时强行 TDD。
• 不要把 benchmark scorer 改动和 task prompt 改动混在一个结论里。
• 不要把 process score 当 hidden correctness。
• 不要把 agent 自报成功当事实。

反例很重要。

因为 agent 最容易犯的错，就是把一个看似正确的方法用到所有地方。

5. 不能被测试打脸

这是最致命的。

如果一个 skill 无论结果好坏都能解释成“有帮助”，那它就是玄学。

好 skill 必须能输。

比如 EDD benchmark 这次就输了很多地方：

• hidden correctness 没提升。
• SOTA seeded-bug delta 还下降。
• economical hidden pass 也没提升。

这反而让它更可信。

因为它允许自己被数据羞辱。

垃圾 skill 不允许。

它永远赢。

也就等于永远没用。

6. 让 agent 更啰嗦，但不让它更正确

这是最常见的 skill 副作用。

用了 skill 后，agent 输出变成：

• 更长。
• 更工整。
• 更多标题。
• 更多表格。
• 更多 checklist。
• 更多“验证说明”。

但代码没更对。

这不是工程能力提升。

这是 PPT 能力提升。

对人类团队来说，这甚至更危险。

因为一个看起来很完整的错误，比一个明显草率的错误更容易被合并。

7. 不维护

工具会变。模型会变。runner 会变。项目结构会变。

skill 如果不更新，很快就会变成过期 SOP。

我们这次就踩过类似问题：Codex runner 允许 workspace-write。如果只验证 final JSON 里的文件，不处理 agent 直接写 workspace 的行为，就可能绕过路径限制。

这类坑不是靠“请保持安全”能解决的。

必须把具体坑写进 skill。

不维护的 skill，就像旧地图。不是没用，是会带你开进河里。

怎么判断一个 skill 值不值得保留？

我现在会用这 8 个问题审 skill：

1. 它有没有具体触发条件？
2. 它有没有明确的输入和输出？
3. 它有没有告诉 agent 先做什么、后做什么？
4. 它有没有失败处理？
5. 它有没有禁止事项？
6. 它有没有验证命令或验收标准？
7. 它有没有记录已知坑？
8. 它能不能被 benchmark 打脸？

如果 8 个里面过不了 5 个，基本可以删。

别舍不得。

skill 太多本身就是污染。

agent 的上下文不是垃圾桶。每塞一个没用 skill，都是在稀释真正有用的约束。

真正有用的 skill 应该长什么样？

不是“最佳实践大全”。

而是这种东西：

当你改 benchmark runner 时：

1. 先读 prepare / run / score / status 四条路径。
2. 找出 per-task metadata，不要硬编码旧 task。
3. 写入文件前必须 reject absolute path 和 `..` path。
4. Codex workspace-write 要 snapshot，直接写入必须丢弃，只应用 JSON 声明文件。
5. prepared run 的 seeded score 必须是 0。
6. reference implementation + hidden edge tests 必须 kill all seeds。
7. 改 scorer 语义要单独版本化，不能和 prompt 改动混成一个结论。

这才有用。

它不是“鼓励 agent 变好”。

它是把过去踩过的坑变成未来的护栏。

最后说句难听的

大部分 skill 没用，不是因为 agent 不够聪明。

是因为写 skill 的人自己也没想清楚：

我到底想改变 agent 的哪个行为？
我怎么知道它真的变了？
如果它没变，我能不能承认？

很多人写 skill，其实是在写一种心理安慰。

像给项目贴上“已工程化”的标签。像给 agent 穿一件反光背心。看起来安全了。实际上车还没刹住。

所以我现在更愿意相信那些短一点、硬一点、能被验证的 skill。

哪怕只有十行。

只要它能让 agent 少犯一个确定的错，它就比一篇三千字的“高质量开发指南”有价值。

skill 不该是玄学。

也不该是提示词装修。

skill 应该是：

可复用的行为约束 + 可执行步骤 + 可验收结果 + 已知失败样本

没有这些，就别叫 skill。

叫垃圾比较准确。

发布短版

大部分 AI agent skill 都是没用的垃圾。
不是 skill 这个概念不行，是大部分 skill 根本没资格叫 skill。

一个 skill 如果没有具体触发场景、没有可观察输出、没有反例、不能被测试打脸，它就只是提示词装修。

我们跑过 EDD Skill benchmark。结果很打脸：process evidence 大涨，但 hidden functional correctness 没有稳定提升。
这说明即使是认真做过的 skill，也只能先证明“更可审计”，不能直接吹“更正确”。

所以那些没有 benchmark、没有失败样本、没有验收标准的 skill，凭什么说自己有用？

真 skill 应该是：可复用的行为约束 + 可执行步骤 + 可验收结果 + 已知失败样本。
没有这些，就别叫 skill。叫垃圾比较准确。