一直不理解 skills， 这不就是提示词吗？

现在还在推荐 skill 的，可以直接定义为割韭菜的

不管上层多玄乎，进模型的总归是提示词
skill 主要是一个大部分 agent 都认的约定格式

其实没啥神秘的，就是告诉 AI 一些特定的操作流程罢了，比如一些私有的 API 调用或者操作 AI 本身不知道

圈外人不懂内部机制，看什么都觉得神秘，博主就是什么有流量做什么
说白了 skill 就是告诉模型一声他没学过的东西，有用但一点不玄乎

skills 是带有知识的提示词，当然神秘了。

所有的 harness 都可以理解为提示词

是提示词，毕竟最后进模型，都是提示词。

你就当他是预制提示词，和预制菜一样。

大模型不知道番茄炒蛋咋做，于是有人做了个 skill ，说先倒油，后咋样，然后再咋样，最后咋样。于是乎大模型照着这个做，就做出来番茄炒蛋。

那么当别人也需要做番茄炒蛋的时候就不用自己一步步告诉大模型制作步骤，直接用这个 skill 就行。

随着大模型越来越牛逼，之后某个大模型在训练的数据里就已经有了番茄炒蛋的制作方法，那么这个大模型即使不需要这个 skill ，也能做番茄炒蛋了

本来就是，技术上没什么神秘或者重大革新的东西。

大多数自媒体都是在瞎吹，蹭热度和流量。

例如当初的 openclaw 。

可以翻译为说明书，各种技能的说明书😄

skill 之后，又有什么新概念出来了吗？

skill 是说明书，skill 配套的工具才是大头，

学的晚就不用学，skill 已经过时了

说白了就是将知识提炼出来一个函数，方便后面重复使用

安装方便，配套代码，格式固定，按需加载

几个字叫短句，几十个字叫短语，几百个字叫小作文，几千个字叫作文，写到几十万字就可以出书了，相似的东西不同的量级就会有不同的组织方式，也会由量变产生一些质的变化，就像 LLM ，个人理解

skill 不只是提示词，可以定义一些脚本，本质是封装一些工作流

我到现在还没用各种 skill ，我觉得 plan + agent.md 够用了。
如果不够，就用更好的模型+思考强度
还不够就加更详细的提示词

skill 还挺好用的
根据我们公司内部的日志平台，做了个线上问题排查的工具，有线上 bug 就直接调用 skill 去查就行了。
说简单也简单，就是发一下日志平台地址，怎么连接，但是每次排查都要说一遍，干脆做了个 skill 直接调用就行了。

skills 相对于简单提示词，还可以打包个脚本，触发的时候调用脚本

我给你最简单最直白最不绕弯的一句话说明 Skill 和一句话提示词的作用：

一句话提示词就好比王阳明的 “破山中之贼，易；破心中之贼，难”；而 Skill 就是 《传习录》《王阳明大传》《王阳明全集》《阳明学述要》《有无之境》。

最主要的是可复用吧

你还可以认为是个组件。抽离的组件

有没有人做过提取主流 skill 中的知识点然后总结出有用的知识点

你在论坛回复，会用这个编辑框和点击下面的回复

而不是裸发 http 请求，你会想，为什么每次这个 cookie 都一样我还要手动传呢

SKILL 很好用的啊，特别是针对自己的，流程有点个性化特殊化，又是重复使用的，炼化成 SKILL ，下次触发一下就干活了。

skill 管的是流程，不是能力上限。

如果你写代码的话，不难理解呀。函数是什么，不就是一些代码。
但是函数的价值在于复用，把重复使用的功能封装起来。那如果要复用的函数很多呢，就形成函数库了。

就是一个不需要每次输入且用于规范性的提示词,所以它叫技能.

从形式上来说，的确就是提示词，但是大部分人就是不会写提示词。那种写得好的，流传下来的就成为 skills

这个概念还是有用的, 一些优秀中间件提供的 skill, 可以做到不用看教程了. 开发流程中也可以用 skill 作为代称来沟通, 形成共识和规范之类的.
从上面的评论可以看到, 大家很容易陷入"不就是 xxx"这种简单化归类的思路上. 我感觉长期这样简单化, 会让自己变成思维巨人, 行动矮人

SKILL 不是目的，是为了让 AI 了解 SKILL 里面的工具，各种工作流 不同 Agent 调用，我觉得都是 AI 上下文不够的情况下的妥协

这不就前端娱乐圈里的 markdown 工程师吗？

你有这闲工夫多加加班，没事去抖音上找什么优越感

Skill 搭配 MCP/插件才是正解，其他全浪费上下文

算是给模型的 SOP 吧

我也有同样的疑惑，不就是提示词嘛，还非要创+用个 skill 来代名，神神叨叨的

