claudeagent开发教程

你很有可能没有充分发挥你的 ai 编程助手的全部潜力，所以现在我想和你一起变得非常实用，向你展示一些顶级智能体工程师在 ai 编程中使用的最佳技巧。 这些人真正建立了与他们的编程智能体，比如 cloud code， hero 或 cursor 协助的系统。因此，我在这里假设你至少对如何使用编程智能体有基本的了解，因为接下来我想为你具体介绍一些真正强大的解锁技巧。 在这里，我的讲解会非常简明扼要，不会浪费你的任何时间。而且最棒的是，这一切都不需要任何新工具，这其实只是更高效的工作方式而已。好吧，那我们开始吧。 在这里，排在首位的是 prd， 优先开发。 prd 是 产品需求文档 product requirement document 的 缩写。这个词可以有很多不同的含义， 但在这里，它指的是一个 markdown 文档，是用来定义你项目全部工作范围的唯一场所。因此，对于从零开始的全新开发，这份文档通常包含了你需要构建的所有内容，已完成你的概念验证 poc 或最小可行产品 mvp。 而这份文档的美妙之处在于，它成为了你的编码代理的指引之星，里面包含了你需要构建的一切。因此，从 prd 中，你可以获得所有要和编码代理一起实现的具体功能。 重要的是，不要让你的编码代理一次做太多事情，否则它会彻底崩溃。所以，你可以利用 prd 将你的项目拆分为更细致的功能，比如实现 api， 实现用户界面，构建认证系统，你可以像这样把它们分开。 而对于综地开发，如果你是在已有的代码库上工作，与其说是记录你项目中已经有的内容，以及你接下来想要构建的部分， 但无论哪种方式，你都在为你的项目创建指引之星。很多人都会忽略这一点，他们直接跳进去开发第一个功能，但实际上，他们在与自己的编码助手进行不同迭代时，并没有建立起任何联系。 为了演示本视频中含盖的所有技巧，我准备了一个 github 仓库链接会放在视频描述中。 在这个仓库里，我搭建了一个非常基础的演示项目，同时也包含了我在这里讲到的所有命令。 所以我日常用于 ai 编程的所有工作流程都已经为你整理好了。这些就是我每天都会用到的核心斜杠命令。其中有一个命令就和我们刚才讨论的内容有关， 我为你搭建了一个完整的工作流程，帮助你创建 prd。 现在切换到本地的仓库，我已经把所有命令都放在了 cloud commands 文件夹里供你使用。顺便说一下，你可以把这些命令用于任何 ai 编程助手。不仅仅是 cloud code， 它们其实就是定义这些工作流程的提示词。 所以我就在这里为你准备了创建 prd 命令。整个流程的核心就是你可以和 ai 编程助手对话， 讨论你想要构建的内容，对吧？比如说，我想要开发 x y z， 帮我规划一下。一旦你和编程助手就你想要创建的内容达成一致，在对话中，你只需要运行 create prd， 它就会把整个工作范围输出到你在这里指定的文档中。 所以对于这个简单的习惯追踪应用来说，这就是我的 prd。 这些部分全部都是在命令中定义的模板的一部分，比如目标用户你的使命包含的内容，不包含的内容，你还可以在这里看到完整的架构布局， 这就是你现在的北极星指引。所以在此之后，你进行的所有功能开发都将参考这个 prd， 并借助你的编程助手来确定要构建什么。 在我的 ai 开发工作流中，我总会用到的另一个命令是 prime 命令。我会在每次新对话开始时运行这个命令，把项目中所有必要的上下文加载进来。 而 prd 是 我始终确保我的助手阅读的核心文件之一。因为在他对代码库进行预处理之后，我就可以直接问，根据 prd 我 们接下来应该构建什么。 这个问题我每天都会问，因为我正在向你展示我无论在开发什么项目时都会用到的工作流程，而且无论我在处理哪个代码库，这一点都不会改变。 好的，接下来你需要理解的一个重要概念是模块化规则架构。因为情况是这样的，大多数人把他们的大局规则写的太长了。请记住，这些规则是你在每次与编码助手对话开始时加载到上下文中的约束和规范。 所以如果这些规则不够精简，你就会因为规则太多而让大语言模型难以应对。因此，无论你的局规则文件是 agent md 还是 cloud md， 你 都应该让它尽量简短，并专注于那些无论你在做什么项目都适用的规则， 比如要运行的命令，你的测试策略、日制记录策略之类的内容。但当你只是在处理前端工作时，比如你专注于组建的规则，或者你在做部署构建应用的 api， 这时你应该把针对不同任务类型的规则拆分成不同的 markdown 文档， 并让你的主局规则文件去引用这些文档。这样只有在你处理真正适用于这些规则的任务时，才会把这些规则加载到大语言模型的上下文中。好的，回到我们这个非常实用的习惯追踪应用，我想给你展示一下这些规则可能是什么样子的。 我现在用的是 cloud code， 所以 cloud md 是 我的局规则文件，而且我把它做的非常简洁， 你可以看到我的规则文件甚至还不到两百行。但其实我在 cloud reference 文件夹里有更多的上下文内容，我马上就会给你展示这些内容。但在这里，我列出的是无论我在做什么项目都很关心的内容。 比如我的技术站，我希望我的编码代理能够了解项目结构，这样它就能更好地导航项目。还有我们用来运行前端和后端的命令，比如 m c p 服务器代码规范，我的日制标准。记住 这些内容真的是，无论我在做什么类型的功能，我都希望 lm 能够了解这些信息。但这里有一个关键点，就在这里，我有一个参考部分， 这里是我引用特定任务类型上下文的地方。这些内容我只想在某些类型的功能中加载，因此因为这些路径被加载到我们的全局规则中，编码代理就会明白。好吧，当我在构建 api 端点时，这就是我应该阅读这个文件的时候。 所以我把这些全部放在我的代码库的 reference 文件夹里。这里有更多的上下文信息，比如仅仅这个文档就接近一千行，而且很多文档都是这样。因为在这里我们会非常具体的写下我们的指令，并且我们可以让它变得更长，因为只有在我们真正处理 api 时才会读取它。 因此，在你的大局规则中设置这个参考部分是让你的规则保持简洁，同时又能拥有所需全部上下文的非常强大的方法， 目标是保护你的编码代理的上下文窗口。很多人都严重低估了这一点的重要性。你也可以在你的指令中引用这些文档。比如，你可能已经建立了一个用于构建 api 端点的工作流程，所以你其实不需要在这里引用它，只需要在你的某个指令中给出路径即可。 所以无论用什么方法，都要确保你能获得所需的全部上下文信息，但又不是一开始就全部加载。接下来我要介绍的技巧可能是所有技巧中最显而易见的，但它非常重要。我必须确保你始终牢记这一点。 你应该把一切都命令化。如果这个词真的存在的话，基本上只要你向你的编码代理发送同样的提示超过两次，这就应该提醒你，这是一个将其转化为命令或可附用工作流的机会。 这些其实就是 markdown 文档，我们把它们作为上下文加载进来，用来为我们的编码代理定义一个流程。 所以当你提交 get， 进行代码审查，或者从你的代码库中加载上下文时，几乎你在开发流程中能做的任何事情都可以被转化为命令。因为随着你不断使用，它会为你节省成千上万次的敲击键盘。你也可以像我现在为你做的这样，把这些工作流程分享给其他人。 回到习惯追踪器的代码库，就像我之前说的，我把我日常使用的所有核心命令都记录在这里，并包含在这个仓库里。 所以你可以随意把这些命令拿去用，并根据自己的需求进行定制。所以几乎所有我发现自己用过两次以上的提示，我都打包成了一个工作流程，放在这里你都可以随意使用。比如提交 git， 像我们之前看到的那样，创建 prd 我核心功能，开发流程中的所有内容，比如执行规划，预处理所有的验证命令，甚至还有一些关于系统引进的命令。稍后我们也会谈到。好的，接下来我要介绍的技巧同样与上下文管理有关。 如果你还没有注意到，这其实是与编码代理合作时非常关键的一个环节，所以这里我们要讲的是上下文重置。我的意思是，在你进行规划和实际编辑代码之间，你应该始终重新开启与编码代理的对话窗口。 而你之所以能够这样做，唯一的原因是你总是在规划环节结束时输出一份文档，通常是一份 markdown 文档， 而这份文档包含了你在执行阶段所需的全部上下文信息。所以我们不会做任何预设，也不会告诉编码代理我们想要构建什么。当我们开始构建解决方案，也就是下一个功能时，我们只需要把这份文档提供给他。 就是这样，我们之所以要这样做，是因为我们希望在实际编码时尽量保持上下文的简洁，这样可以为代理留出更多空间去推理他正在做的事情，进行自我验证，以及完成所有这些重要的工作。 接下来我会演示一下使用我在代码库中为你准备的命令这个过程是什么样的。所以我们总是用 prime 命令开始我们的规划，这样我们就能了解代码库里有什么，然后再和我们的编码代理进行对话，确定接下来要构建什么。 同样基于我们的 p r d 接下来最合理的功能是什么。所以我没有在这里演示整个过程。我直接进入了下一个命令，也就是创建我们的结构化计划。这是我们将要输出的 markdown 文档，我们会用它作为执行时的上下文。 所以在这里我会直接输入 clear， 彻底清空上下文窗口，或者你也可以直接重启你的编码代理。 然后我会调用 execute 命令，这个命令的参数就是我希望他读取的那个计划，这就是他所需要的全部上下文。所以我很快给你演示一下。比如在这个习惯追踪器的简单演示中，我们正在改进日历的视觉效果， 所以这里概述了功能描述，用户故事以及所有高层次的信息，所有可以参考的上下文，还有我们需要构建的各个组建以及逐项的任务分解。像这样非常全面，因为在这里执行计划时，我们没有向代理加载任何其他上下文。现在信不信由你。 我实际上把最重要的技巧留到了最后，因为接下来我们要讲的是系统进化。当你把每一个 bug 都当做让你的编码代理变得更强的机会时，这就是使用编码代理最强大的方式。 所以，与其只是遇到一个 bug， 然后手动修复并继续前进，我们实际上会在编码代理的系统中深入查找我们应该修复什么，才能让这个问题不再发生。当你发现你的编码代理一次又一次的出现同样的问题时，看到这种模式的出现，这种方法尤其强大。 所以通常当你思考可以在系统中修复什么时，要么是你的全剧规则，要么是我们之前提到的其他任何类型的参考上下文，或者是你的命令，也就是工作流。 这里会有一个可以改进的机会，因为当编码代理在某些地方出错时，很可能是他没有理解你想要指定的某条规则，或者是你的验证流程中有某个环节可以做得更好。 所以仅举几个例子，我这里有几个例子。如果编码代理使用了错误的导入风格，那么你就需要添加一条新规则，对吧？比如，你只需要用一句话简单说明一下应该是什么样子， 而且很多时候，这真的只需要一句话就够了。如果 ai 忘记运行测试，你只需要更新你的结构化计划模板，也就是输入到执行环节的内容，加入新的测试部分就可以了。 如果编码代理不理解认证流程，那么你就可以创建一个新的参考文档，并且更新你的大局规则。在处理认证相关工作时，应该参考这份文档，就像我们刚才展示的那样。 所以最终其实有无数种方式可以让我们和编码代理一起进入系统改进模式。但通常你会在刚刚完成一个功能，并且自己验证过之后立刻进行这一步。 你会注意到应用程序的某些地方运行不正确，或者代码中有些问题，然后你就会说，嘿， cloud。 我 发现应用程序里的 x、 y、 z 没有正常工作，所以我做了这个修复。 我希望你现在去查看规则，阅读我们这里用到的所有命令，然后帮我找出我们在流程或规则上可以改进的地方，这样这个问题就不会再发生了。 当然，这有点过于简化了，你可以看到我用语音转文字工具把这段输入到这里，但你大致明白我的意思， 你让他进行更多自我反思，思考实际执行和计划之间的对比，和我们制定的规则流程相比，有哪些不同，有哪些差异是我们可以解决的，这样这些 bug 就 不会再次出现。 所以我在这里对策略的定义非常宽泛，因为实际上这更像是一种我希望你能采纳的思维方式，不要只是修复 bug， 更要修复导致 bug 出现的系统。这样做会让你受益匪浅，因为你的编码代理会随着时间变得更强大，更可靠。就是这样， 这些就是我最喜欢的所有顶尖智能体工程师都会用到的技巧。正如我之前所说，我会在描述中附上包含所有命令的仓库链接，以及这张图表的下载链接，方便你自行下载。 如果你喜欢这个视频，并且期待更多关于智能体工程的内容，非常欢迎你点赞和订阅，我们下个视频再见。

