|
系统自带的Skill在点Cloud这个目录之下，其中有一个是特殊的，是Skill-Creator， 它是专门帮助你去创建Skill的Skill。 在下面这个PPT中我们可以看到Skill它的调用方式是可以在Python中直接去执行的. 这就意味着我们可以直接把这些Agent过程在Python中去执行，非常的高效，而且意味着你可以进行非常灵活的模块化功能组合. client.beta是Anthropic Python SDK（即标准anthropic库）中的一个命名空间或访问点，专门用于访问和调用Beta（测试/预览）阶段的功能。
下面页面，是通过Python去调用Skill的核心逻辑。我们可以看到，当用户发出自然语言的请求之后，Cloud它本身会作为一个调度器，把你的请求和要使用的技能以及它对应的代码组合在一起，形成一个任务包。 然后在这个任务执行完成之后，给你创建出对应的PPT或者相关的交付产物 上下文管理，是 Skill 模式能高效纳入复杂知识的核心逻辑。 最基本的原理是什么？ 当我们要做一件事，文档里可能有一本很长的 SOP 手册。但我们不是第一时间把整本书读完，而是先看目录，从元数据中判断这个工具对当前任务是否有用。然后在任务分析阶段，再决定是否要读完整文档，或者调用其中提供的工具。 这种方式叫做渐进式披露（Progressive Disclosure）。 它解决了大模型 Agent 的一个核心痛点：如何高效加载上下文，避免过长的上下文直接拖垮模型性能，同时大幅降低 Token 成本。 关于 Token 成本，其实在很多场景下，我们已经可以不太 care 了——它没那么贵。 但过长且无效的上下文，带来的问题远不止钱。 它会直接影响大模型输出的稳定性和准确性，还会导致响应时间过长——程序超时、用户等不及、体验崩盘。 这才是真正要命的地方。 关于 Skill 的构建，有三个基本原则。 第一，Concise——简洁。 核心逻辑是什么？你要假定使用的大模型已经具备通用行业知识。 不用再给它解释什么是 SQL 语句，什么是 PostgreSQL 数据库。指令越简洁越好，因为它本身就带通识。 第二，设定合适的自由度。 这里的逻辑是：Skill 是可以在多个任务之间复用的，不要把一个 Skill 和某个特定任务强绑定。 比如你要创建一个"数据分析"Skill，可以给它一个框架性的参考——数据格式介绍、有效性验证、分析启动等几个部分。但不要定义过于严格的模板。 模板太死，每次输出都是一个模子刻出来的，这就违背初衷了。 第三，跨模型测试。 这个基本没什么问题。框架 OK 的话，换到不同模型，只会影响大模型生成的那部分。当然，更高级的模型拿到的结果通常也会更强。 自由度的谱系，说的是如何指导 Agent 完成具体操作。 这里给出三个档位： 第一档：开阔地带（Open Field） 适用于开放性任务，没有严格的校验标准。这时候给出的是指导性原则，本质上就是一个提示词。 第二档：明确路径（Clear Path） 任务已经有相对明确的路径。比如把 Markdown 文档转成 HTML，有专用的 Python 包可以用。这时候可以给出包含代码、伪代码、参数的模板，让 AI 参考，确保它在多种选项中采用最佳实践。 第三档：严格执行（Strict Execution） 适用于容易出错的高风险场景，比如数据库迁移。这时候要确保每次执行都保持完整一致性，可以直接在脚本路径下创建指定代码，并把要求写入 Skill.md 文档中。 简单说：开放任务给原则，常规任务给模板，高风险任务给代码。 Claude 中定义的各种 Skill，可以再次组合。 比如，Excel 处理 Skill + 报告生成 Skill，最终结果就是：解析 Excel 文件 → 完成数据分析 → 生成 PPT。 或者，品牌设计 Skill + 项目策划 Skill，完成策划 → 创意文案，一条龙搞定。 换个视角看：每个 Skill 相当于一个高级专业员工。 多个 Skill 在一起，就是一个团队。 这时候一个公司级别的任务抛下来，具体需要哪几个"员工"去做事？Claude 会根据它们的能力和属性，自由组队，综合完成高复杂度任务。 这不是工具调用，这是 AI 在组建项目组。 顺着上面的逻辑，我们可以很明确地看出来：Skill 框架会直接颠覆之前那些相对固化的拖拉拽、低代码工作流。 而且每个 Skill 之间可以互相组合，调用多个 Skill 的提示词问题？你也不用操心，Claude 会自动帮你解决。 说到这里，给个暴论： 低代码平台已死，只是尚未入土。
| 