前几年 AI 刚出来的时候，我看到有人用“咒语”这个词，感觉更传神

封装提示词和工具 如果你每次用通用功能也能实现 不过已有的功能封装好 可以更加高效完成任务 而不是每次都要重新写 Python 来实现这个能力

感觉 skill 就是封装了一个成功的流程，那些视频像是卖课 卖 skill 的

@hidemyself 不一样吧。hareness 我理解的是让程序来设定条件，规定流程和输入验证，而你说的应该单纯就是提示词的约束和约定

严格来说确实不止提示词，你还可以自己写点特殊实现的代码，提示词告诉 agent 这些代码怎样用。mcp 不就是 http 接口么，不还整个新词出来，历史一直是这样的。对了现在还有个词，本体。不弄新词咋吹牛逼。

把知识，技能，方法论翻译给 AI 模型标准输入，就是 skill

本质不能取代现象。

虽然不必神话 skill ，但是如果每天都在使用 coding agent 开发，还不知道 skill 是什么/怎么生效，还没有梳理总结过自己的 skill ，只能说明学习/总结能力太差。

最简单的，请观察一下 agent 的思维链和工具调用链，如果总是重复同一类错误（如查数据库应该带表名但是没有带，查日志某些字段写不对，生成的技术文档不符合规范），这个时候就应该让 agent 总结经验生成对应的 skill ，至少也应该写进 AGENTS.md 或等价物。

就是提示词写的 ai 时代的 bash 脚本

我一直理解为大模型时代的框架

@wfg 你有病吧

skills 肯定是有用的, 只不过随着现在模型能力越来越强, 臃肿复杂的 skill 可以退出历史舞台了, 但现阶段 skills 依然是上下文工程里重要的成果

无论前面怎么绕，到最后都是给模型一段字符串，模型返回一段字符串的过程。

你这个理解就像是在说，所有的框架、算法、代码包有啥牛逼的，在我看来都是代码，都是 if else 而已呀。

所有的软件到执行层都是那么几个语法的代码而已，所有的 skill 、harness 、agent 最终也都是生成提示词而已。

这其实就是之前咱们笑话的 markdown 程序员的应有之义。

skills 只是一个规范，把一份文档说明+一堆执行脚本或是工具包，放在一个文件夹里。让 AI 阅读文档说明，去调用 skills 文件夹下的其他文件，通过这种手段封装 AI agent 的功能而已。

llm 不就是基于概率的高维统计预测系统吗. 有那么玄乎吗?

大模型的执行过程和结果是不稳定的,并且相同的问题每次都让大模型从头分析处理消耗太多 token,skill 就是把已经走通的流程标准化沉淀下来,作为大模型的外挂提高效率和稳定性,不只有提示词还可以包含脚本片段附加知识等.
每个行业都有自己独特的领域知识,每个人也都有自己的不同习惯和输出要求,在大模型成为全知全能的神之前,skill 都是有用的.

可以理解成提示词+SOP 吧。
其实你选的思考等级也是提示词。

skills 就是提示词？那小说也就是文字，你怎么不是作家。

最初推出来的时候是从 Agent 角度提出的，https://windliang.wang/2025/12/30/%E4%B8%80%E6%96%87%E4%BA%86%E8%A7%A3Anthropic%E6%96%B0%E6%8E%A8%E5%87%BA%E7%9A%84Skills%E6%A0%87%E5%87%86/

@windliang 其实当时明眼人都知道偷了 Cursor Rules 里的可选规则，但是 Cursor 没想着拿它造生态。

skill 还包含脚本呀，很多 skill 是有代码的，这就是和提示词不同

skill 还可以有脚本(代码)，参考图片，参考文档...，比单独的提示词功能要更完全。

skills ，可按需加载的、可复用的提示词。
传入的是摘要，然后模型自己判断是否需要加载 skills 的全文。

有人说脚本，脚本也不是 skills 的本质特征啊，你不要任何 skill ，直接告诉 LLM 脚本 / 接口怎么调用，一样能调用吧，这是模型的 function / tools calling 能力。

LLM 输入输出都是 token ，这意味着大部分新名词都是换个皮的说法。譬如 context 和 prompt 之间差异，包括之前的智能体，大多数时候不也是写一段角色扮演的提示词？真的是新瓶装旧酒，利用了 LLM 极强的 few shots 能力。

进一步说，思维链一开始也只是提示词而已，就是输入上让它一步步思考。后面才发展出来专门的 <think> 标记，以及训练上鼓励这些 token 的生成还有思维链的长度奖励函数。

所有的程序本质都是 CRUD 一个道理，无论是 Web/前端/嵌入式 都是对 DB/State/寄存器 做 CRUD 而已

所有程序不都是些字节吗？有说的这么玄乎吗？