两百行代码能写出 cloud code 吗？能，社区有人证明了，一个 while 循环几个工具，调用核心功能就能跑起来。但这就像说两个轮子就能造出特斯拉， 能跑和能用是两码事。大家好，这里是 l l m x factors， 一个专注于拆解大语言模型时代底层逻辑的频道。 今天我们来拆一个问题，同样的模型放进 cloud code 里，效果为什么就是比自己写得好？这背后的差距不再。代码量在三个容易被忽略的地方，我们先看第一个 踢斗系统。有人做了个实验，把 cloud code 的 秃斗功能关掉，结果任务完成，效果直接掉了一到两个档次。注意，不是换模型，不是改算法， 只是关掉秃斗。为什么一个看起来很笨的功能这么重要？因为大语言模型有个天性，它喜欢提前宣布胜利， 你让他做十步，他做到第三步，可能就说好了，完成了 t o d o 系统就是防止这个的。但 cloud code 的 tito 不是 普通的任务清单， 它是动态深沉的，会根据上下文变化，它会被反复注入到上下文的开头，让模型时刻记得自己在做什么。上下文压缩的时候，它还能作为记忆的锚点。简单说，它是 agent 的 短期记忆系统， 这是第一层差距，第二层更不容易看到模型和工具的协调训练。社区讨论里有人指出一个关键细节， cloud 模型是专门针对自己的工具调用场景做过训练的。 这不是你写完代码再介绍模型，这是在模型训练的时候，就包含了大量工具调用的场景。这意味着什么？传统做法是模型是模型，工具是工具，中间用 prompt 连接。 entropy 的 做法是模型在学习的时候就在练习怎么正确调用工具。差别就像一个是后天学开车， 一个是天生就长在电动车上，这叫 r l v r reinforcement learning with variable rewards 模型训练时就在学什么时候该调用工具，怎么正确格式化，参数 复杂，任务应该按什么顺序调用。所以如果你用 cloud api 做自己的 agent， 有 个建议尽量使用类似 cloud code 的 工具 schema， 因为这些模式模型见过。这是第二层差距， 护城河不再代码在训练数据，第三层是最容易被低估的功臣。细节，两百行代码能实现基本循环和工具调用 没问题，但有一堆问题他没法处理。用户在执行中途发消息怎么办？工具执行超时怎么办？上下文太长，需要压缩的时候怎么保留关键信息？ 多个子任务需要并行的时候怎么协调？社区有个评价很到位，他说很多人觉得自己能搞定 context 的 管理，然后一整年都耗在这上面。这不是夸张， cloud called the agent 的 系统也不简单，它有独立的 system prompt， 可以 指定不同模型， 有自己的工具集。不是简单的函数调用，是一个完整的任务分发系统，加上 hooks， skills 这些功能，每一个都不是锦上添花，而是让 agent 从能跑到好用的关键。这是第三层差距。好，三层都讲完了，我们来做个总结，两百行代码能写 cloud code 吗？技术上能， 如果你只要最核心的循环，实际上不能。如果你要的是生产级效果，差距在三个层次，第一，状态管理， to do 系统。第二，模型优化协调训练。第三，工程细节生产打磨。对我们的启示是什么？如果你在做 agent， 短期来说，不要重复造轮子， 用 cloud code sdk， 用成熟的 agent 框架。长期来说，关注模型和工具的协调工具 skimi 的 设计很重要，尽量贴近模型见过的模式，二零二五年做 agent 的 正确姿势，复杂的循环逻辑，用现成 sdk。 差异化的价值放在工具设计和领域 no 号上。如果非要自己写， 先研究 cloud code 怎么做的，不要在已经解决的问题上花时间。有个有意思的现象，社区已经出现了一批逆向分析 cloud code 工具， cloud trace 可以 看完整的调用链， contextify 可以 搜索历史对话神态在倒闭透明。这些资源链接我放在评论区了，有兴趣可以去看看。最后一句话总结，两百行代码能写出 cloud code？ 能， 但那只是皇帝的衣服，真正的皇帝不在代码里，在模型和工具的协调进化中。这里是 l l mx factors， 我 们下期见。

