一直不理解 skills, 这不就是提示词吗?

3 天前
 zeni18

我一直会看到 抖音上 介绍有了整个 skills 就能啥啥啥的, 但是在我看来 skills 就是按需加载提示词而已呀 。有说的这么玄乎吗?

11361 次点击
所在节点    问与答
110 条回复
ychost
3 天前
所有的程序本质都是 CRUD 一个道理,无论是 Web/前端/嵌入式 都是对 DB/State/寄存器 做 CRUD 而已
Lightbright
3 天前
所有程序不都是些字节吗?有说的这么玄乎吗?
ooppstef
3 天前

你对 llm 所有的能操作的东西,不就是 prompt 么?所以你非说是提示词,也不是不可以。
但是 skill ,按需加载是一回事
另外不是 skill 本质是一个 sop 吗?并且其中的某些步骤,还可以添加 script 通过计算得来,而非静态文本。
所以动态性,流程性才是关键啊。
wolfie
3 天前
对,第一次了解概念时候还自我怀疑不应该这么简单。
jaoyina
3 天前
@jonsmith #16

对呀,认为 skill 只是提示词的肯定只用过最简单的一个 md 文件的 skill 吧。
clanboy
3 天前
skills 我认为是提示词集合+可执行脚本的组合怪,简单的举例,比如可以将生成的图片通过自定义脚本上传到自己的储存桶,直接返回储存桶的 url ,某些时候还是方便的一批
ndxxx
3 天前
要用好 MoE 模型,当然需要好的提示词了,当然现在的 coding agent 的 harness 做得越来越强(主要是软件工程方向),所以给很多人造成了一种 skills 越来越不重要的错觉😅
wangxiaoer
3 天前
我的理解:
1 、skills 的本质就是提示词,只不过不同任务需要的提示词可能不一样,因此通过 skill 文件的方式对提示词进行分类,涉及特定任务的时候由 agent 选择接近的 skill ,把这个 skill 内容作为提示词连同问题提交给模型。
2 、和常规纯文本提示词不一样的地方在于,skill 里面可以包含一些代码之类,本质上还是提示词。哈哈哈
3 、不用 agent 的情况,如果应用程序里面直接调用大模型,处理不同任务,你可能也会把不同提示词做成模板,跟 skill 没区别。
chjqpmain
3 天前
有的 skill 包里会带着一些工具类似 mcp ,

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

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

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

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

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

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

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

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

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

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

怎么一个概率比

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

所以我还是选择适当的用 skill
codeface
3 天前
就是你理解的那样,没什么玄乎的。
bowencool
3 天前
就是因为“按需加载”才火啊,以前那个 MCP 咋死的
ywutiao
3 天前
定义为嘉豪,那编程本质就是机器码呢还
iOCZS
3 天前
上下文是宝贵的资源,所以要渐进式披露
lightyisu
3 天前
skills 嘉豪来了 蹲一个 harness 嘉豪
aireason
3 天前
好问题啊,为什么会有人冷嘲热讽的。不管自己编程还是 AI 编程,把最基础的问题反复折腾弄清楚,从来不是坏事。

skill 我现在用的少了,主要是没耐心读里面的细节,那么它到底预载了什么你就不得而知。我现在主要自己写 agents.md
ota
3 天前
@hidemyself harness 不是一套 loop 吗?叫做任务状态机循环。
laurent
3 天前
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 文件要方便很多。
wellqq
3 天前
语言的边界就是思想的边界
RIcter
3 天前
@laurent 其实 cli 在安全性、可控性方便很难取代 mcp+tools
V2Try
3 天前
@laurent mcp 没有被取代呀

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://v2ex.ih06.com/t/1238642

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX