最近有不少爆火的 skills：Ponytail 号称解决 over-engineering，Caveman 号称大幅减少 token 消耗，andrej-karpathy-skills 试图提升 coding agent 的工程质量，Superpowers 是把 brainstorming、planning、TDD 和 code review 组合成一套完整开发流程。
2026 年 9 月 3 日，这四个 repo 的 GitHub star 分别是 12 万、10 万、21 万和 28 万。作为对比，React 是 25 万左右。
它们都击中了真实痛点。Coding Agent 确实经常输出啰嗦、添加不必要的 abstraction，在需求没想清楚时直接开始改代码。
但他们的几十上百行 Markdown 真的解决这些问题了吗？
两种 Skills
今天在 “Agent Skill” 这个名字下的，我觉得有两大类。
第一类是任务专属能力型 skill。它更像一份给新员工准备的 SOP 或 Runbook，里面包含完成某项任务所需的领域知识、项目 context、操作步骤、文件格式，甚至可以执行的 scripts。
比如一个处理公司财务表单 PDF 的 skill，可能知道应该调用哪些工具、如何定位表单字段、输出文件必须满足什么格式，并附带一个稳定的解析脚本。这类 skill 补充的是模型原本缺少的知识和工具，当然可能显著提高结果。这也符合 Anthropic 最初对 Agent Skills 的定义：instructions、scripts 和 references 的组合。
今年年初的 SkillsBench paper 的结果支持这一点：在 87 个任务中，人工编写并针对任务匹配的 curated skills 将平均通过率从 33.9% 提高到了 50.5%。
第二类则是通用行为型 skill。它们通常不包含新的领域知识，也没提供模型原本无法使用的工具，只是在强调某种特定行为：
- 少写代码；
- 不要 over-engineer；
- 先思考再实现；
- 必须先写测试（TDD）；
- 不要说废话；
- 优先使用标准库；
- 只做用户明确要求的事情。
都是通用的工程价值观和策略选择。而最近流行的这些 skills，大多数都是这类。
把 Trade-off 包装成 Best Practice
这第二类流行 skills 往往遵循同一个模式：
先找到大家经常抱怨的模型行为。这些行为背后几乎都是一个 trade-off：先规划还是先动手，多解释还是少说话。然后选定 trade-off 的一侧，把它改写成 ALWAYS、MUST、NO EXCEPTIONS，最后配上一个容易传播的 persona：“最懒的 senior engineer”“像 caveman 一样说话”“像 Andrej Karpathy 一样写代码”。
然后，用一些所谓的 evaluation 恰好测量这条指令最直接影响的指标（有些甚至什么 evaluation 都没有）：
- 要求少写代码，就测 LOC；
- 要求少说话，就测 output tokens；
- 要求先 plan，就把流程完整度当作质量。
这能证明 skills 改变了模型的行为，但没证明的是，这些行为改变是否能带来更好的通用表现。
Ponytail 和 Caveman
Ponytail 是一个很典型的例子。它本质上是把 YAGNI、标准库优先和最小实现写成了一套更强硬的 instructions。Colin Eberhardt 对其 benchmark 的复测发现，一句 "Follow YAGNI principles" 已经接近完整 skill；再加上 "one-liner solutions"，七个英文单词直接超过了 Ponytail 在自己 benchmark 上的结果。
公平地说，Ponytail 确实能让 agent 少写一些代码，但这和项目宣传里暗示的那种效果，装了这个 skill 就让你的 coding agent 魔法般有了 senior engineer 的工程品味相差甚远。
Caveman 也是，确实能让 agent 的 narration 变短，但在真实 agentic workload 中，大部分输出本来就是代码、diff、tool calls 和错误信息。JetBrains Blog 里面在强制启用 Caveman 的情况下只测到 8.5% 的输出 token 减少，而不是宣传的 65%；任务质量也没任何改善。
Andrej Karpathy Skills
andrej-karpathy-skills 也类似。它借用了 Karpathy 的名字（这个 skill 当然不是 Karpathy 自己写的），听起来像是能让 agent 变得和 Karpathy 一样思考。但核心其实只是让模型先思考、保持简单、减少改动和明确验证目标。
Kun Cheng 用 ProgramBench 的 192 个配对任务测了一下：加入这套 guidelines 后，平均测试通过率从 53.7% 降到了 51.5%，成本反而增加 5%。主要失败模式并不是模型没有遵守指令，而是它遵守 “minimum code” 和 “只实现明确要求” 导致最终主动缩小了功能覆盖范围。
有意思的是，大多数退步的任务里，模型写的代码反而更多了。它会自己说服自己"做一个紧凑的自定义 evaluator，不要试图变成一个数据库"，然后拒绝直接调用 SQLite 这种最简单也最正确的方案。
Superpowers
Superpowers 比前面几个更完整。它不只是一个 style prompt，而是一整套 software-development methodology：先 brainstorm，获得设计确认，创建 worktree，写 implementation plan，再严格执行 red-green-refactor TDD。
这些做法在一些项目中当然有价值。但为什么任何 feature 都必须 TDD？为什么一次很小的内部工具修改，也必须先产生设计文档？为什么 exploratory implementation 不能先帮助我们理解问题？
Kun Cheng （强烈推荐 follow 他的 X）又帮我们用 ProgramBench 测过了，如果强制 TDD workflow：相同的 192 个任务中，通过率降了 4 个百分点，成本增加 55%，turns 增加 69%。Agent 写出了不完整的测试，然后只实现足以让自己测试变绿的功能，最后带着错误的信心提前停止。
一个 benchmark 上的结果当然也不能证明 TDD 不好。但至少能让大家清醒一点：即使一种对人类团队有价值的工程方法，把它无条件强制给 Agent，效果也不一定总是更好。
Skill 能带来更好的通用表现吗？
通用行为型 skills 可以改变 agent 的输出风格。让 coding agent 输出更短、更谨慎、更爱写测试。比如 Ponytail 把模型推向 minimalism，Superpowers 把模型推向 process rigor。
但它无法保证新的策略更适合当前任务。它往往只是把错误的方向从一边移动到了另一边：
- 少了 over-engineering，多了 under-implementation；
- 多了测试，未必多了有效 coverage；
- 多了 planning，也多了 context consumption、cost 和任务所花费的时间。
如果几条简单 instruction 真的能在所有任务上稳定提高正确率，我相信模型和 harness 厂商有比社区 skill 更强的手段去实现它：post-training、tool design、verification harness 或者直接把 instruction 放进 provider 的系统 prompt。它不太可能一直以一个 GitHub repo 里的 Markdown 秘方形式等待大家发现。
Claude Code 的 system prompt 里早就写着不要 over-engineer、不要做用户没要求的改动、不要加不必要的抽象这类话。这些 skill 里的很多条，模型每次启动时就已经读过一遍了。社区 skill 做的事情，是把同样的话再重复一遍，写得更长、更绝对、更有 meme 感、再加一个 persona。
谢谢 Kun Cheng、Colin Eberhardt 和 JetBrains 的 Denis Shiryaev，他们花了真金白银把这些 skill 一个个跑了一遍。总要有人做这件事。
References:
- Ponytail? YAGNI! — Colin Eberhardt
- Ponytail Skill for Claude Code: Does It Really Cut Agent Code by 54%? — JetBrains
- Does Speaking to Agents Like Cavemen Really Save 65% of Tokens? — JetBrains
- Do "reduce LLM coding mistakes" guidelines help a coding agent? — Kun Cheng
- Does test-driven development help a coding agent? — Kun Cheng