很多人在争论 ai skills 是 不是涌现行为，但我发现这是个假问题。真正的问题是，你给 ai 装了一堆技能， 他不知道什么时候该用。大家好，这里是 l l mx factors， 一个专注于拆解大语言模型时代底层逻辑的频道。今天我们聊一个 ai a 阵的开发中最容易被忽视的困境。先看一条真实的开发者反馈。有人说，我问一个我知道应该激活 skill 的 任务， cloud 直接做了，根本没用。 skill 能力有了，出发没了，这才是问题。我们先搞清楚 skills 到底是什么。社区里有人一句话，破功， skills are just prompts the agent can choose to load that's it。 不是 什么黑科技，就是预加载的 prompt 关键词在哪？ can choose to load， ai 可以 选择加载，问题是它会选吗？ skills 和 m c p tools 有 什么区别？ tools 是 函数调用，静态绑定的， m c p 是 动态工作流引擎，复杂但强大。 skills 呢？ 可选夹子的 prompt， 简单但靠人设计。有人说得好， scales 是 更用户友好的 m c p 精简版 scales 组合使用确实有价值，就像工具箱里的扳手、螺丝刀、锤子，组合起来能完成更复杂的任务。但问题来了， ai 知道工具箱里有什么，但它不知道什么时候该用哪个。这就是触发困境的本质。要让 ai 正确激活一个 skill， 需要三步， 识别、场景匹配决定现在该用。执行加载使用第一步就经常失败， ai 不 认为当前场景需要用这个 skill。 有 人想出一个办法，用一个 router skill 来管理其他 skills。 听起来很聪明，但问题是 turtles all the way down。 你 需要 router 正确激活 route 需要什么来正确激活另一个 route 无限欠讨。还有人用 hooks 就是 不断提醒 ai 有 哪些 skills 可用。问题是太通用，缺乏针对性消耗上下文窗口，治标不治本。这告诉我们什么 agent 开发的核心困境是能力不等于可用。 你以为 agent 的 开发是给 ai 更多工具，写更强的 prompt， 增加能力，实际上 agent 的 开发是让 ai 知道什么时候用设计出发条件，增加可信。好的 skill 设计不只是能力描述，需要包含清晰的出发条件，什么时候用明确的边界，什么时候不用 原子化设计一个 skill 做一件事。这就是为什么 demo 爽上线崩 demo 的 时候，你手动告诉 ai 用什么工具。 production 的 时候， ai 需要自己判断用什么百分之九十的 agent 项目死在这一步。给你三个实操建议，第一， 设计 skill 时先写触发条件，不要只写这个 skill 可以 做什么，要写当用户提到什么关键词且场景是什么条件时使用这个 skill。 第二，测试触发比测试执行更重要。设计十个应该触发的场景，十个不应该触发的场景， 跑一遍看成功率。如果激活率低于百分之八十，先修出发逻辑，别急着优化执行。第三，组合 skills 要设计协议。 skills 之间的调用需要明确的入口，出口状态传递规范失败处理机制，否则组合只会增加混乱。回到开始的问题， skills 组合是不是涌现行为？这个问题不重要，涌现是系统产生设计之外的行为， skills 组合是设计内的能力叠加，叫什么不影响你的 agent 能不能用什么才重要， 可能性大于能力。一个能稳定触发的简单 skill 好 过十个触发不了的复杂 skill。 agile 工程的本质，让正确的能力在正确的时机被正确地调用。所以今天的核心判断是什么？争论涌现是假问题， 真问题是 ai 有 了技能，不知道什么时候有。这是 agent 开发最难的部分，也是区分 demo 和 production 的 关键。原文链接我放在评论区了，你在开发 agent 的 时遇到过 skills 触发的问题吗？欢迎评论区讨论。这里是 l l mx factors， 我 们下期见。

