说个暴论，skill已死

我现在也有这种感觉，但是我认为skill在整理一些自定义的工作时还是好用的

感觉会换个形态，但是不会死的，没法替代

用memory替代skill有没有搞头？

死的大多都是做Harness Engineering 的Skill。

基于业务的skill永远不会死。

skill本来就没什么意义，具体的需求ai都能够且有能力理清

之前沉淀的 skill 都会被 codex/claude 内部吸收的。后面大概率只会针对自己公司业务或者仓库做很个性化 skill

大模型每次都去读取Skill这点太麻烦了，但对于一些自动化场景还是有点帮助的

有说RAG已死

有说MCP已死

现在又来个skill已死

superpower只能说是skill的一个发展分支吧？

skill有些时候更像是替代一些重复性工作的

比如说我有时候要修一下cc-switch

如果不用skill的话

那我还要每次都给cc粘贴一下ccs的目录呢

我自己也建了个小的站点

我去批量添加新帐号或者是删除的时候

也是通过skill去处理的

不然我就要一次又一次地复制相关信息给它

还有可能会弄错 ，漏掉部分配置细节

但是用一次次迭代的skill来处理就会好很多

这个可能不太好替代吧？

主要是AI公司会将比较火的skills炼进模型里，导致模型自带skills

grill-me还是挺有用的

superpowers本来就是为弱智的claudecode设计的。gpt从最开始就不需要superpowers

写了非软件代码开发的业务流程skill，

目前不用这个skill应该是没法产出结果的。

对的，这个就是我说的简单的skill，这个目前非常好用

skill不会死 skill本质就是替代重复流程的prompt，就好比你代码中抽象出来的方法

暴论个xx，现在的agent 开发工程师 本质就是skill开发工程师

怎么可能会死 SKILLS会越来越多，技能就是为了快速复用上次的工作流程而减少耗时快速使用的，便宜模型必须使用技能，贵的模型更要使用省token！

skill现在的趋势应该是从重型工作流范式，改变成轻型工具箱了，只是为了让模型不重复造轮子，而不是框死模型的流程

非常弱智且没有主见的想法

## [2026-07-29]



这两天在搞 zzz-skills，颇有些感悟



我之前对于 skills 的认知，无非是“对于BP的规则化“之类很普遍的观点。



随着 fable, gpt-5.6-sol 之类新一代 SOTA 模型的发布，尤其是随着 [The new rules of context engineering for Claude 5 generation models | Claude by Anthropic](https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models) 这篇post的发布。诸如“随着 model能力的进步，prompt/skills 已经不再重要了”之类的说法甚嚣尘上，很多人也跟着人云亦云瞎喊。“轰轰烈烈的prompts大删改活动又 TM 开始了”。



随着这几天处理 zzz skills（这个 zzz-skills 本身其实就是我把之前 alfred 里的 常用snippets抽出来，并做了工程化。

），对 skills 也有了更深的理解。其实skills之于 model，正如拐棍、护具之于人类，导航软件之于外卖小哥，本身就是起到一个辅助作用，在你不知道具体怎么做更高效的时候提供一个 instructions。LLM 的输出是随机的，如果 model 降智了呢（很多人说了，我用的可是 SOTA 模型哦。那我问了 SOTA不也是日常降智吗？）？如果 model 的产出不符合你的实际需求呢？



skills 这时就可以起到一个兜底作用，就像是一个某个区域跑了 N 年的快递小哥也会有迷路的时候，此时 skills 就起到了导航作用，未必是能激发其上限，但是



所以这里的实际bias 在哪？在于两点：



- 1、你真的理解自己的需求吗？

- 2、上限和下限。怎么 tradeoff 二者才是真问题（让 Model 高可用时，博上限；在 model 降智时，通过完善的prompt，提供下限）。但是好像又很难，因为 model 本身压根无法判断自己是否降智了（这里来说，是否应该在 harness 部分进行处理？可以考虑，判断当前 model 状态，然后发送不同prompt？这么搞的话，prompt 也要变成系统工程了）



做了这个 zzz-skills 之后的 workflow



- 1、skills 的链式调用很棒



这是打破我以往固有认知的一个点。我之前把这些 prompt 都存在 alfred snippts 里，就需要完全 HITP，输出完之后再把下一条 prompt 发上去。仍然不够 pipeline，做了 skills 链式调用，拆分清楚 skills 之间的依赖关系，该并行sub-agent的、该pipeline执行的、该停止并 hint 的，一目了然，状态也很清晰。并且可以进一步的基于此，结合herdr 做出一些harness层的实践，可以真正 HOOTP，效率提升不少。



目前所有关于 AI 的思考，都要回到几个边界条件（现实压力）：



- 1、Model 本身的不确定性。降智是必然的。我们不能把所有筹码压在“model 本身不降智”上，否则要做 loop-engr 里面大量调用 skills，一定会很痛苦。我们做传统应用要有“抗 xxx”，无论是日常使用（又或者开发）agent也要有这个意识。但是实话说如果降智到完全不遵循指令（我今天就遇到了，让执行 conclusion prompt，结果完全没按照格式返回，内容也只有一句话。当然这种case 确实偶发且低频），那确实是没辙了。

- 2、

前段时间写的