即刻App年轻人的同好社区
下载
刚在WorkBuddy上创建了一个skill，并让它告诉我怎么使用创建的skill，然后测试使用这个skill完成一项任务。
任务完成后问WorkBuddy有没有调用skill，结论是没有，它又手搓了一遍……
好吧。
任务完成后问WorkBuddy有没有调用skill，结论是没有，它又手搓了一遍……
好吧。
1 00
之前一直不怎么理解工具和skills的区别，刚查了一下：
核心区别一句话概括：小工具（Tool）是给AI的"手"，让它能做某件事；而Skills是给AI的"工作手册"和"大脑中的经验"，教它如何专业、稳定地完成一整件事。
可以把这个区别理解为"能力"与"胜任力"的差别。工具提供原始的原子能力（比如读文件），而Skills则封装了"在什么情况下、用什么工具、按什么顺序、怎么做"的完整方法论。
为什么不直接做成小工具，而要包装成Skills？
把小工具"包"进Skills，主要为了解决以下三个核心痛点：
1. 教会AI何时、为何使用工具，而不只是"能用"工具：一个小工具只负责执行，但不会告诉AI"什么场景该用它，用完之后怎么处理结果"。Skills正好提供了这个缺失的"策略层"。例如，一个"查数据库"的工具，搭配一个"客户信息查询流程"的Skill，就能让AI知道：应该先确认客户授权、再查询、最后按标准格式整理信息。
2. 从"抽卡式"体验，变成稳定可靠的工作流：传统AI做事像"抽卡"，每次结果好坏都依赖提示词写得好不好。Skills的本质是把经过验证的SOP（标准作业程序）、领域知识和经验，打包成一个可复用的"能力包"。这样，AI每次都会按照同一套"SOP"执行，产出的质量和流程变得可预期、可复制。
3. 避免"上下文爆炸"，让AI能记住成千上万个"技能"：如果每个工具的定义都塞进上下文，几百个工具就能撑爆AI的"内存"。Skills采用"渐进式加载"机制：
* 第一层（元数据）：启动时只加载所有Skill的名字和一句话描述（仅占几十个Token）。
* 第二层（激活）：只有当AI判断需要某个Skill时，才会加载其完整的指令文档。
* 第三层（执行）：需要时，才去读取附带的脚本、模板等资源文件。这就像一个巨大的"技能图书馆"，AI只把当前需要的"那本书"从书架上拿下来读，非常高效。
所以，把功能做成Skills，本质上是将临时的"提示词"升级为永久的"知识资产"。这不仅让AI的表现更可靠、更一致，也让这些最佳实践可以被不同项目、不同团队成员轻松复用。
核心区别一句话概括：小工具（Tool）是给AI的"手"，让它能做某件事；而Skills是给AI的"工作手册"和"大脑中的经验"，教它如何专业、稳定地完成一整件事。
可以把这个区别理解为"能力"与"胜任力"的差别。工具提供原始的原子能力（比如读文件），而Skills则封装了"在什么情况下、用什么工具、按什么顺序、怎么做"的完整方法论。
为什么不直接做成小工具，而要包装成Skills？
把小工具"包"进Skills，主要为了解决以下三个核心痛点：
1. 教会AI何时、为何使用工具，而不只是"能用"工具：一个小工具只负责执行，但不会告诉AI"什么场景该用它，用完之后怎么处理结果"。Skills正好提供了这个缺失的"策略层"。例如，一个"查数据库"的工具，搭配一个"客户信息查询流程"的Skill，就能让AI知道：应该先确认客户授权、再查询、最后按标准格式整理信息。
2. 从"抽卡式"体验，变成稳定可靠的工作流：传统AI做事像"抽卡"，每次结果好坏都依赖提示词写得好不好。Skills的本质是把经过验证的SOP（标准作业程序）、领域知识和经验，打包成一个可复用的"能力包"。这样，AI每次都会按照同一套"SOP"执行，产出的质量和流程变得可预期、可复制。
3. 避免"上下文爆炸"，让AI能记住成千上万个"技能"：如果每个工具的定义都塞进上下文，几百个工具就能撑爆AI的"内存"。Skills采用"渐进式加载"机制：
* 第一层（元数据）：启动时只加载所有Skill的名字和一句话描述（仅占几十个Token）。
* 第二层（激活）：只有当AI判断需要某个Skill时，才会加载其完整的指令文档。
* 第三层（执行）：需要时，才去读取附带的脚本、模板等资源文件。这就像一个巨大的"技能图书馆"，AI只把当前需要的"那本书"从书架上拿下来读，非常高效。
所以，把功能做成Skills，本质上是将临时的"提示词"升级为永久的"知识资产"。这不仅让AI的表现更可靠、更一致，也让这些最佳实践可以被不同项目、不同团队成员轻松复用。
0 20