好，这节我们继续来学习 cloud 当中的 skills， 那 上一节当中我们学习的如何使用 ui ux pro max 这个项目去开发一个这样的 ui， 那 其实啊，整体流程大概是这样子，对吧？我们分布一个任务，然后 ai 读这个 skills 文件，最后去通过这个脚本查出当前样式，最后返回给你。那上一节呢？ 嗯，没看的小伙伴可以去看一下。好吧，这一节我们就不过多追述了，我们这一节呢，主要是给大家分享一下，就是关于 cloud skills 是 如何去使用的，因为我发现很多小伙伴有这方面疑问，就是什么是 skills 以及 skills 呢？它能够给我们的 cloud code 带来什么？或者给我们的 cloud 的 模型带来什么，对吧？首先我们先要明确一个， 首先我们需要明确一个概念，就是，呃， skills 呢，实际上是给 ai 加装的一个插件，类似一个插件，你可以理解为它是一个 prompt 的 集合， 需要按顺序加载，能够帮助你提高你的效率。那相比于 m c p 呢？它不需要去调用一些外部的工具，它只是单纯的一段题的词，仅此而已。好，我们开始走什么 skills？ 我 们刚说了，本上 skills 呢，就是一个文件夹，这个文件夹里面包含了指定脚本资源， cloud 呢，会按需加载，就是这个指令，什么时候需要使用这个指令，它会自己去找。什么时候需要这个脚本呢，它也会自己去找。那这时候呢， cloud 呢，是完全自动地接管了你的这个啊，这个权限，然后去，哎，去掉这个 skill， 哎，我该干什么干什么，所以你可以在这个 skill 里面去写，哎，你需要干什么？简单来说，对吧，给 cloud 加技能包， 让 cloud 变得更聪明，那这四个特性大家简单看一下就行了。好吧，我们就往下走，那下面我们来简单说一下， cloud 目前有三种分类，第一种呢是个人技能，也就是说你这个 skill 呢，你的所有项目 都可以使用，比如说我现在配置的一个全职的 skills， 对 吧？那你需要配置在这个点， cloud 杠 skills 下面，这是一个全职的技能，也就是你所有的项目啊，都可以去使用这个 skills， 而不仅仅局限于某一个项目。 第二个是项目级别 skills， 也就是说你这个 skills 呢，只对当前的这个项目的跟目录下面的所有文件生效。哎，秃了这个文件，对吧？它就不生效了，懂我意思吧？第三个是插件的插件也是一样的，就是你安装之后，你所有项目也是一样生效，只是说你可以随时卸载它。好吧， 我们继续往下走啊，首先我们要去使用 skills 呢，需要去插件市场安装一下啊，下面我给大家演示一下。首先我们打开 cloud code， 那 这里呢？我去，哎，去清空一下啊，这时候如果说我需要安装 skills， 你 可以执行这条 mini， 哎，去安装一下 astroc 的 这个 skills 啊，因为我这里呢，要叫有个窗口，我就发跳价哦，我直接发进到高度的 啊。然后这个时候我们再执行这条 mini， 这是那个 cloud 当中的一个 plugin mini 插件 mini 回车啊，这时候我们可以看到，对吧？它在添加这个 skills， 你 看 这个 skills 呢，它是存在 astropica 的 官网，所以呢，它通过 get 啊，给它下载下来啊，就就安装完成了，就安装这个配置，就安装完成了， 好吧，那这里我们就退出了，好吧，那我们可以选择去，哎，可以去安装你的插件，也可以选择去卸载你的插件，好吧，这时候我们就安装完成，之后呢，那 这时候我们就可以使用 skills 了，就这么简单。那这个默认的 skills 里面有什么东西呢？很好的一个问题，它目前提供了两个问题，第一个是 document， pdf 文件之类的， 第二个是一些视力技能包，比如说 m c， p 啊，视觉之类的，就是官方提供了两个 skills。 好， 这时候我们可以就可以去掉这个 skills。 好， 看它是不是创建成功了，比如说，哎，请你给我创建一个学生管理系统需求的啊，文件使用 skills 啊，这是这是 student 点 pdf， 它就这样子，它会给你一个 pdf 文件，那用到 skills 呢？其实这个 cloud code 呢，也会告诉我们是不是用到了这个 skills， 我 们可以看一下 啊，这时候你可以看到是否使用这个 skills， 也就是用这个 pdf 的 skills， 也可以看到这个地方出现这一段话，就是我们用到了什么，用到了第一个 skills， 这个 skills 呢，因为有一个 pdf 文件，那这时候我们可以选择 yes， 也可以选择，哎，下次不提醒它，我们选择， 那这时候我们可以的话就去调这个 skills 了，然后呢，哎，这个 skills 里面呢，因为本身就包含了这个这个命令，所以呢，你看它会自动去执行这个命令，我们并没有跟他说，哎，你要执行某一个命令，使用什么什么库，为什么？因为它的这个 skills 里面就包含了 pdf 的 操作。好，最后总结一下，对吧？所以我们实际上就是将 啊 astroc 它整理的一些啊技能包在这个 prompt 当中啊，给你声明好了，这些啊，比如说调 pdf， 它需要用到哪些工具，需要用到哪些题的词，对吧？它需要用到哪些插件，哪些库，对吧？它都给你整理好了，所以呢，这个时候我们就可以啊，去看到这个啊，这个目录下面会有一个这个 pdf 相关的技能包啊，类似于我们之前学习这个 啊 kilo 的 时候，你看是不是？我们学习 kilo 时候是不是讲过，对吧？是不是有一个 skill， 你 看这 skill 嘛，它会声明你用的是什么 python 什么的啊，什么样的版本，那就那么一个意思，好吧，好，最后呢，安装完成会保证这个目录下面我们先不讲啊，这里我们就我们可以看到就用了这个 skill， 我 们就跳过这样，我们执行完成之后还会确实会给你生成一个 pdf， 类似于人家已经封装好的 prompt， 好 吧， 这时候我们就明白了，对吧？当我们使用 skills 的 时候呢啊， cloud 会自动加载这个 pdf skills 以及文档分析 skills， 最后输出给你一个结果，而不是全部加载上下文中，有效节省头壳，就就是类似于那个 cloud 的 一个机制，好再往下走呢，其实我们和 mcp 的 一个区别是什么？就我们可以看到，对吧？ m c p 呢，是外部提供的应用工具能力，而 scuse 呢，更像是去教模型如何使用工具，在那个结识当中去声明，哎，声明我到底该怎么做，对吧？引导他去执行啊？教模型的一种方法，一般来说我们会通过 m c p 和 scuse 协调工作，最后呢，再通过 scuse 引导去来最终执行。好吧，那这个，这个是什么意思呢？这是斜杠命令啊，意思啊， 所以呢，它也是一个区别。好吧，好，那就本期视频的全部浏览。如果呢，你也对这种 sku 感兴趣的话，不妨去试一下。那通过这个杠 prang 的 插件，对吧？去选择你要安装的插件，包括这个管理所需要的插件。那正常的一个 sku 目录呢？是一个这样的目录，比如说文档啊，文档里面有这个，这个角落会写在这里面啊，资源会写在这里面，它就有一个清晰的分类，这就是所谓的 sku， 那 包括我们也可以看到，对吧？它全程在使用这个 sku 来去执行，我们并没有去插手。好吧，好，那就本期视频的全部浏览，我是小刘，我们下期再见。