小宇宙音频转文本

[00:01] **主持人：** 大家好，欢迎收听《尼海课》，我是Settle，我是伊笑，我是龟龟。本期节目由Podwise赞助播出。Podwise是一款为播客听众制作的AI学习软件，产品的slogan是“Read Before Listen”。Podwise通过AI对播客内容进行转录、提取、总结、分析等一系列操作，帮你掰开了揉碎了硬核的播客内容。同时。  
[00:27] **主持人：** 同时与 Notion、Readwise 等平台的打通，嵌入知识管理工作流，协助您的其他包括新闻、newsletter、blog 的内容，帮你打造第二大脑。Podwise 也为本期听众准备了三个五折优惠码，针对本期在小宇宙与我们互动的精选回复，欢迎大家踊跃来玩。好的，那开始我们本期的节目吧。  
[00:48] **主持人：** 说到 Anthropic 啊，在编程这个领域，它一直都是王者级的选手啊。Cloud Code 到今天啊，基本上已经成为行业标杆了。但除了把模型做大做强之外，Anthropic 其实还特别擅长另外一件事儿，就是它把怎么用模型这件事儿，能把自己的方法论推成行业共识。其实 MCP 我们还没怎么消化完啊，它现在又推出了一个新的叫 Agent Skills，现在各大编程的工具已经把它默认成了一个标准啊。  
[01:16] **伊笑：** 好像只要Anthropic一开口，大家就默认了说，嗯，这个就是正确的抽象。那我们今天就来认真聊聊这个Agent Skills，它到底是一次工程的进化，还是一次大家集体接受的一次概念迁移？我不知道你们怎么看。嗯，我觉得提到Anthropic，确实这家公司我还是挺佩服他们的哈。在计算机领域其实有一句名言是这样说的哈，就任何问题你都可以通过增加一层抽象来解决，当然。  
[01:45] **伊笑：** 除了抽象层数过多这个问题以外，你都可以通过增加一个抽象层来解决。那Anthropic这家公司其实是深谙此道的哈，就像刚才我们开头提到的，像什么MCP都是一个抽象层，抽象的一个标准层对吧？那今天呢，其实 Skills 这一层它本质上也是一个抽象层。就我们去看 Skills，其实我第一次去学习 Skills 的时候，其实我是脑子里一下都会闪过其他的一些框架，比如像什么 LangChain 啊、LangGraph 啊，还有等等其他的一些 Agent 框架，然后以及和他们去对比的话，那我自己会认为。  
[02:27] **伊笑：** 这是一次工程的进化。为什么这么说？就Skills它不像MCP，只是定义了一个标准协议。其实本质上Skills它的底层其实是有一个Long Time的框架的，你可以这样理解。然后在Cloudy它有一个叫Agent SDK的这样的一个框架，一个工具开发工具集吧。那这一层我们可以把它理解成，它几乎是等同于像LangChain啊、LangGraph啊这些，帮你去完成了如何去通过开发，通过代码去构建一个。  
[03:03] **伊笑：** 呃，这样的一个框架层，说其实他们一定是先有了这样的一个框架层给开发者用的这样的一个框架层，然后才会发现说，哎，除了给开发者用，那我们能不能让一些非开发者，或者说没那么喜欢写代码的，或者说希望用一种更低的代码的方式，低代码的方式去使用这样的一个 Agent 的，对，可以去自定义这样的 Agent 能力的方式，所以说他就去提出 Skills 这样的一个定义，对吧？就是定义一堆文件的方式，对，所以说你看到 Skills 它其实是架构在 Cloudy Agent 这样的一个 SDK 这样的一个框架之上的，对，所以说我们可以把 Agent SDK 这个框架。  
[03:49] **伊笑：** 把它理解成是一个 Long Time，对，是一个真正的运行时，对，就像我们所有的开发语言一样。Skills 这个东西它是一个什么东西？它其实就是是一个基于文档的 user interface，对，它其实定义的是一个完全是靠文档来表达的这样的一个用户接口。那这样的话，这个门槛其实就会比直接通过代码的方式去调用Agent去执行Agent确实要简单很多很多，这个门槛要低很多很多了。所以说我觉得这更多的还是一次工程的进化，它不只是说是一个概念，是一个噱头的。我之前看到S Robotics的一个公开说法，好像是说行业不需要再去搞一大堆新的Agent了，啊，而只需要少量的核心Agent，然后再给他们挂上不同的Skills就可以满足需求。我去想了一下，我理解这样好像确实是更舒服一点。  
[04:43] **龟龟：** 因为 Agent 本身出现的目的就是为了领域特化嘛，但是 Agent 其实它有点重，就是它不光是说我在 Agent 里面塞了一些领域业务知识，那以前这些领域业务知识它可能是通过 system prompt 对吧塞进去的，那除了这些之外，它其实还会有一些比较重的实现，比如说我去跟不同领域的这个 MCP 对吧去跟它这个系统的 API 对接，它还不一定是通过 MCP，它可能是硬编码的。然后还有一些说，哎，我运行在不同的环境里面啊，或者说我在权限上会有不同的控制啊，包括我的 memory 的这个结构可能也会不一样之类的。它除了领域业务知识之外，它还会有这些乱七八糟的东西。那这个时候实际上你说，哎，我要去调整一下领域业务知识，或者说其实别的东西都差不多，但是我想要去做一些这个业务领域里面的子的事情的时候，我要去搞这个 agent 其实是比较麻烦的。那不好改，也不好维护，也不好复用，那这些都是问题。但实际上，skills这个概念其实就把领域知识这部分，业务知识这部分单独抽了出来，变成了一个呃比较方便修改和复用的一个能力包。就是一肖说的增加了一层抽象嘛，啊，它就是变成了等于说agent变成了一个runtime，具体怎么工作就交给了skills，skills其实提供了一个工作手册。  
[06:03] **龟龟：** 来做这个事情，啊，当然以前我们其实是也可以把这个业务知识，比如说 SOP 什么的写在 proposal 里面去给 agent 让它照着做，但 skills 把这部分就变成了一个稳定可复用的组件，然后基于这个 SDK 提供的标准，其实它还提供了一些比如说发现啊、动态加载啊、分层渐进加载之类的能力，那其实真实使用起来就会比说我每次都要把我的这个业务知识 copy 到这个 proposal 里面去就会方便非常多。理解这其实也是一种说我在实践中摸索出来的这个方法论，然后发现它确实是有效的，所以沉淀成了一个标准，是这么做出来的。  
[06:50] **主持人：** 我觉得反正这些实践挺多的啊，就他上次搞的那个MCP概念，我还没搞明白呢，这突然又来一个 agent skills，就我想问一下你们，就是 agent skills 跟 MCP 它是个什么关系？还有一个，我们以前不是还在讲说 ChatGPT 它提出了一个东西叫 function calling 对吧？还是叫什么 to call？啊，还有一个这玩意儿，就是这个又是个啥关系？能不能给我先科普一下这三个到底是啥关系？  
[07:18] **伊笑：** 在我的理解里啊，它们三个不能说完全没关系，但是确实是三个层次上的东西，就是这个 function call 或者说什么 to calling 的这个东西，它是在最底下的，它本身是说我给模型提供了一个调用外部 API 的能力，然后再往上才有了说 MCP。那 MCP 我们可以认为它是一个标准协议，来把一套外部的 API 暴露给模型去发现，让模型知道说哎，我有这些 API 是可以用的，在这个场景下，我可以用这个 API 去获取一些外部的数据啊，或者说去执行外部的一些代码。  
[07:42] **伊笑：** 然后再往上才是 skills，那 skills 的主体它其实是纯业务流程和知识，因为它就是个文档嘛，对吧？它是个 markdown，那里面其实描述的是说告诉模型怎么来完成一个完整任务的过程，可能是 step by step 的，说我先干什么再干什么，或者说我在干一些事情的时候我应该遵循一些什么样的标准，那其实是纯业务流程的知识。那在这个过程里面，模型去 follow 这个 skills 里面给的这个业务知识的时候，它仍然可以去通过 MCP 去发现 API，再通过这个 function call 去调用 API。啊，所以它其实是三个层次的，没有 skills 的话，其实模型也可以自由发挥去完成一个任务，你让它去做一件事儿。啊，那有 skills 的时候，它可能会遵循 skills 的这个流程去做，没有的时候，它就根据自己的理解，它也会去做 plan，对吧？现在的模型它也会去做 plan，它也会去生成一个计划表 to do list，然后一步一步去做，它也会去做啊，它也会去用 MCP，但 skills 就相当于说你手把手教模型应该先干什么，再干什么，怎么干啊，那。  
[08:42] **龟龟：** 啊，那其实我在看那个 skills 的这个文档一些实现的时候，如果我没理解错的话，实际上一个 skills 里面也是可以包含 MCP 的，还可以包含一些别的东西，比如说单独的脚本之类的。那这样才能让一个 skill 是完整的，就是我 skill 要去做什么事的时候，我可以带着一个 MCP 给到呃模型说，啊，那你做这件事情的时候，你就可以用到这个 MCP 里面的这个 API 对。  
[09:08] **主持人：** 对，skills 它确实它不简单说就是一个 prompt，只是一个 md 的文档，然后里面去描述我平时像写 prompt 这样干这件事情要怎么怎么干。但实际上就像刚才各位说的，它确实它可能里面还会加载很多很多的工具脚本，就你可以在本地写了很多的 bash 脚本是吧，shell 脚本，那个脚本可能是干什么什么什么事情的，那这些东西都可以注入到 skills 里面，最终去调用，对，这样才是一个完整的东西，这是 skills 的一个完整的定义吧？对，那我总结一下它们三者的关系的话，就是 skills 的你可以理解就是在最上层就是一个更大的集合，它里面是包含 MCP了，它可以调用MCP。好，MCP里面的一个子能力可能是TO CALLING，但MCP还可以干其他的事情，管理一些什么数据啊，乱七八糟的。所以说就是这样的一个包含关系吧。那是不是可以这么理解，在以前没有SKILLS的时候，大家看到那些MCP的那些收录的网站里面收录的很多MCP，它可能是一个SKILLS，可能大家的这个抽象概念在没有SKILLS的时候，大家没办法，就只能把它所有的东西都变成MCP，是这个逻辑吗？  
[10:22] **伊笑：** 我觉得严格来说不能这么说啊，就是我可以说 MCP 它是 Skill 的一个可选部分，但 Skill 的本体其实还是以前的那些 Prompt 啊。就它可能比如说我今天分享出来一个，我说我这个干一个什么事儿的非常有效的 Prompt，但是今天我们可以把它抽象成一个 Skills 啊，只不过这个 Skills 它其实也是有一些规范的，比如说它有这个 Front Matter 的这个 Meta Data 啊，他在写这个 Skills 的时候他需要说按照他的 L1 L2的结构去写，那但是本质上它还是一个去指导模型怎么去工作的一个prompt啊，只不过在这个里面我可以可选的加入一些能够让我这个prompt执行下去的一些外部能力啊，就比如说我加了MCP，加了一个可执行脚本，啊，加了一些别的子的这个流程的。  
[10:51] **伊笑：** 的马克档文件在里面其实是可以这么加进去的啊，所以我我我认为就是说 MCP 它可以是它的一个可选部分，但是它主体并不是这个 MCP 对，嗯，那我举一个例子吧，我觉得举一个我们自己的例子，比如说像在 Podwise 里面，假设用 Podwise 这种，假设现在有一期播客节目就是我们这一期播客节目，我说我需要给它给他总结一下他的 take away 或者他的关键点有哪些，就是说我可能希望就是有一个 skills 帮我干这件事儿，就是总结我们再去播个节目。但是呢你会发现总结这些播个节目有一个很大的问题，你得先拿到组织稿，拿到 transcript 对吧？那这个 transcript 这件事情它相对来说就比较重，可能现在大模型它都搞不定。那这个时候我们可能说，哎，我们刚好有一个 transcript 的服务，那我能不能把这个服务给它包装成一个工具，包装成一个 shell 脚本，那个 shell。  
[12:06] **伊笑：** 那个shell脚本本身是把一个播客的链接发送给这个transcribe服务，然后它最后给你返回一堆文字，返回这个transcribe那个工具就返回了。对，好，那然后这个时候这个skill的这个skills的这个prompt它可能哎就可以开始去开始去总结它的关键点了，所以说我在这里就是需要把转录逐字稿、音频转文字这件事情要给它封装成一个 MCP，或者说封装成一个其他的工具。对，这个时候 Skills 在完成总结这个任务的过程当中，它会自己去决策，哎，我需要去调用这个转录服务的 MCP。啊，转录完成过后才开始做接下来我们大家都理解的这个总结、takeaway 啊这些这些事情，对。  
[12:55] **龟龟：** 所以说它其实是这样的一个一个关系，对，所以说你可以理解有很多很多外部的任务，一些外部的任务，那些任务可能都是比较重的，或者说都是大模型它自己无法无法完成的一些任务，我们可能就通过一些 API，通过一些工具集啊这些方式去做这件事儿，大模型自己去使用这些工具就完事儿了。我想稍微展开一下，可能让大家比较好理解，就是我们确实可以提供一个 MCP 来直接完成从音频到总结的这么一个过程，对吧？因为我出逐字稿，然后我出 summary，然后我去出一些结构化的数据，我是可以直接提供一个 MCP 来干这个事儿的。但是这个 MCP 背后其实是一个 API，这个 API 背后有不同的模型一起完成了这件事情。  
[13:43] **龟龟：** 但今天我们也可以有一个 skills，我把拿逐字稿这件事情通过 MCP 完成，但是我把总结这件事情在我自己的模型这边完成，就是没错。对，这个 skills 其实是去描述你模型能做这些事情的这个过程。那以前我从 MCP，虽然一个 MCP 可以是那个力度的，它可以做同一件事情，但是实际上它是把这件事情托管给了 MCP 背后的那个模型去做。啊，你可以。啊，你可以说，哎，我这个MCP背后的模型它可能在API背后也隐藏着一个skill去做这个事情，你是不知道的啊。但是今天skills其实它是让自己的模型做这个事情，你是知道的，它是透明的，对，它是描述了一模型能做的事情，所以它确实可以一个skill可以和一个MCP做同样的事情，但是它概念上确实是不一样的，对，嗯。  
[14:31] **主持人：** 嗯，其实刚才哥哥也提到了一点，就是我们最早以前其实没有这些概念的时候啊，其实都是 prompt engineering 嘛，反正就是大模型加提示词，那提示词到底怎么组织什么东西的，其实可能大家没有概念嘛，对吧？那到现在，啊，Socratic 它有了 agent skills，然后有了 MCP，对吧？还有之前的 ChatGPT 的 function call，对吧？就这些乱七八。  
[14:53] **主持人：** 乱七八糟的这些逻辑出来了，我看之前就有人吐槽说说其实这些都是一堆 Markdown 文件嘛，你搞这么多概念干嘛？你们怎么看这种发展趋势？  
[15:18] **伊笑：** 对，其实就像一笑说的，多一层抽象解决一些问题啊。那那个对，乍一眼看这个 skills 的主体它确实就是一个 Markdown 文件，但实际上人家是有要求的，对吧？人家其实是有标准和规范在里面的。那比如说，呃，它的这个 front matter 的这个 meta data，它要求你去写 description，这个 description 是非常重要的，就是它是能够让 cloudy 它的这个 agent sdk 能够去正确的找到说，哎，当你一个自然语言描述进来一个需求的时候，我应该用哪个 skill 去处理，那这个就做到了。  
[15:39] **伊笑：** 动态加载的能力就不是说哎我要把一大堆的这个业务流程通过一个巨大的 prompt 灌进去，对吧？嗯，那对于上下文对于整个这个指令的遵循度来说其实都是有帮助，因为你减少了上下文长度嘛，你只是按需的去加载嘛。嗯，对，所以所以其实他他会在他的这个 trouble shooting 里面有提到说你一定要把这个 describing 写清楚啊，区分度写高，那这个其实是一个非常重要的事情，那通过这种。  
[16:06] **伊笑：** 抽象的标准它其实就提供了这个自动发现和动态加载的能力，那它就方便管理和复用啊，对吧？那它其实还提供了渐进加载的能力啊，因为单个 skill 文件夹里面其实除了这个主要的这个 md 文件之外，它可以去包含额外的脚本以及资源或者说一些子的说明文档啊，比如说去说明我要去填写的这个 form 的结构是什么啊，或者说我要去做一个子流程的时候，这个子流程应该是 step by step 是怎么做的，这些都只会在说我真正要去用到的时候才会读取。那这其实也能缓解上下文长度压力，因为我们知道其实很多时候你模型效果不佳，可能就是上下文太长了。  
[16:46] **伊笑：** 它可能执行了几个轮回之后，它超过整个上下文窗口了之后，它开始会遗忘嘛。那如果你能去缓解这个上下文长度压力，除了解放用户输入prompt的这个繁琐动作之外，也能够帮助模型去更好的工作。所以它其实本质上去做了一个工具化和标准化的一个事情。然后工具化和标准化，我觉得是提高生产效率的一个必然方式，对吧？你工业化其实就是要去做标准化，你才能够让整个大家的效率，不管是协作也好，还是它跑的这个效率也好，去提高嘛。啊，那做标准。  
[17:16] **伊笑：** 做标准化你肯定需要一个概念去承接嘛，至于它叫 skills 还是叫其他名字其实都不重要，只要它能让模型干活更高效，产出质量更高，让人的负担更小，啊，让人去更少的介入，那我觉得就是一个好东西。今天来看的话，skill 确实是，反正目前从概念上，因为我们其实还没有深度的去使用它，它出来也没太太久嘛，对，但是我们从这个理解上我觉得它确实是能够做到这些事情的，对，是一个比较好的抽象，嗯。  
[17:44] **龟龟：** 嗯，对，我想先聊另外一个点，就是聊吐槽这个点哈。其实真的确实有挺多工程师啊或者开发者看到这种概念就就喜欢吐槽，哎，觉得这个东西可能就是一堆 Markdown 的文档。但是我今天的看法就觉得啥呢？我觉得这种他能提出 skills 啊，提出 MCP 啊这些概念，我们就当它是一个概念哈，能提出这些概念的团队或者人，我觉得他们真的是除了会做工程以外，他们是真的会做产品的。  
[18:14] **龟龟：** 大家能理解这个东西吗？就是能定义这些东西的那些团队，他们是真的会做产品，他们可能是真的在思考产品这件事情，而不只是一个技术性的问题。其实放到我们中国团队，其实不太擅长干这件事儿，我们不太擅长命名这件事儿，不太。  
[18:32] **龟龟：** 不太擅长去定义一个标准，对，你可能做了一件很牛逼的技术，但是你最终放出来的还是那个技术本身。对，其实我们不太会去思考说这个技术能不能往上面再稍微走一步，那一步可能刚好是一个一个概念层，一个封装层，就可以让在市场上那种出圈啊、跨界啊，或者说被更多的人知道接受，就会更好的。我觉得这一点其实是一个很重要的一个一个一个东西，对，其实。  
[19:02] **龟龟：** 其实国外的那很多公司他们都非常擅长这些定标准啊，那些乱七八糟的。对，这个让我想起其实啥呢？比如说像 Docker 这件事情，在很多年前，其实阿里我们在阿里的时候，在 Docker 没出来之前，其实大家都在搞容器化技术这件事了，已经都搞得风生水起啊，并且都搞到生产环境。对，但是呢，大家没有去定义这个标准，没有去定义，那个时候其实在阿里都已经在做了一密集，就是 Docker 镜像这件事，只是说不是用这种标准化的方式去做，而是自己。  
[19:32] **龟龟：** 随便写一段代码比较土的方式能做做出镜像对，但是没有想到过这个东西它可以标准化，可以抽象成一个可以发布出来让所有的公司人都可以用的东西，你知道吗？就是说大家其实技术层面都实现了，都是那样实现的。嗯，我觉得这次确实是中国公司和海外的很多很多的团队在思考这种产品呢层面是，这特别就是技术型的产品层面是有很大的差距的，对。  
[20:00] **主持人：** 那回到这个问题本身哈，普通用户可能去接触到的就是一堆 Marko 当文档。那我想说的是，这就是那个 Anthropic 团队想要达成的目的啊，他就是想让普通用户就是只接触到一堆文档。那可能人家设计的意图就是说我交给用户的接口就是以文档的方式来驱动的这种接口，因为它本质是先有了一套技术，对吧？我们前面介绍过，那 Scale 它本身底层在驱动的是有一个框架层，对吧？可能人家有 Cloud Agent SDK 这样的框架层，这个是给开发者用的。那他们就向前面走了一步，觉得说光给开发者用可能还不够友好，是吧？我们最好定义另外的一套用户的接口来给。  
[20:40] **主持人：** 来给普通的用户去使用，对，所以说才有了靠文档的方式来驱动的 skills 的这个这个概念的出来。对，所以说我们要看到的是它不单纯真的只是一堆文件，那因为那个 cloud agent sdk，那它里面其实要做很多很多的事情，对吧？要做整个的推理、规划、执行，里面要涉及到很多 mcp 啊或者其他的 tool 的调用的管理等等等等，那这些东西其实都是已经在框架层、在 runtime 层已经实现完了，对。  
[21:10] **主持人：** 所以所以说我想说的是，嗯，对普通用户来说，单纯靠自己去写prompt要能够完成整个过程，自己不去开发这样的一个框架型的代码，我觉得还是真的是玩不转这样的一个东西的。对，我觉得skill的这个提出来，我看到了我觉得是另外一个很好的一个趋势，这个东西感觉真的是在AI这种智能时代过后，它是一种新的这种无代码和这种低代码的开发的方式。  
[21:37] **伊笑：** 对，我觉得至少今天我看到的，在这种轻应用的方向，用 Skill 的这种开发，确实达成了低代码嘛，也不说无代码，我觉得这也算是一种很低的代码，但是因为里面可能你有时候还会去写个封装一个简单的脚本啊之类的，但我觉得这种开发方式，我会把它称为是这个时代的低代码开发平台，对，嗯。  
[21:58] **龟龟：** 嗯，确实现在用 Web Coding 的 Agent 然后去做工具，你一次成型的概率其实还蛮高的。如果你只是一个简单工具啊，如果你是复杂工具的话，其实你自己 Web 个几天也能出得来。对，确实你把它叫做无代码、低代码其实也是 OK 的，就甚至你都不需要干什么，你让它帮你干都可以。对，你甚至不需要有那个工具，它也能帮你干得出来。  
[22:21] **龟龟：** 这个确实是一个挺挺大的一个变化。对，那我们回过头来聊聊自己吧，就是对于 Podwise 来说，因为我们其实也是从 prompt engineer 过来的嘛，对吧？就是我们也是各种各样的 prompt 去组织去抽象出来的。对，那现在的这个 skills 这个概念出来之后，就它这个抽象对于我们的工程化有没有什么帮助？我们可以从自己的实践来给大家分享一下。对。  
[22:45] **伊笑：** 对，这确实是我一直在思考的一个问题。我觉得 Podwise 今天其实在设计这个产品的时候，它有一个哲学，就是极度的简单。它的核心功能其实是没有人机交互的，就人其实是不需要参与播客总结的过程的，对我们只需要获取结果。  
[23:04] **伊笑：** 对，所以说这种无人机交互其实它是就没有人的个性化在里面，就不需要去处理用户的意图。所以说其实整个产品简单，其实相对来说它的流程也是偏简单的。对，所以今天的Podwise的这种核心的主流程其实Workflow加Prompt目前就是我们的最优解，就从可控性呢。  
[23:28] **伊笑：** 成本呐，就这些方面去综合的话，但是其实我们在某些方面可以做的更好，对，比如说我觉得我们之前就就在思考的，就我们可以将不同种类的播客的节目，能不能用不同的背景知识的方式去总结它。  
[23:49] **伊笑：** 对，比如说搞医疗的，对吧？那和AI科技的，那我相信他们在领域上是有非常非常大的差别的。我们完全不需要用一种模板去总结所有的播客的节目。那在这个情况下呢，我们就可以，哎，比如针对医疗类的播客的节目，我们可以给它封装一个skill，这个skill里面其实是专门用来处理这一类的节目，那这个skill它就可可以去加载很多医疗相关的。  
[24:18] **伊笑：** 背景的一些知识，当然可能不需要了，因为是总结嘛，可能他也不需要那么丰富复杂的知识，可能只是把这个领域的一些关键点啊，这些一些关键名词啊，这些可能就会让总结的会更好一点，一些关键人物啊之类的，对的。  
[24:34] **主持人：** 好，那这样的话，那我们最后再去执行的时候，就可以做到让不同的博客用使用不同的 skill 去做这件事情。对，啊，我觉得这反正是一个可以去提升、可以去探索的一个方向。对，但是呢。  
[24:51] **龟龟：** 但是呢，这个方向其实可以看得出来它的那种真正要发挥一个 skill 很复杂的动作，比如说我要开可以处理很多很多外部的操作，这些其实都是没有的。所以说它其实相对来说还是一个比较简单的 skill。在 product wise 上，我觉得还有另外一个方向，不单纯是说是产品的业务业务流程。那比如说今今天我们其实因为我们是小团队，那我们每个人其实都要去处理问题啊，要去运营那运维这个 product wise。  
[25:21] **龟龟：** 对，那其实我最近就在想，我每天可能有时候看到哪儿出了个错，我可能就要去查问题。那我查问题的流程是怎么样的？我可能要要到服务器上看一下日志，然后要到数据库里面去看一下那条数据的元数据长什么样子，然后又在那些代码上去去找一下，大概就是这三个方向，三个地方你可能都要去人肉去拔一下，对。  
[25:45] **龟龟：** 那其实如果我有能用skill这种方式去定义一个我自己的agent的话，那它就变成啥样子？我会把如何去数据库里面去查找元数据封装成一个工具，能够去日志文件里面去grep，如何去查看日志也给它封装成一个工具，对，然后把整个流程写成一个skill，我遇到什么问题，我能不能把这个问题就描述给它，它就根据我指导的流程，然后去巴拉巴拉把数据库查看一遍，把日志查看一遍，根据这些数据，然后最后再到代码里面去看一遍，哎，说不定就定位到大概你是是什么。  
[26:21] **龟龟：** 是什么问题，或者给我解释一下这个出现这个原因是怎么怎么样的？对，我觉得这就能够极大的其实解放个人的精力了，这就是完全是一个全自动化的一个流程，所以我觉得这个是特别好的，我觉得很多团队都需要，特别是大型团队啊，或者说一些更复杂的项目的团队这样，还有另。  
[26:41] **龟龟：** 还有另外一个点，其实你会发现，就是我们能用 scale 来实践的，都是不断的去想办法把我们日常工作里面手工反复做的那些事情给它自动化掉。那我其实平时还有一个手工，在 Podaway 上还有一个很手工的问题，就是我可能过段时间就会发现说，在某个播客呀，在某些节目上的总结效果达不到，我自己一眼看它的质量就很差，就达不到那个那种效果，我就会拿着那个播客的数据，然后去调。  
[27:11] **龟龟：** 某个环节的 prompt，首先拿到那个数据，然后再拿到那个 prompt，然后不断的去调试，啊，这个过程本身就是一个很繁琐的事情，对，要去组织数据，自己手工去组织数据的格式，然后最终再去把 prompt，比方可能我给它粘到就未来的 AI Studio 里面，在那里面去反复去调试调试，调试好了再把 prompt 复制回来，其实这个过程它也也挺麻烦，对，那我如果也可以用一个 skill 去封装的话，哎，我可以让这个 skill 经常。  
[27:39] **龟龟：** 经常去去拿到某个博客的数据，它就自动的能够去帮我去完成这个过程。我会指导他说：“你要这样去调试，那prompt是什么什么什么东西，你最后给我输出一个哎看上去是不是更好的prompt给我。”对，我觉得这些流程都是值得去提升的。  
[27:57] **龟龟：** 那当然，其实我想说的一个更关键点是啥呢？我觉得特别是对于小团队，如果团队里的每个人围绕自己团队的这些手动自动化的工作，大家都能够今天借用这些 skills 也好啊，或者其他的一些 AI 工具，让它完全的 AI 化，达到真正的自动化，那我觉得真的团队是可以做到。  
[28:19] **龟龟：** 真正的以一顶十啊，甚至顶百的这种战斗力的团队的，对，嗯，呃，我觉得一笑刚才有讲一个，如果Podwise去利用Skills的话会怎么用啊？他有讲说把播客节目按照不同的类型，然后去做总结做Skills啊，当然这是一种抽象方式嘛，那我今天我其实也想跟大家聊一下，就是一个比较艺术的问题啊，一个Skills到底应该有多大。  
[28:43] **主持人：** 因为astronomic其实给了一些事例啊，我自己体感上感觉都是中等力度啊，但是其实也没有标准嘛，而且可能也总结不出来到底这个中等力度是一个什么力度，什么力度应该是合适的力度，这个这个问题就非常的艺术。如果我们不谈这个很艺术的问题，我们就当下去聊podwise，就是。  
[29:02] **主持人：** 就是你们觉得说呃Podwise如果去应用Skills的话，它应该怎么切分比较合适？我们拿自己开个刀给大家举个例嘛。啊，当然我们现在也没有应用过啊，我们只是说如果我们要应用的话，我们可能会怎么办？我看到过一个说法啊。  
[29:17] **伊笑：** 那其实包括这个嗯，他自己的指导思想嗯，他是肯定不建议你这个 skills 太细的。那我看的那个说法是怎么说呢？他就说这件事你能叫出来名字啊，但是你要让别人去干的时候，他如果是个新人，你可能得给培训他一下午。  
[29:34] **伊笑：** 啊，就是他不能是说哎，我一句话就能讲清楚，即使你没干过，你也能干。但是呢，我一句话能告诉你，然后你知道说啊，这个事情要这么这么干，是因为我给你培训过，你才能干。他确实是个技能，但是呢，当这个人掌握了这个技能之后，我只要很简单的跟他说一句话，他就能做。  
[29:54] **伊笑：** 这就是一个比较合理的 skill，那它确实我觉得挺匹配这个名字的，就是它是一个被内化了的技能。然后呢，你能很简单的描述它，但是呢，它确实是有复杂度的，你需要去教人家，比如说 an s ropic 他自己举的这个几个例子，他内化的一些都是办公的嘛，对吧？PPT。  
[30:12] **伊笑：** Word啊、PDF，它的那几个 skills 都是这个。那你如果去拿它这个去套的话，就是哎，你把这个什么什么东西做成一个 PDF 啊，做成一个 PPT，或者说你去分析一下这个 Excel 里面的数据，这是一句话。嗯，但是背后说到底怎么去做这个 PPT，你对这个 PPT 有什么要求，或者说这个 Excel 怎么去分析数据是合理的，你可能是需要去交给那个人啊，你或者说他更小白一点，你甚至连怎么打开它、怎么编辑它都要去教他，那他就是一个合。  
[30:42] **伊笑：** 合适的 skill，他就通过这个 skill 变成了说我只需要跟大模型说一句话，我不需要把详细的我也我对他的要求啊，我对他的这个规范啊，对他步骤的一步步的都交给他，我就只需要去说一句话，然后他就可以把它做掉了。啊，那这就是一个合理的 skill 的力度。那如果说从这个力度来看，我认为 podwise 中对整个读字稿的结构化其实都可以是一个 skill 啊。  
[31:07] **伊笑：** 啊，当然你说我把单独的抽出来，每一个环节做一个 skill 可不可以？啊，我觉得也可以，但是不一定有必要啊。我自己的理解是不一定有必要。你你去想象一下，它就变成说我对这个大模型说，哎，你把这个节目用总结的 skill 去总结一下。  
[31:25] **伊笑：** 那我对它的期望，它就是会产出我所有要求的 summary 也好，outlines 也好，mind map 也好，它就都会产出出来，而且符合我的期望，因为我通过 skill 教过它。嗯嗯，对，所以整个结构化我觉得可以就可以是一个 skill，然后包括说翻译也可以是一个 skill。啊，你就告诉大模型说，把这个已经做好的通过翻译 skill 去翻译一下，那我也期望它给出我的结果是对照的翻译，就是。  
[31:51] **伊笑：** 就是原结构是怎么样的，那新结构就是怎么样。因为我在 skill 里面教过它，你翻译不能只去翻译文本，你要产出一个这样的结构，那它就可以是一个 skill。对，所以我理解就是这种比较大力度的业务其实做 skill 是合适的。对，嗯嗯，我今天去写 skill 的话，比如像个人本地的工作流。  
[32:11] **伊笑：** 我自己会倾向做的大一些，要做一件非常完整的事情。对，那比如就是我前面提到的，我要去运维整个 product，就是整个运维工作，它可能就是一个 skill。其实这个工作是非常大的，就并且它是一个你自己事先是无规则的，根本不知道会发生什么事情。对，因为我觉得运维工作这件事情特别合适。  
[32:35] **伊笑：** 用今天的AI agent，对，因为是线上可能会发生任何事情，有任何的用户问题，这个东西是完全是我们想象不到的。对，就这件整个事情，我觉得是写一个大的skill，是我觉得非常非常的合适，就针对我们Podwise这种产品的规模的力度来说。对，但是呢如果是像Podwise的整个AI生成的工作流程，那我会倾向于把它做小一点。对。  
[33:01] **伊笑：** 对，我会先还是倾向于保持现在，比如说它是一个完整的 workflow，对，这件事情是绝对可控的，并且是能控制成本的，是一个完全的 workflow。然后比如我要去总结 mind map 这样的一个力度，顾伟说的做一个翻译这样的一个事情，一个单节点的事情，哎。  
[33:21] **伊笑：** 哎，那我可能会倾向于把它写成一个 skill，但是整个 workflow 我不会倾向于说把 provide 的整个 workflow 用一个 skill 给它包含完，因为我知道这里面的稳定性一定会超乎我们的想象。  
[33:38] **伊笑：** 就一定会有那种来来回回达不成很多的标准，然后他不断的在那儿推理做新的规划，然后再去尝试，就里面有一个非常大的一个循环，这个循环跑起跑来跑的反正就是 token 嘛，对，一定是要烧很多很多的 token 在里面的，对。  
[33:56] **伊笑：** 就像我们平时在本地写代码一样，你看他，你告诉他一个问题，他可能要找很多很多轮，要循环很多很多很多很多次，哎，最终可能出来的结果还不一定对，但是有可能是对的，对。所以说这件事情是不可控的，对。所以说这是为什么我觉得说产品流程，如果你是一个确定性的产品流程，当然这个东西还是，比如像 Podwise 的 AI 的那个产品流程，它因为今天是一个高度确认性的产品流程，是没有人参与的，啊，但是 Podwise 的运维工作它是一个高度不确定性的产品流程，完全。  
[34:28] **伊笑：** 完全是靠人驱动的，今天这个用户会遇到这样的一个问题，我们自己可能也会发现碰到这样奇奇怪怪的问题的。所以这两种形态，我觉得今天做AI产品它的那种实践方法可能是不太一样的，但如果你要追求稳定性、性价比的话，对，对。  
[34:46] **龟龟：** 对，我觉得一笑提到了一点，就是稳定性跟性价比。如果我们要谈稳定性跟性价比的话，其实我们还要引入另外一个概念，就是我们今天讲agent还有workflow，对吧？因为agent呢，其实是我们是要跟它去做交互的嘛。那workflow其实刚才一笑有提到说，其实workflow是追求极致的稳定性的，对吧？因为。  
[35:05] **龟龟：** 对吧？因为 agent 呢其实并不能保证说百分百的稳定性，它可能会有一定的失败率，可能会不断的循环烧 token，性价比可能会有问题啊等等之类的。对，我觉得这一点就是我们去讲 workflow 跟 agent 本身的一个对比，我们之前其实也有讨论过。那刚才其实再去聊 podwise 怎么去做。  
[35:23] **龟龟：** 做 agent 就是怎么怎么做 agent skill 化的时候，其实大家的力度你可以看到也不太一样。但我自己刚才我们在起这个问题的时候，其实也有聊过，说其实这个事情是一个蛮艺术的问题，就跟我们最早以前去做业务啊去做微服务是一样的啊，八个人有八种微服务的做法，对吧？对，所以说我觉得这种相同公司的，比如说都是电商的项目，相同公司的不同的团队，他们抽象出来的电商的那些微服务的力度大小之类的可能也都会不一样，因为这个。  
[35:53] **龟龟：** 因为这个是一个仁者见仁智者见智的事情，甚至我们在最早以前做微服务的时候，大家的参考书籍就是DDD，但是你说真正有多少个人了解DDD啊？反正我也不知道，虽然大家看的都是DDD，那为什么做出来的服务不一样呢？对吧？就是这个事儿是一个挺艺术的问题。对，那我们既然都聊到Agent Skills了，刚才一校也提到Workflow了，那。  
[36:16] **主持人：** 那我就顺道再提一嘴啊，就是你看 workflow 现在好像就包括 define 啊，包括扣子啊，好像自从 agent skills 出来之后，甚至再往前倒一点，他们声量好像都变小了一点。但是我理解啊，skills 其实还是不解决这个确定性的问题的嘛，就就它本身其实只是一种抽象形式嘛。然后如果说我的 skills 多了之后，它的调用成功率其实可能还是会下降的，跟以前一样，跟以前不管我用 mcp 也好，做 blue calling 也好，它可能都会有调用成功率的问题。但是假如我的观察是没问题的，也就是说现在像 define 像扣子它们的声量都稍微小了一些，是不是其实是意味着说是大模型的进步导致了。  
[36:56] **主持人：** 大家用 agent 这种形式上升了，而不是说哎我因为有了 skills 然后我就不用 workflow 了，就跟这个是没关系的，是不是这样？  
[37:07] **伊笑：** 怎么说呢？我觉得 workflow 它是一个比较重的东西，你要去把这个 workflow 用好，它其实还挺难的，你要去学它。但是你像 skills 这样的，它就是一个 markdown，你要去写一写，相对来说其实门槛是要低很多。但是以前我们没办法，我们必须去用 workflow 是因为我的纯粹的一个 prompt 可能它就是。  
[37:24] **伊笑：** 准确率上是不够的，而且我要去做一些外部的模型的调用的时候，你从 MCP 也好，你是一些什么别的方式也好，其实它的稳定性也是很差的。但是 Work Flow 我可以非常明确的去产出这个这个过程。  
[37:40] **伊笑：** 那今天skills，你说它是不是纯粹是大模型的进步导致了这个准确率的上升？我觉得也不尽然，就是那个agent SDK的存在，然后包括这个skills它自己的这个规范，其实是能够去提高这个准确率和命中率的。  
[37:58] **伊笑：** 举个例子来说，就是 skills 的它这个 front matter 的这个 description 是会被那个 agent sdk 去预加载的嘛？那这个东西其实就是去保证它的命中率匹配度的一个首要的一个条件。那其实我们去看 agent skills 的文档中的 troubleshooting 的部分的时候，会发现有两个问题。  
[38:19] **伊笑：** 提到了一个是skill not triggering，就是它没有被触发，还有一个说multiple skills complicate，呃冲突了。那它本质上其实都是我的description可能没有写清楚，没有保证足够的区分度。那在这种情况下，其实像你提到说，哎，我skill多了之后是不是会，会命中率会下降，确实是有可能的。但是它其实还提供了一些别的方式，比如说我在自然语言中明确的点名，哎，我就是要用哪个名字的skill去做这件事情。  
[38:47] **伊笑：** 啊，然后或者说我干脆用斜杠 skill name 来显示的去去调用也是可以的。啊，那其实这两种方式就是提供了两种使用场景，我觉得一个是对这个 skill 的存在不知情的这一类终端用户，啊，就是你可能说你封装了一个产品，你在背后用了很多 skill，但是真正用你的这个呃。  
[39:09] **伊笑：** App去交流的时候，他是不知道这个skills的。那你通过把description去组织好，你就可以去服务这些终端用户。但是呢，如果说我们自己去用的时候，我其实对这个环境里面的存在的skills是非常了解的啊，每个skills能干什么事情，适合什么场景去使用是非常了解的。那我也完全可以用显示的方式去把这个命中率提高到，我不知道能不能到百分之一百啊，但是我觉得应该是能提高到一个比较高的程度的。对，但是这其实不能完全的解决掉说我的workflow这个层层面的准确性，因为你的skills终究它是一个promote。  
[39:46] **伊笑：** 你不能确保说他的这prompt你step by step的去描述完了之后，他一定能够做到像workflow那样的一步一步精准的执行，这个我觉得也不一定。对，嗯，今天回到聊agent。  
[40:00] **龟龟：** 就 skills 其实它本身是个 agent，对，它本身就说是 agent 的方式在运行，它不是 workflow 的方式在运行。所以当我们去讨论 agent 的时候，其实我更倾向的它肯定是无规则的，就是完全是无规则运行，就不像 workflow，workflow 是强规则运行嘛，是完全是靠我人定义的，你今天第一步干啥，第二步干啥，第三步干啥，对对对。所以说对 agent 来说，我其实一定是要让它变成无规则运行，能够让 AI 智能自己去决策如何。  
[40:30] **龟龟：** 测如何运行？那这肯定才能够去突破AI智能的那个上限，就因为Workflow的那个智能上限是有限的嘛，我们经常嗯会会会觉得这件事情对，但是Agent的那个智能的上限是要更高，特别是随着模型升级，可能那个智能上限会越来越高，对，所以说回到。  
[40:51] **龟龟：** 回到写 skills，像刚才呃龟龟提到的那种写 skills 啊，其实虽然说 skills 它可能提供了一些写死的规则，说指定这种场景用 tool 啊或者工具怎么执行的方式方法，我觉得这是一种兜底的方式，但它其实和本质 agent 驱动的方向可能就不是那真正大家鼓励的方向了已经，对，它其实也引入了规则了已经，对，这儿我其实单纯只是聊一下 agent 的这个无规则能带来更高的上限这件事情，可能是所有做 agent 的人在意识里面。  
[41:23] **龟龟：** 更需要去注意的一个方向。嗯，那我回到这个问题的话，就是说这一次关于这种进步是不是模型智能在进步？那我我自己是肯定非常倾向于模型在进步的。对，当然刚才龟龟讲了很多，比如去如何去写prompt，如何去写skill，把它们写的很清楚啊，这些东西都是最佳实践，这些最佳实践可以让模型执行的更好。对，这些是完全是没问题的。对，但是。  
[41:50] **龟龟：** 但是本质上我们去看这一次AI智能的进步，它其实本质上特别是在Agent智能上的进步，肯定是模型有巨大的关系的。那比如说像我们常用的模型，像Gemini，那今天我如果用Gemini二点零，特别是当你用二点零Flash啊这样的模型去驱动Agent的时候。  
[42:08] **龟龟：** 你会发现可能驱动不动了，可能就会发现就会有巨大的问题。对，你必须要上到Gemini三，甚至是三Pro呀之类的模型。我们今天用的很多，特别是抠顶的A镜头用的很爽的原因，其实就是因为跑的都是顶级模型的。嗯，所以说这个是一定的，对没？  
[42:28] **龟龟：** 对，没有这些现在的顶级模型，我觉得今天这种完全无规则的，把所有的能够真正去驱动一个用户的意图的这样的一个agent，就是用户可以提出任何问题，然后最终都能够给他出跑出一个还不错的结果的这样的agent。哎。  
[42:46] **龟龟：** 哎，我觉得没有顶级的模型今天可能很难很难。对，然后我们也可以看到最近其实这些模型的优化方向真的在转向了，可能在去年大家还在做很多的，比如Chatbot的方向，如何让生成的文本的质量更高，啊，然后后面又开始走了一波推理的模型的方向，然后最近这些模型又开始在在推理上主打。  
[43:09] **龟龟：** 主打agent的方向，比如像Kimble前一段时间发的K two，DeepSeek前段时间发的V三点二，这些其实它们的优化的重点都是在如何让agent的整个规划、推理、执行这条链路上更稳定做。  
[43:26] **龟龟：** 做的更好，对对，确实我们看到最近这些模型的方向可能主打都是agent的这个方向了，但我自己也在想一个问题，就是这个agent skills会不会是这些大模型厂商的一个阳谋啊？我发布了这个skills之后，然后我利用开源社区，然后我让大家一起贡献这些专业的领域知识，啊，然后我再把合适的内容放到后期的IOM的这个发布中来。  
[43:50] **龟龟：** 啊，举个例子啊，比如说以前所有的大模型可能都不能生成 PDF，啊，那你现在贡献了一个 PDF 的一个 skills，然后我我就把这个 PDF 然后拉到我的这个里面来，那下次你再用我 LM Chatbot 然后再聊的时候，你可以说哎，帮我把这段文字生成一个新的 PDF 啊，然后你可能就下载下来了，啊，这这是我举的一个例子啊，对，然后。  
[44:12] **龟龟：** 然后我就想类比什么事情呢？呃，有点像 Linux 操作系统，对，但 Linux 操作系统其实它分成两个部分嘛，嗯，有内核还有用户态嘛，对，那其实 LLM 的 chatbot 它其实就可能相当于说我一个裸的内核，然后上面加一个 shell，这个 shell 就是你跟它沟通的嘛，但是这个 shell 里边没有工具，啊，就是只有说你能够跟这个操作系统沟通，比如说你去对话，你跟他聊，假如说。  
[44:35] **龟龟：** 假如说未来他自己发布的这个大模型的这个产品添加了很多很多的 skills，那这个 skills 可能你可以把它理解成为它是一个 Ubuntu 或者一个 macOS 或者一个 Windows 十一啊，但可能不会有 Windows 十一那么大，但反正就类似于如果我未来是发布这种产品而不是发布一个裸的内核的话，就是我不是 Linux，Linux 只管发布内核对吧？其实我是我是发布产品的，对，那我里面可能就会带这些 GNU 以前的那些产品，比如说什么 bash 啊、iOS 啊、mv 啊、cp 啊等等这些工具，可能未来都会集成到这个大模型里面去。对，会不会未来变成这样子，就是其实大家贡献了一波，因为都是开源的嘛，然后可能举个例子可能还都是 MIT 协议的，然后这些大屏厂商可能全部都拉进来了，我自己筛选一下，啊，我用这些这些这些这几个 skills，然后帮我封装成一个操作系统，然后我来发布。对。  
[45:25] **伊笑：** 对，我为什么会有这个想法，是因为呃，ChatGPT前两天啊就不是推出了一个健康版本，就叫ChatGPT Health。啊，我估计它未来可能还会有很多，比如说它会推出ChatGPT律师版、ChatGPT历史版啊等等之类的。当然这里边肯定它既然能推出健康版，我相信它里边肯定会有一些健康的专业知识是从大模型里面特化出来。  
[45:47] **伊笑：** 对，我不知道这件事你们怎么看？嗯，我在想这个事儿，你这个例子就是因为像 bash 也好，ls 好，其实它本质上是一个，虽然是一个命令行工具，但它其实本质上也是一个 app，我其实是可以装的，虽然有一些是内化在里面，但实际上我是可以装的，对吧？我我觉得这个 ls 不好，我也可以去装一个新的 ls，所以我会觉得说它 skill 其实有点像一个 app，它是专门去做一个事情的 app。  
[46:12] **伊笑：** 那你把那个大模型比作那个操作系统，我觉得可以把skill去比相比作一个app，那它不一定要被内化到一个大模型里面，因为我觉得skill它提供的是领域知识，是业务知识，然后嗯，它其实是有个性化的，就是我的这个大模型可以去拥有一些常识，拥有一些科学知识，对吧？  
[46:35] **伊笑：** 拥有一些大家都认为没有问题的客观的知识，但是业务知识它其实和这些不一样，它是会持续的去去迭代去优化的，包括不同的用户他会有他自己的习惯，嗯，对吧？就同样去做一件事情，哎，我觉得我自己的这个工作的流程效率更高，准确度更高，那我去做Anthropic他自己的那个做PDF的那个。  
[47:01] **伊笑：** 不好啊，我就自己去写了一个 skill 去做 PDF，我觉得这自己这个更好，所以它其实是需要被个性化的，对，所以它可能可以被内化到里面，但是它可能更多的还是说我有一个大的生态啊，大家可以说我去做一个大的 skill 的一个 market place，然后你愿意分享也好，或者说你自己去做了你自己的 skill 也好，就把它灌到这个模型里面去用，在我理解里面它会是一个这样的东西，因为 skill 它其实更多还是在。  
[47:28] **伊笑：** 在现在的 prompt 这个层面上的一个事情，它是用来控制规范 LLM 的行为的，它是给 LLM 定标准的那部分的这个层次的一个抽象。对，所以它能很大程度上去解决这个 prompt 难写难维护的问题，然后让 LLM 更好用。我理解它也可以让我们去在上层封装产品也更容易，最终也能够去惠及到普通的这个终端用户。  
[47:55] **主持人：** 啊，那这个对 LLM 整体就是一个好事儿。然后我觉得现在就是看竞争对手们去怎么跟进这个东西了。嗯，嗯，对，我们确实太阴谋论了哈，可能。就是说虽然这个逻辑看上去是成立的哈，对，每个人都在提供专业知识，好像大模型是不是就可以把这一波专业知识给学一遍，对吧？至少大模型可以发现，哎，这哥们儿呢写的这个 skill 的这个专业知识好像产出来的结果就是要更好一些，那我是不是把它给内化掉了？对，就是如果大模型要做这件事儿，从我的认知的角度，它肯定是可以做到的，对。就像龟龟说的，它会不会去做这件事儿，那是另外一件事情了，对，这个可能对我们来说可能太阴谋论了，对。但是总。  
[48:39] **主持人：** 但是总的来说怎么说呢，大模型公司用它的用户产生的数据，比如就是用它的prompt，然后最后生成的结果，然后拿去再继续训练大模型，那这件事情肯定在在过去是是一个共识，比如就是像Gemini就是公开这样说的，对吧？你如果不是付费用户，是免费用户，那我们就是会用你的整个对话数据，整个过程数据，然后去继续去训练他们的下一代模型啊这些，对。那其实skill这儿本质，用归归刚才介绍的本质就是prompt嘛，那它本质也就是一些输入输出的整个过程数据，对。那这个数据它会不会拿去用来训训练它的后面的模型，那其实我们也是根本就不会知道这件事儿的，对，哪怕就像。  
[49:22] **主持人：** 啊，像就美来一样承诺你付费用户我就不会训练了，那其实谁知道呢，对吧？对，反正我们也不知道，对，我所以说我觉得这个问题其实不重要，但只是说从逻辑上来说它是它也是可行的，对。但这个不，刚才赛道不是提到那个 Chat GPT 不是推出了一个健康版嘛，一个 Healthcare 的版本，今天刚好就不就看到了那个 OpenAI Chat GPT 收购了一个叫 Torch 的 App 的团队。  
[49:49] **主持人：** 那个土耳其的团队只干了六个月，好像只他们只干了六个月，产品还没出来，还在 beta。然后四个人干了六个月，这个就是一个做 health 的，对，所以说他们为什么收购他，我觉得可能可能也不单纯说 chat g p 推出 health 就只是因为他自己，嗯。  
[50:06] **主持人：** 嗯，模型训练了黑尔C，所以说他就可以做出一个黑尔C的产品。那他看看出他今天还是在通过收购一些外部团队的专业团队的方式来去达成他的整个的这样的一个布局的一个战略的生态吧。对，这个Tart就是专门做黑尔C的，对，嗯，然后四个人干了六个月，现在用一亿美金给他买走了，对，就是然后产。  
[50:29] **主持人：** 然后产品还没上线呢，还在 beta。对对对，所以说其实我想说，可能对于这些公司来说，大家去做 skill 也好，还有一种方式是你的 skill 做的很好很好，你的那个 skill 产品在它的生态里面跑的很好很好，说不定模型公司要把你收了也是有可能的，它不一定说就是把你给内化掉，把你给吃掉了，对吧？嗯，对我们可能想的好一点就是这个样子的，对，嗯，对对对对对，是的，对。  
[50:58] **主持人：** 对，我觉得今天我们讨论的这个 skills，我们也不是说给大家一个终极解决方案，就是你的 skills 就应该用什么样的力度，然后去怎么去写，写成什么样子。对，因为这个东西在提出来之后，我觉得 anthropic 它也不能说把每一个业务领域里边这个 agent skills 它应该是什么力度给大家讲明白，这个事儿可能都是你自己探索出来的，而且如果你自己有业务领域知识的话，可能你能分出来更好的 skill，对吧？  
[51:24] **主持人：** 对吧？但是也不一定，你可能还需要有一些软件工程领域的知识，然后你去交叉一下，对吧？你才能够可能做出来一个比较工程加业务啊都比较好的一种方式。但是我是觉得说 skills 确实提供了一种新的组织 AI 的方式，它其实解决的是怎么描述问题嘛，但它其实解决不了说怎么能够保证这个效果更好，那这个东西还可能还是要去你去 tweak 模型啊，去搞你的 prompt 对吧？还是要把这个事儿还要去搞起来，对。  
[51:51] **主持人：** 然后真正这个 agent skill 为什么这套东西能够起来？我觉得本身可能还是模型能力的提升嘛，包括我用 Gemini 三 Pro，包括我用 Cloud 最新的这个模型，其实效果上面确实差距很大。你在 Open Code 里边，你用 Cloud 去做。  
[52:08] **主持人：** 做Web coding跟你用什么Mini Max的模型啊，然后那个智谱的模型啊，那它的效果就是有巨大的差异。对，那这个大家得承认这件事儿嘛，对吧？至于说Skills这个事儿会不会成为LLM厂商的一个开源阳谋啊，就是比如说让社区贡献知识，然后最后反哺模型啊，当然可能性是存在的，我们讲说刚才有阴谋论的部分嘛，对，但是有没有可能比如说Minus现在他在做的一个事儿就是其实它算是一个Office，对吧？  
[52:36] **主持人：** 对吧？我有 Linux，然后我有 Office，嗯，对吧？那会不会未来其实大模型的这个聊天端它可能就变成了一个 Office，对吧？就大家可能把什么做 PPT 啊，然后什么做做 Excel 啊这些东西可能默认都放到了 Chatbot 里，对吧？可能把 Manus 的一部分东西内化成了 Skills，对吧？我感觉可能性也是存在的。对，那我们今天只是讨论这个可能性嘛。我觉得就是 Skills 这个事儿你换个角度看，它其实是能加速整个行业工程化进程的，你未来的 AI 应用可以更规范、更高效，我觉得这也是一个挺好的一个事儿。那我们本期节目就先到这里吧，啊，欢迎大家在评论区下方给我们留言讨论，那我们下期再见吧，拜拜。  
[53:16] **全体：** 好，拜拜。以上就是我们本期播客的全部内容，感谢大家收听，也欢迎大家踊跃留言。如果你喜欢我们，欢迎点赞并分享给感兴趣的朋友。如果你在用苹果播客收听，也希望你花几秒钟给我们一个好评，这会让更多的人了解到我们。要是能再点击一下订阅，那就再好不过了。我们下周见。