？
你对 llm 所有的能操作的东西，不就是 prompt 么？所以你非说是提示词，也不是不可以。
但是 skill ，按需加载是一回事
另外不是 skill 本质是一个 sop 吗？并且其中的某些步骤，还可以添加 script 通过计算得来，而非静态文本。
所以动态性，流程性才是关键啊。

对，第一次了解概念时候还自我怀疑不应该这么简单。

@jonsmith #16

对呀，认为 skill 只是提示词的肯定只用过最简单的一个 md 文件的 skill 吧。

skills 我认为是提示词集合+可执行脚本的组合怪，简单的举例，比如可以将生成的图片通过自定义脚本上传到自己的储存桶，直接返回储存桶的 url ，某些时候还是方便的一批

要用好 MoE 模型，当然需要好的提示词了，当然现在的 coding agent 的 harness 做得越来越强（主要是软件工程方向），所以给很多人造成了一种 skills 越来越不重要的错觉😅

我的理解：
1 、skills 的本质就是提示词，只不过不同任务需要的提示词可能不一样，因此通过 skill 文件的方式对提示词进行分类，涉及特定任务的时候由 agent 选择接近的 skill ，把这个 skill 内容作为提示词连同问题提交给模型。
2 、和常规纯文本提示词不一样的地方在于，skill 里面可以包含一些代码之类，本质上还是提示词。哈哈哈
3 、不用 agent 的情况，如果应用程序里面直接调用大模型，处理不同任务，你可能也会把不同提示词做成模板，跟 skill 没区别。

有的 skill 包里会带着一些工具类似 mcp ，

然后我记得之前看到说对比 skill 和 mcp ，

是最开始所有 mcp 被全部全量塞进模型上下文，
那时候 harness 很原始，

后来出了 skill ，skill 里是描述，内容…等等不同块，
模型运行时，上下文只灌输 skill 的名字和什么时候调用，

然后需要的时候模型自己调用，
那时候很多都是带着脚本的，

我感觉现在 vibe 越来越普及，而且审美方面的，和一些非工具类的需求，

这些催生了现在绝大多数的提示词作为 skill ，

我觉得当成是做一个通用任务前，原来你需要逐个给祂提要求，作为提示词发送，

现在模型自己需要时提前看一遍帮助，标准，可能的坑，

这是靠 harness 以及模型的主动训练一起促成的，

我感觉优势挺大的，缺点是我不知道不断迭代的模型就某个问题，到底需不需要该提示词，
该提示词浪费，还是反过来降低了模型的上限，

怎么一个概率比

但是大部分任务都是批量量产的，
哪怕涉及审美的也可以抽出很多部分是同样流程，

所以我还是选择适当的用 skill

就是你理解的那样，没什么玄乎的。

就是因为“按需加载”才火啊，以前那个 MCP 咋死的

定义为嘉豪，那编程本质就是机器码呢还

上下文是宝贵的资源，所以要渐进式披露

skills 嘉豪来了 蹲一个 harness 嘉豪

好问题啊，为什么会有人冷嘲热讽的。不管自己编程还是 AI 编程，把最基础的问题反复折腾弄清楚，从来不是坏事。

skill 我现在用的少了，主要是没耐心读里面的细节，那么它到底预载了什么你就不得而知。我现在主要自己写 agents.md

@hidemyself harness 不是一套 loop 吗？叫做任务状态机循环。

skills+cli 就是用来取代 mcp+tools 的。

mcp+tools 有什么问题？
- mcp 提供的 tools 的定义要全部放入上下文。每个 tool 要怎么用，参数怎么填，全都放入上下文中。使用的 mcp 太多的话，初始一句"hi"都要几十 k 上下文
- 自己写工具要符合 mcp 协议，麻烦；而且 tool 之间无法协作，第一个 tool 调用的输出要作为第二 tool 调用的输入，要怎么办？无法由 Agent 工具处理，要 LLM 自己记住第一个输出，再去用来调用第二个 tool

那换成 skill+cli 呢：
- 相比 mcp+tool ，skill 只将 description 放入上下文，description 只是一句话，讲什么情况下要去阅读这个 skill 。初始上下文少很多。我在 pi 上一般只有 3-4k 初始上下文
- skill 描述的是如何使用 cli 工具。所以只需要用你喜欢的语言普通地写 cli 工具即可，无需符合 mcp 协议。而且 cli 间天生可以用管道协作。比如你的 cli 工具输出 json ，LLM 会直接调用`your-cli | jq ...`来获取想要的字段

另外，skill 只是 markdown 文档，安装只需复制到指定目录。应该比设置 mcp config 文件要方便很多。

语言的边界就是思想的边界

@laurent 其实 cli 在安全性、可控性方便很难取代 mcp+tools

@laurent mcp 没有被取代呀

之前有个炼化前同事的项目，这个其实就是制作 skill 了。
假定你的前同事懂报销流程，知道怎么写周报和季度总结，能安排会议工作事项等等，那咱们就把你前同事会的这些活都给炼化成 skill ，干啥活的时候指挥一下，例如说帮我报销这几张单据，哎，AI 就按报销流程去填写报销表格，计算金额，打印封面，形成报销单据并贴上你的数字签名，发给财务。这就是一个报销 skill ，专事专办，流程规范统一，AI 完全按 skill 文件中规定的要求进行处理，不会自己瞎想乱做乱试。有的 skill 可能需要连接数据库获取员工信息，或者联网获取最新的股票行情，一般需要结合 MCP ，甚至个人专用的 skill 可能需要调用编写好的代码来处理一些复杂工作…
现在 github 上面就有一些项目，可以顷刻之间炼化同事，甚至是自己

啥玩意不是提示词 但你愿意每次打一堆提示词吗

skill 就是 runbook

需要了去看一眼，再用里面的 cmd 操作一下。

1.这堆提示词，并不是你以及其他普通程序员能写出来。

2.这堆提示词，实现了软件工程中的复用与模块化的原则。

3.这堆提示词，能节约 AI 的上下文窗口。

我做了一个某网站的签到 skill ，只需要告诉它账号和密码，设置定时任务就能每天定时签到。
相比使用脚本签到的好处就是，即使网站的 UI 或者 API 或者网址发生了变化，它也能自适应，实现签到。
你说这玩意是提示词，我是不太服的，它就是一个程序。

@jaoyina 思路放开点，定义的脚本不也是提示词吗，我把脚本代码放到 skill.md 里，你该怎么理解呢

因为可以完整严谨的表达自己的需求一个稀缺的技能，skills 可以辅助用户完成这一步骤。llm 是通用场景，对于很多特定领域，有自己的独特要求，那么 skill 就是一个提前准备好的卤料包，省得每次打字打一堆烦腱鞘炎。

没用过就多学学，就算写好提示词，搞懂领域 SOP ，也没你想的那么简单

因为用大模型的人也不知道该给大模型传什么提示词， 于是就有了预制提示词

省 token

编程的 agent 是不是默认自带了一些 skills 提示词？

skills 就是可复用的工具啊，你是愿意每个类似的任务都让大模型重新探索一遍整个流程，还是写好固定的文档让大模型直接照抄省事？

skill 不只是提示词, 还有脚本甚至 exe. 通俗易懂的解释应该是, 把不需要 ai 反复执行的步骤抽取为脚本,然后通过提示词说明书让 ai 自己执行脚本省 token 省时间.

嗯...ai 低代码...

不一样的，把 ai 比作员工，提示词相当于口头要求员工怎么做，skills 就是写了一套规章制度，构建好了工作流程，分配了办公权限，效果是很不一样的

这个理解没错，使用和编写 skill 不用有心智负担，或者说直接不用 skill 只是借用它这个索引加固化流程的设计思想也是一样的效果。

AI 已经开始学会自动加载 skill 了
学得晚就不用学+1

@rxs gpt 是这样，cluade 没用过，不知道；

所以以后 agent 工具都不用自己提供 skill catelog ，模型自己调用 Bash 工具找 skill.md/agents.md ，这样挺好

@RIcter 如果你说的安全性、可控性是指，每次 tool 调用时，命令和参数都是按格式写的，可以很容易校验，拒绝危险操作的话，那这只在禁用 bash tool 的情况下成立。
有 bash tool 的话，Agent 用 bash tool 干啥都行，因为命令内容多种多样，管道、调用 python 、node 写临时脚本，很难去写代码找出 bash 命令中的危险操作。
实际上现在的模型，非常积极的使用 python 写临时脚本来处理任务。禁用 bash 就相当于削弱了模型的能力。

@V2Try skill+cli 可以取代 mcp+tool 。
模型如何使用 mcp? 发起 tool 调用->你的 agent 发现这是由 mcp 提供的 tool->调用 mcp 关联的 cli/发起 mcp 相关的 http 请求->将 cli 输出/http 响应作为 tool 调用结果
那模型如何使用 cli? 发起 bash tool 调用，命令内容是调用 cli -> 使用 bash 子进程执行 cli->cli 输出作为 tool 调用结果

基本上没区别吧？ http 请求用 bash 调用 curl 就行了

实际上，现在的极简 harness 比如 pi 和 dsh 极简模式，只提供 bash+基本的文件编辑 tool ，就没有其他 tool 了，也不支持 mcp

真正的 skills 是我搞了一套工具，然后还把说明书给你了
如果只是给个说明书，没有提供工具，那确实就和提示词没什么区别